Penetration Testing: Enumeration

penetration testingOnce you have hardened your system and network, it is always a good idea to scan, or penetration test, your own systems for weaknesses that may already exist or may develop. Changes are constantly made to production systems. In addition, malicious users are constantly discovering and exploiting new weaknesses. Penetration testing your own network will help you see potential weaknesses through the eyes of an attacker and will help you to close the holes.

During the scanning phase of penetration testing, you will begin to gather information about your network’s purpose: specifically, what ports, and possibly what services, it offers. Information gathered during this phase is traditionally also used to determine the operating system (or firmware version) of the target devices. The list of active targets gathered from the footprinting phase is used as the target list for this phase. You can specify any host within your approved ranges, but you may lose time trying to scan a system that perhaps does not exist, or may not be reachable from your network location.

Penetration Testing: The Enumeration Process

In penetration testing, enumeration is the process of listing and identifying the specific services and resources that are offered by a network. You perform enumeration by starting with a set of parameters, like an IP address range, or a specific Domain Name Service (DNS) entry, and the open ports on the system. You goal for enumeration is a list of services that are known and reachable from your source. From these services, you move further into deeper scanning, including security scanning and testing. Terms such as banner grabbing and fingerprinting fall under the category of enumeration. The most common tools associated with enumeration include nmap and amap.


An example of successful enumeration would be to start with host 10.0.0.10, and TCP port 22 open. After enumeration, you should be able to state that OpenSSH is running, and what version of OpenSSH is running along with the protocol versions. Moving into fingerprinting, ideal results would tell what version of Linux/Unix is running, and what version of the kernel is running. Often your enumeration will not get to this level of detail, but you should set that as your goal.

Keeping good notes is also important during penetration testing, and is important during this phase as well. If the tool you are using cannot output a log follow, make sure you use tools like tee, which allow you to direct the output of a command to a log file. Sometimes you may also want to know the exact flags or switches you used when you ran a tool, or what the verbose output was.

You can perform enumeration using either active or passive methods. Proxy methods may also be considered passive, as the information you gather will be from a third source, rather than intercepted from the target itself. But a truly passive scan should not involve any data being sent from the host system. Active methods are the more familiar ones in which you send certain types of packets and then receive packets in return.


Once enumeration is complete, you will have a list of targets that you will use for the next stage: scanning. You need to have specific services that are running, versions of these services, and any host or system fingerprinting that you could determine. Moving forward without this information could hamper your further efforts in exploitation.

External Links:

Penetration Testing at Wikipedia

Scanlogd: Port Detection Made Easy

scanlogdScanlogd is an open source program that detects and logs TCP-port scanning on your system. A port scan involves an attacker trying many destination ports, usually including some that turn out not to be listening. One signature that could be used for detecting port scans is “several packets to different destination ports from the same source address within a short period of time”. Another signature could be “SYN to a non-listening port”.

Scanlogd: Detecting Port Scans

Different methods of detecting hacking activity have there own advantages and disadvantages, resulting in false positives and false negatives. For example, an attacker could do a scan very slowly. Unless the target system is normally idle, it is possible to make the delay between ports large enough for the scan to be likely not recognized as a scan. In addition, the attacker can send a large amount of spoofed port scans, and only one scan from the real source address. Even if all the scans are detected and logged, there’s no way to tell which one of the source addresses is real. All we can tell is that we have been port scanned.

The goal of scanlogd is not to detect all port scans but instead to detect as many port scans as possible while still being reliable enough. Scanlogd writes one line per scan using the syslog(3) mechanism. It also logs when a source address sends many packets to several different ports in a short amount of time. Because scanlogd is only meant to detect scans, it is totally safe to run on your system. It must have access to raw IP packets to function, and can capture packets coming in and out of the system interface, or across the network to which the system is attached. In addition, scanlogd supports the raw socket interface on libnids, libpcap, and Linux.


What information do port scanners give us? We cannot trust the source address; however, other information is often available. For example, if the TTL is 255, we know the packets are coming from the local network regardless of what the source address field says. However, if the TTL is 250, we only know the attacker was no more than 5 hops away, but we don’t know exactly how far away they are. Starting TTL and source port numbers can also give us a hint as to what the port scanner type or operating system is used by the attacker. For example, nmap sets TTL to 255 and source port to 49724, while the Linux kernel sets TTL to 64.

Once an attack is recognized, the next issue is what to do about it. A typical action is to block the attacking host, by re-configuring access lists of the firewall or something similar. This, however, leads to an obvious Denial of Service (DoS) issue if the attack we are detecting is spoofable. There are also implementation issues with this approach: firewall access lists and routing tables are all of a limited size. Even before the limit is reached, there are CPU usage issues. If the firewall goes down as a result of such issues, this could lead to a DoS of the entire network.

Another common action is to connect back to the attacking host for extra information. For spoofable attacks, we might end up being used in attacking a third party, so this is not good. But for non-spoofable attacks, this might be worth implementing, with a lot of precautions. For example, we should be careful not to consume too many resources, including bandwidth and memory.

Because of the many issues involved with how to respond to a port scan, scanlogd does not do anything but log port scans, leaving the question of what to do to the administrator. What you do is a matter of your own discretion, but at the very least you should probably check system activity around the time of a port scan.


External Links:

The scanlogd home page

sudo Logging

sudo logging

Enabling sudo logging in CentOS.

As mentioned in the introduction to sudo, the sudo command logs which users run what commands. Logging does not occur automatically. You need to set up sudo and syslogd to log commands. This involves two steps. First, you must create a sudo logfile in /var/log. Second, you must configure syslog.conf to log sudo commands. To configure sudo logging, follow these steps:


  1. Log on as root. Create a sudo log file in /var/log. Enter:
    touch /var/log/sudo
  2. Next, you need to add a line in the syslog.conf file to direct logging to your sudo logging file. Open syslog.conf by entering the following:
    vi /etc/syslog.conf
  3. Enter the following line at the end of the syslog.conf file (press i to insert text). The whitespace must be created using TAB, not the SPACE BAR.
    local2.debug /var/log/sudo
  4. This syslog.conf entry logs all successful and unsuccessful sudo commands to the /var/log/sudo file. You can also log to a network host by indicating the network host instead of a local directory.
  5. Press ESC to write and quit the file, and enter wq at the colon.
  6. Since you have modified the syslog.conf file, you need to restart syslogd. To send a HUP signal to syslogd, you must first know this sylogd process identifier (PID). To find the syslogd PID, type:
    ps aux | grep syslogd
  7. The second column lists the PID number. The last column lists the process using that PID. This is the information you need to enter the appropriate kill command and restart syslogd. Type:
    kill -HUP (PID NUMBER)
  8. First, you will generate log entries for user chris. Log on as user chris.
  9. Enter the following ifconfig commands while logged on as user chris:
    sudo -lsudo /sbin/ifconfig eth0 down
    sudo /sbin/ifconfig etho up
  10. Restart one of the httpd proceesses 9or another process of your choice) using the kill command by entering:
    ps aux | grep httpd
  11. Choose an Apache (httpd) PID from the list that appears. Enter:
    sudo kill -HUP (PID NUMBER)
  12. Now list the root user directory as user chris. Enter:
    sudo ls /root
  13. Log on as root and view the sudo log file. All the sudo commands that chris entered should be listed.
  14. You can log any root commands by simply typing sudo before each command. For example, make sure that you afre logged on as root and enter the following commands:
    sudo useradd bessie
    sudo passwd bessie
    sudo vi /hosts
  15. Access and view the sudo log by entering:
    sudo cat /var/log/sudo
    All root user entries are logged, including the cat command you just entered.

Obviously, sudo is very helpful for controlling an auditing root access. It allows a system administrator to distribute root access without giving out the root password. An administrator can control what root access is needed for each user, and can customize system access based on those needs.


External Links:

Introduction to sudo at linux.com

Running sudo: Examples

using sudo

The sudo command in action under CentOS. sudo -l shows the commands user chris is allowed to run as root.

In the previous article, we configured sudo to allow user chris root privileges for the ifconfig, kill and ls commands. If chris wants to run these commands, he must first enter the sudo command, and then his password. To see if it works, do the following:

  1. Log in as user chris.
  2. To find out what commands chris has root access to, enter this:
    sudo -l
  3. If this is your first time running sudo as user chris, a warning will display:
    We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things.
    #1) Respect the privacy of others.
    #2) Think before you type.
     #3) With great power comes great responsibility.
  4. A password prompt appears. Do not enter the root password. Enter chris’s password.
  5. The commands that chris is allowed to run on this host are listed.
  6. To test your sudo configuration, you can run an ifconfig option that requires root permission without using sudo. Enter:
    /sbin/ifconfig eth0 down
    Permission is denied beceause chris is not allowed to deactivate the system’s eth0 interface.
  7. To deactivate the interface, chris must use sudo. Enter:
    sudo /sbin/ifconfig eth0 down
    You will be successful. Please note that sudo will ask for chris’s password if chris’s ticket has expired (the default is five minutes). If you run this command within five minutes from the last time, you will not be prompted for a password.
  8. Reactivate the interface by typing:
    sudo /sbin/ifconfig eth0 up
  9. Next, restart one of the httpd processes using the kill command by entering:
    ps aux | grep httpd
  10. Choose an Apache PID from the list that appears (if Apache is not installed, select a different service process to restart). Enter:
    kill -HIP (PID NUMBER)
  11. You are not allowed to restart the httpd process because you are not root.
  12. Instead, use sudo to run the command as root by entering:
    sudo kill -HUP (PID NUMBER)
    You should be successful.

  13. Next, list the root directory as chris using the ls command. Enter:
    ls /root
    Permission is denied because you are not root.
  14. Again, use sudo to run the command as root:
    sudo ls /root
    Permission is granted and the root user’s directory is displayed.
  15. To expire chris’s timestamp, enter the command sudo -k. Chris will have to enter a password the next time he uses sudo.




External Links:

ifconfig at Wikipedia
kill at Wikipedia
ls at Wikipedia

sudo: Options and Configuration

sudo configurationIn order to use sudo, the user must have already supplied a username and password. If a user attempts to run the command via sudo and that user is not in the sudoers file (at /etc/sudoers), an e-mail is automatically sent to the administrator, indicating that an unauthorized user is accessing the system.

Once a user logs in to sudo, a ticket is issued that is valid by default for five minutes. A user can update the ticket by issuing the -v falg, which will validate the ticket for another five minutes. To do this, type the following:

sudo -v

If an unauthorized user runs the -v flag, an e-mail will not be sent to the administrator. The -v flag informs the unauthorized user that they are not a valid user. If the user enters a command via sudo anyway, an e-mail will then be sent to the administrator.


sudo logs login attempts, successful and unsuccessful, to the syslog file by default. However, this can be changed during sudo configuration. sudo also has several command line options, such as the following:

  • -V: Version; prints version number and exits
  • -l: List; lists the commands that are allowed and denied by the current user
  • -h: Help; prints usage message and exits
  • -v: Validate; updates the user’s ticket for a configured amount of time (the default is five minutes). If required, the user must re-enter the user password to update the ticket
  • -k: Kill; expires the user’s ticket. Completing this option requires the user to re-enter the user password to update the ticket
  • -K: Sure kill; removes the user’s ticket entirely. User must log in with username and password after running this option
  • -u: User; runs the specific command as the username specified. The user specified can be any user except root. If you want to enter a uid, enter #uid instead of the username

Configuring sudo

To configure sudo, you must edit the /etc/sudoers file. The sudoers file defines which users are allowed to execute what commands. Only the root user is allowed to edit the file, and it must be edited with the visudo command. By default, the visudo command opens the sudoers file in the vi text editor. The vi commands are used to edit and write the file. You can change the default text editor used by visudo using the compile time option. Visudo uses the EDITOR environment variable. The visudo command performs the following tasks when editing the sudoers file:

  • Visudo will not save any changes if a syntax error exists. It will state the line number of the error and prompt you for guidance.
  • If you attempt to run visudo while the sudoers file is being edited, you will receive an error message telling you to try again at a later time.

The sudoers file consists of two different types of entries, user specifications and aliases. The following examples show you to use user specifications, which define which user is allowed to run what commands. Aliases are basically variables.


style=”display:inline-block;width:180px;height:90px”
data-ad-client=”ca-pub-8834983181171783″
data-ad-slot=”8138242896″>
//

The sudoers file contains a root entry. The user privilege specification is listed as:

root ALL=(ALL) ALL

This configuration allows the root user to issue all commands. To allow other users to run commands as root, you must enter those users in the sudoers file. You must also list the host on which they are allowed to run the commands. Finally, you must list the specific commands that those users are allowed to run as root. As an example, imagine we have a user called chris and we want to allow him to run some commands as root.

First, we open the sudoers file using the visudo command. The sudoers file will now open in vi. Locate the “User privileges specification” section. After the root entry, enter the following:

chris your-hostname = /sbin/ifconfig, /bin/kill, /bin/ls

[This will allow user chris to run the ifconfig, kill and ls commands as root. NOTE: Depending on your implementation of Linux/Unix, you may have to add your default shell to the list of commands user chris can execute as root; e.g. /bin/bash.] Press ESC, then enter wq at the to write and quit the file. Now, if you have not already, you have to create user chris. To do this, enter:

useradd chris

To create a password of user chris, enter:

passwd chris

Then enter the password when prompted. Now, you should have a user chris on your system that can run ifconfig, kill and ls as root.


External links:

The sudo project page

sudo: An Introduction

sudo

Invoking sudo at the command line in CentOS.

Superuser Do (sudo) is an open source security tool that allows an administrator to give specific users or groups the ability to run certain commands as root or as another user. Its name is a concatenation of “su” (substitute user) and “do”. Sudo is available for download from http://www.sudo.ws/sudo/download.html, but it is included with most Linux distributions. The program can also log commands and arguments entered by specified system users.

Unlike the su command, users typically supply their own password to sudo rather than the root password. The developers of sudo state the basic philosophy of the program is to give as few privileges as possible but still allow people to get their work done. After authentication, and if the /usr/local/etc/sudoers (or /etc/sudoers) configuration file permits the user access, then the system will invoke the requested command. The sudoers configuration file enables a huge amount of configurability, including, but not limited to: enabling root commands only from the invoking terminal, not requiring a password for certain commands; requiring a password per user or group; requiring re-entry of a password every time or never requiring a password at all for a particular command line. It can also be configured to permit passing arguments or multiple comments, and even supports commands with regular expressions.


Sudo was originally written by Robert Coggeshall and Cliff Spencer “around 1980” at the Department of Computer Science at SUNY/Buffalo. The current license is under active development and is maintained by OpenBSD developer Todd C. Miller distributed under a BSD-style license. Sudo’s website is http://www.sudo.ws/.

sudo Features

Here are some of the features of sudo:

  • Command logging: Commands and argument can be logged. Commands entered can be traced to the user. Ideal for system auditing.
  • Centralized logging of multiple systems: sudo can be used with the system log daemon (syslog) to log all commands to a central host.
  • Command restrictions: Each user or group of users can be limited to what commands they are allowed to enter on the system.
  • Ticketing system: The ticketing system sets a time limit by creating a ticket when a user logs on to sudo. The ticket is valid for a configurable amount of time. The default is five minutes.
  • Centralized administration of multiple systems: The sudo configurations are written to the /etc/sudoers files. The file can be used on multiple systems and allows administration from a central host. The file is designed to allow user privileges on a host-by-host basis.


Because sudo logs all commands run as root, many administrators use it instead of using the root shell. This allows them to log their own commands for troubleshooting and additional security. The ticketing system is also ideal because if the root user walks away from the system while still logged in, another user cannot then access the system simply because they have physical access to the keyboard. After the ticket expires, users must then log on to the system again. A shorter time is recommended, such as the default five minutes. The ticketing system also allows user to remove their ticket file.

To install and run sudo from the source distribution, you must have a system running Unix. Almost all versions of Unix support the sudo source distribution, including almost all flavors of POSIX, BSD, and SYSV. Sudo is known to run on: Auspex, SunOS, Solaris, ISC, RISCos, SCO, HP-UX, Ultrix, IRIX, NEXTSTEP, DEC Unix, AIX, ConvesxOS, BSD/OS, OpenBSD, Linux, UnixWare, Pyramid, ATT, SINIX, ReliantUNIX, NCR, Unicos, DG/UX, Dynix/ptx, DC-Osx, HI-UX/MPP, SVR4, NonStop-UX and MacOSX Server.

External Links:

sudo at Wikipedia

The official sudo homepage

Implementing Bastille

BastilleIn the previous article, I covered some of the features of Bastille. In this article, I will cover downloading, installing and running Bastille, and undoing changes.

Downloading Bastille

Bastille is available for free download at Sourceforge’s Bastille page. The program is offered in tarball and rpm format. It must be installed by a root user in his or her root directory. Ensure the perl/tk library installed on your system, since Bastille is a collection of Perl scripts.

The program automatically implements the administrator’s preferences based on the answers to the questions, and saves them in the /root/Bastille/config file.


If you’re using Ubuntu, you can use apt-get to install Bastille, with the following command:

sudo apt-get install bastille

Of course, if you receive an error such as WARNING: /usr/bin/perl cannot find Perl module Tk, then you need to first install the perl-tk package, with the following command:

sudo apt-get install perl

Bastille allows the same configuration to be implemented on other systems. In order to do this, administrators need to install Bastille on that machine, copy the config file and the BackEnd file to the new system’s ~/Bastille directory, and then run this command:

BastilleBackend


Installation and Configuration

To install and configure Bastille, do the following:

  1. Log in as root.
  2. Download the rpm file to your root directory.
  3. Double-click on the package icon in the GUI or use this command-line command: rpm -i Bastille-versionnum.noarch.rpm
  4. To run Bastille GUI, enter the following in the Bastille directory:,/bastille
  5. All choices you implement in Bastille are logged to the /root/Bastille/config file. It is remommended that you make a backup of the config file before running Bastille and keep a manual log.
  6. Next, the opening screen appears, identifying how to navigate through the Bastille configuration process. Select Next to access the first configuration screen.
  7. Next, Bastille leads you through a series of questions. Go through the explanation given below every question and understand the changes Bastille will perform based on your choice.
  8. Bastille will next ask you if you want to implement these changes. Select Save Configuration if you want to just save the configuration with applying any changes. Select Exit Without Saving if you want to discard the changes. Select Go Back and Change Configuration if you want to apply the changes.
  9. If you implemented password aging to 60 says, you may want to observe the changes made to the login.def file (found in the /etc directory).
  10. If you applied limits to the system resources by limiting users to 150 processes, you may want to observe the changes to the limits.conf file (found in the /etc/security directory).




Undoing Changes

If you want to undo changes made to your system by Bastille, this can be a bit tricky. At one time, all that was included with Bastille was a Perl script called Undo.pl that was designed to undo all changes except for RPM installations. This has changed, and now Bastille has an undo/revert program called RevertBastille that restores all the configuration files and other O/S state settings to exactly where they were before installing Bastille.

Of course, this will probably not be a good option if you installed Bastille a long time ago and have made a lot of changes to your system since then. For this reason, it is a good idea to keep a log of all the changes made with Bastille, so you can undo changes as needed, possibly by running through the Bastille configuration questions again and selecting different answers. Another option is to manually remove the changes by replacing each of the configuration files changed with the backup files in the Bastille directory. The backup directory is located at:

/root/Bastille/undo/backup

It should be noted that merely uninstalling Bastille will not undo the changes made by Bastille. The changes will still be written to the specific configuration files modified by Bastille, and unless you restore the original configuration files, the changes will persist.

External Links:

BastilleLinux at help.ubuntu.com

Network Hardening with Bastille

network hardeningBastille is an open source program that facilitates the network hardening of a system running Linux. It performs many of the tasks discussed in previous articles on this blog such as disabling services and ports. It eases the process of hardening a Linux system, giving you the choice of what to lock down and what not to, depending on your security requirements, and bundles many of the routine tasks done to secure a Linux system into a single package.

Bastille is powerful and can save administrators time from configuring each individual file and program throughout the operating system. Bastille is a set of Perl scripts that run as an interactive program, and instead of configuring files and programs individually, in Bastille the administrator answers a series of “Yes” and “No” questions through an interactive GUI. The program automatically implements the administrator’s preferences based on their answer to the questions, thus streamlining the network hardening process.


Bastille is written specifically for Red Hat Linux and Mandrake Linux, but it can easily be modified to run on most Unixoid systems. The specific Red Hat/Mandrake content has been generalized, and now the formerly hard-coded filenames are represented as variables. These variables are set automatically at runtime. Before you install Bastille on your system, you will want to ensure your Linux version is supported by Bastille. It is known to work with Red Hat, Fedora, SUSE, Debian, Ubuntu, Gentoo, and Mandriva, as well as HP-UX.


Network Hardening with Bastille: Features

More information about each of Bastille’s features is available when the program is run, but here is an overview of the main network hardening features of the program:

  • Apply restrictive permissions on administrator utilities: This allows only the root to read and execute common admin utilities such as ifconfig, linux-conf, ping, traceroute, and runlevel. It also disables the SUID root status for these programs.
  • Disable r-protocols: The r-protocols allow users to log on to remote systems using IP-based authentication. This authentication is based on the IP address, so a hacker could easily create spoofed packets that appear to be from the authorized system.
  • Disable CTRL-ALT-DELETE rebooting: This disallows rebooting the machine by this method.
  • Optimize TCP Wrappers: This choice modifies the inetd.conf and /etc/hosts.allow file so that whenever inetd gets a request, it has to contact TCP Wrappers, which will determine if the requesting IP address is allowed to run the service.
  • Limit system resource usage: If you limit system resource usage, you improve network hardening can reduce the chances of a denial-of-service (DoS) attack. If you limit system resource usage, the following changes will occur:
    • Individual file size is limited to 40 MB.
    • Each individual user is limited to 150 processes.
    • The allowable core files number is configured to zero. Core files are used for system troubleshooting, and can be exploited by hackers if the gain control of them.
  • Restrict console access: Bastille can specify which user accounts are allowed to log on via the console.
  • Additional and remote logging: Enables the admin to add two additional logs to /var/log: /var/log/kernel (for kernel messages) and /var/log/syslog (for error and warning severity messages)
  • Process accounting setup: Allows you to log the commands of all users.
  • Deactivate NFS and Samba: NFS (Network File System) and Samba are services for accessing files from Linux systems on remote systems. Unless the firewall is configured to block the packets or the admin secures these services, Bastille recommends deactivating these services.
  • Harden Apache web server: httpd should be disabled if the service is not required. If Apache is being run, there are also ways of enabling Apache in a manner that ensures maximal network hardening.




Implementing this policy goes a long way towards achieving network hardening. In the next article, we will take a look at the process of implementing Bastille.

External Links:

The official Bastille web site

How to Harden Your Linux Server’s Security with Bastille on www.unixmen.com

Hardening your systems with Bastille Linux at linux.com

Port Blocking in Linux

port blockingIn the previous article, I covered the network security benefit of disabling unused services. In this article, I will cover the concept of port blocking, and how it can be done under Linux.

TCP/IP networks assign a port to each service: e.g. HTTP, Simple Mail Transfer Protocol (SMTP), Telnet, FTP, and Post Office Protocol version 3 (POP3). This port is given a number, called a port number, used to link incoming data to the correct service. For example, if a client browser is requesting to view a server’s web page, the request will be directed to port 80 on the server. If the client starts an FTP session, the request will be directed to port 21. The web service receive the request and sends the web page to the client. Each service is assigned a port number, and each port number has a TCP and UDP port. For example, port 137 is used for the NetBIOS name service and has a TCP and a UDP port, with NetBIOS over TCP usually using UDP port 137 (TCP port 137 can be used, but rarely is).

There are two types of ports used for TCP/IP networks: well-known ports and registered ports. The well-known ports are the network services that have been assigned a specific port number (as defined by /etc/services). For example, SSH is assigned port 22, and HTTP is assigned port 80. Servers listen on the network for the requests of well-known ports. Registered ports are temporary ports, usually used by clients, and that will vary each time a service is used. You can also call registered ports ephemeral ports, because they only last for a brief time.

Port Blocking: Determining Which Ports to Block

When determining which ports to block on your server, you must first determine which services you need. In most cases, you can block all ports that are not exclusively required by those services. This is a bit tricky, because in implementing port blocking, you can easily block yourself from services you need, especially services that use ephemeral ports, as explained earlier.


For example, if your server is an exclusive FTP server, you can block all TCP ports except ports 20 and 21, respectively. If your server is an exclusive HTTP server, you can block all ports except TCP port 80. In the case of the FTP server, you can block all UDP ports except port 20, since FTP requires UDP port 20 to be open. If you use the system as an HTTP server, in setting up port blocking you can block all UDP ports, since HTTP uses TCP services exclusively.

However, if you want to use your server as an HTTP client, or as an e-mail client or an e-mail client to a remote mail server, you will restrict the system by doing this. Clients require registered UDP ports for DNS, as well as registered TCP ports for establishing connections with web servers.




If you, for example, try to download an operating system update, and you have only opened UDP port 20, DNS requests will be blocked because DNS queries use port 53. Even if you open port 53, a different registered port may be assigned each time for the answer. In this situation, the best policy may be to open all TCP/UDP registered ports, or set up port blocking to block all of them, and download operating system updates from another computer.

Port Blocking in Red Hat and Other Linux Distros

To utilize port blocking for TCP/UDP services in Linux, you must disable the service that uses the specific port. You may use the GUI interfaces of firewall services offered by most of the Linux distros. In Red Hat Enterprise Linux (RHEL) 5, this is achieved by navigating to System -> Administration -> Security Level and Firewall, which opens up the firewall configuration utility. To allow a service to run, just check and enable the service and to block, uncheck the service. If you want to add any non-standard port or a custom port to be allowed by the firewall, then click on Other ports and add the protocol type (TCP or UDP) and add the port number.

If you don’t use RHEL, don’t despair. Regardless of which version of Linux you use, iptables is the Linux kernel firewall, and rules can be added or deleted at the command line. For example, to set the default chain policy to block, type this:

iptables -P INPUT DROP

Once you do this, you can complete your port blocking setup by selectively enable ports. For example, to allow all incoming SSH connections on eth0, type:

iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp –sport 22 -m state –state ESTABLISHED -j ACCEPT

You may, however, opt to use a frontend to iptables to implement port blocking. Shorewall is one such frontend, and its creators call it “iptables made easy”. If you use Ubuntu, the default firewall configuration tool is ufw (Uncomplicated Firewall), and it simplifies the process of using iptables. To enable ufw, type:

sudo ufw enable

The default parameter allows us to set the default policy. Let’s assume we want set the default policy to block all incoming traffic. We would type:

sudo ufw default deny in

Here, “deny” is the policy (the choices are allow, deny, or reject), and “in” indicates the direction in which traffic is blocked (choices are in or out). Since “in” is the direction the rule applies to by default, we could have just typed:

sudo ufw default deny

If we wanted to allow incoming traffic on port 80, we would type:

sudo ufw allow in to any port 80

There’s much more to ufw than what I present here, so I advise reading the documentation (especially the man page) for more information on port blocking. However, one important parameter for ufw that should be mentioned is –dry-run. When this command is invoked, ufw won’t modify anything, but will just show the changes.


External Links:

iptables at Wikipedia

Shorewall homepage

ufw manpage

Firewall at help.ubuntu.com

25 Most Frequently Used Linux IPTables Rules Examples

Network Security: Disabling Services

network securityI thought it might be a good idea to do a series of articles on network security, and to kick it off I’m going to cover disabling unnecessary services. This article assumes your network is running Linux, at least for services.

As a Linux administrator you will want to know and define the following elements:

  • The role of the server (web, database, proxy, etc.)
  • Services that are required to perform a specific server role (e.g. Apache)
  • Ports required to be opened (e.g. port 80 for HTTP)

All the other services should be disabled and all other ports should be closed. When these tasks are performed, the server becomes a specialized server to play only the designated role.


To ensure network security by hardening a server, you must first disable any unnecessary services and ports. The process involves removing any unnecessary services, such as rlogin, and locking down unnecessary Transmission Control Protocol or User Datagram Protocol (TCP/UDP) ports. Once these services and ports are secure, you must then regularly maintain the system.

Network Security: Controlling Services

Different Linux distributions have different front ends to control services. For example, in Red Hat Linux, you can enable and disable services by navigating to System -> Administration -> Services and opening the Service Configuration utility. From there, you may select or deselect the services, start, stop or restart them and edit the run level of individual services. Although most modern Linux distros have enhanced their GUIs to cover most of the administrative tasks, it is important for admins to know how to perform the tasks without a GUI.

Linux has greater network security than most operating systems; even so, the Linux kernel is being constantly updated and there are undoubtedly many security vulnerabilities that have not yet been discovered. Most Linux services are not vulnerable to this exploits; however, an administrator can reduce the risk by removing unnecessary services. Virtually every Linux distribution includes many services, so it makes sense that administrators customize the system to meet their or their company’s needs, as removing unnecessary services also removes risk and thus improves network security.




No matter what distribution of Linux you are using, the /etc/inetd.d or /etc/xinetd.d directory (for some newer releases, including Red Hat). This is the default configuration file for the inetd (or xinetd) daemon. This files in this directory enable you to specify the daemons to start by default and supply the arguments that correspond to the desired style of functioning for each daemon. It controls many services, include File Transfer Protocol (FTP) and Telnet. It determines what services are available to the system what services are available to the system. inetd or xinetd is a super server listening for incoming network activity for a range of services. It determines the actual nature of the service being requested and launches the appropriate server.

The /etc/inetd.conf (or /etc/xinetd.conf) directs requests for services to the /etc/inetd.d (or /etc/xinetd.d) directory. Each service has a configuration in this directory. If a service is commented out in its specified configuration file, the service is unavailable. Because inetd/xinted is so powerful, for optimal network security only the root should be able to configure its services.

Network Security: Disabling Telnet, FTP and rlogin

While most admins find in convenient to log in remotely their Linux/Unix machines over a network for administrative purposes, in a high-network security environment, only physical access may be permitted for administering a server. In this case, you should disable the Telnet interactive login utility. Because of security vulnerabilities in FTP, you should disable it as well, and use SFTP (Secure FTP) if necessary. To accomplish these two objectives, do the following:

  • Edit the /etc/inetd.d/telnet (or xinetd.d/telnet) file by opening the file, using vi or the editor of your choice
  • Comment out the service telnet line by adding a number sign (#) before service telnet
  • Write and quit the file
  • Restart inetd or xinetd by entering:
    /etc/rc.d/init.d/inetd restart
    or for xinetd:
    /etc/rc.d/xinit.d/xinetd restart
  • Attempt to log onto the system using Telnet. You should fail.
  • Diable the FTP service using the same method.
  • Attempt to access the system via FTP. You should fail.

The remote login (rlogin) service is enabled by default in the /etc/inetd.d/rlogin (or /etc/xinetd.d/rlogin) file. Rlogin has security vulnerabilities because it can bypass the password prompts to access a system remotely. There are two services associated with rlogin: login and RSH (remote shell). To disable these services you have to open the rlogin file and comment out the service login line, and then open the rsh file and comment out the service shell line. Restart xinetd to ensure your system is no longer offering these services. Disabling these three services will go a long way towards improving network security on your Linux server.


External links:

inetd at Wikipedia

© 2013 David Zientara. All rights reserved. Privacy Policy