"My crime is that of outsmarting you,
something that you will never forgive me for."
—The Mentor, Conscience of a Hacker
Let's imagine that you have a couple of servers that perform a huge array of different services. They contain hundreds of gigabytes of public traffic as well as classified information that you need to protect. Your job as security engineer is to ensure that this network is secure. In this Daily Drill Down, I'll examine the basics of building a security infrastructure that provides high speed and maximum security for your network.
The first rule of all systems administrators who write rulesets for their "super-secure" firewalls is: "Disable everything, enable only what you really need." Yeah, sure. Hardly anyone spends more then a second thinking about this rule. Chances are, you probably have this as your first rule for your firewall:
deny ip from any to any
After this rule, you probably add rules to pass connections from trusted hosts, your workstation and so forth. Examine this sample firewall ruleset:
- deny ip from any to any
- reject ip from 10.0.0.0/8 to any out via fxp0
- reject ip from 172.16.0.0/12 to any out via fxp0
- reject ip from 192.168.0.0/16 to any out via fxp0
- allow ip from any to any via lo0
- deny log ip from any to 127.0.0.0/8
- deny log udp from any to any 136-139
- deny log tcp from any to any 136-139
- deny log udp from any to any 31337
- deny log tcp from any to any 12345,12346,20034
- pass ip from 192.168.1.2 to 192.168.1.1
- pass ip from 192.168.2.15 to 192.168.1.1
- pass ip from 172.16.1.1 to 192.168.1.1
- unreach port log tcp from any to 192.168.1.1 22,23 in setup
Rules 2 through 4 reject routing via this host (router) for all packets from the private class networks (according to RFC1918). Rule 5 allows routing for all packets on the "loopback" interface. Rules 6 through 10 are used for dropping all packets addressed to ports, widely used by Trojan horses like NetBus and BackOrifice. Rules 11 through 13 are used to allow full access to the host from "trusted" hosts. Rule 14 is used from logging connection attempts to SSH or telnet ports. Do you like this ruleset? Would you use it in your network? If you answer yes to any of these questions, you are becoming less competitive. And you need to rethink the building of your firewall rulesets.
By following this ruleset, you require your firewall to filter every packet in the network through the "deny" rule, which causes the network to steadily slow down. Therefore, if you're interested in the productivity of your network and its security, you can't use this ruleset. The solution is somewhat complex: You must know what services you serve, which are public and which require restricted access, and you must always have this list up-to-date. However, an experienced software coder can easily automate the process of building such large rulesets. Using this list, build the firewall's schemes without a first "deny" rule. Rulesets built this way may look ugly and be large, but your firewall and network will work 10 or even 100 times faster.
Slowing things down with rulesets: How to avoid this trap
You may have billing servers or servers with classified corporate information. Access to these servers should be restricted to only a direct link, such as Ethernet. This may lead you to say, "One more rule for my firewall's rule set," but that's the wrong answer. This wouldn't be only one more rule—for large networks, it can generate about 10 or more lines of rules, describing all direct links to the protected host. This slows down the network a great deal. A broken firewall will make all hosts vulnerable to intruders and attacks. Hosts that should be available only for Ethernet-linked stations shouldn't have any "default" route in their routing map. For example:
This simple step will prevent you from making any outgoing connections, but you'll still be able to answer and work with connection requests from Ethernet-linked stations. And there's no speed penalty for the entire network because there's no work for the firewall.
All authorization and authentication servers, such as RADIUS or TACACS, as well as monitors, and backup and logging servers should be isolated physically and be accessible only from trusted hosts or NASs (in the case of RADIUS or TACACS). No servers with confidential, classified information should serve any public services. If possible, all public services should be on a different network segment from the secure servers. This prevents an intruder from grabbing traffic between secure hosts. The secure segment will also work much faster because there will be no need for hard-ruled firewalls.
Intruders usually take two steps:
- Make a connection request to the telnet port.
- Trace a path to the host. This is used for collecting information about the victim, usually by the traceroute or tracert command.
After completing the first step, the intruder knows (about 80 percent of the time) the OS running on the victim host. After completing the second step, the intruder tries to determine the relationships between the victim host and other hosts on its path. Next, the intruder usually tries:
rpcinfo -p your.domain.com
showmount -ae your.domain.com
This code attempts to gain some of the information needed to crack into your system. Therefore, you must close the ports for RPC requests. No stranger should be able to obtain any information using these commands. Very often, information obtained from running these commands is a very powerful weapon in the hands of the intruder. The intruder may also try to obtain a list of users, because knowing login names on your server makes it possible to get a shell account on your server. Thirty percent of successful attacks are accomplished because a user has an easy-to-guess password. Therefore, you must disable public services that will give out such information. Among these are: SMTP's VRFY and EXPN commands, finger services, fake /etc/passwd files, routers, configuration files with plain or crypted passwords, and backup copies of pwd.db on anonymous-accessible FTP servers.
TFTP and DNS
Another security problem is the TFTP server. Many systems administrators leave it publicly accessible, forgetting that it has no authentication. For security's sake, tftp shouldn't be run. Since it's widely used for downloading and uploading configuration files to routers, it's not feasible to just turn it off. You should restrict access for the TFTP server to a directory that has no valuable information, or run tftp under the control of a chroot program.
The next big potential security hole is DNS. In half of all of attacks, the intruder uses the victim's zone information, obtained from the domain name server. Having a full name zone copy, the intruder can easily imagine the structure and topology of your network. DNS requests need to be answered, and closing port 53 isn't a solution—but you can disable DNS zone downloads. This feature was included in BIND 8.
Finally, consider the weaknesses of your operating system. Often an attacker's goal is to kill your network, not to steal from it. Be wary of systems such as Linux or Windows NT, which can be crashed by streams of broken packets or overloaded by massive numbers of bogus service requests. It's nearly impossible to prevent a denial of service attack by a determined attacker, but at least you can keep him or her from making your servers crash and corrupting filesystems. Systems such as the freely available BSD variants are much more stable in this respect than many better-known commercial products.
Proper security for a busy network requires careful analysis of the services to be provided and the information to be protected. The three keys to a successful security solution are:
- Use the features of your operating system to prevent access.
- Separate public access traffic from secure information and services.
- Know the information that hackers are looking for and keep it out of their hands.