Strange RST,ACK packet from my Host
opie at 817west.com
Thu Dec 23 17:02:01 CET 2004
On Thu, 2004-12-23 at 03:07, lst_hoe01 at kwsoft.de wrote:
> we have a mailserver protected itself by iptables and a firewall (iptables) in
> front of it. The firewall sometimes log RST,ACK packets from our mailserver as
> not permitted so i have done a tcpdump trace for one source IP for which this
> is happening (attached to the mail).
> This trace shows that after the last packet from the remote (18.104.22.168) our
> mailserver respond with a RST,ACK packet from a random high port which is
> dropped from the firewall because it does not match any connection??
> Can anyone explain why the mailserver send this strange packet?
> OS is Linux Kernel 2.4.21
> Iptables v1.2.8
the RST,ACK from your mail server is not the strangest packet in this
capture by a long shot.
after the three-way handshake--the remote machine sends this (before it
ever receives the 220 banner from your mail server, already breaking the
POST / HTTP/1.0
which is not an SMTP command.
the remote machine then sends:
which is a request to abort the current "mail transfer" and start
fresh. i'm pretty sure the RFC's require the remote side to wait for a:
response to an RSET before continuing. the remote machine in your
capture can't be bothered with such trivial things, and sends message
man eugene mookie
which does look pretty important, especially considering we have no MAIL
FROM or RCPT TO at this point.
after a couple of ACK's, the remote side sends:
and your machine sends:
which puts this connection (with respect to your firewall) into state
your mail server then sends an SMTP error:
502 Error: Command not implemented
which is probably in response to the POST command at the beginning, or
possibly the 'man eugene mookie' command.
to which the remote machine sends a RST packet, as it seems to have
moved on with its life at this point.
your firewall sees the client->server RST packet and puts the connection
in CLOSE state.
and finally, your mail server sends a RST,ACK to acknowledge the RST;
which arrives 20 seconds after the connection went into CLOSE-WAIT, and
10 seconds after the RST put the connection into CLOSE.
my guess is that the RST,ACK is being sent after the firewall had
removed the connection from conntrack. i *believe* the default timeout
for the TCP CLOSE state is 10 seconds; which would make sense.
oh--and i don't know if you've picked up on this or not--but the remote
machine in this communication never had any honorable intentions with
this communication, and shouldn't concern you.
"Kids, you tried your best and you failed miserably. The lesson is,
More information about the netfilter