Unexpected RSTs?

Unexpected RSTs?

[Martijn Klingens]

Please consider the following piece of our firewall script's output:

----
* Setting up connection tracking for already-active traffic
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state RELATED -j ACCEPT
iptables -A FORWARD -m state --state RELATED -j ACCEPT
modprobe ip_conntrack_ftp

[ .. snip creation and activation of custom chains .. ]

* Setting up connection tracking for ACL lan
iptables -A acl_lan -p tcp --tcp-flags RST RST -j log_lan
iptables -A log_lan -p tcp --tcp-flags RST RST -j LOG \
        --log-level debug --log-prefix '* DROP: Unexpected RST * '
----

The last line intrigues me. We drop these packets since quite a while, but 
didn't log them until yesterday. It turns out that almost 15% of my firewall 
log now consists of packets qualifying as 'Unexpected RST' though.

But... isn't the conntrack code at the beginning supposed to take care of 
accepting RSTs if they are associated with an active connection? Isn't a 
packet with RST that passes through the RELATED/ESTABLISHED match a packet 
that is not associated with an active connection and should thus be dropped?

I'm a bit surprised to see this to say the least. It's not a subnet-wide 
portscan at least, the dropped packets definitely seem to indicate legitimate 
traffic.

Thanks in advance for any hints,
-- 
Martijn

Re: Unexpected RSTs?

[Antony Stone]

On Friday 11 October 2002 1:34 pm, Martijn Klingens wrote:

> Please consider the following piece of our firewall script's output:
>
> iptables -A acl_lan -p tcp --tcp-flags RST RST -j log_lan
> iptables -A log_lan -p tcp --tcp-flags RST RST -j LOG \
>         --log-level debug --log-prefix '* DROP: Unexpected RST * '
>
> The last line intrigues me. We drop these packets since quite a while, but
> didn't log them until yesterday. It turns out that almost 15% of my
> firewall log now consists of packets qualifying as 'Unexpected RST' though.

Depending on what else you're logging, 15% of your log entries could be a lot 
of packets, could be only a few....

> But... isn't the conntrack code at the beginning supposed to take care of
> accepting RSTs if they are associated with an active connection?

Yes.

> I'm a bit surprised to see this to say the least. It's not a subnet-wide
> portscan at least, the dropped packets definitely seem to indicate
> legitimate traffic.

I'd expect the reason might be a system sending two RST packets (I believe 
this is quite common, but I haven't done any specific network sniffing to 
check it out).   The first one takes down the connection so it is no longer 
ESTABLISHED, the second one gets logged because it doesn't correspond to an 
established connection...

Maybe you could try putting a LOG rule to catch *all* RSTs at the beginning 
of your rules (before even the ESTABLISHED, RELATED rule) and see if this 
shows they are coming along in pairs ?

Antony.

-- 

Most people have more than the average number of legs.

Re: Unexpected RSTs?

[Martijn Klingens]

On Friday 11 October 2002 15:03, Antony Stone wrote:
> Depending on what else you're logging, 15% of your log entries could be a
> lot of packets, could be only a few....

It's thousands of them ;-)

(And the timeframe was only a day or so...)

> I'd expect the reason might be a system sending two RST packets (I believe
> this is quite common, but I haven't done any specific network sniffing to
> check it out).   The first one takes down the connection so it is no longer
> ESTABLISHED, the second one gets logged because it doesn't correspond to an
> established connection...

Hmm, besides the obvious questions *why* the second RST is sent and why 
conntrack doesn't have provisions for ignoring subsequent RSTs for a short 
amount of time the reasoning itself makes sense.

> Maybe you could try putting a LOG rule to catch *all* RSTs at the beginning
> of your rules (before even the ESTABLISHED, RELATED rule) and see if this
> shows they are coming along in pairs ?

Good idea. I'm not going to modify the firewall so close before the weekend, 
but will do so next monday. Thanks for the tip and I'll let you know about 
the results!
-- 
Martijn

Send mail Secure(SSL): No, Socket Error

[Sundaram Ramasamy]

hi ,

My external users are getting following error, while sending E-mail.

Your server has unexpectedly terminated the connection. Possible causes for
this include server problems, network problems, or a long period of

inactivity. Subject 'Coming Late', Account: 'www.percipia.com', Server:
'www.percipia.com',

Protocol: SMTP, Port: 25, Secure(SSL): No, Socket Error: 10053, Error
Number: 0x800CCC0F



I am not allowing SSL port? Do I need to open the SSL port for this error?



Thanks

-SR

Re: Send mail Secure(SSL): No, Socket Error

[Antony Stone]

On Friday 11 October 2002 5:07 pm, Sundaram Ramasamy wrote:

> hi ,
>
> My external users are getting following error, while sending E-mail.
>
> Your server has unexpectedly terminated the connection. Possible causes for
> this include server problems, network problems, or a long period of
>
> inactivity. Subject 'Coming Late', Account: 'www.percipia.com', Server:
> 'www.percipia.com',
>
> Protocol: SMTP, Port: 25, Secure(SSL): No, Socket Error: 10053, Error
> Number: 0x800CCC0F
>
> I am not allowing SSL port? Do I need to open the SSL port for this error?

No, you don't need to allow SSL - that's why it says "Secure(SSL): No" - it 
is not using SSL.

The solution is to upgrade your mail client - getting them opff Outlook will 
solve an awful lot of other security problems as well :-)

If they don't want to run Kmail, Mutt, Mozilla etc, try them with something 
like Pegasus or Eudora...

Antony.

-- 

90% of network problems are routing problems.
9 of the remaining 10% are routing problems in the other direction.
The remaining 1% might be something else, but check the routing anyway.

Re: Unexpected RSTs?

[Martijn Klingens]

On Friday 11 October 2002 16:29, Martijn Klingens wrote:
> On Friday 11 October 2002 15:03, Antony Stone wrote:
> > Maybe you could try putting a LOG rule to catch *all* RSTs at the
> > beginning of your rules (before even the ESTABLISHED, RELATED rule) and
> > see if this shows they are coming along in pairs ?
>
> Good idea. I'm not going to modify the firewall so close before the
> weekend, but will do so next monday. Thanks for the tip and I'll let you
> know about the results!

Just did some small tests, and unfortunately this idea seems to be incorrect.

Each 'unexpected rst' has exactly *ONE* RST coming in, so it's not a duplicate 
entry being dropped, it's a unique entry.

Also, the IP addresses causing unexpected RSTs are sending accepted RSTs later 
on in the firewall log with a slightly higher port number, so it looks like 
the senders are legitimate and not malicious users.

Do you have any other ideas why the RSTs are not accepted by the conntrack 
code as 'related' ?

-- 
Martijn