David Hoffman wrote:
This one is really confusing me...
I am running IPTables to configure my firewall, telling it to ALLOW
incoming traffic on eth1 from anywhere to port 25. The way the
firewall is set up, it says to allow connections that are RELATED or
ESTABLISHED, before going the following rules. One of the following
rules says to allow connections that are NEW if they are destined for
port 25.
At the bottom of my firewall rules, I have an entry that rejects all
traffic that has failed to pass all other checks. Right before that
entry, I have an entry that logs the packet that was rejected.
What I am seeing is traffic that is coming in from a machine as a NEW
connection, and is being allowed in. During the SMTP transaction (and
this only happens sometimes - usually when Postfix has rejected the
connection for failing some sanity check) Postfix might reject a
connection, and then shortly after, I see a log entry from the
firewall for a connection from port 25, but it failed to pass the
previous checks, and so it rejects it.
My guess is that the state of the packet is not being considered as
RELATED, ESTABLISHED, or NEW... but from the packet, I'm not sure if
there is a way to determine which state the packet is in.
Is there a way to tell the reason for rejection or the state of a
packet from the log entry that IPTables generates? Here is an example
of a log entry that I saw. AFTER valid traffic accepted, an SMTP
session was setup, and postfix rejected the mail with an error code, I
saw this message in my log:
Apr 10 06:40:29 master kernel: IN=eth1
OUT=MAC=00:50:ba:49:d8:aa:00:20:78:db:4f:3f:08:00 SRC=220.117.112.56
DST=192.168.158.1 LEN=40 TOS=0x00 PREC=0x00 TTL=108 ID=54733 PROTO=TCP
SPT=3705 DPT=25 WINDOW=0 RES=0x00 RST URGP=0
Once you've eliminated RELATED, ESTABLISHED, and NEW, the only
remaining state is INVALID. I don't know why the connection
state would be considered INVALID, but that packet looks like a
tcp-reset packet (40 bytes, "RST" flag) that was received after
postfix closed, or tried to close, the connection on your machine.
To see what is actually happening in the handshake you need to
run 'ethereal' and look at the packets.
--
Bob Nichols rnichols42@xxxxxxxxxxx
