iptables and 'new not syn' packets

Printable View

06-05-2009
BNSC

iptables and 'new not syn' packets

Hello,

Our machines are running behind a Debian firewall/router with iptables, under a 2.6.26 kernel, and with a fairly generic set of rules.
One such rule...

Code:

iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

... drops 'new not syn' packets. The log usually contains a few, less than 20, of these each month. However, after recently starting some work with another known (and I think trusted) site, communications with them yield at least one of the above mentioned packets with each contact. Sometimes 60-80 per day. The remote site is adamant that the problem has to lie in our OS or netfilter configuration. The occurrence of these packets doesn't seem to have any adverse effects on the exchange of data, the work flow appears to hum along fine. My question is, is it logical to assume that, given the 'every single time' occurrence of the dropped packets, and no other increase in activity in this category from other sources, that the remote site is somehow munging things at their end? Or, is there some other nuance of dealing with 'new not syn' packets that we should be doing? The latter seems unlikely as I've already exceeded my quota for mistakes this year. :wink:
Any thoughts on this are appreciated!

Chuck Logan
06-05-2009
Lazydog

It could be the app is trying to start another stream but because it thinks they are already sync'ed they don't need to do this again. Maybe they do have some sort of malware that is trying to piggyback in. Without seeing the packets it all just a guessing game. You need to look at the packets to figure this one out.
06-05-2009
BNSC

Quote:

Originally Posted by Lazydog

You need to look at the packets to figure this one out.

Well, I let the Wireshark out of it's tank and let it nibble on a few packets when one of our clients 'phoned home'. I won't pretend to understand all I see in it's output, but in comparing the firewall log with the sniffer, I *might* see something pertinent. The firewall log showed that the dropped packet was headed for port 42129. Here's an abbreviated output of the first few frames captured:

Code:

Outbound 42129 > 80 [FIN, ACK] Outbound 42144 > 80 [SYN] Inbound 80 > 42129 [ACK] Inbound 80 > 42144 [SYN, ACK]

Frames 4-14 shows traffic to and from port 42144.

Frame 15 is:

Code:

Outbound 42129 > 80 [FIN, ACK]

This is followed by 3 more frames of chat on port 42144

Finally, frames 19-23 all show:

Code:

Outbound 42129 > 80 [FIN, ACK]

The final frame is as above but with port 42144 [FIN, ACK]

As I was typing this long-winded message we captured another session and it appears to be almost identical to what I've posted, only the high-end port numbers changed. I think I feel confident to say that if the problem is in fact originating at our end, it's a function of the client software they provided, and not our firewall being paranoid. If anything above seems pertinent, let me know.
I appreciate the help!

Chuck
06-06-2009
Lazydog

In your captures you should see what frames the FIN, ACK and SYN, ACK are replying to.

Looking at what you posted it looks like 42129 is sending the FIN, ACK then deciding it doesn't want to finish so it sends a SYN packet.

Looks like 80 is ACK the FIN, ACK of 42129 and then SYN, ACK the SYN packet from 42129.

I have port 80 traffic dropped on my system from time to time and I do not make a big deal out of it as if the connection is needed it will start a new one. But it sounds like the software should be looked at closer to understand why it does this so much.
06-06-2009
BNSC

Quote:

Originally Posted by Lazydog

In your captures you should see what frames the FIN, ACK and SYN, ACK are replying to.

Thanks, Robert. Looking at the captures and the chronological time stamps, the very first packet sent from the client to start the conversation is the FIN ACK. There is no SYN ever sent for that first port that I can see. Oddly this is the case as well in transactions that have no firewall related issues. However, there are 5 possible scenarios that can happen when the client calls in. I suspect that one or two of those situations is what is causing the bad packets while the others slide on by. At this point I hereby deem it a "Monday problem", maybe if I apply enough barley pop over the weekend it will have corrected itself by then. :D
At any rate, with help of your sanity checks, I'm now confident that there isn't much more that can be done from a sysadmin point. I truly appreciate your help!

Best regards,
Chuck Logan