.

Firewall denying syn/ack inbound.

<<

dean

Post Thu Apr 05, 2007 1:17 pm

Firewall denying syn/ack inbound.

Thought this might be interesting.

Looking into a host on our network doing bad things (usual bot stuff) I noticed some unusual traffic on the firewall. The firewall is a Cisco FWSM for a 6500. We are not blocking outbound http/port 80 traffic at all and as this shows this traffic is a reply to a SYN packet that was sent.

I'm pretty sure as to what it is but was curious as to what others thought.

Any ideas?

-dean-

Apr  4 13:49:12 156.145.0.20 Apr 04 2007 13:49:12: %FWSM-6-106015: Deny TCP (no connection) from XXX.XXX.XXX.XXX/80 to XXX.XXX.XXX.XXX/21418 flags SYN ACK  on interface outside
Apr  4 13:49:24 156.145.0.20 Apr 04 2007 13:49:24: %FWSM-6-106015: Deny TCP (no connection) from XXX.XXX.XXX.XXX/80 to XXX.XXX.XXX.XXX/21418 flags SYN ACK  on interface outside
Apr  4 13:49:48 156.145.0.20 Apr 04 2007 13:49:48: %FWSM-6-106015: Deny TCP (no connection) from XXX.XXX.XXX.XXX/80 to XXX.XXX.XXX.XXX/21418 flags SYN ACK  on interface outside
Apr  4 13:50:11 156.145.0.20 Apr 04 2007 13:50:11: %FWSM-6-106015: Deny TCP (no connection) from XXX.XXX.XXX.XXX/80 to XXX.XXX.XXX.XXX/21597 flags SYN ACK  on interface outside
<<

Negrita

User avatar

Sr. Member
Sr. Member

Posts: 299

Joined: Sat Sep 10, 2005 5:45 pm

Location: /dev/null

Post Thu Apr 05, 2007 4:07 pm

Re: Firewall denying syn/ack inbound.

156.145.0.20 is an idle port scan zombie.
CEH, CCSA NG/AI, NNCSS, MCP, MCSA 2003

There are 10 kinds of people, those that understand binary, and those that don't.
<<

dean

Post Thu Apr 05, 2007 7:27 pm

Re: Firewall denying syn/ack inbound.

No, that's the firewall interface.

Another possibility that I'm investigating is where additional TCP flags are set that cause packets to be dropped. The ECN bit (explicit congestion notification)can cause packets to be dropped. This happens because routers or software that cannot recognize the flags will drop the traffic rather than ignoring the bit and passing the traffic through. Cisco Pix will do this.

Using a tool like tcptraceroute, that uses TCP and not UDP packets, you can test this. The -E switch will allow you to send a packet with the ECN bit set.

-dean-
<<

CadillacGolfer

Newbie
Newbie

Posts: 36

Joined: Thu Dec 14, 2006 1:58 pm

Post Fri Apr 06, 2007 8:33 am

Re: Firewall denying syn/ack inbound.

yes, not an idle scan.  That IP is the FW.  Or at least there isn't enough info to determine if an internal host was trying to do a scan.  You'd expect to see the attacker sending SYn ACK directly to zombie in the last step of an idle scan to get the IP ID.  With all the IPs redacted, there is't enough info.  Good right up here on idle scans
http://insecure.org/nmap/idlescan.html


Could be a lot of things.  Could also be that a legitimate SYN was sent outbound, but the internet server had a long delay and the outbound entry was cleared from the state table.  Could be a bad guy doing packet crafting trying to get past sa simple packet filter.  Could also be a NAT issue.  However, I think you might be on the right track with the ECN. 
<<

dean

Post Fri Apr 06, 2007 9:31 am

Re: Firewall denying syn/ack inbound.

We looked at the same things you mention in your post, CadillacGolfer. We're not nat'ing anything here. Transparent setup on the firewall. The joy of having 4 class B's is that everyone gets a internet addressable IP. Don't ask.  :)

Looking at the conn table and xlate table there are entries with the correct flags. It seems that a function of Cisco firewalls is to drop packets that contain unexpected values (ECN). Annoying.

Half open/embryonic connection limit had not been exceeded either. Even so at that point the Pix would delay the connection by sending a copy of the original SYN to the destination host.

Cheers,
-dean-

Return to Incident Response

Who is online

Users browsing this forum: No registered users and 0 guests

.
Powered by phpBB® Forum Software © phpBB Group.
Designed by ST Software