So it used to be I received a /56 IPv6 prefix and then my router picked a /64 for my lan. Then it turned into a /60. Now I get a /64 and my router has to turn that into a /72. Come on Comcast, don’t break IPV6 norms.
Most service providers have been the victim of a Denial of Service (DoS) attack at one point or another. Sometimes you may not realize you are under an attack. A few months ago, I posted a simple screenshot at https://blog.j2sw.com/networking/anatomy-of-a-ddos/ of what an active DDoS looks like.
Types of Attacks
In order to know what to look for you have to understand the four basic types of attacks. I will outline this and talk about how modern attacks are affecting Internet Service Providers (ISPs). In my next article, we will talk about identifying these types of attacks and some mitigation techniques you can employ.
Throw everything at you attack aka Buffer overflow
This type of attack is throwing enormous amounts of traffic at you to fill up your switch and router buffers, causing the device to exceed its capabilities. Your devices become crushed by an overwhelming volume of data throw at them. This attack isn’t always sheer bandwidth. Sometimes it is tens of thousands of remote connections.
Attacking vulnerable protocols
Attackers go after exposed services like ICMP to do amplification attacks. Fragmented packets, which keep the router tied up are also a common method of attacking a host.
These are the ones most consumers hear about. Vulnerabilities in operating systems, applications, and packages are exploited and used in attacks.
The fourth kind is not lumped in with Application attacks, but I wanted to separate it for a few reasons. The first reason is that someone compromising a system is not always sophisticated. If a bad actor guessed the password on your router and erased the configuration, they have performed a Denial of Service against you. If you don’t keep your software up-to-date and someone exploits a backdoor and “hacks” your system, they have performed of DoS attack.
Modern Attacks against networks
Modern DoS attacks are always evolving. As network administrators find ways to mitigate these attacks, the bad actors find ways to tweak them and get around mitigation techniques employed by providers. Most of the exploits above involve sheer volumes of traffic or connections being directed at a host to take it offline. This attack is especially detrimental for service providers because it takes your customers offline if the attack is significant enough.
One of the most common techniques these days is the Distributed Denial of Service attack (DDoS). These are usually botnets involving thousands of compromised machines or devices acting against a host(s). These can be anywhere in the world. They could even be users inside your network with compromised machines or other devices. Distributed attacks are hard to mitigate because they can be legitimate traffic pointed at a web-server as an example. The traffic is not malicious from a technical perspective. You have thousands and thousands of machines sending legitimate requests to a web-server or other host on your network. This traffic looks legitimate but is overwhelming for your hardware and Internet pipe.
So what does a DDoS look like and what are your options when it comes to Denial of Service Attacks? In my next article in this series, I will talk about some best practices you can do so you are not as vulnerable to these types of attacks.
Does your ISP network need a way to validate customer speeds? RDOF compliance? State compliance for broadband speeds and latency? as many of you know there are problems with using public speedtest servers to validate customer speeds.
J2networks, in conjunction with Aloremnetworks, has an on-premise solution that is easy to manage, small footprint, and scalable. Our appliance lets you add a speed test server in almost any part of your network. It’s small footprint and low power draw makes it easy to fit in remote cabinets as well as the data center.
Contact us for more details and pricing.
I am starting to see the following scenario more and more as IPv4 space is hard to get, but isn’t.
With ARIN it is still possible to get an IPv4 allotment. Many smaller ISPs qualify for a /24 and can get one if they wait long enough on the ARIN waiting list. a /24 of IPv4 space is the smallest block that 99% of the Internet allows to be advertised on the Capital I Internet. There are filter rules in place that drop smaller prefixes because that is the agreed upon norm.
So what happens if you are an ISP and you have a shiny new /24 but you have two networks which are not connected. Let’s look at our scenario.
The above network have no connectivity between the two of them on the internal side. These could be half way across the world or next door. If they were half way across the world it would make sense to try and get another /24. Maybe they are either side of a big mountain or one is down in a valley and there is no way to get a decent link between the two networks.
So what is a way you can use this /24 and still be able to assign IP addresses to both sides of the network? One way is to use a tunnel between your two edge routers.
Without the tunnel the scenario is traffic could come into network1, but if the IP is assigned on network 2 it will come back as unreachable. BGP is all about networks finding the shortest path to other networks. You don’t have much control over how networks find your public IP space if you have two providers advertising the same information. Some of the Internet will come in Network2 and some will come in Network1.
By running a tunnel between the two you can now subnet out that /24 into two eqal /25s and assign one /25 Network1 and one /25 to Network2 or however you want to. You can make the tunnel a GRE, EOIP, or other tunnel type. If I am using Mikrotik I prefer to use EOIP. If it’s another vendor I tend to use GRE.
Once the tunnel is established you can use static routing, OSPF, or your favorite IGP (interior Gateway Protocol) to “tell” one side about the routes on the other side. Let’s look at a fictional use.
In the above example our fictional ISP has an IPv4 block of 188.8.131.52/24. They have two networks separated by a tall mountain range in the center. It’s too cost prohibitive to run fiber or a wireless backhaul between the two networks so they have two different upstream providers. The ISP is advertising this /24 via BGP to Upstream1 from the Network 1 router. Network 2 router is also advertising the same /24 via BGP to Upstream 2.
We now create a Tunnel between the Mikrotiks. As mentioned before this can be EOIP, GRE, etc. We won’t go into the details of the tunnel but let’s assume the ISP is using Mikrotik. We create an EOIP tunnel (tons of tutorials out there) between Network 1 router and Network 2 router. Once this is established we will use 172.16.200.0/30 as our “Glue” on our tunnel interfaces at each side. Network 1 router gets 172.16.200.1/30. Network 2 router gets 172.16.200.2/30
To keep it simple we have a static route statement on the Network 1 Mikrotik router that looks like this:
/ip route add dst-address=184.108.40.206/25 gateway=172.16.200.2
This statement routes any traffic that comes in for 220.127.116.11/25 via ISP 1 to network1 across the tunnel to the Network 2 router. The Network 2 router then send it to the destination inside that side of the network.
Conversely, we have a similar statement in the Network 2 Mikrotik router
/ip route add dst-address=18.104.22.168/25 gateway=172.16.200.1
This statement routes any traffic that comes in for 22.214.171.124/25 via ISP 2 to network2 across the tunnel to the Network 2 router. The Network 2 router then send it to the destination inside that side of the network.
It’s as simple as that. You can apply this to any other vendor such as Cisco, Juniper, PFSense, etc. You also do not have to split the network into even /25’s like I did. You can choose to have os of the ips available on one side and route a /29 or something to the other side.
The major drawback of this scenario is you will takef a speed hit because if the traffic comes in one side and has to route across the tunnel it will have to go back out to the public internet and over to the other ISP.
So, due to Covid, weather and everything else I am quite behind on blog updates and such. this is one that kinda fell through the cracks. I meant to get this out much sooner than now. My buddy Schylar Utley has a pretty cool projects for optimizing CPE deployments and such.
Check them out at https://github.com/MajesticFalcon
I have included an old video to give you an idea. I am sure things have changed since this video was created.
Has anyone used one of these switches?
Their sales staff has been very helpful. I have not come across a switch manufacturer that has had no software updates to their product. I asked about firmware and software updates and they do not have any.
The switch itself looks very intriguing for the WISP market. It’s a small form-factor SFP and SFP+ switch. It appears ports 1-14 are 2 1 gig, and 15-16 are SFP+.
Feedback from anyone who has deployed one. I asked for a reduced price demo and they don’t have one.
#switch #versitron #SG162147M
Preseem now supports IPv6 for all use cases. This includes the ability to assign subscribers a prefix of arbitrary length.
IPv4 with Prefixes of Arbitrary Length
Previously Preseem modelled subnet assignments to customers as a number of /32 assignments. For example a subscriber who was assigned a /30 would result in four internal /32 mappings. Preseem now supports assigning any prefix length to a subscriber without expanding these into /32 entries internally.