Practical Linux/Unix Security

ccTLD Workshop 2004

October 2004
Bangkok, Thailand

Presented by Hervey Allen

Network Startup Resource Center

1
 What do we mean by “practical”?
Theoretical security concepts will be
introduced followed by the some “real
world/practical” examples.
How often do you hear, “Backup your
system ,” but just how do you do this?

Anyone have some recommendations?

We'
ll revisit this later.
2
 Core security concepts
Abstract, Theoretical, or the “end result”:
– Maintaining confidentiality.
– Keeping our data safe from intruders.
– Integrity: protect from loss or
change.
– Authentication
Is this person who they claim to be?
Is this person allowed access?
– Availability
Are our systems up and running?
3
 Maintaining confidentiality
A number of pieces are involved,
including:
– Correct user and file permissions.
– Strong passwords.
– Trusting your users.
– Use of good cryptographic methods.

4
 Keeping our data safe from
intruders
You could argue this is the hardest thing
to do.
– Keep people out who don' t belong:
● Trust your users.
● Strong passwords.

● Limit services you run.

● Protect the services you do run.

– Encrypt data as needed.

– Backup data in case of intrusion or
corruption.
– Don' t forget about physical security.
5
 Integrity
Protect your data against loss or change.
– Backup, backup, backup.
– Revision control.
– Intrusion detection systems (IDS).

6
 Authentication
How do you ensure?:
– Someone accessing your system is
who they claim to be?
● Trusted users.
● Strong passwords.

● Public/Private keys.

– The person is allowed access?

● Maintain accounts properly.
● Correct user/group/file permissions.

● Scan and watch for SUID and SGID.

7
 Authentication: Host name
Very weak
DNS is easily attacked (e.g. by loading false
information into cache)
Slight protection by ensuring that reverse and
forward DNS matches
e.g. Connection received from 84.201.255.1
Lookup 84.201.255.1 ­> noc.ws.afnog.org
Lookup noc.ws.afnog.org ­> 84.201.255.1
This is why many sites won't let you connect
unless your forward and reverse matches
8
 Availability
Make sure your server and services are up and
detect attacks like Denial of Service (DoS).
– Log what your services do and install log
“watching” software.
– Setup notifications if there are problems.
– Scan for network attacks like spoofing
(ARP), syn packet dumping, general
packet source address spoofing, brute
force attacks (dictionary password crack
9
attempts).
 More practical UNIX security
● Run only the services you plan on using.
● Use only the services that are necessary.

● Stay up­to­date and patch

services as needed.
● Use secure passwords and

force your users to use them.

● Consider if you need quotas.

● Restrict root access to services.

● Restrict access to services via

10 tcpwrappers if appropriate.
 More practial Linux/UNIX
security cont.
● Restrict access to your box using IP
firewall services (ipfw).
● Buffer overflow attacks. What to do.

● Log events and understand your logs.

● Install intrusion detection software.

● Back up your server' s data!

● Think about physical security.

● Test your security model.

● Don' t forget about your clients.

11
 Some resources
As part of the books for this class you will
be given:
Practical Unix & Internet Security, 3rd Edition
http://www.oreilly.com/catalog/puis3/index.html
There are many other useful publications at:
– http://www.oreilly.com/
– http://www.aw­bc.com/catalog/academic/discipline/0,,69948,00.html

Be sure to take advantage of this book to learn

about the philosophy of security,
particularly in the UNIX world.
12
 Some more resources
We've setup a repository of security
resources and references with some
examples here:
– http://nsrc.org/security/
In addition, for more advanced topics
see:
– Linux Server Hacks by Rob Flickenger
from O'Reilly.
– Network Server Hacks by Andrew Lockhart
from O'Reilly.
13
 Security from the start
Make sure a server is secure before you
connect it to your network.
Consider that you may experience some of
these types of attacks:
Passive attacks:
­ e.g. Packet sniffers, traffic analysis (ngrep, dsniff).
Active attacks:
­ e.g. Connection hijacking, IP source spoofing,
exploitation of weaknesses in IP stack or applications.
Denial of Service attacks: e.g. synflood.
“Man in the middle” attacks: Hijacking services.
Attacks against the network itself: e.g. smurf.
14
 Understand what you are doing
A bad security solution is worse than no
security at all. False sense of security.
Know what you are doing:
– Read all the documentation.
– Read sample configurations.
– Build test machines.
– Ask questions (don' t be shy!).
– And, to repeat, join the announcements and/or
security mailing list for your O/S and
applications.

15
 Step­by­step practical items
We' ll go through each practical security
item mentioned with some pointers
and a possible hack or two.
Remember, we are discussing a server­
based environment. For a desktop or
laptop you would adjust accordingly.
Some of these items apply more to Linux
vs. FreeBSD, but all apply in general.

16
 Run only the services you plan on using

What is being started at system startup?

– grep YES /etc/defaults/rc.donf
– grep YES /etc/rc.conf
– ls /usr/local/etc/rc.d
– /etc/inetd.conf
Delete services you are not using.
– Change “YES” entries in rc.conf to
“NO”
– Remove /usr/local/etc/rc.d start
scripts.
– Comment out services in
17 /etc/inetd.conf
 Run only the services you plan on using
cont.
To see what is running use:
– lsof -i
– netstat -an -f inet
– ps -aux | more
– sockstat -4
Know what each and every item is.
Simplify, simplify, simplify – remove
any and all services you are not using.

18
 Run only the services you plan on
using cont.
Some services that often run that you
might want to remove include:
– rpc, rpc.mountd, rpc.nfsd (nfs support)
– smbd and nmbd (Samba Windows fileserver)
– automount (mount filesystems when accessed
under Linux_)
– named (DNS server)
– inetd (old­style tcpwrappers)
– telnet rlogin, rexec, ftp (not encrypted!)
– finger, comsat, chargen, echo, identd (id cmds)
– sendmail
19
 Run only the services you need
What do we mean by this? Really this
means, more or less, the following:
– Think through what it is you are providing
to your clients.
– Is there some other way to provide a
service that is more secure?
– Should you separate out services to more
than one server?
● NFS or Samba or shell access? FTP?
20
 Services you should run
cryptographically
● POP/IMAP with SSL only.
● Consider TLS­Enabled SMTP.
● Remove Telnet replace with SSH.
● Remove FTP replace with SCP or SFTP.
● Anonymous FTP is OK, but be careful if
you allow user uploads.
● Require HTTPS (HTTP over SSL) for
sensitive information.
21
 Stay up­to­date and patch
services as needed
Be sure that you track all the services you
are running.
– If you run Bind, Apache, and Exim
then subscribe to the appropriate
security mailing lists for each.
– Subscribe to generic security mailing lists
that pertain to your OS or Linux version.
– Subscribe to general security lists.

22
 Consider if some services should
run under the inetd tcpwrapper
● Access control for services is done in /
etc/hosts.allow (hosts.deny is
deprecated).
● /etc/inetd.conf determines what
services will run under the inetd
wrapper.
● What does inetd provide? ==>

23
 What does inetd provide?
● The inetd daemon (service) listens for
network packets for each service started in /
etc/inetd.conf.
● inetd saves on memory and resources as a
service is only started if a packet arrives for
it, but it'
s better not to use inetd for a loaded
service like http.
● You can control how packets arrive or don't
arrive on a service­by­service basis in a
detailed manner using inetd.
24
 inetd vs. iptfw
● iptfw permits full control over packets
arriving for a service or server.
● ipfw provides a more complete ruleset that
you can apply to a service, including more
fine­grained control over icmp and udp
packets.
● ipfw is part of the kernel, thus it is more
efficient.
● inetd has (imho) an easier syntax to
understand.
25
 More inetd information
If you are interested in all the parameters
you can specify on a service­by­service
basis in both /etc/inetd.conf and
/etc/hosts.allow, and when you start
the inetd daemon, then see:
– man inetd
– man hosts_access
– man hosts_options

26
 Restrict access to your box using IP
firewall services (ipfw)
FreeBSD 5.2.1 implements ipfw version 2 – a
kernel­level packet filter.
Details on using ipfw are in section 14.9 of the
FreeBSD Handbook.
You must configure the kernel for ipfw and
recompile. Relevant options are:
– options IPFIREWALL
– options IPFIREWALL_VERBOSE
– options IPFIREWALL_VERBOSE_LIMIT=10
– options IPFIREWALL_DEFAULT_TO_ACCEPT
27
 Firewalling cont.
From the Handbook:
The configuration of the IPFW software is done through
the ipfw(8) utility. The syntax for this command looks
quite complicated, but it is relatively simple once you
understand its structure.
There are currently four different command categories
used by the utility: addition/deletion, listing,
flushing, and clearing. Addition/deletion is used to
build the rules that control how packets are accepted,
rejected, and logged. Listing is used to examine the
contents of your rule set (otherwise known as the chain)
and packet counters (accounting). Flushing is used to
remove all entries from the chain. Clearing is used to
zero out one or more accounting entries.
28
 Firewalling cont.
To use ipfw you should place ipfw rulesets
in /etc/rc.conf.
Logging is recommended when you first
build your ipfw ruleset to help debug
what you are doing.
A couple of example ipfw rules:
ipfw add deny tcp from evil.doers.org to nice.people.org 22
ipfw add deny log tcp from evil.crackers.org/24 to nice.people.org

We explain these on the next page ==>

29
 Firewalling cont.
This command will deny all packets from the
host evil.doers.org to the ssh port of the host
nice.people.org:
ipfw add deny tcp from evil.doers.org to nice.people.org 22

The next example denies and logs any TCP

traffic from the entire crackers.org network (a
class C) to the nice.people.org machine (any
port).
ipfw add deny log tcp from evil.crackers.org/24 to nice.people.org

30
 Firewalling cont.
Before starting:
● Read FreeBSD Handbook on ipfw
● Read “man ifpw”
From the FreeBSD Group:
● Block all access to ports below 1024
● Block all incoming UDP traffic (controversial?)
● Block access to port 6000 if you use X.
● Block access to all internal server ports (MySQL =
3306, etc).
31
 Where to find some security
mailing lists
General security mailing lists:
● BugTraq: http://www.securityfocus.com/
● CERT: http://www.cert.org/
● Rootshell: http://www.rootshell.com/
For Apache, Bind, Exim and SSH:
– http://www.apache.org/
– http://www.isc.org/ (Bind)
– http://www.exim.org/
– http://www.openssh.org/
FreeBSD Security Notifications Mailing
List:
32 ­ http://lists.freebsd.org/mailman/listinfo/freebsd­security­notifications
 Patching your software
As needed download patches for the
services you run. You should be notified
of these via the mailing lists mentioned.
For your OS the vendor will often provide
specific patches or update installers.

33
 Software patches cont.
In general you can either apply a patch
directly to installed software if:
– You have the original source for the software, and
– You plan on building the software from source.
Otherwise, the software vendor may
supply an “updated” version of the
software in installer (pkg) form.

34
 Use secure passwords and
force your users to use them
First, there are some issues to consider:
– “Bad” passwords can be guessed.
– If passwords become too complex,
then users tend to write them down.
– Passwords sent unencrypted can be
“sniffed” from the network and
reused (consider the case of dsniff).
So, enforce strong passwords and don' t
run services that are unencrypted.
35
 What is a “good” password
● Combination of upper and lower­case
letters, numbers and symbols.
– Brute force attacker has to try many more
combinations.
●Not in any dictionary, including hackers
dictionaries.
Two samples of creating a good password:
$40&yc4f
"Money for nothing and your chicks for free"
wsR!vst?
"workshop students aRe not very sleepy today ?"
36
 How to enforce good passwords
You can use cracklib with Pluggable Authentication
Modules (PAM).
Cracklib keeps a user from creating trivial passwords.
You can find cracklib here:
– /usr/ports/security/cracklib
You should enable it here:
– /etc/pam.d/passwd
Cracklib is not enabled by default in FreeBSD – it is in
many Linux distributions.
37
 Controlling your users
Here are some practical tips, and...

Look in to /etc/login.conf if you wish to

define login classes for your users to
control their access to resources.
See Section 13.7 of the FreeBSD
handbook for details.

38
 Cracklib
From “locate cracklib” on a Fedora Core 2
machine:
/usr/lib/cracklib_dict.hwm
/usr/lib/cracklib_dict.pwd
/usr/lib/cracklib_dict.pwi
/usr/share/doc/cracklib-2.7
/usr/share/doc/cracklib-2.7/MANIFEST
/usr/share/doc/cracklib-2.7/HISTORY
/usr/share/doc/cracklib-2.7/LICENCE
/usr/share/doc/cracklib-2.7/POSTER
/usr/share/doc/cracklib-2.7/README
/usr/share/doc/cracklib-2.7
/usr/share/doc/pam-0.77/txts/README.pam_cracklib
/lib/security/pam_cracklib.so
As you can see cracklib is installed, a cracklib
dictionary, and the PAM cracklib shared library.
39
 Cracklib password checks
Taken directly from the cracklib README file:
4) it's MIND-NUMBINGLY THOROUGH!
(is this beginning to read like a B-movie flyer, or
what?)
CrackLib makes literally hundreds of tests to
determine whether you've chosen a bad password.
It tries to generate words from your username and
gecos entry to tries to match them against what you've
chosen.
It checks for simplistic patterns.
It then tries to reverse-engineer your password into a
dictionary word, and searches for it in your
dictionary. (> million entries!)
- after all that, it's PROBABLY a safe(-ish) password.
8-)
40
 Other password checkers
Some tools you could run against /etc/shadow after
password generation for more thorough testing.
– John the Ripper: http://www.openwall.com/john/
– Crack: http://www.crypticide.org/users/alecm
– Slurpie: http://www.ussrback.com/docs/distributed/
(URL may not work)
You would create a cron entry to run a process against
some/all user passwords once every certain period.
“Cracked” passwords would generate an email
warning to the user asking them to change their
password or be disabled.
41
 Consider if you need to use quotas
● Can you trust your users?
● What happens if /tmp or /home fills?
● Are these on separate disks or
partitions?
● If not, you might want quotas.
● Quotas have been updated to version 2
in Fedora Core 2.

Practical quota tips ==>

42
 Practical quota tips
General Steps to Activate:
– Recompile kernel with “options QUOTA” in your
kernel configurtation file.
– Enable quotas in /etc/rc.conf with:
enable_quota=”YES”
– Enable group and/or user quotas in /etc/fstab:
/dev/da1s2g /home ufs rw,userquota,groupquota 1 2
– Use edquota to update the quota.user and
quota.group files in the root directory of each
quota­enabled file system.
– Commands include quota, quotaon/quotaoff,
43 quotacheck, edquota.
 Restrict root access to a minimal
set of services
Check for files with setuid/setgid bits
running as root. If you don' t need these
files, or users don't need to run them,
then remove this bit (permission).
Consider running a service in a
“sandboxed” environment using chroot.
Consider running a service under a
different userid if possible.

Practical restriction tips ==>

44
 Practical root restriction tips
To find all files with setuid or setgid bits
set on a machine you can do:
– find / -perm +6000 -type f -exec ls -ld {} \; >
setuid.txt &
You'll have a file listing all setuid/setgid files (but not
scripts) on your machine.
Use chroot to run services with their own
root directory – i.e. in a “sandbox” or
“jail”.
You could consider running BIND in a
45
chroot jail. We'll ask Joe what he thinks...
 Bind in a chroot jail
From Linux Server Hacks by Rob Flickenger:
As root create a “named” user and group (if needed):
– groupadd -g 25 named
– useradd -u 25 -g named -c “chroot BIND user” \
-d /var/named/jail -m named
Now create the skeleton directory structure where named will run:
– cd ~named
– mkdir -p var/{run,named}
– cp -Rav /var/named/data var/named/
If you are acting as a slave for any zones then create a writeable
directory for this:
– mkdir var/named/slave
46 – chown named.named var/named/slave
 Bind in a chroot jail
Created dev/ and etc/ directories and copy critical system files:
– mkdir {dev,etc}
– cp -av /dev/{null,random} dev/
– cp -av /etc/{localtime,named.conf,rndc.key} \
etc/
Fix ownership and permission on these directories
– chown root.root .
– chmod 0755 .
– chown named.named var/named/data/
– chmod 0700 var/named/data/
– chown named.named var/run/
Update syslog if used for DNS logs:
47 – syslogd -m O -a /var/named/jail/dev/log
 Bind in a chroot jail
Now see if named can run in this environment:
– /usr/sbin/named -u named -t /var/named/jail \
-c /etc/named.conf
If you have problems look in /var/log/syslog or /var/log/messages,
and from /var/named/jail check your directories with:
– ls -lR
In the end BIND can still be compromised, but damage is
contained (in theory) to the /var/named/jail directory
structure.
Be careful about what you copy to a jail area as all items can be
used in case of attack.
If you need to find what libraries a binary needs you can do
“ldd /dir/binary”.
48
 How apache runs as user “apache”
Taken directly from /etc/httpd/conf/httpd.conf:
# If you wish httpd to run as a different user or group, you
# must run httpd as root initially and it will switch.
#
# User/Group: The name (or #number) of the user/group to run
# httpd as. . On SCO (ODT 3) use "User nouser" and "Group
# nogroup". . On HPUX you may not be able to use shared memory
# as nobody, and the suggested workaround is to create a user
# www and use that user.
# NOTE that some kernels refuse to setgid(Group) or semctl
# (IPC_SET) when the value of (unsigned)Group is above 60000;
# don't use Group #-1 on these systems!
#

User apache
Group apache
49
 Buffer overflow attacks
A Cracker pushes more data on to a services
buffer than space provides. They can “break
out” of the program space and execute
arbitrary commands on your system with
the privileges of the compromised service.
Many security patches deal with newly
discovered buffer overflow holes.
Solutions to this include GCC compilers such
as ProPolice from IBM and Stackguard from
immunix.org and running fewer services!
50
Another solution is LibSafe from Avaya Labs.
 Log events and understand
your logs
This is time consuming – even with the many
tools that are available.
You need to go through each service running
and decide if you want to log events from
this service. This has been partially done for
you in /etc/syslog.conf under Fedora Core 2.
Ideally logs should be created or saved off
your server. A cracker will alter your logs to
cover their tracks.
51
 Logging continued
You should consider setting up automated
warning systems. Under Fedora Core 2
logwatch runs by default and sends a
summary report via email to root once a day.
To configure what is logged read “man
syslog.conf” for full details on how this file is
formatted.
Consider using a central logging server. You
can use /etc/syslog.conf to send events to
another server via your network.
52
 Yet more logging...
A few useful tools to monitor activity:
– Swatch: Simple WATCHer is available from
http://swatch.sourceforge.net/ and will watch for “trigger”
events in your logs and notify you immediately.
– Process accounting: turn this on under Linux to keep track
of who has done what. Fedora Core 2 does not install this.
– logwatch and logrotate: read up on both of these “man
logwatch” and “man logrotate” to understand how
they work and what they do. Under Fedora Core 2 both are
run automatically each by cron (see /etc/cron.daily).
– See http://nsrc.org/security/#logging for some more tools.

53
 Networking monitoring/logging
A few useful network monitoring tools:
– httptop: can give you real time monitoring of your web
traffic. Find this from http://examples.oreilly.com/.
– Nagios: monitors services running on hosts on your
network as well as resources. Can monitor you of events
via email, pager, etc. Find this at http://www.nagios.org/.
– nmap: network exploration tool and security scanner can
identify machines and services on your network. Find this
at http://www.insecure.org/nmap/.
– ntop: from http://www.ntop.org/ gives full featured
protocol analysis of who' s talking to whom on your
network. Includes graphical reports and web interface.
Caveat: these tools can get you in trouble. Be
54
sure you have permission to run them.
 Install intrusion detection software
● Intrusion Detection System = IDS
● Network Intrusion Detection System = NIDS

● And, System Integrity Checking is a generic term for

this.
An IDS monitors network traffic and warns if
suspicious behavior is detected.
A System Integrity Checker looks for changes to files
that are not expected and warns you of these.
Tripwire from http://www.tripwire.org is the best
known of these. It monitors binary signature, size,
expected change of size and more of files.
55
For a list of many tools see http://nsrc.org/#integrity
 Snort intrusion detection system
Snort from http://www.snort.org/ is a very
popular tool to detect unexpected network
events using a known set of rules and
patterns. This is a signature­based IDS.
Additional Snort add­ons include:
– ACID: Anaylsis Console for Intrusion Databases. Web front­
end to IDS alert database(s). Good for large site. From
http://acidlab.sourceforge.net/.
– Sguil: Snort GUID for Lamerz. Complex system to analyze
possible IDS events with tools such as ethereal and TcpFlow as
well as Snort. From http://sguil.sourceforge.net/.
– Snort_inline: from http://snort­inline.sf.net/. Detect
intrusions and react to them.
– SnortSam: from http://www.snortsam.net/ to update firewalls
56
on the fly to deal with attacks.
 Back up your server'
s data!
Pretty hard to stress this more. If your security
is compromised what will you do without a
backup? A few basic items to consider are:
● What needs to be backed up.
● How often do you need to backup?
● Where will your backup media be in case of
disaster (fire, flood, earthquake, theft)?
● What happens in case of total loss?
● What tools will you use? Tar, Arkeia, cpio?
57
 Detailed considerations for backing
up your server's data
● What do you want to backup?
● What do you need to backup?
● How often must you backup:?
– User data
– System configuration files
– Operating system files
● What is the backup rotation? Daily, weekly, monthly, semi­annually, yearly?
● What type of backup media are you going to use?
● Will you use the same media and software for each piece of your backup process?
● Where will you backup your data?
● Where will you keep copies of your backups?
● Have you tested your backups? I.E. have you tried a restore?
● What will you do if you lose your server? Do you have a place to restore your data
58 in this case?
 Tools to use for backups
● Arkeia: commercial product:
– http://www.arkeia.com/
– http://nsrc/security/#backups
● dd: convert and copy a file.
– man dd
– dd if=/dev/hda of=/dev/fd0/bootsector.bin bs=512
count=1
Backs up a boot sector to a floppy.
– dd if=/dev/fd0/bootsector.bin of=/dev/hda bs=512
count=1
Recovers from floppy to hda. Be very careful doing this!
59
 Tools to use for backups cont.
● cpio: copy files to and from archives:
– cpitool: http://www.nickb.org/utils/
– man cpio
● dump: ext2/ext3 filesystem backup.
– man dump
● rsync: remote copy.
– man rsync.
● tar: read
60 – man tar (scary!)
 A few practical backup tricks
You can use ssh and tar together to quickly
backup parts of your server. For instance, to
backup all /home directories to another
server as a single image:
– root@machine1# tar xzvf - /home/ | \
ssh machine2 “cat > machine1-homes.tgz”
Or, you can use rsync over ssh if you wish to
keep directories synchronized between two
locations:
– rsync -ave ssh remote:/home/docs .
61
 rsync with ssh and ssh keys
Later today we'll discuss ssh and the use of ssh keys to
connect to a remote machine without passwords
and use encryption.
Image if in /etc/cron.daily/sync­web you did the
following:
– rsync -ae ssh /var/www/html/ \
backup.machine:/var/www/html/
This recursively copies your root web documents to a
backup machine using rsync via ssh.
If you use the “­­delete” option in rsync, then files
removed on your local machine would be removed
on the remote machine as well when you run this.
62
 Think about physical security
All the security in the world does nothing against a
disgruntled employee, server sitting out in the open,
people who copy keys, and so on.
Backups: where do you physically keep your them? Who
has access to them. Are they separate from your server?
Logs: are they on a separate and physically secure log
server? Printed to a separate printer?
Bootloader password and encrypted files: what happens
if someone walks off with your machine?! Or, how
about just the hard drive(s)?
Physical access = total access
63
 Test your security model
Once you have in place what you believe
to be a secure server try connecting to it
from an external machine. Verify that
your security model works as expected.
Try circumventing your own rules.
Run a security scanner against your
server (your network as well?). A nice
tool to run against your server is
Nessus. You can find this product here:
http://www.nessus.org/
64
We'
ll take a look at this...
 Don'
t forget about your clients
Make sure that your users must connect to your servers
in such ways as to help ensure the integrity of their data
and their user accounts.
Insist on software clients that use encryption like SSH vs.
Telnet, SCP/SFTP vs. FTP, POP/IMAP over SSL.
Human clients running their OS' es... Dealing with
Windows security issues such as viruses, Windows
Updates, worms, spyware, etc...
Virus scanning software to defang email on your server?
Scripts as well – can rename files like .exe, .pif, .com, .
scr, .vbs, .bat to fn.ft.txt.
Social issues. Security is inconvenient. For instance,
Windows still does not ship with SSH – ouch!
65 We'
ll take a look at “securing” a Windows 2000 box now...
 Remember these resources
CERT (Coordinated Emergency Response Team)
● http://www.cert.org/ and http://www.us­cert.gov/cas/index.html
Nice List of Security Resources for Linux/UNIX
● http://www.yolinux.com/TUTORIALS/LinuxSecurityTools.html
nmap: Network exploration tool and security scanner
● http://www.insecure.org/nmap/
O'
Reilly Books
● http://www.oreilly.com/
SANS Computer Security and Mailing Lists
● http://www.sans.org/ and http://www.sans.org/newsletters/risk/
Security Documents from nsrc.org
● http://nsrc.org/security/ and http://nsrc.org/freebsd­tips.html

And, don'
t forget your own local help at http://www.sanog.org/!
66
 More Resources
The FreeBSD Handbook Security Section
● http://www.freebsd.org/doc/en_US.ISO8859­1/books/handbook/security.html
FreeBSD Website “intrusion detection” Software
● http://www.freebsd.org/cgi/ports.cgi?query=intrusion+detection&stype=all
FreeBSD Security Notifications Mailing List
● http://lists.freebsd.org/mailman/listinfo/freebsd­security­notifications
Security Documents from nsrc.org
● http://nsrc.org/security/ and http://nsrc.org/freebsd­tips.html
CERT (Coordinated Emergency Response Team)
● http://www.cert.org/ and http://www.us­cert.gov/cas/index.html
SANS Computer Security and Mailing Lists
● http://www.sans.org/ and http://www.sans.org/newsletters/risk/
Nice List of Security Resources for Linux/UNIX
● http://www.yolinux.com/TUTORIALS/LinuxSecurityTools.html
Nessus Security Auditing Package
67 ● http://nessus.org/
 Summary
● Be sure you understand what you are doing.
● Start with some useful books, such as:
– Practical Unix & Internet Security, 3rd Edition
http://www.oreilly.com/catalog/puis3/index.html
– Linux Server Hacks, Rob Flickenger, O' Reilly books.
– Network Security Hacks, Andrew Lockhart, O' Reilly books.
● And, as a reminder, here are the practical security items we
started with:
– Run only the services you plan on using.
– Use only the services that are necessary.
– Stay up­to­date and patch services as needed.
– Use secure passwords and force your users to use them.
68
 Summary cont.
The practical security items we started with cont:
– Consider if you need to use quotas.
– Restrict root access to a services.
– Restrict access to services via tcpwrappers if appropriate.
– Restrict access to your box using IP firewall services (ipfw).
– Buffer overflow attacks. What to do.
– Log events and understand your logs.
– Install intrusion detection software.
– Back up your server' s data!
– Think about physical security.
– Test your security model.
– Don' t forget about your clients.
69
 Summary cont.
We have not discussed Windows vs.
Linux/UNIX security in this presentation.
In general – With Linux/UNIX you can see
what is happening or what is broken. Under
Windows you may not have access to that
which you are trying to secure or fix.
For fun/pain see:
– http://darkwing.uoregon.edu/~hervey/secure­w2k.html
– http://nsrc.org/isp.html#server
70
 Conclusion
More security means less convenience,
but a security breach can be the least
convenient moment of all.
There is always a tradeoff between how
much security you put in place and
what services you are providing.
Your users may grumble, but they'll really
grumble if their data is compromised –
Remind them of this :­)
71