Does your monitoring system scream when routing changes?
Suppose you are an Internet provider or you have your own network with dynamic routing, then the actual subject ...
A reasonable question, why? There are many reasons to keep logs of changes, and the monitoring system should yell for the simple reason that no one is immune from error. About the error under the cat, but for now, if you know how routing works, carefully analyze and answer the question in the figure.
The correct answer to the question is through router 3.3.3.3, simply because the prefix through this router is longer. When deciding which of the two routes will win, the prefix is ​​always checked first. If there are two routes to the host with the same prefix, then the route with a higher priority routing protocol wins, if the routing protocols are the same, then the internal routing protocol metrics will be taken into account.
But we were a little distracted, in fact, I wanted to tell a long story, about 2006, about how I accidentally got the opportunity to intervene in the routing of my provider, and what can be done in such a case.
It all started with the fact that I had to configure IDS snort . It was necessary to catch packages on demark-e with the provider. Therefore, it was configured to mirror the port on the switch, which included the provider. The internal interface of the snort server was on the local network; the external interface smelled mirror traffic from demark. Naturally, in such cases, when setting up, tcpdump or something similar is always launched. When I began to analyze what I received tcpdump, an interesting thing came to light - the provider's router periodically sent EIGRP HELLO multicast packets to me.
')
At first I was interested in how this could happen. I didn’t work with EIGRP before, but I quickly found out that when EIGRP is configured by default, all interfaces are switched to active mode and the routers immediately start searching for routing neighbors using multicast. You can globally transfer all interfaces to passive mode and make only certain of them active. You can leave all interfaces active and transfer unnecessary (those that look at clients) to passive mode. The provider used the second approach. Most likely, someone from the network administrators of the provider was mistaken and did not put the interface that was looking at me into passive mode.
It became clear how this could happen. Suppose you are configuring, at this moment you are distracted by a 5 minute phone call, you return to work and you understand that everything has already been configured and everything works. Save the configuration, but forget that you did not put the interface into passive mode.
It turned out that I can configure EIGRP in myself and join the provider’s routing. Naturally, I was interested in how this can be used. The more I thought about it, the more interesting it became.
I must say that I had an excellent relationship with the provider. The employees of the provider have informed us that, in principle, they are not against the fact that we will try to hack them and will not complain. The main thing is not to break anything, and in case we find something, tell them. All people are all wrong. They are tested for penetration free of charge, and we have a cool testing ground.
Therefore, I called the provider, said that I had found something, that I would say the next day, but for now I’m experimenting. If they see what I'm doing, let them cover me. In fact, it was interesting to find out if my interference with the routing is detected or not. Not found. But let's see what can be done in this case.
This is trite. Having picked up EIGRP, I immediately picked up their routing table. Having it available, it is easy to find out which subnet is free, register it on your router and get a channel that is not limited by traffic or speed. I used it a little.
You can register on your router any of the subnets present in the routing table. If you break this subnet into several, with a longer prefix, then the traffic will go to you, and not to the client’s provider.
There may be many uses. For example, you can effectively hide the traces of their illegal activities. To test the concept, I really captured the IP addresses of dialup clients. They do not mind if anything, they can reconnect and get a different IP.
Another example is to grab the provider's DNS server IP address for the time being and replace the DNS server server with its own. In this case, you can even (oh, horror !!!) steal passwords from classmates. Of course, it is difficult to make sure that you are not figured out, but now this is not the point.
And let's think about what symptoms of failure the client sees whose network is being captured. For verification, I deployed GNS3 . Here is the network.
But what happens when there is a route on R1 with a longer prefix to the subnet specified on its interface - 192.168.0.0/24, and in the case when it is not there.
The client simply does not see his default gateway at the third level.
Therefore, if you are very angry, then, for example, you can arrange a beautiful, arrogant and sophisticated DoS network administrators of the provider, depriving them of the ability to manage their own network.
Did you know that the “true administrators” of the provider like to sit in a white subnet, behind a reliable firewall, which they themselves have configured? At the same time, the ability to access network device management is only from this subnet. Of course, not always, but so often do.
To carry out an attack, you need to know in which subnet they are sitting. To do this, you can send a link to the network administrator of the provider to a cool image on your server. And when several smiles come back, see the IP address of the server logs. You can use other similar methods, social engineering has not been canceled.
Further split this subnet several subnets and register them on your router. Everything, ahtung is provided, the Internet has been lost for the network administrators of the provider. From the administrators of the provider it seems that their default gateway has dropped. That is, its MAC is visible, but it is not pinged and is not available on management ports (telnet, ssh, www). You can, perhaps, connect to the console. It is difficult to calculate even the fact that you are attacked, it is more like a hardware failure, or an operating system crash on the router. Cruel, but beautiful, right?
Monitoring changes in routing is not in vain considered to be the best practice. Of course, you should not give a loud notification when routes change in the network, but IMHO, you should set up a notification that a new router participating in dynamic routing has appeared on the network.
PS Take care ofyour routing, Senya.
A reasonable question, why? There are many reasons to keep logs of changes, and the monitoring system should yell for the simple reason that no one is immune from error. About the error under the cat, but for now, if you know how routing works, carefully analyze and answer the question in the figure.
The correct answer to the question is through router 3.3.3.3, simply because the prefix through this router is longer. When deciding which of the two routes will win, the prefix is ​​always checked first. If there are two routes to the host with the same prefix, then the route with a higher priority routing protocol wins, if the routing protocols are the same, then the internal routing protocol metrics will be taken into account.
But we were a little distracted, in fact, I wanted to tell a long story, about 2006, about how I accidentally got the opportunity to intervene in the routing of my provider, and what can be done in such a case.
How the error was revealed.
It all started with the fact that I had to configure IDS snort . It was necessary to catch packages on demark-e with the provider. Therefore, it was configured to mirror the port on the switch, which included the provider. The internal interface of the snort server was on the local network; the external interface smelled mirror traffic from demark. Naturally, in such cases, when setting up, tcpdump or something similar is always launched. When I began to analyze what I received tcpdump, an interesting thing came to light - the provider's router periodically sent EIGRP HELLO multicast packets to me.
')
How can you make a mistake.
At first I was interested in how this could happen. I didn’t work with EIGRP before, but I quickly found out that when EIGRP is configured by default, all interfaces are switched to active mode and the routers immediately start searching for routing neighbors using multicast. You can globally transfer all interfaces to passive mode and make only certain of them active. You can leave all interfaces active and transfer unnecessary (those that look at clients) to passive mode. The provider used the second approach. Most likely, someone from the network administrators of the provider was mistaken and did not put the interface that was looking at me into passive mode.
It became clear how this could happen. Suppose you are configuring, at this moment you are distracted by a 5 minute phone call, you return to work and you understand that everything has already been configured and everything works. Save the configuration, but forget that you did not put the interface into passive mode.
Options for operating errors.
It turned out that I can configure EIGRP in myself and join the provider’s routing. Naturally, I was interested in how this can be used. The more I thought about it, the more interesting it became.
I must say that I had an excellent relationship with the provider. The employees of the provider have informed us that, in principle, they are not against the fact that we will try to hack them and will not complain. The main thing is not to break anything, and in case we find something, tell them. All people are all wrong. They are tested for penetration free of charge, and we have a cool testing ground.
Therefore, I called the provider, said that I had found something, that I would say the next day, but for now I’m experimenting. If they see what I'm doing, let them cover me. In fact, it was interesting to find out if my interference with the routing is detected or not. Not found. But let's see what can be done in this case.
Steal traffic.
This is trite. Having picked up EIGRP, I immediately picked up their routing table. Having it available, it is easy to find out which subnet is free, register it on your router and get a channel that is not limited by traffic or speed. I used it a little.
Capture any of the used client subnets.
You can register on your router any of the subnets present in the routing table. If you break this subnet into several, with a longer prefix, then the traffic will go to you, and not to the client’s provider.
There may be many uses. For example, you can effectively hide the traces of their illegal activities. To test the concept, I really captured the IP addresses of dialup clients. They do not mind if anything, they can reconnect and get a different IP.
Another example is to grab the provider's DNS server IP address for the time being and replace the DNS server server with its own. In this case, you can even (oh, horror !!!) steal passwords from classmates. Of course, it is difficult to make sure that you are not figured out, but now this is not the point.
And let's think about what symptoms of failure the client sees whose network is being captured. For verification, I deployed GNS3 . Here is the network.
But what happens when there is a route on R1 with a longer prefix to the subnet specified on its interface - 192.168.0.0/24, and in the case when it is not there.
The client simply does not see his default gateway at the third level.
Therefore, if you are very angry, then, for example, you can arrange a beautiful, arrogant and sophisticated DoS network administrators of the provider, depriving them of the ability to manage their own network.
Did you know that the “true administrators” of the provider like to sit in a white subnet, behind a reliable firewall, which they themselves have configured? At the same time, the ability to access network device management is only from this subnet. Of course, not always, but so often do.
To carry out an attack, you need to know in which subnet they are sitting. To do this, you can send a link to the network administrator of the provider to a cool image on your server. And when several smiles come back, see the IP address of the server logs. You can use other similar methods, social engineering has not been canceled.
Further split this subnet several subnets and register them on your router. Everything, ahtung is provided, the Internet has been lost for the network administrators of the provider. From the administrators of the provider it seems that their default gateway has dropped. That is, its MAC is visible, but it is not pinged and is not available on management ports (telnet, ssh, www). You can, perhaps, connect to the console. It is difficult to calculate even the fact that you are attacked, it is more like a hardware failure, or an operating system crash on the router. Cruel, but beautiful, right?
Conclusion
Monitoring changes in routing is not in vain considered to be the best practice. Of course, you should not give a loud notification when routes change in the network, but IMHO, you should set up a notification that a new router participating in dynamic routing has appeared on the network.
PS Take care of
Source: https://habr.com/ru/post/135615/
All Articles