Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • That's generally caused by a dumb firewall. Those logs don't show what TCP flags are set, but I'd bet they're not SYN (unless they're SYN+ACK, that is). I've seen this before in e-mails from users saying our DNS servers are attacking them, when it's really just the response packets to DNS requests they're sending out. This could be the same kind of thing - your firewall isn't keeping track of your TCP sessions properly, so it doesn't realize these packets are part of a session you're starting intentional
    • by Matts (1087) on 2002.06.12 13:11 (#9503) Journal
      I'm using gShield [linuxmafia.org] with most of the default settings, though I have tweaked it a bit.

      Someone on IRC said it was a timing out connection trying to hold the connection open to me, when I'd already dropped the connection... Here's an actual full log entry in case it helps anyone:
      Jun 12 19:10:10 ted kernel: gShield (default drop) IN=eth0 OUT=
      MAC=00:00:c0:92:ac:f9:00:20:6f:07:b5:6d:08:00 SRC=64.157.4.88
      DST=217.158.50.178 LEN=53 TOS=0x00 PREC=0x00 TTL=51 ID=3178 DF
      PROTO=TCP SPT=25 DPT=60271 WINDOW=17520 RES=0x00 ACK PSH FIN URGP=0
      • Based on the ACK PSH FIN flags on that, I'm guessing that's the final packet of an SMTP transaction. I'm not familiar with gShield at all, and I'm no expert (though I've done plenty of TCP stream/firewall debugging of my own), but that's my diagnosis :)