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

use Perl Log In

Log In

[ Create a new account ]

Matts (1087)

Matts
  (email not shown publicly)

I work for MessageLabs [messagelabs.com] in Toronto, ON, Canada. I write spam filters, MTA software, high performance network software, string matching algorithms, and other cool stuff mostly in Perl and C.

Journal of Matts (1087)

Wednesday June 12, 2002
04:33 AM

Firewall logs

[ #5602 ]

Does anyone else get things like this in their linux firewall logs:

Jun 11 23:19:06 gShield (default drop)  TCP mc8-m8.law13.hotmail.com:25 ->
54544(54544)
Jun 11 23:59:27 gShield (default drop)  TCP mpsb-nat30.plala.or.jp:25 -> 54606(54606)

Looks like when I send email, the SMTP server is somehow trying to connect back to me on the same port I'm connecting out on (the high port).

I haven't been able to find out anything about this on Google.

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
    • 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=0x

      • 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 :)