Re: SOHO firewall dropping incoming 443 connections - incorrect state

From: ITguy_uk (itguy_uk@hotmail.com)
Date: 03/12/03 

From: itguy_uk@hotmail.com (ITguy_uk)
Date: 12 Mar 2003 03:37:55 -0800

"uweiro" <uweiro@lycos.com> wrote in message news:<pan.2003.03.12.16.08.47.247876@lycos.com>...
> Strange, I take it this sample snip of your logs is from a single session?
> ie. One source (remote) IP, to one (local) Destination IP?
>
> I'm not sure how familiar you are with the TCP handshake, but what I don't
> understand is why the remote PC is trying more than one connection in such
> a short space of time? I take it that these logs are only from one remote
> PC, considering the closeness of the ephemeral source ports. This would
> explain why your firewall is complaining about so many SYN requests from
> the one IP address!
>
> It seems to connect happily, then try again!
>
> Perhaps this is a HTTPS function that is beyond me...
>
> I'm sorry I can't be of more help, and will keep an eye on this thread,
> but to me some very strange things seem to be happening,
> if you take a close look at the time and Port#'s of these logs.
>
>
> :?

Thanks for the assistance, I know the basics of the TCP handshake but
probably need to refresh my memory of the SYN,ACK message sequence and
this did not occur to me as being part of the issue. I did not notice
that althought the IP address of the client was changing the ephemeral
ports were gradually increasing. You are correct in assuming that the
client host connecting to the firewall was a single host. Apologies
for changing the IP's to meaningless values. Below is a list of the
logs with the values changed to meaningful value. To clarify the
external host 207.46.134.190 (actually Microsofts IP but used as an
example) connects to the firewall which should NAT it through to an
internal server containing the Oulook Web Access component. These
external hosts are usually mobile users on dialups, I have however
experienced this on issue on my ADSL line from home. I intend to try
to reproduce this from my home account and note the exact time and
then look at the firewall logs to see what is happening. I will also
use a sniffer (ethereal) to analyse the traffic between the firewall
and my host PC.

I know you mentioned the number of SYN messages being sent to the
firewall could be an issue. Was you suggesting that the type of
traffic the Outlook Web Access is creating looks like a SYN flood
attack? I am going to test this but I think it could be possible that
because of the nature of HTTPS requests it uses a different ephemeral
port with each HTTPS request which is normal for Outlook Web Access
but to the firewall it looks like a SYN flood attack and so gets
blocked. This only occurs when the user is generating a lot of HTTPS
requests i.e. when changing screens a lot.

I will post on here the results.

Thanks again
Martin

2003-02-19 14:56:38 Local0.Info 192.168.1.1 IP: Packet allowed from
167.247.31.44 port 35332 to 207.46.134.190 port 443 (TCP)(allow by
HTTPS)
2003-02-19 14:56:39 Local0.Info 192.168.1.1 IP: Packet allowed from
167.247.31.44 port 35334 to 207.46.134.190 port 443 (TCP)(allow by
HTTPS)
2003-02-19 14:56:39 Local0.Warning 192.168.1.1 IP: Packet discarded
from 167.247.31.44 port 35229 to 207.46.134.190 port 443
(TCP)(incorrect state)
2003-02-19 14:56:39 Local0.Info 192.168.1.1 IP: Packet allowed from
167.247.31.44 port 35338 to 207.46.134.190 port 443 (TCP)(allow by
HTTPS)
2003-02-19 14:56:39 Local0.Info 192.168.1.1 IP: Packet allowed from
167.247.31.44 port 35341 to 207.46.134.190 port 443 (TCP)(allow by
HTTPS)
2003-02-19 14:56:39 Local0.Info 192.168.1.1 IP: Packet allowed from
167.247.31.44 port 35347 to 207.46.134.190 port 443 (TCP)(allow by
HTTPS)
2003-02-19 14:56:39 Local0.Info 192.168.1.1 IP: Packet allowed from
167.247.31.44 port 35349 to 213.2.66.74 port 443 (TCP)(allow by HTTPS)
2003-02-19 14:56:39 Local0.Info 192.168.1.1 IP: Packet allowed from
167.247.31.44 port 35350 to 207.46.134.190 port 443 (TCP)(allow by
HTTPS)
2003-02-19 14:56:39 Local0.Info 192.168.1.1 IP: Packet allowed from
167.247.31.44 port 35353 to 207.46.134.190 port 443 (TCP)(allow by
HTTPS)
2003-02-19 14:56:40 Local0.Warning 192.168.1.1 IP: Packet discarded
from 167.247.31.44 port 35255 to 207.46.134.190 port 443
(TCP)(incorrect state)
2003-02-19 14:56:40 Local0.Warning 192.168.1.1 IP: Packet discarded
from 167.247.31.45 port 22891 to 213.2.66.74 port 443 (TCP)(incorrect
state)
2003-02-19 14:56:40 Local0.Info 192.168.1.1 IP: Packet allowed from
167.247.31.44 port 35354 to 207.46.134.190 port 443 (TCP)(allow by
HTTPS)
2003-02-19 14:56:40 Local0.Info 192.168.1.1 IP: Packet allowed from
167.247.31.44 port 35357 to 207.46.134.190 port 443 (TCP)(allow by
HTTPS)
2003-02-19 14:56:40 Local0.Info 192.168.1.1 IP: Packet allowed from
167.247.31.44 port 35358 to 207.46.134.190 port 443 (TCP)(allow by
HTTPS)
2003-02-19 14:56:41 Local0.Warning 192.168.1.1 IP: Packet discarded
from 167.247.31.44 port 35259 to 207.46.134.190 port 443
(TCP)(incorrect state)
2003-02-19 14:56:41 Local0.Warning 192.168.1.1 IP: Packet discarded
from 167.247.31.44 port 35268 to 207.46.134.190 port 443
(TCP)(incorrect state)
2003-02-19 14:56:41 Local0.Warning 192.168.1.1 IP: Packet discarded
from 167.247.31.44 port 35271 to 207.46.134.190 port 443
(TCP)(incorrect state)
2003-02-19 14:56:41 Local0.Warning 192.168.1.1 IP: Packet discarded
from 167.247.31.44 port 35278 to 207.46.134.190 port 443
(TCP)(incorrect state)
2003-02-19 14:56:41 Local0.Warning 192.168.1.1 IP: Packet discarded
from 167.247.31.44 port 35274 to 207.46.134.190 port 443
(TCP)(incorrect state)
2003-02-19 14:56:42 Local0.Warning 192.168.1.1 IP: Packet discarded
from 167.247.31.44 port 35289 to 207.46.134.190 port 443
(TCP)(incorrect state)
2003-02-19 14:56:42 Local0.Warning 192.168.1.1 IP: Packet discarded
from 167.247.31.44 port 35283 to 207.46.134.190 port 443
(TCP)(incorrect state)
2003-02-19 14:56:42 Local0.Warning 192.168.1.1 IP: Packet discarded
from 167.247.31.44 port 35296 to 207.46.134.190 port 443
(TCP)(incorrect state)
2003-02-19 14:56:42 Local0.Warning 192.168.1.1 IP: Packet discarded
from 167.247.31.44 port 35301 to 207.46.134.190 port 443
(TCP)(incorrect state)
2003-02-19 14:56:42 Local0.Warning 192.168.1.1 IP: Packet discarded
from 167.247.31.44 port 35305 to 207.46.134.190 port 443
(TCP)(incorrect state)
2003-02-19 14:56:43 Local0.Warning 192.168.1.1 IP: Packet discarded
from 167.247.31.44 port 35311 to 207.46.134.190 port 443
(TCP)(incorrect state)

Relevant Pages

  • Re[2]: Spoofed RFC1918 Network Source Addresses...
    ... Just for clarification, the host: ... exists outside the firewall and the 10.x.x.x network addresses exist ... which given my theory (of return packets) does not make much ... RF> Logs would be useful, ...
    (Incidents)
  • [fw-wiz] RE: IDS (was: FW appliance comparison)
    ... IDS help detect unexpected changes. ... >> unexpected host is a good event to trigger IDS events. ... >> Even when your firewall blocks this traffic, ... >> analysis of firewall logs and DHCP logs should ...
    (Firewall-Wizards)
  • Re: Strange WAN Activity
    ... > firewall logs for a possible TCP FIN scan that keeps ... > company's intranet server IP and its port 80 across our ... > My firewall is a Sonicwall Pro 200 and I'm running W2K ... It's difficult to be sure without inspecting the web server for signs of ...
    (microsoft.public.win2000.security)
  • Re: Winvnc hack! [25 KB]
    ... came in from a service such as IIS that logs IP address. ... Check your IIS ... Some firewall software such as ... You can also use the NETSTAT -A command that comes with Windows to look at ...
    (microsoft.public.win2000.security)
  • RE: [fw-wiz] Log checking?
    ... tend to evaluate where and what logging is important in a different light. ... I've been happy to analyze a year's worth of firewall denied logs, ... have denied firewall traffic logs or denied logs with any relevant data. ...
    (Firewall-Wizards)