April 5, 2007 at 6:17 pm #1245
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.
Apr 4 13:49:12 188.8.131.52 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 184.108.40.206 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 220.127.116.11 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 18.104.22.168 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
April 5, 2007 at 9:07 pm #12325NegritaParticipant
22.214.171.124 is an idle port scan zombie.
April 6, 2007 at 12:27 am #12326
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.
April 6, 2007 at 1:33 pm #12327CadillacGolferParticipant
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
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.
April 6, 2007 at 2:31 pm #12328
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.
- You must be logged in to reply to this topic.