Network Security


Virtually all Fedora Core 2 systems will be connected to other computers via a network at some time. This may be a permanent connection through a network adapter to a local area network (LAN), an always on connection to the Internet, or a dial-up connection to an Internet service provider that is active only when required. Whatever the connection, you need to make sure that a hacker cannot use it to gain access to your system, or mount a denial-of-service attack that prevents legitimate use of your computing resources. This section looks at some of the techniques that you can use to secure your system and make life hard for the potential hacker.

Unless you are connected to an isolated network where every machine is secure and trusted, you must assume that all the information you send and receive across the network can be intercepted by a third party (someone other than you and the intended recipient of the information).

Network Services

One way a hacker may try to gain unauthorized access to your system is by exploiting weaknesses in the network services that you are running on your Fedora Core system. These are programs ”often run in the background with no controlling terminal (called daemons in UNIX, and services in Microsoft Windows) ”that provide services to other computers. Examples include file transfer protocol (FTP), Web, Network File System (NFS), and print servers.

Enabling and Disabling Services

The first and easiest way of reducing your vulnerability is to disable all the services that you don t need. In particular, you need to be very careful about older services that send sensitive information (such as usernames and passwords) across the network without any form of encryption (in plain text). Also, services that gratuitously hand out information about your system should be avoided where possible.

The following table will help you to decide which services you need to run.

Service

TCP/UDP Port Number

Description

Fedora Package

Security Level

Run It?

Echo

7

Sends received characters back to sender.

xinted

None

No (unless you really need to debug remote terminal

Daytime

13

Sends current data and time as ASCII string back to sender.

xinetd

None

No. Use NTP for time synchronization. It is more accurate and has better security features.

Chargen

19

Generates continuous stream of ASCII characters for testing terminals.

xinetd

None

No (unless you really need to debug remote terminal problems).

FTP

20 (data)

21 (control) Random ports > 1023

File Transfer Protocol. Transfers files between systems.

vsftp or

wu-ftp

Weak. Usernames and passwords are sent in plain text. Anonymous FTP gives access with no passwords

No. Use sftp instead.

SSH

22

Secure Shell. Allows remote system to access command shell on local machine.

openssh-server

Good. Data is encrypted and connections can be authenticated to verify identity of remote system.

Only if remote access to command line is required.

Telnet

23

Allows remote system to access command shell on local machine.

telnet-server

Weak. Usernames and passwords are sent in plain text.

No. Use ssh instead.

SMTP

25

Simple Mail Transfer Protocol. Used to transfer mail between systems.

sendmail or procmail

Weak. Mail is transferred in plain text.

Only if mail needs to be handled locally. Encrypt sensitive information before e-mailing .

Time

37

Sends current time (in seconds since 00:00 on 1st January 1970) back to sender.

xinetd

None.

No. Use NTP for time synchronization. It is more accurate and has better security features.

Finger

79

Gives information about local system or users to remote machine.

Finger-server

None.

No.

HTTP

80

Hypertext Transfer Protocol. Used by Web servers

httpd

Depends on server configuration.

Only if Web server needs to run on system.

Auth (identd)

113

Identification protocol. Allows remote system to identify user of a particular IP address.

pident

Supports DES encryption of returned information.

Only if required to access specific public services (for example, some FTP and Internet Relay Chat sites).

sftp

115

Secure File Transfer Protocol. FTP-like file transfer using SSH protocol.

openssh-server

Good. Transfers are encrypted and systems may be authenticated.

Only if file transfers are required.

NNTP

119

Network News Transfer Protocol. Used to transfer USENET news groups.

inn

Depends on configuration. server

Only if newsgroup server needs to be run on the system.

SMB (netbios)

137, 138 & 139

Server Message Block. Allows Fedora servers to interoperate with Microsoft Windows clients .

samba

Depends on configuration, but note that server Samba versions up to and including 2.2.8 have a serious security vulnerability.

Use non- vulnerable versions if interoperation with Microsoft Windows clients is required.

HTTPS

443

Secure HTTP.

httpd

Depends on server configuration.

Only if Web server needs to be run on the system.

rsh, rlogin

514

Allows remote machine to run commands or access command prompt on a local machine without supplying a password.

rsh-server

Weak. Relies on Domain Name Server (DNS) to identify remote system, so is exposed if DNS is compromised.

No.

LPD

515

Allows remote machines to send print jobs to local printers.

cups

Weak. Information is passed over the network without encryption.

Only run if your system has printers you want to share.

NFS

2049 (requires portmapper to be listening on port 111)

Network File System. Allows other machines to access filesystems remotely.

nfs- utils

Weak. Information is passed over the network without encryption.

Only use to access information that is not sensitive.

Having decided which services are required, you need to make sure they are started, and make sure that any of the undesirable services are stopped . This is done through the Red Hat Service Configuration application. As an example, we ll use the Red Hat Service Configuration application to turn off the lpd and portmapper services because our theoretical demonstration machine doesn t have any printers attached to it (so there s no point in running lpd), and we re not using NFS or NIS (so there s no point in running portmapper).

Try It Out Running the Service Configuration Application

  1. Start the Service Configuration application by choosing Main Menu>System Settings>Server Settings>Services, or typing redhat-config-services at the command prompt.

  2. If you re not logged on as root (and you shouldn t be), you ll be prompted for the root password in the dialog box shown in Figure 10-4.

    click to expand
    Figure 10-4

  3. Now the service configuration menu appears, as shown in Figure 10-5.

    click to expand
    Figure 10-5

    In the Service Configuration window, there are a few important things to note. First, the status line immediately below the toolbar icons shows you that the system is running in Runlevel 5, and that this is the runlevel that is being edited. (A runlevel is a particular state of the operating system, characterized by a set of processes that are started. If you haven t changed the system runlevel, you ll be editing the default, which is just what you want. For more information on runlevels, see the man pages for inittab and telinit . Be careful if you experiment with these because mistakes could render your system unbootable, forcing you to boot from CD-ROM to correct the problem.)

  4. If you click the name of a service, the information panels on the right of the window will show a brief description of what the service is for, together with its status.

    Note

    Not all services represented here represent external services; some are internal daemons vital for the smooth running of your computer. It s a good idea to take a moment to read through all the descriptions here and start to familiarize yourself with what s available.

  5. Scroll through the list of services, and clear the check boxes next to lpd and portmapper, as these are two services that do allow remote connections to your system and that are enabled by default, but probably aren t needed in the majority of cases.

    When you make a change to any of the services, the Save button is no longer grayed out. When you re happy with the changes you ve made, click Save to update the configuration files. Note that this does not actually start or stop any services; all it does is update configuration files so that next time the runlevel that is being edited is entered, the right services are started, and when it is being left, the right services are stopped. If you want to make the change effective immediately, highlight the service and click the Start, Stop, or Restart button on the toolbar according to what you want to do.

xinetd

You may have noticed in the table of services and their daemons presented earlier that several services (such as echo, daytime, and chargen) appear to be provided by the same service, namely xinetd . This isn t a typo ” xinetd does provide these, and it also looks after a whole lot more.

The xinetd service is an enhanced version of the standard UNIX inetd (Internet daemon) program, which manages incoming connections to many different services (it is sometimes called a super server). It is a long-running service (usually started when the system boots) that listens for incoming TCP/IP connections on ports that it has been told about in its configuration file. When a connection request arrives, xinetd checks that the connection should be allowed, and then starts the appropriate server (if required) to handle the connection. This section takes a brief look at some of the configuration options xinetd has that relate to system security.

The main configuration file of xinetd is /etc/xinetd.conf . Figure 10-6 shows the default contents of this file.

click to expand
Figure 10-6

This file simply sets up some sensible default values that apply to all services managed by xinetd (by placing them inside defaults { } ), and then tells xinetd to read configuration information from all the files in /etc/xinetd.d . The table that follows lists the meanings of the default values.

Value

Meaning

instances = 60

No more than 60 instances of each subserver will be started.

logtype = SYSLOG authpriv

Service log output is sent to syslogd using the authpriv facility (so that the output is logged to a file that can be read only by privileged users).

log_on_success = HOST PID

Logs remote host address and process ID (if there is one) when a service is started or exits.

log_on_failure = HOST

Logs remote host address when a service fails to start (with the reason for the failure).

cps = 25 30

Allows maximum connection rate of 25 connections per second (first number) and disables service for 30 seconds (second number) if this rate is exceeded.

Monitoring Services

It is useful to be able to check what services are running on your Fedora Core 2 system, especially whatports they are listening on. Before a remote machine can make a connection to your local machine, some process on your local machine has to be ready to receive network packets (listening) sent to its portnumber.

You can use a couple of tools to identify what ports are listening on your machine: netstat and nmap .

netstat

The netstat program is a multipurpose utility for reporting on all things relating to networks. You invoke it with the flags shown in the following table.

Flag

Meaning

-t

TCP

-u

UDP

-l

Port sockets in state of listening

-n

Show numeric values for hosts and ports

-p

Show process ID that owns sockets

   # netstat -nutlp   Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address  Foreign Address State  PID/Program name tcp    0   0 127.0.0.1:32769 0.0.0.0:*   LISTEN 718/xinetd tcp    0   0 0.0.0.0:6000   0.0.0.0:*   LISTEN 979/X tcp    0   0 0.0.0.0:22    0.0.0.0:*   LISTEN 704/sshd tcp    0   0 127.0.0.1:25   0.0.0.0:*   LISTEN 832/sendmail udp    0   0 0.0.0.0:68    0.0.0.0:*       772/dhclient udp    0   0 10.4.65.253:123 0.0.0.0:*       803/ntpd udp    0   0 127.0.0.1:123  0.0.0.0:*       803/ntpd udp    0   0 0.0.0.0:123   0.0.0.0:*       803/ntpd 

This lists the TCP and UDP sockets that are ready to receive incoming data (connections in the case of TCP and datagrams for UDP). You can see that this machine is listening on four TCP/IP ports, which are the numbers after the : in the Local Address column (22 for ssh, 25 for incoming mail, 6000 for X11 and 32769 for the xinetd super server). It will also accept datagrams on port 68 (DHCP client) and 123 (Network Time Protocol service).

Three TCP/IP addresses appear in this local address column: 0.0.0.0 means that the server is listening on all addresses, 127.0.0.1 is the machine s loopback address, and 10.4.65.253 is the address of the machine s Ethernet card (leased from a DHCP server).

If you leave out the “l flag, netstat shows you all the active connections. If you leave out the “n flag, netstat looks up port names in /etc/services and host names using DNS, giving symbolic output. Try varying the flags to see what information is returned.

You can check the output of the netstat command to make sure that you don t have any programs listening on TCP or UDP ports that you re not expecting. The “p flag, which gets netstat to print out the Process ID (PID) and name of the process that opened the socket, is very useful for identifying rogue programs, perhaps modified by an intruder, that are listening on unexpected ports. (Of course, if you ve got Tripwire set up and you re running regular scans , you ll quickly identify a program modified by an intruder.)

nmap
  1. The nmap program takes a different approach to the problem of identifying which ports are being listened to (are open in nmap parlance) on a machine. It sends special packets to ports on the machine in question, and listens for the response. This enables it to deduce whether the port is open, closed, or even being blocked by a firewall (more on that later). The nmap program isn t installed by default, but it is on the Fedora Core CD-ROMs, so you may need to install it if you want to try these examples.

First, by way of example, let s get nmap to see what ports are open on our machine. We ll use the flags -sUT to tell nmap we want it to scan both TCP and UDP ports, and accept the defaults for everything else (including the port range, which is 1 to 1023, because these are the ports that privileged services use, plus others that are mentioned in /etc/services ).

Here s the output from a test system:

   # nmap -sUT localhost   Starting nmap V. 3.00 (www.insecure.org/nmap/) Interesting ports on rh9 (127.0.0.1): (The 3064 ports scanned but not shown below are in state: closed) Port    State    Service 22/tcp   open    ssh            25/tcp   open    smtp           68/udp   open    dhcpclient        123/udp  open    ntp            6000/tcp  open    X11            nmap run completed -- 1 IP address (1 host up) scanned in 3 seconds 

It has identified the same ports as netstat did, with the exception of xinetd listening on tcp/32769. Port tcp/32769 is not listed by nmap because it is not in the range 1 to 1023, nor is it listed in /etc/services , so it won t get scanned by default. If we used the “p flag to specify port numbers (for example, added -p 1-65535 to the command line to have all ports scanned), then the open port is found and listed with unknown in the service column.

Notice that nmap needs to be told which host to scan the ports on, suggesting that it can be used to scan for open ports on remote machines. The nmap program is capable of scanning for open ports on a range of remote machines, even choosing addresses at random. However, it is wise to get written permission from the owners of systems before scanning their ports because this action may be seen as a prelude to illegal hacking activity. After all, it is just like walking past a row of parked cars and trying the doors on each one to see if they re locked. If a policeman caught you doing that, you d have a hard time explaining that you were just looking for unlocked cars so you could tell the owners to be more careful.

IP Traffic

Capturing and analyzing network traffic is surprisingly easy. Many tools are available that enable users with sufficient privileges to record the headers and contents of network packets into files on disk and analyze the contents later. With broadcast network media, such as Ethernet, every machine on a network segment receives all the packets, regardless of who the packet is addressed to. Typically, the receiving network card discards packets not addressed to it, but most network cards can be configured to operate in promiscuous mode, which allows them to receive and process packets regardless of their intended destination. (Ethernet switches , as opposed to hubs , have intelligence and effectively create a series of point-to-point Ethernet links, instead of sending all packets to all machines. This not only improves security, but it can also improve performance.)

We ll use a utility called tcpdump (from the RPM package of the same name) to demonstrate just how easy it is to capture data not destined for your machine. (As with nmap , make sure you have permission to do this if you re going to try it on a network that you don t own.)

Our theoretical test setup is this. There are three machines, all connected to a 10/100 Ethernet hub, and all on a private subnet 192.168.1/24 (that s shorthand for a subnet 192.168.1.0 with a netmask of 255.255.255.0 , that is, 24 bits). Fred ( 192.168.1.1 ) is a Windows machine that we ll use as a Telnet client, Bob ( 192.168.1.2 ) is a Linux server we ll be telnetting into, and Kate ( 192.168.1.3 ) is our Fedora Core 2 machine. On Kate, we su to root and type the following:

   # tcpdump i eth0 l q X src or dst port 23   

This tells tcpdump to listen to all packets on interface eth0 ( -i eth0 ), buffer the output line-by-line ( -l ), not to print lots of header information ( -q ) but do print the packets in ASCII ( -X ), and show only packets where the source or destination port is 23 ”the Telnet port ( src or dst port 23 ). We ll get an acknowledgment:

   tcpdump: listening on eth0   

This shows that tcpdump is logging all Telnet packets it sees on the network segment connected to eth0 .

Now we go to Fred, our Windows machine, and telnet from there to Bob, our Linux server. As soon as we do, we see the packets being logged by tcpdump , even though that s running on a machine that s not the destination for the packets!

   12:11:51.070377 fred.3335 > bob.telnet: tcp 0 (DF)     0x0000   4500 0030 317b 4000 8006 3342 0a04 4101  E..01{@...3B..A.     0x0010   0a04 4102 0d07 0017 24e6 7419 0000 0000  ..A.....$.t.....     0x0020   7002 2000 26f7 0000 0204 05b4 0101 0402  p...&...........     12:11:51.070826 bob.telnet > fred.3335: tcp 0 (DF)     0x0000   4500 0030 0000 4000 4006 a4bd 0a04 4102  E..0..@.@.....A.     0x0010   0a04 4101 0017 0d07 f267 5575 24e6 741a  ..A......gUu$.t.     0x0020   7012 16d0 e838 0000 0204 05b4 0101 0402  p....8..........   

If you look carefully at the packet log, you can find the Password prompt and see what the user typed in response. The password has been highlighted to make it easier to see, but hackers don t need that much help ”they ll probably use an automated password sniffer that ll decode the packets for them:

   12:12:02.265222 bob.telnet > fred.3335: tcp 10 (DF) [tos 0x10]   0x0000   4510 0032 9d51 4000 4006 075a 0a04 4102  E..2.Q@.@..Z..A. 0x0010   0a04 4101 0017 0d07 f267 55fc 24e6 746e  ..A......gU.$.tn 0x0020   5018 16d0 2c48 0000 5061 7373 776f 7264  P...,H..Password 0x0030   3a20                    :. 12:12:02.465557 fred.3335 > bob.telnet: tcp 0 (DF) 0x0000   4500 0028 4a7b 4000 8006 1a4a 0a04 4101  E..(J{@....J..A. 0x0010   0a04 4102 0d07 0017 24e6 746e f267 5606  ..A.....$.tn.gV. 0x0020   5010 21a8 0941 0000 2020 2020 2020     P.!..A........ 12:12:03.180919 fred.3335 > bob.telnet: tcp 1 (DF) 0x0000   4500 0029 4b7b 4000 8006 1949 0a04 4101  E..)K{@....I..A. 0x0010   0a04 4102 0d07 0017 24e6 746e f267 5606  ..A.....$.tn.gV. 0x0020   5018 21a8 a337 0000 6620 2020 2020     P.!..7..f..... 12:12:03.218203 bob.telnet > fred.3335: tcp 0 (DF) [tos 0x10]  0x0000   4510 0028 9d52 4000 4006 0763 0a04 4102  E..(.R@.@..c..A. 0x0010   0a04 4101 0017 0d07 f267 5606 24e6 746f  ..A......gV.$.to 0x0020   5010 16d0 1418 0000 65fd 01ff fb05     P.......e..... 12:12:03.423073 fred.3335 > bob.telnet: tcp 1 (DF) 0x0000   4500 0029 4c7b 4000 8006 1849 0a04 4101  E..)L{@....I..A. 0x0010   0a04 4102 0d07 0017 24e6 746f f267 5606  ..A.....$.to.gV. 0x0020   5018 21a8 9736 0000 7220 2020 2020     P.!..6..r..... 12:12:03.423232 bob.telnet > fred.3335: tcp 0 (DF) [tos 0x10]  0x0000   4510 0028 9d53 4000 4006 0762 0a04 4102  E..(.S@.@..b..A. 0x0010   0a04 4101 0017 0d07 f267 5606 24e6 7470  ..A......gV.$.tp 0x0020   5010 16d0 1417 0000 6465 6420 4861     P.......ded.Ha 12:12:03.555199 fred.3335 > bob.telnet: tcp 1 (DF) 0x0000   4500 0029 4d7b 4000 8006 1749 0a04 4101  E..)M{@....I..A. 0x0010   0a04 4102 0d07 0017 24e6 7470 f267 5606  ..A.....$.tp.gV. 0x0020   5018 21a8 a435 0000 6520 2020 2020     P.!..5..e..... 12:12:03.555354 bob.telnet > fred.3335: tcp 0 (DF) [tos 0x10]  0x0000   4510 0028 9d54 4000 4006 0761 0a04 4102  E..(.T@.@..a..A. 0x0010   0a04 4101 0017 0d07 f267 5606 24e6 7471  ..A......gV.$.tq 0x0020   5010 16d0 1416 0000 0d0a 0869 6e3a     P..........in: 12:12:03.699442 fred.3335 > bob.telnet: tcp 1 (DF) 0x0000   4500 0029 4e7b 4000 8006 1649 0a04 4101  E..)N{@....I..A. 0x0010   0a04 4102 0d07 0017 24e6 7471 f267 5606  ..A.....$.tq.gV. 0x0020   5018 21a8 a534 0000 6420 2020 2020     P.!..4..d..... 

This is what we mean when we say that the Telnet protocol sends passwords in plain text across the network. If that network uses broadcast media, every machine on the same network segment as the sender receives the unencrypted password on its network interface. Most of the time, the other machines will just ignore this data, but all it takes is one of them to be running a promiscuous mode packet logger such as tcpdump and all the passwords sent by telnet can be captured. FTP suffers from a similar vulnerability. Fortunately, there are secure alternatives to both Telnet and FTP ( ssh and sftp , respectively) that encrypt all data they send over the network using strong encryption techniques so the eavesdropper is not able to glean any useful information from the packets.

Another packet analyzer that can be installed from the Fedora Core 2 CDs is called Ethereal. This has a graphical front end that makes it much easier to set up filters and interpret the contents of packets. (There is also a character-based version called tethereal that does not require X Windows). When Ethereal is started (as root, by simply typing ethereal at the command prompt once the ethereal and ethereal-gnome RPMs have been installed, of course), the main window opens. The Capture>Start menu option opens another window where you can set capture options (see Figure 10-7).

click to expand
Figure 10-7

Note the check box to put the interface ( eth0 ) in promiscuous mode, so packets not intended for this machine can be captured. Once capturing is running, another window is updated continuously with packet counts, as shown in Figure 10-8.

click to expand
Figure 10-8

With the options chosen in the example capture window, the main display is also updated in real time, as demonstrated in Figure 10-9.

click to expand
Figure 10-9

This example shows the start of an ssh session between two machines. This time, you won t be seeing any plain text passwords.

The point of showing tcpdump and Ethereal is not to encourage you to go sniffing for packets on networks, but rather to illustrate just how easy it is to capture sensitive information such as passwords that are sent across broadcast networks, such as Ethernet. However, if you make sure that you use protocols such as ssh and sftp that encrypt sensitive data, it won t matter if someone is capturing the packets you send.

Firewalls

Firewalls are another useful tool for improving the security of your system. They come in different varieties, but all do essentially the same thing: network traffic passing through the firewall is analyzed , and the decision about what to do with the traffic (let it through, throw it away and tell the sender, throw it away and don t tell the sender, and so on) is made based on the rules configured by the firewall administrator.

Some firewalls analyze network traffic at the packet level; these are called packet filters . They can work with any network traffic, but can implement only fairly simple rules based on the contents of the packet header (typically where the packet came from, where it s going to, and what flags are set). Other firewalls understand more about the higher-level protocols used for e-mail and Web browsing. They can perform more complex tasks such as scanning e-mail attachments for viruses, or requiring users to authenticate themselves before allowing access to certain Web sites. In a typical corporate environment, the protection provided by simple packet filtering firewalls is enhanced with more sophisticated firewalls and proxies that can analyze the contents of the packets as well as their headers.

Because the Linux kernel has built-in packet filtering capabilities, we ll look at how we can configure these to enhance the security of our Fedora Core system.

Network Connections

Before exploring the mechanics of configuring the Fedora Core built-in firewall, you need to understand how network connections work. For TCP/IP connections, there are two basic protocols: Transmission Control Protocol (TCP) and Universal Datagram Protocol (UDP).

TCP is a connection-oriented protocol. This means that when two machines wish to communicate via TCP, their TCP stacks negotiate a connection and the application (such as a Web browser talking to a Web server using HTTP) and TCP ensure that packets are delivered to the application in the right order, with no duplicates. The mechanism for setting up a connection involves the exchange of TCP packets between the systems that have different flags set in their headers. First, the client (that s the machine that wants to establish a connection) sends the server (the machine the client wants to connect to) a TCP packet with the SYN flag set. The server replies with a packet whose header has both the SYN and ACK flags set, and when the client receives this packet, it sends one back with just the ACK bit set. From this point on, the connection is established, and the client and server can exchange packets.

When the connection is no longer required, either party can request that it be closed by sending the other end a TCP packet with the FIN flag set. The recipient replies with a packet that has the ACK flag set, and then performs whatever termination steps are required by the application. When this is done, a packet with the FIN flag set is sent back to the end that initially requested the connection to be closed. When this is acknowledged with a packet where the ACK bit is set, the connection is finished.

UDP is a much simpler, connection-less protocol. All that happens here is that the originator sends the UDP datagram to the recipient, and the network layer tries its best to deliver it. Unlike TCP, delivery is not guaranteed , and datagrams traveling over long distances may go by different routes and, therefore, arrive out of order at the other end. All the logic for synchronizing client and server, or retrying failed packets, has to be handled by the application code.

It is important that you understand the differences between TCP and UDP when configuring firewalls. With TCP, the direction of the connection (incoming, where the client is remote and the server is on your machine, or outgoing, where the client is local and the server is remote) is determined by the exchange of SYN, SYN+ACK, and ACK packets at the start of the connection, but with UDP, there is no connection, so incoming and outgoing simply refer to the direction of the packet.

Configuring the Fedora Core Firewall

Configuring the Fedora Core firewall is very straightforward. Start the Security Level Configuration application by choosing Main Menu>System Settings>Security Level, or by typing redhat-config-securitylevel at the command prompt. If you are not logged on as root, and you haven t recently supplied the root password to enable you to update system-wide settings, you ll be prompted to do thatbefore the Security Level Configuration starts. When it does, you ll see the window shown in Figure10-10.

click to expand
Figure 10-10

Under the Security Level drop-down list, the options are Enable Firewall and Disable Firewall. If you choose Disable Firewall, the other options are disabled, and when you click on the OK button and click the Yes button on the Warning dialog, any firewall configuration is removed and your system is completely open to any packets sent to it on any network interface. For obvious reasons, this is not recommended.

If you choose Enable Firewall, you can trust (that is, allow incoming connections) on five different services by checking the box next to the service name:

  • WWW (HTTP): Used for remote Web browser connections to your local Web server

  • File Transfer Protocol (FTP): Used for transferring files, but sends passwords in plain text

  • SSH - Secure Shell (SSH): Used for encrypted and authenticated remote shell and file transfer

  • Telnet: Allows users to log in remotely

  • Mail (SMTP): Allows other machines to send our machine e-mail messages

Note that this configuration only affects incoming connections, that is, when it is the remote machine that initiates the connection. The Fedora Core 2 firewall configuration does not affect outgoing connections, that is, when it is your local machine that initiates the connection.

The bottom half of the Security Level Configuration application window shows the available network devices. You can choose to trust (that is, not restrict the traffic on) a device by checking the box next to the device name. Trusted network devices ignore any restrictions you may place on the services you trust. For example, if you trust only SSH, but also trust the eth0 device, incoming Telnet or FTP connections will still be accepted on the eth0 interface (provided you have the FTP and Telnet servers correctly configured to handle incoming connections).

The example in Figure 10-10 shows a system where SSH and eth1 are trusted. This means that incoming SSH connections will be accepted on any interface, and all incoming packets are accepted on eth1 . There is one significant drawback to using the Security Level Configuration application to configure your packet filtering firewall; both configure only rules that selectively block incoming network traffic. Outgoing traffic and traffic that is forwarded (that is received on one network interface and sent out on another) by your Fedora Core system are not checked in any way. This means that, should you have a system behind your firewall that has been compromised (hacked or maybe infected by a virus), it is free to transmit whatever it likes through your firewall. It is a good idea to configure your firewall to block selected outgoing and forwarded traffic, too. For example, you may want to force all Internet access for machines behind the firewall to be handled by secure proxy servers. You can do so by blocking outgoing Internet access for all machines except the proxy servers. More detailed firewall configuration like this is done with the iptables command, so let s look at how to do that.

iptables

This section is a brief introduction to setting up customized security beyond what is possible with the GUI tools provided by Red Hat. It s not meant to be comprehensive, as everyone s needs are different, and it d be impossible to cater to them all. However, we hope it will give you a taste of the tools available.

Blocking and allowing traffic based on direction (incoming or outgoing) and port number gives some degree of control over network traffic, but there are situations when you need finer control. For example, you may want to run a Web server that can be accessed only from machines within your department, and not from machines elsewhere. Or you may want to prevent users on certain machines from being able to FTP files from your machine while allowing others to do so. The firewalling code in Fedora Core 2 is perfectly able to cope with these situations, and far more complex ones, but you have to roll up your sleeves and configure it from the command line.

This is where the iptables command comes in. It is used to manipulate the kernel s packet filtering tables, so you can fine-tune the firewall settings to your environment.

Imagine your Fedora Core machine has two network interfaces: eth0 has the IP address 192.168.1.1 and eth1 has the IP address 192.168.10.1 . Both interfaces have netmasks of 255.255.255.0 . You re running a Web server listening on port 80, and an FTP server that uses ports 20 and 21. You need to allow machines with IP addresses starting with 192.168.10 access to the Web server, but nobody else. You also need to allow all machines in the 192.168.1.0 network access to the FTP server, except 192.168.1.57 . How do you configure this?

The first thing to do is look at the existing firewall configuration. Log on to the machine and switch to the root user. Run the following command to get a verbose listing of the current firewall rules:

   # iptables L v   

Rules are grouped together into chains . There are three default chains:

  • INPUT , which handles incoming network packets destined for processes on the local machine

  • OUTPUT , which handles outgoing network packets produced by the local machine

  • FORWARD , which handles packets that arrive on one interface and leave on another (meaning the local machine is forwarding them).

If you have enabled the Fedora Core 2 firewall, you will see that the INPUT and FORWARD chains are linked to a user-defined chain called RH-Firewall-1-INPUT . The rules in the RH-Firewall-1-INPUT are those that the Security Level Configuration application created in response to your trusted service and trusted device selections.

To set up your machine to meet the specifications, clear out (or flush ) the existing rules with the following command:

   # iptables F   
Note

You can use this command to delete the named user-defined chain:

   # iptables X name   

You re going to be dealing only with packets coming into your machine in this example, so you ll be configuring rules in the INPUT chain. Your first step is to configure the default behaviors ”or Policy ”for the INPUT chain so that if it receives a packet that doesn t match any rules, it drops (discards) it. This is the most security-conscious approach because it means that everything is blocked unless you explicitly allow it. The command to set the policy on the INPUT chain to DROP is as follows:

   # iptables P INPUT DROP   

As soon as you type that in, all incoming network packets are dropped, so before you do so, make sure that you re logged in to the machine on the console. If not, you ll lose your connection to the machine and won t be able to get it back.

Note

You could also have used REJECT instead of DROP as the policy. This would result in a message being sent back to the sender of a blocked packet informing them that the port is not reachable . This is polite, and could prevent a hapless user from continually retrying a connection attempt that will never work. However, it also confirms your presence to a would-be hacker. The policy of DROP silently discards the incoming packet, so your would-be hacker won t even know there s anything listening at your IP address. Of course, this is valid only if you never respond to any requests ”once you ve responded to one, you ve given the game away.

Now, you need to allow machines with IP addresses on the 192.168.10/24 network access to the Web server. This is listening on TCP port 80. You ll add a rule that says to accept any packet arriving on interface eth1 from a machine in the 192.168.10/24 network that is destined for port 80. The syntax for this is as follows:

   # iptables A INPUT p tcp s 192.168.10/24 i eth1 --dport 80 j ACCEPT   
  • -A INPUT means append the rule to the INPUT chain.

  • -p tcp means match packets for the TCP protocol.

  • -s 192.168.10/24 means match packets with a source address in the 192.168.10/24 network.

  • -i eth1 means match packets on the eth1 interface.

  • --dport 80 means match packets with a destination port of 80.

  • -j ACCEPT means jump to the ACCEPT target (that is, allow the packet through).

    Note

    You don t have to specify the network interface, but doing so will prevent someone spoofing an IP address on the wrong network from gaining access.

Your second requirement is to allow FTP access to hosts in the 192.168.1/24 network attached to eth0 , except 192.168.1.57 . You do this as a pair of rules; the first is a specific rule to block FTP access from 192.168.1.57 , and the second is a more general rule that allows the others in. Because packets are passed to rules in order, you want to place your more restrictive rules first to ensure that they match. So, your two new rules are created with the following:

   # iptables A INPUT p tcp s 192.168.1.57 -dport 20:21 j DROP     # iptables A INPUT p tcp s 192.168.1/24 i eth0 -dport 20:21 j ACCEPT   

If you view your tables with the following command, you ll see our rules . . . eventually:

   # iptables L v   

If DNS is configured on your machine, you ll find that all the DNS queries time out because you ve blocked all the DNS traffic. So, you need to add some more rules to allow important network traffic through:

   # iptables A INPUT p all s nameserver -dport domain j ACCEPT   

(Replace nameserver with the TCP/IP address of your name server.) Now your name server queries should work again. Here s what the rules look like:

   # iptables -L -v     Chain INPUT (policy DROP 26 packets, 2276 bytes)     pkts bytes target   prot opt in   out   source        destination     0   0 ACCEPT   tcp -- eth0  any   192.168.10.0/24    anywhere      tcp dpt:http     0   0 DROP    tcp -- any  any   192.168.1.57     anywhere      tcp dpts:ftp-data:ftp     0   0 ACCEPT   tcp -- any  any   192.168.1.0/24    anywhere      tcp dpts:ftp-data:ftp     0   0 ACCEPT   all -- any  any   nameserver     anywhere      tcp dpts:domain         Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)     pkts bytes target   prot opt in   out   source        destination     Chain OUTPUT (policy ACCEPT 1190 packets, 430K bytes)     pkts bytes target   prot opt in   out   source        destination   

Once you ve configured your rules, you need to make sure that they work as expected. In this example, you could try FTP and Web server access from different hosts to see that they were allowed or blocked, as required. When you re happy with the rules, save them so they will be reactivated if the machine is rebooted. Do this with the following command:

   # service iptables save   

Virtual Private Networks

Virtual Private Networks (VPNs) are widely used to connect two trusted networks via a third network that is not trusted. A typical example is a company that needs to give some of its employees secure access to internal network resources from their own homes. This is possible using dedicated communications lines between the office and the employees homes , but such lines are usually expensive. A VPN solution only requires the office and employees homes to be connected to the Internet, which is usually a much cheaper alternative.

Tunneling

Tunneling is the name given to the technique of transporting information between two endpoints across a transmission medium where the information being transported is hidden from the transmission medium. The diagram in Figure 10-11 illustrates this.

click to expand
Figure 10-11

In the diagram, the two endpoints are called Secure Network A and Secure Network B; however, in real life, the endpoints could just as well be host systems instead of networks. The problem that you are trying to solve is that you want to transfer information between the two secure networks, but do not trust the network path in between (for example, because it is the Internet).

The diagram shows how you solve the problem by creating a tunnel between the two networks. Information leaving Secure Network A is encoded before it enters the tunnel in such a way that only Secure Network B can decode it, and Secure Network B can also verify that the information could have come only from Secure Network A. (It is possible to create a tunnel that does not have these security features, but this is not often done).

When you create tunnels and use them in this way, you are creating Virtual Private Networks (VPNs). The next few pages look at how you can set up VPNs using your Fedora Core 2 system in common scenarios.

When talking about VPNs, the terms client and server have a rather loose interpretation. Once a VPN tunnel is established, it is a peer-to-peer connection, with both ends performing identical roles. In this section, the client is taken to be the end that makes the initial request to set up a VPN tunnel, and the server is the end that responds to the request.

Working with Microsoft VPN Servers

This section shows you how to set up your Fedora Core 2 system so that it can connect to a Microsoft VPN server (for example, you may have such a server in your office and wish to connect to it from yourhome).

You must make sure you have permission from the owner of the VPN server to connect your Fedora Core 2 system to it. When your VPN tunnel is up and running, your machine effectively becomes part of the secured network behind the VPN server. If you are also connected to the Internet (which is very likely, as that is probably how you are accessing the VPN server), the firewall configuration on your machine is the only thing between the Internet and the secured network.

Point-to-Point Tunneling Protocol

The tunneling protocol you will be configuring here is the Point-to-Point Tunneling Protocol (PPTP). Some Microsoft Windows versions also support Layer 2 Tunneling Protocol (L2TP) tunnels. With PPTP tunnels, there are two paths between the endpoints. A control session is created using TCP on port 1723, and the tunneled data is sent using the Generic Route Encapsulation (GRE) protocol, which is protocol number 47. (See the file /etc/protocols for a list of protocols ”you are probably already familiar with ICMP, TCP, and UDP, which are protocol numbers 1, 6, and 17, respectively.)

The protocol number for GRE is important if you have any sort of firewall or port filtering between your machine and the VPN server (which you certainly should). You will need to ensure that the TCP connection on port 1723 and the GRE protocol are allowed by your firewall before you will be able to get a VPN tunnel working.

MPPE and MPPC

Microsoft uses its own encryption algorithm, Microsoft Point-to-Point Encryption (MPPE ”described in RFC 3078), along with its own compression algorithm, Microsoft Point-to-Point Compression (MPPC ”described in RFC 2118). Unfortunately, at the time of this writing, support for these protocols is not included in the Fedora Core 2 release, so if you want to connect your system to a Microsoft VPN server, you will have to add MPPE and MPPC support yourself.

The first place to look for the necessary MPPE and MPPC packages is http://pptpclient. sourceforge .net/ . This is the home of a Point-to-Point Tunneling Protocol (PPTP) Client that is released under the GNU General Public License. By the time you read this, there may be specific instructions and RPM packages for Fedora Core 2. In any case, there is a lot of very helpful information on this site, and it is well worth a visit.

Another place to look for the patches required to add MPPE support to Fedora Core 2 is at www.polbox.com/h/hs001/ .

From here, you can download the appropriate kernel patch (for example, linux-2.6.1-mppe-mppc-0.98.patch.gz for the 2.6.1 kernel). As the name implies, this file is a patch for the kernel source code, so you will need to install the kernel-source-2.6.1-1.65 RPM package and the utilities required to build the kernel. Be warned : This requires about 2GB of space in /usr/src . If you have not got enough space in /usr , you can create a new filesystem and mount it under /usr/src before installing the kernel source RPM.

Patching the Kernel

After you have installed the kernel source RPM, you are ready to patch the kernel. Change to the directory where you saved the downloaded file, and extract the patch with the following command:

   gzip d linux-2.6.1-mppe-mppc-0.98.patch.gz   

This will uncompress the file and you will have a new file without the .gz filename extension. Switch to the root user and apply the patch with the following commands:

   su     patch d /usr/src/linux-2.6.1-1.65 Np1 < linux-2.6.1-mppe-mppc-0.98.patch   

You should see output similar to this as the patch modifies the kernel source files:

   patching file drivers/net/Kconfig     Hunk #1 succeeded at 2313 (offset 17 lines).     patching file drivers/net/Makefile     Hunk #2 succeeded at 103 (offset 1 line).     patching file drivers/net/ppp_generic.c     patching file drivers/net/ppp_mppe_crypto.c     patching file drivers/net/ppp_mppe_crypto.h     patching file drivers/net/ppp_mppe_mppc_comp.c     patching file include/linux/ppp-comp.h   

Now type

   exit   

to return to your nonprivileged shell prompt.

Now decide where you want to build the new kernel. This should be a directory under your home directory. Use the following commands to create the directory and set up an environment variable ( $BD ) that will save you some typing and reduce the chance of errors. (In the example, the build directory is set to /home/user1/build/kernel; change this to suit your system.)

   mkdir p /home/user1/build/kernel     BD="/home/user1/build/kernel"   

Now change the directory to the top of the source tree and configure the kernel by running these commands:

   cd /usr/src/linux-2.6.1-1.65     make O=$BD menuconfig   

This brings up a character-based menu that can be used to configure the kernel (see Figure 10-12).

click to expand
Figure 10-12

Navigate through the menus as follows: Device Drivers>Networking Support.

Scroll down the list of devices until you find Microsoft PPP compression/encryption (MPPC/MPPE). Type M to have this built as a kernel module (see Figure 10-13).

  1. Press Escape repeatedly to exit back up through the menus, and answer Yes when you are asked if you want to save your new kernel configuration.

    click to expand
    Figure 10-13

Building the Kernel

Now build the kernel with this command:

   make O=$BD   

This starts the kernel build process that takes quite some time (up to an hour , depending on the speed of your hardware). The name of each object file is listed as it is compiled, along with any error or warning messages from the compiler. If all the objects are built successfully, they are linked together to form a new kernel.

The next step is to build the modules. You do this with the following command:

   make O=$BD modules   

Finally, the modules need to be installed. Root authority is required for this because the modules are written to a directory that is not writeable by unprivileged users.

   su     make O=$BD modules_install   
Using the New Kernel

Having built the patched kernel and built and installed the modules (including the one that provides MPPE and MPPC support), you can now copy the kernel image and map file (essential for booting) to /boot , and configure GRUB (refer to Chapter 1 for more information on using GRUB) to boot the new kernel for you.

The location of the kernel image depends on your machine architecture. There are different subdirectories under the arch directory for each supported hardware architecture. Assuming you are running on 32-bit, Intel-compatible hardware, the kernel image will be called arch/i386/bzImage .

   cp $BD/arch/i386/boot/bzImage /boot/vmlinuz-2.6.1-1.65custom     cp $BD/System.map /boot/System.map-2.6.1-65custom   

Configuring GRUB is simply a matter of editing the configuration file /boot/grub/grub.conf , copying the stanza that defines the kernel that you currently boot your Fedora Core system with, and modifying the title and kernel definitions. If, for example, your current Fedora Core 2 boot stanza is

 title Fedora Core 2     root (hd0, 1)     kernel /vmlinuz-2.6.1-1.65 ro root=LABEL=/ rhgb     initrd /initrd-2.6.1-1.65.img 

Create a new stanza like this:

 title Fedora Core 2 with MPPE MPPC support     root (hd0, 1)     kernel /vmlinuz-2.6.1-1.65custom ro root=LABEL=/ rhgb     initrd /initrd-2.6.1-1.65.img 

After all this work, you can reboot your system and choose your new kernel.

Testing Kernel MPPE and MPPC Support

Now that you are up and running with the new kernel, you need to test that the MPPE/MPPC support module can be loaded by the kernel.

First, define an alias so that the PPP daemon can load the module using the name ppp_compress_18 by adding the line

 alias ppp_compress_18 ppp_mppe_mppc 

to /etc/ modprobe .conf , and then running the following command:

 modprobe ppp_compress_18 

(You will need to be root to do both of these.) Check that the ppp_compress_18 module is loaded by running the following:

 lsmod  grep ppp 

You have just a couple more tasks before you can try and connect to a VPN server.

Checking for MPPE Support in pppd

PPTP VPN tunnels use the Point-to-Point Protocol (PPP) daemon ( pppd ) to transport TCP/IP packets, so pppd must also have support for MPPE. Full details of how to check and update pppd can be found at http://pptpclient.sourceforge.net . Essentially, the checking process is simply to see if the string mppe appears in the pppd executable, as follows:

 strings /usr/sbin/pppd  grep ic mppe 

This command counts how many times the string mppe occurs in the /usr/sbin/pppd executable and displays the result. If it is zero, pppd does not have MPPE support and needs upgrading.

If you need to upgrade, download the latest ppp 2.4.2 i386.rpm update from http://pptpclient.sourceforge.net , and then use rpm --upgrade to upgrade your currently installed PPP RPM.

 rpm --upgrade ppp-2.4.2_cvs_20040102-1.i386.rpm 
Setting Up a VPN Client Connection

Now you need the PPTP client ( pptp-linux RPM package) itself and (optional, but recommended) the graphical configuration tool (the pptp-php-gtk RPM package). Both of these can be obtained from http://pptpclient.sourceforge.net , so download and install them now.

After the pptp-php-gtk package is installed, you can access the graphical configuration tool by clicking the Red Hat icon, and then choosing System Settings>More System Settings>PPTP Client. If you are not running as root (and you should not be), you will be prompted for the root password before the main pptp-php-gtk-setup window appears. The window is split into two parts ; the top part shows the status of each tunnel you have defined, and the bottom part contains entry fields where you can define tunnels (see Figure 10-14).

click to expand
Figure 10-14

The first thing to do is fill in the fields on the Server tab. The example in Figure 10-15 shows how you would set up a server called MyWorkplace where the IP address of the remote VPN server is 172.20.1.1 , the Windows username is mylogin, and the password is secret. (A Windows domain name is not needed to log in to this particular server, but if you do need to supply one, there is a field to put it in.)

click to expand
Figure 10-15

After defining the server, you must configure the routes. Click the Routing tab, and you will see four routing options. You want to set up a route from your machine to all the addresses in the 172.20.1.0/24 network via the tunnel, so this is a Client to LAN type routing requirement (because your machine ”the client ”needs a route to a LAN). Select the Client to LAN radio button, and then click the Network Routes button (see Figure 10-16).

click to expand
Figure 10-16

Another window opens where you can define the required routes. Fill in the Network information (in the format network address/network mask bits, that is, 172.20.1.0/24 for the network 172.20.1.0 with netmask 255.255.255.0 ), give it a name, and click the Add button. Repeat these steps for all the network routes that are required (see Figure 10-17), and then click the Close button.

click to expand
Figure 10-17

Back in the main window, click the DNS to configure the name server options. In this example, the remote VPN server tells the client the IP addresses of the name servers to use during the PPP link setup phase, so you simply need to check the Automatic box (see Figure 10-18). This causes the PPTP client to change the /etc/resolv.conf file using information provided by the remote VPN server when bringing the link up and restore it from a saved copy when taking the link down again.

click to expand
Figure 10-18

The next tab is the Encryption tab. Here you can set the encryption options to suit the remote VPN server. Our example VPN server does not require any options (see Figure 10-19), but you may find that you need to force MPPE to get the tunnel started.

click to expand
Figure 10-19

The last tab is the Miscellaneous tab (see Figure 10-20). You do not usually need to set any options here, but if you are having trouble starting your tunnel, enabling connection debugging may be helpful.

click to expand
Figure 10-20

After you have entered all the information for your tunnel, click the Add button and a new entry appears in the list in the top part of the window. (What is happening behind the scenes is that the files containing PPP authentication information, /etc/ppp/chap-secrets and /etc/ppp/pap-secrets , are updated, a file is created in /etc/ppp/peers with your connection information, and the configuration file /etc/ppp-php-gtk/tunnels is updated.)

Now you are ready to test the tunnel. Click the line representing your tunnel in the list at the top of the screen, and then click the Start button (see Figure 10-21).

click to expand
Figure 10-21

A new window opens and shows you progress messages as pptp-php-gtk tries to start your tunnel (see Figure 10-22).

click to expand
Figure 10-22

All being well, the pptpclient creates a PPP interface ( ppp0 , in this example), makes a connection to the remote VPN server, and passes the data coming from the tunnel to the PPP daemon, which decrypts them and unencapsulates the TCP/IP packets within. DNS information is provided by the remote VPN server when the link is established (the primary DNS address 172.20.1.248 ), and the pptp-php-gtk application uses this to change /etc/resolv.conf . The application also adds the network route that we asked it to.

Working with Microsoft VPN Clients

You have seen how, with a little bit of work, you can use your Fedora Core 2 system to connect to a remote Microsoft VPN Server. What if you want to do things the other way around, and have your Fedora Core 2 system as the VPN Server and allow Microsoft Windows clients to connect to you? For this you need a PPTP server. This section will use PoPToP , the PPTP Server for Linux.

The first thing to do is visit www.poptop.org . Here you can read about PoPToP and follow links to the SourceForge download sites. When you get to the SourceForge site, click the Files link at the top of the text frame to go to the list of files. Here you should find RPM packages for the latest stable release ( pptpd-1.1.3-4.i386.rpm ) and the latest beta test release ( pptpd-1.1.4-b4.i386.rpm ). Note that these are for the Intel-compatible platform; if you are running on something else, you will need to download the source code and build from that.

Download and install the RPM package (latest stable if you will be running a production server, or the beta test one if you prefer and stability is not crucial). Add the following line to /etc/modprobe.conf :

   alias net-pf-47 ip_gre   

You need to specify the IP addresses to be used by the local PPTP server and remote clients, and this is done with the localip and remoteip options in /etc/pptpd.conf . Note that each simultaneous connection to your PPTP server requires a unique IP address, so make sure you specify enough remote IP addresses to meet your needs. (Each connection can, however, share the same local IP address). See the comments in /etc/pptpd.conf for information on how to configure ranges of IP addresses. Add the following line to this file to tell pptpd where to find the ppp options file:

   option /etc/ppp/options.pptpd   

The options file, /etc/ppp/options.pptpd , provides the options for pptpd to pass on to pppd . (Note that this is different from the file /etc/ppp/options.pptp , which specifies the PPP options to use when you are acting as the PPTP client). Add the following lines:

   refuse-pap     refuse-eap     refuse-chap     refuse-mschap     require-mschap-v2     require-mppe     nomppe-stateful     nomppe-40   

The first few lines prevent the PPP daemon started by pptpd from negotiating the following with the remote client:

  • Password Authentication Protocol ( refuse-pap )

  • Extensible Authentication Protocol ( refuse-eap )

  • Challenge Handshake Authentication Protocol ( refuse-chap )

  • Microsoft CHAP v1 ( refuse-mschap )

The next lines require the remote client to agree to the following:

  • Microsoft CHAP v2 ( require-mschap-v2 )

  • Microsoft Point-to-Point Encryption ( require-mppe )

  • Prevent negotiation of stateful MPPE ( nomppe-stateful ) or 40-bit MPPE encryption keys ( nomppe-40 )

If the client does not agree to all of these during the initial negotiation, the connection is dropped.

The final configuration file to edit is /etc/ppp/chap-secrets . This is where you list the usernames and passwords that the remote machines must supply to authenticate with you and bring up a VPN connection. Add a new line, containing four fields separated by white space.

  • The first field (client) is the username that the remote machine must supply.

  • The second field (server) must match the name of the server, as specified with the name option in /etc/ppp/options.pptpd .

  • The third field (secret) is the password that the remote machine must supply.

  • The fourth field (IP address) is the IP address of the remote client ”specify * to allow the client to have any IP address (from the range(s) allowed by the remoteip option in /etc/pptpd.conf ).

With all these changes made, you can start pptpd with the following command:

   service pptpd start   

Set up your Microsoft Windows clients per the instructions in the client configuration section of the documentation on the PoPToP Web site and you re done.

ssh and Friends

There are many times when a system administrator needs to work with remote systems (systems where access is via some sort of network connection, rather than a directly attached terminal), either logging in to a shell to run interactive commands, transferring files between systems, or running commands non-interactively, without needing to supply a password. The most popular protocols for these tasks ”Telnet for interactive login, FTP for file transfer and rlogin for automated logins ”all have a major weakness: they are insecure. Telnet and FTP both send passwords across the network connection in plain text, where they can easily be intercepted, and rlogin is vulnerable to an attacker who makes their system appear to be one that the remote system trusts (sometimes called spoofing).

Fortunately, there are widely supported, secure alternatives to these insecure protocols. This section explores using ssh for running remote commands, and scp and sftp for transferring files. All three of these commands use the SSH protocol to transfer information securely over a network link that may not be trusted. This protocol supports a variety of options to ensure that the systems at each end of a link are who they claim to be (thus preventing spoofing attacks), and to encrypt the information flowing across the link so that even if it is intercepted, an attacker will not be able to understand it. As a bonus, the SSH protocol also compresses the data it sends, and this generally speeds things up (except perhaps where you have a very slow machine and a fast network).

Try It Out Using ssh to Set Up a Secure Connection

You will use ssh to make a secure connection either between two separate systems, if you have them available, or between client and server running on the same system. We will assume that both systems are running Fedora Core 2, but if this is not the case, you should be able to adapt the following steps to suit your setup.

  1. Check that the client machine (the one you will be connecting from ) has the ssh client program installed by running the following command:

     rpm -q openssh-clients 

    You should get a brief message showing you the version of the openssh-clients package that is installed. If you get a message saying package openssh-clients is not installed, you should install it from your Fedora Core 2 installation media now.

  2. Check that the server machine (the one you will be connecting to ) has the sshd server program installed by running the following command:

     rpm -q openssh-server 

    As in the previous step, you should get a message listing the version of the package that is installed. If you get a message saying that the package is not installed, install it now from your Fedora Core 2 installation media.

  3. Try using ssh to connect from your client machine to your server by running the command

     ssh servername 

    where servername is the hostname or IP address of your target server. Use localhost if you only have one system at your disposal. You should receive a message similar to the following:

       The authenticity of host 'bach (192.168.1.1)' can't be established.     RSA key fingerprint is dc:29:c6:8e:03:96:f3:44:9f:21:fe:c4:d0:46:d7:27.     Are you sure you want to continue connecting (yes/no)?   

    This message is telling you that the server you have connected to has provided a public key to your client to prove its identity (an RSA key in this example), but your client has no record of this key. Are you sure that you have connected to the right server? What if an attacker is spoofing the identity of your target server? Type no at the prompt and press Enter to abort the connection because, at the moment, you are not sure that you have connected to the right server.

  4. The way to be sure that you are connecting to the right server is to obtain the fingerprint of its public key by an independent route that you trust. If you are the system administrator for the remote system, you need to log on to it via a locally attached terminal and find out the fingerprint. Here s how to do this:

    Log in to the server (you do not have to be root to do this; an unprivileged login is sufficient) and run the following command:

     ssh-keygen -l 

    You will be prompted for the name of the file containing the key. On a Fedora Core 2 system, the default location for the SSH RSA public host key is /etc/ssh/ssh_host_rsa_key.pub , so type this in at the prompt. (Version 2 of the SSH protocol uses RSA keys by default, but it may be configured to use DSA keys, in which case the public key file you should use is /etc/ssh/ssh_host_dsa_key.pub . If you are using version 1 of the SSH protocol, the public key file to use is /etc/ssh/ssh_host_key.pub. ) The ssh-keygen command calculates the fingerprint of the key in this file and displays it. You should get an output similar to this:

       [user1@bach user1]$ ssh-keygen -l     Enter file in which the key is (/home/user1/.ssh/id_rsa): /etc/ssh/ssh_host_rsa_key.pub     1024 dc:29:c6:8e:03:96:f3:44:9f:21:fe:c4:d0:46:d7:27 /etc/ssh/ssh_host_rsa_key.pub   

    Make a note of this fingerprint ”you don t have to worry about security because this is the fingerprint of the server s public key, and this should be known to any system that wants to use the SSH protocol to connect to it.

    If you are not the system administrator for the remote server, you should really ask the person who is to confirm the public key fingerprint.

  5. Now that you have obtained the server s public key fingerprint without using a network connection that may be secretly diverted to an attacker s system, you can try to connect again from the client system. Rerun the following command:

     ssh servername 

    You will get the same warning message about the authenticity of the server you are connecting to, but this time you can verify the fingerprint and be sure you are connecting to the right server. (Only a system with the right private key installed on it will be able to generate the public key that has the right fingerprint, so, as with all asymmetric key encryption systems, the strength of the security depends on how well the private key is protected).

    Check that the fingerprints match and type yes at the prompt to continue connecting. You will receive a message saying that the host has been permanently added to the list of known hosts, and then be prompted for your password. Type in your password and press Enter to log in. Whereas the Telnet protocol would have sent your password in plain text over the network for any eavesdropper to see, the SSH encrypts your password to keep it safe.

    Try out a few simple commands. Everything you type and all the responses back from the server are compressed and encrypted, so you can be reasonably sure that they are secure. Log out as you would with a Telnet session (that is, type exit or logout at the shell prompt).

  6. The list of known hosts is maintained in two locations on the client system. There is a system-wide list stored in /etc/ssh/ssh_known_hosts , and each user has his or her own list in $HOME/.ssh/ssh_known_hosts . The contents of these lists can be queried using the ssh-keygen -l command as before, so do this now to examine the contents of $HOME/.ssh/ssh_known_hosts (on the client system) You should see an entry that corresponds to the server that you have just connected to.

  7. If you frequently have to connect to remote systems to run interactive commands, or if you need to automate remote commands, it is very useful not to have to type in a password every time you connect to the remote system. The rsh and rlogin commands allow you to do this, but they are insecure (because they rely on looking up the hostname of the client system from its IP address, and this can be spoofed). In these next few steps, you will see how ssh can give you the same capability, but in a much more secure way.

    Just as the SSH client uses a server s public key to authenticate that server (that is, to verify thatthe system it is communicating with really is the right one), the SSH server also needs to authenticate the identity of a client by using the client s public key if it is to allow a user to log in from that client without requiring a password.

    How does an SSH client get a public key? The answer is by using the ssh-keygen utility that you have already used. Each user on a system can use this utility to generate a public and private key pair for the SSH client to use in authenticating itself with an SSH server. Run the following command to generate an RSA public and private key pair for your SSH client to use:

     ssh-keygen -t rsa 

    You will be prompted to enter the name of a file in which to store the private key. This defaults to $HOME/.ssh/id_rsa , so just press Enter to accept this.

    Next, you will be prompted for a passphrase. You can choose not to have a passphrase by just pressing Enter, but this means that anyone who gets hold of the file containing your private key will be able to masquerade as you and connect to remote systems using your login without requiring a password. If you do use a passphrase (strongly recommended), your private key file is useless to anyone else, unless they can guess your passphrase. So, enter a strong passphrase (that is, one that contains mixed case letters , punctuation, and numbers, but is not so complex that you cannot remember it without having to write it down).

    After confirming your passphrase by typing it in a second time, the RSA key pair is generated. The private key is stored in the file you specified, and the public key is stored in the file whose name is the name of your private key file with .pub appended to it.

    The overall dialog should look like this:

       [user1@bach user1]$ ssh-keygen -t rsa     Generating public/private rsa key pair.     Enter file in which to save the key (/home/user1/.ssh/id_rsa):     Enter passphrase (empty for no passphrase):     Enter same passphrase again:     Your identification has been saved in /home/user1/.ssh/id_rsa.     Your public key has been saved in /home/user1/.ssh/id_rsa.pub.     The key fingerprint is:     26:56:72:0a:4f:24:45:e0:a9:88:c5:67:ca:c5:cc:87 user1@bach   
  8. Now that you have a public key, you need to install it on the server system(s) that you wish to connect to without being prompted for your password. The SSH server will look in the file $HOME/.ssh/authorized_keys (if this file is not writeable by anyone other than the owner) and try to match up the credentials being presented by your SSH client with the public keys of the systems you have installed in this file. If there is a match, you will be able to connect without supplying a password.

    Copy the public key only to the server by running this command and entering your password on the remote system ( server ) when prompted.

     scp $HOME/.ssh/id_rsa.pub server:temp.key 

    (Don t worry about the syntax of the scp command yet ”we will explore it in more detail later. All you need to know at this point is that this command will copy your public key to a file called temp.key in your $ HOME directory on the remote system called server .)

    Now log in to the remote server (using ssh ), and run these commands to add your client s public key to the list of host systems from which you want to log in without being prompted for a password:

     cd         cat temp.key >> .ssh/authorized_keys         chmod 600 .ssh/authorized_keys 
  9. Log out from the server system and try to log back in again using ssh . Instead of being prompted for your user password on the remote server, you should now be prompted for the passphrase for the RSA private key you have just generated and saved. Type in your passphrase and you should be logged in to the remote server, without needing to enter your password on that server. Log out from the remote server.

    You are probably not impressed with this. Instead of having to type in your user password on the remote system, you now have to type in the passphrase for your private key, which is probably much longer than the password. You will have to do this each time you connect, unless you use another part of the SSH suite to automate this task: the ssh-agent . This program takes care of supplying authentication details to SSH client programs as required, so you only have to supply your private key passphrase once (typically when you first log on to your SSH client system).

  10. You can now start the ssh-agent . The agent outputs strings on stdout when it starts that should be evaluated by the shell to set two environment variables ( SSH_AUTH_SOCK and SSH_AGENT_PID ), which tell the SSH client programs how to communicate with the agent. (Theagent tries to work out whether the shell requires C-shell or Bourne-shell syntax, but it can be forced either way by using the -c or -s flags, respectively).

    Start the SSH agent and set the environment variables by running the following command:

     eval `ssh-agent` 

    You should get a message showing the process ID of the ssh-agent process that has just started, and the two environment variables previously mentioned will be set to appropriate values. Check this by running the following command:

     env  grep SSH 
  11. With the agent running, all that remains is to add private keys to the agent so that it can supply them to SSH clients, as required. Do this with the ssh-add program. Run with no arguments, ssh-add adds the private keys stored in the files $HOME/.ssh/id_rsa , $HOME/.ssh/id_dsa , and $HOME/.ssh/identity (used by SSH Version 2 RSA, SSH Version 2 DSA, and SSH Version 1 protocols, respectively). This is usually all that is required, so just run the following command:

     ssh-add 

    If you protected your private key(s) with passphrases, ssh-add will prompt you to enter these.

    You can see what private keys have been added to the agent by running the following:

     ssh-add -l 

    Remove individual keys with the following:

     ssh-add -d 

    Remove all keys with the following:

     ssh-add -d 
  12. Now that the SSH agent is able to perform functions that require your private key on behalf of SSH clients, you can (at last) log in to the remote servers (where you added your public key to the $HOME/.ssh/authorized_user file) without having to enter your password.

    Run the following command:

     ssh servername 

    where servername is the name of the remote system that knows your public key, and this time you should be logged on straight away. You can also give ssh a command to run on the remote system:

     ssh servername date 

    This will cause ssh to run the date command on the remote system and then exit.

  13. There is one last trick that ssh can do that is worth a mention in this briefest of introductions to SSH, and that is the ability to forward X11 connections over a secure channel. Many organizations do not allow X11 traffic on their networks because it is insecure (the client-server traffic is not encrypted in any way, so it is vulnerable to eavesdropping), and it also consumes a lot of bandwidth. The ssh program addresses both of these issues by compressing and encrypting the X11 protocol traffic between client and server. All that is needed is for the DISPLAY environment variable to be set when the ssh command is run.

    If you have a graphical login (you are running an X11 server on your system and the DISPLAY environment variable is set), you can run a command such as

     ssh servername xterm 

    to open an xterm session on the remote server.

Copying Files

There are two programs in the OpenSSH suite that copy files between systems; scp (secure copy) is like the insecure rcp (remote copy) program, and sftp (secure FTP) is like the insecure ftp program. The syntax of these two programs is similar to that of the insecure ones that they replace, so getting used to them should not be a problem. For example, suppose you wanted to copy a file called /home/user1/data1 from a machine called tangerine to the /data/incoming directory on your local machine. The syntax for the rcp command to do this is as follows:

 rcp tangerine:/home/user1/data1 /data/incoming 

Using scp , the syntax is as follows:

 scp tangerine:/home/user1/data1 /data/incoming 

To compare, you might use the ftp program to connect to a remote system called caesar and send files in a local directory called /app1/archive to a directory called /app1/backup on the remote system using commands like this:

 $ ftp caesar (Enter username and password when prompted.  These are sent in plain text across the network). ftp> lcd /app1/archive ftp> cd /app1/backup ftp> binary ftp> prompt ftp> mput * ftp> bye 

With sftp , the commands are very similar:

 $ sftp caesar (Enter password or passphrase when prompted.  This is not sent across the network). sftp> lcd /app1/archive sftp> cd /app1/backup sftp> put * sftp> exit 

The man pages for scp and sftp have more details on these commands.




Beginning Fedora 2
Beginning Fedora 2
ISBN: 0764569961
EAN: 2147483647
Year: 2006
Pages: 170

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net