Securing Network Services

Secure Systems
1. Security policy
– What needs to be protected
– Kinds / level of protection
3. Security mechanisms
– Responsibilities
– cryptography
– Auditing policy
– authentication
– security protocols
2. Security environment
– Physical environment 4. Monitoring and auditing
– Physical security procedures
– Hardware, operating system – monitor access
– firewalls, etc – audit trails
– feedback on failures,
security breaches
– containment & recovery
Module Code and Module Title Title of Slides
 Topics

• This week:
• Simpler tools that can be used together
• iptables
• tcpwrap
• SASL
• PAM

• Next week:
• More complete AAA systems
– SELinux, Kerberos, RADIUS

Module Code and Module Title Title of Slides

 Layers of Security

Perimeter Controls Fences, Security patrols

Building Controls
Locked doors, Cameras
Facility Controls
ID Badges, Sign-in

Monitoring
Unique user ID
Identification
Something you know (password, pin) Authentication
Something you have (card, certificate)
Something you are (fingerprint, retina) Access Controls

File permissions, ACLs

Module Code and Module Title Title of Slides
 Controlling Access to Services

“Trust is a substitute for security”

“More Security = Less Convenience”
– Hence the frequent use of Trust agreements

Trusted hosts – listed in /etc/hosts.equiv

rsh, rlogin remote shell/login for command execution
(like telnet, but not interactive)
rcp, rdist, rsync push files

• Insecure, but useful for maintenance

• Must be carefully controlled

Module Code and Module Title Title of Slides

 Firewalls

• Packet filters
– only pass certain traffic, based on any observable
characteristic of each packet.
– IP addresses, port, packet type or sequence, etc.
• Stateful firewalls
– “circuit-level” rules pertaining to connections rather
than individual packets

The firewall must be the only interconnection device

between the networks.

Module Code and Module Title Title of Slides

 Firewall
• Describes filters operating at the network and transport layers that
rely on packet headers to supply the attributes used to make access
control decisions.
– Access control decisions can be made given the subject/object
address, service, and direction of the packet.

• Simple Rule: Allow or Deny

– What is not allowed is denied
– What is not denied is allowed

• Packet Filter
– Accept or Reject packets by Source + Destination IP address
– Access Control Lists (ACLs) can be implemented in a router as
well as a separate server
Module Code and Module Title Title of Slides
 Packet Filters

DMZ Internet
Enterprise Service
Network Provider

ACLs on router and Web, File, DNS, Mail DMZ: demilitarized zone
individual servers Servers (uncontrolled access)

Internet
Service
Enterprise
Provider
Network

“Militarized”: Every access ACLs on dedicated

is examined and logged firewall or “Bastion Host”

Web, File, DNS, Mail

Servers
Module Code and Module Title Title of Slides
 Securing the Firewall

• Dedicated to single purpose

– minimal software
– minimal peripherals (even kb, screen)
– minimal accounts
• Leave no default settings

• No additional user services

• Only administrators have direct access.
• Access to the firewall is limited to directly attached consoles.
– . Administrators are trusted to perform their duties correctly.

Module Code and Module Title Title of Slides

Access Control Lists (ACLs)
Access Control Lists (ACLs) can be set up on routers and servers to
accept or deny packets from particular addresses or services.
Security policy: packet filter will either
1) Deny specific types of packets and accept all else
• requires a thorough understanding of specific security threats
• can be hard to implement
2) Accept specific types of packets and deny all else
• does not have to predict future attacks
• requires a good understanding of network requirements

Module Code and Module Title Title of Slides

 Packet Filtering: iptables
• Configure tables of packet-filter rules in Linux kernel
– Each table has a number of chains
– Each chain consists of a list of rules
– Each rule specifies what to do with a matching packet

• The default table (filter) has 3 built-in chains:

– INPUT controls traffic from outside the LAN
– OUTPUT places restrictions on outbound connections
– FORWARD allows control over routing between interfaces

Module Code and Module Title Title of Slides

 iptables - rules
IPTables uses policies (-P) to create default rules
• The following rules will block all traffic on a network gateway,
iptables -P INPUT DENY
iptables -P OUTPUT REJECT
iptables -P FORWARD REJECT
– DROP and DENY silently drop packets, REJECT returns a
connection refused error to users
• Specific rules are appended (-A) at the end of an existing ruleset.
-A is followed by the name of the chain for a rule. then Flags like
– (p)rotocol
– (i)nterface
– (s)ource (d)estination (sport) (dport)

Module Code and Module Title Title of Slides

 iptables – Rule examples

# refuse telnet connections

iptables -A INPUT -p tcp --sport telnet -j REJECT
iptables -A INPUT -p udp --sport telnet -j REJECT

# allow ssh connections

iptables -A INPUT -p tcp --sport 22 -j ACCEPT
iptables -A INPUT -p udp --sport 22 -j ACCEPT

# Allow new TCP connections from hosts in the

# 192.168.1.0/24 network to port 137 (stateful)
iptables -A INPUT -m state --state NEW -m tcp -p tcp
-s 192.168.1.0/24 --dport 137 -j ACCEPT

Rules are activated at boot time

Rules are defined in /etc/sysconfig/iptables

Module Code and Module Title Title of Slides

NSF Shares: Protecting Portmap

• Also add iptables rules to the server restricting access to specific

networks.
–This example allows connections to the portmap service (listening on port
111) from the 192.168.0/24 network and from localhost - All other packets
are dropped.
iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 111 -j DROP
iptables -A INPUT -p udp -s! 192.168.0.0/24 --dport 111 -j DROP
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT
iptables -A INPUT -p udp -s 127.0.0.1 --dport 111 -j ACCEPT

Module Code and Module Title Title of Slides

 TCP Wrapper
• In general terms, a TCP wrapped service is one that has been
compiled with the libwrap library
– These typically include sshd, sendmail, xinetd, etc.
• When a connection attempt is made the service checks if
connection is allowed based on rules in /etc/hosts.allow
and /etc/hosts.deny
– If no rules for the service are found in either file, or if neither
file exists, access to the service is granted.
• It uses the syslog daemon (syslogd) to write the name of the
requesting host and the requested service to /var/log/secure or
/var/log/messages

Module Code and Module Title Title of Slides

 TCP Wrapper - Examples

ALL : .example.com EXCEPT cracker.example.com

• If this rule appears in /etc/hosts.allow, all example.com hosts are
allowed to connect to all services except cracker.example.com
• If this rule appears in /etc/hosts.deny, only cracker.example.com has
access to all services, and other example.com hosts have access to
none
So, what is the effect of this?
ALL EXCEPT telnetd : 192.168.0.

Module Code and Module Title Title of Slides

 TCP Wrapper - Examples

• Changes to the hosts.allow and hosts.deny are dynamic: they

take effect as soon as the file is saved.
• A good starting point is to specify only the clients you want to allow to
use particular daemons and then deny everything to everybody else.
• It is good practice and a good habit to append the allow or deny
option at the end of each rule.
– this provides a clear picture on your access rules
• So, hosts.deny can simply specify
ALL:ALL
• With all specific rules in hosts.allow only.

Module Code and Module Title Title of Slides

 TCP Wrapper - Examples
For example, we can have this in hosts.allow
imapd: .apu.edu.my :allow
sshd: .apu.edu.my except cti1.apu.edu.my, cti2.apu.edu.my: deny

Using the except option, the hosts on the left hand side of the word "except"
are denied access, but the hosts in the right hand list after the word "except"
are allowed
The dot (".") before apu.edu.my is a wild card and means
all hosts ending with apu.edu.my

Note:
hostnames can be forged , so using IP addresses or the keyword ALL
when specifying hosts in hosts.allow or hosts.deny is more secure, BUT
addresses allocated using DHCP may change.

What’s the solution? (hint: take a look at the DHCP config files)

Module Code and Module Title Title of Slides

 IPtables or TCPwrap ?

TCPwrap is simpler, rules take effect

immediately, can use domain names

IPtables is faster, but rules are more

difficult to write and require restart,
limited to layers 3 and 4

No need for redundant rules

Lots of ways to divide things up

Need to use the logfiles over time to see

traffic patterns and make informed decisions

Module Code and Module Title Title of Slides

 SASL and PAM
Simple Authentication and Security Layer (SASL) is a method for
adding authentication to connection-based protocols
• used when a simple user/password authentication is not
enough
• protocols supporting SASL include: SMTP, IMAP, POP, LDAPv3
(but not v2)

Pluggable Authentication Modules (PAM) is a method for adding

authentication to applications and services
• “Plug in” different authentication methods
• Different services can have different authentication policies
Most linux distributions are “pam-aware” (compiled with the
/usr/lib/libpam.a library) – but ours is not

Module Code and Module Title Title of Slides

 SASL
• A SASL capable protocol includes configuration directives for
authenticating a client to a server and for optionally negotiating a security
layer
• Servers can be configured to negotiate and use possibly nonstandard
and/or customized mechanisms for authentication
• A challenge/response system is used to get the needed information from
the client, up to the point the authentication is either successful or fails.

Most servers support several SASL mechanisms

•PLAIN : cleartext user/password authentication
•CRAM-MD5 : IMAP/POP authentication
•DIGEST-MD5 : http Digest authentication
•GSSAPI : Kerberos authentication
•EXTERNAL : External authentication
Module Code and Module Title Title of Slides
 SASL

• Usually used for authentication of systems

• For example:
– MUA to MSA (webmail to mailserver)
– MSA to MTA (mailserver to mailserver)
– MTA to MDA (mailserver to IMAP server)
– MUA to Directory (webmail to LDAP server)

Module Code and Module Title Title of Slides

 PAM
There are four groups of PAM modules for independent management:
•Account modules check that the specified account is a valid
authentication target under current conditions. This may include conditions
like account expiration, time of day, and that the user has access to the
requested service.
•Authentication modules verify the user's identity, for example by
requesting and checking a password or other secret. They may also pass
authentication information on to other systems or modules.
•Password modules are responsible for updating passwords, and are
generally coupled to modules employed in the authentication step. They
may also be used to enforce strong passwords.
•Session modules define actions that are performed at the beginning and
end of sessions. A session starts after the user has successfully
authenticated.

Module Code and Module Title Title of Slides

 PAM
• Which authentication module is to be used depends on the local
system setup and is at the discretion of the local system
administrator.

• Modules are stacked (order is important)

Sample PAM configuration in /etc/pam.d

interface control flag module name
auth required pam_nologin.so
auth required pam_securetty.so
auth sufficient pam_unix.so
auth required pam_ldap.so

lots of modules are available

http://www.linux-pam.org/modules.html
Module Code and Module Title Title of Slides
 PAM

Standard Warning:
•You can lock yourself out of your own system if
you are not careful!

•(also applies to SELinux) (next week)

Module Code and Module Title Title of Slides

 PAM, LDAP and
Network Accounts
• Local accounts are unique to each host. Changes to an account
(e.g., new password) on one host do not affect similar accounts on
other hosts
• A networked account is a single user identity shared by many hosts.
Changes to the account globally affect all other hosts
• PAM is required to use a LDAP server to provide user information
rather than the local database of users (/etc/passwd)

Module Code and Module Title Title of Slides

 Scenario

ssh to server, network account

•Caught by iptables, source & destination allowed <or>
Caught by tcpwrap, host & service allowed (redundant?)
•Caught by PAM, request passed to LDAP client application
•LDAP client contacts LDAP server
•LDAP server requires SASL authentication before bind
•Authentication successful, LDAP server returns username and
(encrypted) password
•LDAP client passes these back to PAM
•Next PAM module verifies credentials
•ssh connection is allowed (whew!)

Module Code and Module Title Title of Slides

 TinyNet

• We will do an iptables exercise

• TCPwrap is available
• Postfix configuration files are partially ready for
SASL, can also use with dovecot and openLDAP
• PAM is not available – it is something to know
about though (same for SELinux, next week)

Module Code and Module Title Title of Slides

 TinyNet

• firehol-1.273
• An easy to use but powerful iptables stateful firewall. The default
configuration file will allow only client traffic on all interfaces.

• shorewall-4.4.7.5
• Shorewall is an open source firewall tool for Linux that makes it
easier to manage more complex configuration schemes by working
with "zones", such as the DMZ or a 'net' zone. Each zone would
then have different rules, making it easy to have for example
relaxed rules on the company intranet, yet clamp down on traffic
coming in from the internet.

Module Code and Module Title Title of Slides

 TinyNet

• Firehol and ShoreWall will also install the iproute2 package.

• iproute2 (IP routing utilities) tools are used to administer many

advanced IP routing features in the kernel. You should not need to
go too far into this, unless you really want to ...
Home:
http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2

• Note: Route NAT is not supported in Linux 2.6.

Module Code and Module Title Title of Slides

 References

• security guide pdf

– p.46 securing portmap
– p.49 securing nfs
– p.50 securing web
– p.54 sendmail (!!!)
– p.55 nmap
– p.65, 75-77, 97- firewalls

Module Code and Module Title Title of Slides

Module Code and Module Title Title of Slides