Securing Your Home Network - Page 3

By Carl Hallberg | Posted Oct 16, 2000
Page 3 of 3   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn


For the Truly Serious

Let’s look at an example of a paranoid solution to home networking security. Although the details get technical, they provide an example of the possibilities.

In this example, all inbound and outbound Internet traffic is filtered through a Red Hat v6.2 box. The only open local service is SSH (Secure Shell for encrypted Telnet). Internal services are accessed via Red Hat’s built-in port forwarding feature. IPCHAINS is used for Network Address Translation (AKA Masquerading) as well as for creating IP filtering policies. As another line of defense, the HOSTS.DENY and HOSTS.ALLOW files are used to make sure computers that aren’t preauthorized cannot access any services. Internal hosts are then guarded with Norton Internet Security 2000 and have specific filters for communicating with other internal workstations.

On the Red Hat side, Psionic’s Portsentry v1.0 (www.psionic.com) is used to detect port scans. This product integrates well with IPCHAINS and can be used to run scripts and activate DENY rules based on inbound attacks. Portsentry can be used with IPCHAINS to respond to attacks, for example, rerouting the attacker’s traffic back to the attacker. This isn’t recommended; in our case it is used simply to run a trace route, ping and a few other common tools against the attacker. The results are captured to a file stored on another server so that a good snapshot exists of what the attacker looked like at the time of the attempt.

After the data has been gathered, a complete IPCHAINS DENY rule is set on the attacker’s address and stays resident for about a week or two. If the attacker is paying attention, he will see that he was lightly probed and will (we hope) stay away. If the attacker is a repeat offender, he gets added to the permanent DENY rule set. This can require ongoing administration and detailed log review; however, it’s a step worth taking if you’re at risk.

Outside of the tools enabled on the Red Hat box, a few things on an internal NT server are running as well. SurfControl SuperScout (www.jsb.com) is a product that uses sniffer technology to scan and intercept traffic that is not permitted. This product is used primarily to monitor and enforce corporate Internet use, but it also makes a great addition in an assortment of enterprise-level security tools. In addition, SnifferPro (www.nai.com) is used as an internal traffic analyzer and capture utility. SnifferPro gives a real-time, easy-to-read host’s list of recent connections. It logs the total amount of traffic transmitted during the stay, and has a nice matrix of active connections, all without even capturing any packets. Generally, capturing is only enabled when the user is troubleshooting or viewing network problems.

Great! Now we’re secure! We’re happily logging stealth scans hitting our network, noting attempts to log in, and so forth. Now what? Are we done?

An important element to remember when securing your information is the importance of strong passwords. Always try to use a combination of uppercase and lowercase letters as well as numbers and other extended characters -- just be sure that you pick something that is memorable. Syllables work well; e.g., "gola3bonu" or "uwitga9hoolor." We recommend that you always pick a password with at least 8 characters; we usually shoot for 15-20.

Use a secure screen saver even at home and set it for a reasonable period delay -- say, 15 minutes. If it gets in your way, extend the delay.

Encrypt the sensitive files on your system.

Don’t forget to protect access to your printer -- you don’t want some prankster printing junk (or worse) on your paper.

Perhaps. Perhaps not.

This may very well be the end, if you’re happy to leave it at that. It would certainly be a valid response to say "No harm, no foul." Many, however, will be tempted to give a would-be attacker a taste of his own medicine. A word to the wise: Along with the responsibilities of securing your equipment, you must realize the liabilities as well. You are responsible for anything that happens on your equipment. Even if an attack is launched from your computer without your knowledge, you could be held accountable. And in today’s insecure Internet, there is no way you can be absolutely sure that the apparent origin of an attack is actually the origin of the attack: someone could be spoofing the IP address and forging packets. Were you to become a cyber-vigilante, you could become part of the problem instead of part of the solution.

Two possible circumstances come to mind. First, you haven’t done anything to secure your network, and you become a zombie in someone else’s attack. Sure, your ISP can take some of the blame, maybe, because it should be able to secure its infrastructure, of which you are only a part. However, don’t expect to be able to hide behind your ISP. Just as any business may possibly face negligence suits, you may as well. If you haven’t done your part, you could be in for a rough ride. Not only is it socially responsible to protect your home computer from being co-opted by the bad guys, but it could keep you out of some nasty legal battles.

Second, you are secure, and you detect some things that are more than just scans. What is your response? Good security starts with a clear policy. A security policy needn’t be overly complicated. You may simply say, "I’m not letting any traffic in." Beyond that, you would need to decide, ahead of time, what your reaction would be to certain situations. It would be a good starting point to contact your ISP when considering your personal security policy (which you should have). Find out what its policies are. If you detect something, what is your ISP likely to act on? Should you report it? Who would you report it to?

You may be inclined to throw back at the attacker what the attacker is throwing at you. Before doing so, keep in mind that your ISP may see you doing this. Also, since you are on the ISP’s network in the first place, you are potentially much easier to track than someone breaking in from the outside. From your ISP’s point of view, allowing your attack out poses a serious liability to the ISP, which may prompt the provider to take action against you. Again, before reacting to an attack, simply log the attempt and contact your ISP. We strongly urge you not to try attacking the attackers using questionable tactics.

The bottom line is that you shouldn’t expect someone to take care of your security for you. Just as you diligently lock your car door whenever you leave it, you should lock up your computer system to keep the bad guys out.



Carl Hallberg (challberg@atomictangerine. com) and Michael Pavlu (mpavlu@atomictangerine.com) are Senior Technologists at AtomicTangerine, Inc. They welcome your questions.

Copyright ) Carl Hallberg & Michael Pavlu. All rights reserved.


SecurityPortal is the world's foremost on-line resource and services provider for companies and individuals concerned about protecting their information systems and networks.
http://www.SecurityPortal.com
The Focal Point for Security on the Net (tm)

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter