ASA - Land Attack
cisco_trooper
Member Posts: 1,441 ■■■■□□□□□□
I'm getting quite a few of these log messages on my ASA.
2|Mar 12 2009 11:13:37|106017: Deny IP due to Land Attack from * to *
I have ACLs on my border routers to deny this traffic from the Outside. I have set up a capture port on my Core switch and applied it to all the VLANs to try to capture this traffic, but the capture isn't catching any traffic. The capture DOES work because I tested it on my own IP. What am I missing here? Surely if this is originating internally I should be able to capture it somehow. I'm looking for ideas on how to determine where the attack is originating.
2|Mar 12 2009 11:13:37|106017: Deny IP due to Land Attack from * to *
I have ACLs on my border routers to deny this traffic from the Outside. I have set up a capture port on my Core switch and applied it to all the VLANs to try to capture this traffic, but the capture isn't catching any traffic. The capture DOES work because I tested it on my own IP. What am I missing here? Surely if this is originating internally I should be able to capture it somehow. I'm looking for ideas on how to determine where the attack is originating.
Comments
-
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Do a capture on the ASA itself for type asp-drop (you may be able to refine it with a specific type with a little digging but you can always use 'all', sorry long day so you'll need to do any refining on your own
). You can then download and import the output into wireshark. ASP-DROP allows you to capture anything the ASA is dropping, whereas an ACL capture will only show you what is passing through. We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
cisco_trooper
Member Posts: 1,441 ■■■■□□□□□□
Do a capture on the ASA itself for type asp-drop (you may be able to refine it with a specific type with a little digging but you can always use 'all', sorry long day so you'll need to do any refining on your own ). You can then download and import the output into wireshark. ASP-DROP allows you to capture anything the ASA is dropping, whereas an ACL capture will only show you what is passing through.
Awesome, I'll try the ASP-DROP when I'm on site.
Regarding the ACL capture, I'm not sure how it would possible for this traffic not to pass through. I've applied the vlan access-map to EVERY internal and DMZ VLAN. If the traffic originates from inside then it HAS to pass through the filter I've set up (right?). And with an ACL on the border router denying the same traffic, NOT getting hit, I would have to assume it is originating internally. Someone please let me know if I'm missing something with this logic. I'll post the ACL and Capture configurations shortly, so you know what you're dealing with. -
cisco_trooper
Member Posts: 1,441 ■■■■□□□□□□
Border Router
interface FastEthernet0/0/0 description Outside ip address 3.3.3.1 255.255.255.252 ip access-group BOGON_IN in ip access-group BOGON_OUT out duplex full speed 100 no cdp enable ip access-list extended BOGON_IN deny ip host 2.2.2.2 any log-input BAD_GUY deny ip 1.1.1.0 0.0.0.255 1.1.1.0 0.0.0.255 log-input LAND_ATTACK deny ip 0.0.0.0 0.255.255.255 any log deny ip 1.0.0.0 0.255.255.255 any log deny ip 0.0.0.0 1.255.255.255 any log deny ip 2.0.0.0 0.255.255.255 any log deny ip 5.0.0.0 0.255.255.255 any log deny ip 10.0.0.0 0.255.255.255 any log deny ip 14.0.0.0 0.255.255.255 any log deny ip 23.0.0.0 0.255.255.255 any log deny ip 27.0.0.0 0.255.255.255 any log deny ip 31.0.0.0 0.255.255.255 any log deny ip 36.0.0.0 1.255.255.255 any log deny ip 39.0.0.0 0.255.255.255 any log deny ip 42.0.0.0 0.255.255.255 any log deny ip 46.0.0.0 0.255.255.255 any log deny ip 49.0.0.0 0.255.255.255 any log deny ip 50.0.0.0 0.255.255.255 any log deny ip 100.0.0.0 3.255.255.255 any log deny ip 104.0.0.0 3.255.255.255 any log deny ip 109.0.0.0 0.255.255.255 any log deny ip 127.0.0.0 0.255.255.255 any log deny ip 169.254.0.0 0.0.255.255 any log deny ip 172.16.0.0 0.15.255.255 any log deny ip 175.0.0.0 0.255.255.255 any log deny ip 176.0.0.0 7.255.255.255 any log deny ip 185.0.0.0 0.255.255.255 any log deny ip 192.0.2.0 0.0.0.255 any log deny ip 192.168.0.0 0.0.255.255 any log deny ip 198.18.0.0 0.1.255.255 any log deny ip 223.0.0.0 0.255.255.255 any log deny ip 224.0.0.0 31.255.255.255 any log permit ip any any
Core Switchvlan access-map MONITOR_LAND_ATTACK 10 match ip address LAND_ATTACK action forward capture vlan access-map MONITOR_LAND_ATTACK 20 match ip address ALL_TRAFFIC action forward vlan filter MONITOR_LAND_ATTACK vlan-list 1-999 ip access-list extended ALL_TRAFFIC permit ip any any ip access-list extended LAND_ATTACK permit ip 1.1.1.0 0.0.0.255 1.1.1.0 0.0.0.255 log-input permit udp 1.1.1.0 0.0.0.255 1.1.1.0 0.0.0.255 log-input permit tcp 1.1.1.0 0.0.0.255 1.1.1.0 0.0.0.255 log-input
One of two things should happen here. Either the border router ACL counters should be going wild, or I should be getting captures with my capture port....or I thought so anyway.
Anyway, I'll be trying your approach Ahriakin. Thanks. -
cisco_trooper
Member Posts: 1,441 ■■■■□□□□□□
Man, I wish I had waited to do that capture on the ASA. Now I can't go to bed.
Inside IP = 5.5.5.5
Outside IP = 1.1.1.1
ASA Config:
static (Inside,Outside) 1.1.1.1 5.5.5.5 netmask 255.255.255.255
Syslog Message:
2|Mar 12 2009 23:55:34|106017: Deny IP due to Land Attack from 1.1.1.1 to 1.1.1.1
2|Mar 12 2009 23:55:37|106017: Deny IP due to Land Attack from 1.1.1.1 to 1.1.1.1
2|Mar 12 2009 23:55:43|106017: Deny IP due to Land Attack from 1.1.1.1 to 1.1.1.1
2|Mar 12 2009 23:55:55|106017: Deny IP due to Land Attack from 1.1.1.1 to 1.1.1.1
2|Mar 12 2009 23:56:19|106017: Deny IP due to Land Attack from 1.1.1.1 to 1.1.1.1
2|Mar 12 2009 23:57:07|106017: Deny IP due to Land Attack from 1.1.1.1 to 1.1.1.1
ASP-DROP Capture:
67: 23:55:34.995035 5.5.5.5.60484 > 1.1.1.1.25: S 2891709491:2891709491(0) win 5840 <mss 1460,sackOK,timestamp 1064300474 0,nop,wscale 6>
69: 23:55:37.993753 5.5.5.5.60484 > 1.1.1.1.25: S 2891709491:2891709491(0) win 5840 <mss 1460,sackOK,timestamp 1064301224 0,nop,wscale 6>
70: 23:55:43.993753 5.5.5.5.60484 > 1.1.1.1.25: S 2891709491:2891709491(0) win 5840 <mss 1460,sackOK,timestamp 1064302724 0,nop,wscale 6>
72: 23:55:55.993738 5.5.5.5.60484 > 1.1.1.1.25: S 2891709491:2891709491(0) win 5840 <mss 1460,sackOK,timestamp 1064305724 0,nop,wscale 6>
75: 23:56:19.993738 5.5.5.5.60484 > 1.1.1.1.25: S 2891709491:2891709491(0) win 5840 <mss 1460,sackOK,timestamp 1064311724 0,nop,wscale 6>
76: 23:57:07.993707 5.5.5.5.60484 > 1.1.1.1.25: S 2891709491:2891709491(0) win 5840 <mss 1460,sackOK,timestamp 1064323724 0,nop,wscale 6>
As you see from the NAT rule 1.1.1.1 is the outside address for 5.5.5.5 on the inside. Looking at the ASP-DROP capture we see 5.5.5.5 sending traffic to 1.1.1.1, which is ITSELF!
My question now becomes this: If 5.5.5.5 sends traffic to 1.1.1.1 from the Inside, how does it get NAT'd such that the syslog shows a deny for 1.1.1.1 to 1.1.1.1? Do the NAT rules work in both directions? Is there something I need to do to prevent such an occurence?
Thinking out loud here....
Why would this box be sending traffic to itself like this? This is a damn near brand new device. Misconfiguration? Piece of crap? -
mikearama
Member Posts: 749
Only thing that makes sense to me is failover... have you enabled failover pairs with the ASA as its peer?
Do a sh failover, a sh failover group, and a sh failover state.
If failover is up and running, throw out a debug fover and see if failover hello's are being sent/received from this asa to this asa.
Who knows... also just thinking out loud.
MikeThere are only 10 kinds of people... those who understand binary, and those that don't.
CCIE Studies: Written passed: Jan 21/12 Lab Prep: Hours reading: 385. Hours labbing: 110
Taking a time-out to add the CCVP. Capitalizing on a current IPT pilot project. -
cisco_trooper
Member Posts: 1,441 ■■■■□□□□□□
This device is not in a failover pair yet.
I'm leaning toward a misconfiguration of the SMTP device/DNS records after sniffing some traffic. -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Do you have any lab or redundant devices that might be using the same IP scheme (maybe a server with Dynamips)?We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
