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
itsecworks 
Posted on July 8, 2022
0