Hey all,

I've recently run into a problem where a local ISP has begun running some IDS software and our company has been consistantly blacklisted because we were creating what appeared to be a FIN attack. I'm not exactly sure how this works, but it involves sending a packet with the FIN flag set that doesn't belong to any active session?

Anyway, after doing some research w/ ye ole trusty packet sniffer, I found the culprit to be Netscape? It seems that sometimes upon an initial page load, and always upon clicking a link on that first page page, that Netscape will set the FIN flag during the initial TCP handshake. This is on Windows, Mac, and Linux running 4.7x. It also appears to be affecting the NS email client.

Any security people finding this too? Did you "turn down" your security parameters, or just reconfigure your firewall to block the offending FIN packets? I'm not sure what the ISP is running to actually detect the packet. It sounds like they forward ALL their packet headers to a box that parses them for anything weird, possibly using snort. Due to "security problems" they wouldn't give me specifics.

I believe the server is running on a Sun box running Solaris 8 and some current version of Apache. I did notice that the server would send it's own FIN packets to the client after exactly 15 seconds of inactivity. The workstation responded w/ an ACK. But, it's like it just ignored the FIN request, and wanted to issue it's own. The server thinks it's already closed and records this. Too instances and we get nailed.

I did some search and found references to Netscapes mishandling of TCP sockets that date back to 1998, still in version 4.

Any ideas?

Thanks,
Jon

No I haven't got an idea, except you could enclose some tcpdump output to show us the warbled handshake and the references, because Nutscrape doesn't handle packets, it just requests the kernel for a connection to be set up/torn down.
And why not run Snort yourself and add some rules for the TCP handshaking? Shouldn't be that hard.

Yeah, I thought about running snort. Problem is I need an active approach for handling the problem -- that is I need to prevent the packets from going out before they actually go out. Snort probably would detect them, but I'd rather just keep them from ever leaving the NAT box. I figured snort was more of a analyzer than blocker.

The box I'm on has 2.2 and ipchains. It doesn't really have this ability but I guess iptables does... so...might be upgrading

As for the tcpdump, I guess I could... it'll be a little long ... I'll post it when I get to work.

Thanks,
Jon