Border Security: What's the Latest?

There are plenty of things you can do to tighten down your network, but it's the little things that continue to mean the most.

Back in 2005 we spent some time on "Border Security," giving some advice about protecting yourself from the big bad Internet. Even more importantly, we alluded to the notion of protecting the Internet from you. Let's take an updated look at some basic firewall settings that everyone should employ, with the developments of the last few years, and rehash the importance of personal security for the overall good.

Over time, one's security model normally remains the same, but the specifics of "filtering" need to be updated. Over the last few years, IRC botnets have become commonplace. Their reach is still expanding, and the ownership rights to well-connected computers on fast network connections are a commodity, traded on the open (underground) market.

So first and foremost, we might like to prevent the new "owners" of these computers from accessing their resource. Luckily these compromised computers are generally used to store data or participate in DDoS attacks, instead of acting as a springboard into your internal network. Not to say that it won't happen, but in general, botnet operators aren't really interested in your network. Surprisingly, the majority of the IRC botnets still use the default IRC port, 6667. Blocking this port (inbound) at your border router (or firewall) can go a long way toward preventing any of your machines from hosting a botnet controller. Blocking it outbound, assuming you have no legit IRC users, is also very helpful: compromised machines won't be able to phone home.

"But they will just change ports, right?" No, not really. There are two factors to consider here. First are the users of the software; they aren't the authors, they simply know how to use it. Second is the fact that not many sites will block IRC traffic, so there are still plenty of accessible compromised hosts online. It would make sense for botnets to use port 80, SSL encrypted, so that detection and blocking is impossible, but there's really no need with so many easily compromised and wide-open hosts available.

Just like the previous article, this one's focus is about how to play nice on the 'Net.

But this time, let's talk about preventing DDoS attacks. We don't normally worry about denial-of-service attacks until they're happening to us, but you must ask yourself, "how can this happen in the first place?"

A massively distributed denial-of-service attack is pretty unpreventable. If 10,000 hosts are all sending 56Kb/s, that's roughly 50Mb/s. Enough to take many businesses off the Internet, but given the fact that each computer is only sending a dial-up's worth of data, there isn't much a remote site can do to stop the DDoS.

Often DOS attacks are done with a limited number of hosts. For example, 100 compromised hosts on a University network may be instructed via IRC to send as much data as possible to a site in Brazil. This type of attack certainly can be limited.

On a university network with gigabit Internet connectivity, why do all hosts need 100Mb or 1Gb connections? There may be legitimate reasons that a few computers need to have the ability to send a few hundred Mb of traffic externally (to the Internet), but not many. The same thing goes for the well-connected corporate network, though those are rare.

The old adage is that end hosts shouldn't be connected as fast as your switch uplinks, but in reality that's not feasible. 10GbE interfaces are still horribly expensive, and end nodes need more than 100Mb at times. That's usually only an internal requirement; very few computers really need more than a few Mb connectivity to the Internet, depending on your business, of course.

Be nice! Rate-limit all external connectivity, so that your end hosts can't send more than a reasonable amount of traffic. A simple PC hidden away on your network shouldn't be able to make other Internet sites notice your presence. If this is potentially an issue for you, please consider rate-limiting all of your nodes. The other advantage to rate-limiting is that you can configure end systems' ports to prevent them from taking down your internal network too.

Aside from the added plea to well-connected sites, not much has changed in the world of border security. Literally, the security considerations and exploits haven't changed much, and sites' security implementations haven't improved either. There are more products available to push virus and spam filters into your firewall device, but those only work for low-bandwidth sites.

Everyone needs to review the IETF BCP (best current practices) documents listed in the previous article. That's minimum functionality, which many people seem to forget.

In the end, no matter how over-engineered your network is, regardless of your firewall rules, in spite of all your policies, your overall security boils down to the lowest common denominator. A single compromised Windows computer can give an attacker access to your internal network, providing a springboard with which to fan-out and attack other, more critical servers.

In the interest of making the Internet a safer place, we can't forget to mention that ISP-connected personal computers are also large contributors to botnets and DDOSes. Most Internet providers have taken steps to prevent end users from sending too much traffic, but they can still do more to prevent hosts from being compromised in the first place. And when is the last time you ever heard of a large ISP contacting a customer and forcing them to get virus-free before allowing them Internet access again? Never.

That single compromised computer on your enterprise will most likely be involved in scamming innocent people or executing a denial-of-service attack. To both ensure your own security, and make the Internet a better place, the first step is to stay up to date on patches and security updates.

It seems obvious, but people still aren't doing it.

Please enable Javascript in your browser, before you post the comment! Now Javascript is disabled.