Unix & Internet Security White Paper

by Len Rose <len@netsys.com>

Presented at KAIST (Korean Advanced Institute for Science and Technology),
SNU (Seoul National University), and POSTECH (Pohang University of Science
and Technology) in Korea during April 2000.

What is Internet Security?

What is Internet Security?

I will try to answer that as I see it. My opinions are based on years of experience
in real-world situations, but after all, these are just my opinions.

Internet security is perhaps better described as an exercise in compromise.

What do I mean?

In order for me to explain that, let’s talk about the original idea behind the
Internet.

The Internet was created to allow academic and other research institutions to
exchange ideas. These ideas are represented within data. In order for this data
to be exchanged, you have to allow the data to be sent from here to there or vice
versa.

The business of Internet security is often defining what data you wish to allow
your organization to be able to send and receive via the Internet. While you may
wish your remote sales people to be able to input sales orders from their laptops
in some far away city, you certainly don’t want unwanted data transfers to and
from your network.

It’s a question of making compromises. These compromises are of the sort that
determines how much loss of Internet functionality your organization is willing to
sacrifice in order to achieve an acceptable level of security. Who decides what is
an acceptable level of security? Your senior management will decide, hopefully
with input from you. You will be paid to advise them, and hopefully they will listen
to you.

1
In order to preserve functionality you will always have to sacrifice some measure
of security. In order to preserve security you always have to sacrifice some
measure of Internet functionality. The kinds of compromises you will have to
make will depend on the operational needs of your organization. In most
organizations you will often have to weigh the risks, deliver your assessment to
senior management and then let them decide.

In my experience, Internet security is about 20% technology, and 80% vigilance.

No amount of hardware in the world will help you if no one is watching your hosts
and networks. An analogy is the famous candy commercial (M&M candy). A hard
shell and soft chewy center. To translate this to real life, don’t rely on having a
secure external defense, yet leave all of your hosts unprotected. Rely on both
good network security, and good host-level security. Always try to implement
multiple levels of protection if possible.

Whose job is Internet Security?

The lines between network security and systems security have finally blurred into
a mixture of both networking and system administration. A competent systems
admin has to have an intimate understanding of internetworking, and a
competent network should have an intimate understanding of systems
administration. I do not believe you can be good at either of those jobs unless
you are aware of the implications of the network or the implications of how the
systems that live on the network actually perform their functions. Sun’s adage of
“The network is the computer” has been proven to be the model that we all
work from today. We could not do our jobs if there were no network, as no single
host is sufficient in today’s multi-platform, multi-purpose environment.

Zones of trust:

Establish zones of trust. Decide what groups within your organization actually
need to access certain hosts, and by either implementing access control
mechanisms on the hosts themselves, or filtering routers you can control access
within your internal networks. Don’t assume that just because someone works for
your company that they can be trusted. In my experience, most attacks come
from within, or are committed by employees.

Establish concentric rings of increasing security levels if possible. By enforcing

different levels of security within your internal network you demonstrate to your
senior management that you understand the needs of the company. Refer to
slide Z1

2
As an example, you can accomplish this by utilizing vlans on Cisco switches
such as 8500 series. Since you can implement RFC1597
(http://www.netsys.com/rfc/rfc1597.txt) networks, you won’t have to be concerned
about wasting address space by segmenting your networks. Managing these
zones of security can be somewhat less convenient but you should implement as
much security as the information requires. As a byproduct of using NAT (or any
private RFC-based network design) your networks will be unreachable from
outside (the internet) and most attacks will be rendered null and void. This leaves
only your gateways to defend, and you should never allow external gateways
access to the internal networks unless you’re using some sort of VPN (private
virtual network) tunneling mechanisms. These are risky in themselves as this
means you’re extending trust to a remote system. In this case your internal
network security is totally reliant on the security of the remote location. (Refer to
Slide V-1)

3
 “Secure your hosts and network according to the needs dictated by the
sensitivity of the data”

Host Level Security - Unix Specifics:

1. Access control mechanisms

What are access control mechanisms? It is any method by which you can
control who

A. Implement tcp wrapper for any service listed in inetd.conf

B. Disable any unnecessary services

4
 C. Modify libc.a to ignore ruserok(3) calls.
D. Enforce good password security
E. Enforce password expirations
F. Implement secondary access control mechanisms such as
SecureCards.

2. Source routing protection

A. Disable source routing on all routers and switches
B. Disable source routing on all hosts.
See RFC 2267 for details. (http://www.netsys.com/rfc/rfc2267.txt)

3. IP Forwarding
A. Disable IP forwarding on all hosts. Especially hosts that are sitting
on your external DMZ networks.
See RFC 1180 for details (http://www.netsys.com/rfc/rfc1180.txt)

4. DNS security.
A. Do not base your access control mechanisms on DNS. Use IP
addresses if possible. (i.e. hosts.access, hosts.deny, sshd_config,
etc)
B. Implement host authentication within your DNS infrastructure.
Recent implementations of bind (bind 8.x) support this. See
http://www.isc.org/products/BIND for further reference.
C. Implement 2 or more dns servers. This will provide you some
redundancy in case of failures.

D. In a corporate environment, Implement split dns (refer to slide D1)

E. Don’t permit open access to dns information, i.e. block zone

transfers. If you do this, people can’t readily get as much
information about your hosts.

5
5. Avoid clear-text protocols!

A. One of my most important recommendations is regarding clear text

protocols. By definition, a clear text protocol is anything that:

1. Exchanges authentication in the clear (i.e. not encrypted)

2. Sends and receives data in an unencrypted form.

It’s easy to do if you are willing to sacrifice some choices in

application software and functionality. In a unix environment this is
easy to do as the SSH suite of programs provides functional
replacements for most r* commands (rsh, rcp, rlogin, etc) and you
can tunnel almost anything through an ssh session.

B. The risks of using clear text protocols:

By using clear text protocols, anyone with a windows workstation can

run a sniffer program and steal logins and passwords.
If you are unable to use encryption, try to use a network device that
can perform arp scrambling like those of 3COM.

These hubs perform a randomized physical address jumbling (arp

scrambling) and can be used to prevent hosts from sniffing any traffic
that isn’t directly addressed to them. Refer to slide S1.

6
 By the very nature of devices like these, you can almost assure
that data privacy is guaranteed.

6. Syslog, Syslog, Syslog.

A. Turn on as much logging as possible by implementing access

control mechanisms that log every access attempt.
B. Organize your syslog data by log level and priority.
As an example institute standards for classes of logs:

Security: local1.debug

/etc/syslog.conf

local1.debug /var/adm/security.log

Then modify tcp wrapper, sshd, etc to log at this level. Only
concentrate on the logs that are important!

C. Secure you syslog server as you would a bank vault.

D. Monitor you logs with log processing tools that generate reports on
unusual events yet filter unwanted noise.
E. Archive your logs as long as possible.

7
 F. Isolate your syslog server behind it’s own defense system.

7. Keep your hosts well maintained.

A. Always install the latest security-related patches.

B. Clean up old unused accounts.
C. Review access control mechanisms regularly.

8. X-Windows

A. Most modern X-Windows implementations have secure modes.

Use them.
B. Remote use of X-Windows should be eliminated unless you tunnel
X through ssh.
C. Remove X-Windows on any server that doesn’t require this service.

9. NFS

A. Never, ever employ NFS outside of a filtered network.

B. If possible, implement NFSv3 (has more security features)
C. Employ very specific exports if possible.
D. Combine with secure rpcbind.
E. Be very careful with trust relationships (i.e. don’t export NFS to non-
trusted servers.)

10. FTP

A. Try to eliminate WUARCHIVE-derived ftp server. Use ncftpd if

possible. (See http://www.ncftp.com) Any server derived from the
original wuarchive source code is always suspect. Ncftpd is a very
robust ftp server, supports virtual ftp, and doesn’t rely on any other
unix binaries, and supports a separate password file.

B. FTP is obviously a clear-text protocol. If possible avoid use of ftp at

all, instead using scp (which is part of the ssh suite)

11. Password Security

A. Implement regular crack scans on your password files.

B. Enforce password expiration policy if possible.
C. Replace passwd(1) with a version that enforces good passwords.
D. If you are running a version of unix that doesn’t support shadow
password files, try to implement public domain shadow password
support.
E. Set all default or system accounts other than root to a fake shell.
(i.e. /bin/false) .. In case your system is compromised from remote

8
 you make it more difficult for intruder to actually abuse these
accounts because they won’t have an executable shell to work with.

12. Sendmail

A. If possible, replace Mprog declaration within sendmail.cf with

/bin/false. If you are unable to do this, replace it with smrsh.
The risks of leaving Mprog enabled means that you are leaving a
method of attack for remote sendmail exploits. On external firewalls
or mail servers, try to avoid use of any sendmail-based “mail to
program” methodology.

Network Level Security:

In today’s very hostile environment, a filtering router is no longer enough

to guard against a determined attack, however a filtering router in conjunction
with a firewall is often the best approach to securing your networks.

1. Whenever possible implement strict filtering on IP traffic. This should be

based on explicit deny and specific permit access lists. In simple terms
allow specific ports, and protocols that are the minimum acceptable level
of service, and deny everything else.

2. Employ point-to-point IP encryption technology wherever possible,

including internal leased line networks between corporate offices. Some
examples of IP encryptions technology are the NSC Borderguard router,
used by the United States National Security Agency. (This router was
originally manufactured by NSC but it was recently sold to Blue Ridge
Networks (www.blueridgenetworks.com). Another example of VPN
encryption is the Cisco PIX firewall system with VPN support. (See
www.cisco.com) for further information. Cisco also has plug-in encryption
expansion board products for many of their Catalyst ethernet switches.

3. Layered Approach to Network Security

Use 2 or more layers of devices to protect your networks.

Refer to Slide N-1

9
3.1 Implement access lists on external routers if possible

3.2 Disable Source Routing. Using Cisco IOS, the command would be:
“no ip source-route” Some of the issues that are solved with this
would be to help eliminate IP spoofing.

3.3 Establish Access lists that prevent an internal source address from
being seen on an external interface. This can help eliminate source
routed attacks (i.e. if you didn’t disable source routing for operational
reasons.

3.4 Disable broadcast attacks (smurf attacks) Using Cisco IOS, the
command would be: “no ip directed-broadcast” You should
implement this on all interfaces.

3.5 Disable ICMP redirects. Using Cisco IOS, the command would be:

“no ip redirects”

10
 3.7 Disable unrestricted access to routers, i.e. disable telnet, etc. Using
Cisco IOS, the commands would be:

“line vty 0-x”

access-class 20 in
[snipped]
access-list 20 permit x.x.x.x 0.0.0.255

If you remember that Cisco access lists are processed such that if
an access list exists, anything not listed as allowed is explicitly
denied.

3.8 Disable small servers: Using Cisco IOS the commands would be:
“no service finger”
“no service udp-small-servers”
“no service tcp-small-servers”

3.9 Implement ssh on modern versions of Cisco routers.

3.10 Implement SecurID (or other tokenized access control methods)

3.11 Disable public SNMP access to your routers and other network
devices.

3.12 Implement vlans to help segment users into various security

groups. For instance, engineering staff may need more access than
sales staff. Since modern corporate networks are “flat” and more likely
to be based on large ethernet switching architecture, vlans are quite
useful.

4. Internal dialup access points.

4.1 Employ dial-back security if possible.

4.2 Employ secure access cards.

4.3 Require encryption protocols, (ssh, des-telnet, ssl, etc)

4.4 Employ PPP dialups with static IP addresses assigned to each employee
so you can establish access control to internal network assets based on IP
address.

11
 4.5 Employ access control mechanisms like radius with strict accounting and
auditing of sessions.

4.6 Don’t permit desktop access to modems. I.E. forbid use of remote access
mechanisms like “PC Anywhere”, etc.

5. Site Security Policy

Establish your site security policy in conjunction with management. Define it

clearly so that each employee understands their rights and responsibilities.
For some guidelines on this, see RFC 1244
(http://www.netsys.com/rfc/rfc1244.txt)

6. Site Security Audits

By using standard tools such as port scanners, MD5 checksums, log analysis,
etc.

1. Maintain a close watch on your external hosts for access attempts. If you
are unaware of who has been knocking on your door then you are not
being vigilant.

2. Create a loghost server that receives syslog from all hosts. Defend this
loghost as best you can. Run regular analysis of all of your security related
logs looking for anomalies, and patterns. Archive these logs in case you
need to research suspect activity months later.

3. Perform regular file system analysis on critical servers. Store MD5

checksums of all system binaries on a secure host, and use these for
comparisons. Tools like tripwire are often used for this purpose.

7. Service Provider (ISP) Security Issues:

12
In many cases the only way to attack a company is through their ISP. Therefore
an ISP has to place much greater emphasis on network security than most
corporate entities.

ISPs should be particularly concerned about BGP security.

It’s possible for an advanced attacker to actually disrupt an entire backbone if

they are able to gain access to the ISP’s core routing infrastructure.

In many cases, customers trust their ISP. Here are some examples of this trust
relationship:

1. secure mail relay

2. DNS (primary)
3. Access to customer routers (internet gateway)
4. Managed firewalls
5. Confidential network design information

You should never choose an ISP that doesn’t have a competent network security
staff as in many cases your security also depends on them. The alternatives are
to maintain your own network and system security staff, but the disadvantages of
that are obvious. – higher staffing costs.

Denial Of Service Attacks:

In a denial of service attack situation you will have to understand the nature of
the attack, which means you MUST have someone who is competent in
analyzing sniffer logs, router logs, who can understand the nature of the attack
and deal with it swiftly. In the past I have seen denial of service attacks take
down large ISP’s due to the sheer amount of bandwidth caused by the attack.
For instance during smurf attacks directed at irc servers, you can easily see
traffic peaking at 200mb in your routing core. Fortunately Cisco has developed
CAR (committed access rate) software to help you minimize these sorts of
attacks. As an ISP you will often have to filter traffic on behalf of your customers
in the case of such attacks. Therefore your core routers must have enough
performance to filter and route at the same time.

Always try to keep some reserve of performance on your core routers, as there
will often be a need to filter during a denial of service attack.

8. Network Intrusion & Detection Systems

13
Network Intrusion Systems (IDS) are basically alarm systems. Their purpose
is to monitor your networks (and by extension your hosts), and notify network
security and system staff when certain conditions exist. These conditions are
configurable by the organization when the IDS is installed.

In order for any IDS to be effective you will have to analyze your
organization’s network and hosts, determine which hosts and networks
should be protected, and establish rules (or conditions) that the IDS system is
supposed to be monitoring.

You configure IDS systems to watch entry and exit points to/from your
network. (and within your network) Most IDS systems look for specific
signatures of an attack or entry method, and most IDS systems can be
configured to watch for any sort of activity depending on what the needs of
your organization are.

Depending on the design of your networks, you may need to implement

distributed IDS. This can be accomplished by using an IDS that can
accommodate remote probes installed on any number of physically separate
networks all reporting (and being monitored) by a central collection server, or
perhaps by multiple independent IDS systems. (Refer to Slide ID-1)

Make sure that you install your IDS systems using TAPS (see

14
www.shomiti.com/products/hardware/tapfamily.shtml) for an example.
Ethernet switch port mirroring is not effective for most IDS installations.
TAPS are really just ethernet splitters, and are often used in switched-network
installations.

The advantages of using IDS.

No firewall is perfect. There are superior individuals out there who may be
motivated by pride, or monetary rewards who are good enough to find ways
around the best security installations. With IDS, you are able to monitor the
effectiveness of your firewall, and generate alarms if your firewall has been
penetrated.

IDS systems can also be used to ensure that individuals within your
organization aren’t engaged in unauthorized transfers of company data.

As far as I am concerned, network intrusion detection systems are still in their

infancy. Network Intrusion systems are no replacement for vigilance. Nor are
they a magic bullet for network security problems. In fact, they can lend a
false sense of security to inexperienced systems and security personnel.

From what I have seen so far, Network Flight Recorder, by Marcus Ranum’s
new company NFR, Inc. (http://www.nfr.net) is the best example of this breed.
Although Cisco’s NetRanger is also adequate, it seems that NFR is the best
performance system on the market today.

With network intrusion detection, you will have another tool at your disposal.
Like any tool, the usefulness depends on the skill of the person who uses the
tool. You have to be able to understand the threats that network intrusion
systems detects, what their weaknesses are, and what their strengths are.

The disadvantages of IDS:

Current IDS implementations are not adaptable without regular updates.We’re

talking about updates to the attack signature database by the IDS vendor.

In other words, they have hard-coded dependencies on specific algorithms

that detect threat situations. In order to keep your IDS system effective, you
are constantly required to input new conditions, new signatures, etc. This
means that for an IDS system to be truly effective you will have to constantly
maintain the system.

15
 Eventually, your IDS could become ineffective due to too many rulesets,
unless the IDS vendor has designed means of scaling, and expansion into the
basic design.

For an IDS to be effective, it has to be operational 24 x 7, otherwise you have

a gap in your defenses and monitoring system.

IDS are very vulnerable to denial of service situations. Most of the threat
comes from overloading. An IDS can be overloaded by several scenarios:

1. Network failures that cause high packet traffic

2. Host failures that cause high packet traffic
3. Denial of service attacks (an actual attack against the IDS itself)
4. General device failures:

A. cpu overload
B. disk capacity
C. memory
D. etc..

IDS are not cheap. This is defined in both actual cost of the IDS, as well as
ongoing maintenance. In order for the IDS to remain an effective tool, it will
require constant maintenance by a security person assigned in this role.

As far as I am concerned, network intrusion detection systems are still in their

infancy. Network Intrusion systems are no replacement for vigilance. Nor are
they a magic bullet for network security problems. In fact, they can lend a
false sense of security to inexperienced systems and security personnel.
.

8. The human factor

It has been proven that most serious security problems come from within,
whether it’s a disgruntled employee, or someone who has penetrated your
organization in order to conduct industrial espionage for profit. Not only
should you be studying incoming traffic, you should guard against
unauthorized traffic within.

This leads us to another point. As far as management is concerned, they

have to be able to trust you, the system and network security experts. This
begs the question, “Who will watch the watchers?” If an unethical or
criminal system or security person is guarding your network, everything your
organization has done to secure their networks has been rendered useless.

16
 This is why some companies prefer to have third-party security firms audit
their security.

Employing consultants (tiger teams) periodically to evaluate your

organization’s security is often useful for senior management’s piece of mind,
as it will allow them to audit the state of their security. If you find yourself up
against a tiger team, the chances are they will succeed in some small
measure due to the human factor. Tiger teams often are able to penetrate the
best security installations because some unsuspecting employee is careless.

In order for you to guard against employee carelessness, you will have to
educate your user community, strictly enforce security policies, and rely on
senior management to help you enforce those policies.

(Discuss social engineering here)

9. Windows “Security”

While I am certainly not an expert with regards to Windows, and Windows NT, I
do have some minor points to make about these operating systems. The serious
vulnerabilities inherent in CIFS (a.k.a. NetBEUI a.k.a. NETBIOS) simply dictate
that you never, ever rely on these systems to store secure data unless you have
filtered them from the outside world. See ftp://ftp.netsys.com/len/papers/cifs.txt
for further information on this service.

NETBIOS ports 137 through 139, WINS ports 153 are all particularly sensitive
since there are tools designed to brute force attack windows file sharing, and to
disrupt NT domain controllers.

Since Microsoft is less open about their operating system it’s often an exercise in
frustration when trying to secure Windows machines.

My advice to you is to not trust Windows systems in the same sense you trust a
well secured unix server. I suppose I’m letting my prejudices show, but I never

17
really cared for the Micro$oft world and the way things are done there. Perhaps if
we all had access to the source code things would be different.

My advice is to treat Windows machines as a black box that you can’t study or
analyze (unless you just happen to have access to the source code) and try to
follow common sense practices when it comes to Windows security.

Disable “guest” accounts! Only share NTFS partitions (they support ACL’s).

If the server is critical, you may wish to think about implementing the C2 level
security system that comes with the NT resource kit. (See “c2config” on the NT
resource kit.)

Microsoft actually did a decent job of implementing C2 level security, but there
have been problems when trying to implement the C2 security system when
using languages (locale) other than English.

Specific Problems:

Back Office or otherwise known as Back Orifice J

What is Back Orifice?

Back Orifice is a remote control penetration application originally produced and

distributed by the CDC (Cult of the Dead Cow) a mid-90’s hacking group. It
installs itself on machines running Windows 95 and Windows 98, and hides itself.
It uses hooks within the Windows operating system that were originally designed
to support Micro$oft Back Office. Back Orifice becomes a remote
administration tool that can completely control your workstation.

Ever since CDC (Cult of the Dead Cow) wrote this software it has become a
bane to almost any Windows user on the Internet today. This is something that
everyone who uses Windows operating systems needs to be aware of, and
guard against.

It is inarguably easier to compromise a Windows machine than a unix system

because of the way Windows was designed to operate.

With unix, a specific series of commands has to be executed in order to enable

an attachment to be executed.

With Windows, all you have to do is “click” on attachment and it can be executed
right from your mail program.

Most Back Orifice victims merely clicked on an attachment that they received
from either a malicious source or another unsuspecting victim. The odds of being

18
infested by a Back Orifice attempt are even greater if the Windows user likes to
use pirated software. When you run the infected program, Back Orifice secretly
installs itself on your machine. Intruders then have complete control of your
machine.

The issue with this is that in many organizations, windows machines aren’t as
well protected as their unix servers. Once someone has been able to install Back
Orifice on your workstation, they can use your workstation as a tool to conduct
further penetration into your network.

Many so-called “software pirates” take great delight in embedding virus, and
other back-door mechanisms in their “warez” that they distribute.

This is why most MIS departments today insist that users do not download
software from the Internet, and also attempt to have users execute a virus scan
every time they login to an NT domain.

Although I seem to be plugging “NFR, Inc.” a lot, they make a very decent
product for detecting Back Orifice attempts (See http://www.nfr.com) for further
details.

There are very many Windows security references on the network, and I won’t
attempt to document much more about Windows and NT security within this
presentation. Microsoft’s site has a great deal of resources about security, and is
a great starting point for information (If you can wade through the marketing
hype, that is)

Closing Summation:

In conclusion, I’d like to point out is that internet security is applying common
sense practices to managing your hosts and networks. There is not one single
approach to good internet security. Each company’s security strategy will have to
be tailored to your particular needs.

If you are an ISP, the effectiveness of your security will impact your customer’s
security. As an ISP, you have a greater responsibility to your customers, and you
need to also act as a security resource for them.

If you are engaged in internet commerce, you have a responsibility to protect

your customer’s privacy and financial data. There is no quicker way to ruin your
privacy than to compromise your customer’s credit card data, or personal data.

19
20