MIS Security Check-list
Consider your entire organization
When considering security, the best way to avoid obvious breaches of security
is to capture the big picture of your installation. Practically, this means
that you should work from the outside in, ie. consider security of the
building and area, then the actual offices, followed by the network infrastructure,
and end with hosts themselves. It's a bit pointless to spend a lot of time
securing hosts if anyone can walk into the server room and walk out with
a host under each arm. Those things do happen. This is all the more important
since most of computer crime is perpetrated by insiders, for obvious ease
of action and lack of interest to hackers about the average corporate data.
Because it is more exciting to most system administrators, computer books
usually concentrate on securing hosts, but sound computer security doesn't
deal with just individual computers. You must consider your entire organization.
Prepare for disaster
Generally speaking, check for any single point of failures in your environment,
and provide backup solutions. Perform dry runs regularly to make sure everyone
knows what to do in case of a breakdown. Post-incident plans must be updated
whenever any change is made to your site, and as much as possible, everyone,
especially MIS personnel, must be capable of performing the procedures.
Plans should also include procedures to solve day-to-day MIS activities,
like installing a new host, welcoming a new employee, etc. Also, whenever
possible, use fail-safe tools, ie. should the device fail, they should
refuse access instead of letting people in.
A firewall is not the magic bullet to securing a site. Generally speaking,
try to place as many barriers as possible between valued asset and a potential
adversary, without this security being too invasive to employees. Remember
that an effective security policy requires that every single employee abide
by it, and not just the rank-and-files.
The more prepared you are to handle break-ins and disasters, the better
for the image of the company and the MIS team. In addition, your company
may be held responsible legally if your network was used by hackers to
launch attacks on other sites. You might want to hire an outside company
to test your security at random times.
A usage policy is an important user-oriented document, not just to cover your ass in case someone in your organization steals information that is off-limit for them, but also because it forces you to think about how your organization works from an MIS point of view.
A security policy is more MIS-oriented than the user policy, and its goal is to offer a big picture view of security of your organization.
Keep in touch with local police authorities about robberies in your area,
as thieves are likely to keep using a tactic if it proved successful in a
location (eg. burglars pretending to be couriers and stealing unattended
portable PCs.) Update this list accordingly, and warn users about those new
risks. Also, check with authorities what the regulations are about setting up
an alarm system at your site, and whether it can be set up to call up the
police automatically when the alarm goes off.
Doors and windows
- All entrances must be equipped with secure locking devices that cannot be
circumvented (key locks, dead bolts, cipher locks, etc.), and hinge pings that
are spot-welded or otherwise protected
- Doors must be constructed of sturdy material (steel, solid core wood),
must not exceed the number for safe and efficient operation, and must always
be secured when not in active use
- All ventilators or other possible means of entrance must be covered with
steel bars or wire mesh grill
- All windows must be securely fastened from the inside. Windows accessible
from the ground or located on roofs must come with window/glass tamper or
breakage protection features, and be protected by steel bars or grill
- Check that blinds and shades are available to hide valued items from the outside
Locks and keys
- Set up security patrols at random hours during the day, and end-of-workday
- Check with local police authorities if day- and night-time patrols are
scheduled in the neighborhood
- Access control cards must be clearly different for company personnel and visitors
- Provide escort for visitors
- If multiple corporate sites, inter-connect security systems to increase
monitoring of sites located in different time zones, and to make travel easier
by providing only one electronic badge to each employee
- Only MIS personnel should have access to the server room
- Grant users access with the least amount of privilege required to
accomplish their job, using user profiles to manage accounts more securily
- Check the log files created by the application running the electronic locks
- Set up a procedure to monitor use of all locks and keys. Update when necessary
- Keep tracks of keys issued, with their number and identification, for both
master keys and duplicate keys
- Keep records of use and turn-in of keys, and check locks quarterly
- Change locks immediately upon loss or theft of keys
- If used, master keys must be devoid of marking identifying them as such
- Only issue keys to authorized employees. Other must use an electronic badge.
- Keys not in use must be secured in a locked, fireproof safe that is
secured to prevent removal
- When making duplicates of master keys, mark them "Do Not
Duplicate" and obliterate manufacturer's serial numbers
- Any visitor, either a corporate employee from another site or an outside
guest, must warn MIS of his/her visit as early as possible, so as to provide
adequate security (ie. some guest might need to be allowed in areas that are
off-limit to standard guests.)
- Employees from other sites and guests must provide the following
information: Name, Location, Visit Start and End Dates, Arrival Time, Access
Needs Greater than Week Day (7 AM - 7 PM), Buildings to be Visited (if
known), Employee e-mail address, Name of manager, Point of Contact at local site
- MIS must be informed of loss of access control card ASAP so as to disable
access and provide a new, safe badge
- Guests must return their visitor access control card upon leaving the premises
- MIS must conduct periodical security inspections, and report any problem
so as to implement corrective action
- Set up either television recording, burglar alarm, or intrusion alarm
systems linked to off-site security team. Test them regularly
- Make sure the television system can record a minimum of four days
- Check that the alarm systems are backed up automatically, and have an
alternate or independent source of power available to cut in and operate automatically
- Provide adequate protective lighting for all areas
- Mark emergency routes clearly
- Write procedures for emergency evacuations (fire, bomb threats, etc.), and
exercise plans regularly
- Train users in fire fighting
- Provide response to medical emergency (phone numbers to local medical
facilities; first aid supplies)
- Provide electronic-friendly sprinklers in or over the data center/server rooms
- No possible leaks over computers, especially server room (water pipes,
sprinklers, AC units)
- Alarm systems must be tamper- , and weather resistant
- Provide security personnel trained in physical security
- Set up procedure to respond to alarms, including night-time and week-ends
- The monitoring system must provide sufficient information to investigate
any break-in, and remedy
- Check that fake floors and ceilings cannot be used for break-ins
- Check that fire extinguishers and other fire fighting equipment are in
sufficient number, that they match the type of fire they would be used to put
off, and that they're properly secured on walls (no extinguisher lying around)
- Install air conditioning to keep hosts (and users :-) cool, at least in
the server room
- Have someone come in at least once a year to maintain AC units
- Set up thermometers linked to monitoring software to check the temperature
in the server room, and have it page/call or send e-mail if temperature rises
- In a large site, use a naming convention for rooms (eg. country names, etc.) and a cabling management software to make sure everyone understands which room and which plugs you mean
- Use asset management software to assure strict accountability of all
- In highly-sensitive locations, make sure guests are either restricted to
safe areas, escorted at all times, and that their bags are checked when they
depart (Welcome to Intel :-)
- Consider printing sensitive information on easily identifiable paper (eg. yellow, orange, or red paper, depending on its importance), and forbid employees
to go off-site with top sensitive documents
- Guests must sign a log when they visit, and register their laptop computers and camera (manufacturer and serial #.)
- Make sure there's always personnel available to watch entrances, and that they can call security and send an immediate message to everyone in the building should someone try to walk into the office unauthorized (especially important during lunch-hour and late at night)
- Make sure video cameras connected to VCRs are pointing at all exits to help police authorities investigate break-ins
- Monitor your WAN links through MRTG, and your LAN through netstat -i (watch for the collision/outpackets, outerrs/outpackets, and inerrs/inpackets ratio)
- Use proxy servers to control use of bandwidth and to hide information about your private network
- Set up an alternate, anonymous connection to the Net to let users find information for yet-unannounced products, as the competition could use this information to tell what your company is working on
- Run monitoring software like Linux-based Netwatch to keep a eye on the use of network bandwitdth, especially on what servers on the Internet users are connecting.
- Install an intrusion detection server on all servers, both in the DMZ and in the internal network, and do not ignore traffic coming from your internal network. Consider putting a sensor both on your public routers and firewalls so as to be warned of any suspicious traffic
- (Unix) Do not run NIS if you can avoid it, or consider NIS+. Consider centralized authentication systems like Kerberos, or Samba
- Have agents run on all servers, so as to keep an eye on log files, disk space, etc. They could consist in Perl or Python scripts, as those have been ported to different environments and offer a rich amount of modules that avoid your reinventing the wheel
- If you discover that some hosts have been hacked, and you'd like to get in contact with people on remote sites (eg. a host from which the hacker seems to have connected, or MIS personnel at other corporate sites, etc.) to try to catch him red-handed, either use the phone, set up a brand new mail server, or use encrypted e-mails through PGP/GnuPG, as the hacker may have set up tools to snoop on your network, and be warned of your plans.
- Remind users that downloading binaries is either forbidden by corporate policy, or, if possible, should be scheduled at night to make the most of the corporate link to the Net.
- Set up some hosts loaded with anti-virus software and that can be easily removed from the network to test software downloaded from the Net. Encourage users to p
- Encrypt all network traffic, especially the one flowing on public LANs, unprotected by firewalls. This can be done at different network levels (magic words are SSL/SSLey, S-HTTP/HTTPS, IPSec/CIPE, L2TP/PPTP/PoPToP, S/MIME, APOP, SSH, STelnet, PGP/GnuPG, proxy servers, VPN, etc.)
- Run a live messaging application on all hosts (eg. WinPopup or ICQ) to reduce work disruption while allowing for broadcasts when needed (ie. a suspicious individual is in the building, or the mail server just crashed). Some PBXs lets you use the loudspeaker of digital phones as a PA system.
- In case your site is ruined by a fire, a flood, or physical break-in, either provide a fully-equiped temporary location, or check how long it would take to be provided with new or temporary equipment by a commercial supplier or other corporate sites
- If your site is connected to remote sites through alternative links besides the Internet, make sure those sites also keep an eye on security, as breaches of security there could easily end up jeopardizing your own site
- Remember that any unsecure host on your network can be used to launch an attack on other resources, whether they are located on your LAN, on other corporate sites connected through WAN, or foreign sites on the Internet. As the Melissa and ILOVEYOU viruses have shown, security is only as strong as its weakest link.
- Add an IDB (ISDN Dial Backup) unit to your routers that goes up should your permanent connection go down. Test it regularly.
- Used a dynamic firewall (eg. Abacus/Port Sentry)
- Keep a current backup of all data files that your company cannot afford
losing after a computer goes south
- Keep an ad hoc step-by-step restore procedure current, update it every
time you change the configuration of a host, and perform regular restores on
bare-metal systems at a remote site to prepare to see your location ruined by
a fire or flood
- Do not keep the latest backup tapes in the location, as you'll need them
after a fire or flood. Either take them home every night, leave them in a
magnetic media-friendly safe at a nearby bank, or have a courier pick them up
at night. Watch out for magnets (heated car seats, monitors, washing machines,
etc.) and safes that are not meant to protect magnetic media
- If resorting to a courier solution, consider encrypting data. Make
sure you can decrypt tapes on a bare-metal system after your site has been damaged
- Perform frequent restores of a few files to check that the backups
- Remember to clean drive heads regularly, and stop using tapes that show
too many access errors
- As backup jobs use a lot of bandwidth, consider setting up a SAN instead
- Check if you really need walk-up network connections. If not, no rogue,
unused network plug. Could be used to set up a host to sniff passwords. Unplug
any unused network connection on the patch panel, and set up DHCP server to
not give out IP addresses to unauthorized hosts.
If you do need such access, consider limiting it to a restricted local LAN
connected to the rest of the network through a firewall + bastion host to
limit access only to limited services. If possible, keep an up-to-date list of
unused network plugs, and have a monitoring program warn you immediately when
a connection goes up
- Check out authentication systems like challenge/response, one-time
passwords (PAP/CHAP, S/Key, etc.), time-limited tickets (Kerberos), smart card
or finger-print based systems
Routers - Firewalls - Switches
- Run Antisniff to try to see if a host is sniffing the network
- Run tools like Nessus to check what your firewall and routers can withstand (eg. crashing when receiving severely mangled packets)
- Check out reverse path filtering to prevent IP spoofing
- Set up hubs to forbid hub-mode on ports (ie. letting a host listen to all traffic by setting up the port it's connected to from switch- to hub-mode); Assign a MAC address to each port (ie. if only one host is connected to a given port)
- Assign descriptive host names in the DNS to make logs more meaningful (eg. 174.los-angeles-63-64rs.ca.dial-access.att.net)
- All incoming connections from on-the-road employees through the Internet
must use SSH and related tools to ensure encryption
- Check ACLs on routers and firewalls. Start by closing all services, and
only open those you really need and understand. Especially remember to disable
telnet access from the Net.
- Ban any packet coming from the Internet whose source address pertains to
the private ranges (10.x, 172-16/31.x, 192.168.x)
- Set up routers and firewalls to log infos to the same central host running
syslogd that other hosts are using
- Do not just rely on ACLs on routers, ie. filtering routers. A
context-based firewall is much more secure, especially for UDP-based
applications (Three basic types of firewalls: network-level (screening
routers), application-level (proxy servers), and circuit-level firewalls (eg.
Cisco PIX) )
- As IPChains is not stateful, your network can be endangered by UDP or ICMP packets. Consider buying a stand-alone, stateful firewall instead.
- Use SNMP-capable switches to monitor network use
- Use bandwidth control tools like Packeteer to prevent denial of service by
programs gone haywire
- Prefer stand-alone firewalls like Cisco PIX over PCs. They have fewer
moving parts (cooling fans are just about the only mechanical part), so
present less risk of breaking down, and are less likely to run other software
besides the firewall part, hence less security risk.
- Consider using a Radius or Tacac authentication server to centralize the
task of authentication users. Generally speaking, aim at using SSO (Single
Sign-On) architecture to reduce the number of login/passwords used. Besides
Radius and Tacac, take a look at Samba, NIS, NDS, Kerberos, LDAP, and PAM,
digital certificates, smart cards, hardware tokens, or even biometric devices
- Evaluate different methods to hide your private network: masquerading,
packet filtering, transparent proxying and Fast NAT. Implement both proxies or
packet filters, to force users to use proxying
- With switched technologies, use Permanent Virtual Circuits or Closed User
Groups whenever possible.
- Fight IP spoofing coming from your by not letting out any packet whose source address does not belong to your network
- If your PBX can be configured remotely through a modem, change default password/code
- Check daily logs if available, especially regarding outgoing calls
(hackers using corporate phone system as relay)
- Set up security codes on all voice mailboxes, if available
- Add authentication for dial-out users. Do not allow dial-out from an
unauthenticated dial-in call
- If possible, run separate dial-in and dial-out modem spools
- Disable the use of the escape sequence +++ to switch to command mode, and
make sure modems cannot be reprogrammed remotely. Modems should be reset to a
standard configuration after each call
- Check that calls terminate cleanly, and that the server forces logout from
all active sessions
- Check that no useless RAS access is available (users setting up a modem on
their computer, unbeknownst to MIS; modems inside PBX to allow for remote
administration; modems still connected to the POTS that everyone forgot about, etc.)
- All RAS access must require login/password, and call-back if available
- Log Caller ID information if available
- Maintain an up-to-date register of all your modem lines and conduct
regular site checks for unauthorized modems (eg. automated connection on all
the phone lines available at your site to check for rogue modems installed by
users without noticing MIS)
- Set a short delay after the first and second failed logins, and force a
disconnect after the thirdto slow down automated password attacks. Don't
tell the user whether the username, the password, or both, were incorrect.
- Install a firewall on all hosts, including client hosts: Free solutions
for Windows are Tiny Software's Tiny
Personal Firewall, Zone Labs' ZoneAlarm,
and Sygate's Personal Firewall.
You'd be surprised at the number of spyware applications sending out information
to the Net without telling you...
- Once the firewall is set up on your network, test it regularly from
- Protect against buffer overflows (StackGuard, patch the Linux kernel, use the LIBSAFE set of libraries to protect binaries)
- Limit what kernel options can be changed while the server is up (eg. only root should be able to run
echo "1" > /proc/sys/net/ipv4/ip_forward)
- Require a password when booting in single-user mode
- Disable or restrict email relaying on your MTAs
- Run a cache DNS, especially on your MTA, so as to reduce the need for sending queries to a remote DNS, and allow for backup in case of short interruptions
- Mount as many partitions in read-only as possible. On Unix, use the noatime attribute in /etc/fstab.
- Set up hosts to limit use of resources (eg. /etc/limits.conf)
- Keep compilers and packagers on a removable device to make it difficult for someone to compile and/or install packages
- (Unix) Consider using xinetd to replace inetd + TCPWrapper
- (Unix) Remove all unneeded aliases in /etc/aliases (eg. games, etc.)
- Remove all unneeded user and group accounts
- On your mailer, disable the use of EXPN and VRFY commands
- Considering disabling remote reboot/shutdown, and limit this function for console connections
- (Unix) Disable host reboot through CTRL-ALT-DEL by commenting out the "ca::ctrlaltdel:/sbin/shutdown... " line in /etc/inittab
- (Unix) Chmod 0700 /etc/rc.d/init.d/* to keep users from checking out boot-time scripts
- Any failed attempt to connect should trigger an instant message (eg. ICQ) and e-mail
- Set up hosts to log users out or lock their screen after X minutes of no
activity, and have an e-mail sent to MIS so that you know who your reckless
- Disable command-line history log by adding HISTFILESIZE=0 in your local .bash_profile configuration file.
- No rogue hosts: Decommission any host that is no longer being used
- Do NOT connect a new host to the network until it has been thoroughly secured, especially if that host is connected to the public part of your network (ie. the DMZ in front of a firewall). It doesn't take long for hackers to locate such unsecure hosts.
- Disable services started up at boot-time by either deleting the symlink in /etc/rc.d/rcX.d, or by changing the leading letter from S to s.
- Use /etc/securetty to make sure that root can only log on through the console (eg. tty1, tty2, etc.) and NOT through the pseudo-terminals over the network (eg. ttyp1, ttyp2, etc.). It's much safer that users who telnet into a host first log on as a regular user, and su to root, as this switch is logged.
- Add legalese to /etc/issue to warn users, and hide which OS and version number is running.
- Use safe names for hosts, eg. names should not give away information on
their platform or OS version, although tools like nmap can determine the platform
you are running in different ways
- Take advantage of TCP Wrapper's /etc/hosts.allow and hosts.deny feature. Start by denying all access in hosts.deny, and only allow specific access in hosts.allow .
- Use the wheel group to specify who is allowed to su to root, and change the group ownership to su accordingly (eg. /etc/pam.d/su)
- Create locked /root/.rhosts /root/.netrc /etc/hosts.equiv files to avoid hackers from creating them (use touch followed by chmod 0)
- When creating a new user account, create locked ~/.rhosts, ~/.forward, etc. for added security
- Do not run unneeded binaries that run as administrator (eg. SUID/SGID in
Unix), and have your monitoring tool check for such files every night
- Check for all world-writable/everyone files and directories, especially
system configuration files
- Implement the undelete or chattr feature, if available on your system,
to make it easier for users to recover files deleted by mistake, or avoid
messing with them in the first place
- Take advantage of the extended attributes offered by the ext2fs to forbid changed to configuration files (eg. chattr +i /etc/inetd.conf)
- Only use an administrator account when absolutely needed, and even then,
consider using tools that let you perform only limited tasks as administrator
(eg. sudo). Make sure this tool does not run applications with shell escape,
thus granting a regular user admin rights
- Check that your PATH is secure, especially root's (ie. no ".", no writable
directories to avoid running bogus binaries upload by hackers, etc.)
- When running as root, get the habit of always using absolute pathnames
to executables (eg. /usr/bin/su instead of simply su)
- New files should be created with safe, default rights (eg. umask of 027
under Unix, and 077 for root)
- If available, set up program so run in chroot() to enhance security
- OS-permitting, build a host with different partitions on different hard
disks, to enhance performance and security (so a rogue program or hacker filling
up a hard disk and crashing this host)
- To install and upgrade programs, take advantage of package managers like
RPM to make it easier to know what packages are installed, and which version
- Once the host has all the packages you need, consider removing sensitive
tools that could be taken advantage of by hackers (compilers, etc.)
- Files exported through either NFS or Samba should be read-only as often
as possible, no root access, and prohibit users from running applications
- Set limits to how much RAM and processes are available to average users
- When installing a new closed-source software program, run a tool that monitors
sockets to check whether it's trying to upload information to the Internet,
unbeknownst to you
- Restrict physical access (BIOS password, secure cases to unable access
to jumper to reset passord, no boot from floppy drive, tamper-proof cable
to secure host physically to server room, etc.)
- When setting a password in the BIOS and using auto-shutdown UPS units (with
auto-reboot set in the BIOS when power returns), check whether the UPS application
can send the password over a wire. Otherwise, be prepared to drive to the
office in the middle of the night if power goes off at this inconvenient time.
- Boot loaders like LILO can also be set to prompt users for a password before
booting an OS, thus preventing the host to reboot automatically after power
- Users might want to affix a tamper-proof picture of themselves on their
laptop computer to reduce risk of theft
- In case you either lose the administrator password or it was changed by
hackers, learn how to boot as administrator to reset the password (eg. under
Linux, booting with linux single in
LILO; For NT, check the nifty utilities from Winternals.)
- On Unix hosts, either remove identd, or check its configuration so that
it does not return important information to remote sites
- Mail server: For added security, consider using two hosts, one to send
mail, the other to receive mail
- Use file quotas in user home directories
- Check that the default file permissions are safe (eg. umask of 022; consider
077 for system configuration files)
- Check that access to devices is secure (eg. /dev/*)
- Keep /tmp in its own partition
- Display login banner with some legalese to warn hackers that those are not public resources. Make sure this banner does not give out any information on the host platform and version #.
Sample seen on rootprompt:
This computer system is for authorized users only. Individuals using this system without authority or in excess of their authority are subject to having all their activities on this system monitored and recorded or examined by any authorized person, including law enforcement, as system personnel deem appropriate. In the course of monitoring individuals improperly using the system or in the course of system maintenance, the activities of authorized users may also be monitored and recorded. Any material so recorded may be disclosed as appropriate. Anyone using this system consents to these terms.
- Utmp is not fool-proof: it will not be updated if a user's shell crashes
(hence the user will appear to be still logged on), and is a plain-text file.
- NT: Do not set up unneeded trust relationships with other domains
- Remove all login information (eg. a connection to the SMTP port of a mail
server should not tell you which MTA is running and its version)
- Run password cracking software regularly to check that users do not choose
unsafe passwords, and implement password aging to force them to change their
- Change all default passwords on applications you install, if applicable.
- On *nix systems, use shadow passwords instead of relying on /etc/password, and use MD5 hashes instead of the crypt() function
- Consider password/account blocking after a predefined number of failed
attempts to authenticate
- Do not create "Joe accounts", ie. test accounts whose password is easy
to crack. When creating new user accounts, use a difficult, secure, and unique
password as default to make them safe (ie. do not use the same password for
all newly-created accounts). Remind employees to never write down their password,
and change the default to their own, safe password (see appendix for how to
choose a safe password)
- Disable all unused accounts. After a waiting period, remove those of employees
who have definitely left. Take advantage of password aging to force users
to change their password regularly, without choosing one that they used in
the past (Linux and NT, for one, offer this feature)
- Each month, check for all unused accounts, and contact their owner to check
if they still need it. If they don't, or do not get back to you, disable their
- Remove guest accounts. All users should use a personal account, to make
logging easier, ie. do not use group accounts; put users in a group instead
- All accounts should have a password
- If using NIS, make sure you do not delete the leading + sign in /etc/password,
leaving your Unix system wide-open
Authorization deals with controlling access to resources, while authentication means checking that the user is indeed who he means he is (ie. enter a password to prove this)
- Check if your system supports the use of ACLs such as SubDomain instead of the basic Unix owner-group-world system of authorization
- Check for unowned files regularly
- Use sudo or equivalent to allow restricted use of root access. Access should be limited to what a user could need to be doing on a host but not more
- Things to watch for: system crashes and reboots, new user accounts or high
activity on a previously low usage account, new files with novel or strange
file names,accounting discrepancies, changes in file lengths or dates (use
Tripwire), attempts to write to system, data modification or deletion,
denial of service, unexplained, poor system performance, anomalies, suspicious
probes, suspicious browsing, inability of a user to log in due to modifications
of his/her account, etc.
- In log files, pay special attention to any attempt to achieve a different
security level by any user or process, especially from anonymous/guest
Make sure passwords are not logged
Check history log
Monitor connections and log files
Consider logging to different files, on a central host: one for critical
information to be sent to you by e-mail and/or printed, the other to the
regular log file. Even safer is sending logs to a printer directly attached
to each host to avoid sniffing, preferably one that doesn't use a data
buffer, and furnished with enough paper. Remember to use a shredder before
throwing out useless logs, and check that passwords are not actually logged
for anyone to read
To avoid log files from using too much disk space, consider either compression,
or rotation followed by periodic moving of old log files to permanent storage
like CD-Rs in case you need to investigate a break-in in the future, especially
if one of your hosts turns out to have been used by hackers as relay to
launch attacks on other sites
Check with lawyers how much data must be logged by auditing software, and
what the legal restrictions are about logging user personal information
Keep two web servers: One in the public part of the LAN to contain files
meant for the outside world; Another server in the private part, to host
private, corporate resources (Search engines on the web can list all files
on a weakly protected public web server). Do the same for FTP and e-mail
Run host monitoring tools like WhatsUp to check services running on remote
hosts. Generally speaking, should know before users if something is wrong
on the network, hence the need for a lot of monitoring tools
Choose the "that which is not explicitly permitted is denied" philosophy,
and work from there. Disable any unneeded services running hosts (Unix:
/etc/inettab, /etc/inetd.conf; NT : Control Panel | Services). Maintain
a skeptical attitude to determine if a service is truly needed or just
a user's whim.
Uninstall any service/software that you do not need; do not simply disable
them by removing entries in start-up scripts and inet.conf
Check for process table attack and related types of denial of service attacks
Take a look at Bastille Linux or Debian, as they are more secure distributions
Unless absolutely necessary, do not run the r-services (rlogin, rsh, etc.)
and fingerd, ie. tools that either do not require authentication to access
resources, or that give out information on your hosts and network
Do not rely on a trusted-hosts architecture (/etc/hosts.equiv.) All access
to resources should be authorized
Scan for .rhosts files in user home directories regularly, and delete them.
As a better solution, create an empty .rhosts file owned by root and read-only
to forbid users from creating one of their own, and set the sticky bit
of user home directories to 1 to forbid users from deleting this file.
Do the same thing for .forward files in case a hacker tried to reroute
Use secure terminals (/etc/securetty) to force admins to first log in with
their personal account and su to root
To share directories and files from an Unix host, considering using Samba
instead of NFS for ease of deployment and increased security
Consider installing a bastion host to be the point of access of all connections
to the Internet (the router should only allow outgoing connections originating
from that host)
Take a look at outgoing filters to control which sites users can access
on the Internet, and document this as part of the security policy
If possible, each service should be running on a different machine whose
only duty is to provide a specific service. This helps to isolate intruders
and limit potential harm.
If this translates into too many servers, services should be placed
on hosts according to their security level (ie. install important services
on secure hosts, and trivial services on trivial hosts. Security is only
as strong as the weakest link in the chain.)
Provide guest FTP access instead of anonymous access. Use a spare hard
disk as home to FTP users to prevent hackers from crashing the host by
uploading huge files. Monitor use of hard disk space to watch for warez
Try to protect from human error, eg. a misconfigured host offering temporary
Use UPS on all hosts that require them, equiped with auto-shutdown and
reboot. Ideally, the main UPS sends an SNMP trap that can trigger all other
hosts to shutdown. Check that the BIOS of each host handles automatic reboot
when power resumes, to minimize down time
Run scanners like Satan, Cops, Trinux, Nessus, to check for open ports
and other possible insecurities
Famous attacks: TCP/IP sequence-number prediction, TCP session hijacking,
sniffing, active desynchronization, TCP spoofing, passive attacks, TCP
ACK storms, early desynchronization, Telnet session, stealth scanning (through
the FIN packet), SYN flooding (solutions are Random Early Drop, and SYN
Cookies), SACK (Selective Acknowledgement), DDoS, IP-directed broadcast
(pinq x.255 with source address is a local address)
Run anti-virus software on all hosts, with automatic updates for a local,
central host to avoid every user downloading the same update from the Net,
and making sure that all hosts are regularly updated. A free solution
for Windows hosts is AVG.
Provide backup hosts for major applications (e-mail, web server), either
stand-alone hosts, high-availability systems (RAID 5 with hot-pluggable
hard disks, Beowulf Linux, etc.)
Have spare hosts and spare parts ready (hard disks, fans, power supplies,
RAM, motherboards, monitors, etc.) with a step-by-step procedure on replacing
Use BIOS system monitoring feature (temperature in case, hard disk status,
Have users turn their monitor off to save power when leaving the office,
but leave their host running to minimize wear due to frequent power-offs,
and to back up their files at night
Use secure time server to keep all hosts in sync (especially important
for time-dependent applications like build machines, source control applications,
or groupware servers). Check that DST works and has no impact on applications
(source control, groupware, etc.)
DHCP: If applicable, do not allow anonymous hosts from getting an IP address.
Monitor use of DHCP leases; Have it look up addresses from DNS and assign
static addresses to known hosts. New or temporary hosts could use anonymous
addresses from a DHCP pool
DNS: Do not run dynamic DNS until a secure version is available; Check
for suspicious changes made to zone files, and run dnswalk
check for errors
Keep that all software up to date. Test upgrade on a test host to check
that no application is broken in the process. The best way is to stop the
host to be updated, clone its hard disk, and perform upgrade tests on the
copy, so as to have the exact same setup
Before applying an update, use MD5 or PGP to check that no hacker has tampered
with it. Never install binaries for which you don't have the source code
and didn't check that they come from a reliable source
Consider encrypting data files, either manually through PGP/GnuPG, through
a filesystem that supports automatic file encryption, or through applications
that do this automatically (Lotus Notes.) This is especially important
for theft-prone portables
If confidentiality is not an issue but integrity is, teach users how to
sign files through PGP/GnuPG
Add corporate banner to all e-mails
Do not just throw away outdated or broken equipments. Hard disks, floppies,
tapes, CDs can still contain confidential data. Either keep those for possible
use later, or destroy them. Remember to run eg. Norton utilities to make
sure a hard disk really is blank and its contents unreadable.
Run Tripwire or equivalent to monitor changes to system files. When you
want to check your machine, take it off the network and boot off a fresh
kernel (usually a read-only boot floppy is good for this) and then run
Tripwire to check your files.
Provide easy-to-use procedure to set up new hosts from secure images to
avoid having users install new, unsecure hosts themselves
- Instruct marketing and sales people to check with MIS before publishing any information on company resources, as this can be used by hackers to learn about your network
- Information given in your NIC record for the domains you own: Make them as generic and minimal as possible (eg. do not reveal the name of MIS personnel, along with phone and fax numbers); Use toll-free phone numbers instead of actual, internal numbers;
- Educate users as much as possible, through initial training and online
knowledge databases (groupware, help desk application.) The more users can do
themselves, the more time you have to take care of tasks that only you can do
as administrator. The goal should be to reduce synchronous calls to
emergencies that require an immediate response from MIS. Provide classes for
all new employees on software used internally
- All interventions should be logged in the help desk application, so as to
provide history to users and MIS, and feedback to management on MIS activity
and the type of problems that occur most often
- As answering synchronous calls is stressful and boring, and keeps MIS
personnel from working on longer-term projects, organize a balanced work
schedule (eg. such and such employee answers calls only at certain hours or
certains days, and works on system-oriented tasks the rest of the time)
- Reduce inter-dependencies and specialization to a minimum. Make sure all MIS
personnel is able to take over someone else's job at short notice. Remind
MIS personnel to take advantage of groupware application to document procedures,
tips, contacts, etc.
- Keep on- and off-line list of MIS employees, along with heads of
departments, so you know how to reach them at any time
- Check purchase requests from employees for any unsafe choices
- Tell users not to share accounts, and ask for a personal account if they
- Check with management if users should be allowed to post to newsgroups
from their corporate account
- If MIS personnel need to ask technical questions to newsgroups that could be used by hackers to break into their site, use a private ISP account for this to hide the origin of the article (eg. Dejanews, etc.)
- Do not leave sensitive documentation on desks, printers, fax machines, or
in trash cans. Use shredders for sensitive data
- Provide a computer use policy so that users know what they can and cannot
do with their computer (eg. installing softwares downloaded from the Net or
found in magazines, posting corporate information in newsgroups, checking
trivial web sites or newsgroups, or downloading offensive JPGs, etc.)
- Consider setting up a bogus domain name to hide connections from your site
(eg. masquerading, adding support for virtual domains in sendmail, etc.).
This is especially important when posting to newsgroups or inquiring about
- Watch out for hackers resorting to social engineering to find information
(pretending to be with MIS and calling someone in the company to have them
change their password, etc.)
- Check that acronym-based passphrases are used instead of passwords (eg.
w45hatgtg "where 45 have all the good times gone" instead of an
actual word; online dictionaries abound on the Internet, which makes it all
the easier for hackers to crack passwords.)
- Remind users not to write down their password. Have them use passphrases
instead, as they're easy to remember and much more secure than regular passwords.
- Check password aging. Require users to change their password regularly.
Check that they do not re-use an older password
- Before leaving for any trip, check how safe the political and economic situation
is, and that you have all the required equipment (PC Card and cable, phone
adapters, transformers, access control card to the premises if applicable,
- When traveling in groups, employees should not all fly on the same plane
- When off-site, or on-site if visitors are around, pay attention not to give
out confidential information on either the company or its computer infrastucture.
Walls have ears
- Check appendices in this document on steps for hiring and firing personnel
Appendix A - Employee In- and Out-Processing
- Create various accounts (NT user, NT computer, Unix e-mail, Lotus Notes,
FTP, etc.), and communicate login/password. Tell user to change passwords
immediately, and choose solid passwords per instructions in user guide
- Add IP address in DHCP and DNS
- Add phone # to online phone list
- Update caller ID and SPID in PBX
- Hand out documentation on resources available onsite (Phone-HOWTO, backup, etc.)
- Take picture, update mug-sheet and organization chart, provide access
- Disable all accounts (including RAS) immediately before employee is
leaving or is told of his dismissal (disgruntled employees and the like are
the most common problem of internal threats). Disabling is better than
deleting, in case the employee can be expected to return in a short while.Add
account to list, and remember to delete them after a given period of time in
case the employee is not to return
- Remove user from all mailing lists and backup jobs
- Check with manager or co-workers whether some files should be backed up
from employee's workstations, and burn CDs or save to tapes before
- If admin passwords were known by employee, change them
- E-mail: Set up automated answer for incoming mails, except corporate and
known mailing lists (eg. personal or ex-customers), explaining that the employee
has left and can be reached at such and such phone # or e-mail address
- Do NOT forward e-mails to a new address, as employee could continue
receiving individual corporate e-mails after leaving the company
- Remove employee picture from mug-sheet, phone directory, and Caller ID
- Remove hosts from backup selection list
- Make sure security knows that this employee is no longer with the company,
and, unless OKed by management, should not be allowed in in the premises without
Appendix B - MIS Personnel Hiring Test
- Difference between a repeater, a bridge, a router.
- Different standards of routing protocols
- TCP/IP : What form does an IP address take ; How is an address bound to a
NIC ; What are class and classless IP addresses ; What are private IP
addresses ; What is sub-netting
- Your ISP grants your site class C IP network address 18.104.22.168/24. How
would you use it to set up 2 networks of your own ?
- Differences between TCP/IP and Netbeui
- Explain what the following terms mean: ATM, X25, Frame-relay, ISDN, FDDI,
xDSL, cable modem, VPN, NFS, NIS, SMB/CIFS
- Explain what the following terms mean: RS-232, V42, V42bis, V34,
X2/K56Flex/V90, BBS, SLIP/PPP, call-back, black-listing, BBS, Kermit, ZModem.
- Example of some basic modem AT commands ?
- Difference between a hub and a switch ?
- Maximum number of 10BT hubs that can be linked together using regular
- Name different LAN architectures available
- Name of the different layers that constitute the OSI/ISO and TCP/IP models
- Difference between TCP and UDP ?
- Some well-known port numbers ?
- What settings does a TCP/IP host need to connect to a LAN ?
- Name major NOS
- Different ways to protect a LAN from outside hacking ?
- How many wires are required for 10BT wiring ? For 100BTX ? For 100BT4 ?
- What do UTP and STP stand for ? When is it necessary to use either one ?
- What are straight-through and cross-over cables ?
- How many wires are required to plug an analog phone into a PBX ? An ISDN
- What's SPID (French : SDA) ?
- Approximate voltage level of a RING signal ?
- Name different mass-storage devices currently in use, either random- or
sequential-access, each with its rough storage capacity
- What's the difference between an incremental and differential backup job
- What's the difference between RAID 0, RAID1, and RAID 5 ?
- Name different manufacturers of microprocessors
- Different models of the Intel family
- Different types of RAM
- How many devices can be connected onto an IDE bus ?
- SCSI : Speeds, and type of connectors ; How many devices can be connected
onto a single SCSI bus ; Things to watch for before connecting a new device
onto a SCSI bus
- How many primary partitions does a hard-disk support ? How many cylinders
should a hard-disk contain to avoir problems when booting an OS from one of
the partitions ?
- What does MBR stand for, and what is it for ?
- What frequency should you choose so that the picture displayed by a
monitor doesn't flicker ?
- What is the CPU/bus ratio ?
- Name some major OS's
- What do the following terms mean : SNMP, ping, sniffing, tripwire,
tcpdump, netstat, netwatch, nslookup, DNS, BootP, DHCP, POP, IMAP, X.500, LDAP ?
- What is the difference between POP and IMAP ?
- What is Lotus Notes ? What is currently its strong point as compared to
Microsoft Exchange ?
- What is ASCII ? Unicode ?
- What is a DLL ?
- What does client/server mean ? Alternative ?
- What do the following terms mean : DDE, OLE, COM, DCOM, Corba ?
- What do the following terms mean : Java, ActiveX, VBX, OCX?
- Name different file systems available on Microsoft platforms
- What is the difference between FAT and FAT32 ?
- Name major DBMS vendors
- Name the two original Unix branches
- Name the major current flavors of Unix
- Name the current, main Linux distributions
- What is POSIX ?
- What is the point of building a new kernel ? What are modules, and when
should you use them ?
- How do you add a new user account into a Linux server ? How to you set a
new password for it ? What should you change to unable users to login, and
only access a Linux server for e-mail ? What is a shadow password ?
- What do SUID/SGID mean, and when should you use them ?
- What is Samba ? Can it be used as a DC ?
- On a DNS server, how do you set an alias for a host ?
- How does a DHCP server work ?
- What are Telnet, INND, FTP, NIS/NIS+, Kerberos ?
- What are run-levels ?
- When should you use inet.d over RC scripts ?
- How do you set things up, so that a user is presented with a GUI to log in
on a Linux server ?
- What is an i-node ?
- Name different file systems supported by Linux.
- What are hard links, and symbolic links ?
- How does an X server work ?
- What are the different release numbers of NT ?
- What is the difference between a workgroup and an NT domain ? What is a DC ?
- What is Active Directory? What are the benefits to move to AD?
- What do the following terms mean : NetBios, name resolution, broadcasts,
LMHOSTS, WINS, HOSTS , DNS, master browser ?
- What is an SID ? What happens if you clone the partition of an NT host
currently connected to the network, and restore this image onto a new PC ?
- How can you upgrade a stand-alone NT host into a DC ?
- Is FAT32 supported by NT 4 ?
- What's an ERD ?
- What is a trust relationship ?
- What is an NT service ?
- Where are user or application parameters saved in Windows 9x and NT ?
(Proficiency in VB, C/C++, Python, PearlPerl, DOS batch files, Visual Test,
- Aural comprehension: TOEFL tape
- riting proficiency: TOEFL MCQs
- Reading comprehension: TOEFL MCQs
Check applicant's location, transportation means, and commute time
If possible perform assessment test: Fill a box with different hardware (NIC,
video adapters, etc.), and ask applicant about their use
Appendix C - User Policy
- Read the corporate computer use policy
- If you receive an e-mail or an instant message asking you to update
the password of any of your accounts (NT, e-mail; etc.), do not answer and
ask IT to investigate
- Contact MIS in case of any malicious and threatening telephone calls. Be
suspicious of any phone call asking for confidential information (your
password, information on corporate infrastructure, etc.)
- Do not answer any SPAM e-mails, as this can be used by spammers to confirm that an e-mail address is valid. Contact MIS if your mailbox is filled with it.
- Do not use your actual e-mail address when posting to newsgroups or
mailing lists, and do not post your address in any web page accessible from
the Internet (eg. your home page). Spammers can easily build themselves
mailing lists by scanning such material. Disguise your e-mail address, eg. jdoe@yaPLEASEREMOVETHISTOMAILMEhoo.com
- Do not install a modem to your host. If you need to connect to a remote
site, either use the legitimate corporate connection, or check with MIS if the
remote site requires setting up an ad hoc connection
- Remember that telephone lines, including wireless, can be tapped. Use
one-time passwords or tunneling to encrypt all data flow between corporate
servers and your modem-equipped host
- When off-site, or on-site if visitors are around, pay attention not to give
out confidential information on either the company or its computer infrastucture.
Walls have ears
- Do not leave confidential information lying on your desk, or fax or copy
machines. Use a paper shredder before throwing out confidential data
- Do not run any software received through the mail or the Internet (e-mail
attachments, web sites)
- While on the road, never leave a portable computer unattended (eg. leaving
it at your feet in an airport, or waiting for you through the metal detector; at your hotel, put your portable in a safe), always secure it with a lock and cable when
working in an office, set up a password in the BIOS, encrypt all sensitive
files (e-mails, etc.), make sure the portable comes up with a visible
tamper-proof corporate sticker to discourage theft
- MIS monitors network use, and is responsible for prohibiting use of to
newsgroups and web sites that are not work-related. Your e-mail and any file
on your computer can also be monitored.
- Challenge any stranger not wearing an access control card, and call
MIS/security ASAP. If no one is available, use the site PA system if available
- If available, make the most of the corporate groupware or help desk
application before calling up MIS. Those contain answers to Frequently Asked
Questions (FAQs), and history of past incidents. This channel also reduces
synchronous interruptions to a minimum.
- Do not throw away computer equipment, and bring it to MIS instead, as they
may still contain sensitive data (for instance, with the right tools, data can
still be read on a re-formated hard drive, etc.)
- Watch out for hackers resorting to social engineering to find information
(pretending to be with MIS and calling someone in the company to have them
change their password, etc.)
- Passwords: Instead of regular words, use acronym-based passphrases (eg.
w45hatgtg "where 45 have all the good times gone" instead of an
actual word; online dictionaries abound on the Internet, which makes it all
the easier for hackers to crack passwords.)
- Do NOT write down passwords.
- Before leaving for any trip, check how safe the political and economic
situation is, and that you have all the required equipment (PC Card and cable,
phone adapters, transformers, access control card to the remote presmises if
- When traveling in groups, employees should not all fly on the same plane
- Generally speaking, contact MIS whenever you detect a situation that you
consider is or could be a security or safety incident
Appendix D - Security Policy
The security policy to handle incidents should have the following sections: Goals and objectives, notification, identification of the incident, handling, post-mortem to improve security in the future.
As explained in RFC 2196, in each area, identify what you are trying to protect (files, corporate reputation, etc.), determine what you are
trying to protect it from (files being accessed or deleted or replaced, unauthorized programs being run, disruption of service, using your hosts as stepping stone to launch attacks to other sites, etc.), determine how likely the threats are, implement measures which will protect your assets in a cost-effective manner, and review the process continuously and make improvements each time a weakness is found.
The basic goals of security are authentication, authorization, availability, confidentiality, and data integrity. Threats include unauthorized access to resources and/or information, and denial of service. For each service that will be provided, list who will provide and administer it, and who will be allowed to access them.
Needless to say, the cost of protecting assets should be less than the cost of their loss, whether it's the amount of work to re-create them (lost files), or the impact of the image or future of the company (break-ins, confidential information passed on to the competition.)
Also, take into account the knowledge required to use computers securely, as e-mail-based virus are all it takes to bring down an entire organisation. To make matters worse, non-technical employees are those most likely to not upgrade to the latest anti-virus and launch any application or click on any e-mail attachement. Performing such daily routine tasks is not only time-consuming, but also very boring, and hence, very likely to be neglected. Therefore, automate as many tasks as you can, and hire MIS employees with such coding skills. Perl, Python, and shell scripts are your friends.
No security, especially as technical and involved as handling day-to-day management of a computer infrastructure, can be achieved without dedicating significant resources. Pay peanuts, and you'll get monkeys.
That money can be spent on software, hardware, or the wages of your staff, but if you don't take measures to provide these necessary resources, there is no way that anybody will be able to provide you with any acceptable level of security.
Finally, keep in mind that, as the Bugtraq mailing list shows, new breaches of security are found every single day, if only because new software and upgrades often means new security flaws. Do not assume that because your whole site is secure today, that it will remain so tomorrow. Security is a state of mind, so remember to check security-related mailing lists and web sites on a daily basis.
Applications (and their corresponding bugs and breaches of security) are updated constantly. In order to keep it as universal as possible and
avoid having to update it too often, this document gives a list of general hints, and does not deal with particular versions of softwares you might be running. Hence the need to keep abreast through mailing lists and web sites.
Appendix E - Choosing a backup software
- Use encryption, especially if using a courier company to store tapes off-site
- Make sure you can restore encrypted tapes on a bare-metal host (eg. if
using an RSA-type of encryption, make sure you keep safe copies of your
private key on a separate media)
Tape Drive Roundup - Which Tape Drive Is Best for Your Linux System?
CastleWood ORB Int IDE $150 Int SCSI $160 Ext SCSI $180 USB $200 2.2GB tapes
Travan TR4 (4-8GB $200-500), TR5 (10-20GB, $250-600) Mgf = Seagate TapeStor
OnStream (15-30GB, 25-50GB, $150-600) DI30 (IDE) is Certified for Linux! ADR50 is Certified for Linux!
120M floppy drive
DAT 4mm (DDS)
DAT 8mm (AIT)
Drive price, tape price, models (IDE, int SCSI, ext SCSI, USB), Linux, standard recording format (can be accessed using non-proprietary software)
The Emerging Tape Backup Market
Tape technology is broken into two major categories: helical tape and linear tape. The former touts higher density and performance, while the latter promises increased reliability. The main difference between the two is that a helical-scan drive pulls the tape out of the cartridge and, using a series of tensioners, wraps the tape around a rotating drum that contains the heads. Linear scan uses stationary heads and a less complex tape-threading method. The stationary heads of the linear tape technology are what theoretically give linear-tape drives superior reliability.
The other difference is the way data is written to the tape. Linear scan writes data from front to back in a serpentine method. That is, when the head reaches the end of the tape, it drops down a row and switches direction. Helical scan writes data diagonally across the entire tape--simultaneously using multiple heads. Concerns about the tape stretching or snapping due to drum rotation speeds upward of 7,000 rpm and high tension conditions have been quelled by the success and reliability of solutions such as the Sony AIT-2 drive. Aided by DLT, linear-scan drives have been winning the race with proven market success.
Appendix F - Unix Security Checklist
(from Practical Unix & Internet Security
- Reread your manuals and vendor documentation.
- Mark your calendar for 6-12 months in the future to reread your manuals, again.
Chapter 1: Introduction
- Order other appropriate references on security and computer crime.
Schedule time to read them when they arrive.
- Become familiar with your users' expectations and experience with UNIX.
- Write a letter to your vendors indicating your interest and concem about
(insufficient) sottware quality and security features.
- Post a reminder above your computer or desk: "Security is not 'Me versus the Users' but 'All of Us versus Them.' "
Chapter 2: Policies and Guidelines
- Assess your environment. What do you need to protect? What are you
- Understand priorities, budget, and resources available.
- Perform a risk assessment and cost-benefit analysis.
- Get management involved.
- Set priorities for security and use.
- Develop a positive security policy. Circulate it to all users.
- Ensure that authority is matched with responsibility.
- Ensure that everything to be protected has an "owner."
- Work to educate your users on good security practice.
- Don't have different, less secure rules for top-evel management.
Chapter 3: Users and Passwords
- Be sure that every person who uses your computer has his or her own account.
- Be sure that every user's account has a password.
- After you change your password, don't forget it!
- After you change your password, test it with the su command, by trying to
log in on another terminal, or by using the telnet localbost command.
- Pick strong, nonobvious passwords.
- Consider automatic generation or screening of passwords.
- Pick passwords that are not so difficult to remember that you have to
write them down.
- If you must write down your password, don't make it obvious that what you
have written is, in fact, a password. Do not write your account name or the
name of the computer on the same piece of paper. Do not attach your password
to your terminal, keyboard, or any part of your computer.
- Never record passwords online or send them to another user via electronic mail.
- Don't use your password as the password to another application such as a
Multi-User Dungeon (MUD) game.
- Don't use your password on other computer systems under different
- Consider use of one-time passwords, tokens, or smart cards.
- Ensure that all users know about good password management practices.
Chapter 4: Users, Groups, and the Superuser
- Ensure that no two regular users are assigned or share the same account.
- Never give any users, other than UUCP users, the same UID.
- Think about how you can assign group IDs to promote appropriate sharing
and protection without sharing accounts.
- Avoid use of the root account for routine activities that can be done
under a plain user ID.
- Think of how to protect especially sensitive files in the event that the
root account is compromised. This protection includes use of removable media
- Restrict access to the su command, or restrict the ability to su to user root
- su to the user's ID when investigating problem reports rather than
exploring as user root.
- Scan the files /var/adm/message,, /var/adm/sulog, or other appropriate log
files on a regular basis for bad su attempts.
Chapter 5: The UNIX Filesystem
- Learn about the useful options to your version of the Is command.
- If your system has ACLs, learn how to use them. Remember, do not depend on
ACLs to protect files on NFS partitions.
- Set your umask to an appropriate value (e.g., 027 or 077).
- Never write SUID/SGID shell scripts.
- Periodically scan your system for SUID/SGID files.
- Disable SUID on disk partition mounts (local and remote) unless necessary.
- Determine if write, chmod, chown, and chgrp operations on files clear the
SUID/SGID bits on your system. Get in the habit of checking files based on
- Scan for device files on your system. Check their ownership and
permissions to ensure that they are reasonable.
- If your system has "universes" or Context Dependent Files
(CDFs), be sure that all your administrative actions actually scan all the
files and directories on your system.
Chapter 6 Cryptography
- Learn about the restrictions your government places on the use, export,
and sale of cryptography. Consider contacting your legislators with your
opinions on these laws, especially if they negatively impact your ability to
protect your systems.
- Never use rot13 as an encryption method to protect data.
- Don't depend on the crypt command to protect anything particularly
sensitive, especially if it is more than 1024 bytes in length.
- If you use the Data Encryption Standard (DES) algorithm for encryption,
consider superencrypting with Triple-DES.
- Use the compress command (or similar compression system) on files before
- Learn how to use message digests. Obtain and install a message digest
program (such as MD5).
- Never use a login password as an encryption key. Choose encryption keys as
you would a password, however - avoid obvious or easily guessed words or patterns.
- Protect your encryption key as you would your password - don't write it
down, put it in a shell file, or store it online.
- Protect your encryption programs against tampering.
- Avoid proprietary encryption methods whose strengths are not known.
- Consider obtaining a copy of the PGP software and making it available to
your users. Use PGP to encrypt files and sensitive email, and to create and
check digital signatures on important files.
Chapter 7: Backups
- Make regular backups.
- Be certain that everything on your system is on your backups.
- Remember to update your backup regimen whenever you update your system or
change its configuration.
- Make paper copies of critical files for comparison or rebuilding your
system (e.g., /etc/passwd, /etc/rc, and /etc/fstab).
- Make at least every other backup onto a different tape to guard against
- Do not reuse a backup tape too many times, because the tapes will
- Try to restore a few files from your backup tapes on a regular basis.
- Make periodic archive backups of your entire system and keep them forever.
- Try to completely rebuild your system from a set of backup tapes to be
certain that your backup procedures are complete.
- Keep your backups under lock and key.
- Do not store your backups in the same room as your computer system:
consider off-site backup storage.
- Ensure that access to your backup tapes during transport and storage is
limited to authorized and trusted individuals.
- If your budget and needs are appropriate, investigate doing backups across
a network link to a "hot spare" site.
- Encrypt your backups, but escrow the keys in case you lose them.
- When using software that accesses files directly rather than through the
raw devices, consider remounting the filesystems as read-only during backups
to prevent changes to file access times.
- Make periodic paper copies of important files.
Chapter 8: Defending Your Accounts
- Make sure that every account has a password.
- Make sure to change the password of every "default" account that
came with your UNIX. system. If possible, disable accounts like uucp and
daemon so that people cannot use them to log into your system.
- Do not set up accounts that run single commands.
- Instead of logging into the root account, log in to your own account and
- Do not create "default" or "guest" accounts for visitors.
- If you need to set up an account that can run only a few commands, use the
rsh restricted shell.
- Think about creating restricted filesystem accounts for special-purpose
commands or users.
- Do not set up a single account that is shared by a group of people. Use
the group ID mechanism instead.
- Monitor the format and contents of the /etc/passwd file.
- Put time/tty restrictions on login to accounts as appropriate.
- Disable dormant accounts on your computer.
- Disable the accounts of people on extended vacations.
- Establish a system by which accounts are always created with a fixed
expiration date and must be renewed to be kept active.
- Do not declare network connections, modems, or public terminals as
"secure" in the /etc/default/loging or /etc/ttys files.
- Be careful who you put in the wheel group, as these people can use the su
command to become the superuser (if applicable).
- If possible, set your systems to require the root password when rebooting
in single-user mode.
- If your system supports the TCB/trusted path mechanism, enable it.
- If your system allows the use of a longer password than the standard
crypt() uses, enable it. Tell your users to use longer passwords.
- Consider using some form of one-time password or token-based
authentication, especially on accounts that may be used across a network link.
- Consider using the Distributed Computing Environment (DCE) or Kerberos for
any local network of single-user workstations, if your vendor software allows it.
- Enable password constraints, if present in your software, to help prevent
users from picking bad passwords. Otherwise, consider adding password
screening or coaching software to assist your users in picking good passwords.
- Consider cracking your own passwords periodically, but don't place much
faith in results that show no passwords cracked.
- If you have shadow password capability, enable it. If your software does
not support a shadow password file, contact the vendor and request that such
support be added.
- If your system does not have a shadow password file, make sure that the
file /etc/passwd cannot be read anonymously over the network via UUCP or TFTP.
- If your computer supports password aging, set a lifetime between one and
- If you have source code for your operating system, you may wish to slighdy
alter the algorithm used by crypt 0 to encrypt your password. For example, you
can increase the number of encryption rounds from 25 to 200.
- If you are using a central mail server or firewall, consider the benefits
of account-name aliasing.
Chapter 9.. Integrity Management
- If your system supports immutable files, use them. If you don't have them,
consider asking your vendor when they will be supported in your version of UNIX.
- If possible, mount disks read-only if they contain system software.
- Make a checkdist listing the size, modiflcation time, and permissions of
every program on your system. You may wish to include cryptographic checksums
- in the lists. Keep copies of this checklist on removable media and use
them to determine if any of your system files or programs have been modified.
- Write a daily check script to check for unauthorized changes to files and
- Double check the protection attributes on system command and data files,
on their directories, and on all ancestor directories.
- If you export filesystems containing system programs, you may wish to
export these filesystems read-only, so that they cannot be modified by NFS clients.
- Consider making all files on NFS-exported disks owned by user root.
- If you have backups of critical directories, you can use comparison
checking to detect unauthorized modifications. Be careful to protect your
backup copies and comparison programs from potential attackers.
- Consider runting rdist from a protected system on a regular basis to
- Make an offline list of every SUID and SGID file on your system.
- Consider installing something to check message digests of files (e.g.,
Tripwire). Be certain that the program and all its data files are stored on
read-only media or protected with encryption (or both).
Chapter 10: Auditing and Logging
- Consider installing a dedicated PC or other non-UNIX machine as a network
- Have your users check the last login time each time they log in to make
sure that nobody else is using their accounts.
- Consider installing a simple cron task to save copies of the lastlog file
to track logins.
- Evaluate whether C2 logging on your system is practical and appropriate.
If so, install it.
- Determine if there is an intrusion-detection and/or audit-reduction tool
available to use with your C2 logs.
- Make sure that your utmp file is not world writable.
- Turn on whatever accounting mechanism you may have that logs command usage.
- Run last periodically to see who has been using the system. Use this
program on a regular basis.
- Review your specialized log files on a regular basis. This review should
include (if they exist on your system) loginlog, sulog, aculog, xferlog, and others.
- Consider adding an automatic log monitor such as Swatch.
- Make sure that your log files are on your daily backups before they get reset.
- If you have syslog, configure it so that all auth messages are logged to a
special file. If you can, also have these messages logged to a special
hardcopy printer and to another computer on your network.
- Be aware that log file entries may be forged and misleading in the event
of a carefully crafted attack.
- Keep a paper log on a per-site and per-machine basis.
- If you process your logs in an automated fashion, craft your filters so
that they exclude the things you don't want rather than pass only what you do
want. This approach will ensure that you see all exceptional condition messages.
Chapter 11: Protecting Against Programmed Threats
- Be extremely careful about installing new software. Never install binaries
obtained from untrustworthy sources (like the Usenet).
- When installing new software, install it first on a noncritical system on
which you can test it and observe any misbehavior or bugs.
- Run integrity checks on your system on a regular basis (see Chapter 9).
- Don't include nonstandard directories in your execution path.
- Don't leave any bin or library directories writable by untrustworthy accounts.
- Set permissions on commands to prevent unauthorized alteration.
- Scan your system for any user home directories or dot files that are world
writ-able or group writable.
- If you suspect a network-based worm attack or a virus in widely circulated
software, call a FIRST response team or the vendor to confirm the instance
before spreading any alarm.
- Never write or use SUID or SGID shell scripts unless you are a hoary UNIX wizard.
- Disable terminal answer-back, if possible.
- Never have "." (the current directory) in your search path.
Never have writ-able directories in your search path.
- When running as the superuser, get in the habit of typing full pathnames
- Check the behavior of your xargs and find commands. Review the use of
these commands (and the shell) in all scripts executed by cron.
- Watch for unauthorized modification to initialization files in any user or
system account, including editor start-up files, .forward files, etc.
- Periodically review all system start-up and configuration files for
additions and changes.
- Periodically review mailer alias files for unauthorized changes.
- Periodically review configuration files for server programs (e.g., inetd.conf.)
- Check the security of your at program, and disable the program if necessary.
- Verify that any files run from the cron command files cannot be altered or
replaced by unauthorized users.
- Don't use the vi or ex editors in a directory without first checking for a
Trojan .exrc file. Disable the automatic command execution feature in GNU Emacs.
- Make sure that the devices used for backups are not world readable.
- Make sure that any shared libraries are properly protected and that
protections cannot be overridden.
Chapter 12: Physical Security
- Develop a physical security plan that includes a description of your
assets, environment, threats, perimeter, and defenses.
- Determine who might have physical access to any of your resources under
- Have heat and smoke alarms in your computer room. If you have a raised
floor, install alarm sensors both above and below the floor. If you have a
dropped ceiling, put sensors above the ceiling, too.
- Check the placement and recharge status of fire extinguishers on a regular basis.
- Make sure that personnel know how to use all fire protection and
- Make sure that the placement and nature of fire-suppression systems will
not endanger personnel or equipment more than is necessary.
- Have water sensors installed above and below raised floors in your
- Train your users and operators about what to do when an alarm sounds.
- Strictly prohibit smoking, eating, and drinking in your computer room or
near computer equipment.
- Install and regularly clean air filters in your computer room.
- Place your computer systems where they will be protected in the event of
earthquake, explosion, or structural failure.
- Keep your backups offsite.
- Have temperature and humidity controls in your computer room. Have alarms
associated with the systems to indicate if values get out of range. Have
recorders to monitor these values over time.
- Beware of insects trying to "bug" your computers.
- Install filtered power and/or surge protectors for all your computer equip
ment. Consider installing an uninterruptible power supply, if appropriate.
- Have antistatic measures in place.
- Store computer equipment and magnetic media away from building structural
steel members that might conduct electricity after a lightning strike.
- Lock and physically isolate your computers from public access.
- Consider putting motion alarms or other protections in place to protect
valuable equipment when personnel are not present.
- Protect power switches and fuses.
- Avoid having glass walls or large windows in your computer room.
- Protect all your network cables, terminators, and connectors from
tampering. Examine them periodically.
- Use locks, tie-downs, and bolts to keep computer equipment from being
- Encrypt sensitive data held on your systems.
- Have disaster-recovery and business-continuation plans in place.
- Consider using fiber optic cable for networks.
- Physically protect your backups and test them periodically.
- Sanitize media (e.g., tapes and disks) and printouts before disposal. Use
bulk erasers, shredders, or incinerators.
- Check peripheral devices for local onboard storage that can lead to
disclosure of information.
- Consider encrypting all of your backups and offline storage.
- Never use programmable function keys on a terminal for login or password information.
- Consider setting autologout on user accounts.
Chapter 13: Personnel Security
- Conduct background checks of individuals being considered for sensitive
positions. Do so with the permission of the applicants.
- If the position is extremely sensitive, and if it is legally allowable,
consider using a polygraph examination of the candidate.
- Have applicants and contractors in sensitive positions obtain bonding.
- Provide comprehensive and appropriate training for all new personnel, and
for personnel taking on new assignments.
- Provide refresher training on a regular basis.
- Make sure that staff have adequate time and resources to pursue continuing
- Institute an ongoing user security-awareness program.
- Have regular performance reviews and monitoring. Try to resolve potential
problems before they become real problems.
- Make sure that users in sensitive positions are not overloaded with work,
responsibility or stress on a frequent or regular basis, even if compensated
for the overload. In particular, users should be required to take holiday and
vacation leave regularly.
- Monitor users in sensitive positions (without intruding on their privacy)
for signs of excess stress or personal problems.
- Audit access to equipment and critical data.
- Apply policies of least privilege and separation of duties where applicable.
- When any user leaves the organization, make sure that access is properly
ter minated and duties transferred.
- Make sure that no user becomes irreplaceable.
Chapter 14: Thlephone Security
- Make sure that incoming modems automatically log out the user if the
telephone call gets interrupted.
- Make sure that incoming modems automatically hang up on an incoming call
if the caller logs out or if the caller's login process gets killed.
- Make sure that outgoing modems hang up on the outgoing call if the tip or
cu program is exited.
- Make sure that the tip or cu programs automatically exit if the user gets
logged out of the remote machine or if the telephone call is interrupted.
- Make sure that there is no way for the local user to reprogram the modem.
- Do not install call forwarding on any of your incoming lines.
- Consider getting CALLER*ID/ANI to trace incoming calls automatically. Log
the numbers that call your system.
- Physically protect the modems and phone lines.
- Disable third-party billing to your modem lines.
- Consider getting leased lines and/or callback modems.
- Consider using separate callout telephone lines with no dial-in capability
for callback schemes.
- Check permissions on all associated devices and configuration files.
- Consider use of encrypting modems with fixed keys to guard against
unauthorized use or eavesdropping.
Chapter 15. UUCP
- Be sure that every UUCP login has a unique password.
- Set up a different UUCP login for every computer you cornmunicate with via UUCP.
- Make sure that /usr/lib/uucp/L.sys or /usr/lib/uucp/Systems is mode 400,
readable only by the UUCP user.
- Do not export UUCP files or commands on a writable NFS partition.
- Make sure that the files in the /usr/lib/uucp directories can't be read or
written remotely or locally with the UUCP system.
- Make sure that no UUCP login has /usr/spooI/uucp/uucppublic for its home directory.
- Limit UUCP access to the smallest set of directories necessary.
- If there are daily, weekly, or monthly administrative scripts run by cron
to clean up the UUCP system, make sure that they are run with the UUCP UID but
that they are owned by root.
- Make sure that the ruusend command is not in your L.cmds file (Version 2 UUCP).
- Only allow execution of commands by UUCP that are absolutely necessary.
- Consider making some or all of your UUCP connections use callback to
initiate a connection.
- Make sure that mail to the UUCP users gets sent to the system administrator.
- Test your mailer to make sure that it will not deliver a file or execute a
command that is encapsulated in an address.
- Disable UUCP over IP unless you need UUCP.
- If the machine has an active FTP service, ensure that all UUCP users are
listed in the /etc/ftpusers file.
- Be sure that the UUCP control files are protected and cannot be read or
modified using the UUCP program.
- Only give UUCP access to the directories to which it needs access. You may
wish to limit UUCP to the directory /usr/spool/uucppublic.
- Limit the commands which can be executed from offsite to those that are
- Disable or delete any uucpd daemon if you aren't using it.
- Remove all of the UUCP software and libraries if you aren't going to use them.
Chapter 16. TCP/IP Networks
- Consider lowAevel encryption mechanisms in enterprise networks, or to
"tunnel" through external networks.
- Do not depend on IP addresses or DNS information for authentication.
- Do not depend on header information in news articles or email as they can
Chapter 17: TCP/IP Services
- Routinely examine your inetd configuration file.
- If your standard software does not offer this level of control, consider
installing the tcpwrapper program to better regulate and log access to your
servers. Then, contact your vendor and ask when equivalent functionality will
be provided as a standard feature in the vendors' systems.
- Disable any unneeded network services.
- Consider disabling any services that provide nonessential information to
outsiders that might enable them to gather information about your systems.
- Make sure that your version of the ftpd program is up to date.
- If you support anonymous FTP, don't have a copy of your real /etc/passwd
as an ~ftp/etc/passwd.
- Make sure that /etc/ftpusers contains at least the account names root,
uucp, and bin. The file should also contain the name of any other account that
does not belonged to an actual human being.
- Frequenfly scan the files in, and usage of, your ftp account.
- Make sure that all directory permissions and ownership on your ftp account
are set correctly.
- If your software allows, configure any "incoming" directories so
that files dropped off cannot then be uploaded without operator intervention.
- Make sure that your sendmail program will not deliver mail directly to a file
- Make sure that your sendmail program does not have a wizard's password set
in the configuration file
- Limit the number of "trusted users" in your sendmail.cf file
- Make sure that your version of the sendmail program does not support the
debug, wiz, or kill commands.
- Delete the "decode" alias in your aliases file. Examine
carefully any other alias that delivers to a program or file.
- Make sure that your version of the sendmail program is up to date, with
all published patches in place
- Make sure that the aliases file cannot be altered by unauthorized individuals.
- Consider replacing sendmail with smap, or another more tractable network agent.
- Have an alias for every non-user account so that mail to any valid address
gets delivered to a person and not to an unmodified mailbox.
- Consider disabling SMTP commands such as VRFY and EXPN with settings in
your sendmail configuration.
- Disable zone transfers in your DNS, if possible.
- Make sure that you are running the latest version of the nameserver
software (e.g., bind) with all patches applied.
- Make sure that all files used by the nameserver software are properly
protected against tampering, and perhaps against reading by unauthorized users.
- Use IP addresses instead of domain names in places where the practice
makes sense (e.g. in .rhosts files). (But beware that most implementations of
trusted commands don't understand IP addresses in .rhosts, and that, in such
cases, doing this might introduce a vulnerability.)
- Make sure that TFTP access, if enabled, is limited to a single directory
containing boot files.
- Tell your users about the information that the finger program makes
available on the network
- Make sure that your finger program is more recent than November 5, 1988.
- Disable or replace the finger service with something that provides less information.
- If you are using POP or IMAP, configure your system to use APOP or
Kerberos for authentication.
- Consider running the authd daemon for all machines in the local net.
- Configure your NNTP or INND server to restrict who can post articles or
transfer Usenet news. Make sure that you have the most recent version of the software.
- Block NTP connections from outside your organization.
- Block SNMP connections from outside your organization.
- Disable rexec service unless needed.
- Routinely scan your system for suspicious.rhosts files. Make sure that all
existing .rhosts files are protected to mode 600.
- Consider not allowing users to have .rhosts files on your system.
- If you have a plus sign (+) in your /etc/hosts.equiv file, remove it.
- Do not place usemames in your /etc/hosts.equiv file.
- Restrict access to your printing software via the /etc/hosts.lpd file.
- Make your list of trusted hosts as small as possible.
- Block incoming RIP packets; use static routes where possible and practical.
- Disable UUCP over IP unless needed.
- Set up your logindevperm or fbtab files to restrict permissions on frame
buffers and devices, if this is possible on your system.
- If your X11 Server blocks on null connections, get an updated version.
- Enable the best X11 authentication possible in your configuration (e.g.,
Kerberos, Secure RPC, "magic cookies") instead of using xhost.
- Disable the rexd RPC service.
- Be very cautious about installing MUDs, IRCs, or other servers.
- Scan your network connections regularly with netstat.
- Scan your network with tools such as SATAN and ISS to determine if you
have uncorrected vulnerabilities - before an attacker does the same.
- Re-evaluate why you are connected to the network at all, and disconnect
machines that do not really need to be connected.
Chapter 18: WWW Security
- Consider running any www server from a Macintosh platform instead of from
a UNIX platform.
- Do not run your server as user root. Have it set to run as a nobody user
unique to the WWW service.
- Become familiar with all the configuration options for the particular
server you use, and set its options appropriately (and conservatively).
- Disable automatic directory listings.
- Set the server to not follow symbolic links, or to only follow links that
are owned by the same user that owns the destination of the link.
- Limit or prohibit server-side includes.
- Be extremely cautions about writing and installing CGI scripts or
programs. (See the specific programming recommendations in the chapter.)
Consider using taintperl as the implementation language.
- Configure your server to only allow CGI scripts from a particular
directory under your control.
- Do not mix WWW and FTP servers on the same machine in the same filesystem hierarchy.
- Consider making your www server chroot into a protected directory.
- Monitor the logs and usage of your WWW service.
- If you are transferring sensitive information over the WWW connection
(e.g., personal information), enable encryption.
- Prevent general access to the server log files.
- Be aware of the potential risks posed by dependence on a limited number of
Chapter 19: RPC, NIS, NIS+, and Kerberos
- Enable Kerberos or Secure RPC if possible.
- Use NIS+ in preference to MS, if possible.
- Use netgroups to restrict access to services, including login.
- Put keylogout in your logout file if you are running secure RPC.
- Make sure that your version of ypbind only listens on privileged ports.
- Make sure that your version of portmapper does not do proxy forwarding.
- If your version of portmapper has a "securenets" feature,
configure the program so that it restricts which machines can send requests to
your portmapper. If this feature is not present, contact your vendor and ask
when it will be supported.
- Make sure that there is an asterisk (*) in the password field of any line
beginning with a plus sign (+) in both the passwd and group files of any NIS client.
- Make sure that there is no line beginning with a plus sign (+) in the
passwd or group files on any NIS server.
- If you are using Kerberos, understand its limitations.
Chapter 20: NFS
- Program your firewall and routers to block NFS packets.
- Use NFS version 3, if available, in TCP mode.
- Use the netgroups mechanism to restrict the export of (and thus the
ability to remotely mount) filesystems to a small set of local machines.
- Mount partitions nosuid unless SUID access is absolutely necessary.
- Mount partitions nodev, if available.
- Set root ownership on files and directories mounted remotely.
- Never export a mounted partition on your system to an untrusted machine if
the partition has any world- or group-writable directories.
- Set the kemel portmon variable to ignore NFS requests from unprivileged ports.
- Export filesystems to a small set of hosts, using the access= or ro= options.
- Do not export user home directories in a writable mode.
- Do not export filesystems to yourself!
- Do not use the root= option when exporting filesystems unless absolutely necessary.
- Use fsirand on all partitions that are exported. Rerun the program periodically.
- When possible, use the secure option for NFS mounts.
- Monitor who is mounting your NFS partitions (but realize that you may not
have a complete picture because of the stateless nature of NFS).
- Reconsider why you want to use NFS, and think about doing without. For
instance, replicating disk on local machines may be a safer approach.
Chapter 21: Firewalls
- Keep in mind that firewalls should be used in addition to other security
measure and not in place of them.
- Consider setting a policy of default deny for your firewall.
- Consider intemal firewalls as well as extemal firewalls.
- Use the most complete firewall you can afford and one that makes sense in
your environment. At the very least, put a screening router in place.
- Consider buying a commercially provided and configured firewall, rather
than creating your own.
- Plan on centralizing services such as DNS, email, and Usenet on closely
guarded bastion hosts.
- Break your network up into small, independent subnets. Each subnet should
have its own NIS server and netgroups domain.
- Don't configure any machine to trust machines outside the local subnet.
- Make sure that user accounts have different passwords for machines on
- Make sure that firewall machines have the highest level of logging.
- Configure firewall machines without user accounts and program development
utilities, if possible.
- Don't mount NFS directories across subnet boundaries.
- Have a central mail machine with MX aliasing and name rewriting.
- Monitor activity on the firewall regularly.
- Configure your firewall/bastion hosts to remove all unnecessary services
- Keep in mind that firewalls can sometirnes fail. Plan accordingly:
periodically test your firewall and have defense in depth for that eventuality.
- Give serious thought to whether or not you really want all your systems to
be connected to the rest of the world, even if a firewall is interposed. (See
the discussion in the chapter.)
Chapter 22: Wrappers and Proxies
- Consider installing the smap proxy in place of the sendmail program to
receive mail over the network.
- Consider installing the tcpwrapper program to restrict and log access to
local network services.
- Consider installing the ident/authd service on your system to help track
network access. However, remember that the results retumed by this service are
not completely trustworthy.
- Consider writing your own wrapper programs to provide extra control or
logging for your local system.
Chapter 23: Writing Secure SUID and Network Programs
- Convey to your vendors your concem about sofiware quality in their products.
- Observe the 24 general rules presented in the chapter when writing any
software, and especially when writing software that needs extra privileges or trust.
- Observe the 17 general rules presented in the chapter when writing any
network server programs.
- Observe the 14 general rules presented in the chapter when writing any
program that will be SUID or SGID.
- Think about using chroot for privileged programs.
- Avoid storing or transmitting passwords in clear text in any application.
- Be very cautious about generating and using "random" numbers.
Chapter 24: Discovering a Break-in
- Plan ahead: have response plans designed and rehearsed.
- If a break-in occurs, don't panic!
- Start a diary and/or script file as soon as you discover or suspect a
break-in. Note and timestamp everything you discover and do.
- Run hardcopies of files showing changes and tracing activity. Initial and
time-stamp these copies.
- Run machine status-checking programs regularly to watch for unusual
activity: ps, w, vmstat, etc.
- If a break-in occurs, consider making a dump of the system to backup media
before correcting anything.
- Carefully examine the system after a break-in. See the chapter text for
specific - there is too much detail to list here. Specifically, be certain
that you restore the system to a known, good state.
- Carefully check backups and logs to determine if this is a single
occurrence or is related to a set of incidents.
Chapter 25: Denial of Service Attacks and Solutions
- If user quotas are available on your system, enable them.
- Configure appropriate process and user limits on your system.
- Don't test new software while running as root.
- Install a firewall to prevent network problems.
- Educate your users on polite methods of sharing system resources.
- Run long-running tasks in the background, setting the nice to a positive value.
- Configure disk partitions to have sufficient inodes and storage.
- Make sure that you have appropriate swap space configured.
- Monitor disk usage and encourage users to archive and delete old files.
- Consider investing in a network monitor appropriate for your network. Have
a spare network connection available, if you need it.
- Keep available an up4o-date paper list of low-level network addresses
(e.g., Ethernet addresses), IP addresses, and machine names.
- Ensure good physical security for all network cables and connectors.
Chapter 26: Computer Security and US. Law
- Consult with your legal counsel to determine legal options and liability
in the event of a security incident.
- Consult with your insurance carrier to determine if your insurance covers
loss from break-ins. Determine if your insurance covers business interruption
during an investigation. Also determine if you will be required to institute
criminal or civil action to recover on your insurance.
- Replace any "welcome" messages with warnings against
- Put explicit copyright and/or proprietary property notices in code
start-up screens and source code. Formally register copyrights on your locally
developed code and databases.
- Keep your backups separate from your machine.
- Keep written records of your actions when investigating an incident.
Time-stamp and initial media, printouts, and other materials as you proceed.
- Develop contingency plans and response plans in advance of difficulties.
- Define, in writing, levels of user access and responsibility. Have all
users provide a signature noting their understanding of and agreement to such
a statement. Include an explicit statement about the return of manuals,
printouts, and other information upon user departure.
- Develop contacts with your local law-enforcement personnel.
- Do not be unduly hesitant about reporting a computer crime and involving
- If called upon to help in an investigation, request a signed statement by
a judge requesting (or directing) your "expert" assistance.
Recommend a disinterested third party to act as an expert, if possible.
- Expand your professional training and contacts by attending security
training sessions or conferences. Consider joining security-related organizations.
- Be aware of other liability concerns.
- Restrict access to cryptographic software from the network.
- Restrict or prohibit access to material that could lead to legal
difficulties. This includes copyrighted material, pornographic material, trade
- Make sure that users understand copyright and license restrictions on
commercial software, images, and sound files.
- Prohibit or restrict access to Usenet from organizational machines.
Consider coupling this to provision of personal accounts with an independent
- Make your users aware of the dangers of electronic harassment or defamation.
- Make certain that your legal counsel is consulted before you provide
locally developed software to others outside your organization.
Chapter 27: "Who Do You Trust?
- Read the chapter. Develop a healthy sense of paranoia.
- Protest when vendors attempt to sell you products advertised with
"hacker challenges" instead of more reliable proof of good design
- Make your vendor aware of your concerns about security, adequate testing,
and fixig security bugs in a timely fashion.
- Buy another 1000 copies of this book for all your friends and
acquaintances. The copies will make you intelligent, attractive, and
incredibly popular. Trust us on this.
Appendix B: Important Files
- Become familiar with the important files on your system.
- Understand why SUID/SGID files have those permissions.
Appendix C: UNIX Processes
- Understand how processes work on your system.
- Understand the commands that are available to manipulate processes on your system.
Appendix F: Organizations
- Learn more about security.
- Explore other resources concerning security, UNIX, and the Internet.
- Monitor newsgroups, mailing lists, and other resources that will help you
stay current on threats and countermeasures.
- Explore professional opportunities that enable you to network with other
professionals, and add to your knowledge and experience.
Appendix G: Table of IP Services
Read the table and add your own site notes indicating the services you do
and do not wish to support.
nslookup (ls -d acme.com. > zone.txt), host -lvt any acme.net, close tcp 53 on firewall, traceroute -S -p53 x, fping gping, icmpquery & icmpush, strobe & udp-scan, identd to get infos on a running process, net view /domain: mydomain, vrfy/expn mysmtp, netcat, don't run progs as root, remove all unneeded sws, dll's, core dump, world-writable files + dir, tx alarm if nic set to promiscuous, seifried.org/lasg, modems, rogue phone plugs, spread dial-in phone #s,g
Policy for handling incidents:
- Overview (goal and objectives in handling the incident)
- Evalution (how serious is it?)
- Notification (who should be notified)
- Documentation logs (records to keep from before/during/after the incident)
djbDNS instead of BIND
Use tcpserver to replace inetd
netstat -an --inet
netstat -nl --inet
# netstat -ln
There's replacements for, among other things, dns, http and FTP software, and of course Qmail
One gruesome night of crawling through man pages, newsgroups, deeply hidden scripts and obscure configuration files reveals that in fact the only one not using port 6000 is the local user. On the local machine domain sockets are used. Even better, X's TCP port can be banished, if you just know how. Ditto of xdm's UDP port.
I've decided to switch to a little known print system called PDQ. It's not particularly sophisticated, but it's got the funniest web site of the lot. As before, I won't go into detail on installing it; that's what documentation is for. I will however, try to explain how it works, since it is very different from the way lpd works. http://feynman.tam.uiuc.edu/pdq
So I have my standards. Anything that does interaction with the outside world should either be very trivial, very well audited, or be sufficiently sandboxed that possible damage is limited. Preferably it should be all of them. Many classic programs cannot be set up this way and should not be exposed to the public Internet.
Suid programs can be made only accessible to those who need to use them. The usual way it to create a special group for each class of suid programs you can identify and make each user a member of the groups needed. Programs like sudo provide other ways to control who may use what program.
Of the remaining 12, 7 had a legitimate reason to be suid root (like su) while the other 5 needed to be suid root for practical reasons but there really should be a better way of doing this. Examples are ping and Xwrapper. All remaining twelve programs had one thing in common: normally they would only be started by humans. No system account needs to use them. I therefore put them all into a directory that only those accounts that correspond to real users can access. If an attacker breaks into a system account he cannot reach any suid root program. For six of the twelve I added extra requirements - a number of special group IDs controls who may access these.
More at http://packetstorm.securify.com/UNIX/utilities/
- Guide: Setting
up a virtual FTP server
- Pure FTP Server
Highly Available Networking
- The Diceware
Passphrase Home Page
- FoundStone (plenty of cool,
- www.securityfocus.com (home of the Bugtraq mailing list)
- www.first.org (Forum of Incident
Response and Security Teams)
- Building Internet Firewalls D. Brent Chapman and Elizabeth D.
Zwicky ISBN 1-56592-124-0
- Essential System Administration Æleen Frisch, O'Reilly ISBN 1-56592-127-5
- Linux System Security Scott Mann & Ellen L. Mitchell, Prentice Hall, ISBN 0-13-015807-0
- Maximum Linux Security Anonymous, ISBN 0-672-31670-6
- Practical Unix & Internet Security Simson Garfinkel and Gene
Spafford ISBN 1-56592-148-8
- Unix System Administration Handbook, 2nd Edition (a.k.a. The Red
Book; A new edition is expected at the end of 2000) by Evi Nemeth, Garth
Snyder, Scott Seebass, Trent R. Hein, published PTR-PH, ISBN 0-13-151051-7
- Network Instruction Detection - An Analyst's Handbook Stephen Northcutt, New Riders, ISBN 0-7357-0868-1
- rfc2196 - Site Security Handbook by B. Fraser September 1997
- Securing Optimizing RH-Linux by Gerhard Mourani
- Linux Security HOWTO by Kevin Fenzi & Dave Wreski
- Improving the security of your unix system - Final Report + April 1990, by David A. Curry
- Securing Linux http://linuxworld.com/linuxworld/lw-1999-05/lw-05-ramparts_p.html
- Kurt Seifried's Linux Administrators Security Guide http://www.securityportal.com/lasg/
- Deviation v.1 locking down Linux/BSD 2001 http://www.antioffline.com/deviation/ind.html
- SSL http://www.antioffline.com/pki.txt
Sysadmin's Security Basics
: another brick in the (security) wall
- A Taste
of Computer Security by Amit Singh
- Data Integrity –
The Unknown Threat by Dwayne Melancon
to spot security risks
- "The All-Internet-Security.com
Website is an established marketplace for free, shareware and anti-intrusion
resources such as: antivirus web scaner, personal firewall software as well
as network security scanner, or essential download, etc."
Lance Spitzer's Armoring Linux is a pretty cool doc for most newer Admins/Newbie/Cluebie users. He's actually a kick ass guy on the Checkpoint side of things ;) as well. http://www.enteract.com/~lspitz
BroncBuster has an ok doc written in accordance to Slackware. Even though he didn't give me an opportunity to interview him for the BroncBuster vs. Michael Jackson event, I ain't mad at him. http://www.attrition.org/hosted/bronc
Vetesgirl is a good friend, and has some cool shit on her page in reference to Linux. She is also the author of VetesScan which is also a cool ass tool to have around /usr/local/bin http://www.self-evident.com
Packet Storm Security is one of the biggest security sites around. Started by Ken Williams which is also one of the coolest people in the world, Packet Storm is on top of security like JP is on top of Brad's anus. Definitely a place to go and read documentation on everything from a-z. http://packetstorm.securify.com
SecurityFocus is another one of the coolest sites to gain info from. This is AlephOne's bugtraq site, complete with tools, documentation, postings, etc. http://www.securityfocus.com SecuritySearch is a search engine dedicated to security and should be in your bookmark list. This is the most thorough search engine related to security I've found. Although you do have to watch those damn geoshitty sites that have sprung up there like the plague... ;) http://www.securitysearch.net
XForce has some pretty cool documentation related to security. While I get tired of typing this 1/2 hour doc, I'll just throw in links and you can check em for yourself. http://xforce.iss.net NMRC (great Novell documentation) http://www.nmrc.org
Rewted Labs (pestilence sector9 bell are cool as hell) http://www.rewted.org
Technotronic Security http://www.technotronic.com