Theoretical Hacking for IT Managers
Not everyone has "l33t skilz" or mass amounts of hardened TCP/IP stack programming experience. When I'm at work, I don't look at logs all day long, nor do I run security audits every five minutes. I do my job, which takes all of my time. This is the situation for most small to medium sized companies that have only a few IT guys. So how does an everyday IT guy handle the constant threat of impending attack?
Keeping up with the latest security threats in a mixed OS environment is virtually impossible. You have to choose where to put your defenses. I choose my defenses based on my own paranoid view of the world, with my procrastination and laziness factored in for good measure. The term I use for this is "theoretical hacking", in which no actual computers, programs or animals are harmed.
The first question in theoretical hacking is, "Where do I start?". You have two options here, inside out or outside in. That is, you can consider attacks from the point of view of someone outside your office trying to break in. Or, you can consider scenarios in which someone inside your office is trying to cause damage or steal data. For now, let's take the standpoint of some random dude on the outside trying to break into your network.
First, though, let me make one thing clear: if someone really wants to cause you harm or wants to break into your network--and I mean really wants to do it--you can't do much about it. Anyone with enough time and resources can do just about anything. In response, you can hope that you set enough tripwires to give you warning if something bad is going on. Or, you can hope to be far enough off the grid as to be invisible. I say "off the grid" because not everyone is a Google, Microsoft, IBM or Apple. The only Web presence my company has is a Web site not hosted by us and e-mail, which we do host. So, only one real link exists between my company and the outside world, giving us only SMTP/POP to deal with--more on this later.
I like to compare network security to a glass house. In a glass house, you can have a great deal of security on all of the doors and windows. You can have armed guards. You can have cameras, lasers, alligators, a catapult and a sith lord. But, that doesn't change the fact that everyone walking by can see what is going on inside your glass house. If someone stands outside and looks in long enough, he will know everything about the place. You also can't stop people from walking up and knocking on the door or looking in the mail box. And the really bad part is you can't stop some kid from throwing a rock at your glass house. The best you can do is watch and hope your glass house doesn't break. Network security is passive in this same way. We have to wait and watch for something to happen.
When you're considering a network security design, there are two extremes. One is the delusional paranoid design, which consists of a standalone computer with no peripherals, no Internet, no USB, no Bluetooth, no CD-ROM, no floppy, no external hookups at all. The standalone uses biometric authentication with 128-character alphanumeric passwords to access each application as it is needed. You have to memorize whatever work you do and retype it at another location. The other extreme is a more common situation, in which a bunch of computers are set up in a public place with free Internet access and without passwords. The reality for most people lies between these two extremes but leans more toward the latter.
Let's start with the basics. Think about the actual connections leaving the network; think about what is leaving. A big part of security ends up concerning who is on the network, not what is on the network. So, think about the employees. Who is doing what? Are employees surfing the Web or actually performing tasks for which Internet access is a critical tool? In most cases, minus e-mail, the latter isn't true. So what is the real concern with employee Web surfing? Viruses. I use the term "viruses" to refer to trojans, spyware and any type of application not intended to be installed as a job function application. A lot of tricky apps are out there that get users to install them under the guise of other apps. Users on your network never should be allowed to install anything.
Thus, in a company where employees are Web surfing and using e-mail, the first order of business is to stop any and all viruses. This actually is fairly simple to do if you are running Linux, but most companies have a large allotment of Windows desktops. Therefore, I suggest using desktop antivirus software with hourly updates. This is a simple yet highly effective method of stopping almost any type of attack. If your company has no services running--FTP, SQL, etc.--the only real threat is viruses. How else can some random dude gain access to a system?
So here we are with a bunch of users on the Internet, and the only defense is antivirus/trojan software. Simple scenario? Yes. Realistic? Yes. So, how would you break into a network with no services running and no exploits on the desktops? You scan the network. How do you scan the network? You start by figuring out what subnet or IP address the computers are on. There are only three ways of finding out that information. First, you can do a general scan of IP addresses and hope you run across the company's network. But, if there aren't any services running, how would that network show up? Keeping with the no services example above, your network is pretty safe on that front. The second way to find subnets or IP addresses is to track them from a Web site. If one of your users goes to someone's Web site, blog, list or anything of that sort, the IP address can be logged and used later. The third method of finding subnets and IP addresses is through e-mail messages, which keep them in the headers.
So, it really boils down to hiding your network's IP addresses from the world when users are Web surfing and e-mailing. One way to hide them while surfing is to use an application such as Tor. Here is a quote from the Tor Web site about what it does:
Tor is a toolset for a wide range of organizations and people that want to improve their safety and security on the Internet. Using Tor can help you anonymize web browsing and publishing, instant messaging, IRC, SSH, and other applications that use the TCP protocol. Tor also provides a platform on which software developers can build new applications with built-in anonymity, safety, and privacy features. Tor aims to defend against traffic analysis, a form of network surveillance that threatens personal anonymity and privacy, confidential business activities and relationships, and state security. Communications are bounced around a distributed network of servers called onion routers, protecting you from websites that build profiles of your interests, local eavesdroppers that read your data or learn what sites you visit, and even the onion routers themselves.
With something like Tor in place, we're left to deal with e-mail headers. There isn't a universal easy solution to this one, although it can be easy to fix--it really depends on the situation. If you outsource your company's e-mail, that protects your network. But, now you have to worry about some third party looking over your e-mail. If that is not a concern and outsourcing e-mail is cost effective, then with a few minor tweaks you should be good to go. The tweaks themselves are simple, too: secure POP and SMTP and do not send POP/SMTP passwords over the Internet without some type of encryption.
If your company hosts its own mail server, however, you have a whole other set of problems. Hosting your own mail server brings to the table a lot of overhead, and you need to consider many more potential problems. For the purposes of this article, I lightly cover some basic considerations.
When handling e-mail yourself, two basic components are needed, a firewall and a mail server. The firewall performs two functions, network address translation (NAT) and IP/port forwarding. NATing a network is a huge security plus that is simple and effective. It essentially creates a buffer for your network. In that buffer, you can do anything you can dream up to prevent anything you can think up. You also need to IP or port forward the incoming mail to the mail server. I think it's always a good idea to separate exposed servers from the rest of the network, DMZ-style.
Next, you need to introduce antivirus software strictly for the mail server. You can choose from several, so spend some researching which one is best for your company's needs. The main thing here is to let the mail antivirus server take the brunt of the traffic and have it forward the clean mail to the mail server on a different port. I'm not going to get into how to secure the mail antivirus server in this article, but it does need to be done.
At this point, we still need to worry about the IPs in e-mail headers. This is a catch-22 situation, however. You can remove the outgoing headers on e-mail, but doing so can cause difficulties when you are troubleshooting e-mail problems. If you really don't want people to see IP addresses in your company's e-mail headers, you can strip them out at the firewall as the messages leave the network. This step isn't easy to do, but it is possible. In reality, whether you should implement this step depends on how much time you can spend on it.
Still, stripping out the IP address from the header is only part of the solution. You also should add the extra layer of protection offered by hosting an off-site relay for mail. This relay could be a mail server that forwards your company's e-mail to the network. Or, it simply could be the use of secure POP/IMAP to access e-mail. The reason for this relay is DNS MX records. Anyone can look up the host of your domain and get your IP address from your MX record. Having a relay prevents this from happening.
Essentially, the point of this article is to get you thinking about what is happening on your network and about what you can do to be safe without going crazy from all the talk about security breeches and all the security applications on the market. The main idea is to set things up so you don't have to check on them every day. Ideally, you want to have a general sense that your network is secure to the point that someone has to throw a lot of rocks at your glass house before something breaks. At that point, one of your alerts goes off, and you can tell that stupid kid to stop throwing rocks by blocking his IP from connecting to your network.
In conclusion, we are trying to hide our networks from the world. If the world doesn't know where we are, it can't do any damage to us. We are relatively safe simply because we sat down and thought about how some random dude could break into our network.
Aaron Steimle is a partially functional paranoid human with an addiction to Linux and a degree in Electrical Engineering. He vigorously enjoys not being dead. He can be reached at firstname.lastname@example.org.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- I once had a better way I
5 hours 4 min ago
- Not only you I too assumed
5 hours 22 min ago
- another very interesting
7 hours 15 min ago
- Reply to comment | Linux Journal
9 hours 8 min ago
- Reply to comment | Linux Journal
16 hours 2 min ago
- Reply to comment | Linux Journal
16 hours 18 min ago
- Favorite (and easily brute-forced) pw's
18 hours 10 min ago
- Have you tried Boxen? It's a
1 day 2 min ago
- seo services in india
1 day 4 hours ago
- For KDE install kio-mtp
1 day 4 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?