CHECKLIST
Generic rules of thumb for security:
From: Bruce
Marshall
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.
- Use shadow passwords (the command pwconv or
pwconv5 will convert regular passwords to shadow
passwords). (Linux uses shadow passwords as a default except for some of the
very early versions.)
- In /etc/hosts.deny, put this line in:
ALL: ALL
- In /etc/hosts.allow, enter the hosts
you want to have access to your box for the various services. For example:
in.telnetd:
my.host.com, your.host.com
in.ftpd: my.host.com
- In /etc/inetd.conf, comment out all
services you don't use regularly. Each service is a potential security risk.
-
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:
|
echo |
stream |
tcp |
nowait |
root |
internal |
|
Wrapped service:
| telnet |
stream |
tcp |
nowait |
root |
/usr/sbin/tcpd |
in.telnetd |
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.
- 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.
- 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)
-
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
***"
- 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.
-
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
- 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.
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.
- 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.
- 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.
- Take a look at www.rootshell.com
if you are interested in the methods used to break into your machine.
- 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.
- 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:
| -rwsr-xr-x |
1 |
root |
root |
21384 |
Apr |
3 |
1999 |
sliplogin |
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
- 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:
-
chmod o-rw /bin
- 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.
-
chmod o+t /tmp <=== turn
on the sticky bit
- Consider giving /etc a mode of 711. With this, users cannot read the
contents of files but can still traverse the directory.
- 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.)
- Consider 'secure logging' by sending a copy of your logs to a remote site,
or stashing them somewhere on your system.
- Append only - for logs that don't grow much, consider making them append
only so that a hacker cannot overwrite the files.
-
chattr +a
/var/log/syslog
lsattr
/var/log/syslog
- Turn on 'syn cookies' in the kernel. This will prevent 'SYN flooding'
which is method of attack.
- Edit your passwd file from time to time and verify who has accounts on
your system.
- 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.
- Consider improving on logging by enhancing your /etc/syslog.conf:
# /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
http://www.linux-sxs.org/security/scheck.html |
Responder a este mensaje
