 |
 |
 |
 |
 |
|
|
|
|
|
|
Security Principles
previous 1
2
Security Tools and Procedures
Now that you know that you need security, what are you going to do? I'm sure you're probably making mental notes about things to check on your servers at work. I've put together a list of tools for Windows and Solaris that will help you in locking down your networks.
Solaris
TCP Wrappers and SSH Installation I've put together a script that installs TCP Wrappers 7.6 and SSH 2.0 (Non-Commercial Version) from http://www.ssh2.org. Please note that this version of SSH is for educational purposes only. If you want to use it for your business, you will need to contact http://www.ssh.com and order a copy for your server. You can download the files in one big tarball here. The files should be located in /export/home/install and the script tcp should have its permissions set as 755. You must be root to install this. Click here for the contents of the script file, tcp. You will also need to have gZip, tar, and GCC installed and in your path. These utilities are available from http://www.sunfreeware.com.
The tarball (install-ssh.tar) contains:
tcp
hosts.allow
hosts.deny
inetd.conf
S68sshd
Securing DNS If your organization is very dependent upon DNS and your internal DNS servers are accessible via the Internet, you may want to consider locking down DNS. BIND allows for several security-related options, including hiding the DNS version ID and allowing queries from specified hosts/networks.
To hide the version ID of your BIND DNS server, edit /etc/named.conf and look for the options { ... } directive and add a statement for version:
# /etc/named.conf
options {
...
version "[Put your text here]";
...
};
That's all there is to it to hide your version. Suppose, now, that you have a DNS server that has multiple zones on it--some of them you want people to know about (such as information for web servers, mail servers, etc.), but you also have some internal zones that you only want people inside your organization to be able to resolve. That's where creating an ACL for DNS comes into play. To create that ACL, you simply need to add the { allow-query { ... } directive to your zone file entry. For example,
# /etc/named.conf
zone "my.domain.com" {
type master;
file "/usr/local/named/my.domain.com";
allow-query { any; };
};
will allow any host to query your DNS server for a hostname on my.domain.com. The default behaviour for BIND is to allow all queries, so adding the allow-query { any; }; directive is redundant work. However, if you change the allow-query statement to an IP address or network address, you effectively deny anyone except that address or network access to query your DNS server for answers in that particular zone. For example,
# /etc/named.conf
zone "my.domain.com" {
type master;
file "/usr/local/named/my.domain.com";
allow-query { 10.1.1.1;
192.168.0.0/16; };
};
restricts your DNS server to only answer queries from 10.1.1.1 and hosts on the 196.168 class B network. All others will receive "Query refused." For my tools page (that includes some DNS utilities), click here.
Checking your system files
There are a variety of root kits floating around that do such things as replace common commands like 'ls' or 'cat' with a trojan program. Many of these trojans act like the program they're named after (for example, the ls trojan still performs the ls command so that it tricks the user), but they unleash their payload in the background. Trojans can create logins, modify log files, install programs, or open ports.
I wrote a script based on MD5 that lets you record the checksums of whatever files you want. Simply compile a list of programs/files that you want to maintain an up-to-date checksum file of and run the script. It's not perfect by any means, but it did what I needed it to do. It's not terribly complex, either, so it's easy for you to modify. The script requires the freeware MD5 tool. You can get it at http://www.sunfreeware.com or on this website (SPARC/Solaris 2.6 or SPARC/Solaris 8). Please note, though, that mine is not updated very frequently. You can get the script here.
You'll probably want to back up the file containing the checksum from time to time (like when it changes) so you can keep a tally of when it does change. That could be useful for correlating a system crash with a system file change (patch/patch cluster update, user stupidity, virus). Of course, to make that useful, you'll probably want to run the script on a regular basis. I'll update it soon so it can run non-interactively (like via cron). I just haven't been that enterprising yet.