Just a little firewall switch today. Netgate firewall appliance switched out to replace some old Cisco ASAs.
I recently was hanging out with an ISP admin who moved over from the Enterprise world. After a few days with him, it rekindled the interest in writing this article. From a high level, a network is a network. Its job is to move bits to and fro. The goals of the network are where we start to see networks separate themselves. Let’s start with some simple goals of each system.
An enterprise network’s goal is to protect the end-users from outside threats and themselves while giving access to the things they need for their job. An enterprise admin deals with things like firewalls, file servers, software, and Domain controllers. Switches and routers are backend systems for the enterprise. A means to deliver the software to the end-user.
An ISP network’s goal is to give access to the Internet as a whole to its customers while protecting its infrastructure. Access points, fiber ONTS, and backhauls are the things routinely dealt with by ISP admins. Servers and things are backend systems for the ISP. The servers become the support systems to deliver access to the customers.
The most significant difference between the two networks above is the Enterprise customers are given access to what they need for their job. If they need the Internet, it is routinely filtered for content, and non-work related sites are blocked. Admins of the Enterprise network follow the “block all and allow what is needed” approach. Sure, the Enterprise admin deals with things like WAN connections, switching, and sometimes even BGP but not in the same ways a Service provider does.
In contrast, Service Provider networks should give unfettered access to the Internet and leave it up to the customer to decide what they should and should not restrict access. With ISP customers you are only dealing with Internet access and don’t necessarily know what the users are doing with the Internet “pipe”. You don’t have to worry about content filtering (unless that is an add-on or your business model), file shares (handled by corporate VPNs) and restricting access to things.
My oversimplified view is most ISPs mainly deal with layers 1-3 of the OSI model for their access networks, while Enterprise networks deal a lot with layers 4-7. The software takes focus, and layers 1-3 are just necessary to make the software work. In other words, the corporate network deals with the LAN more than the WAN and the ISP network deals with the WAN more than the LAN. As corporate networks grow these lines tend to blur a little.
If you are an ISP admin, your goal should not be blocking what users are doing. Your goal should be to give the user fast speed and the lowest latency possible while protecting your infrastructure from them and the outside world. I mentioned latency because of gaming and streaming. Every device the customer goes through it adds latency. Sometimes its fractions of a millisecond, but there is no free lunch. This speed hit is why firewalls have limited uses in the ISP world for access customers. Firewall options give you a myriad of choices when it comes to throughput and latency. These licensing options for things such as the number of concurrent connections, latency level pricing, and the sheer number of users supported. You pay for the more connections you need to run through the firewalls. What may be useful for a corporation of 500 users probably won’t support a 500 user ISP if everyone is routed through a firewall.
So what is someone to do with all this information? If you are an ISP, you should adopt and adapt the following guidelines for your business.
1. Don’t firewall your customers on your access network. Let them be responsible for that. If you are a managed service provider (MSP) then you have firewall services at the desktop and router level you can sell. If you are just an ISP you can sell a managed router service to help protect the customers and your infrastructure. However, don’t be heavy-handed as it will create more problems than it solves (see #2)
2. Things change so much in terms of how programs and apps utilize networks. Customer demand routinely drives service providers to adapt and change with the times. An ISP who restricts what their customers do gets left behind pretty quickly. In some instances, you even have laws about limiting access to content.
3. As technology evolves so does the use of your network. Restricting customer access to the Internet via firewalls creates more support because you are routinely editing rules, troubleshooting, and upgrading firewall software.
I want to close with a little philosophy. It’s not that firewalling an ISP network is a bad thing, it’s just not very efficient and cost-effective. You need to keep buying more and more firewalls to keep up with demand. Firewalls have their place in corporate environments. In my next article, I talk about how ISPs should be running both types of networks. Look for this coming soon.
Some dell servers going in for a client. Cisco 3063 switches, Palo Alto firewalls. The yellow and red power cables denote A and B power.
There are many scripts out there, especially on Mikrotik, which list drop as the action for denying bad guy traffic. While this isn’t wrong, you could put the tarpit action to better use for actions which are dropping attacking type of traffic.
So what is Tarpit?
Tarpit is fairly simple. When connections come in and are “tarpitted” they don’t go back out. The connection is accepted, but when data transfer begins to happen, the TCP window size is set to zero. This means no data can be transferred during the session. The session is held open, and requests from the sender (aka attacker) to close the session are ignored. They must wait for the connection to timeout.
So what’s the downside?
TCP is not really designed to hold onto a connection. It can be additional overhead on a taxed system. Most modern firewalls can handle tarpitting without an issue. However, if you get thousands of connections it can overwhelm a system or a particular protocol.
How can I use it?
If you have scripts, such as the SSH drop off the Mikrotik wiki, simply change the action to “tarpit” instead of “drop”.