Article
Secure Your Linux Server
Page: 1 2
/etc/ftpusers -- In the same way that telnet is disabled for the method of transmission, FTP should also not be used for root transactions. As a side note, it is also a good idea for a normal FTP user to find an SFTP client. This will allow secure FTP transactions to occur, as long as the hosting provider gives Secure Shell Access (SSH) to its users. But, back to the topic at hand.
When you edit /etc/ftpusers, make sure that root is not among the listed users. If it is, comment it out by putting a # at the start of the line.
/etc/xinetd.conf -- Older versions of Linux use /etc/inetd.conf instead, and it has a slightly different syntax and use. The xinetd.conf file is crucial to your networking. It starts services that pertain to your network connections. From it, you can (and should!) disable services that are not running or needed.
On our system, we'll descend further, to the /etc/xinet.d/ directory, where a file is listed for each of the default internetworking services. On our system, this directory includes chargen, chargen-udp, daytime, daytime-udp, echo, echo-udp, finger, finger-udp, ntalk, rexec, rlogin, rsh, rsync, servers, services, talk, telnet, time and time-udp.
The contents of these files look similar to this:
# default: off
# description: A daytime server. This is the tcp \
# version.
service daytime
{
type = INTERNAL
id = daytime-stream
socket_type = stream
protocol = tcp
user = root
wait = no
disable = yes
}
If you do not need, or are not familiar with any of the services listed, go into the file and set the disable attribute to yes until you can familiarize yourself with that service's use. Make sure that, whenever you make any changes to these files, you restart the inet daemon using:
# /etc/rc.d/init.s/inet restart
ipchains
ipchains is Linux's answer to a firewall. There are a lot of neat tricks that can be performed with ipchains, and you can search for those tricks on Google. But the module itself is fairly easy to use once you get the hang of it. I hope you can stay with me on this, as it can sound a bit over-technical. PLEASE BE CAREFUL, AS YOU CAN EASILY LOCK YOURSELF OUT OF YOUR OWN BOX.
It is important to recognize that ipchains actually refers to three separate chains. A typical ipchain command consists of several parts.
Firstly, it carries one of 3 commands.
-F flushes a chain
-P sets the handling for a chain
-A adds a new rule to the chain
To set up a chain, you might use:
# ipchains --F input
# ipchains --A input REJECT
This is a blanket command that essentially halts all incoming traffic. The first command flushes the input chain, and the second command adds a new rule to the input chain that rejects all traffic.
You could do this if you were completely disconnected from a network, but most of the world is not. Almost every Linux box in the world is connected to a network or the Internet, so it's not realistic to use such a blanket command.
Let's look at some more options available to us, to setup a more intelligent filtering system. Let's say your Linux box is a development server accessible only on the local LAN. The IP of its network device is 192.168.25.4 and has a netmask of 255.255.255.0.
Note that on Linux you can determine the source machine's network IP through ifconfig, or on Windows using the ipconfig command at the Command Prompt. The rest of the network is on the 192.168.x.x private block as well.
You might write a rule that looks like this:
# ipchains --A input --I eth0 -s 192.168.1.0/255.255.255.0 --d 192.168.25.4 --j ACCEPT
What the heck does that mean? Let's analyse.
ipchains --A input -- As mentioned above, this adds a rule to the input chain.
-I eth0 - This tells the firewall that the packet traffic on which we want to run this rule is attached to Ethernet Network Device 0 (Eth0).
-s 192.168.1.0/255.255.255.0 -- the source, or sending IP is at 192.168.1.0. The number after the slash denotes the mask, which in our case is 255.255.255.0
ACCEPT designates that all traffic from this source should be allowed. You could also use REJECT to keep traffic out.
The best bet for ipchains firewalling lies within its documentation, which can be found here.
Other Tricks
Some other tricks you can perform to further secure your server have to do with your servers' hosts* files.
In /etc/hosts.deny and /etc/hosts.allow you can deal with items called tcp wrappers, which simply "wrap" a service in a particular rule. Your hosts.allow file might look similar to this:
// Allow localhost
ALL : 127.0.0.1
// Allow SSH Access to anyone except from 192.168.1.101
sshd : ALL EXCEPT 192.168.1.101 : ALLOW
Your /etc/hosts.deny file might look similar:
// No one can connect via anything except loopback localhost
ALL : ALL EXCEPT 127.0.0.1:DENY
Intrusion Detection
You may want to consider using a package like Tripwire to detect intrusions. It doesn't come with Redhat, but you can get the source and compile it yourself. The way it works is that it creates and compares the hashes of critical files to determine whether any changes have been made.
An effective hacker won't just break into your system. He will also create a backdoor for himself so that he can gain access at other times. Most of the time, these backdoors are in exploited files, and this is one way you can protect against this occurrence.
Summary
There are many other tricks and tips available to the security-conscious systems administrator. The key to being effective is to always be on your toes and ready to think outside the box. There's generally more than one way to skin a cat and hackers are consistently inventing or discovering new means.
Please do not read this article and think that this is the be-all and end-all of system security. These tips merely scratch the surface. Happy guarding!l