Land Attack or configuration failure?

Posted on July 8, 2022

0



As you know the Local Area Network Denial (LAND) attack is a type of Denial of Service (DOS) attack in which the attacker attacks the network by sending the same source and destination IPs and ports (like TCP SYN where the source IP and destination IP is from the destination device itself).

if you check the global counters in Palo Alto Firewall you will see sometimes a counter is keep increasing and it is called “flow_policy_nat_land”.

> show counter global filter severity drop delta yes

Global counters:
Elapsed time since last sampling: 2.6   seconds

name                                   value     rate severity  category  aspect    description
--------------------------------------------------------------------------------
flow_policy_deny                           2        0 drop      flow      session   Session setup: denied by policy
flow_policy_nat_land                       2        0 drop      flow      session   Session setup: source NAT IP allocation result in LAND attack
flow_tcp_non_syn_drop                      7        3 drop      flow      session   Packets dropped: non-SYN TCP without session match
flow_fwd_l3_mcast_drop                    14        6 drop      flow      forward   Packets dropped: no route for IP multicast
flow_host_service_unknown                  2        0 drop      flow      mgmt      Session discarded: unknown application to control plane
flow_fpga_ingress_exception_err           46       22 drop      flow      offload   Packets dropped: receive ingress exception error from offload processor
--------------------------------------------------------------------------------
Total counters shown: 6
--------------------------------------------------------------------------------

We have the delta value 2 in the output, so who the hell is this? Which IP does that?

To get the details you can not go to threat logs or traffic logs since it is dropped before it could be checked against existing sessions or against the rulebase. The only way to see who is it, is to enable logging only for that specific counter:

>  debug dataplane packet-diag clear filter-marked-session 
>  debug dataplane packet-diag clear log log 
dataplane debug logs cleared

>  debug dataplane packet-diag set log counter flow_policy_nat_land 
>  debug dataplane packet-diag set log on 
Packet log is enabled. WARNING: Enabling of debug commands could result in network outage. Not recommended if dataplane CPU is above 60%.

This is what we see for packet-diag, just to make sure we are filtering really only that one counter and we have no other filter:

>  debug dataplane packet-diag show setting 

--------------------------------------------------------------------------------
Packet diagnosis setting:
--------------------------------------------------------------------------------
Packet filter
  Enaaled:                   yes
  Match pre-parsed packet:   no
  Filter offload:            yes
--------------------------------------------------------------------------------
Logging
  Enabled:                   yes
  Log-throttle:              no
  Sync-log-by-ticks:         yes
  Features:
    flow    : basic
  Counters:
    flow_policy_nat_land           drop      Session setup: source NAT IP allocation result in LAND attack
  Timeout duration:          60 seconds
  Buffer threshold:          80%
  CPU threshold:             80%
--------------------------------------------------------------------------------
Packet capture
  Enabled:                   no
  Snaplen:                   0
  Username:
--------------------------------------------------------------------------------

After drinking a bit of your coffee and get back to the cli we can filter to that log entries:

>  show log system | match flow_policy_nat_land 
2022/07/07 16:59:13 info     general        general 0  counter flow_policy_nat_land=2967
2022/07/07 17:00:08 info     general        general 0  counter flow_policy_nat_land=2842
2022/07/07 17:00:08 info     general        general 0  counter flow_policy_nat_land=3164
2022/07/07 17:00:08 info     general        general 0  counter flow_policy_nat_land=4033
2022/07/07 17:00:51 info     general        general 0  counter flow_policy_nat_land=5768

Get the timestamp and filter for it again in another way (we need this since the system logs have line breaks.):

>  show log system start-time equal 2022/07/07@17:00:08 
Time                Severity Subtype Object EventID ID Description
===============================================================================
2022/07/07 17:00:08 info     general        general 0  counter flow_policy_nat_land=2842
Packet info: len 62 port 76 tag 3891 interface 161
IP:     192.168.1.125->66.24.164.78, protocol 17
        version 4, ihl 5, tos 0x00, len 44,
2022/07/07 17:00:08 info     general        general 0  counter flow_policy_nat_land=3164
Packet info: len 62 port 76 tag 3891 interface 161
IP:     192.168.1.125->66.24.164.78, protocol 17
        version 4, ihl 5, tos 0x00, len 44,
2022/07/07 17:00:08 info     general        general 0  counter flow_policy_nat_land=4033
Packet info: len 62 port 76 tag 3891 interface 161
IP:     192.168.1.125->66.24.164.78, protocol 17
        version 4, ihl 5, tos 0x00, len 44,

There we go, the internal host 192.168.1.125 keep try to reach out to the public IP of the firewall on protocol 17 that is udp the interface id is the 161 and the vlan it comes in is 3891. The internal host when it goes to untrust zone will be source natted to the public IP of the firewall, so the packet from the host reaches after SNAT the LAND Attack format, where the source and the destination is the same and it will be silently dropped and no logs will be generated:

This can happen because of a wrong SNAT and DNAT configuration as well. See the following Palo Alto knowledge base article:

LAND Attacks When Configured Source and Destination NAT for Same Public IP Address