First, I think it is best for us to understand what is external BGP and then dive into how it is insecure and how it can lead to massive problems. Now there are two parties, internal and external routing protocols. An example of an internal routing protocol would be EIGRP (Enhanced Interior Gateway Routing Protocol) or OSPF (Open Shortest Path First), as these routes would be advertised internally or within a given network, but never to the internet. Therefore, external routing protocols are the opposite, they are not to be used within the network, but instead to connect networks together*. This is where BGP comes into play, also known as Border Gateway Protocol, it is the routing protocol of the internet. In simple terms, what we call the internet is the just the massive connection of autonomous systems or AS, which is just the assignment of a publicly known number used to identify a given network or set of IPs. Currently there is an estimated ~84,000 allocated autonomous system networks. BGP also differs from internal routing protocols in that it does not broadcast the entire routing table, instead at boot a nearby peer will hand over their table, then only updates are relayed after. In addition, BGP routes are stored in RIB, or Routing Information Base, where multiple routes to a specific destination are stored. Here, routes are then placed, based on best choice by the router, into the routing table to be used. (The routing table picks the route that uses the least number of AS hops.) This allows for the routing table to be kept small and to update only if needed. Because of the RIB, if a route needs to be removed, but only exists here, then it is silently dropped and no update will be sent. Also, because of this functionality there is no need for RIB entries to time out, so they exist in the base as long as they are valid.
Now, after discussing how BGP works, it is important to talk about its faults and how it has lead to some pretty drastic mishaps. Poor configuration of BGP has plagued the internet since the beginning, but now that more of our lives are connected and better information of proper maintenance is available, it is more important now than ever to educate ourselves. BGP does not appear to be going away anytime soon, so the best thing we can do as security engineers to help protect our organizations is by learning from others mistakes.
Let us take Verizon for example, in June of 2019 a massive route leak impacted huge parts of the Internet. In short, a small Internet Service Provider company named DQE Communications used a BGP optimizer which preferred specific routes over generalized ones and then advertised these routes to their client Allegeny Technologies. From here it was then advertised to Verizon where it was further advertised to the world. Which in return, rerouted traffic to this preferred path causing a massive fault as this route was not prepared to deal with so much traffic. Now the advertisement should have stopped at Verizon, but because it did not around 20% of the Internet was impacted.
In an act to prevent this from occurring, the major thing that should have been implemented is to impose a hard limit of prefixes expected to be received on a BGP session. We will actually explore BGP security more in a later blog so keep following along.
Overall, BGP is the routing protocol of the Internet and while it is the backbone, it does not mean that it is perfect by any means, but we has engineers have to do our best so that another issue like this does not occur.
*For simplicity sake we are going to forget about Internal BGP and will not discuss it. If you want to learn more about how BGP can be used on the internal side visit this link:
CAM table overflows typically are an attack of the past, however that does not mean that we should forget about them. After all once a vulnerability has been found we cannot assume that future devices won't be vulnerable to this threat. In short, CAM table overflows are the idea of an attacker flooding a switch's MAC address table with bogus addresses, thus leading the switch to enter into a flood 'all traffic on all ports' state. This can create a DOS or allow the attacker to sniff traffic.
The best solution to this vulnerability is Port Security and the configuration is quiet simple, all you need is a Cisco switch.
Below we will walk through setting up port security on 24 ports to allow a maximum of 2 MAC addresses, to save already existing MAC addresses, and to shutdown the port if this violation occurs.
Default configuration: Please note that be default Port Security is set to memorize only one MAC address and shutdown the port if this violation occurs.
moses-switch# configure terminal
moses-switch(config)# ! grouping the range of ports, from 1 to 24
moses-switch(config)# int range gigabitEthernet0/1-24
moses-switch(config-if-range)# ! setting all of the ports to be access mode
moses-switch(config-if-range)# switchport mode access
moses-switch(config-if-range) # ! setting the maximum number of mac addresses allowed
moses-switch(config-if-range)# switchport port-security maximum 2
moses-switch(config-if-range) # ! saving the already existing MAC addresses for port security
moses-switch(config-if-range)# switchport port-security mac-address sticky
moses-switch(config-if-range)# ! setting the ports to shutdown if more than two MAC addresses is received
moses-switch(config-if-range)# switchport port-security violation shutdown
moses-switch(config-if-range)# ! Lastly starting up the service itself
moses-switch(config-if-range)# switchport port-security
Now please note that you can enable port security on a trunk, however regardless of the port it must be static, meaning that the switchport cannot be set to dynamic.
In addition, please note that while this example is shutting down the the port, in an enterprise environment it might be best to restrict or protect the port instead and set up an SNMP trap to alert an administrator of a potential problem. Also please note that this is just the tip of the iceberg, as port security can even rate limit and limit the number of MAC addresses saved for a VLAN.
The DNS service is vital part of any company's network and compromising it can lead to the loss of confidentiality and integrity. Therefore it is crucial service that needs to be both monitored and protected heavily.
In this post we are going to discuss 3 common DNS attacks that you should protect against, now given there are many more so continue to do your research afterwards. In addition, I am also going to assume that you understand how DNS works.
The basics of this attack is simple, redirect valid traffic going to a legitimate server over to a malicious one and it does this by corrupting the DNS cache data. Each time your computer encounters a domain name it does not recognize it must contact the DNS server, this server looks up the translation of IP addresses to domain names and then sends the packets accordingly. However, if an attacker can modify the information that the DNS server is telling users then it can affect entire companies, even more so, depending on the relationship this server has with others, then this false information can propagate to other servers in different organizations and so forth, eventually spreading like wildfire.
In short the attack can work like this:
DOS - TCP SYN Floods
In short, an attacker will overload the server by sending bogus SYN packets to abuse the TCP 3-way handshake connection. In reply, the server will send SYN-ACK responses, thus leaving the server 'hanging', which eventually leaves the server unable to connect to requests coming from valid users.
A method to prevent against such an attack would be to implement a host based firewall and a host-based intrusion detection system, while securing the network itself.
MITM - DNS Hijacking
Man in the middle DNS hijacking is the idea of an attacker intercepting and altering the cache data traffic between a user and the DNS server, thus leading the user to be redirected to a different destination that is often malicious.
While not fool-proof the three best methods that can be used to prevent against such an attack are to secure the surrounding network, locking down who is allowed access, using DNSSEC, and encouraging and sometimes even forcing clients to use HTTPS whenever browsing websites. Now, forcing users to use HTTPS will not encrypt the DNS traffic itself, but can act as a last line of defense with the web browser displaying that user has entered into an unsafe zone.