Host and Network Security

System design and normalization

Security is a property of systems; to address security, we must speak of the system as a whole:

 Identify what assets we are trying to protect.

 Evaluate the main sources of risk and where trust is placed.
 Work out possible counter-measures to attacks.

Counter-measures can be both preventative and reactive. They consist of:

 Rules
 Codified responses.

The foundation of security is policy. We must agree on what is valuable and acceptable in the
system. Without such an assessment, we cannot speak of the risk to those assets, and determine
what level of risk is acceptable. Policy is decided by social groups.

Transport Layer Security

The secure socket layer (SSL) was originally introduced by Netscape communications in order to
allow private web transactions based on X.509 certificates.

(HTTPS is SSL encoded HTTP). Version 3 of the protocol was extended with experiences and
suggestions from other companies in the industry and was published as an Internet draft
document standard. Transport layer security (TLS) is essentially an outgrowth of SSLv3, and it is
intended that this will become a network industry standard.

In reality, the trusted ports can no longer be trusted since every PC owner is a trusted user on
their own system. The threshold for trust has been lowered considerably by the proliferation of
computing.
 Authentication methods

SSL and TLS use public key methods to authenticate sites and establish a session key for
communications. The protocol authenticates both parties and negotiates a computationally
‘cheaper’ encryption algorithm and message digest to sign the message.

SSL is designed to be a drop-in replacement for standard socket communication, easily

implemented, with minimal investment on the part of the programmer.

Roughly speaking, one simply replaces some system calls with library functions from SSL and
the encryption should be transparent. In order to achieve this level of simplicity, a Trusted Third
Party Trust model is used, since this avoids an interaction.

Keys are referred to as certificates and are only accepted on trust if they are signed by a signing
authority (normally Verisign). Any keys that are not signed by a known authority are presented
to users so that they can make a manual decision.

In a system administration context, SSL has both advantages and disadvantages. Clearly, one
does not want to pay a signing authority a hundred dollars or more to authenticate each host at a
site, but this applies mainly to the Web and could be circumvented with custom software. A
larger problem is the centralization of the model: each new communication requires verification
with the central authority, thus there is a single point of failure. Administratively speaking,
forced centralization is either a convenience or a curse depending on how centralized
administrative practices are.

Sign and encrypt attacks

The belief that signing and public key encryption give strong security, especially in combination,
is only partially true. It is still possible to construct attacks against the naive use of these
encryption methods. These attacks apply to a number of security infrastructures, including
S/MIME and IPSec. They are easily curable with administrative care. We define first some
notation for representing encryption and signing:

 Public keys: capital letters.

 Private keys: small letters.
  Encryption with public key A:{”message”}A.
 Signing with private key b:(”message”)b.

Notice that a small letter denotes both signing and the use of a private key, and a capital letter
denotes both encryption and the use of a public key. We now consider the two attacks on the
sign-encrypt trust model.

Protecting against attacks

 Look out for users with weak or non-existent passwords. This is the easiest way for an
attacker to enter the system.
 Train all staff in basic security procedures, and pay special attention to those who are
highly privileged.
 Do not give trusted access to other hosts unless absolutely necessary.
 Make sure there are no NIS wildcards+in /etc/hosts.equiv. Avoid using .rhostsfiles
altogether, and replace all of the old Berkeley ‘r’-commands (rlogin, rsh etc.) with a
version of secure shell (ssh).
 Attempts at initiating ping attack have been identified by large numbers of persistent ping
processes.
 Disable unused services, e.g. in/etc/inetd.conf, which might contain security leaks, like
UUCP, TFTP.
 Make sure that each active service runs in its own sandbox, with nonoverlapping
privileges.
 Make sure the router filters all unnecessary traffic. Usually there is no reason to permit
RPC or SNMP, NetBEUI, or NFS traffic outside of the local domain for instance. Anti-
spoof filtering of IP addresses is also a must: e.g. a packet with a source address from a
network on the other side of the planet cannot
 Originate from inside the local network, so filter it.
 Make sure that the latest security patches are installed on all systems.
 Monitor connections usingnetstat -ato show all listening connections.

Role-based security and capabilities

In a dynamic, interactive situation we could generalize the notion of access to allow users
different permissions depending on what they are doing. This can be done in different ways:

 Define roles for users (e.g. by membership in privileged groups with access to special
systems, like man in Unix).
 By asking a service to carry out an operation, whose abilities have the appropriate
privileges for the task (e.g. WWW, telnet, Java).
 By setting some attribute which determines the allowed permissions for a given task (e.g
Unix setuid programs). Use of abstract ownership (e.g. polymorphic methods in object-
oriented languages).

Unix setuid programs are an example where the activities of a program can be changed (by the
superuser) so as to grant a specific program the right to operate with a different user-identity and
thus privileges (without authentication). The setgid is a corresponding mechanism for setting the
group ownership of a process. Note that setuid programs often give more privilege than is
necessary and such programs have been a major cause of security problems on Unix platforms.

POSIX ‘Capabilities’ have recently been implemented in the Linux kernel. These ‘Capabilities’
are an additional form of privilege control to enable more specific control over what privileged
processes can do by giving them a direct line to the kernel. Rather than making a program ‘setuid
root’, one could give a program privilege to perform a specific task and nothing more. Other
examples are Rule Set Based Access Control (RSBAC), and LIDS (Secure Linux Project) which
implement Mandatory Access Control in the kernel for all kinds of operations on files and
processes. This presents some administrative difficulties for software since there is no longer any
user with complete privilege.
WWW security

The concept of World Wide Web (WWW) security sounds like a contradiction in terms. The
WWW is designed to publish information to the masses. Security has to do with restricting
access. What has the WWW got to do with security?

Web security has to do with:

 Protecting the published data from corruption.

 Granting access only to those files we wish to publish.
 Preventing users from tricking the WWW server into executing unauthorized commands
on the server host.
 Protecting against a protocol that opens the system to all manner of attacks through
abuses of the protocol.

Although there have been many security problems with the feature over-laden Internet
Information Server for Windows, there is nothing principally insecure about the WWW service.
Any file-server can, in principle, compromise the security of a host by making information about
that host available to others. If a server provides access to unauthorized files, this will clearly be
the case. All we need to do is to ensure that proper access controls are maintained.

The Free Apache WWW server has all of the features one requires to operate a secure web
service. It can be run without special privilege, and it has quite sophisticated mechanisms for
restricting access to data. It is nevertheless possible to configure the server in an insecure
fashion, so one needs to be cautious. There are three distinct categories for web use:

 External web service for organization.

 Internal web service for organization.
 Private users’ web pages.

The last of these is arguably the greatest potential security risk for the Web: we usually trust the
files and programs which we write ourselves in the name of our organization, but we have no
reason to trust the integrity of private or guest users.

There are two areas where a security breach can occur:

  File ownership and access rights.
 CGI-scripts.

CGI-scripts can be used to execute commands on the server-host with the user privileges of the
WWW user. Although the WWW user is introduced precisely to isolate the powers of the WWW
service, we can still do quite a bit of damage – not to the host directly, but to other users and to
the web server access controls. It is an inevitable consequence of running a public service with a
private ID that any file which gets written by a CGI-script can also be overwritten by another
CGI-script, regardless of which user is responsible for that script. Thus users could wage war on
one another with CGI-scripts such as guest-books, corrupting or even deleting one another’s data
freely. This is a fundamental weakness in the WWW service: if we allow the existence of
arbitrary CGI-scripts on the system, then we can carry out arbitrary operations with the
privileges of the WWW user. Users can:

 Send anonymous, untraceable mail which appears to come from the WWW user at the
organization hosting the CGI program.
 Circumvent .htaccessaccess controls to certain files on most types of operating system, by
executing the command/bin/cat filenameas part of a CGI-script.

IPSec – secure IP

Many problems in network communication would be easily solved if there were transport layer
encryption of Internet traffic. Spoofing would be impossible, because attackers would have
access to cryptographic checksums of the packet (spoofing could be easily detected). Similarly
sniffing the net for passwords, leaked by old protocols, would be impossible, since no plaintext
data would be sent.

IPSec is a security system developed for use with IPv6, but it has also been implemented for
IPv4 (RFC1636). It offers encryption at the IP level (below the TCP/UDP layer). This means that
common TCP attacks, such as sequence guessing or spoofing attacks, cannot occur since
attackers could never see the contents of travelling packets.

IPSec allows hosts to set security policies on routed packets. It includes access control lists for
encryption, integrity checks and point-to-point private tunnels.
This all sounds like the perfect solution to the problem, however IPSec is not without problems:
it is not fully implemented by network hardware and software today. This could take some time.
IPSec supports both session encryption and strong authentication, based on either public or secret
keys. It consists approximately of two protocols:

 Authentication Header (AH): this describes the initial negotiation of identity and
encryption methods.
 Encapsulation Security Payload (ESP): this describes the encryption schemes and also
relates to the strong authentication of data.

These provide the following services:

 Access control
 Connectionless integrity
 Data origin authentication
 Replay protection
 Privacy (encryption)

Security Associations (SA)

IPSec maintains a security context known as a Security Association (SA), which is a policy
decision that times out after a specified lifetime. A Security Association is uniquely defined by
three parameters:

 Security Parameters Index: This is a context identifier.

 IP destination address: A unicast address that is to be the endpoint for the SA (but not
necessarily the endpoint of a packet/datagram).
 Security Protocol Identifier: Indicates whether an AH or ESP security method is to be
used.

Decisions based on these parameters are collected into a Security Policy Database (SPD), where
they are examined for each packet or datagram that is forwarded by a router, firewall or host.
IPSec is designed to offer great flexibility to administrators;
 IP filtering for firewalls

Filtering of TCP/IP data can be accomplished in numerous ways, both at routers and at the host
level. Filters can exact access control on datagrams, where the attributes are, amongst other
things,

 Source port
 Destination port (service type)
 Source IP address
 Destination IP address
 TCP protocol attributes (SYN/ACK).