United States (change)
Shortcuts: Downloads Fedora Red Hat Network
Issue #6 April 2005
Red Hat's customer service team receives technical support questions from users all over the world. As they are received, Red Hat technicians add the questions and answers to the Red Hat Knowledgebase on a daily basis. Individuals with a redhat.com login are granted access. Every month, Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries.
This month's issue features articles about security, including an inside view of Red Hat Enterprise Linux 4. We realize it is impossible to answer all your security questions with just one magazine issue, but we've tried to answer a few more with this month's Tips & Tricks.
Screen is a useful utility that I stumbled across several years ago
and continue to use today. It is a terminal multiplexer that acts as
a full screen window manager for text-based terminals. Simply put,
screen allows you to open multiple terminals on a single connection.
You might wonder how or why this is useful since Red Hat provides six
ttys by default. As an example, consider when only one tty is
available, as is the case in single user mode. Another good example
is when a user connects to a remote system through SSH or over a
modem. Rather than making multiple connections, you can use your
single connection and run screen to get multiple ttys.
Screen can monitor terminals and display a message if it
detects activity. It provides a clipboard type feature that allows
you to copy/paste from window to window. It also gives you a buffer
allowing you to scroll back through history.
How many of you have started a long process at work like, for
instance, a kernel rebuild? If you begin that process within
screen, then you the screen, go home, ssh to
your office machine, and re-attach to the screen. The
process remains running the entire time. You can attach and detach
screens at will, but the processes continue to run.
The screen utility is provided by the screen
rpm. You can install it on your Red Hat Enterprise Linux system by
typing up2date . Some important
keystrokes to note: Ctrl-A is the control key for screenscreen.
You follow Ctrl-A with another key that corresponds to what you want
to do. To see a list of all of the key bindings, press Ctrl-A
followed by ?. Don't forget to check out the main page for more
information.
The next time you need multiple windows over one connection, don't forget about this valuable utility!
After configuring network services, it is important to pay attention to which ports are actually listening on the system's network interfaces. Any open ports can be evidence of an intrusion.
There are two basic approaches for listening the ports that are
listening on the network. The less reliable approach is to query the
network stack by typing commands such as netstat
-an or lsof -i. This method is
less reliable since these programs do not connect to the machine from
the network but rather check to see what is running on the system. For
this reason, these applications are frequent targets for replacement
by attackers in an attempt to cover their tracks if they open
unauthorized network ports.
A more reliable way to check which ports are listening on the
network is to use a port scanner such as nmap.
The following command issued from the command line determines which ports are listening for TCP connections from the network:
nmap -sT -O localhost
The output of this command looks like the following:
Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on localhost.localdomain (127.0.0.1): (The 1596 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 111/tcp open sunrpc 515/tcp open printer 834/tcp open unknown 6000/tcp open X11 Remote OS guesses: Linux Kernel 2.4.0 or Gentoo 1.2 Linux 2.4.19 rc1-rc7) Nmap run completed -- 1 IP address (1 host up) scanned in 5 seconds
This output shows the system is running portmap due to the presence of the sunrpc service. However, there is also a mystery
service on port 834. To check if the port is associated with the
official list of known services, type:
cat /etc/services | grep 834
This command returns no output, which indicates that while the port
is in the reserved range (meaning 0 through 1023) and requires root access to open, it is not associated with a
known service.
Next, check for information about the port using netstat or lsof.
To check for port 834 using netstat, use the
following command:
netstat -anp | grep 834
The command returns the following output:
tcp 0 0 0.0.0.0:834 0.0.0.0:* LISTEN 653/ypbind
The presence of the open port in netstat is reassuring because a cracker opening
a port surreptitiously on a hacked system would likely not allow it to
be revealed through this command. Also, the -p option reveals the process id (PID) of the
service which opened the port. In this case the open port belongs to
ypbind (NIS), which is an RPC service handled
in conjunction with the portmap service.
The lsof command reveals similar information since it is also capable of linking open ports to services:
lsof -i | grep 834
Below is the relevant portion of the output for this command:
ypbind 653 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 655 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 656 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 657 0 7u IPv4 1319 TCP *:834 (LISTEN)
These tools reveal a great deal about the status of the services running on a machine. They are
flexible and can provide a wealth of information about network services and configuration. Consulting
the man pages for lsof, netstat, nmap, and similar services is therefore highly recommended.
To disallows direct root login, edit the /etc/ssh/sshd_config file with a text editor and
find the following line:
#PermitRootLogin yes
Change the yes to no and remove the comment character at the beginning of the line:
PermitRootLogin no
Restart the sshd service:
service sshd restart
It is also recommended that you also restrict access to your system by
limiting users root access with the su
command. Refer to additional articles in Red Hat Knowledgebase on how to
restrict the use of su command.
The Red Hat
Network (RHN) service is hosted at xmlrpc.rhn.redhat.com. This is the default
configuration and need not be changed unless you are using a Red Hat
Network Satellite server.
To verify the server your system is configured to use, issue the command:
up2date-nox --configure
at a terminal. Here is an example of the command output:
0. debug No 1. useRhn Yes 2. rhnuuid 578918ea-cb1c-11d8-8f02-814df2323483 3. isatty Yes 4. showAvailablePacka No 5. networkSetup Yes 6. retrieveOnly No 7. enableRollbacks No 8. noSSLServerURL http://xmlrpc.rhn.redhat.com/XMLRPC 9. pkgSkipList ['kernel*'] 10. storageDir /var/spool/up2date 11. adminAddress ['root@localhost'] 12. noBootLoader No 13. serverURL https://xmlrpc.rhn.redhat.com/XMLRPC 14. fileSkipList [] 15. versionOverride 16. sslCACert /usr/share/rhn/RHNS-CA-CERT 17. noReplaceConfig Yes 18. useNoSSLForPackage No 19. systemIdPath /etc/sysconfig/rhn/systemid 20. enableProxyAuth No 21. retrieveSource No 22. disallowConfChange ['noReboot', 'sslCACert', 'useNoSSLForPackages', 'noSSLSe 23. headerFetchCount 10 24. networkRetries 5 25. pkgsToInstallNotUp ['kernel', 'kernel-modules'] 26. enableProxy No 27. proxyPassword 28. updateUp2date Yes 29. keepAfterInstall No 30. proxyUser 31. removeSkipList ['kernel*'] 32. useGPG Yes 33. gpgKeyRing /etc/sysconfig/rhn/up2date-keyring.gpg 34. httpProxy 35. headerCacheSize 40 36. forceInstall No 37. noReboot No Enter number of item to edit:
Entry numbers 8 and 13 — noSSLServerURL and serverURL — define what servers up2date uses.
Alternatively, you may also verify the settings by looking at the
contents of the file /etc/sysconfig/rhn/up2date and locating the
entries for noSSLServerURL and serverURL:
... noSSLServerURL=http://xmlrpc.rhn.redhat.com/XMLRPC ... serverURL=https://xmlrpc.rhn.redhat.com/XMLRPC ...
For RHN and up2date to work correctly
the firewall must allow connections to:
In addition, to be able to access the Red Hat Network (RHN) website, the firewall must allow connections to:
To prevent non-root users from using the shutdown/reboot/halt commands:
/etc/X11/gdm/gdm.conf, change the line that reads:
SystemMenu=true
to
SystemMenu=false
/etc/inittab, change the line that reads:
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
to
ca::ctrlaltdel:echo <A message indicating rebooting is not possible>
/etc/security/console.apps/, delete the files
reboot, poweroff, and halt./usr/bin/poweroff.
To remove files, you can use the rm command.
Example: rm /usr/bin/poweroff.
Sendmail can be configured to encrypt email via the secure socket layer (SSL) when sending and receiving messages. This requires the following configuration changes to Sendmail.
First, SSL requires a valid certificate on the server. This can be obtained from a company which digitally signs the certificate or it can be created locally. To generate an SSL certificate, follow these steps:
cd /usr/share/ssl/certs make sendmail.pem
Enter the desired information for Country Name, State or Province,
Organization Name, etc. when prompted. Next, uncomment the following
lines in /etc/mail/sendmail.mc by removing the dnl at the beginning of the line:
... define(`confCACERT_PATH',`/usr/share/ssl/certs') define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt') define(`confSERVER_CERT',`/usr/share/ssl/certs/sendmail.pem') define(`confSERVER_KEY',`/usr/share/ssl/certs/sendmail.pem') ... DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')
Restart Sendmail with the command:
service sendmail restart
Secure SMTP is now enabled for sending mail over port 465 using SSL. To enable the secure IMAP/POP3 services, enable them with:
chkconfig pop3s on chkconfig imaps on
Secure POP3 operates over port 995 and secure IMAP uses port 993. The server is now configured to use SSL for sending and receiving email. When setting up the email client, make sure it is configured to use secure connection (SSL) "Always" in both the sending and receiving preferences.
One advantage of Pluggable Authentication Module (PAM) is it can be used to limit the number of network users who have access to a certain service based on a list. For example, you can limit SSH connections via PAM.
In /etc/pam.d/sshd, add the following line:
auth required /lib/security/pam_listfile.so onerr=fail item=user sense=allow file=/etc/sshd_users
This will allow a user to login via sshd if they are
listed in the /etc/sshd_users file. The
options specified have the following meanings:
onerr=fail—If an error occurs (file
specified is not found or an improperly formatted entry is found in
the file), fail this test. This will deny the user access via
sshd. The other possible option for onerr is
succeed.item=user—This states that we are
testing or verifying the user's login name.sense=allow—This means that if the
user is found in the file specified, this test succeeds. This will
allow the user access if all other PAM tests succeed as well. The
other possible option for sense is deny. file=/etc/sshd_users—This specifies
the file that will contain the list of users (one per line) that are
allowed to access sshd.With that, the /etc/pam.d/sshd will look like:
#%PAM-1.0
auth required pam_stack.so service=system-auth
auth required pam_nologin.so
auth required pam_listfile.so onerr=fail item=user
sense=allow file=/etc/sshd_users
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
session required pam_limits.so
session optional pam_console.so
Afterwards, put the valid SSH users in the /etc/sshd_users file. Each username should be on
a new line.
To use a Network Time Protocol (NTP) client or server on your system you need to have access to port 123 both incoming and outgoing between any client and the server that it is communicating with. The startup script for the NTP service should create the firewall holes on your machine automatically. You will have to ensure that all points along the route between the client and the server will allow traffic on port 123.
This article is protected by the Open Publication License, V1.0 or later. Copyright © 2004 by Red Hat, Inc.