Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!

TUCoPS :: Linux :: Discontinued :: susesfaq.htm

SuSE Security FAQ
COTSE - Nix's Niche - SuSE Security FAQ Peter Nixon
Bullet Home Bullet SuSE-Security FAQ Bullet Public Key Bullet Pete's Place Bullet COTSE
Peter Nixon

Nix's Place

SuSE Security FAQ

Version 0.44, [an error occurred while processing this directive]
FAQ Maintainer:

This is a collection of the most commonly asked questions on the SuSE-Security mailing list.
The Official archives of the list can be found here or a searchable archive of the list here. You probably will want to take a look at the SuSE Security Announcements.

Contributions to the FAQ are welcome. Please send them to

Incident Reporting

Q: One of my servers has been cracked open and overtaken by intruders. What now?
A: In case of a compromised system, immediately follow these steps:

  1. Disconnect the host from the network, do *NOT* switch it off
  2. Connect a monitor, switch it on and carefully watch the status of all consoles, note down any obscurities, or take a polaroid.
  3. Login to the compromised host and create a complete system backup on clean media. Secure this backup afterwards.
  4. Use a non-networked computer to restore all the backed up data from the compromised host on a single harddisk for later examination with tools like grave digger from the Coroner's Toolkit by Wietse Venema (
  5. Additionally, secure all system logs from the compromised system onto a non-writeable medium (CD-ROM) for quick referrence.
  6. Get in touch with your boss and/or your organisation's legal departement and inform them about the breach of security immediately. Cooperate with them to find out any legal possibilities of the case. During this time, do not wipe or modify any data on the compromised system for it might be relevant for legal examination.
  7. After checking things with your laywer/legal departement/boss, low-level format all harddisks of the compromised system.
  8. Analyze the logs of the compromised host and the post-mortem data you backed up from it in order to find the vulnerability the attacker exploited to crack your system.
  9. Install a new SuSE-Linux from scratch *WITHOUT* any config files from the compromised system. Read the FAQ section "How do I secure SuSE?" for more infos about securing your freshly installed system. If you have to restore certain data from the compromised system (e. g. customer web spaces, files for your ftp-server...), double- and triple-check that the data has not been modified or trojaned. This specially goes for scripts of any kind (CGI, php, etc.). Where possible, use clean versions of the files instead of those from the compromised server. If you can not
  10. Configure a firewall, either as a dedicated host or on the server itself, and install an instrusion detection system (IDS, like snort)
  11. If there are more systems which have not been compromised on the first glance, check their logfiles for more signs of intrusions.

Q: I have secured all data from the compromised system and checked back with our lawyers. Is there another place to report system compromises to?
A: The
CERT Coordination Center ( offers facilities for incident reporting, information about good security practises and ressources for your research around security. Reporting incidents to CERT results in advises from the CERT security experts and vital information to get back online quickly. If you want to report your incident to CERT, follow the steps found on the CERT Incident Reporting Form (

Secure Remote Access

Secure Shell

Q: How do I securely access my server remotely?
A: If you have not done so already you need to install the
OpenSSH package. This should be in the SEC section on your SuSE CD or DVD although as this is a network service I recomend that you first check to see if there is a newer version on
SSH is basically a version of telnet that uses Secure Sockets Layer (or SSL) encryption. It can do everything that telnet, rsh and rlogin can, except in an encrypted manner. The only difference you really nead to know about compared to telnet is that you need to specify the username you wish to login with on the command line before you connect, rather than at an interactive prompt. (ie. I wish to connect to as the user joe, I would type ssh If you do not do this, ssh will try to automatically log you in as the current user.

Secure File Copy

Q: How do I securely copy files between my (SuSE) Linux machines?
Arguably the best way to securely copy file over a network is with OpenSSH's scp command.

Q: How do I securely copy files between my Windows PC and my (SuSE) Linux Server.
The most commonly used Windows SCP client is PSCP.
For those people who are typing impaired, there is a 3rd party Windows GUI available for PSCP called Secure iXplorer, as well as a really nice stand alone Windows GUI called WinSCP.

I can't connect to my server using SSH

Check you have enabled access to SSHD in /etc/hosts.allow
SuSE's version of OpenSSH all come with libwrap support compiled in by default. That is, they honour the /etc/hosts.allow and /etc/hosts.deny
If you have previously run harden_suse you will now have a line at the bottom of /etc/hosts.deny that looks like:


If this is what's causing your connection to be refused, you should will to see it in the /var/log/warn logfile. This can be checked by using the command

tail -f /var/log/warn

To enable access from your IP address, simple add the line:

sshd : x.x.x.x

to /etc/hosts.allow (where x.x.x.x is the IP that you are connecting FROM.) You can also use the format x.x.x.x/y.y.y.y where y.y.y.y is the subnet mask of an entire network (ie. Your LAN) that you wish to allow. If you wish to allow SSH access from anywhere, you can replace x.x.x.x with the word ALL. This is not recommended.

SSHD also has the possibility of denying root access. Look at /etc/sshd_config and see if PermitRootlogin is yes (or try connecting as another user). Finally, you could be having a problem with different ssh versions. Openssh 2.3 supports both SSH1 and SSH2 and should work, and you should upgrade to it anyway, since earlier versions have some security problems.

How do I Secure SuSE?

Have you read your SuSE Manual? Do that first!
Of course you have also already read Marc Heuse's ( white paper on the
Installation of a Secure Web Server :-)
30 Second Tutorial..
Install and run harden_suse (found at
Install Sec Check (found at
Apply any updates that are applicable from :

Now, if you ran harden_suse and answered yes, it will have pretty much locked everything down for you. You will need to set INETD to start again in /etc/rc.config and you will need to re-enable ftp by un commenting the line in /etc/inetd.conf that matches the ftp server you are running. (Personally I like proftpd. Read /etc/proftpd.conf for info on locking it down, it's self explanatory) You will need to add the ip range that you want to connect to sshd from into
And you will need to enable Apache (httpd) in /etc/rc.config

Once you have done all this (it should take you about 15 min) reboot the machine just to check that everything works and is set to startup etc, then do a "nmap localhost" (or a netstat -nat) your ports should now look like:

Port State Service
21/tcp open ftp
22/tcp open ssh
80/tcp open http

Once you have double checked just to see that you have applied all the available patches for the rpms you have installed compare that web page to the output of

	rpm -qa

There is of course alot more that you can do to secure a system, and I'm sure that you'll get a bunch of people telling you about securmod and tripwire and all the other cool security toys, all of which you should learn about and implement, but for your specification of a web server only (I am assuming your are the only person with a shell account)this will be sufficient to get your server on the web without worrying about being easily compromised.

Notice you didn't even have to configure a firewall/packetfilter?!


I've heard that sendmail is insecure, but it is also used very often. Do you know other mail-deamons which are more secure?

There have been no known security weaknesses in sendmail as of version 8.9.3. Sendmail is quite powerful but not that easy to configure. Postfix and QMail are smaller, faster and possibly easier to configure, but from the security point of view there is no difference.

The Pros:

- very active maintainer team (
- a couple of millions users worldwide
- very flexible and adaptable for your needs
- fully compatible to almost all internet mail standards
- supported by most tools/apps (antivirus, spam-blocker, etc.)
- very well documented, lots of good books are available
- highly reliable if configured correctly

The Cons:

- _Can_ be difficult to set up
- most admins need quite some time to get used to it

How do I configure Sendmail Securely?

Sendmail can be considered to be configured securely in a standard install of SuSE that has has harden_suse ran on it.

How do I enable feature "X"?

What you do is simply edit /etc/mail/ (or a copy of it) and select the options you want by removing the "dnl" from the front of the lines you want.
In some cases you will also need to change the domain etc also. It is very well commented, and you should have not trouble figuring it out. Once you think you have the right options you then execute the command
          "m4 /etc/mail/ > /etc/"
and it will regenerate the file for you, with the options you have selected.
Then a simple
          "/etc/init.d/sendmail restart"
will put the changes into effect for you.

How do I configure Postfix

For a standard config where you have one domain only that you wish to recieve mail for, simply edit /etc/rc.config.d/postfix.rc.config
It has very good commenting and you should be able to follow it yourself.
Once you have changed this file to reflect your domain, save it and run the command SuSEconfig
This will merrily go off and generate the required config files for you. The primary file you need be interested in if you wish to do more advanced configuration of Postfix is /etc/postfix/

Why doesn't SuSE ship Qmail?

Qmail's license is VERY restrictive and basically does not allow vendors to ship it (you cannot ship modified binaries). That and qmail's development has been somewhat stunted by the fact that contributions to it are often not included, basically only DJB is working on it, which means qmail lacks a LOT of features.

I want to use X, but I don't want it to listen on the network for connections (port 6000)

(At least with SuSE 6.4) Edit /usr/X11R6/lib/X11/xdm/Xservers, and change
:0 local /usr/X11R6/bin/X :0 vt07
:0 local /usr/X11R6/bin/X :0 vt07 -nolisten tcp

How do I enable MD5 Password Encryption

The documentation to enable MD5 password encryption is in /usr/share/doc/packages/pam/md5.config on your SuSE 7 machine.

Firewalls and IDS

Port Forwarding

Q: I have a little LAN with a SuSE Server as gateway, within my LAN I have a NT box with IIS, I want to be able to access the the httpd on the NT box from the internet by specifying some port on my gateway. I have firewals-2.1-5 installed and all clients in my LAN have unlimited access to the internet and to the gateway. I tried configuring the redirection, but seems to me like this only works when the NT box has an public IP, but it has not not, an will never have. So is it possible to do it with the firewall or do I have to fiddle with ipchains?
A: What you need to do is "reverse" Masquerading. This can be accomplished with the IPMASQADM tool included on your SuSE CD. You will need to use this tool by hand, although it will happily co-exist along with Marc's IPFIREWALS package. (You will need to enable access to the port you want to forward in the firewall config of course) You can read the
Author's FAQ here.
NOTE: This requires that you have regular Masquerading working first!

I see port scans to port number xyz - What does this mean? What is this port used for?

In order to gather information about your system most attackers use port scanners like nmap ( to look for open ports and to remotely identify the operating system the target host is running.

This information, together with a list of known security vulnerabilites of various services and applications, can be used to exploit these holes, start denial of service (DoS) attacks and finally gain root access to the attacked system. That's why it is important to close services which you don't need (see HOW DO I SECURE SUSE?) and to keep up-to-date with the latest security patches.

If you want to know what service hides behind a certain port number you can look into /etc/services. For a (nearly) complete list of ports and services you may consult IANA's list of ports Unfortunately, there are also a lot of trojan horses around which use certain ports for their inbound and outbound activity. Some trojan apps come with a client utility capable of scanning single hosts or entire subnets for infected machines which can then be hijacked. For information about ports used by common trojan horses consult m , www.simovit s . com/sve/nyhetsarkiv/1999/nyheter9902.html or the The Trojans Lair Trojan Database.

What does "kernel: martian source aabbccdd for 11223344, dev eth0" mean?

These are packets that Linux does not expect from the direction they came from (i.e. packets from internal hosts coming in on the external interface). The cause is probably a misconfigured machine on your LAN. You can turn off logging those packets via
which is documented in /usr/src/linux/Documentation/proc.txt

Rejecting vs. Denying Packets

Please note, that the following applies to ipchains. Things are a little different for iptables/netfilter which ships with Linux kernel 2.4.x

Most packet filters offer you the possibiliy of either denying or rejecting a packet. So where's the difference?

DENYing a packet simply means not responding at all i.e. silently drop the packet.

REJECT drops the packet, but (if it's not an ICMP packet) generates an ICMP reply to the source to tell it that the destination was unreachable.

Sometimes denying isn't the the best of responses because in doing so, we actually tell the attacker that a packet filter is present. Another drawback of denying is, that some services will wait for a response, thus slowing down other services while waiting for the reply packet you'll never send. (please, please _remember_ that when it comes to inetd issues ;-)

Additional Information:


- Read the doc of nmap!!

- thousands of postings on millions of mailing-lists


When a service isn't running on a unix system it normally let's the remote host know with some sort of return packet. In TCP this is done with an RST (reset) packet. UDP returns (usually) an icmp-type: port-unreachable packet with the original destination address of the packet.

But anyway, you cannot influence that behaviour using ipchains. If you like to do that consider using a *BSD system with ipf. For a start read the IP-Filter-HOWTO which should be available on


What is chroot?

Quoting Zwicky, Cooper, Chapman: Building Internet Firewalls: "The chroot mechanism allows a program to irreversibly change it's view of the filesystem by changing the program's idea of where the root of the filesystem is."

So, this is where the name comes from ;-)

Think of a chroot'ed program as a program that lives in it's own, restricted filesystem without access to the rest of your filessystems (say e.g. binaries or /etc/passwd). This restricted filesystem has to include everything (_but no more_) the chroot'ed program needs to run. Thus it has to include e.g. /etc, /bin, /lib etc. (don't forget the shared libraries).

The environment that needs to be set up like this called the chroot environment (often called "jail"). Please remember to avoid setting up symbolic links that point to areas outside the chroot environment.

The benefit of chrooting is e.g. to restrict users to a subset of tasks or to build up an additional layer of defense against an intruder, taking over one of your processes. Note, that it's not really impossible to break out of a chrooted environment, so don't rely on that exclusively.

Almost every program can be chrooted (Yes, even netscape ...) either by "built-in" means or by the chroot system call (man chroot, man 2 chroot).

To get a more practical approach, please read the man page of ftpd with special respect to /etc/ftpchroot. A proper anonymous ftp setup is an example for a chrooted environment.

Security Resources

Can you recommend some good reading on Linux Security?

Online and free:
Linux Administrator's Security Guide to be replaced by:
Linux Security Knowledge Base tz/papers.html
Anonymous: "Maximum Security" SAMS Publishing (
(German translation: "Hacker's Guide", Markt+Technik-Verlag München)
Anonymous: "Maximum Linux Security" SAMS Publishing (
ISBN 0-672-31670-6
(German translation: "Linux Hacker's Guide", Markt+Technik-Verlag München)

Other Places to Look for Security Info FAQ - "This newsgroup is dedicated to the discussion of issues related to establishing and maintaining the security of machines running the Linux Operating System on all processor architectures."

Church of the Swimming Elephant - Have you gone to church today?

Security Portal - "Recognized as an objective force in the information security industry, SecurityPortal currently serves as the voice of security with its widely distributed e-newsletter and website with thousands of pages of security information"

Yet to be done/added

- firewalls: dmz

- Obtuse SMTPD

- service tunneling using ssh

- log file checking/digestifying

- correct use of unix permissions

- saint/satan reports service xyz is insecure - what now?

- mail and file virus scanning

- buffer overflows

- password security


- incident reporting

- mail relaying/anti spam

- ftp and firewalls

- glossary to properly describe words and phrases like tcp,

 udp, trojan, scans, ports, firewall, stateful packet

 inspection, packet filtering, vpn, ipsec, etc. pp...

enhance the paragraph HOW DO I SECURE SUSE in a way that

the users *know* what's going on if harden_suse or the

seccheck-scripts are started, and *why* it is important

not to run services with UID/GID 0, offer services which

 aren't used or have an eye at file permissions.


Peter Nixon -
Kurt Seifried -
Boris Lorenz -
Johannes Geiger -
Chris Wahl -
Kevin Ivory -
lukas geider -
Matthias Patz -

If you want name on this list, Send me a completed Answer to one of the unfinished ones above.

This FAQ created and maintained by

This site is designed and maintained by Peter Nixon
Copyright ©1997-2001


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2016 AOH