Protection of TCP/IP Based Network Elements

Just some interesting things about it
Published: Oct 16, 2002 Updated: Oct 16, 2002 Section: Network Security Library :: Unix Security Author: Printable Version Adjust font size: Rating: 2.1/5 - 10 Votes 1 2 3 4 5

In 1994, CERT reported over 40,000 compromised sites on the Internet (1994 CERT Annual Report). That number possibly references a much lower percentage of the actual problem as the Department Of Justice estimates that over 75% of incidents go unreported to proper authorities.

The need for effective security controls for the explosive growth of TCP/IP networks is now more important than ever.

The purpose of this document is to provide an overall baseline for security considerations for securing TCP/IP based network elements. This document's intent is to provide a guideline for such considerations, and should not be considered a complete resource guide for implementing security precautions.

The problem is that many Security Administrators are faced with providing protection for their systems within their Corporate Network, without the benifit of knowing the makeup of that network. This document attempts to provide an overview on the ability to identify systems within your companies network, the exposures on those systems, who owns them, and how to effectively plan for the long term security strategy needed to keep them protected. Should you have any feedback for this document, please feel free to contact me.

To obtain a copy of "Security Considerations for the NetworkMCI Internet Network", use the following URL: (http://www.security.mci.net/sec-whit.html).

Step 1

Identify valid internal network address numbers

This information can be obtained from network administrators, or the Internet Directory (if you are using "official" network address assignments).

Establish a connection to or a presence on such networks for security functions. You must have a machine that has the ability to connect to the network, or a machine dedicated on the network. The firewall that protects the network must permit that "security" system to access any element.

Identify your systems

You need to identify the network addresses of your internal systems in order to run auditing programs against them. Once the range of addresses has been identified, you can scan these address to identify valid systems that are active. Once you've identified active systems, you can use that information to identify what types of systems they are. This information can be used to plan your security reviews and your notification programs.

Scan network elements for active systems (e.g.; "pingall" program)

The "pingall" program is a modified version of "ping" that probes each network address, waiting for a reply. When a system answers, it is then added to a network database that can be used as a listing of active systems. Versions of the pingall program are available on public FTP sites, as well as the SATAN distribution. A version of Satan can be found on the COAST archive ( http://www.cs.purdue.edu/coast/satan.html).

The "pingall" program can be found at the MCI FTP site ( ftp://ftp.mci.net/pub/security/pingall).

In the following example, the user is attempting to identify all of the active hosts in the 204.70.128 subnet:

	user@host% pingall 204.70.128.
	204.70.128.1	ns.mci.net
	204.70.128.2	host.mci.net
	.... 
	....

This database can then be used in future runs to identify when additions are placed on the network. This is useful to identify new systems that have been added to the network that have not been added to the security policy.

There are several versions and models of the "pingall" program.

Store such information into a query database

The query database can be used to store active hosts in the network. This database can then be used by other programs that may perform routine audits, security checks, patch upgrades or to identify when new systems have been added to the network, as well as provide trend analysis on potential exposures.

The database(s) created by the SATAN tool contain such valuable information, including; system name, OS type, IP address, and current system configuration parameters.

These databases can be a crtitical and valuable link for being able to quickly identify specific types of systems in your network, who owns them and what applications are running on them.

Two useage examples;

1) Once you have a list of active addresses in your network, you could easily create a script that sends an email to the administrator of that system (root, webmaster, and postmaster for example), telling them to identify an owner for the system.

We use a WEB page for this function; when our scanning software identifies a "non-registered" address in the internal network, it sends the administrator an email, telling them to connect to an intenral WEB page to register their system. This WEB page asks for Management chain information, contact information and provides accessability to internal security policy documents and standards.

2) Once you have a database of systems, platform types, owners and other useful information, you can use this to handle incident responses. For example, let's say CERT releases an alert about a new vulnerible version of sendmail (amazing but true!). You can use your databases to find out which systems are running sendmail, what platform they are, and who owns them - to ensure that exposure is corrected.

Ensure you have a database!!

Step 2

Scan systems for external vulnerabilities/exposures

An assessment of this nature should be performed on some regular basis (e.g.; once a month). If the software allows, you should perform an assessment on a range of systems rather than specific systems as this is a good way to identify newly installed systems on your internal network(s).

If your assessment software supports multiple databases to store audit results, it is advisable to create separate databases for different network segments or platforms. If your assessment software supports email notification instead, it is recommended that you have the results sent to a central location email address specifically set up to receive such reports. This email address can then be used to automatically receive and review the reports for appropriate action.

Use vulnerability program(s) to identify exposures on identified system elements:

Public Domain Software:
- SATAN
- ISS
- NetProbe (PD)
- NSS
- Misc scripts
- etc.
- These tools are available at: ftp://coast.cs.purdue.edu/pub/tools/unix
Commercial Software:
- PINGWARE (Bellcore)
- Netprobe Commercial
- ISS Commercial
- etc

Step 3

Obtain access to system elements

Access to the system is a requirement in order to install security programs, auditing programs, and overall monitoring functions.

Work with system admins to obtain user account presence on systems (e.g.; "security" account) Preferably ROOT access, however not always needed.

With great access, comes great responsibility. Access across all of these internal systems should be considered critical path access. One time passwords should be used to gain access to all systems if available. Where such functionality does not exist, secure, diverse password selection should be used, and the use of .rhosts and other "non-password" entry services should be disabled. Your access is the "Keys to the Kingdom" and should be treated appropriately.

Step 4

Perform vulnerability assessment on internal systems

Depending on the software available, and its functionality, there are three basic ways to accomplish the task of running security audits to be executed on the internal systems themselves; 1) If your auditing software supports a client/server model, then the server module can send the appropriate commands to the client to successfully run an audit and to send the results to some appropriate location. 2) Have a scheduled job (i.e.; CRON) to execute the audit software at a predefined date and time and to mail the results to some appropriate location and 3) have a security system somewhere on the network upload and execute the auditing code at a predefined interval.

It is recommended to always have auditing software stored off of the client, retained on a secure system as auditing routines can be easily modified to return false results.

It is recommended to have the vulnerability assessment reports sent to a central location email address specifically set up to receive such reports.

Use vulnerability program(s) to identify exposures on identified system elements

Public Domain Software:
- COPS
- Tiger
- Tripwire
- etc.
- These tools are available at: ftp://coast.cs.purdue.edu/pub/tools/unix
Commercial Software:
- Axent
- Los Altos Technologies
- Tivioli
- etc.

Step 5

Classify your systems

Your systems information database should include some basic but important reference material in order to provide a quick summary of the system, its use within the company and the owner of that system at a moments notice. Having a classification of systems is also handy in order to determine the amount of security attention a particular system or set of systems should receive, dependent on its overall function within the company. Critical systems (e.g., Billing, Human Resources, etc.) may be paid close attention during anomaly scans, Firewall Policy creation and incident response procedures.

Your classification database should contain at least the following information:

System IP Addresses
System name
Platform Type
OS Type
Sendmail Type (optional)
System Owner
System Owner Contact
Classification Priority
- mission critical
- critical
- sensitive
- baseline
- minimal

Step 6

Deploy Security measures and monitoring programs on systems

Ensure that any security programs/data you have on remote systems are well protected from potiential or accidential tampering. Security programs should be in a common directory structure, protected from other users on the system.

Correct identified exposures from external scans

Using the output from the external vulnerability assessment program(s), correct any identified security exposures.

Get help from your system administrators to get this done!

Correct identified exposures from internal scans

Using the output from the internal vulnerability assessment program(s), correct any identified security exposures.

Deploy Security Patches

A majority of the vulnerability assessment software can identify which security patches need to be implemented on the system. Obtain the required security patches from the vendor (a majority of the vendors have FTP sites), verify the supplied checksums and install as appropriate.

Monitor the CERT Advisory mailing list (cert-advisory-request@cert.org) and other appropriate vendor mailing lists to learn of newly released security patches.

Establish Password Checks

If reusable passwords are being used to access a system or resource, it is recommended to make modifications to the system's password program to enforce password selection "rules". These rules would prevent the user from picking easy to guess passwords that could be used by unauthorized personnel to gain access to a system. Poor password selection is the number two method for gaining access to a system.

Some operating systems, such as AIX and VMS, include these functions in the standard system software. They simply need to be enabled. Other systems require the installation of new password management software, such as passwd+ or npasswd, both available via anonymous FTP from ftp://coast.cs.purdue.edu/pub/tools/unix/.

It is further recommended to make use of password "cracking" programs on sensitive systems that check password files for easy to guess entries. This functionality can be included in the internal auditing applications as a routine check, although it is recommended to make use of an offsite system for such attacks.

The Crack password cracking program is available via anonymous FTP from ftp://coast.cs.purdue.edu/pub/tools/unix/crack/.

Log files from systems, applications

All log files should be reviewed and analyzed for anomalies and exposures! It is recommended to have these log file forwarded to a central location (see SYSLOG). If such functionality is not available, it is recommended to have an application on the system that reviews the log data in real time - or nightly - and forwards appropriate security alert information to a notification system.

SYSLOG

A majority of TCP/IP compliant systems support SYSLOG reporting of data. This allows the system to collect audit related data from applications, users, and the system itself and either store such information in appropriate system log files, and/or forward such information to a central SYSLOG server.

It is recommended to have SYSLOG clients forward security related audit information to a central SYSLOG server, which can receive and analyze such information in real time and send appropriate notification information when vulnerabilities are identified.

At a minimum the following parameters should be set in the network clients;

auth.crit

"auth.crit" is a SYSLOG parameter that is used to identify and record critical authentication messages. (e.g.; bad passwords, repeated login failures, etc). A typical entry in the client would look like so;

"auth.crit /var/log/auth.crit

auth.crit @secure_system"

Where "/var/log/auth.crit" is the name of the file to store audit messages locally on the system and "secure_system" is the name of the system that the client sends "auth.crit" messages will be sent.

SYSLOG also has the capability of monitoring other applications such as TACACS, POP, TCPWRAPPER, FTP, TFTP, and other inetd services. Check the individual application to identify the SYSLOG tag to be used.

If SYSLOG capability is not available for specific applications (e.g.; WEB, FTP, etc) a script can be used to read audit trail data from a file and send it via SYSLOG to the central location. Such scripts are used widely within the NetworkMCI Internet network, and are available to this distribution ( ftp://ftp.mci.net/pub/securityapp-monitor.tar.Z/).

NETWORK MONITORS

There are several programs which can monitor network traffic for unauthorized, or suspicious activity. Network monitoring, along with audit file monitoring, provide a very good first line of defense for proactively monitoring the state of security on your systems. One such Network Monitor, NETLOG, can monitor for network problems, application vulnerabilties and other network based events. Other tools include; GABRIEL and COURTNEY. All such tools include source code to allow you to customize the tool for your specific environment.

CRON JOBS

CRON JOBS (the ability to schedule commands on a system) can be used to regularly run commands to check the system for security functionality or assessment.

TCP WRAPPERS

TCP Wrappers can be used to provide access control to specific systems, as well as audit unauthorized access attempts to individual system elements.

Use Telephone exchange scanners

Routinely scanning internal telephone exchanges for modem tones, enables the ability to identify possible unauthorized implementations of dial-up access capabilities to access internal systems. Such capabilities are often unsecured, as they bypass traditional security polices.

Control Group Accounts

The use of group accounts should be examined from an implementation and policy standpoint. Identification on who is using group accounts and for what purpose should be understood, as well as a clear policy guideline on the use of group accounts.

If at all possible, modifications should be made to group accounts so that a user much log in with an individual name and password, then obtain access to the group accounts. Groups accounts should not be able to access the system directly.

Deploy Virus Scanners

Virus scanners should be used as part of your and your employees daily routine. Computer virus's continue to grow at an alarming rate and have the capability of affecting any media that touches your computer, including network connections.

Virus scanning programs should be purchased and placed on all employee computers. It is preferable to purchase virus identification software that has the capability of running automatically, without requiring user initialization, as the majority of user populations tend to forget about integrating these routines in their daily work habits.

If applicable, implement a network storage site to allow employees to access and download security related software, including virus scanners, and make them aware of the importance of such procedures and the availability of when updated scanning programs are available.

Destructive virus can erase or alter data, as well as make entire hard drive partitions inaccessible, sometimes significantly overshadowing the cost of deploying an effective virus control program.

Control ROOT/SUPERUSER accounts

Privileged accounts should be tightly controlled and monitored. The ability to access a privileged account via direct login should be disabled (user should log in with his/her individual account, then obtain superuser privileges).

Password policy rules should be enforced on superuser password selection, as well as password expiration and rotation.

If available, access rules should be applied per system so that only authorized individual accounts have the ability of obtaining superuser privileges.

A cautionary word should be provided regarding any Administrative access to a system. It is recommended that administrative access only be obtained after an individual access has been obtained (eg; logging in with your individual account, then obtaining administrative access). Remote access to administrative usernames is also a major concern.

It is recommended that one-time passwords be used to access administrative accounts, this prevents interception of such passwords in network transit. Packages such as S/KEY, or hand-held authenticators like SecurID can be used to elevate this concern.

Network Security

Additional public domain (and commercial) tools exist to aid in the security of networks. These tools monitor the overall status of network security, not necessarily individual client security.

Gabriel

Specially designed to detect SATAN scans and attacks, but also can detect other types of scans, probes and system attacks.

ARGUS

Used to monitor packet headers and traffic types. Ability to analyze traffic to identify possible trends, as well as traffic that bypassed Cisco firewall filters.

Thse tools may be obtained via anonymous FTP from ftp://coast.cs.purdue.edu/pub/tools/unix/.

Step 7

Identify gateway machines

Special attention should be paid to gateway/firewall systems, as they usually control access to network elements. Such gateways should be identified, its function within the network should be assessed and owners or administrators should be identified early on to resolve security related issues with such elements.

Step 8

Obtain access to gateway systems to ensure firewall polices

If a function of the gateway is to protect elements, or such functionality exists and could be used to protect network elements, then access to the gateway should be obtained in order to review current Access Control policies and the security of the system itself.

Such access can then be used to facilitate automated scripts to ensure the security of such machines.

Step 9

Secure gateway systems

Security of the gateway itself is imperative to ensure the security of the systems behind it. A thorough examination of the gateway is in order to ensure security policies are being exercised. In this example, we will be reviewing the security precautions available for CISCO routers:

Turn off unsecure services
- Finger
- IP Forwarding
- Loose source routing
Ensure the system has appropriate security patches
- Cisco "established" security patch
- Ip route-cache patch
Secure access to the gateway
- ACCESS-CLASS used to identify who can access the router
- Disable SNMP Write
- Enable SNMP-ACCESS class restrictions
- TACACS used to provide username/password authentication
Ensure Access Control List policies are carefully reviewed, implemented and monitored. Care should be taken to ensure that the firewall policy takes common TCP/IP threats into account. Such threats include:
- IP Spoofing
- Protocol attacks (FTP, SNMP, etc.)
- TCP Fragmentation Attacks

Once a firewall policy has been reached, the firewall should be monitored at all times to detect additions, modifications or deletions. A monitoring program could be used to audit the on-line ACL on a routine basis to identify any changes. An example of such a program is "pollem" ( ftp://ftp.mci.net/pub/security/pollem).

Step 10

Develop a comprehensive Firewall model

Used correctly, Firewalls can provide a valuable piece to your overall security model. Firewalls should be used to protect your internal networks from untrusted networks (e.g., internal test labs, the Internet, etc). Firewalls can also be used to segment internal LANs to separate operational functionality. This allow developing internal firewall policies to keep Engineering employees from having access to the Human Resources department for example. Firewalls, however, should not be the only solution available in your security model. Firewalls provide perimeter security, and do not address security issues on individual systems. This is analogous to a hard crunchy outside, and short chewy inside. In addition, Firewalls do not completely address all perimeter security concerns; there are modem dialup lines and other internal LAN/WAN connection issues that must be addressed.

There are wide variety of firewall products available on the market today, a majority of which provide a wide variety of functionality, from standing filtering rules (Access Control Lists), to encryption to enhanced authentication.

Firewall administration should be centrally controlled and evaluation of firewall policies should be done prior to actual firewall deployment.

Authentication requirements to Firewall systems should be a critical concern, and it is suggested that only the use of one-time passwords are used to access Firewall elements. It is also suggested that a daily audit of all Firewall configurations is performed to ensure no unauthorized changes have taken place.

Some available Firewall Products available today are:

PRODUCT	Company Name	Street Address	City	State	ZIP	Phone
ANS Interlock	ANS CO+RE Systems	100 Clearbrook Road	Elmsford	NY	10523	914-789-5337
ASR 4200	ACC Network	8320 Guilford Rd suite G	Columbia	MD	21406	410-290-8775
BlackHole	Milky Way Networks	2650 Queensview Dr, suite 255	Ottawa	Ontario CAN		613-596-5549
BorderWare	Border Network Tech.	1 Yonge St, Suite 1400	Toronto	Ontario CAN		416-368-7157
CyberGaurd	Harris Computers	2101 W Cypress Creek Rd	Ft. Lauderdale	FL	33309	305-974-1700
DEC SEAL	Digital	40 Old Boston Rd	Waltham	MA	01775	508-496-8626
Eagle	Raptor Systems	69 Hickory Dr.	Waltham	MA	02154	617-487-6755
Firewall-1	Checkpoint Software	One Militia Dr	Lexington	MA	02173	617-859-9051
SunScreen	Sun Microsystems	2550 Garcia Avenue	Mountain View	CA	94043	408-255-2937
Gauntlet	TIS	2060 Washington Rd	Glenwood	MD	21738	301-854-6889
ToolKit	TIS	2060 Washington Rd	Glenwood	MD	21738	301-854-6889
GFX-94	Global Tech, Assoc	3504 Lake Lynda Dr, Suite 160	Orlando	FL	32187	407-380-0220
IRX Livingston	Livingston Enterprises	6920 Koll Center Parkway #220	Pleasanton	CA	94566	510-426-0770
Int Security Router	Atlantic Systems	Incutech Center, Bag Service	Fredericton	CAN		506-453-3505
NetGate	Smallworks of Travis	4401 Stone Meadow Lane	Austin	TX	57831	512-338-0619
NetSP Secure Net	IBM	POB 12195, MS B44A-B501	ResearchPark	NC	27709	919-254-5074
Network-1	Network-1 Software	909 Third Ave (9th floor)	New York	NY	10022	800-NETWORK1
Portus	Livermore Software	1602 Mosay Stone	Houston	TX	77077	800-240-5754
Priv Internet Ex	Network Translation	1901 Embarcadero Rd, Suite 108	Palo Alto	CA	94303	415-494-6387
Security Router	Network Systems	7600 Boone Avenue North	Brooklyn Park	MN	55428	612-424-1784
Sidewinder	Secure Computing	2675 Long Lake Rd	RoseViller	MN	55113	613-628-2700
Cisco	Cisco Systems	PO BOX 3075	Menlo Park	CA	94026	800-553-NETS
SmartWall	V-One	12300 Twinbrook Parkway, #235	Rockville	MD	20852	301-881-2297
Brimstone	Sources Of Supply	461 Fifth Ave., 16th Floor	New York	NY	10017	800-SOS-UNIX
Freeston	Sources Of Supply	461 Fifth Ave., 16th Floor	New York	NY	10017	800-SOS-UNIX

Step 11

Develop notification mailing lists

Be prepared to respond to security incidents. Develop security notification lists for; HR Managers, PR Contacts, Legal, Upper Management, Department Heads, Project Contacts, etc.

Step 12

Be proactive

The key to identifying security issues before they become incidents is to be proactive. Staying in tune and up-to-date on security related issues should be the single most important aspect of your security program.

There is a significant number of resources available on the Internent and within the industry that provide accessibility to this type of information.

Keeping up-to-date with the flood of security topics can also be overwhelming if not handled in a controlled manner.

When subscribing to security mailing lists, be sensitive to the amount of projected mail that is expected to originate from those lists. Deploy email filtering programs to automatically file this mail if possible, and scan such mail for concerned keywords.

There are also a number of organizations that collect this information and provided summaries of such. Although subscription to these services can be invaluable, analysis of the frequency of their distributions and the sources of their information is a crucial aspect of subscription.

Subscribe to mailing lists

Firewall Mailing List: Send "subscribe firewalls" to majordomo@greatcircle.com
CERT Alerts: Send "subscribe" to cert-advisory-request@cert.org
Coast Mailing List: See http://www.cs.purdue.edu/coast/coast.html
IDS Mailing List: Send "subscribe ids" to majordomo@wyrm.cc.uow.edu.au
CIAC Mailing List: See http://ciac.llnl.gov/

Subscribe to security news groups

Employee Awareness Issues

Ensure security policies are in place and enforced. A good employee awareness program is crucial to ensuring that employees understand the risks and the reasoning for the amount of effort needed in company security programs.

Your security awareness program should include posters, seminars, and memos that provide employees with informational items on security facts, even including news clippings of recent security events.

Without employee involvement, security enforcement becomes extremely difficult, if not impossible to maintain at a high confidence level.

Obtain security related tools

Tripwire, SWATCH, S/KEY, Argus, SATAN, COPS, npasswd+, ISS, anlpasswd, binaudit, chrootuid, Courtney, crack, deslogin, dialup2.0, etherprobe, etherman, interman, ip_fil, ipacl, TCP Wrapper, logdaemon, netaccess, netlog, nfswatch, nping, tcpr, tiger, etc (see ftp://coast.cs.purdue.edu/pub/tools/)

Other Security Sites available

Computer & Network Security Reference Index: http://www.telstra.com.au/info/security.html
Computer Security Resources: http://www.sparc.com/charles/security.html
NASA: http://nasirc.hq.nasa.gov/
8LGM: http://www.8lgm.org/home.html
Security Links: http://www.c3.lanl.gov/~mcn/cseclinks.html
Cryptography: http://www.itr.ch/~pheinzma/crypt.html
HTTP Security Group at W3C: http://www.w3.org/hypertext/WWW/Security
Firewall Summaries: http://iwi.com/pubs/fwform-intro.html
Network Security & Firewalls: http://www.tis.com/Home/NetworkSecurity.html
SAIC: http://mls.saic.com
Unix Security: http://ausg.dartmouth.edu/security.html
Unix Security: http://www.alw.nih.gov/Security/security.html
COAST: http://www.cs.purdue.edu/coast/coast.html
Network/Computer Security Technology: http://www.tezcat.com/web/security/security_top_level.html
FIRST: http://www.first.org

SECURITY PROGRAMS

Exposure Analysis
- COPS
- SATAN
- ISS
- Tripwire
- Crack
- Securescan
Authentication and Control
- S/Key
- SSH
- Kerberos
- Crack
- NPPASSWD
Encryption
- SSH
- Kerberos
- STEL
- DESlogin
- PGP
Access Control
- IPACL
- TIS FWTK
- chroot
- dialup2.0
- ip_fil
- portmap_3
- rpcbind
- tcpr
Log monitoring
- Netlog
- ARGUS
- Gabriel
- Courtney
- log_tcp
- logdeamon
- nfswatch
- pmon

These tools are available at: ftp://coast.cs.purdue.edu/pub/tools

SECURITY RELATED BOOKS

Bill Cheswick and Steve Bellovin. Firewalls and Internet security: Repelling the Willy Hacker. Addison-Wesley

David A. Curry. Unix System Security: A guide for Users and System Administers. Addison-Wesley

Rik Farrow. Unix System Security: How to Protect Your Data and Prevent Intruders. Addison-Wesley

Simon Garfinkel and Gene Spafford. Practical Unix Security. O'Reilly and Associates

Katie Hafner and John Markoff. Cyberpunk: Outlaws and Hackers on the Computer Frontier. Simon & Schuster

Bruce Sterling. The Hacker Crackdown: Law and Disorder on the Electronic Frontier. Bantam Books

Cliff Stoll. The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage. Doubleday

Steve Levy. Hackers: Heroes of the Computer Revolution. Dell Books

Karanjit Siyan and Chris Hare. Internet Firewalls and Network Security. New Riders Publishing

Nichelle Slatalla and Joshua Quittner. Masters of Deception: The Gang that Ruled Cyberspace. Harper Collins

Charlie Kaufman, Radia Perlman and Mike Speciner. Network Security: Private Communications in a Public World. Prentice Hall

ADDITIONAL RECOMMENDATIONS:

1) Make use of one time password technologies

S/KEY
SecurID
Kerberos V
Digital Pathways

2) Encryption

Link encryption - Encrypt sensitive data links
- Semaphore
- Cylink
Data Encryption - Encrypt sensitive email
- PGP
- TIS/PEM
File Encryption - Encrypt sensitive data online
- RSA
- PGP
- DES

3) File Access Policies

Ensure file access policies are established so that only authorized users can access files.

4) MD5 Checksum File

A common attack on internal systems by computer hackers is to replace system programs with modified versions, used to either hide their access, or allow them to access the system through "backdoor" methods. It is a good idea to compare active, critical binaries on your system with a master list of valid binary checksums. MD5 is the preferred method, as computer hackers can easily make modifications to such programs that fool standard checksum programs.

Several programs exist to allow this functionality, including TRIPWIRE and TAMU's TIGER.

5) User access histories

Use of the shell history feature (e.g., csh .history, or .bashistory, etc) provides an additional auditing feature in your security model arsenal. Use of this feature may allow you the ability to identity possible system abuse by examining these history files for any unusual or suspicious command sequences.

6) Enforce password change cycles

If you MUST use reusable, disclousable passwords, ensure that the passwords are maintained with an expiration date to force password change cycles. The more a static password is used, the more chances of that password being disclosed or compromised.

COMMON EXPOSURES

1) Social Engineering

This, by far, is the number one exposure relating to compromise of information. Social Engineering is the process in which an unauthorized individual attempts to represent themselves as an internal employee or another trusted party to gain information.

2) Poor Passwords

Users tend to pick easy to remember passwords, which equate into easy to guess passwords for unauthorized users.

3) Sendmail

There are several older versions of sendmail that provide the ability for unauthorized users to gain unauthorized access to a system.

4) NFS

Network File System protocol attacks are very common due to poor security export controls of available file systems.

5) Sniffable Traffic

A common attack by unauthorized users is to place "sniffing" programs on compromised systems used to collect other account information (e.g., usernames and passwords). This can be used to expand the scope of an intruders attack to attack and compromise multiple systems within your network. Whenever possible, make use of one-time password schemes.

6) WEB Server Security

There is a significant dependance on the WEB for day-to-day and mission critical Internet activities; Indeed the WEB is the future of the Internet and if we're not careful, its next downfall.

The WEB's greatest strength, its flexibility, is also its greatest flaw. CGI scripts that provide functionality for your users, can open the door to intruders.

In addition, WEB Servers can be programmed to index available information, and sometimes can be accidentify configured to index too much information. (Ever try to search for the word "/etc/passwd" at www.altavista.com?).

The following guidelines can be used to help ensure that your WEB Server environment is secured:

Limit server access to a specific area on the host. Some Web Servers, eg OMI, offer a chroot directive in in the configuration file. Others can be chrooted using the chroot utility, although this typically involves copying some system libraries and device files.
Set user ID and group ID to nobody to run HTTP server. Make sure that no files or directories other than WEB log data, are writable by user/group nobody.
Map document root to a specific directory, client can only access that area.
Disable directory index unless it is necessary.
Enforce to use secure protocal (shttp, https, PCT) to access sensitive documents and regions require password.
Set allowed hosts list, only those hosts can access private/sensitive documents.
Protect key database and server password (use to encript the server key), ie set file mode to 600.
Secure transfer all files may contain passwords (eg server core dump, configuration file, key file, etc).
Review server logs frequently for signs of misuse and attempted breakins.
Do not put script language interpreter in cgi bin.
Never pass user input directly to an interpreter (e.g, /bin/sh, /bin/perl, etc).
Scrub all input data for malicious content such as shell meta-characters. User input should be considered to include all fields in an HTML form, including hidden fields that the users weren't supposed to modify. User input should also include environment variables set by the server such as the name of the remote host or remote user.
For detail CGI script security, please visit following sites:
Disable other network based applications that aren't used by the server.
Ensure used network based applications are secured (e.g., smtp, ftp, etc)
If using a WEB based administrative tool, ensure you restrict access to only authorized systems (via IP address, rather than hostname). Always change default passwords.
Ensure you know what files are accessable via the WEB Server. (e.g., many sites unknowningly allow access to "/etc/passwd", allowing unauthorized users to identify guessable passwords).

This document can be obtained in updated form from http://www.security.mci.net/web-security.html

7) Denial Of Service Attacks

Denial Of Service Attacks, the most recent Internet Plauge, are having dramatic effects on the service and stability of its victims.

Although not new, the increased accessability of the Internet and the ever decreasing age and sophistication of the average computer hacker, is resulting in an enourmous surge in the type of attack which is specifically and soley intended to deny service to the system or application. In many cases, the exploit code to conduct these attacks are freely available on the Internet, and can effect the stability of systems by a few keystokes and mere click of the mouse.

These attacks take advantage of deficiencies in the TCP/IP protocal, used as the baseline of communications on the Internet, and are difficult, if not impossible, to trace to their source since the packets can be "spoofed" or "forged" as coming from any source on the Internet.

Several types of attacks exist:

* SYN ATTACK

PROBLEM:

From CERT Alert CA-96.21:

"When a system (called the client) attempts to establish a TCP connection to a system providing a service (the server), the client and server exchange a set sequence of messages. This connection technique applies to all TCP connections--telnet, Web, email, etc.

The client system begins by sending a SYN message to the server. The server then acknowledges the SYN message by sending SYN-ACK message to the client. The client then finishes establishing the connection by responding with an ACK message. The connection between the client and the server is then open, and the service-specific data can be exchanged between the client and the server. Here is a view of this message flow:

<--------------------SYN-ACK

ACK-------------------->

Client and server can now send service-specific data

Creating half-open connections is easily accomplished with IP spoofing. The attacking system sends SYN messages to the victim server system; these appear to be legitimate but in fact reference a client system that is unable to respond to the SYN-ACK messages. This means that the final ACK message will never be sent to the victim server system.

The half-open connections data structure on the victim server system will eventually fill; then the system will be unable to accept any new incoming connections until the table is emptied out. Normally there is a timeout associated with a pending connection, so the half-open connections will eventually expire and the victim server system will recover. However, the attacking system can simply continue sending IP-spoofed packets requesting new connections faster than the victim system can expire the pending connections.

In most cases, the victim of such an attack will have difficulty in accepting any new incoming network connection. In these cases, the attack does not affect existing incoming connections nor the ability to originate outgoing network connections.

However, in some cases, the system may exhaust memory, crash, or be rendered otherwise inoperative.

The location of the attacking system is obscured because the source addresses in the SYN packets are often implausible. When the packet arrives at the victim server system, there is no way to determine its true source. Since the network forwards packets based on destination address, the only way to validate the source of a packet is to use input source filtering..."

SOLUTIONS:

The SYN Attack rests at the very core of identified weakness of the TCP/IP protocal, and are difficult, if not impossible in some cases, to correct.

Things you can do:

ISS:

http://www.iss.net/RealSecure

http://www.checkpoint.com/fw21/syndefender/index.html

http://www.fc.net/phrack/files/p48/p48-13.html

* ICMP or PING FLOOD ATTACK

PROBLEM:

Known as a "Ping Flood" attack, computer hackers send a steady stream of PING packets (known as "echo request" packets) to your system(s). In many cases, this flood of traffic can consume system resources, and even consume significant amounts of bandwidth on mid to low speed connections (eg; T1 and below).

SOLUTIONS:

o Block Traffic

o Report abuse to your Internet Service Providor

* MAIL BOMB

PROBLEM:

Unauthorized users can send large amounts of large email messages to and through your email server, often filling up disk space on your mail system, denying email services to other users.

These attacks usually involve the unauthorized user(s) sending thousands of large binary attachments to a single or multiple valid users on your server (or spooling through your server in attack against someone else, using your server to hide his tracks).

Once the disk fills up, additional messages are rejected by the server.

SOLUTIONS:

In addition, monitoring systems should check for active disk space on your systems, and reporting when your partitions are in jepordy.

For example, having the mail spool, queue and/or users mail directories on a Unix ROOT file system may effect the available of the system itself if the system was subject to a successfull Denial Of Service Attack.

* SYSLOG and SNMP Bombs

PROBLEM:

Unauthorized users can send large amounts of large log messages to your logging server, often filling up disk space on you system, denying collection of additional logging data.

These attacks usually involve the unauthorized user(s) sending thousands of large log messages to your server.

Once the disk fills up, additional messages are rejected by the server.

SOLUTIONS:

In addition, monitoring systems should check for active disk space on your systems, and reporting when your partitions are in jepordy.

For example, having a log message directory on a Unix ROOT file system may effect the available of the system itself if the system was subject to a successfull Denial Of Service Attack.

Updated information on Denial Of Service Attacks (DoS) and identified corrective measures can be found at: http://www.security.mci.net/dos.html.

8) WEB Broswer Security Issues

Many people "surf the web" under the mistaken impression that their identity is anonymous to the sites that they visit and, in some cases, to the network that they surf on.

Your WEB browser may be providing information to WEB Servers without your knowledge, or your permission. In some cases, WEB servers may be uploading a "tracer" to your browser to a) track your activity on the WEB and b) track how many times you visit a particular WEB site. This activity can be used, for example, by Marketing organizations for mass or even individualized WEB advertising.

This information can be obtained in several ways:

WEB Server Transaction Logs
Browser "cookies"
Browser icons

9) DNS Naming Conventions

DNS is the service that lets you map IP addresses to hostnames, and vis versa. When connecting to the Internet, great care should be taken into how your hostnames are picked, as they can be used by "bad guys" to obtain potientially useful information on the makeup of your internal network, potiential projects that you are involved in or names of employees to target for Social Engineering.

It is quite trivial for an unauthorized user to pull every hostname out of your DNS tree. Should these hostnames represent potientially confidential or sensitive information, the attacker can use that to gain additional information about your organization.

For example:

billspc

adminstation1

cisco-test-5

One solution to this problem is to run two DNS servers; one external and one internal. However, a significant amount of administrative overhead comes into play with this.

OTHER CONSIDERATIONS

The following are bulletined items of considerations that should also be taken into account when developing a comprehensive security status for your networks and systems. These items are only provided as a reference, and additional documentation is required to fully understand the nature of these concerns:

1) Network Security Policies and Procedures

Comprehensive security and network polices need to be developed and deployed widely within the company

2) Backups

Ensure you have appropriate backup policies, and off-site storage considerations

3) Physical Security

Ensure physical access to sensitive systems is reviewed on a regular basis.

4) Information Security

Paper based information should be properly marked and controlled, as well as disposal of such information

5) Contractors/Vendors

Policies and procedures should be taken into account for non-company employees. This includes restricted shells, secure access, etc.

6) Human Resource Termination Lists

Security and Administrative personnel must obtain the ability of being notified appropriately when employees, contractors, vendors and other users have left the company, and when such access needs to be removed from systems and applications.

7) Employee Education Issues

Routine educational awareness seminars must be provided to company employees to make them fully aware of security-related issues to ensure that they relate their day-to-day activities in association with the educational seminaries they have had. Emphasis should be paid to upper-management to ensure their support is obtained.

8) Encryption

Use of encryption to protect sensitive links is a valuable tool to ensure compromise of confidential information is not compromised. Encryption models can be used to protect email traffic (eg; via the use of PGP or TIS/PEM) as well as session data (eg; the use of software of hardware modules to encrypt traffic between two machines/networks).

9) Inventory

Make an inventory of the network elements contained in the network, what their purpose or function is, and who administers that system. This information can be invaluable when responding to security incidents or assessing proper network security models.