Linux

Since the development of UNIX and Linux are very closely linked, many of the security tips that apply to UNIX, are also relevant to Linux.

General Security Tips

  • Don't run NIS (or NIS+) unless it's absolutely necessary. NIS broadcasts encrypted passwords over the network, thus an attacker can download them and run a password cracker to decode weak passwords.
  • If possible setup your OS to encrypt your password strings using MD5.
  • Use pwconv to convert passwords to pass-phrases.
  • Only use NFS if absolutely necessary and only mount a filesystem whilst it is being used. As soon as you are finished, "unmount", and "unexport" it.
  • If you are using NFS filter any packets at the firewall/border router to reject ports 111 and 2049 (TCP/UDP) as this should prevent any external access to your shares.
  • Never export NFS filesystems unrestricted to the world. Always try to export file systems read-only, and to specific hosts.
  • Don't allow the "exports" file to contain a entry for 'localhost', and export to fully qualified hostnames only.
  • Linux NFS has its own set of mount options, including secure, and root_squash. See the man page for details.
  • Never export mail spool directories as users with the same id may be able to access other user's mail.
  • If you only run NFS intermittently, disable the daemon processes, and start them manually, only when you actually want to use them.
  • Mount filesystems using mount options, such as nosuid, nodev and noexec.
  • Change the permissions of mount, umount, and ping, as normal users should not have access to these executables.
  • Use IP Addresses rather than DNS names as these cannot be spoofed.
  • Use fixed arp addresses to prevent hijacking.
  • Consider using an encrypted replacement NFS filesystem and/or test your NFS implementation with NFSbug.
  • If you are sharing files with Windows/MSDOS users:
    Create an "msdos" group (E.g. gid=2000)
    Add users to this group
    Now edit the "/etc/fstab" file and append "noexec, umask, gid" parameters, and set the gid as follows: "/dev/hda4 /mnt/msdos vfat noexec,umask=003,gid=2000 0 0"
    This means that members of the "msdos" group can mount this filesystem, and write to it, to all other users, it remains read-only! To give/remove write permission to the mountpoint, simply add or remove the user from the "msdos" group.
  • Examine carefully services offered by "(x)inetd" and the portmapper and think about using a secure portmapper where possible. If you are not using this service, stop and disable it.
  • Eliminate any other daemons and services that aren't explicitly needed.
    E.g. sendmail, fingerd, rwhod.
  • Running automated update services E.g. Redhat's "up2date" can reset application setting to their defaults, and thus override security settings.
  • Install TCP Wrappers to limit who can access services on your system(s). (see "/etc/hosts.allow" and "/etc/hosts.deny") E.g:
    "/etc/hosts.allow":
    ALL: 127.
    "/etc/hosts.deny":
    ALL: ALL
    This prevents external connections to your machine, whilst allowing internal and outbound connections.
    or:
    ALLOW 128.2.93.
    ALLOW 128.2.87.80
    DENY 128.220.
    DENY ALL

    Setting Traps in TCP Wrappers
    This rejects the connection and notifies the administrator.
    /etc/hosts.allow
    tftpd:ALL:spawn (/usr/bin/safe_finger -I @%h2>&1 \|
    mailx -s "remote tftp attempt" root)
    Banner Messages
    Sends the message from /tmp/banner/telnetd.
    Telnetd:195.5.2.:banners/tmp/banner

    telnetd: .xyz.com EXCEPT abc.xyz.com

    tcpdmatch - Simulates how the tcp wrapper would handle a specific request.

    If "name checking" is activated, the wrapper will verify that the name to address mapping is the same as the address to name mapping. If there is any discrepancy, the wrapper concludes that it is dealing with a host that is using a bogus name. If detected, it is logged, and the connection aborted.

  • Regularly consult your manufacturer's website(s) and be aware of security bulletins.
  • Ensure there are no device files outside of "/dev".
  • Use "xauth" (MIT-MAGIC-COOKIE) to validate your X-Windows connections. See this mini-HOWTO which describes how to run secure remote X applications. It is also a good idea to create standard .xinit, .xinitrc, and .xserverrc files and put them into each user's home directory. Better still tunnel X traffic over SSH.
  • SSH can be used to forward ports to another port on the same (or other) computer, e.g. port number 3000 can be done with ssh, e.g.
    ssh -f -L 3000:localhost:2000 localhost tail -f /dev/null
    Note: All cryptography relies on good quality random number data (entropy) to seed its cryptographic routines. If possible use "/dev/random" and "/dev/urandom" to generate this data.
  • Ensure that "/dev/random" and "/dev/urandom" are secure to prevent an attacker from reading or injecting data.
    NOTE: /dev/random provides the highest quality data, however it can be exhausted and this could be used to mount a denial of service attack. "/dev/urandom" on the other hand provides slightly lower quality entropy data, but will use hashing algorithms to prevent it from being exhausted, and this is normally good enough for most applications.
  • Edit the "xdm-config" file and set the "DisplayManager*authorize" attribute to true. When granting access to the display from another machine, use the xauth command instead of xhost.
  • Configure workstations to disable listening for incoming X sessions over the network. See the -nolisten tcp option.
  • xdm bypasses the normal getty and login functions, which means that quotas for the user, ownership of /dev/console and possibly other preventive measures put in place by you may be ignored.
  • Limit login times to office hours. Attackers prefer to attack when there are fewer people on the system that may witness their actions.
  • Use pwconv and grpconv to create user and group shadow password files.
  • Create (touch) /var/log/btmp To login all failed login attempts.
  • Only install a webserver if really needed.
  • Remove the C compiler or Perl interpreter unless needed as it makes hacks easier. If you can't remove your compiler, disable it for non-root users. This makes compiling exploits quite difficult.

    rpm -ql gcc | xargs chmod go-rwx
    rpm -ql bin86 | xargs chmod go-rwx
    rpm -ql gcc-c++ | xargs chmod go-rwx

  • Edit the files "/etc/cron.allow" and "/etc/cron.deny" to allow or deny selected users from being able to run scheduled tasks.
  • Remove or disable "sniffer" software such as "tcpdump". An attacker could use this to gain valuable information about your system.
  • Create a legal disclaimer message in "/etc/issue", "/etc/issue.net", and "/etc/motd".
  • Installing X-Windows undoubtedly makes managing a Linux server much easier, however if this is a firewall you think about removing it. Alternatively you can ensure that X-traffic cannot pass outside of your local network.
  • Run Apache, DNS/Bind and FTP within a 'chroot' jail on critical systems.
  • Consider using SSL (Secure Socket Layer) for encrypting any TCP/IP protocols in use. SSL can be used for server authentication, client authentication, and transmitting encrypted data.E.g. SHTTP (Secure HTTP).
  • There are also replacement servers such as "publicfile", a read-only HTTP and FTP server. (http://cr.yp.to/publicfile.html).
  • Never run Apache (or any other Webserver) as root. Create a new user with minimal privileges. Do NOT use the nobody account as this account is used to map the root account over NFS.
    Remove the "default html" content, and the two CGI scripts "test-cgi" and "printenv". Weaknesses in these files are very well-known, and frequently targeted by hackers. Refer to the WWW Security FAQ for details on how to further secure Apache.
  • Scan for FTP weaknesses using the freely available Nessus scanner: http://www.nessus.org and lockdown as many settings as possible (E.g. Ensure that your FTP server does not have the SITE EXEC command enabled). You should also consider replacing FTP with SSH's secure version.
  • If you activate both the wu-ftpd and vsftpd services, xinetd will only activate vsftpd because it comes first alphabetically.
  • Disable SNMP unless required, or configure it to request an additional authentication trap. Change the community string name, and where possible, make it read-only.
  • If SNMP is required consider using SNMP v3 as this is more secure. See: www.ibr.cs.tu-bs.de/projects/snmpv3/
  • Use Linux firewalls to protect against attacks. ("ipchains" or "iptables", a statefull-inspection firewall) Access denial rules can also be implemented on the fly using "portsentry".
  • Set up some filtering rules to drop bogus TCP packets using iptables. Filter bogus packets using the following rules:
    iptables -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j LOG -m limit --limit 10/m --log-level "LOGLEVEL" --log-prefix="bogus packet"
    $IP -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j DROP
  • When creating rules for iptables use DENY and not REJECT to avoid replying to remote hosts with "ICMP Not Reachable" messages, as this can alert an attacker to your presence.
  • Ports should be unbound on switches and routers to act as a second line of security. Remember to regularly use Nmap, lsof, or similar, to scan for ports that are still open.
  • All servers should only be accessible through a gateway server.
  • Good locks are no good if you can’t tell if someone has broken in, therefore log monitoring is vital. Get used to how your logs look so that you are more likely to notice any exceptions.
  • Create a system logbook/diary and keep accurate records of each machine's activity.
  • Verify the cryptographic digital signature of any signed downloaded files to ensure integrity. Don't use a file whose signature doesn't match its contents! Information about PGP/GnuPG is available in the USC at A.2.10 PGP/GnuPG.
  • Check for the availability of a hardening script package for your particular system.
  • Remove unneeded accounts/groups and disable interactive login access to system accounts
  • Set a sensible system wide umask E.g. 027 or 077.
  • Remove /tmp and /var/tmp on reboot.
  • Regularly rotate and archive log files.
  • If you use any scanning and auditing tools, consider placing them onto a floppy/ CD-ROM, or other read-only medium.
  • The EXINIT variable should be set to override "~/.exrc" (This prevents editor attacks):
    /etc/profile
    export EXINIT=-V
  • To safeguard X-Windows, the "/tmp/.X11-unix.allow" should have the permissions 1775.
  • Prevent the syslog daemon from listening to the network. Tcp-Wrappers can be configured to prevent inbound connections whilst still enabling outbound ones.
  • Ensure that "/etc/syslog.conf" is configured to correctly trap all alerts and messages.
  • Use Swatch to analyse your logfiles.
  • Do not install UUCP unless you really need it! Alternatively remove the (n)uucp users and groups, any crontab entries, and any UUCP packages..
  • Expect all ".login", ".profile", ".exrc", ".logout", "crontab, "/etc/rc*" and similar system startup and shutdown files, for any suspicious entries.
  • Where possible use secure RPC with DES authentication and is a Sun Microsystems secure authentication mechanism for RPC. It depends on synchronised clocks and a shared DES key.
  • Activate process accounting.
  • Check for unsuccessful login attempts.
  • Put untrusted users in a special group then make a sensitive files belong to that group, then set the access permissions to rx----rx
  • Pay particular attention to the contents of .bash_profile (env vars and progs to run at login)
    .bashrc (functions and aliases) files and ensure that there are no suspicious entries.
  • Setup IP Masquerading using iptables -nat -F POSTROUTING
    iptables -t nat -A POSTROUTING -o ppp0 -s 10.0.0.0/16 -j MASQUERADE
    echo 1 > /proc/sys/net/ipv4/ip_forward
    (See the IP Masquerading Howto).
  • Use SNARE to audit your system:
    Disk Space
    Processor Availability
    Management
    Monitoring
    Analysis
    Reporting
    Response
  • Use chrootkit to scan for known rootkits installed on your system.
  • Consider installing portsentry to detect port scanners that are probing your system.
  • Configure sendmail to limit the amount of connection it will allow. This can prevent a denial of service attack.
  • Use find / -user root -perm "-u+s" to make a list of SUID programs when you first install your OS, then regularly repeat the scan to look for any new ones.
  • cmp -l /usr/bin/login /usr/bin/ksh - Can compare binaries when "sum" is not trusted.