+ Reply to Thread
Results 1 to 8 of 8
  1. Netlurker cisco_trooper's Avatar
    Join Date
    Aug 2007
    Posts
    1,420

    Certifications
    CCNP Security, ASA Specialist, Firewall Security Specialist, IOS Security Specialist, IPS Specialist, VPN Security Specialist
    #1

    Default ASA - Land Attack

    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.
    Reply With Quote Quote  

  2. SS -->
  3. SupremeNetworkOverlord Moderator Ahriakin's Avatar
    Join Date
    Oct 2005
    Location
    ::1/128
    Posts
    1,798

    Certifications
    CCIE #23276-Sec, JNCIE-Sec #105, TCSE #2343,MCSE 2003-Sec,LPIC-1
    #2
    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.
    Reply With Quote Quote  

  4. Netlurker cisco_trooper's Avatar
    Join Date
    Aug 2007
    Posts
    1,420

    Certifications
    CCNP Security, ASA Specialist, Firewall Security Specialist, IOS Security Specialist, IPS Specialist, VPN Security Specialist
    #3
    Quote Originally Posted by Ahriakin View Post
    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.
    Reply With Quote Quote  

  5. Netlurker cisco_trooper's Avatar
    Join Date
    Aug 2007
    Posts
    1,420

    Certifications
    CCNP Security, ASA Specialist, Firewall Security Specialist, IOS Security Specialist, IPS Specialist, VPN Security Specialist
    #4
    Border Router
    Code:
     
    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
    Code:
     
    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.
    Reply With Quote Quote  

  6. Netlurker cisco_trooper's Avatar
    Join Date
    Aug 2007
    Posts
    1,420

    Certifications
    CCNP Security, ASA Specialist, Firewall Security Specialist, IOS Security Specialist, IPS Specialist, VPN Security Specialist
    #5
    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?
    Reply With Quote Quote  

  7. Senior Member mikearama's Avatar
    Join Date
    May 2007
    Location
    Oshawa, Ontario
    Posts
    757

    Certifications
    CCNP, CCSP, CISSP, MCSE
    #6
    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
    Reply With Quote Quote  

  8. Netlurker cisco_trooper's Avatar
    Join Date
    Aug 2007
    Posts
    1,420

    Certifications
    CCNP Security, ASA Specialist, Firewall Security Specialist, IOS Security Specialist, IPS Specialist, VPN Security Specialist
    #7
    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.
    Reply With Quote Quote  

  9. SupremeNetworkOverlord Moderator Ahriakin's Avatar
    Join Date
    Oct 2005
    Location
    ::1/128
    Posts
    1,798

    Certifications
    CCIE #23276-Sec, JNCIE-Sec #105, TCSE #2343,MCSE 2003-Sec,LPIC-1
    #8
    Do you have any lab or redundant devices that might be using the same IP scheme (maybe a server with Dynamips)?
    Reply With Quote Quote  

+ Reply to Thread

Social Networking & Bookmarks