Image
 
linkedin_logo.png rss_logo.jpg
twitter_logo.png youtube_logo.jpg
Latest Additions
 
EH-Net Login
Welcome Guest.






Lost Password?
No account yet? Register
Who's Online
We have 34 guests online
 
Advertisement

You are here: Home arrow Ethical Hacking Discussions and Related Certificationsarrow Incident Responsearrow Firewall denying syn/ack inbound.
EH-Net
May 25, 2013, 08:48:47 PM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Go back to The Ethical Hacker Network Online Magazine Home Page
 
   Home   Help Calendar Login Register  
Pages: [1]   Go Down
  Print  
Author Topic: Firewall denying syn/ack inbound.  (Read 6255 times)
0 Members and 1 Guest are viewing this topic.
dean
Guest
« on: April 05, 2007, 01:17:39 PM »

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
Logged
Negrita
Sr. Member
****
Offline Offline

Posts: 299



View Profile
« Reply #1 on: April 05, 2007, 04:07:50 PM »

156.145.0.20 is an idle port scan zombie.
Logged

CEH, CCSA NG/AI, NNCSS, MCP, MCSA 2003

There are 10 kinds of people, those that understand binary, and those that don't.
dean
Guest
« Reply #2 on: April 05, 2007, 07:27:03 PM »

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-
Logged
CadillacGolfer
Newbie
*
Offline Offline

Posts: 36


View Profile
« Reply #3 on: April 06, 2007, 08:33:20 AM »

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. 
Logged
dean
Guest
« Reply #4 on: April 06, 2007, 09:31:21 AM »

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

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-
Logged
Pages: [1]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines
Joomla Bridge by JoomlaHacks.com
Valid XHTML 1.0! Valid CSS!
Page created in 0.06 seconds with 22 queries.
 
Exclusive Deal

sansfire13_245x90_cw90.jpg
SANSFIRE 2013
June 15 - 22

5% Off w/ Code: EHN_5

SANS Deals 4 EH-Netters
5% OFF Any SANS Course in Any Format!
Coupon Code: EHN_5 Including SANS Rocky Mountain 2013 & SANS Boston 2013
Polls
Compared to this year, 2013 will be:
 
Recent Forum Topics
EH-Net News Feeds
Latest Additions
 
         
Advertisement

© 2013 The Ethical Hacker Network
Joomla! is Free Software released under the GNU/GPL License.