pix how to NOT block the LAND ATTACK

[ROBERTO TACCON]

Hi to All,

how can I configure a pix Version 8.0(4) to NOT block the LAND ATTACK ?

pix# sh log | i 17.12.18.24

Oct 07 2010 15:47:31: %PIX-2-106017: Deny IP due to Land Attack from 17.12.18.24 to 17.12.18.24

Oct 07 2010 15:47:31: %PIX-6-302014: Teardown TCP connection 1264706965 for outside:17.12.18.24/80 to inside:10.12.40.114/59790 duration 0:00:00 bytes 0 looping-address

I've already disable the signature 1102

http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=1102&signatureSubId=0&softwareVersion=6.0&releaseVersion=S473

pix# sh run | i audit

ip audit signature 1102 disable

pix#

but the drop continue ....

pix# sh log | i 17.12.18.24

Oct 07 2010 15:50:22: %PIX-2-106017: Deny IP due to Land Attack from 17.12.18.24 to 17.12.18.24

Oct 07 2010 15:50:22: %PIX-6-302014: Teardown TCP connection 1264706965 for outside:17.12.18.24/80 to inside:10.12.40.114/59891 duration 0:00:00 bytes 0 looping-address

Thanks

Roberto Taccon

[mirober2]

Hi Roberto,

What are you trying to accomplish with this traffic? A packet in the network shouldn't have the same source and destination IP address.

-Mike

[ROBERTO TACCON]

Hi,

I think (as I have caputerd all the traffic inside and outside interfaces and I can't see any src-dst same IP) the problem is pix bug

BUT the questions are:

- how I can DISABLE on the pix the "Deny IP due to Land Attack" ?

- how can i capture ONLY the ASP DROP packets ?

Best Regards

Roberto Taccon

[mirober2 · Accepted solution]

Hi Roberto,

You can disable the syslog message (no logging message ), but you can't disable the actual action of dropping land attack packets.

To capture dropped packets, you can setup a capture with 'capture drop type asp-drop all' and then do a 'show capture drop' to see the packets.

-Mike

[ROBERTO TACCON]

Hello,

following the questions:

Q1) why you tell me "but you can't disable the actual action of dropping land attack packets" ?

On Cisco docs:

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/i3.html#wp1837699

Q2) May I ask you if the following is the correct command to DISABLE the LAN ATTACK DROP ?

ip audit signature 1102 disable

Q3) are there any BUG about the "static nat" and "land attack" ?

Best regards.

Roberto Taccon

[Panos Kampanakis]

Roberto,

Land attack is a L3 attack that the FW will not allow. It is not part of the IPS, it is part of the basic L3 firewall checks.

I hope it is clear. I don't understand why your would want to allow it.

PK

[ROBERTO TACCON]

Hello,

the 17.12.18.24 is a static nat configured on the firewall:

static (inside,outside) 17.12.18.24 10.217.40.114 netmask 255.255.255.255

access-list acl-out extended permit tcp any host 17.12.18.24 eq www

access-list acl-out extended permit tcp any host 17.12.18.24 eq https

If I try to connect to the PUBLIC IP web server 17.12.18.24 from the outside after 5 minutes of using it (it's a crm web server) the web server not respond and the firewall DENY the connection for the LAND ATTACK

If I try to connect to the PRIVATE IP web server 10.217.40.114 from (another PIX interface without the nat) the DMZ ALL is working perfectly !

I can't understand why the pix do the LAN attack DENY packet (maybe a bug on the version PIX Version 8.0(4) ): I've captured the packets from inside and outside but I can't see the LAN attack (source destination same ip packet private or public).

Now I try to capture the ASP DROP packets to see if the LAND attack packet is present.

Q.:

- it's possible to configure the PIX as indicated below:

with a static nat IP public IP public

route static the IP public to the private IP of the webserver

configure the webserver with the secondary IP public 17.12.18.24

!

interface Ethernet1.41

vlan 41

nameif inside

security-level 100

ip address 10.217.60.1 255.255.0.0

!

static (inside,outside) 17.12.18.24 17.12.18.24 netmask 255.255.255.255

access-list acl-out extended permit tcp any host 17.12.18.24 eq www

access-list acl-out extended permit tcp any host 17.12.18.24 eq https

route inside 17.12.18.24 255.255.255.255 10.217.40.114

!

[Panos Kampanakis]

The answer to your last questions is Yes, you can do it.

Though, I don't think you understand what the packets dropped due to the Land attack are. These are not legitimate packets. These are packets sourced from 17.12.18.24 and destined to 17.12.18.24. Same source and destination. They are not regular inbound connection packets. For the issue with the webserver that fails something else is probably happening.

PK

[ROBERTO TACCON]

It's was a problem with the webserver application: using the static public public resolved the LAND ATTACK (now the webserver admin need to resolve the application problem).

Bye.

Roberto Taccon