PIX logs source port 0, TCP SYN/RST scans?

[Curt.Wilson () siucu org]

Greetings.

A few questions based on some of our PIX firewall logs:

Detect 1: May 14 01:29:39 [192.149.115.1] %PIX-4-500004: Invalid transport
field for protocol=6, from 172.152.127.244/0 to 208.197.xxx.xx/1024

Invalid transport field. An AOL user attempts to connect from TCP port 0 to
TCP port 1024 on one of our IP addresses. Port 1024 has been used for
various types of trojan horse applications, but could this also be an
attack designed to look like response traffic to an ephemeral port? Usually
I see this type of traffic with a destination of port 0, which seems to be
used in operating system fingerprinting techniques and nmap protocol scans.
Perhaps attacker is trying a different type of fingerprint by setting
source port instead? I was unable to craft an nmap scan packet with a
source port of 0 using -g0  (something about source port must be non-zero)
but I was able to come close to matching the packet in Detect 1 except that
I could not set the destination port to anything other than 0 through a
nmap protocol scan.

My attempt at matching this traffic with nmap obtained the following
result:

May 15 11:22:31 [192.149.115.1] %PIX-4-500004: Invalid transport field for
protocol=6, from 199.120.223.5/0 to 208.197.xxx.xx./0

Our PIX firewall does not display the TCP flags and unless a NAT
translation or a conduit exists for the destination IP address, therefore
I'm unable to determine anything more about this packet (we will be
implementing snort or some other IDS in the near future to help with the
non-verbose FW logs). Note that there is no one at work at this time of
morning, but we do have automatic websense and anti-virus updates taking
place, as well as our home banking site taking hits.

Detect 2: May 14 19:35:15 [192.149.115.1] %PIX-4-500004: Invalid transport
field for protocol=6, from 144.232.173.2/0 to 208.133.197.4/3072

Source port 0 again, dest port 3072. I can't seem to recall what lives on
3072 and it's not in my lists?

Another TCP based question: We've recently switched our DSL line to a
different ISP (Cable & Wireless) and since then, I'm seeing some different
traffic patterns (not sure if this matters). Basically, someone will be
performing what appears to be a standard SYN scan on our external IP CIDR
block, which shows rejected SYN connection attempts as normal. However,
when the scan hits an active address that has a dynamic or static NAT
translation, an RST packet is denied instead of a SYN.

May 11 11:54:15 [192.149.115.1] %PIX-2-106001: Inbound TCP connection
denied from 38.247.106.173/56397 to 208.133.xxx.x/111 flags SYN  on
interface outside
May 11 11:54:15 [192.149.115.1] %PIX-6-106015: Deny TCP (no connection)
from 38.247.106.173/56395 to 192.168.xxx.x/111 flags RST  on interface
outside

In this standard TCP 111 SYN scan, you can see this action. The SYN is
denied on a global address; the RST is denied on an internal address. Most
of the scans coming through do not demonstrate this behavior, and they hit
the same addresses. What makes this particular scan (and a few others like
it) different? Did attacker perhaps use a SYN and RST packet together that
the PIX did not log since it perhaps filtered on the SYN flag first and
foremost?

Thanks for any assistance in helping to understand these logs. Soon, we
will have a real IDS in place and won't have to make guesses based on
incomplete information.

Curt Wilson




_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards