3

I want to log, with iptables, everything wich can seems to be a flood, except on the web and IRC ports. So I did:

iptables -A INPUT -p tcp -m multiport ! --dports 80,443,6667,6697 -m hashlimit --hashlimit-above 10/sec --hashlimit-burst 20 --hashlimit-mode srcip --hashlimit-name aflood --hashlimit-srcmask 8 -j LOG --log-prefix "[IP FLOOD ALL]"
iptables -A INPUT -p udp -m multiport ! --dports 80,443,6667,6697 -m hashlimit --hashlimit-above 10/sec --hashlimit-burst 20 --hashlimit-mode srcip --hashlimit-name aflood --hashlimit-srcmask 8 -j LOG --log-prefix "[IP FLOOD ALL]"
iptables -A INPUT -p icmp -m hashlimit --hashlimit-above 10/sec --hashlimit-burst 20 --hashlimit-mode srcip --hashlimit-name aflood --hashlimit-srcmask 8 -j LOG --log-prefix "[IP FLOOD ALL]"

But when I look in the logs, I get (MAC and IP obfuscated):

Aug  3 16:49:00 server kernel: [IP FLOOD ALL]IN=eth0 OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:00:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=107 TOS=0x00 PREC=0x00 TTL=61 ID=6765 DF PROTO=TCP SPT=6667 DPT=40605 WINDOW=10818 RES=0x00 ACK PSH URGP=0
Aug  3 16:49:00 server kernel: [IP FLOOD ALL]IN=eth0 OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:00:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=104 TOS=0x00 PREC=0x00 TTL=61 ID=54214 DF PROTO=TCP SPT=6667 DPT=49484 WINDOW=10815 RES=0x00 ACK PSH URGP=0
Aug  3 16:50:00 server kernel: [IP FLOOD ALL]IN=eth0 OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:00:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=60 ID=9024 DF PROTO=TCP SPT=80 DPT=36729 WINDOW=123 RES=0x00 ACK FIN URGP=0

You can see the SPT having values I normaly protect (6667 and 80).

Anyone has an idea about this trouble ?

CrazyCat
  • 61
  • 2

2 Answers2

2

Those packets are returning from connections made to external IRC servers (they come from source port 6667). Your set up aims to lift limit only for inbound IRC connections (inbound destination port 6667 and so).

asdmin
  • 2,050
  • 17
  • 28
  • I'm not sure I understand completely the logic, but I've tried using **ports** rather than **dports** and it seems ok. Like this, do I really have an exception for people visiting my websites or using my IRC server ? – CrazyCat Aug 04 '16 at 07:38
  • the INPUT chain matches only incoming packets, and you matched the destination port of those incoming packets, indicating that you want to 'whitelist' packets for connections initiated remotely to your IRC server. The packets which you indicated in the original question were belonging to connections, which were initiated by your side to a remote IRC server. The whitelist was not matching, because of that. – asdmin Aug 04 '16 at 10:18
  • All right, I understand. Btw, I've added a `-m state --state NEW` and it seems to work as I wanted. – CrazyCat Aug 04 '16 at 13:33
  • So the issue was that your server itself opened new connections and what ended up in the logfile were the answer packets belonging to the connection opened by your server? Can you confirm this by looking at the IP addresses? – corny Aug 06 '16 at 18:04
1

Answer: All the packets you see in your logfile perfectly match your firewall rules. Your rules never attempt to do any matching on source ports.

So, what does the logfile tell you? Either your machine maintains valid connections with other servers or someone is sending spoofed packets to your machine. As suggested in the other comments, it's quite likely that your machine has established outgoing connections to other irc servers and the logged packets are answers from these servers.

Here is how I got the Answer: I just dumped your rules into fffuu and slightly manually tuned the output. I rewrote your LOG actions to ACCEPT and the default policy to DROP to see what will be accepted (i.e. LOGed) after simplification.

Here is the output after the ruleset got simplified and all negated matches on ports were rewritten to non-negated matches. Due to my previous replacement of LOG by ACCEPT, everything the firewall below accepts will also get logged by our original ruleset:

ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0    dports: 0:79
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0    dports: 81:442
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0    dports: 444:6666
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0    dports: 6668:6696
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0    dports: 6698:65535
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0    dports: 0:79
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0    dports: 81:442
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0    dports: 444:6666
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0    dports: 6668:6696
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0    dports: 6698:65535
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0    
DROP       all  --  0.0.0.0/0            0.0.0.0/0

Now, you can easily match the packets from your logfile to this simplified firewall. They all match.

Disclaimer: I'm the author of fffuu, my views may be biased and fffuu is not perfect (yet). But hey, it's free and libre and I hope it helps :-)

Reproducibility

Here is what I did in detail, in case you want to reproduce:

I rewrote the LOG actions to ACCEPT, used iptables-save format and saved it to foo.txt:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -p tcp -m multiport ! --dports 80,443,6667,6697 -m hashlimit --hashlimit-above 10/sec --hashlimit-burst 20 --hashlimit-mode srcip --hashlimit-name aflood --hashlimit-srcmask 8 -j ACCEPT
-A INPUT -p udp -m multiport ! --dports 80,443,6667,6697 -m hashlimit --hashlimit-above 10/sec --hashlimit-burst 20 --hashlimit-mode srcip --hashlimit-name aflood --hashlimit-srcmask 8 -j ACCEPT
-A INPUT -p icmp -m hashlimit --hashlimit-above 10/sec --hashlimit-burst 20 --hashlimit-mode srcip --hashlimit-name aflood --hashlimit-srcmask 8 -j ACCEPT
COMMIT

Then I just ran fffuu --chain INPUT foo.txt to get the output from above.

(fffuu is still under development, I'm using the repo development snapshot of fffuu fb858bcf95268451772ca9156a04b9fc229d3578 for this comment)

corny
  • 285
  • 1
  • 6
  • I think he needs an answer to his question, not a suggestion & how-to for an external tool. – asdmin Aug 08 '16 at 11:33