Screen OS

Hello All,

Seeing countinous land attacks on ISG-2000.

2015-08-11 03:36:37 system alert 00010 Land attack! From x.x.x.x to
                                       x.x.x.x, proto 6 (zone Untrust,
                                       int aggregate1). Occurred 1 times.

The above Ip on which land attack is occuring is same source and same destination, and that particular ip is used in dip as well. All the land attacks that are occuring are for dip range that is defined on the ISG.

Land attack screening has been enabled on the untrust zone.

set zone "Untrust" screen land

Still seeing the events and that is filling up the event log. Counter for the interface is also ticking.

ISG02-> get counter screen interface agg1  | i land
Land attack protection                                   24184
ISG02-> get counter screen interface agg1  | i land
Land attack protection                                   24185
ISG02->

ISG02-> get counter statistics interface agg1 | i land

land attack      1827922 | in self          1164253 | no map                 0
ISG02-> get counter statistics interface agg1 | i land

land attack      1827923 | in self          1164254 | no map                 0
ISG02-> get counter statistics interface agg1 | i land

land attack      1827924 | in self          1164255 | no map                 0
ISG02->

Can someone assist how to deal with this.

Thanks!!

Block the attacks further upstream.  For example, on the upstream router, null route anything that has the same source and destination address.

Thanks for your revert but the problem is that its generating such alarms over the Ip which are defined on ISG in Dip pool.

If i put a route on internet route as null, it will make the authentic traffic to drop as well.

Please advice further

I know on some routers (Junos based I know for sure), you can create a firewall filter on the interface that states if the source is x.x.x.x and the destination is also x.x.x.x, discard.  From what I understand, Cisco routers also support this via an ACL.

I'm not sure I follow what the issue is here.

If the SSG is logging the Land attack then you are successfully dealing with the issue.  The attack is being blocked by the firewall.

Is the issue, the attack is so large it is creating a DOS of your device?

If so then blocking the sources upstream is the only other answer.

Is the issue you don't want so many logs?

Then there is not much that can be done.  This is an Alert level, so you could turn off Alert on "Internal" in reporting.  But this will remove lots of valuable logging.  And knowing that this attack is occuring is valuable as well.  We just don't have a lot of granular logging controls.

Thanks Steve for valuable advice!! But i am not able to figure it out here whether its a DOS attack or its an alert. But the thing is that i am countinously getting these logs.

2015-08-17 16:53:36 system alert 00010 Land attack! From x.x.x.75 to
                                       x.x.x.75, proto 6 (zone Untrust,
                                       int aggregate1). Occurred 1 times.
2015-08-17 16:53:31 system alert 00010 Land attack! From x.x.x.75 to
                                       x.x.x.75, proto 6 (zone Untrust,
                                       int aggregate1). Occurred 1 times.
2015-08-17 16:53:27 system alert 00010 Land attack! From x.x.x.75 to
                                       x.x.x.75, proto 6 (zone Untrust,
                                       int aggregate1). Occurred 1 times.
2015-08-17 16:52:21 system alert 00010 Land attack! From x.x.x.40 to
                                       x.x.x.40, proto 6 (zone Untrust,
                                       int aggregate1). Occurred 1 times.
2015-08-17 16:52:20 system alert 00010 Land attack! From x.x.x.31 to
                                       x.x.x.31, proto 6 (zone Untrust,
                                       int aggregate1). Occurred 1 times.
2015-08-17 16:52:15 system alert 00010 Land attack! From x.x.x.40 to
                                       x.x.x.40, proto 6 (zone Untrust,
                                       int aggregate1). Occurred 1 times.
2015-08-17 16:52:12 system alert 00010 Land attack! From x.x.x.40 to
                                       x.x.x.40, proto 6 (zone Untrust,
                                       int aggregate1). Occurred 1 times.
2015-08-17 16:52:12 system alert 00010 Land attack! From x.x.x.31 to
                                       x.x.x.31, proto 6 (zone Untrust,
                                       int aggregate1). Occurred 1 times.
2015-08-17 16:51:51 system alert 00010 Land attack! From x.x.x.40 to
                                       x.x.x.40, proto 6 (zone Untrust,
                                       int aggregate1). Occurred 1 times.
2015-08-17 16:51:45 system alert 00010 Land attack! From x.x.x.40 to
                                       x.x.x.40, proto 6 (zone Untrust,
                                       int aggregate1). Occurred 1 times.

Here x.x.x is ist 3 octets. All these ips are from the DIP pool which is created over the same Firewall.

Here is DIP created on FW, and all the logs that are generating over the firewall having the same source and destination.

set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 5 x.x.x.5 x.x.x.5
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 6 x.x.x.6 x.x.x.10
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 7 x.x.x.11 x.x.x.15
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 8 x.x.x.16 x.x.x.20
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 9 x.x.x.21 x.x.x.25
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 10 x.x.x.26 x.x.x.30
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 11 x.x.x.31 x.x.x.35
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 12 x.x.x.36 x.x.x.40
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 13 x.x.x.41 x.x.x.45
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 14 x.x.x.46 x.x.x.47
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 15 x.x.x.55 x.x.x.55
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 16 x.x.x.56 x.x.x.60
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 17 x.x.x.61 x.x.x.65
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 18 x.x.x.66 x.x.x.70
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 19 x.x.x.71 x.x.x.75
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 20 x.x.x.76 x.x.x.80
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 21 x.x.x.81 x.x.x.85
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 22 x.x.x.86 x.x.x.90
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 26 x.x.x.96 x.x.x.100
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 27 x.x.x.111 x.x.x.115
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 28 x.x.x.116 x.x.x.120
set interface aggregate1 ext ip x.x.x.1 255.255.255.0 dip 25 x.x.x.91 x.x.x.95

Can you please share your advice how to troubleshoot this. Thanks!!

Just want to add the debug captured for the land attack source and destination. In here its showing as if its dropped because of the policy but in log its land attack Please help in getting rid of this alarm

**st: <Untrust|aggregate1|Root|0> 4f9c118: 3a8:x.x.x.59/c1a4->x.x.x.59/4801,17,131
****** 6434527.0: <Untrust/aggregate1> packet received [131]******
  ipid = 936(03a8), @04f9c118
  packet passed sanity check.
  flow_decap_vector IPv4 process
  aggregate1:x.x.x.59/49572->x.x.x.59/18433,17<Root>
  no session found
  flow_first_inline_vector: in <aggregate1>, out <N/A>
  chose interface aggregate1 as incoming nat if.
  flow_first_inline_vector: in <aggregate1>, out <N/A>
  search route to (aggregate1, x.x.x.59->x.x.x.59) in vr trust-vr for vsd-0/flag-0/ifp-null
  [ Dest] 24.route x.x.x.59->y.y.y..2, to aggregate1
  routed (x_dst_ip x.x.x.59) from aggregate1 (aggregate1 in 0) to aggregate1
  policy search from zone 1-> zone 1
 policy_flow_search  policy search nat_crt from zone 1-> zone 1
  RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip x.x.x.59, port 18433, proto 17)
  No SW RPC rule match, search HW rule
swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0
  Searching global policy.
swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0
  packet dropped, deny by zone block
  packet dropped, null policy

There is nothing more you need to do about this particular situation.  The attack is being identified by your screen protections and even if they were not so identified you have a policy that would block the traffic as well.

The logs are frequent and annoying, but there is no operational problem which you need to address.

Thanks for your advice!!

But i have one doubt, i am getting all these land attacks from the ip which i have defined in my extended dip pool on firewall.

Source and destination ips are same and both are from the extended dip pool.

How the firewall is initiating the traffic from the Ips that are defined on it. Is that the issue with Extended DIP pool or its issue with my configuration.

The source and destination ip address are the same because that is the nature of how the Land Attack works.  The attacker is spoofing the source address to be the same as the destination as a part of the attack structure.

http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/denial-of-service-network-land-attack-understanding.html

Thanks Steve, but i am worried as the source and dst ips are both from my dip pool which is defined on my isg box.

Do not worry about the ip addresses source and destination being the same.

The definition of Land Attack is that the two ip addresses are the same.  If they were NOT the same this would NOT be a Land attack.

Having the two addresses the same is part of HOW the attacker is trying to disrupt your system.

On a side note, If you do not want to see the 'LAND attack' related logs, you can configure an exclude-list as below:

'set log exclude-id <id number> event-type 00010  <----- event-type 00010 corresponds to LAND Attack as seen in the logs.

Regards,

Rushi