I forwarded port 80 to my DMZ.
How relevant is it also to set the TCP flags ACK, SYN, PSH, FIN in firewall rules?
First the dst-nat rule is needed.
And then a rule from wan to dmz and then a second rule from dmz to wan.
How must be the TCP flags set for the two firewall rules that the routing is secure?
I saw that TCP connections to the webserver are very long established - can I set a lower timeout?
Now a lot of abnormal requests came from an ip-adress located in china.
How can I set a fail2ban list for ip-adresses which tries several invalid combinations of tcp-flags?
Does noone have some hints for me? 
How relevant is it also to set the TCP flags ACK, SYN, PSH, FIN in firewall rules?
How must be the TCP flags set for the two firewall rules that the routing is secure?
In this case it is not relevant.
I saw that TCP connections to the webserver are very long established - can I set a lower timeout?
Under IP > Firewall > Connections > Tracking you can change the session timeout for TCP Established sessions, but this setting is effective on all the TCP sessions on the device.
How can I set a fail2ban list for ip-adresses which tries several invalid combinations of tcp-flags?
I can’t help you with that. Sorry.
How can I set a fail2ban list for ip-adresses which tries several invalid combinations of tcp-flags?
It it possible to detect and filter manipulated requests?
I personally believe that this is overkill on routers - make sure the server’s OS and applications offered to the Internet are all maintained well and kept updated with the latest patches. Certainly hackers are going to think of many more things to break than you are going to be able to think of with strange combinations of TCP flags and setting different timeouts.
Follow best practices:
If it’s not needed, turn it off.
If it is needed, turn it on and keep it up-to-date
On firewalls:
forward only the packets for the services you intend to offer
discard all other connections
If you’d like to detect port scans and blacklist the source for a while-
make the first two rules of the filter chain be drop rules for src-address-list=BLACKLIST and dst-address-list=BLACKLIST
make the rules which allow the published services (e.g. permit http inbound) have a rate-limit per-src-address…
put the same rate limit on the “discard all others” rule (per source address)
then after that, create a new rule which adds the src address to BLACKLIST with timeout=1d (or whatever blacklist period you want) and then a final drop all rule with no rate limits, etc.
You may want to make another address list ‘UNBANNABLE’ and modify the rule that adds the src to the BLACKLIST by including src-address-list=!UNBANNABLE. This prevents an attacker from being able to spoof your important remote addresses with traffic that would get them blacklisted. (e.g. the DNS root servers… )
You might also create a “port knock” configuration that your internal servers could use to send a blacklist entry if their fail2ban rules trigger… (i.e. if a server logs an ssh brute force attempt, it can fail2ban the remote IP for its own services, and then send a port knock to the Mikrotik that will cause the offending IP to get blacklisted.)
Ok, thx very much.
All your hints I have already implemented.
My RB2011 has a CPU utilization about 3 up to 15 percent (about 30-40 permanent outgoing/incoming connections).
So I thought the router could also check the traffic for any anomalies for example: initialitation, three-way handshake, right synchronization and acknowledgement, and so on.
What I am interested in, is there any penetration test or hacking attack where a Mikrotik router was involved in first instance?
I used to have a few rules that examined the TCP flags, and then I came to realize that this was just drilling a second hole into the lid of my garbage can, so to speak… I was already going to throw away new stuff I didn’t want, and the Mikrotik was already configured to deny all connections from the WAN except from my office’s static IP…
Besides, there are more combinations of ways to mess with TCP flags and such than I’m aware of, and more will be invented in the future. If you’re really set on it, I’d just modify the rule that permits tcp/80 state=new and require that the syn flag be set.
As for the timeout values in connection tracking, I find the default timers for TCP connection tracking to be pretty workable in most situations.
Thanks.
Yes, there are some different combinations possible but if I only allow the “good” combinations for port 80 forwarding and drop all the rest it should work.
I tried to set at incoming port 80 rule the syn and ack flag to check if the handshake is right but it does not work.
Moreover, the logging of the mikrotik is not very detailed - it would be fine if the sequencs number and so on also will be logged. 
Normally this order should be the right one:
incoming:
1syn
3psh+ack
outgoing:
2syn-ack
Now I created three rules but how can I set that the right order must be observed because any other order like ack,syn,psh+ack would be not valid.
How can I set that rule 3 only is allowed when before rule 1 came in?
Has noone an idea how incoming connections could become more secure by checking the TCP flags? 