New connection but not SYN

Hi maybe anyone understands this better. There are occassions i’ve been bombarded with ACK request but looks like a NEW connection, should be a SYN request.
And it seems default firewall were not able to block it.

I posted this a while back
http://forum.mikrotik.com/t/receiving-lots-of-ack/126550/1

See picture here is a firewall i’ve made to detect and block it

add action=add-src-to-address-list address-list=UNKNOWN_IPS \
    address-list-timeout=1d chain=input comment="Add to list ACK requests" \
    connection-state=new in-interface=ether1 log=yes log-prefix=\
    ADD_UNKNOWN_IPS protocol=tcp tcp-flags=!syn
add action=drop chain=input comment="Block UNKNOWN_IPs" in-interface=ether1 \
    log=yes log-prefix=DROP_UNKNOWN_IPs src-address-list=UNKNOWN_IPS




What should be the firewall? to prevent this DDOS i guess. I just drop NEW connection but is NOT SYN request

The default firewall will block this, so you have probably fouled it up.
(it should only allow new traffic going outside, not this kind of new traffic coming in)

When you see this a lot you probably have connection issues on the inside (e.g. users losing their WiFi connection while using your network).

Thanks!

here’s my firewall i’m not sure where in part i made a mistake. How do i prevent it? its consuming bandwidth

/ip firewall filter
add action=fasttrack-connection chain=forward comment="fasttrack LAN" \
    in-interface-list=LAN log-prefix=FT out-interface-list=LAN
add action=drop chain=forward comment="Drop invalid packets" \
    connection-state=invalid in-interface=ether1
add action=accept chain=forward comment=\
    "Allow established connections on Internet" connection-state=\
    established,related in-interface=ether1 log-prefix=LAN
add action=accept chain=forward comment=\
    "Allow established connections on LAN" connection-state=\
    established,related in-interface-list=LAN out-interface-list=LAN
add action=drop chain=input comment="Drop invalid packets" connection-state=\
    invalid in-interface=ether1 log=yes log-prefix=INVALID_PACKETS
add action=add-src-to-address-list address-list=UNKNOWN_IPS \
    address-list-timeout=1d chain=input comment="Add to list ACK requests" \
    connection-state=new in-interface=ether1 log=yes log-prefix=\
    ADD_UNKNOWN_IPS protocol=tcp tcp-flags=!syn
add action=drop chain=input comment="Block UNKNOWN_IPs" in-interface=ether1 \
    log=yes log-prefix=DROP_UNKNOWN_IPs src-address-list=UNKNOWN_IPS
add action=accept chain=input comment="Allow OpenVPN" dst-port=1194 \
    in-interface=ether1 log-prefix=openvpn protocol=tcp src-address-list=\
    !UNKNOWN_IPS
add action=accept chain=input comment="allow PPP devices" in-interface=\
    all-ppp
add action=accept chain=input comment="Allow all outbound" connection-state=\
    established,related in-interface=ether1 log-prefix=OUTBOUND-REPLY
add action=drop chain=input comment="drop all router request" in-interface=\
    ether1 log-prefix=DROP_PACKETS

That is not at all what the default firewall looks like.
You could reset it and work from there or consult another topic how to setup a correct firewall.
In any case there should be some drop statement at the end of chain=forward, e.g. drop everything from ether1.

Hello,

This is my (very basic) suggestion. It’ll be your job to translate it to ROS :wink:

==1==
chain=intput
in-interface=ether1
connection-state=established, related
action=accept

==2==
chain=forward
in-interface=ether1
connection-state=established, related
action=accept

==3==
chain=intput
in-interface=ether1
action=drop and log
log prefix=CA-IN===
comment=“-----CATCH-ALL-----”

==4==
chain=forward
in-interface=ether1
action=drop and log
log prefix=CA-FWD===

With these 4 filters (out towards in), you permit legimit traffic back to your router or your network and drop the rest. You won’t even need to speficy connection states (inv and new). But you mat add those if you have need of it for statistical reasons.

This said, I don’t suggest the use of “FWD ACCEPT” between your LANs as it adds a load on the CPU, unless you specificaly need to control traffic betwwen LANs. Its not a big load, you’ll say, but I like to cut back on ressource usage as much as I can. You may want to continue using fast-track though.

Also, I don’t suggest that you add bad IPs to an address list on a permanent basis as the list WILL grow and use up memory. I usualy add them for 30 minutes. I figure that if one IP comes here by mistake, it’ll be gone in 30 minutes and wont come back. Idiots (or hackers to be politicaly correct) will just reappear every 30 minutes :wink:

Final piece of advice, look at your counters and place the filters that get the most hits on top. BUT DONT break the logic of your firewall though. For example, CATCH-ALL filters MUST be the last ones, its their job to catch whatever was not processed before. The reason for that is that the sooner the packet gets processed, the sooner it releases the CPU.

Cheers,

Thanks @AlainCasault @pe1chl ! I am learning so much here. i’ll try fixing my firewall based from your inputs. Thanks for the help!

This is normal “background traffic” - a client behind your router closed a connection to a server (FIN / RST) but the packet was lost in transit. The server has no idea the connection is closed, but because your router saw the outgoing FIN / RST, it removed the conntrack entry. So any packets coming from the server are now considered to be invalid (only SYN can be new, unless it’s UDP). Not sure what you’re trying to do with the address list and ack rules, the default firewall will drop this unknown traffic just fine.

Thanks. okie, my issue is sometimes i see a flood of ack just no idea whats going on (see link in post 1). I was just trying to understand if its a legit connection or someone was DDOS my router.

What I said: when you see a “flood” of these it is most likely that your clients have lost their link while pulling traffic over your router.
Or when it is really a bad flood it could be a DDoS. However, there is not much you can do against a DDoS by using a firewall on your
own router, except when the bandwidth you have towards internet is much larger than the bandwidth towards your clients.