ASA - Land Attack

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

Comments

  • AhriakinAhriakin 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_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    Ahriakin wrote: »
    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_troopercisco_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 Switch
    vlan 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_troopercisco_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? icon_scratch.gif 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?
  • mikearamamikearama 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.
    Mike
    There 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_troopercisco_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.
  • AhriakinAhriakin 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?
Sign In or Register to comment.