A year ago, I attended a 4 day Linux Security class. The following are a list of notes that I compiled after I had returned from the class.

There are obviously many more things that can be done to safeguard your system but most of these items are a good starting point.

As the instructor repeatedly stated: "It's not a question of IF you're system is going to be hacked, it is a question of WHEN."

Remember: A FIREWALL WILL NOT KEEP CRACKERS OUT, ITS PURPOSE IS TO BUY YOU TIME TO REACT BEFORE THEY (script kiddies, et. al.) CAN DO SERIOUS DAMAGE. The only secure box is turned off and locked in the back room -- but it's also not much use to anyone.

1. Use shadow passwords (the command pwconv or pwconv5 will convert regular passwords to shadow passwords). (Caldera Open Linux uses shadow passwords as a default except for some of the very early versions.)
2. 
    
3. In /etc/hosts.deny, put this line in:
4. 
       ALL: ALL
    
5. In /etc/hosts.allow, enter the hosts you want to have access to your box for the various services. For example:
6. 
       in.telnetd: my.host.com, your.host.com
       in.ftpd: my.host.com
    
7. In /etc/inetd.conf, comment out all services you don't use regularly. Each service is a potential security risk.
8. 
    

    

   The following services provide some useful service to remote users, yet do not provide login access:

• echo - echo service
• discard - remote "/dev/null"
• daytime - daytime
• chargen - character generator
• netstat - remote netstat output
• time - time
• comsat - warm users of new mail
• systat - system status
• auth - identd
• qotd - quote of the day
• msp - message send protocol
• 
   

   

  Interactive user services - The following services allow users to login or connect and directly access your system:
   

• telnet - user login
• ftp - file transfer protocol
• sendmail - email transfer
• shell - remote shell
• login - remote login
• exec - remote execution service
• talk - talk (direct chat)
• ntalk - new talk
• klogin - kerberos login
• eklogin - e-kerberos login
• kshell - kerberos shell
• pop2/pop3 - post office protocol
• imap - interactive mail access
• uucp - news and other
• tftp - trivial ftp
• finger - finger info
• rpc - remote procedure call services
• 
   

   

  Which services are used? Check /var/log/syslog to see if there are any instances of a sevice being used. If none, remove the service or remove it anyway until you find you need it. It is better to lock down the box and slowly re-enable services than to leave everything open.

  After making the changes to/etc/inetd.conf, restart inetd using:

<find the pid number for inetd>
ps aux | grep inetd

<tell inetd to do a restart>
kill -HUP <pid for inetd>

Other services can be 'wrapped' if they aren't already. This means using a package called "tcp_wrappers". When wrappers are used, all requests for the wrapped service are tested against /etc/hosts.allow and /etc/hosts.deny thus either authorizing the access or denying it. (see the man pages for "tcpd" for more information)

To verify a service is wrapped, look at the entry in /etc/inetd.conf. The TCP_wrapper checks any incoming request for service against an Access Control List (ACL).

Unwrapped service:

Wrapped service:

Some network tools are started from /etc/rc.d/rc<runlevel>.d (Example: /etc/rc.d/rc5.d) The files in these directories can be renamed to eliminate the associated startup.

Another method for eliminating startup of daemons is to change the files in /etc/sysconfig/daemons. Edit the files there and change the parameter ONBOOT="yes" to "no".

Get a copy of nmap (www.insecure.org/nmap) and run it to determine what ports are open.

5. Be careful in upgrading daemons! Latest is not always the greatest. New versions often bring on bugs that can cause security problems. Stay away from 'alpha' releases and be wary of 'beta' releases.
6. 
    
7. Consider replacing daemons with more secure alternatives. Both ftpand telnet send plain text passwords over the net. Consider using some of the more secure facilities such as sshinstead of telnet, scpinstead of ftp. sshcan be found at www.ssh.org. Check your /etc/ftpaccess file for denying unauthorized users. After installing something like ssh, carefully check the configuration parameters. For example: PermitRootLogin no should be specified. (version 1.2.27 is preferred over the 2.0.x versions due to licensing considerations)
8. 
    

    

   FTP access is controlled by the /etc/ftpaccessfile. Below are two entries; the first allows a single domain to have access and the second denies all access to everyone:

   class all real most-trusted.com

   deny * /etc/ftpdeny
   (use this statement to block all ftp access but also comment out ftpd in /etc/inetd.conf)

   The ftpdeny file can contain a message: "*** FTP ACCESS DENIED ***"

9. Search for and find tripwire and install it and use it. portsentry from www.psionic.com is also very good. logcheck, also from the www.psionic.com site will scan your logs and send you email with anything that looks suspicious. This alone is a very valuable tool.
10. 
     

     

    Here's an example of a logcheck scan of the log files. An attack was reported and prevented by portsentry:

    Active System Attack Alerts
    =-=-=-=-=-=-=-=-=-=-=-=-=-=
    May 1 22:12:16 bmarsh portsentry[6728]: attackalert: SYN/Normal scan from host: 194.74.16.5/194.74.16.5 to TCP port: 81
    May 1 22:12:16 bmarsh portsentry[6728]: attackalert: Host 194.74.16.5 has been blocked via wrappers with string: "ALL: 194.74.16.5" (an entry is placed in /etc/hosts.deny to block the attacker)
    May 1 22:12:16 bmarsh portsentry[6728]: attackalert: SYN/Normal scan from host: 194.74.16.5/194.74.16.5 to TCP port: 81
    May 1 22:12:16 bmarsh portsentry[6728]: attackalert: Host: 194.74.16.5/194.74.16.5 is already blocked Ignoring

    Security Violations
    =-=-=-=-=-=-=-=-=-=
    May 1 22:12:16 bmarsh portsentry[6728]: attackalert: SYN/Normal scan from host: 194.74.16.5/194.74.16.5 to TCP port: 81
    May 1 22:12:16 bmarsh portsentry[6728]: attackalert: Host 194.74.16.5 has been blocked via wrappers with string: "ALL: 194.74.16.5"
    May 1 22:12:16 bmarsh portsentry[6728]: attackalert: SYN/Normal scan from host: 194.74.16.5/194.74.16.5 to TCP port: 81
    May 1 22:12:16 bmarsh portsentry[6728]: attackalert: Host: 194.74.16.5/194.74.16.5 is already blocked Ignoring

    Unusual System Events
    =-=-=-=-=-=-=-=-=-=-=
    May 1 22:12:16 bmarsh portsentry[6728]: attackalert: SYN/Normal scan from host: 194.74.16.5/194.74.16.5 to TCP port: 81
    May 1 22:12:16 bmarsh portsentry[6728]: attackalert: Host 194.74.16.5 has been blocked via wrappers with string: "ALL: 194.74.16.5"
    May 1 22:12:16 bmarsh portsentry[6728]: attackalert: SYN/Normal scan from host: 194.74.16.5/194.74.16.5 to TCP port: 81
    May 1 22:12:16 bmarsh portsentry[6728]: attackalert: Host: 194.74.16.5/194.74.16.5 is already blocked Ignoring
     
     

11. Make sure you have sendmail version 8.9.x or above. (COL 2.4 is using 8.9.3). Make sure your sendmail is not set up for mail relay.
12. 
     

     

    Knowing the version of your sendmail can help a hacker if there is an exploit for it. The 'configuration version' is kept in your /etc/sendmail.cf file. (Search for "Configuration version number") Change the version to anything you like. The sendmail greeting message can be changed in a similar manner.

    # Configuration version number
    DZ8.9.1

    Change to:
    DZ8.7.2 (or anything)

    O SmtpGreetingMessage=$j Sendmail $v/$Z; $b

    Change to:
    # SMTP initial login message (old $e macro)
    O SmtpGreetingMessage=$j UpChuck 1.01/1.nospam; $b

    There are many other options and parameters that can be changed in sendmail.cf to improve security.

13. Don't use easy passwords. Don't use a password that contains part or all of the userid associated with the password. Don't use any word that is contained in a dictionary. Use a combination of letters, numbers and special characters if possible.
14. 
     
15. Keep up with all security based updates. Think like a cracker and look for chinks in your own armor (visit www.rootshell.com often). You can use the syslog -r facility on one box and have all boxes send their log messages to that one box. Also, not everyone (yet) knows about the chattr -- even root can't replace a file that has the immutable bit set (until it's unset). There are lots more tips and tricks -- and even more ways around them.
16. 
     
17. Take a look at www.rootshell.com if you are interested in the methods used to break into your machine.
18. 
     
19. Limit finger output or eliminate it. Get ffingerd and use it instead if you must provide finger information. This will give users control over what information is available.
20. 
     
21. Limit SGIDs and SUIDs. These are files with a special bit set on that allow a standard user to run them, but execute the binary at a higher privilege. Sendmail is one of these because it needs to access system resources and open up a restricted socket. There are very few commands that need this status. You may find over 150 such commands but only about 10 need this. Commands such as: sendmail, su, ping, traceroute, write, passwd, Xwrapper, and possibly others. (files with SUID/SGID will show an 's' in the user execution field:

To find such programs, use the command:

find /<blank>\( -perm -4000 -o -perm -2000 \) >> /tmp/remove_suids

which will create the /tmp/remove_suids file containing the names.

Once you have found all the files, make a script to change all the SUID/SGID' Edit the /tmp/remove_suids file to first remove those programs that need the permission:

find / \( -perm -4000 -o -perm -2000 \) >> /tmp/remove_suids
cd /tmp
vi remove_suids
< remove sendmail, su, ping, traceroute, write, passwd, Xwrapper, cgi-bin files and possibly others>
<esc>
:g/^/s//chmod -s /
<move to top line and add the following line:>
#!/bin/sh
:wq!

<the script: remove_suids has been created. Now we make it executable>
chmod 700 remove_suids

<now execute the completed script file>
./remove_suids

14. Consider 'Fascist File Permissions' . This involves group controls for files. Slowly remove 'other' permissions from files (and see who complains) Consider making some directories as non-readable or writable (/bin, /sbin) Users do not need to read or write the full contents of such directories as long as they can excute the files. To change the mode of a directory:

15. chmod o-rw /bin

16. Consider removing the readability from /tmpand /var/tmp.  Many exploits require the ability to read these directories in order to expolit a flaw. Consider turning on the 'sticky bit' for tmp directories. This prevents one user from overwriting the files of others and may prevent an exploit.

17. chmod o+t /tmp <=== turn on the sticky bit

18. Consider giving /etc a mode of 711. With this, users cannot read the contents of files but can still traverse the directory.
19. 
     
20. Edit securetty and remove all ttyS* entries. This means that root must login only at a console. (this appears to be the default on Caldera 2.4 and most earlier systems.)
21. 
     
22. Consider 'secure logging' by sending a copy of your logs to a remote site, or stashing them somewhere on your system.
23. 
     
24. Append only - for logs that don't grow much, consider making them append only so that a hacker cannot overwrite the files.

25. chattr +a /var/log/syslog
    lsattr /var/log/syslog

26. Turn on 'syn cookies' in the kernel. This will prevent 'SYN flooding' which is method of attack.
27. 
     
28. Edit your passwd file from time to time and verify who has accounts on your system.
29. 
     
30. Maintain your backups!! And while you're at it, stash a copy of ps, ls, and other utilities off in a secure place. The first thing a hacker will do is provide copies of utilities that hide what (s)he is doing.
31. 
     
32. Consider improving on logging by enhancing your /etc/syslog.conf:
33. 
     

     

    # /etc/syslog.conf
    # For info about the format of this file, see "man syslog.conf" (the BSD man
    # page), and /usr/doc/sysklogd/README.linux.
    #
    # NOTE: YOU HAVE TO USE TABS HERE - NOT SPACES.
    # I don't know why.
    #
    *.=info;*.=notice;*.warn;mail.none<2 tab>/var/log/messages
    *.=debug<5 tab>/var/log/debug
    *.warn;*.crit;*.emerg<4 tab>/var/log/syslog

    auth. *<6 tab>/var/log/log.auth
    cron.*<6 tab>/var/log/log.cron
    daemon.*<5 tab>/var/log/log.daemon
    kern.*<6 tab>/var/log/log.kern
    mail.*<6 tab>/var/log/log.mail
    mark.*<6 tab>/var/log/log.mark
    syslog.*<5 tab>/var/log/log.syslog
    user.*<6 tab>/var/log/log.user

    #uucp.*<6 tab>/var/log/log.uucp
    #lpr.*<6 tab>/var/log/log.lpr
    #news.*<6 tab>/var/log/log.news

Search