Prevent Denial of Service (DoS) attacks spreading default routes into your IS-IS interarea network

Prevent Denial of Service (DoS) attacks spreading default routes into your IS-IS interarea network

The obvious solution is to just shut that edge router down, or block the port(s) that the malicious traffic is coming in on.
However what if this edge subnet network is important and needs to continue to communicate with Subnet network B directly connected to it.
For example air traffic control communications, or a highly secure network of some sort (perhaps a jelly bean factory doing important backups, it doesn’t matter you get the point).
You shut down Subnet A network and you have effectively been beaten by the attackers (this might not have been there primary goal/attack vector, however its a nice secondary win for them).

So now you have a problem, you need to keep network A up and connected to B network, but want to limit the botnet flooding bad traffic throughout your interarea network.

This is where the “ignore-attached-bit” is-is command becomes very useful.

To prevent network A from being able to reach interarea destinations within your network, you can prevent the network A router from installing the default route without affecting the status of its IS-IS adjacencies.
The ignore-attached-bit statement is used to tell the Level-1 network B router to ignore the presence of the attached bit in Level 1 link-state PDUs, which blocks the installation of the IS-IS default route.

Lets configure this simple command:

Note:The ignore-attached-bit statement is disabled by default.

You can set it a variey of ways

set protocols isis ignore-attached-bit

or

set routing-instances JELLY-BEAN protocols isis ignore-attached-bit

or

set logical-systems JELLY protocols isis ignore-attached-bit

or

set logical-systems JELLY routing-instances JELLY protocols isis ignore-attached-bit

Your Level 2 IS-IS inner network is secure from injected default routes, while still allowing vital jelly bean services to connect to Network A 🙂

We could go a bit further, imagine setting up a script to automate this on edge devices, the triggers could be high amount of unusual traffic, cpu spiking, certain malicious subnets. Perhaps a future blog.

Leave a Reply

Your email address will not be published. Required fields are marked *