Fedora Core 6 No More

As of this last Friday, December 7th Fedora Core 6 is no more. With it goes the last release the Fedora Project had seen the split between “Community” (Extras) and Red Hat sponsored (Core). Those not intimately involved in Fedora might be interested to learn that when the merge happened it was the core packages that ended up having to follow the former “Extras” packaging guidelines and not the other way around. Yet another testament to the power of community.

Fedora often takes a bit of flack over not maintaining a longer release / support cycle. I think the main reason for this is simply because it allows Fedora to take bigger risks then any other operating system out there. By releasing often (now every 6 months) we can take any number of large risks. The worst case is having to fix it during the next release in 6 months, the best case is we integrate yet another killer technology before anyone else. Having been involved in Fedora for about 2 years I can say, 6 months is not very long.

At the same time not having to worry about updates for very long (current release + 1 release + 1 month) allows our developers to be more focused on innovation. Other groups and businesses are taking note of this as well as they integrate software into Fedora. It has become the perfect platform for a company to present new software to the world. Our setup allows us to be incredibly dynamic.

I think it’s best not to think of Fedora as a stand alone distribution but rather as part of a family of Red Hat compatible products. I mean that in terms of the technical specifications, not Red Hat the company. When Fedora is combined with RHEL and CentOS that family can fit into just about any market imaginable and I think that’s the key to the success of each of these distributions.

Fedora 9 is on the horizon and the recently announced FUDCon will be even more exciting then the last one. Those interested in helping just check out: http://fedoraproject.org/join-fedora

Disable ping responses from the system

To configure a Linux system to not respond to a ICMP (ping), run the following
command as the root user.


echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all


To make the changes persistent across reboots, add the following line to
your /etc/sysctl.conf file.


# Ignore all to ICMP (ping)
net.ipv4.icmp_echo_ignore_all = 1

log the iptables messages to a different log file

In this example, we will create a new logfile within the /var/log directory called iptables.

Make a backup of /etc/syslog.conf before making any changes to it.

# cp /etc/syslog.conf /etc/syslog.conf.bak

Edit /etc/syslog.conf with an editor such as vi and add lines:

# comment iptables log
kern.warning   /var/log/iptables

Make sure the iptables rule is logging at the appropriate level.

This can be done by using the �log-level switch. Default log-level is warning.

This example will log ssh attempts:

# iptables -I INPUT -p tcp - - dport 22 -j LOG �log-level 4

Log Levels can be found using command:

$ man syslog.conf

Log Levels
0  emerg or panic
1  alert
2  crit
3  err or error
4  warn or warning

Note: Consider adding a prefix to your iptables rule. This makes it easier to separate the firewall message from the few random messages that the kernel puts out.

This example will log ping and add the prefix "#### Firewall ####".

# iptables -I INPUT -p icmp �icmp-type ping -j LOG �log-prefix ' #### Firewall #### '

Verify which ports are listening

After configuring network services, it is important to pay attention to which ports are actually listening on the system's network interfaces. Any open ports can be evidence of an intrusion.

There are two basic approaches for listing the ports that are listening on the network. The less reliable approach is to query the network stack by typing commands such as netstat -an or lsof -i. This method is less reliable since these programs do not connect to the machine from the network, but rather check to see what is running on the system. For this reason, these applications are frequent targets for replacement by attackers. In this way, crackers attempt to cover their tracks if they open unauthorized network ports.

A more reliable way to check which ports are listening on the network is to use a port scanner such as nmap .

The following command issued from the console determines which ports are listening for TCP connections from the network:

nmap -sT -O localhost

The output of this command looks like the following:

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on localhost.localdomain (127.0.0.1):
(The 1596 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
111/tcp open sunrpc
515/tcp open printer
834/tcp open unknown
6000/tcp open X11
Remote OS guesses: Linux Kernel 2.4.0 or Gentoo 1.2 Linux 2.4.19 rc1-rc7)
Nmap run completed -- 1 IP address (1 host up) scanned in 5 seconds

This output shows the system is running portmap due to the presence of the sunrpc service. However, there is also a mystery service on port 834. To check if the port is associated with the official list of known services, type:

cat /etc/services | grep 834

This command returns no output. This indicates that while the port is in the reserved range (meaning 0 through 1023) and requires root access to open, it is not associated with a known service.

Next, check for information about the port using netstat or lsof. To check for port 834 using netstat, use the following command:

netstat -anp | grep 834

The command returns the following output:

tcp      0        0  0.0.0.0:834          0.0.0.0:*        LISTEN     653/ypbind

The presence of the open port in netstat is reassuring because a cracker opening a port surreptitiously on a hacked system would likely not allow it to be revealed through this command. Also, the [p] option reveals the process id (PID) of the service which opened the port. In this case the open port belongs to ypbind (NIS), which is an RPC service handled in conjunction with the portmap service.

The lsof command reveals similar information since it is also capable of linking open ports to services:

lsof -i | grep 834

Below is the relevant portion of the output for this command:

ypbind 653 0 7u IPv4 1319 TCP *:834 (LISTEN)
ypbind 655 0 7u IPv4 1319 TCP *:834 (LISTEN)
ypbind 656 0 7u IPv4 1319 TCP *:834 (LISTEN)
ypbind 657 0 7u IPv4 1319 TCP *:834 (LISTEN)

These tools reveal a great deal about the status of the services running on a machine. These tools are flexible and can provide a wealth of information about network services and configuration. Consulting the man pages for lsof, netstat, nmap, and services is therefore highly recommended.

specify a range of IP addresses or ports using iptables

To specify a range of IP addresses or ports, use a dash. When using IP addresses and ports in conjunction, use a colon to separate. For example:

IP-IP:Port-Port

IP address ranges are only valid in the nat table, using the options --to-source and --to-destination. When a range is given, a simple round-robin (one after another in cycle) takes place between these adresses.

For example, when using NAT you can map to a range of possible IP addresses with:

# iptables -t nat -A POSTROUTING -j SNAT --to-source 1.2.3.45-1.2.3.55

and you can map to a range of possible ports with:

# iptables -t nat -A POSTROUTING -j SNAT --to-source 1.2.3.45:1234-1334

Features and benefits of using SSH

SSH™ - (or Secure SHell) is a protocol which facilitates secure communications between two systems using a client/server architecture and allowing users to log into server host systems remotely. But unlike other remote communication protocols such as FTP or Telnet, SSH encrypts the login session, making it impossible for intruders to collect unencrypted passwords.

SSH is designed to replace older, less secure terminal applications used to log into remote hosts, such as telnet or rsh. A related program called scp replaces older programs designed to copy files between hosts, such as rcp. Because these older applications do not encrypt passwords transmitted between the client and the server, avoid them whenever possible. Using secure methods to log into remote systems decreases the risks for both the client system and the remote host.

Features of SSH

The SSH protocol provides the following safeguards:

• After an initial connection, the client can verify that it is connecting to the same server it had connected to previously.
• The client transmits its authentication information to the server using strong, 128-bit encryption.
• All data sent and received during a session is transferred using 128-bit encryption, making intercepted transmissions extremely difficult to decrypt and read.
• The client can forward X111 applications from the server. This technique, called X11 forwarding, provides a secure means to use graphical applications over a network.

  Note: X11 refers to the X11R6 windowing display system, traditionally referred to as the X Window System or X. Red Hat Enterprise Linux includes XFree86, an open source X Window System.

Because the SSH protocol encrypts everything it sends and receives, it can be used to secure otherwise insecure protocols. Using a technique called port forwarding, an SSH server can become a conduit to secure otherwise insecure protocols, like POP, and increasing overall system and data security.

Red Hat Enterprise Linux includes the general OpenSSH package (openssh) as well as the OpenSSH server (openssh-server) and client (openssh-clients) packages. Refer to the chapter titled OpenSSH in the Red Hat Enterprise Linux System Administration Guide for instructions on installing and deploying OpenSSH. Also note that the OpenSSH packages require the OpenSSL package (openssl) which installs several important cryptographic libraries, enabling OpenSSH to provide encrypted communications.

Why Use SSH?

Nefarious computer users have a variety of tools at their disposal enabling them to disrupt, intercept, and re-route network traffic in an effort to gain access to a system. In general terms, these threats can be categorized as follows:

• Interception of communication between two systems - In this scenario, the attacker can be somewhere on the network between the communicating entities, copying any information passed between them. The attacker may intercept and keep the information, or alter the information and send it on to the intended recipient.

  This attack can be mounted through the use of a packet sniffer - a common network utility.

• Impersonation of a particular host - Using this strategy, an attacker's system is configured to pose as the intended recipient of a transmission. If this strategy works, the user's system will remain unaware that it is communicating with the wrong host.

This attack can be mounted through techniques known as DNS poisoning or IP spooling.

Note:

DNS poisoning occurs when an intruder cracks a DNS server, pointing client systems to a maliciously duplicated host.

IP spoofing occurs when an intruder sends network packets which falsely appear to be from a trusted host on the network.

Both techniques intercept potentially sensitive information, and if the interception is made for hostile reasons, the results can be disastrous.

If SSH is used for remote shell login and file copying, these security threats can be greatly diminished. This is because the SSH client and server use digital signatures to verify their identity. Additionally, all communication between the client and server systems is encrypted. Attempts to spoof the identity of either side of a communication will not work, since each packet is encrypted using a key known only by the local and remote systems.

Pluggable Authentication Modules (PAM)

Programs which grant users access to a system verify each user's identity through a process called authentication. Historically, each such program had its own way of performing the task of authentication. Under Red Hat Enterprise Linux, many such programs are configured to use a centralized authentication mechanism called Pluggable Authentication Modules or PAM.

PAM uses a pluggable, modular architecture, which affords the system administrator a great deal of flexibility in setting authentication policies for the system.

In most situations, the default PAM configuration file for a PAM-aware application is sufficient. However, sometimes it may become necessary to edit a PAM configuration file. Because misconfiguration of PAM can compromise system security, it is important to understand the structure of these files before making any modifications.

Advantages of PAM

PAM offers the following advantages:

• It provides a common authentication scheme that can be used with a wide variety of applications.
• It allows a large amount of flexibility and control over authentication for both system administrators and application developers.
• It allows application developers to develop programs without creating their own authentication scheme.