Miscellaneous Linux Topics

Miscellaneous Linux Topics

Introduction

From upgrades to headless operation to emulation - some topics, no matter how important, refuse to fit neatly into any one chapter. This appendix serves as a reference center for some of these need-to-know items.

Linux Security With TCP Wrappers

The TCP Wrappers package is installed by default on Fedora Linux and provides host-based security separate from that provided by a firewall running on the server itself or elsewhere.

The application relies on two main files:

/etc/hosts.allow: Defines the hosts and networks allowed to connect to the server. The TCP Wrappers enabled application searches this file for a matching entry, and if it finds one, then the connection is allowed.

/etc/hosts.deny: Defines the hosts and networks prohibited from connecting to the server. If a match is found in this file, the connection is denied. No match means the connection proceeds normally.

The /etc/hosts.allow file is always read first and both files are always read from top to bottom, therefore the ordering of the entries is important.

The TCP Wrappers File Format

The format of the file is as follows:

<TCP-daemon-name> <client-list>  : <option>

This example allows all traffic from the 192.168.1.0/24 and the 192.168.2.0/255.255.255.0 networks and SSH from only two hosts, 172.16.1.1 and 216.10.119.244. All HTTP Web traffic is allowed. All other TCP traffic to the host is denied. Notice how the subnet masks can use the slash nomenclature or the dotted decimal 255.255.255.0 format.

# File: hosts.allow

ALL: 192.168.1.0/24 192.168.2.0/255.255.255.0

sshd:  172.16.1.1 216.10.119.244

httpd: ALL

# File: hosts.deny

ALL: ALL

Determining the TCP Daemon's Name

The easiest way of determining the name of a daemon is to use the ps command and then use grep to filter for the name of the service. Here, the example quickly determines the daemon name (/usr/sbin/sshd) for the SSH server process. Because TCP Wrappers only requires the program name and not the path, sshd therefore becomes the entry to place in the TCP-daemon-name column of the configuration file.

[root@bigboy tmp]# ps -ef | grep -i ssh

root 10053 � 1 0 Nov06 ? 00:00:00 /usr/sbin/sshd

root 14145 10053 0 Nov13 ? 00:00:02 sshd: root@pts/1

root 18100 14148 0 21:56 pts/1 00:00:00 grep ssh

[root@bigboy tmp]#

Additional TCP Wrappers Help

For a full explanation of all the options available, refer to section 5 of the man pages for hosts_access.

[root@bigboy tmp]# man 5 hosts_access

TCP wrappers is simple to implement, but you have to set them on every host. Management is usually easier on a firewall that protects the entire network.

Adjusting Kernel Parameters

Unlike many Linux applications that need to be restarted before their configuration parameters are read, many of the Linux kernel's parameters can be instantaneously activated and deactivated.

The Linux kernel stores many of its dynamic parameters in the /proc filesystem, which resides on a virtual RAM disk in memory for maximum performance.

Parameters are generally categorized by function within subdirectories of the /proc; information on IDE hard drives are located in the /proc/ide directory, for example, and general system parameters are located in the /proc/sys directory.

System parameters are held within files with names that mimic their function. For example, a Linux system can become a rudimentary router if the IP forwarding networking parameter is set to 1, not 0. Networking parameters for IPv4 addressing schemes are located in the /proc/sys/net/ipv4/. The file that covers IP forwarding is named ip_forward and contains a single byte: 1 when it's active or 0 when it's not.

You can update these files by redirecting the output of the echo command to overwrite the file contents using the > redirection character. This line activates IP forwarding by overwriting the contents of the ip_forward file with the value 1.

[root@bigboy tmp] echo 1 > /proc/sys/net/ipv4/ip_forward

There are some disadvantages to doing this. It is not a permanent solution, and the system will revert back to its defaults after the next reboot. You can overcome this by adding the echo commands to the /etc/rc.local script that runs at the end of each reboot. This too has its disadvantages; it is the very last script to be run so if your parameters need to be set earlier, as most kernel parameters should be, it isn't a suitable solution.

Linux has a more elegant solution called the /etc/sysctl.conf file. It is a list of all the /proc filesystem files the systems administrator wants to customize and the values they should contain. The file has two columns, the first is the filename relative to the /proc/sys directory, and the second is the value the file should contain separated by an equals sign. You can also replace the slashes in the filename with periods. Continuing with the example, you can set the /proc/sys/net/ipv4/ip_forward file with a value of 1 using either of these configurations.

# Sample /etc/sysctl.conf file

# Activate IP forwarding

net.ipv4.ip_forward = 1

# Activate IP forwarding too!

net/ipv4/ip_forward = 1

Editing the /etc/sysctl.conf file isn't enough, because the update isn't instantaneous. You have to force Linux to reread the file and reset the kernel parameters using the sysctl -p command. In the example, the /proc/sys/net/ipv4/ip_forward file had a value of 0 until the sysctl command ran, after which time, IP forwarding was activated.

[root@bigboy tmp]# cat /proc/sys/net/ipv4/ip_forward

[root@bigboy tmp]# sysctl -p

net.ipv4.ip_forward = 1

net.ipv4.conf.default.rp_filter = 1

kernel.sysrq = 0

kernel.core_uses_pid = 1

[root@bigboy tmp]# cat /proc/sys/net/ipv4/ip_forward

[root@bigboy tmp]#

The use of the /etc/sysctl.conf is important in day to day administration.

Running Linux Without A Monitor

You can reduce the cost of ownership of your Linux system by not using a VGA monitor. This creates what is also known as a headless system. Operating costs may not be important at home, but will be in a corporate environment with large numbers of Linux servers racked in data centers. In such cases, access to the Linux box can be more cheaply provided via the COM port.

I've included this section, largely because I have occasionally hosted the Web site www.linuxhomenetworking.com at friends' homes and felt badly about borrowing their monitors. Having access via the COM ports has also helped me in both the home and business situations. The most common occurrence is when the system is hung, locking out network access, and I need to get to it by using:

A notebook PC with a console cable connected to the COM port

A modem connected to the COM port

Telnet to log in to a terminal server that has one of its ports connected to the Linux box's COM port

Preparing To Go 'Headless'

One of the advantages of this method is that you don't need a keyboard either. Unfortunately, your BIOS may halt the system during the Power On Self Test (POST) if it doesn't detect a keyboard. Make sure you disable this feature in the BIOS setup of your PC before proceeding. You can usually find the POST feature on the very first screen under the Halt On option.

You also need to make sure that you have activated your COM ports in your BIOS settings.

For connectivity that doesn�t involve modems (PC to PC) connect a null modem cable to the COM port you want to test, connect the other end to the client PC running Hyperterm or whatever terminal emulation software you are using. One popular Linux equivalent to Hyperterm is minicom.

If you're using a modem for connectivity, then you'll need a full modem cable and you'll have to test via a dial up connection.

Configuration Steps

In RedHat/Fedora Linux, the COM1 and COM2 ports are controlled by a program called agetty, but agetty usually isn't activated when you boot up unless its configuration file /etc/inittab is modified. In other versions of Linux, agetty may be called just plain getty. Table I.1 lists the physical ports to their equivalent Linux device names.

Table I.1 How Physical COM Ports Map To Linux TTYS Devices

You can determine whether you have valid serial ports using the setserial command. In this case we are looking for all available ports between ttyS0 to ttyS7. You can see we only have two valid selections, ttyS0 and ttyS1.

[root@bigboy tmp]# setserial -g /dev/ttyS[01234567]

/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4

/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3

/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4

/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3

[root@bigboy tmp]#

To configure both valid COM ports for terminal access, add these lines to /etc/inittab:

# Run COM1 and COM2 gettys in standard runlevels

S0:235:respawn:/sbin/agetty -L 9600 ttyS0 vt102

S1:235:respawn:/sbin/agetty -L 9600 ttyS1 vt102

What do these lines mean? At boot time, when the system enters runlevels 2, 3, or 5, agetty must attach itself to devices ttyS0 and ttyS1 and emulate a VT102 terminal running at 9600 baud. The -L means ignore modem control signals, this option should be omitted if you are connecting the port to a modem. The respawn lines mean that agetty will restart automatically if, for whatever reason, it dies.

The next step is to restart the init process to re-read /etc/inittab:

[root@bigboy tmp]# init q

You'll be able to verify the activation of agetty process by querying the process table using the ps command.

[root@bigboy tmp]# ps -ef | grep agetty

root 958 1 0 Dec13 ttyS0 00:00:00 /sbin/agetty -L 9600 ttyS0 vt100

root 1427 1 0 Dec13 ttyS1 00:00:00 /sbin/agetty -L 9600 ttyS0 vt100

[root@bigboy tmp]#

Now you need to configure the terminal client (Hyperterm) to match the speed settings in /etc/inittab. Connect the console/modem cable between the client and your Linux box. Press Enter a couple times, and celebrate when you see something like this:

Red Hat Linux release 8.0 (Psyche)

Kernel 2.4.18-14 on an i586

bigboy login:

Note: By default, user root will not be able to log in from a terminal. To do this, you'll have to edit the /etc/securetty file, which contains the device names of TTY lines on which root is allowed to login. Just add ttyS0 and ttyS1 to the list if you need this access.

Switching Your Console to the Serial Port

By configuring the options in your /etc/grub.conf file you can redirect console output to one of your newly configured serial ports. This will allow you to see all of the bootup and shutdown messages on this new serial terminal port. In this example, the /dev/ttyS1 port has been configured to become the new console. The text to add to the file is highlighted in red:

default=0

timeout=5

splashimage=(hd0,0)/grub/splash.xpm.gz

hiddenmenu

title Fedora (2.6.23.1-21.fc7)

root (hd0,0)

kernel /vmlinuz-2.6.23.1-21.fc7 ro root=LABEL=/ console=ttyS1,9600 rhgb quiet

initrd /initrd-2.6.23.1-21.fc7.img

title Fedora (2.6.22.9-91.fc7)

root (hd0,0)

kernel /vmlinuz-2.6.22.9-91.fc7 ro root=LABEL=/ console=ttyS1,9600 rhgb quiet

initrd /initrd-2.6.22.9-91.fc7.img

With this modification you will still be able to completely administer the system using this port, inclusive of the grub pre-boot commands, after the next reboot. Note: It is possible that the kudzu hardware detection program may not be compatible you're your non default console configuration that doesn't use your system's video adapter. If your system hangs on reboot, you may have to reset your system; break into the grub bootloader; temporarily remove the console options from the boot command line; and disable kudzu when the system fully reboots.

[root@bigboy tmp]# chkconfig kudzu off

This is an unlikely event with newer Linux versions, but you should be aware that it can happen.

Make Your Linux Box Emulate A VT100 Dumb Terminal

Dumb terminals are devices that allow you to log in to your system via the COM port. You can make your Linux box emulate a dumb terminal quite easily. Why would you want to? For example, you run Linux on a notebook and you need to use it to access a hung headless Linux server via the COM port, Or, perhaps you need to gain access to a modem connected to the COM port. This section will focus on the notebook scenario, not using Linux to dial a modem:

Configuration Steps

The most commonly used Linux terminal emulation program is minicom. It is simple to use mainly because it uses a text-based GUI. You first need to go through all the relevant steps listed in the 'Preparing to go Headless' section to ensure you have the right type of cable and correct BIOS settings.

Be warned, minicom will clash with your agetty configuration explained previously: A headless system cannot be used to access another headless system using the headless COM port. You, therefore, have to disable the agetty configuration for the port on which you wish to run minicom.

1. It is important not to have an agetty entry for the COM port you are going to use. If an entry exists, disable agetty on COM1 by commenting out the ttyS0 agetty statements in the /etc/inittab file. COM1 now handles outbound minicom connections to other systems, and other systems using minicom can use COM2 to access this system. The next phase is to restart the init process to reload the new /etc/inittab settings.

2. Edit /etc/inittab:

# Run COM1 and COM2 gettys in standard runlevels

#S0:235:respawn:/sbin/agetty -L 9600 ttyS0 vt102

S1:235:respawn:/sbin/agetty -L 9600 ttyS1 vt102

3. Restart init

[root@bigboy tmp]# init q

4. Run minicom in setup mode using the minicom -s command, which brings you to the setup menu:

[root@bigboy tmp]# minicom -s

------[configuration]-------

| Filenames and paths |

| File transfer protocols |

| Serial port setup |

| Modem and dialing |

| Screen and keyboard |

| Save setup as dfl |

| Save setup as.. |

| Exit  |

| Exit from Minicom |

5. Select the Serial Port Setup menu item. Make the speed match that of the remote headless system and make sure the correct serial COM device is chosen. Device /dev/ttyS0 is COM1 and /dev/ttyS1 is COM2. Also make sure that flow control is off.

| A - Serial Device  : /dev/ttyS0 |

| B - Lockfile Location  : /var/lock |

| C -  Callin Program  : |

| D - Callout Program  : |

| E - Bps/Par/Bits  : 9600 8N1 |

| F - Hardware Flow Control : No |

| G - Software Flow Control : No |

|

| Change which setting? |

6. Select the Modem and Dialing option and make sure the Init String and Reset String settings are blank.

7. Select the Save Setup as dfl to make this your saved default setting, and then choose Exit from Minicom.

8. Make sure the other system is correctly configured for headless operation. Connect the cables between the systems.

9. Re-enter minicom, this time without the -s.

[root@bigboy tmp]# minicom

10. Press Enter, and you should get a login prompt

Welcome to minicom 2.00.0

OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n

Compiled on Jun 23 2002, 16:41:20.

Press CTRL-A Z for help on special keys

bigboy login:

11. To exit minicom, type Ctrl-A, then Z, then X

12. Users other than root will get a 'permission denied' message if they use minicom, because the COM ports are not normally accessible to regular users. To get around this, user root can either give everyone read/write access using the chmod command or add selected trusted users to your sudo configuration.

Remember that minicom resets the privileges to the COM port each time you change the configuration with minicom -s so you may find yourself having to run chmod from time to time.

[root@bigboy tmp]# chmod o+rw /dev/ttyS0

Note: This configuration is sufficient for connection to a Cisco router, switch or PIX firewall. Just remember to use the Cisco proprietary RJ45 type console cable to connect your COM port to the network device.

VPN Terms and Methods

A virtual private network (VPN) provides security for transmission of sensitive information over unprotected networks such as the Internet. VPN relationships are established between trusted sites on the Internet making the public network appear to be virtually the same as a private network to the VPN members. VPNs, however, have their own language. Once you know the terms, you'll be ready to get to work.

Authentication: The process of ensuring that the VPN data received is both unchanged and from the expected source.

Encryption: The use of special mathematical equations to scramble the bits in a data stream, rendering the data stream unreadable to anyone who does not have access to the corresponding decryption equation. The process is usually made even harder through the use of an encryption key, which modifies the way the equations do the scrambling. Only persons with access to this key and the corresponding programs are able to recover the original data. Data encryption helps to prevent unauthorized persons from having access to the data.

IPSec: The name given to a number of data communications protocols designed to authenticate and encrypt VPN data to protect it from unauthorized viewing or modification as it is transmitted across a network.

Authentication header (AH): One of two IPSec security protocols. Provides authentication and antireplay services, without encryption, by adding its own security header to the original IP packet

Encapsulating security protocol (ESP): The other IPSec security protocol. Provides authentication, encryption, and antireplay services. It encrypts the data within the packet and then adds its own security header to the original IP packet. Because ESP headers don't authenticate the outer IP header as AH headers do, AH and an ESP are often used in combination with each other. This is called transport adjacency.

Transport mode VPN: A style of VPN in which the original source and destination address of the data sent over the VPN is unchanged. Figures I.1 and I.2 provide examples of transport mode VPN IP packets. (For more information on the IP protocol, please refer to Chapter 2, 'Introduction to Networking', which introduces networking concepts.)

Figure I.1 Transport mode AH packet format

Figure I.2 Transport mode AH / ESP packet format

Tunnel mode VPN: A style of VPN in which the original source and destination address of the data sent over the VPN is changed by encapsulating the original IP packet within another IP packet. The original packet is frequently encrypted, header and all, in an effort to provide an additional layer of security by not revealing the true identities of the servers communicating with each other. Figures I.3 and I.4 show examples of tunnel mode VPN IP packets.

Figure I.3 Tunnel mode AH packet format

Figure I.4 Tunnel mode AH / ESP packet format

Authentication and Encryption methods

IPSec data integrity is usually provided by one of two hashed message authentication code (HMAC) methods:

Message Digest 5 (MD5)

Secure Hash Algorithm (SHA-1).

IPSec usually uses one of two methods to encrypt data:

Data Encryption Standard (DES) using a 56-bit encryption key

Triple DES using a 168-bit encryption key.

Internet Key Exchange (IKE)

IKE provides authentication of the IPSec peers, negotiates IPSec security associations, and establishes IPSec keys. There are two main methods of establishing a trusted relationship between two devices that want to create a VPN between themselves.

Public Encrypted Keys

The first method is public key cryptography using RSA encryption pioneered by RSA Data Security Inc. Each VPN device has its own public and private keys. Anything encrypted with one of the keys can only be decrypted with the other. This allows you to create a signature when the message is encrypted with a sender's private key. The receiver verifies the signature by decrypting the message with the sender's public key.

A successful exchange requires the receiver to have a copy of the sender's public key and to know with a high degree of certainty that it really does belong to the sender, and not to someone pretending to be the sender. This certainty is assured using certificates and Certification Authorities.

A digital certificate contains information that identifies a user or device, such as a name, serial number, company, department, or IP address. It also contains a copy of the entity's public key. Certificates are managed and issued by Certification Authorities (CAs). A CA can either be a trusted public third party, such as VeriSign, or an in-house private server that you establish within your organization.

Prior to installing a certificate-based VPN, each VPN device must be preconfigured with the certificate generated for them by the CA. The VPN devices are also be preconfigured with the CA's certificate.

During the key exchange, the VPN peers authenticate by sending each other the certificate issued to them by the CA, but encrypted using their private key.

Each peer then uses the pre-installed CA certificate they have to authenticate with the CA and securely receive the other peer's certificate from the CA using public key cryptography.

Each peer then extracts the public key from the certificate they receive from the CA and uses it to decrypt the certificate they just received from the other peer.

Once the certificates received from the CA and the other peer match, authentication is complete.

Private Shared keys

The second method of establishing a trusted relationship is to have the devices at each end of the VPN use a shared key or password. The disadvantage is that each pair of VPN connections needs set of keys, making it difficult for large scale implementations. Unlike the RSA method, there is no CA to provide an impartial audit trail of VPN connection initiations.

IKE's role in creating Security Associations

Once authentication is complete, the VPN peers use IKE to negotiate the security associations (SAs) to be used at each end point. IKE, in turn, uses special ISAKMP IP packets using IP protocol 50 to establish a security association. SAs are comprised of transforms and shared keys. Transforms describe how the data will be transformed by the VPN and between which pre-defined networks at each end of the tunnel to provide the desired security, for example:

Packet encryption methods

Packet authentication methods

Transport versus tunnel mode

AH and or ESP usage

SA lifetime before it is renegotiated. (SAs are permanent for when manually established)

Shared keys are the actual keywords used by the encryption and authentication processes to protect the data.

VPN Security And Firewalls

All security devices in the path of a VPN connection have to allow IP protocol 50 between the two VPN devices to ensure that IKE works properly.

VPNs also use a separate channel through which the encrypted data passes as UDP packets through port 500. Unusually, the source and destination port is 500.

For the VPN to function correctly these protocols must also be allowed to pass through unimpeded. In certificate based VPNs, you may have to open up these ports and protocols to the CA as well.

Note: VPN tunnels frequently don't operate correctly if they have to pass through a firewall that uses NAT. They will tend to work if the NAT firewall is the termination point of the VPN.

VPN User Authentication Methods For Temporary Connections

The discussion so far has been slanted towards a permanent connection between purpose built VPN devices. Frequently, however, the device at the other end of the connection is a PC. Table I.2 shows some authentication methods used in such cases.

Table I-2 Types Of Dial Up VPN Authentication

TCP/IP Packet Format

The TCP/IP packet contains an IP header followed by a TCP or UDP header followed by the TCP/UDP data as seen in Figure I.5.

Figure I.5

Tables I.3 through I.5 show the general format of the various TCP/IP header fields you may encounter.

Table I.3 Contents Of The IP Header

Table I.4 Contents Of The TCP Header

Table I.5 Contents Of The UDP Header

ICMP Codes

You'll also encounter ICMP codes in your troubleshooting exercises, especially when viewing your iptables log files. Table I.6 lists the most commonly used codes.

Table I-6 ICMP Codes