iptables (netfilter) losing packets!

koningshoed · 06-26-2003, 06:24 PM

Hello all,

yes, I'm serious, according to me, the netfilter code in linux (2.4.18 - patched ipt_ULOG.c as well as 2.5.69 - and therefor likely 2.5.72 as well) loses packets under some circumstances. Yes, I felt the same way, ok, here it goes, I flush my tables, and set all policies to accept, and then add some logging and some denying (We're writing a portknock server and is trying to tap into the ULOG target in order to pick up the knocks).

iptables -F
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -A INPUT -p tcp --destination-port 745:1000 --syn -j ULOG
iptables -A INPUT -p tcp --destination-port 745:1000 --syn -j DROP

that settles the firewall part, and the environment for the port knocking to be able to occur. Replace LOG for ULOG in the above and find logging info by tailing /var/log/messsages.

Now, out portknock program produces the following output, and this works correctly (try the above without the DROP rule).

$ ./portknock --remote=localhost --option=ssh --pass=private
Good.
MD5: 2c:17:c6:39:37:71:ee:30:48:ae:34:d6:b3:80:c5:ec
CSEQ: 73:73:68:00:00:00:00:00:00:00:00:00:00:00:00:68
ESEQ: 18:89:5b:21:62:bf:22:49:53:e3:ce:03:3c:10:d3:e2
knock: 769
knock: 882
knock: 836
knock: 778
knock: 843
knock: 936
knock: 779
knock: 818
knock: 828
knock: 972
knock: 951
knock: 748
knock: 805
knock: 761
knock: 956
knock: 971

But, when I use the "full" ruleset as above, I end up with the following three lines in my log:

Jun 27 01:09:00 kroon kernel: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=65216 DF PROTO=TCP SPT=32816 DPT=769 WINDOW=32767 RES=0x00 SYN URGP=0
Jun 27 01:09:03 kroon kernel: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=65217 DF PROTO=TCP SPT=32816 DPT=769 WINDOW=32767 RES=0x00 SYN URGP=0
Jun 27 01:09:09 kroon kernel: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=65218 DF PROTO=TCP SPT=32816 DPT=769 WINDOW=32767 RES=0x00 SYN URGP=0

Which is
1) All the same (The first packet).
2) Incomplete.

iptables also only reports having seen 3 packets (using the counters).

Please tell me it's just me screwing up. I really do not want to go bug-hunting in kernel code ...

I'm willing to send all code I have on request to specified email addresses.

beltorak · 06-26-2003, 09:42 PM

I am not familiar with the details of portknocking -- just the basic idea. try these rules (as a portknock may or may not send a 'syn' packet to the various ports):

Code:

iptables -A INPUT -p tcp --destination-port 745:1000 \
    -m state --state NEW -j ULOG
iptables -A INPUT -p tcp --destination-port 745:1000 \
    -m state --state NEW -j DROP

I think that is more or less what you intended with the syn packets...
If you think iptables is still dropping packets, remove the '-m state --state NEW' bit.

hope this helps...

-t.

koningshoed · 06-27-2003, 06:50 PM

Problem solved. See http://www.kroon.co.za/portknock

Anyway, I feel extremely stupid. The iptables commands are fine, so is my ulogport program (although it seems weird). After using hping to perform a sequenced knock I realized that the problem was in the client code. When a socket times out, it's ripped to threads in the kernel, although not as expected. Executing a successive connect on the same sockets fails, but it doesn't fail with EBADFS, but rather with one of ETIMEOUT ECONNREFUSED or EINTR (I suspect ECONNREFUSED as it seems to be attempting to reconnect to the same ports). Anyway, I modified the client to use a clean socket for each connect system call and it now works as expected.

Sorry about this.

beltorak · 06-28-2003, 02:31 PM

hey, not a problem. Good that you figured it out, and even better that you told us what it was.

What ulog program are you using? is it of yer own writ? I wrote a small program to partially decode the ulog messages, and am working on a better one now when I have time (yeah, right, time hahaha).

-t.

koningshoed · 06-28-2003, 04:09 PM

You can easily help, I'm publishing my code (http://www.kroon.co.za/ulogport), and yes, it is of my own design. It sucks atm, all it can do is check that the packet was a tcp packet, and if so, what the source ip was and the destination port, it prints this out. The only reason I wrote it in the first place was to work with my portknock program (http://www.kroon.co.za/portknock) which can be configured to do all kinds of really wicked stuff. I'm actually still looking for beta testers (hint hint).

And I suspect what I call portknocking is something else from what you understand? portknocking is when some packets are sent to your ip stack to test it, hack it, etc (or at least that is what I understand). We are using it as a method of passing data through a firewall, or rather, to give commands to the firewall from a remote location. So far we have managed to configure it to open ssh for us to a given ip without having access to the server.

Well, actually, for that specific tryout I merely constructed a simple syn-blocking firewall, and logged some SYN packets to ULOG which I picked up as the knocks. Then I send a specific sequence of knocks, which the server then picks up, and takes appropriate action (opening ssh in this case).