Strange RST,ACK packet from my Host

Strange RST,ACK packet from my Host

[lst_hoe01]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

Hello

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 (217.219.215.10) 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

Thanxs for any help

Andreas




[-- Attachment #2: test.log --]
[-- Type: application/octet-stream, Size: 1414 bytes --]

Re: Strange RST,ACK packet from my Host

[Jason Opperisano]

On Thu, 2004-12-23 at 03:07, lst_hoe01@kwsoft.de wrote:
> Hello
> 
> 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 (217.219.215.10) 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
SMTP protocol):

  POST / HTTP/1.0

which is not an SMTP command.

the remote machine then sends:

  RSET

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:

  250 OK

response to an RSET before continuing.  the remote machine in your
capture can't be bothered with such trivial things, and sends message
data:

  man eugene mookie
  abcdef

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:

  FIN,ACK

and your machine sends:

  ACK

which puts this connection (with respect to your firewall) into state
"CLOSE-WAIT."

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.

-j

--
"Kids, you tried your best and you failed miserably. The lesson is,
 never try."
	--The Simpsons

Re: Strange RST,ACK packet from my Host

[lst_hoe01]

Zitat von Jason Opperisano <opie@817west.com>:

> 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
> SMTP protocol):
>
>   POST / HTTP/1.0
>
> which is not an SMTP command.

Yes, i know this is more a open proxy than a mailserver.

> the remote machine then sends:
>
>   RSET
>
> 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:
>
>   250 OK
>
> response to an RSET before continuing.  the remote machine in your
> capture can't be bothered with such trivial things, and sends message
> data:
>
>   man eugene mookie
>   abcdef
>
> 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:
>
>   FIN,ACK
>
> and your machine sends:
>
>   ACK
>
> which puts this connection (with respect to your firewall) into state
> "CLOSE-WAIT."

Until this point its a normal crappy spam-send ...

>
> 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.

The mixup in the SMTP protocol could be by ESMTP pipelining ...
I'm pretty sure postfix does it right ;-)

> 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.

That was my idea at first. What really stumble me is the source port from my
machine which is totally unrelated to the rest of the communication.

>
> 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.

Spam anyway of course but as said only the last packet is dropped by the
firewall and i want to know why it is created with this strange source port.
For my understandig it should origin from port 25 or have i missed something???


Regards & Thanxs

Andreas