FIREWALL SET UP
HOW TO SET UP A FIREWALL UNDER LINUX?
To configure a Linux firewall, you will likely use the latest implementation of firewalling, called IPTables. IPTables is a packet filter for kernels 2.4 and above. It is a tremendous improvement over IPChains and provides enhanced features such as stateful packet filtering, Network Address Translation, MAC Address filtering and much more.
Creating a firewall from scratch can be daunting. Thankfully, there are plenty of sample rules, as well as sites and utilities that will help you customize a ruleset for your own needs. Those making use of automatically generated firewalls should use these firewalls as a base, make sure they understand them, and not blindly trust them. That being said, here is a list of useful tools: Sample IPChains, IPFWADM, and IPtables rules at Linuxdoc.org.
Sample scripts for iptables can be found at http://www.linuxguruz.org/iptables Jomorris also has a very mature rc.firewall package available through freshmeat. Endosheild: http://endoshield.sourceforge.net/ – Easy to configure firewall script thatt works with both IPchains and IPtables.
Sample IPTables rules by David Whitmarsh – Well commented and easy to customize. There are many different ways to start your firewall, and your choice of method is often one of personal preference. For most people, it should be adequate to keep thing simple, and initialize your firewall after your network devices come up, either via an init script, or with DHCP, which is covered in the next section. Those serious about securing their box will want to remove the window of vulnerability between the network device and firewall initialization, and start a minimal, restrictive, pre-firewall before any network devices are brought up. After the network devices are brought up successfully, the full firewall can be initialized. To do so, have an init script execute a pre-firewall just before networking is initialized. The pre-firewall script could contain some simple and restrictive rules such as:
/sbin/iptables -P INPUT -j DROP
/sbin/iptables -P OUTPUT -j DROP
/sbin/iptables -P FORWARD -j DROP
To get a list of all running processes, enter the command “ps auxw”. You might also want to try using “ps auxf” (or “ps auxfw” if the lines get truncated) – this prints everything in a nice tree format that may give you a better understanding of how and why things are running.
To get a complete listing of all listening network services using netstat, enter: netstat -altpu You can also get similar information using lsof by entering: lsof -i | egrep -i ‘LISTEN|UDP’ To get a “hackers-eye view” of what services you are running, use a port scanner such as nmap. Remember to port scan from outside of your firewall to get an accurate picture of what others see. Much ado has been made about whether or not Linux is truly more secure than Windows.
- Windows only suffers so many attacks because there are more Windows installations than Linux, therefore Linux would be just as vulnerable if it had as many installations
- Open source is inherently less secure because malicious hackers can find flaws more easily
- There are more security alerts for Linux than for Windows, therefore Linux is less secure than Windows
- There is a longer time between the discovery of a flaw and a patch for the flaw with Linux than with Windows
LINUX ROOTKITS
A rootkit is a collection of tools (programs) that a hacker uses to mask intrusion and obtain administrator-level access to a computer or computer network‖. Rootkits are commonly written for variations of the Unix operating systems including Linux, BSD, and SunOs, but have also been written for the Windows operating systems as well.
There are many different versions of rootkits that perform basically the same function. Well known Linux rootkits include LRK, tOrn, and Adore and some Windows Rootkits include NTROOT, NTKap, and Nullsys.
Not only are rootkits designed to hide the presence of an attacker; they are also used to gain future administrator-level (root) access, launch distributed denial of service (ddos), or obtain financial or confidential information. Because rootkits are designed to hide the presence of an attacker, it is necessary to understand how a rootkit functions. When a rootkit is installed, it overwrites many commands used on a daily basis such as ls, ps, or netstat. By overwriting such commands, the intrusion can be masked from the administrators. The following is a list of common commands that can be overwritten by a rootkit .
netstat: A useful tool used to display information about current network connections, routing tables, and interface statistics. Netstat can be altered by rootkits to hide the connections made by the intruder to and from the system.
du: A command used to display file space usage. Much like the ls command, du makes hierarchical directory tree but displays how much disk space each file or directory is using. The du command is trojaned mainly to hide files and directories installed by the rootkit.
find: Used to find files in a directory hierarchy. By altering the find command, intruders make it harder for administrators to search for known files installed by rootkits. Much like the ls and du commands, find is trojaned to hide the presence of rootkit files.
ifconfig: Used to configure and display information about network interfaces. If a sniffer is installed and running, the network interface is placed in promiscuous mode. Placing an interface in promiscuous mode enables the network interface to intercept and read packets on the network. Ifconfig is most commonly altered to conceal the evidence of an interface in promiscuous mode thus hiding the presence of a sniffer or password grabber.
inetd (xinetd): A super server designed to start programs that provide Internet services. (x)inetd then spawns the appropriate server to accept the connections. Many rootkits add their applications to the configuration file causing rootkit services to be spawned when a specific port is accessed. This is done to hide the process from administrators until the attacker calls it.
killall: A command used to stop processes. Killall is trojaned in most rootkits so administrators cannot stop certain processes that have been installed by the rootkit.
login: A daemon that is used when signing onto a system. The login daemon can be modified to document all usernames and passwords typed into the system. This documented list can be saved to a directory to be accessed for later use, sent to another system, or displayed on an alternative source such as a chat server or news group.
Rootkit Prevention
Rootkit prevention as well as preventing any other type of attack starts at the basics of system security. A basic system security plan should include items such as firewalls, VPN‘s, as well as updating applications with vendor patches. By implementing basic security measures, administrators can assure a relatively secure network.
SECURITY BASICS
Firewall all networks.
It is always a good practice to make sure all networks are protected from the Internet by using a firewall. Keep in mind that a firewall is not the only preventative measure an administrator can take to deter intruders.
Know exactly what is running on all systems.
After a system is installed, take inventory of what is running. Turn off any services that are not needed. Perform periodic audits of system processes to ensure that no unauthorized applications are running.
Grant access to users that are needed to perform their jobs.
Never give a user more access to network services than he or she needs. Only grant permission to services that the user needs to perform his or her job and nothing more.
Enable secure communications such as VPNs and Secure Shell.
By implementing VPN‘s, administrators ensure that all data transmitted across Wide Area Network(s) (WAN) are encrypted. Secure Shell or SSH is an alternative to the telnet protocol. SSH encrypts all data transmitted during a session including usernames and password
Install host and network based intrusion detection systems.
Knowing what is going on within your network is very important. If an intruder tries to gain access, let your IDS application notify you.
Monitor all log files.
Monitoring log files will give administrators the upper hand since most systemactivities are logged. It is a good idea to automate this task using a log-checking program such as Logwatch or LogSentry. Monitoring log files will not notify administrators of a rootkit attack, however it will also inform them of unusual system activity such as successful and unsuccessful login attempts.
