Linux Administrator - Linux Network Administration II

Welcome to:
Linux Network Administration II:

Network Security and Firewalls
(Course code LX24)
Copyright IBM Corporation 2004

3.1
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Welcome to:
Unit 1:
Introduction to Network Security and
Firewalls

3.1
Unit Objectives
Describe the purpose of a Security Policy
Identify the role of a Firewall in a Security Policy
Describe different types of Firewalls
Describe different types of Attacks

Security Policy
Document describing the way computer equipment may/may not be
used
Preventing unauthorized use of computer equipment
Ensuring uninterrupted service to legitimate users
Should be decided by management
Should be implemented and enforced by hardware/software setup
Different aspects:
Physical security
Network security
Authentication
Authorization
Evolves over time

Physical Security
Ensure that nobody can access computer hardware
Locks on doors
Access codes
Signing-in of staff
Physical protection of cabling
Physical environment
Uninterruptible Power Supply (UPS)
Fire suppression system
Air Conditioning (heat, moisture)
Physical breakdown of computer hardware
Spare components
Backups (consider off-site storage)

Network Security
Ensure that no unauthorized user can access the system over the
network
Internet
Modem
other WAN
LAN
Needs to be done for every networked system

Authentication and Authorization
Authentication: Establishing who you are
Username/Password
Public key cryptography
Smartcards
Biometrics
Authorization: Determining what you may do
Usually dependent on group membership

Hackers, Crackers and Script Kiddies
A hacker is someone who wants to satisfy his curiosity
Means no harm
May cause harm accidentally
A cracker is someone who wants to gain something
Access to your system to use resources
Access to data (for example, credit card numbers)
Publicity
Revenge
A Script Kiddie is someone who uses hackers tools without
understanding what they do
To a firewall administrator, there is no difference
All can cause harm
From the type of activity you cannot distinguish them

Motivation of Hackers and Crackers
Curiosity
Challenge
Prestige
Corporate, political espionage
Confidential information, intellectual property
Proprietary software
Access to resources
Disk space
CPU time
Monetary
Credit card numbers
Base of operation for attacks on other sites
DDoS
Untraceable junk mail

Types of Attack (1 of 2)
Scanning
Which services are enabled
Which software and version is used
Sniffing
Monitoring data (for example, passwords) in transit
Break-in
Gain access to a computer, preferably as superuser
Brute Force
Try every possible combination until one works
Man-in-the-Middle
Act as the server to a client
Act as a client to the server

Types of Attack (2 of 2)
Virus
Malicious program that attaches itself to other programs
A macro virus resides in a macro which is typically stored in a
data file
Worm
Self-replicating malicious program
Trojan Horse
Apparently useful program with a malicious component
Denial of Service (DoS)
Prevent legitimate users from working
Usually done by crashing or overloading the system or network
Distributed Denial of Service (DDoS)
DoS attack from many different sources simultaneously

What You Have to Lose
Loss of resources
Disk space
Bandwidth
CPU time
Loss or alteration of data
Loss or impairment of service
Loss of reputation, goodwill, trust
Disclosure of personal, proprietary or confidential information
Financial loss
Stolen credit card numbers
Legal, criminal action against you

Forms of Protection
No Internet connection
Safe but users will set up their own access
Choke point (firewall)
One device where all traffic passes through
Can log activity
Can limit activity
Needs careful setup
No central protection
Requires protection on every host
Gives virtually unlimited Internet access

What is a Firewall?
It is not a single device
It is not a proxy, socks or filter
It is a combination of components which implements and
enforces the security policy
Filtering Router
DMZ (DeMilitarized Zone) or screened subnet
Network Address Translation or IP Masquerading
Socks Server
Proxy Server
Mail Gateway
DNS Server
Tunneling Device
Always customized to local environment and needs

Position of a Firewall
Firewall
Filtering Router
DMZ/Screened Subnet
NAT/IP Masquerading
Socks Server The Internet
Proxy Server
Mail Gateway
DNS Server
Tunneling Device
Company Network

DMZ and Packet Filters
Traffic is only allowed from a host on the Company

Network to a host on the DMZ, and from a host on
the DMZ to a host on the Internet
(Filtering based on IP address)
Packet
The Internet
DMZ X
Filtering
Router
X

Packet
Filtering
Packet
Router
Filtering
Router DMZ
X
Company Network Company Network

NAT, Socks and Proxies
NAT Web
Socks Server
Proxy
Packet The Internet

Filtering
DMZ Router
Packet
Filtering
Router
A NAT, Socks or Proxy
accepts a client connection,
Client verifies it and sets up a
second connection to the
Internet to retrieve the data
Company Network

E-mail
Packet The Internet

Filtering
DMZ Router
Mail
Packet
Gateway
Filtering All e-mail to and from the
Router Internet should pass through
the Mail Gateway.
Mail All connections through the
Client
Server SMTP it are SMTP connections.
Filtering based on IP address
POP/IMAP
and port number (SMTP=25).
Company Network
POP and IMAP are only used
on the Company Network.

Domain Name System
DNS Packet The Internet

Server Filtering
DMZ Router
Packet The DNS server in the DMZ

Filtering
resolves queries on the DMZ
Router
and on the Internet.
The internal DNS resolves
queries for the Company
Network, and forwards all
other queries to the DNS
Company Network server on the DMZ.
DNS
Server Filtering based on IP address
and port number (DNS=53)

The Company Web Servers
Company
Web
Server
Packet The Internet

Filtering
DMZ Router
Packet
Filtering An internal client can
Router
access both the Intranet
server and the Internet
server. An external client
Client
can only access the
Internet Server.
Intranet
Company Network Filtering based on IP address
Server and port number (HTTP=80)

Virtual Private Networking
With VPN, traffic between one network

and another is sent encrypted over
the Internet, creating one Virtual Network
Packet The Internet
Filtering
DMZ Router
Packet Tunneling
Filtering Device
Router Firewall
with
Client
Tunneling
Company Network Customer Network

Intranet
Server

The Complete Picture
Firewall
NAT Company Web
Socks Web Server
Proxy Server
DNS Packet The Internet

Server Filtering
DMZ Router
Mail
Gateway Packet Tunneling
Filtering Device
Router Firewall
with
Client
Tunneling
Mail
Server Client
Intranet Company Network Customer Network

DNS
Server Server

What a Firewall Does Not Protect Against
Misuse of allowed connections
Malicious users (employees, contractors) behind the firewall
Data in transit on the Internet
Connections that bypass the firewall
Modem connections
Software/Data brought in/out on physical media
Connections to systems outside the firewall
Company Web server
Physical theft, break-in attempts, bribery, fire, ...

Network Security Techniques Usage
Technique Intranet Server Internet Server Firewall

Physical security yes yes yes
Packet Filtering maybe yes yes
Encrypted maybe yes yes
communications
NAT N/A N/A yes
Socks N/A N/A yes
Proxies N/A N/A yes
Individual service maybe yes yes if fw runs
security services
Split DNS N/A N/A yes
Virus scanning maybe yes yes
VPN solutions N/A N/A maybe
Hackers' tools maybe yes yes
IDS tools maybe yes yes

Checkpoint Questions
1. What is the difference between a Hacker and a Cracker?
2. Does it really matter?
3. What is a firewall?
4. What components can a firewall have?
5. Against what does a firewall offer no protection?

Unit Summary
Various people on the Internet may try to access your systems
A common way of protecting is a firewall
A firewall consists of a number of components: DMZ, filtering
routers, NAT, Socks, Proxies, VPN.
A firewall cannot protect you from everything

Welcome to:
Unit 2:
Installing and Securing Linux

3.1
Unit Objectives
Install Linux
Apply Patches
Hardening Linux

Installing Linux
Install Linux in the normal fashion
Create separate partitions for /, /boot, /var, /home, /usr, /usr/local,
/tmp, swap
Install as few services as possible
Every service is a potential vulnerability...
Set a good root password (one you didn't use before)

Apply Patches
Download all available patches for your distribution and install them
fedora# yum update
redhat# up2date -u
suse# you
Do not install patches from untrusted sources
Verify MD5 and GPG checksum of all patches
fedora/redhat# rpm --import /mnt/cdrom/RPM-GPG-KEY
suse# gpg --import /media/cdrom/pubring.gpg
rpm -K <package>

Kernel Recompile
Might want to recompile the kernel
Disable support for not available hardware
Optimize for processor
Optimize as router, not host
Disable support for loadable modules
What if a hacker was able to load a custom module?
Add security features that did not (yet) make it to the mainstream
kernel
Add security features not allowed in mainstream kernel
Might need to recompile the kernel
Security problems
Add support for special hardware

Hardening Linux
BIOS Considerations
Boot Loader password
User account considerations
Disable unneeded services
Disable Ctrl-Alt-Del
Change /etc/issue and /etc/issue.net
Change /etc/motd
Set $TMOUT
Recompile kernel
Harden filesystem

BIOS Considerations
Allow boot from hard disk only
If supported: enable BIOS virus protection
Disable APM
Set BIOS Password
Note: BIOS passwords can be cracked
By shorting the CMOS battery
By using a BIOS crack program
Note: Please don't do this in this class...

Boot Loader Password
LILO and GRUB both allow you to set a password
Regular boot possible without password
Non-regular boots (for example, single user mode) requires
password to be entered
LILO: Add "password" and "restricted" line to /etc/lilo.conf
GRUB: Add "password" to /boot/grub/menu.lst
Can be encrypted - use grub to encrypt
# vi /etc/lilo.conf # grub
boot=/dev/hda grub> md5crypt
map=/boot/map Password: secret
install=/boot/boot.b Encrypted: $1$24QV1/$ecUahVmWxCDBU3k5Mzmjy/
prompt grub> quit
timeout=50
default=linux # vi /boot/grub/menu.lst
password=secret default=0
restricted timeout=10
... password=$1$24QV1/$ecUahVmWxCDBU3k5Mzmjy/
# chmod 600 /etc/lilo.conf ...
# lilo # chmod 600 /boot/grub/menu.lst
User Account Considerations
Every user account is a potential security problem!
Use as few accounts as possible
Consider deleting all default user accounts (bin, ...)
Disable/delete unused accounts as soon as possible
Two approaches
No user accounts on firewall, login as root directly
User account for each administrator, su to root
Consider changing "root" to something else

Disable Services
Services can be started directly or through xinetd
Direct services:
Usually started with startup script in /etc/rc.d/init.d
Contents of /etc/rc.d/rc<runlevel>.d determines which services are
started in that runlevel
To disable: chkconfig <service> off
Services started through xinetd:
Disable in /etc/xinetd.conf or /etc/xinetd.d/service
Can also be done with chkconfig
service xinetd restart / rcxinetd restart
To verify which services are running:
ps aux (displays all processes)
netstat -a (displays all open ports)

Filesystem Hardening
Mount filesystems with following options, where possible:
noexec: Do not allow execution of programs
nosuid: Do not allow suid/sgid bits to take effect
nodev: Do not allow access to devices
ro: Mount read-only
If for instance read-write access is needed, remount:
mount -o remount,rw /usr
Example /etc/fstab:
/dev/hda1 /boot ext2 defaults,noexec,nosuid,nodev 2 2
/dev/hda5 / ext2 defaults 1 1
/dev/hda6 /usr ext2 defaults,ro,nodev 2 2
/dev/hda11 /usr/local ext2 defaults,ro,nodev 2 2
/dev/hda7 /tmp ext2 defaults,nosuid,nodev 2 2
/dev/hda8 /home ext2 defaults,nosuid,nodev 2 2
/dev/hda9 /var ext2 defaults,noexec,nosuid,nodev 2 2
/dev/hda10 swap swap defaults 0 0
/dev/hdc /mnt/cdrom iso9660 noauto,owner,nosuid,noexec,nodev 0 0
/dev/fd0 /mnt/floppy auto noauto,owner,nosuid,noexec,nodev 0 0

Disable Ctrl-Alt-Del
If people have access to the console, you might want to disable
Ctrl-Alt-Del
Comment out corresponding line in /etc/inittab
vi /etc/inittab
kill -HUP 1
Disadvantage: If a reboot is necessary for some external reason,
people have no option but to switch off the system without a proper
reboot

/etc/issue, /etc/issue.net
Remove all information that may give a hacker useful information
Add usage policy
Note: Some distributions overwrite /etc/issue and /etc/issue.net at
reboot!
# cat /etc/issue
This system is for authorized users only. If you are not an

authorized user, disconnect now.

/etc/motd
Can be used to state usage policy of the system
# cat /etc/motd
************************** NOTICE *******************************
* *
* This computer system is for authorized users only. If you *
* are not an authorized user, you may face administrative *
* disciplinary action and civil and/or criminal penalties. *
* *
* Usage of this system is monitored for security reasons. All *
* your actions are logged and can be used against you. On this *
* system, your privacy is NOT guaranteed. *
* *
* By continuing to use this system you indicate your awareness *
* of and consent to the terms above. LOG OFF IMMEDIATELY if you *
* do not agree to the conditions stated in this notice. *
* *
*****************************************************************

$TMOUT Shell Variable
Shell variable that specifies the idle timeout (in seconds)
If reached, user is logged out automatically
For system-wide timeout, add to /etc/profile:
For per-user timeout, add to $HOME/.bash_profile:
export TMOUT=3600

1. Name some considerations when installing Linux on a firewall.
2. What steps do you take to harden your system?

Unit Summary
Installing Linux
Hardening Linux

Welcome to:
Unit 3:
The TCP/IP Protocol Suite

3.1
Unit Objectives
Discuss the IP protocols and IP addressing
Describe content of IP, TCP, UPD and ICMP packets
Trace TCP/IP traffic with tcpdump
Change TCP/IP kernel options

TCP/IP Layering
TCP/IP Applications
TCP UDP
ICMP
IP
Network Interface

IP Protocol
Internet Protocol
Defined in RFC 791, 950, 919, 922 and 1349
Main protocol to forward data to destination host
Uses "datagrams" (packets) to send data
Source and destination are identified with an IP address
Connectionless, unreliable service
Hop-by-hop forwarding in "routers"

IP Addressing
Every interface needs a unique IP address
IP addresses are 32 bit
Usually written in "dot-quad" notation: 9.132.123.133
binary: 00001001 10000100 01111011 10000101

8+1 128+4 64+32+16+8+2+1 128+4+1
dot-quad: 9 . 132 . 123 . 133

IP Address Assignment
IP addresses assigned by IANA
Internet Addressing and Naming Agency
http://www.iana.net
5 "classes":
A: 8 bits assigned, 24 free
B: 16 bits assigned, 16 free
C: 24 bits assigned, 8 free
D: multicast - assigned individually by IANA
E: experimental - not used any more
Reserved classes for private networks:
A: 10.0.0.0
B: 172.16.0.0 through 172.31.0.0
C: 192.168.0.0 through 192.168.255.0
Other special:
Class A 127.0.0.0 used for loopback interface

IANA Address Assignment
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A |0 IANA | SELF | SELF | SELF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B |1 0 IANA | IANA | SELF | SELF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C |1 1 0 IANA | IANA | IANA | SELF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D |1 1 1 0 IANA | IANA | IANA | IANA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E |1 1 1 1 NOT | IN | USE | ANYMORE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class A: 2^7=128 networks of 2^24=16M addresses

Class B: 2^14=16K networks of 2^16=64K addresses
Class C: 2^21=2M networks of 2^8=256 addresses
Class D: 2^28=256M multicast addresses

IP Address Usage
Example: Use private address 10.0.0.0 to create 64 K networks of
256 hosts each
First 8 bits are fixed: 00001010 (number 10)
Next 16 bits identify the network (2^16=64K)
Last 8 bits identify the host in the network (2^8=256)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1 0| Network Identifier | Host ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Use "subnetmask" 255.255.255.0 to identify what

part is network ID and what part is host ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
255 . 255 . 255 . 0

IP Packet Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VERS | HLEN | Service type | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | FLG | Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to live | Protocol | Header checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional: IP Options |
. +-+-+-+-+-+-+-+-+-+-+-+
. | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP data |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Important IP Header Fields
Total length: Might be used to force fragmentation or buffer
overflows
ID, FLG and Fragment Offset: Might be used in DoS attacks since
fragments need to be buffered
Source IP Address: might be forged ("spoofed")
To prevent tracing back an attack
To masquerade as a trusted host
Destination IP Address: might be an address behind the firewall to
discover firewall capabilities
IP Options: Source Routing might be used to bypass routing
algorithms

The ICMP Protocol
Internet Control Message Protocol
Defined in RFC 792 and 950
Used to report network errors back to sender
Except errors from ICMP itself
Used to discover information about another host
Uses IP for packet forwarding

ICMP Packet Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | CODE | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICMP Data (depending on type) |
| |
. .
. +-+-+-+-+-+-+-+-+-+-+-+
. | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Important ICMP Message Types
Echo request (8)/Echo reply (0): Test whether a host is active
Used in smurf attacks with a spoofed source address to flood a
target
Destination unreachable (3):
From a router: Don't know the route to the target
Can be used to obtain information about the firewall
From a host: Protocol or port not enabled
Used in port scans to verify that a port is not active
Source Quench (4): Packets arriving too fast - slow down
Can be used for DoS attacks
Redirect (5): Use another router to route these packets
Can be used to redirect traffic over another route so that it can be
sniffed

UDP Protocol
User Datagram Protocol
Defined in RFC 768
Uses IP to send data
Uses port numbers (16 bits) to identify the service
Connectionless, unreliable service

UDP Packet Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP data |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Important UDP Header Fields
Source Port: Port where packet originates from
Can be spoofed to simulate a "secure" port (<1024)
Can be spoofed to simulate a well-known service
Destination Port: Port where packet goes to
Used to select the target service
UDP does not support "pacing": The sender can send as many
packets per second as his network connection allows
Can be used in DDoS attacks to overload the network

TCP Protocol
Transmission Control Protocol
Defined in RFC 793
Uses IP to send data
Uses source and destination ports to select service
Reliable, connection-oriented service

TCP Packet Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Data | |U|A|P|R|S|F| |
|Off- | Reserved |R|C|S|S|Y|I| Window |
| set | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options |
. +-+-+-+-+-+-+-+-+-+-+-+-+-+
. | Padding .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Data |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TCP Connection Setup
First packet:
SYN bit set, Sequence number a
(a should be random)
Second packet:
Initiator ACK bit set, Acknowledgment number a+1 Server
SYN bit set, Sequence number b
(b should be random)
Third packet:
ACK bit set, Acknowledgment number b+1
May contain data

Important TCP Header Fields
Source Port: Port where packet originates from
Can be spoofed to simulate a "secure" port (<1024)
Can be spoofed to simulate a well-known service
Destination Port: Port where packet goes to
Used to select the target service
Sequence number: Which packet this is in the stream
Needs to be in window range
URG: Urgent data
Certain applications are known to crash on receiving this
SYN: Used in SYN attacks where a 1st SYN packet is sent but the
connection is not set up further
Fills up the connection table (DoS)
SYN cookies prevent this

Tracing Network Traffic
Done with "sniffers"
tcpdump default sniffer in UNIX
Syntax: tcpdump [options] [expression]
Important options:
-i <interface>: Listen on <interface>
-p: Put interface in promiscuous mode
-l: Make output buffered (useful when viewing real-time)
-n: Don't translate IP addresses to hostnames
-s <number>: Show <number> bytes of packet
-x: Print whole packet in hexadecimal
Important expressions:
host <hostname or IP address>
ether <MAC address>
port <portnumber>
tcp
udp
Tcpdump Examples
[root@sys1 /root]# tcpdump -i eth0 -l -n
Kernel filter, protocol ALL, datagram packet socket
tcpdump: listening on eth0
16:21:08.341008 > 10.0.0.1 > 10.0.0.6: icmp: echo request
16:21:08.341554 < 10.0.0.6 > 10.0.0.1: icmp: echo reply
^C
2 packets received by filter
[root@sys1 /root]# tcpdump -i eth0 -l -n -x

Kernel filter, protocol ALL, datagram packet socket
tcpdump: listening on eth0
4500 0054 0172 0000 4001 6531 0a00 0001
0a00 0006 0800 ec0a e704 0000 14d8 f538
2adc 0500 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
16:22:12.384664 < 10.0.0.6 > 10.0.0.1: icmp: echo reply
4500 0054 0020 0000 ff01 a782 0a00 0006
0a00 0001 0000 f40a e704 0000 14d8 f538
2adc 0500 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
^C
2 packets received by filter

Understanding tcpdump Output
Hexadecimal Binary Meaning

---- ---- -------- -------- -------- -------- ---------------------------------
4500 0054 01000101 00000000 00000000 01010100 VERS=4, HLEN=5, Service=00,
Total length=0054(hex)
0172 0000 00000001 01110010 00000000 00000000 ID=0172, FLG=0, FO=0
4001 6531 01000000 00000001 01100101 00110001 TTL=40(hex), Protocol=01 (ICMP),
Checksum=6531
0a00 0001 00001010 00000000 00000000 00000001 Source IP addr=0a000001 (10.0.0.1)
0a00 0006 00001010 00000000 00000000 00000110 Dest IP addr=0a000006 (10.0.0.6)
0800 ec0a 00001000 00000000 11101100 00001010 ICMP type=08 (echo request), code=0,
Checksum=ec0a
e704 0000 11100111 00000100 00000000 00000000 ICMP echo request specific data
14d8 f538 00010100 10111000 11110101 00111000
2adc 0500 00101010 11011100 00000110 00000000
0809 0a0b 00001000 00001001 00001010 00001011 ICMP default pattern
0c0d 0e0f 00001100 00001101 00001110 00001111
1011 1213 00010000 00010001 00010010 00010011
1415 1617 00010100 00010101 00010110 00010111
... ...

Kernel Configuration Options
Default options set at compile time
Can be changed in virtual /proc filesystem
echo 1 > /proc/sys/net/ipv4/ip_forward
Should be configured before networking is started
Settings in /etc/sysctl.conf
net.ipv4.ip_forward = 1
Red Hat: Activated by /etc/rc.d/rc.sysinit
SuSE: Activated by /etc/init.d/boot.sysctl
Note: conflicts with /etc/init.d/boot.ipconfig
Extensive documentation in /usr/src/linux/Documentation/proc.txt

Kernel Configuration Options (ICMP)
Ignore ICMP echo requests to broadcast address:
net.ipv4.icmp_echo_ignore_broadcasts = 1
Limits on sending ICMP packets (in # per 1/100s)

net.ipv4.icmp_ratelimit = 100
net.ipv4.icmp_ratemask = <mask>
icmp_ratemask determines to which ICMP packets icmp_ratelimit applies -
see /usr/src/linux/Documentation/networking/ip-sysctl.txt for details

Kernel Configuration Options (IP)
Default TTL
net.ipv4.ip_default_ttl = 255
Local port range for TCP and UDP connections

net.ipv4.ip_local_port_range = 1024 32000
No Path MTU Discovery

net.ipv4.ip_no_pmtu_disc = 1
IP fragmentation memory thresholds and timeouts:

net.ipv4.ipfrag_high_thresh = 262144
net.ipv4.ipfrag_low_thresh = 196608
net.ipv4.ipfrag_time = 30

Kernel Configuration Options (TCP)
Detect broken connections early:
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_time = 600
Protection against SYN attacks:

net.ipv4.tcp_syncookies = 1
Protect against unfinished connections:

net.ipv4.tcp_retries1 = 3
Protection against FIN attacks:

net.ipv4.tcp_fin_timeout = 30

Kernel Configuration Options (Interface)
Interface specific options are in
/proc/sys/net/ipv4/conf/<interface-name>
Changes to the "default" interface apply to all interfaces that will be
configured later
Changes to the "all" interface apply to all interfaces that are already
configured
Do not accept/send ICMP redirects
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.send_redirects = 0
Do not accept source-routed packages
net.ipv4.conf.default.accept_source_route = 0
Log packets with source address with no known route
net.ipv4.conf.default.log_martians = 1
Source address validation:
net.ipv4.conf.default.rp_filter = 1

1. What are the core protocols in the TCP/IP protocol suite?
2. Name at least two important fields in every one of the four
protocols discussed.

Unit Summary
The TCP/IP Protocol Suite consists of four major protocols: IP,
ICMP, UDP and TCP
IP forwards data to the destination host
ICMP reports on errors, using IP
UDP offers connectionless, unreliable data transport to applications,
using IP
TCP offers connection-oriented, reliable data transport to
applications, using IP
tcpdump can be used to trace all data packets on a network
Various kernel options for TCP/IP can be changed in the
/proc/sys/net/ipv4 hierarchy

Welcome to:
Unit 4:
Packet Filtering and Network Address
Translation

3.1
Unit Objectives
Describe Packet Filtering concepts
Describe Network Address Translation concepts
Use iptables to implement Packet Filtering and Network Address
Translation
Save and restore iptables rules

Packet Filtering
Packet Filtering: Filtering IP packets based on
Network Interface
Protocol (UDP, TCP, ICMP, ...)
Source and/or Destination IP address
Source and/or Destination TCP or UDP Port
Direction of TCP Connection Setup
Existence of TCP connection
ICMP Packet Type
MAC address
User ID of sending/receiving process
Possible actions:
Accept: Allow packet
Drop: Don't allow packet
A "rule" is a statement which combines a set of criteria with an
action to perform

Network Address Translation
Changing Source and/or Destination IP address and/or Port of
packets in transit
Source NAT (SNAT): Change source IP address
IP Masquerading
Destination NAT (DNAT): Change destination IP address
Port Forwarding
Transparent Proxying
Packet Mangling: Change TCP/IP options
Priority
TTL

Chains (1 of 2)
A "chain" is a series of rules that are checked for a certain type of
packet
Default chains:
INPUT: For packets send to this host
OUTPUT: For packets send from this host
FORWARD: For packets send through this host
PREROUTING: For DNAT
POSTROUTING: For SNAT
A user can add his own chains
A rule in a default chain then refers to this chain
Rules in a chain are checked in order
When a rule does not match, check next
When a rule matches, execute the action
Accept, Drop or go to user-defined chain

Chains (2 of 2)
Incoming Packets
Sanity Check
PREROUTING
y Destination n
= local?
ip_forward n
INPUT on?
y
Local Process FORWARD
OUTPUT Discard
packet
POSTROUTING
Outgoing Packets
Packet Filtering in Linux
Packet Filtering done at kernel level
Usually compiled as kernel modules which are loaded
automatically
Configuration done with user space tools
Linux 2.0 kernel: ipfwadm
Linux 2.2 kernel: ipchains
Linux 2.4 kernel: iptables
Downwards compatibility ensured
Additional features:
Logging
Statistics

The iptables Tool
User level tool for configuring kernel filter rules
Different modes of operation:
Flush all rules
Set default action for a chain
Append, Insert, Replace, Delete rules
Display rules
Display, reset statistics
Check packet against a chain
iptables-save and iptables-restore can be used to save and
restore all rules to/from a file

iptables Basic Syntax (1 of 2)
iptables [-t table] command [chain] [parameters] [-j target]
Tables:
filter (default): For filtering rules
nat: For NAT rules
mangle: For packet mangling rules
Simple commands:
-L: List all rules
-F: Flush all rules
-Z: Zero all counters
-A: Append a rule
-I: Insert a rule
-P: Default action for this chain
-N: Create user defined chain
-X: Delete user defined chain

iptables Basic Syntax (2 of 2)
iptables [-t table] command [chain] [parameters] [-j target]
Simple parameters:
-i incoming interface
-o outgoing interface
-p protocol
-s source-IP
--sport source-port
-d destination-IP
--dport destination-port
--icmp-type type
Use ! to negate options
Targets:
Basic: ACCEPT, DROP
Extended (require kernel module): REJECT, LOG, ...

Scenario
The Internet
ppp0: 62.186.134.70
Firewall
in-a-box
eth0: 10.0.0.1
Company Network
10.0.0.0/24

iptables Initial Setup
Delete all user-defined chains
Flush all rules
Set default policy for each chain
Enable all traffic over the loopback and Ethernet interface
Deny all traffic not destined for or originating from the external
interfaces IP address
# iptables -X
# iptables -F
# iptables -P INPUT DROP
# iptables -P OUTPUT DROP
# iptables -P FORWARD DROP
# iptables -A INPUT -i lo -j ACCEPT
# iptables -A OUTPUT -o lo -j ACCEPT
# iptables -A INPUT -i eth0 -j ACCEPT
# iptables -A OUTPUT -o eth0 -j ACCEPT
# iptables -A INPUT -i ppp0 -d ! 62.186.134.70 -j DROP
# iptables -A OUTPUT -o ppp0 -s ! 62.186.134.70 -j DROP

Protect Against Spoofed Addresses
Don't accept or send packets on the external interface claiming to
be coming from and/or going to
The internal network
Yourself
Any reserved IP address
The loopback interface
Universal broadcast addresses
# iptables -A INPUT -i ppp0 -s 10.0.0.0/8 -j DROP

# iptables -A OUTPUT -o ppp0 -d 10.0.0.0/8 -j DROP
# iptables -A INPUT -i ppp0 -s 0.0.0.0 -j DROP
# iptables -A OUTPUT -o ppp0 -d 255.255.255.255 -j DROP

Configure ICMP Echo Request/Reply Filtering
Allow ICMP Echo Request/Reply (type 8/0)
Can be used in smurf DoS attacks though
Sending echo requests to a broadcast address with spoofed
source address floods a server with replies
So only accept Echo Requests for your IP address
# iptables -A OUTPUT -o ppp0 -p icmp -s 62.186.134.70 -d 0.0.0.0/0 --icmp-type 8 -j ACCEPT

# iptables -A INPUT -i ppp0 -p icmp -s 0.0.0.0/0 -d 62.186.134.70 --icmp-type 0 -j ACCEPT


Configure Other ICMP Filtering
Allow the following ICMP packets:
Destination Unreachable (type 3)
Source Quench (type 4)
Time exceeded (type 11)
Parameter Problem (type 12)





Configure Outgoing TCP/UDP Connections
Allow outgoing TCP and UDP connections
Source port > 1023, destination port <= 1023
# iptables -A OUTPUT -o ppp0 -p tcp -s 62.186.134.70 --sport 1024: -d any/0 \

--dport :1023 -j ACCEPT
# iptables -A INPUT -i ppp0 -p tcp -s any/0 --sport :1023 -d 62.186.134.70\
--dport 1024: -j ACCEPT
# iptables -A OUTPUT -o ppp0 -p udp -s 62.186.134.70 --sport 1024: -d any/0 \

# iptables -A INPUT -i ppp0 -p udp -s any/0 --sport :1023 -d 62.186.134.70\

Identd Considerations
The IDENTD protocol (RFC 1413) identifies the owner of a
connection
Used for FTP
Required for IRC
Uses TCP port 113
Incoming connections should not be denied but rejected
Otherwise: long timeouts on the client
Disadvantage: Hackers may use this instead of ping to determine if
a host is alive
# iptables -A INPUT -i ppp0 -p tcp -s 0.0.0.0/0 -d 62.186.134.70 --dport 113 -j REJECT
1025 ftp logon request 21

ftp client
113 who is on port 1025? ftp
identd tux is on port 1025 daemon
welcome, tux

iptables Statistics
For every rule configured, a counter counts the number of matches
for that rule
To retrieve counters, use iptables -v -L [chain]
Use -x option to print full numbers instead of K, M or G
To reset counters, use iptables -Z [chain]

iptables Logging
Arbitrary packets can be logged to syslogd with "LOG" target
(requires ipt_LOG kernel module)
Use --log-level to specify log level (default DEBUG)
Use --log-prefix to specify prefix
Facility is always KERN
To limit the amount of logging, use -m limit extension (requires
ipt_limit kernel module)
Use --limit to specify maximum average
Use --limit-burst to specify maximum initial number
LOG rules are nondeterministic: can be inserted anywhere in a
chain without affecting the workings of the chain
# iptables -I INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-level DEBUG\

--log-prefix "Incoming IP packet:"

IP Masquerading
Only done on a router
Replaces the source IP address with the router IP address on
outgoing packets
Keeps track of connections for de-masquerading
Also works for UDP and ICMP
10.0.0.2:1287 -> 134.191.38.72:80 62.186.134.70:4011 -> 134.191.38.72:80

Router
Client 134.191.38.72:80 -> 10.0.0.2:1287 with 134.191.38.72:80 -> 62.186.134.70:4011 Server
IP Masq.
10.0.0.2 10.0.0.1 134.191.38.72

62.186.134.70
Intranet Internet

Configuring IP Masquerading
Done with iptables in "POSTROUTING" chain
Target MASQUERADE used for dynamic IP addresses:
Connections dropped when interface is down
Target SNAT used for static IP addresses: Connections persist
when interface down; requires specification of source address
Need to allow this traffic in FORWARD chain
IP Forwarding needs to be enabled
# iptables -t nat -A POSTROUTING -o ppp0 -p tcp -s 10.0.0.0/24 --sport 1024: -d ! 10.0.0.0/24\

--dport :1023 -j SNAT --to-source 62.186.134.70
- OR -
# iptables -t nat -A POSTROUTING -o ppp0 -p tcp -s 10.0.0.0/24 --sport 1024: -d ! 10.0.0.0/24\
--dport :1023 -j MASQUERADE
# iptables -A FORWARD -i eth0 -o ppp0 -p tcp -s 10.0.0.0/24 --sport 1024: -d ! 10.0.0.0/24\

# iptables -A FORWARD -i ppp0 -o eth0 -p tcp -s ! 10.0.0.0/24 --sport :1023 -d 10.0.0.0/24\
# echo 1 > /proc/sys/net/ipv4/ip_forward

Configuring NAT for Difficult Situations
NAT support in Linux is extensible by loading kernel modules
For regular FTP support (with server initiated data conn.)
modprobe ip_conntrack_ftp ip_nat_ftp
For IRC support
modprobe ip_conntrack_irc ip_nat_ftp
And more...
Make permanent by adding this to /etc/rc.local, /etc/modules.conf or
/etc/modprobe.conf

Saving and Restoring iptables Rules
# /sbin/iptables-save > iptables.rules
# chmod 600 /etc/iptables.rules
# cat /etc/iptables.rules
*mangle
:INPUT DROP
...
COMMIT
*nat
:PREROUTING ACCEPT
:POSTROUTING ACCEPT
-A PREROUTING -s ...
COMMIT
*filter
:INPUT DROP
:FORWARD DROP
:OUTPUT DROP
-A FORWARD -s...
COMMIT
# iptables -F
# iptables -X
# /sbin/iptables-restore < iptables.rules

Restoring iptables Rules on Startup (Fed/RH)
Fedora and Red Hat come with an iptables startup script
/etc/rc.d/init.d/iptables
Supports various options:
start: Restore rules from /etc/sysconfig/iptables
stop: Flush rules, delete user-defined chains
restart: Same as stop/start
save: Save current rules in /etc/sysconfig/iptables
panic: Flush all rules, set all defaults to DROP
status: Executes iptables -nL
Integrated in boot process before networking is started
chkconfig iptables on

SuSEfirewall2
SuSE comes with an elaborate firewall setup:
yast: Configure internal/external interface and services offered -
stored in /etc/sysconfig/SuSEfirewall2
rcSuSEfirewall2: Script that activates about 200 iptables rules to
protect system properly, based on /etc/sysconfig/SuSEfirewall2
information
If you don't want to use SuSEfirewall2, need to make your own
startup scripts, for example, using iptables-restore

FWBuilder
GUI frontend that allows for easy creation/management of firewall
rules
Supports other firewall rule types as well: ipfilter, OpenBSD PF
and Cisco PIX
http://www.fwbuilder.org

Other iptables Features
Transparent proxying
A packet that needs to be routed is sent to the local system (for
example, proxy) instead (DNAT)
Port forwarding
A packet that is sent to a local port is masqueraded and sent to
another server instead (DNAT)
Useful if you have an Internet Web server inside the firewall
Stateful TCP inspection
Only allows TCP packets through that belong to an existing
connection
Requires ipt_state kernel module
Packet mangling
Change IP and TCP options on packets in transit

1. What criteria can be used in packet filtering?
2. How is packet filtering implemented in Linux?
3. What is a chain?
4. What is a rule?
5. What is Network Address Translation?

Unit Summary
Packet Filtering and Network Address Translation is integrated in
the Linux Kernel
The user administration tool depends on the kernel level: ipfwadm,
ipchains or iptables
Netfilter uses five default "chains", each containing rules which are
applied to packets
A rule can specify different things to do with a packet: ACCEPT,
DROP, REJECT, LOG, SNAT, DNAT, MASQUERADE

Welcome to:
Unit 5:
Secure Shell and Secure Copy

3.1
Unit Objectives
Discuss problems with telnet, ftp, rlogin, rsh, rcp, rexec
Describe the SSH standard
List different SSH implementations
Use OpenSSH

Telnet, ftp, rexec, rsh, rcp Problems
telnet, ftp, rexec, rsh, rcp are traditional methods of remote login, file
transfer and remote execution
Authentication usually based on password
Send as plain text
Vulnerable to sniffing
Authentication can also be based on IP address
Uses /etc/hosts.equiv or $HOME/.rhosts file
Vulnerable to IP address spoofing
Dependent on DNS server

SSH Protocol
Invented at http://www.ssh.fi
Submitted as Internet Draft (pre-RFC status)
Two client programs:
ssh -> remote login, remote execution
scp -> remote copy
One server program: sshd
Eliminates the need for telnet, ftp, rexec, rsh and rcp
Uses encryption to protect data in transit
Support for various encryption methods
Sniffing attack no longer practical
Uses public key algorithms to authenticate server
Prevents against man-in-the-middle attack

SSH Implementations
Linux:
http://www.ssh.fi
Traditional implementation
Restrictive license
http://www.openssh.org
New implementation
GNU Public License
Uses OpenSSL library of cryptographic routines
Windows 95/98/NT/2000:
Various client implementations available. See
http://www.securityportal.com/lasg/servers/shell/index.html for an
overview.

ssh Usage
Syntax: ssh [options] [user@]hostname [command]
Interprets command line options:
-c <cipher>: Encryption to be used (blowfish, 3des)
-p <port>: Remote port number
-P: Use local port > 1023
-C: Use compression
Reads config file $HOME/.ssh/config
Reads config file /etc/ssh/ssh_config
Connects to hostname
Performs user authentication
If configured: sets $DISPLAY to tunnel X connections and performs
X authentication token transfer
Executes command (optional)

scp Usage
Syntax: scp [options] [sourcefile] ... [destinationfile]
Options:
-c <cipher>: Encryption to be used (blowfish, 3des)
-p: Preserve modification times and modes
-r: Recursively copy subdirectories
-C: Use compression
-P <port>: Remote port number
Filenames specified as: [[user@]host:]filename
Third-party copies also possible:
hostC# scp hostA:/tmp/fileA hostB:/tmp/fileB

sshd Usage
Daemon process directly on port 22
Does not use [x]inetd
Started by /etc/rc.d/init.d/sshd
When started:
Read config from /etc/ssh/sshd_config
Read host-specific RSA key from /etc/ssh/ssh_host_key
Create session-specific RSA key (never stored on disk)
When a client connection is started
Negotiate session key with client
Encrypt all communications with session key
Authenticate client
Log in, execute command or copy file(s)

ssh/sshd Host Authentication
Every sshd host needs to generate a host key pair
Private key stored in /etc/ssh/ssh_host_key
Public key stored in /etc/ssh/ssh_host_key.pub
Upon first connection, the public key is transferred to the client
User gets warning: Unknown host. Accept (yes/no)?
When user accepts, public key stored in
$HOME/.ssh/known_hosts
Upon subsequent connections, keypairs verified.
When option StrictHostKeyChecking is set, you can only connect to
hosts whose public key is stored in /etc/ssh/known_hosts or
$HOME/.ssh/known_hosts
Prevents against man-in-the-middle attack

sshd User Authentication
Four methods, tried in order:
1. .rhost authentication (normally disabled)
Requires the hostname to be stored in .rhosts or /etc/hosts.equiv
(insecure - vulnerable to IP spoofing)
2. .rhosts with RSA host authentication (normally disabled)
Requires the hostname to be stored in .rhosts or /etc/hosts.equiv
and requires the client host to have the correct RSA certificate
(fairly insecure - only authenticates host, not the user)
3. RSA challenge-response authentication
Requires the user to have the correct RSA key pair (really secure)
4. Password based authentication
Requires the user to supply the correct password (secure but
vulnerable to timing attack)

RSA Challenge-Response Authentication
User generates RSA keypair on client with ssh-keygen
Private key stored in $HOME/.ssh/identity
Public key stored in $HOME/.ssh/identity.pub
Can be protected with passphrase
Can contain comment
Transfers public key to server and adds it to
$HOME/.ssh/authorized_keys
# scp ~/.ssh/identity.pub 192.168.1.1:myidentity
# ssh 192.168.1.1
# cat myidentity >> ~/.ssh/authorized_keys
User can then login without password

DSA Challenge-Response Authentication
SSH Protocol Version 2 uses DSA instead of RSA
To generate a DSA key, use ssh-keygen -t dsa
Private key stored in $HOME/.ssh/id_dsa
Public key stored in $HOME/.ssh/id_dsa.pub
Transfers public key to server and add it to
$HOME/.ssh/authorized_keys2
# scp ~/.ssh/id_dsa.pub 192.168.1.1:myid_dsa
# ssh 192.168.1.1
# cat myid_dsa >> ~/.ssh/authorized_keys2
# chmod 600 ~/.ssh/authorized_keys2
User can then login without password

Protecting Your Private Key
Anyone who can use your private key (identity or id_dsa) can login
to any system where you are authorized
Important to password-protect your private key
Disadvantage: Need to type password every time the key is used
Solution:
ssh-agent is a client-side daemon who retains unlocked private
keys in memory and activates them when one of its child
processes needs it
ssh-add manages the private keys that are retained in memory
by ssh-agent
Use ssh-add [<filename>] to add a key
Use ssh-add -l to list all keys
Use ssh-add -d [<filename>] to remove a key

SSH X Forwarding
When enabled, ssh/sshd can forward all X traffic through the SSH
tunnel
Requires xauth on the server for X authentication
Requires X11Forwarding yes in /etc/ssh/sshd_config

SSH Tunneling
SSH also allows forward (-L) and reverse (-R) tunnels
Can be used to encrypt arbitrary TCP connections, e.g. telnet,
pop3, http, ...
Forward tunnels:
Used to encrypt traffic from a local system to a service on or
behind the firewall
Usage: ssh -L <local port>:<remote sys>:<remote port>
<firewall>
Reverse tunnels:
Used to encrypt traffic from the firewall or a system behind the
firewall to a local system
Usage: ssh -R <remote port>:<local sys>:<local port>
<firewall>

SSH Firewall Considerations
SSH client uses a dynamic port
May be below 1024 unless -P option used
SSH server uses port 22
May need to open up server to allow incoming connections from the
Internet:
# iptables -A input -i ppp0 -p tcp -s any/0 --sport 1024: -d 62.186.134.70 --dport 22 -j ACCEPT
# iptables -A output -o ppp0 -p tcp -s 62.186.134.70 --sport 22 -d any/0 --dport 1024: -j ACCEPT

1. Why are the traditional remote login, remote file transfer and
remote execution programs not safe?
2. How does the SSH protocol counter these weaknesses?
3. Which SSH products are available?
4. Which certificates (RSA key pairs) are there?
5. When is a host public key transferred and what is it used for?
6. When is a user public key transferred and what is it used for?

Unit Summary
There are various reasons not to use telnet, ftp, rexec, rsh and rcp
Vulnerable to password sniffing
Vulnerable to IP address spoofing
The SSH protocol uses strong encryption and can prevent this kind
of attacks
Several implementations for Linux exist
http://www.ssh.fi
http://www.openssh.com
Five programs are used in an SSH implementation
ssh: client program for remote login and execution
scp: client program for file transfer
ssh-agent: client-side key daemon
ssh-add: client program for managing ssh-agent keys
sshd: server-side daemon

Welcome to:
Unit 6:
Socks Service

3.1
Unit Objectives
Describe Socks service concepts
Name socks servers for Linux
Install and Configure the Dante socks server

Socks Protocol
RFC 1928
Client starts connection to socks server port 1080.
First data over the connection is the requested ip address and tcp
port.
Socks server sets up connection to ip and port, then data flow is
transparent.
Client 134.191.38.72:80 Socks Server

10.0.0.2:1287 -> 10.0.0.1:1080 62.186.134.70:4011 -> 134.191.38.72:80
10.0.0.2 10.0.0.1 134.191.38.72

62.186.134.70
Intranet Internet

Advantages and Disadvantages
Advantages:
TCP-aware: not vulnerable to SYN spoofing
Transparent connections after initial setup
Clients can be "socksified" for complete transparency
Comprehensive logging
Very secure: only listens on the internal interface
Disadvantages:
Does not work well with UDP
Does not work at all with ICMP
Only works with IP addresses: client needs to do DNS resolution
Generally a little slower than NAT

Linux Socks Servers
Nec Socks: http://www.socks.nec.com
Original implementation
Restrictive license
Dante: http://www.inet.no/dante
Free implementation of a Socks server
Also contains code for socksifying client applications
Tsocks: http://sourceforge.net/projects/tsocks/
Lightweight alternative for Dante
More...

Dante Installation and Configuration
Dante compilation and installation:
cd /usr/src
tar -zxvf /root/dante-version.tar.gz
cd dante-version
./configure --prefix=/usr
make
make check
make install
Note: Dante includes a dante.spec file, so you can build a binary
RPM in one go:
{rpm|rpmbuild} -tb dante-version.tar.gz

Sample /etc/sockd.conf
logoutput: syslog # Log to syslog daemon

internal: 10.0.0.1 port = 1080 # Only listen on this interface
external: 62.186.134.70 # Only send on this interface
method: username none # Use /etc/passwd for authentication
user.privileged: root # Use "root" for privileged actions
user.notprivileged: nobody # Use "nobody" for everything else
connecttimeout: 30 # Timeout for connection setup
iotimeout: 86400 # Timeout for sending data
client pass { # Clients are only allowed if their
from: 10.0.0.0/24 to: 0.0.0.0/0 # IP address is in 10.0.0.0/24
log: connect # Log all connections
}
block { # Block all requests for anything
from: 0.0.0.0/0 to: 127.0.0.0/8 # to my loopback device
log: connect error
}
pass { # Allow all requests from any
from: 10.0.0.0/24 to: 0.0.0.0/0 # 10.0.0.0/24 address to any
protocol: tcp udp # address over tcp and udp
}

Starting and Stopping sockd
Start and stop sockd as any other service
fedora/redhat# service sockd start
fedora/redhat# service sockd stop
fedora/redhat# service sockd restart
fedora/redhat# service sockd status
suse# rcsockd start
suse# rcsockd stop
suse# rcsockd restart
suse# rcsockd status

Socksifying Applications
Every application that uses TCP/UDP can be "socksified"
Every outgoing TCP or UDP connection is automatically passed
through the socks server
Configuration file: /etc/socks.conf
route {
from: 0.0.0.0/0 to: 10.0.0.0/24 via: direct
}
route {
from: 0.0.0.0/0 to: 0.0.0.0/0 via: 10.0.0.1 port = 1080
protocol: udp tcp
proxyprotocol: socks_v4 socks_v5
method: none
}
Examples:
# socksify telnet www.instructor.com
To socksify all applications that use shared libraries:
# export LD_PRELOAD="libdsocks.so"
# telnet www.instructor.com

1. How does the socks protocol work?
2. What are the advantages and disadvantages of the socks
protocol?
3. Which socks servers are there for Linux?
4. How do you implement the Dante socks server?

Unit Summary
The socks protocol specifies that the client initiates a connection to
the socks server, port 1080
The first data on this connection should be the remote IP address
and port number
The socks server initiates a second connection to the specified IP
address and port number, and forwards all data transparently
There are a number of socks servers available for Linux: NEC,
Dante, Tsocks and others
Dante installation is fairly straightforward

Welcome to:
Unit 7:
Proxy Service

3.1
Unit Objectives
Describe Proxy service concepts
List advantages and disadvantages of proxies
Name proxy servers for Linux
Configure Apache for proxy service
Install and Configure the Squid proxy server

Proxy Protocol
RFC 2616
Client starts connection to proxy server port 8080.
First data over the connection is the requested URL
Proxy server sets up connection to server and retrieves the data,
then forwards the data to client.
Client GET http://134.191.38.72/ Proxy GET / Server

10.0.0.2:1287 -> 10.0.0.1:8080 62.186.134.70:4011 -> 134.191.38.72:80
10.0.0.2 10.0.0.1 134.191.38.72

62.186.134.70
Intranet Internet

Advantages and Disadvantages
Advantages:
Proxy does DNS lookup
Very granular logging
Very granular access control
Based on user (supports password authentication)
Based on client IP address
Based on server IP address
Based on type of document
Proxy can do transparent caching
Disadvantages:
Only works for specific protocols
Generally slower than NAT

Linux Proxy Servers
Apache: http://www.apache.org
Most popular web server on the Internet
Supports HTTP/FTP proxy service in a separate module
Very useful if you have a combined web server/proxy
Available by default in Red Hat Linux
Squid: http://squid.nlanr.net
HTTP/FTP Proxy function only
Very extensive configuration possible
Supports ICP (Internet Cache Protocol)
TIS Firewall Toolkit (http://www.tis.com)
Various proxy servers for telnet, FTP, gopher, ...

Configuring Apache for Proxy Service
Apache 1.x httpd.conf:
Listen 10.0.0.1:8080
LoadModule proxy_module modules/libproxy.so
AddModule mod_proxy.c
<IfModule mod_proxy.c>
ProxyRequests On
<Directory proxy:*>
Order deny,allow
Deny from all
Allow from 10.0.0.0/24
</Directory>
</IfModule>
Apache 2.x httpd.conf:
Listen 10.0.0.1:8080
LoadModule proxy_module modules/mod_proxy.so
<IfModule mod_proxy.c>
ProxyRequests On
<Proxy *>
Order deny,allow
Deny from all
Allow from 10.0.0.0/24
</Proxy>
</IfModule>

Installing, Configuring and Starting Squid
Install Squid:
rpm -ivh squid-version.rpm
Change Squid config file /etc/squid.conf (next visual)
Start Squid
service squid start
rcsquid start

/etc/squid.conf
http_port 10.0.0.1:8080
icp_port 0
cache_mem 8 MB
cache_dir ufs /var/cache/squid 100 16 256
cache_access_log /var/log/squid/access.log
cache_log /var/log/squid/cache.log
pid_filename /var/run/squid.pid
acl all src 0.0.0.0/0.0.0.0
acl allowed_hosts src 10.0.0.0/255.255.255.0
http_access allow allowed_hosts
http_access deny all
icp_access deny all
miss_access allow all
cache_effective_user squid
cache_effective_group squid
snmp_port 0

Summary Visual: NAT, Socks, Proxies
NAT/IP Socks Proxy

Masquerading
Individual solution for No No Yes
each application?
Speed Fast Somewhat slower Slower
Logging At IP packet level At TCP connection At application level
level (username,
filename)
Caching possible? No No Usually
Authorization based IP address IP address IP address,
on username, password
Implemented how In kernel Additional software Additional software
Which protocols? TCP, UDP, ICMP TCP, UDP Depends on
application, typically
TCP only
DNS lookups by? Client Client Server
Transparent for Yes Yes if socksified No, always need to
user? stack is used configure client app.

1. How does the proxy protocol work?
2. What are the advantages and disadvantages of the proxy protocol?
3. Which proxy servers are there for Linux?
4. How do you configure Apache as a proxy server?
5. How do you implement Squid?

Unit Summary
The proxy protocol specifies that the client initiates a connection to
the proxy server, port 8080 (default)
The first data on this connection should be the URL to retrieve
The proxy server initiates a second connection to the web server
and retrieves the URL
The most often used proxy servers for Linux are Apache and Squid

Welcome to:
Unit 8:
Securing DNS

3.1
Unit Objectives
List DNS consideration on firewalls
Configure DNS on firewalls

DNS Considerations
Don't give away internal information to Internet users
Might be used by hackers
Might contain reserved IP addresses
Allow internal users to retrieve Internet DNS information
Needed when using NAT or Socks
Not strictly needed when using Proxies (the proxy resolves the IP
address)
Ensure that regular and reverse DNS queries match
Don't allow dynamic updates
Might be used to insert malicious data
Don't allow large transfers to anybody (e.g. zone transfer, dig)
Might be used for DoS attacks

DNS Name Considerations
One name registration:
www.acme.com: Internet server
w3.acme.com: intranet server
One registration, two domains:
www.intranet.acme.com: intranet server
Two registrations:
www.acme.net: intranet server
Made-up Top-Level Domain (TLD)
www.servers.acme: intranet server

DNS Servers
Authoritative for the DMZ
DMZ Packet The Internet

DNS Filtering
Server DMZ Router
Packet
Filtering
Router
Authoritative for the intranet and DMZ

Forwards Internet queries to DMZ DNS Server
Company Network Intranet

DNS
Server

Scenario (DMZ Situation)
www.acme.com
DMZ
Sec. DNS Company
Server Web
bar.acme.com
server
62.186.134.20
foo.acme.com 62.186.134.71
DMZ Packet The Internet
Pr. DNS DMZ Filtering
Server 62.186.134.0/24 Router
62.186.134.70 62.186.134.1
ftp.acme.com 62.186.134.2
Packet
Company
Filtering
FTP server
Router
10.0.0.1
62.186.134.21
w3.acme.com widget.acme.com
Intranet Company Network 10.0.0.40
Web 10.0.0.0/24 Intranet
server DNS
10.0.0.60 Server

Internet Primary DNS Server Config File
# cat /etc/named.conf
// Internet DNS server for acme.com
options {
directory "/var/named";
};
zone "." {
type hint;
file "named.ca";
};
zone "acme.com" {
type master;
file "named.acme.com";
allow-update { none; };
allow-transfer { 62.186.134.71; };
};
zone "134.186.62.in-addr.arpa" {
type master;
file "named.62.186.134";
allow-transfer { 62.186.134.71; };
};

Internet Primary DNS Server Name Zone File
# cat /var/named/named.acme.com
$TTL 86400
@ IN SOA foo.acme.com. webmaster.acme.com. (
2001120100 ;Serial
28800 ;Refresh
14400 ;Retry
3600000 ;Expire
86400 ;Default TTL
)
@ IN NS foo.acme.com.
@ IN NS bar.acme.com.
foo IN A 62.186.134.70
bar IN A 62.186.134.71
www IN A 62.186.134.20
ftp IN A 62.186.134.21

Internet Primary DNS Server IP Zone File
# cat /var/named/named.62.186.134
$TTL 86400
@ IN SOA foo.acme.com. webmaster.acme.com. (
2001120100 ;Serial
28800 ;Refresh
14400 ;Retry
3600000 ;Expire
86400 ;Default TTL
)
@ IN NS foo.acme.com.
@ IN NS bar.acme.com.
70 IN PTR foo.acme.com.
71 IN PTR bar.acme.com.
20 IN PTR www.acme.com.
21 IN PTR ftp.acme.com.

Internet Secondary DNS Server Config File
// Internet DNS server for acme.com
options {
};
zone "." {
type hint;
file "named.ca";
};
zone "acme.com" {
type slave; masters { 62.186.134.70; };
file "named.acme.com.bak";
allow-transfer { none; };
};
type slave; masters { 62.186.134.70; };
file "named.62.186.134.bak";
allow-transfer { none; };
};

Intranet DNS Server Config File
// Intranet DNS server for acme.com
options {
forward only;
forwarders { 62.186.134.70; 62.186.134.71; };
};
zone "acme.com" {
type master;
file "named.acme.com";
};
type master;
file "named.10.0.0";
};

Intranet DNS Server Name Zone File
$TTL 86400
@ IN SOA widget.acme.com. webmaster.acme.com. (
2001120100 ;Serial
28800 ;Refresh
14400 ;Retry
3600000 ;Expire
86400 ;Default TTL
)
@ IN NS widget.acme.com.
router1-dmz IN A 62.186.134.1
router2-dmz IN A 62.186.134.2
foo IN A 62.186.134.70
bar IN A 62.186.134.71
www IN A 62.186.134.20
ftp IN A 62.186.134.21
router2-int IN A 10.0.0.1
w3 IN A 10.0.0.60
widget IN A 10.0.0.40

Intranet DNS Server IP Zone File
# cat /var/named/named.10.0.0
$TTL 86400
@ IN SOA widget.acme.com. webmaster.acme.com. (
2001120100 ;Serial
28800 ;Refresh
14400 ;Retry
3600000 ;Expire
86400 ;Default TTL
)
@ IN NS widget.acme.com.
1 IN PTR router2-int.acme.com.
40 IN PTR widget.acme.com.
60 IN PTR w3.acme.com.

DNS Query Resolving
Intranet client:
Client asks widget
widget forwards query to foo or bar for Internet queries
foo or bar resolve query on Internet
DMZ client:
Client asks foo or bar
foo or bar resolve query on Internet
For intranet queries: store in /etc/hosts
Note: Mail servers need widget as their DNS server
Internet client:
Client asks foo or bar
foo or bar answer query

DNS Packet Characteristics
Regular client -> Server DNS query
Initially done through UDP, source port > 1023, destination port 53
If fails done through TCP, source port > 1023, destination port 53
Server -> Server DNS query
Initially done through UDP, source port 53, destination port 53
(Bind 8.1: source port >1023)
If fails done through TCP, source port > 1023, destination port 53
Server -> Server zone transfer
Only done through TCP, source port > 1023, destination port 53

DNS iptables Rules
On the DNS server itself:

# iptables -A INPUT -i ppp0 -p tcp -s any/0 -d 62.186.134.70 --dport 53 -j ACCEPT
# iptables -A OUTPUT -o ppp0 -p tcp -s 62.186.134.70 --sport 53 -d any/0 -j ACCEPT
# iptables -A INPUT -i ppp0 -p udp -s any/0 -d 62.186.134.70 --dport 53 -j ACCEPT
# iptables -A OUTPUT -o ppp0 -p udp -s 62.186.134.70 --sport 53 -d any/0 -j ACCEPT
On a router:
# iptables -A FORWARD -i ppp0 -p tcp -s any/0 -d 62.186.134.70 --dport 53 -j ACCEPT
# iptables -A FORWARD -i ppp1 -p tcp -s 62.186.134.70 --sport 53 -d any/0 -j ACCEPT
# iptables -A FORWARD -i ppp0 -p udp -s any/0 -d 62.186.134.70 --dport 53 -j ACCEPT
# iptables -A FORWARD -i ppp1 -p udp -s 62.186.134.70 --sport 53 -d any/0 -j ACCEPT
# iptables -A FORWARD -i ppp0 -p tcp -s any/0 -d 62.186.134.71 --dport 53 -j ACCEPT
# iptables -A FORWARD -i ppp1 -p tcp -s 62.186.134.71 --sport 53 -d any/0 -j ACCEPT
# iptables -A FORWARD -i ppp0 -p udp -s any/0 -d 62.186.134.71 --dport 53 -j ACCEPT
# iptables -A FORWARD -i ppp1 -p udp -s 62.186.134.71 --sport 53 -d any/0 -j ACCEPT

1. What are considerations when configuring DNS on a firewall?
2. Do you need to be able to resolve Internet DNS queries on the
intranet?
3. Where do you place your DNS servers?
4. Which DNS server has which information?
5. What DNS servers are used, in which order, to resolve different
client queries?

Unit Summary
If you are using NAT or socks, Intranet clients need to be able to
resolve DNS queries on the Internet
Internet clients need to be able to resolve DNS queries for hosts on
the DMZ
The usual configuration consists of at least two DNS servers on the
DMZ, and at least one DNS server on the Intranet
The Intranet DMZ server(s) forward all Internet queries to the DMZ
DNS servers
The DMZ DNS servers are configured to give away as little
information as possible

Welcome to:
Unit 9:
Securing E-mail

3.1
Unit Objectives
List e-mail considerations
List different MTA programs for Linux
Configure Sendmail on a firewall
Discuss a number of checks that can be performed on incoming and
outgoing e-mail

E-mail Considerations
Allow internal users to send e-mail to Internet users
Allow Internet users to send e-mail to internal users
Don't give away internal information
Don't allow your server to be used as a relay
Block messages that are too large
Block incoming junk e-mail (spam)
Block messages with viruses
Block dangerous attachments

Mail Gateway and Mail Server
Packet The Internet

Filtering
DMZ Router
Mail
Gateway Packet
Filtering
Router
Mail
Server Client
SMTP
POP/IMAP
Company Network

Mail Servers for Linux
Sendmail (http://www.sendmail.org)
Traditional implementation
70% market share
Large security history
Very flexible
Postfix (http://www.postfix.org)
Developed as a secure replacement for Sendmail
Well thought out
Default in SuSE Linux
Qmail (http://www.qmail.org)
Developed as a secure replacement for Sendmail
Modular design
GNU Public License
Exim (http://www.exim.org)

Configuring Sendmail as Mail Gateway
Allow relaying of e-mail to/from acme.com domain
cd /etc/mail
vi access
Add: acme.com RELAY
vi mailertable
Add: acme.com smtp:mail.acme.com
make
Allow connections via all interfaces
vi /etc/sendmail.mc
dnl DAEMON_OPTIONS(Port=smtp, Addr=127.0.0.1,
Name=MTA)
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
Restart Sendmail
service sendmail restart

Configuring Postfix as Mail Relay
Allow relaying of mail to/from acme.com domain
cd /etc/postfix
vi access
Add: acme.com OK
postmap access
vi transport
Add: acme.com smtp:mail.acme.com
postmap transport
vi main.cf
myhostname = mailrelay.acme.com
mydomain = acme.com
myorigin = $mydomain
inet_interfaces = all
mynetworks = 192.168.1.0/24
relay_domains = $mydestination, $mydomain
rcpostfix restart

Configuring Sendmail as Mail Server
Add local domain and smart relay info to config file:
vi /etc/mail/sendmail.mc
MASQUERADE_DOMAIN(team1.com)
define(SMART_HOST, mailrelay.acme.com)
dnl DAEMON_OPTIONS(Port=smtp, Addr=127.0.0.1,
Name=MTA)
Add local domain names to /etc/mail/local-host-names
Allow mail relaying from clients to clients in this domain:
vi /etc/mail/access
Add: acme.com RELAY
make
service sendmail restart
Enable POP3 server
chkconfig ipop3 on
Add local users

Configuring Postfix as Mail Server
Add local domain and gateway info to config file
vi /etc/postfix/main.cf
myhostname = mail.acme.com
mydomain = acme.com
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, $mydomain
relayhost = fw.team1.com
Allow relaying from local clients:
vi /etc/postfix/access
acme.com RELAY
Restart Postfix
rcpostfix restart
Allow POP3
chkconfig qpopper on

Configuring DNS for Mail Relaying
DMZ DNS MX records should point to the mail relay
.
@ IN MX 10 mailrelay.acme.com.
.
mailrelay IN A 62.186.134.80
.
Intranet DNS MX record should point to the mail server
.
@ IN MX 10 mail.acme.com
.
mail IN A 10.0.0.80
.

Limiting Message Size
Sendmail: Configure MAX_MESSAGE_SIZE in sendmail.mc
vi /etc/mail/sendmail.mc
define(confMAX_MESSAGE_SIZE, 50000)
Postfix: Set message_size_limit in main.cf
vi /etc/postfix/main.cf
message_size_limit = 50000

Blocking Junk E-mail (Spam)
Add spamming domain to /etc/mail/access or /etc/postfix/access
with keyword:
REJECT: Bounces messages as undeliverable
OK: Allow from this subdomain even if another rule prevents
receiving mail from the higher-level domain.
DISCARD: Discard message, don't send anything back
### Error Message: Bounce messages with a custom error
number and message (similar to REJECT)
localhost.localdomain RELAY
localhost RELAY
127.0.0.1 RELAY
acme.com RELAY
cracker.org REJECT
spammer.org DISCARD
good.spammer.org OK
badsmtp.org 500 Bad SMTP spoken by you
SpamAssassin
Evaluates message using various criteria to determine "spam score"
If spam score is too high, message is spam and marked as such
(subject or other header fields)
Can use Bayesian filtering too
Learns what spam is from past messages classified manually as
such
Two modes:
Invoke every time (inefficient)
Run as daemon with lightweight client
Invocation:
By MTA using milter interface (Sendmail) or external filter (Postfix)
By procmail

Installing SpamAssassin
Install spamc/spamd client/server pair, start and test
daemon
Included in most distributions as RPM
Sendmail: Install spamass-milter and activate milter
interface in sendmail.mc:
INPUT_MAIL_FILTER(spamassassin, S=local:/var/run/spamass.sock, F=,
T=C:15m;s:4m;R:4m;E:10m)dnl
define(confMILTER_MACROS_CONNECT, b, j, _, {daemon_name},
{if_name}, {if_addr})
Postfix: Create postfixfilter which calls spamc and then

reinjects message in Postfix; then modify main.cf to use
postfixfilter:
smtp inet n - n - - smtpd -o content_filter=spamfilter
spamfilter unix - n n - - pipe flags=Rq argv=/usr/bin/postfixfilter -f ${sender}
-- ${recipient}

Real-Time Blacklisting
Real-Time Blacklisting:
List of known spammers at vix.com (and other sites)
Accessible through DNS hack:
If hostname 196.197.198.199.rbl.maps.vix.com exists,
199.198.197.196 is a known spammer
More information on http://maps.vix.com/rbl

Detecting Viruses in Attachments
AMaViS (A Mail Virus Scanner)
http://amavis.org
Detaches all attachments (uncompresses if necessary)
Uses a separate virus scanner to scan attachments
20+ commercial virus scanners supported
If virus found, deletes message and send e-mail to sender, recipient
and/or administrator
Two modes:
Invoke every time (inefficient)
Run as daemon with lightweight client
Invocation:
By MTA using milter interface (Sendmail) or external filter (Postfix)
(always)
By procmail (only when delivering mail locally)

Installing AMaViS
Install a commercial virus scanner
Install amavisd
Required a large number of perl modules which might not be
included with your distribution
Requires various decompress utilities
Sendmail: Add milter interface for AMaViS:
INPUT_MAIL_FILTER(milter-amavis,
S=local:/var/amavis/amavis-milter.sock, F=T, T=S:10m;R:10m;E:10m)dnl
Postfix: Add AMaViS as external filter (before SpamAssassin):
smtp inet n - n - - smtpd -o content_filter=vscan
vscan unix - n n - 10 pipe user=vscan argv=/usr/sbin/amavis ${sender}
${recipient}
localhost:10025 inet n - n - - smtpd -o content_filter=spamfilter
Test setup with eicar.com test file

SMTP Firewall Rules
Allow incoming connections to port 25 (SMTP):
# iptables -A INPUT -i ppp0 -p tcp -s any/0 -d 62.186.134.70 \

--dport 25 -j ACCEPT
# iptables -A OUTPUT -o ppp0 -p tcp -s 62.186.134.70 --sport 25 \
-d any/0 -j ACCEPT

1. Which e-mail servers are available for Linux?
2. Name some considerations of e-mail on a firewall.
3. Name some checks you can have performed automatically on
incoming and outgoing e-mail.

Unit Summary
There are several e-mail servers available for Linux:
Sendmail
Qmail
Postfix
All these programs can be used as a mail relay on a firewall
All these programs can be extended to reject spam, check for
viruses, reject messages that are too large and so forth

Welcome to:
Unit 10:
Virtual Private Networks

3.1
Unit Objectives
Describe Virtual Private Networks concepts
List different VPN protocols
Discuss the IPSec protocol suite
List different IPSec implementations for Linux
Install and configure KAME/setkey/Racoon

Virtual Private Networks Concepts
Packet The Internet

Filtering
DMZ Router
Packet Tunneling
Filtering Device
Router Firewall
with
Client
Tunneling
Company Network Customer Network

Intranet
Server

Virtual Private Network Solutions
PPP over telnet or ssh
PPTP (Point to Point Tunneling Protocol)
IETF Standard (RFC 2637)
PPP over IP
PAP, CHAP authentication
RC4 encryption (max 128 bits)
Supported in Microsoft Windows 95/98/NT/2000
IPSec (IP Security Protocol)
IETF Standard (RFC 2411)
IP encapsulated over IP
Integral part of IPv6, ported back to IPv4
Encryption, Authentication, Integrity protection, Replay protection,
Non-repudiation
Key management protocol
Widely supported

IPSec Overview
RFC 2411 (Documentation Roadmap)
Uses three subprotocols
IKE (Internet Key Exchange)
ESP (Encapsulation Security Protocol)
Authentication and Encryption
AH (Authentication Header)
Only Authentication
Uses any encryption algorithm that is available (automatic
negotiation at startup)
Allows two modes:
Transport mode: host-to-host
Tunneling mode: router-to-router

IPSec Modes
H1 H2
Transport mode: host-to-host security
H1 R1 R2 H2
Tunnel mode: router-to-router security

Authentication Header Protocol (AH)
Integrity checking
Authentication through MD5 or SHA
Protocol number 51
Regular IP packet: IP Header IP Payload
IP packet, transport: IP Header AH Header IP Payload
IP packet,
IP Header AH Header IP Header IP Payload
tunneled:

Encapsulating Security Payload (ESP)
Integrity checking
Authentication through MD5 or SHA
Encryption through DES, 3DES, CDMF
Protocol number 50
Regular IP packet: IP Header IP Payload
IP packet, transport: IP Header ESP Header IP Payload (encrypted)
IP packet, IP Header
IP Header ESP Header IP Payload (encrypted)
tunneled: (encrypted)

Internet Key Exchange (IKE)
Uses UDP/IP as transport protocol
UDP Port 500 on both sides
Automated connection setup between two IPSec hosts
Initial phase: cleartext
Negotiate session key using Diffie-Hellman
Rest of communication is encrypted
Automated negotiation of Security Associations
Unique, one-way session between two IPSec systems
Need two SA's for two-way communication
Automated refresh of cryptographic keys (automatic keying)

Session Key Exchange and Authentication
Session Keys
Manually keyed: Automatically keyed:

Session key stored in Session key negotiated and
/etc/ipsec.conf refreshed automatically
(Same on both machines, (Needs authentication)
does not need authentication)
Authentication
Shared secret Public key (RSA)

(common secret on both (usually distributed as part of
machines) X.509 certificate - may be
self-signed or signed by CA)

IPSec Support in Linux
Required: kernel support and userland programs
Kernel support:
FreeS/WAN, OpenS/WAN and others: add-ons to 2.4 and earlier
kernels
KAME: Integrated in 2.6 kernels, backported to 2.4 by distributors
Userland programs:
OpenS/WAN: Works with OpenS/WAN and KAME based kernels
setkey: Tool to manually configure IPSec policies and keys
racoon: Tool which automatically sets up setkey-defined policies
In this course we'll cover KAME/setkey/racoon (ipsec-tools RPM)

setkey.conf Policies
/etc/racoon/setkey.conf (read by setkey) lists the policies: describe
what traffic should be encrypted
Syntax:
spdadd <source> <dest> <upperspec> <policy>;
<upperspec> is "any" or any protocol from /etc/protocols
<policy> is usually one of:
-P <direction> discard
-P <direction> none
-P <direction> ipsec protocol/mode/src-dst/level
Example
spdadd 192.168.1.0/24 192.168.2.0/24 any -P out ipsec
esp/tunnel/10.0.0.1-10.0.0.2/require;
Use spdflush at top of setkey.conf to flush all policies

setkey.conf SA Descriptions
For manually keyed connections (who do not need IKE) you can add
the actual SA definitions to setkey.conf as well
Syntax:
add <src> <dst> <proto> <spi> <extensions> <alg>
Example:
add 10.0.0.1 10.0.0.2 esp 0x200 -m tunnel -E 3des-cbc
0x12345678... -A hmac-md5 0x12345678...
Use flush at top of setkey.conf file to flush all SAs

Racoon
User-space daemon that performs SA association negotiation (using
IKE) with other systems
Uses setkey policies to determine whether an SA is needed
Will negotiate an SA as soon as it is needed according to the policy
Note: Because of this, the first few packets of a connection may
get lost...
Will automatically refresh all keys
Configuration file /etc/racoon/racoon.conf
Settings for remote systems
SA settings

Racoon Manual Authentication
Add a common secret to both /etc/racoon/psk.txt files
Secret can be an arbitrary sentence or a random number
The shared secret is sometimes also known as "passphrase" or
"pre-shared key"
62.186.134.71 "This is our common secret"

62.186.134.72 "0x70b2c76d_f2ds30e9_f9..."

RSA Public Key Authentication
Generate self-signed or CA-signed X.509 certificate on both
systems using openssl (complex syntax)
Transfer X.509 to other side, verify and store in /etc/racoon/certs
Change /etc/racoon/racoon.conf to use these certificates instead of
shared secrets

Firewall-to-Firewall and Firewall-to-Subnet
A regular tunnel only allows subnet-to-subnet communications
For firewall-to-firewall and firewall-to-subnet communications, set up
additional policies (in /etc/racoon/setkey.conf)
Firewall-to-firewall connections may use transport or tunnel mode

Verifying Connections With tcpdump
On the workstation:
ping -p feedfacedeadbeef 192.168.2.2
On the firewall:
tcpdump -i eth0 -x -l -n
tcpdump -i ppp0 -x -l -n

Useful Commands
setkey -DP: Display current active policies
setkey -D: Display current active SAs

IPSec iptables Rules
Need to allow protocol 50 (ESP) and/or 51 (AH) on external
interface (incoming and outgoing)
# iptables -A INPUT -s 62.186.134.71 -d 62.186.134.70 -p 50 -i ppp0 -j ACCEPT
# iptables -A OUTPUT -s 62.186.134.70 -d 62.186.134.71 -p 50 -i ppp0 -j ACCEPT
# iptables -A INPUT -s 62.186.134.71 -d 62.186.134.70 -p 51 -i ppp0 -j ACCEPT
# iptables -A OUTPUT -s 62.186.134.70 -d 62.186.134.71 -p 51 -i ppp0 -j ACCEPT
Need to allow traffic to/from UDP port 500 (IKE)

# iptables -A INPUT -p udp -s 62.186.134.71 --sport 500 -d 62.186.134.70\
--dport 500 -i eth0 -j ACCEPT
# iptables -A OUTPUT -p udp -s 62.186.134.70 --sport 500 -d 62.186.134.71\
--dport 500 -i eth0 -j ACCEPT

1. What different VPN solutions are there for Linux?
2. Name the components of the default IPSec implementation in
todays distributions.
3. Name the steps to take to get IPSec up and running.
4. Name two keying methods. Which one requires authentication?
5. Name two authentication methods.

Unit Summary
Various methods for creating VPN's exist. The IETF standard is
IPSec
IPSec is implemented in Linux through various solutions. The
default today is KAME/setkey/racoon.
setkey defines your IPSec policies and can manually configure your
SAs.
racoon sets up the IPSec SAs using the IKE protocol.
Keying can be done manually or automatically; automatic keying
requires authentication.
Authentication can be done manually or through RSA public/private
keys.

Welcome to:
Unit 11:
Hacker's Tools

3.1
Unit Objectives
List categories of hacker's tools
Install, configure and use ethereal
Install, configure and use nmap
Install, configure and use Nessus

Categories of Hacker's Tools
Sniffers
Fingerprinters
Port Scanners
Intrusion Scanners
Others

Sniffers
Most sniffers use libpcap library
Default RPM in Linux
Require adapter to be in "promiscuous mode"
Receives ALL packets on the network
Does not work when using switches instead of hubs
Unless you configure the switch to allow sniffing
Various sniffers available:
tcpdump (Default in most distributions)
Ethereal (http://ethereal.zing.com)
Sniffit (http://sniffit.rug.ac.be)
Ettercap (http://ettercap.sourceforge.net)
Anti-sniffer software can detect adapters that are in promiscuous
mode
Send data to valid IP address but bogus MAC address
Antisniff (http://www.l0pht.com/antisniff)

Ethereal Installation
Download ethereal-version.tar.gz from http://www.ethereal.com
Install Ethereal:
cd /usr/src/
tar -zxvf /root/ethereal-version.tar.gz
cd ethereal-version
./configure
make
make install
Run Ethereal
ethereal
Ethereal may already be included in your distribution

Ethereal Example

Fingerprinters
Contact a host with various valid and invalid IP, TCP and UDP
packets to determine OS type and version
Usually leave no trace in logfiles, because connections are never
fully opened
Can usually only be detected with a packet sniffer
Examples:
Queso (http://apostols.org/projectz/queso)

Port Scanners
Contact various well-known (or all) ports to determine which
programs (and versions) are running on the host
Knowledge may then be used as basis of attack
Port scanning usually leaves a log trail
Examples:
nc (netcat) (Default in most distributions)
Strobe (ftp://suburbia.net/pub)
Nmap (http://www.insecure.org/nmap/index.html)

Nmap
Fully featured host scanning tool
Supports:
TCP/IP Fingerprinting (a la Queso)
Vanilla TCP connect() scanning
TCP half open scanning
TCP stealth scans
TCP FTP proxy scans
SYN/FIN scans
TCP ACK and Window scans
IDP raw ICMP port unreachable scans
ICMP scans
TCP ping scans
Direct RPC scans
Reverse-identd scans
Supports slow scans to make detection harder

Nmap Installation
Download nmap-version.tar.gz from
http://www.insecure.org/nmap/index.html
To install:
cd /usr/src
tar -zxvf /root/nmap-version.tar.gz
cd /usr/src/nmap-version
./configure
make
make install
To run:
xnmap
Nmap may already be included in your distribution

Nmap Example

Intrusion Scanners
Test hosts against a list of known vulnerabilities
Usually leave a log trail
May actually cause the host to crash
Examples:
Satan (http://www.fish.com/~zen/satan/satan.html)
Saint (http://www.wwdsi.com/saint)
Nessus (http://www.nessus.org)

Nessus Overview
Client/server architecture
Server on Linux, FreeBSD, NetBSD, Solaris
Clients on Linux and Windows + Java client
Client-Server communication encrypted
Supports:
Port scanning
Intrusion scanning (200+ known vulnerabilities built-in)
Plug-in language available to incorporate other scans

Nessus Installation (1 of 2)
Download these four files from http://www.nessus.org:
nessus-libraries-version.tar.gz, libnasl-version.tar.gz,
nessus-core-version.tar.gz, nessus-plugins-version.tar.gz
To install:
for package in nessus-libraries \
libnasl nessus-core nessus-plugins
do
cd /usr/src
tar -xzvf /root/$package-version.tar.gz
cd $package
./configure --prefix=/usr
make
make install
done
Nessus may already be included in your distribution

Nessus Installation (2 of 2)
Add a Nessus user account
nessus-adduser
Create a Nessus server certificate
nessus-mkcert
Start the Nessus daemon proper
nessusd -D
Start the Nessus client
nessus

Nessus Example

Nessus Output Example

Other Hacker's Tools
Firewalk (http://www.packetfactory.net/Projects/Firewalk):
Attempt to find holes in (iptables style) firewall setups
Use packets with a destination behind the firewall to probe for
misconfigurations
Cheops (http://www.marko.net/cheops):
Scan a network for interesting devices
"Network Neighborhood on Steroids"
TCP/IP fingerprinting
Port scanning
Exploits
Custom programs that allow you to use a certain exploitable
vulnerability
Typically found on sites like http://www.rootshell.com and
http://www.insecure.org

1. As a hacker, how would you proceed in retrieving all information
about a site?
2. As a system administrator, how would you use that knowledge to
your advantage?

Unit Summary
Various hacker tools exist on the Internet: sniffers, port scanners,
intrusion scanners and other tools
Sniffers can trace all the data on a network and analyze this
Port scanners can determine which ports on a server are open
Intrusion scanners use a database of known vulnerabilities to detect
whether a system has holes
Various other tools can discover information about your site and
setup too

Welcome to:
Unit 12:
Detecting and Countering Firewall
Intrusions

3.1
Unit Objectives
Create a baseline of your system and detect deviations from the
baseline
Configure and use network intrusion detection systems
Configure and use logfile monitoring
React to attack attempts
Discuss deception

Detecting Attack Attempts
Filesystem Changes
Added/deleted/changed files
Changed file permissions
Network packet monitoring
Monitor network packets, try to detect pattern
Logfile monitoring
Look for strange entries in logfiles

Baseline
Baseline is a "blueprint" of your firewall in pristine state
Saved to secure media
CD-Recordable
Tape
Read-only floppy
Used to figure out what has changed
After system administration
After a break-in
After a while
Various possibilities
Full system backup
Do It Yourself
File system monitoring

Do-It-Yourself Baseline
Save the following files
/etc/*
/boot/*
Save output of following commands
ps -aux
netstat -an
netstat -rn
free
df
du /
vmstat
ls -lR /
mount
rpm -qa
Save md5sum of all executables and libraries

Filesystem Integrity Checking
Save characteristics of every important file:
User, group
Permissions
ctime, mtime
length
link count
checksum
...
Regularly verify actual situation with stored characteristics
Various tools available:
Tripwire (http://www.tripwire.com)
AIDE (http://www.cs.tut.fi/~rammer/aide.html)
L5 (ftp://avian.org/src/hacks)
See
http://www.securityportal.com/lasg/attack-detection/index.html
for exhaustive list
Tripwire
Popular File Integrity Checking tool
Originally written as academic research project in 1992
No development until 1997 when one of the authors continued
development as a commercial product range
Core tool released as open source in 2000
All tripwire files encrypted and signed
Digital signatures protected with password
Creates a system-dependent config file automatically when
installing

Tripwire Installation and Usage
Install tripwire-version.rpm
Review text config file /etc/tripwire/twcfg.txt and policy file
/etc/tripwire/twpol.txt
Create local, site key and signed/encrypted config and policy files:
Automatically with /etc/tripwire/twinstall.sh (Red Hat)
Manually with twadmin (SuSE)
To initialize database:
tripwire --init
To perform a check against the database:
tripwire --check [filename]
twreport -m r -r report
To update the database:
tripwire --update

Network Intrusion Detection Systems
Act like intelligent sniffers
Can work autonomously
Examples:
Psionic PortSentry (http://www.psionic.com/abacus/portsentry)
Scanlogd (http://www.openwall.com/scanlogd)
Snort (http://www.snort.org)

Snort
"Open Source Network Intrusion Detection System"
Three modes:
Sniffer
Packet capture on disk
Intrusion Detection
Works on most UNIX systems (and Linux of course)
Uses libpcap
Installing snort:
# cd /usr/src
# tar -zxvf /root/snort-version.tar.gz
# cd snort-version
# ./configure
# make
# make install

Snort Sniffer Mode
Similar to tcpdump
General syntax: snort [-i interface] -v [expression]
[expression]: tcpdump-style packet selection
Options:
-e: show layer-2 info as well
-d: show data as well (hex and char)

Snort Packet Logging Mode
Saves all packets to disk
Two ways of storage possible:
tcpdump compatible (one binary for all packets)
snort-specific directory structure (slower)
tcpdump compatible:
snort -b [-l <directory>] [-L <filename>]
To read a tcpdump binary file: snort -r <file>
snort specific structure:
snort -l <directory> [-h <home-net>]
Directory structure is
<directory>/<foreign-IP>/<PROTO>:<port>-<port>
File content is identical to output of snort -v

Snort NIDS Mode
Logs interesting packets and sends alerts
Managed by configuration file /etc/snort.conf
Snort variables
Preprocessors (for example, fragmentation reassembly)
Output plugins (for example, syslog, tcpdump, database, SNMP)
Rules and rule set includes
A snort rule describes the traffic to watch for, and the action to take
Example: log tcp any any -> 1.2.3.4 22
Rules may list packet data
Rules may use variables defined in snort.conf
A rule set is a file containing related rules which can be included as
a whole in snort.conf
See /usr/src/snort-version/rules

Snort Rulesets
Snorts includes ~50 rulesets by default
More rule sets are available on www.snort.org
When a new virus/exploit/... hits the web, a snort rule is only hours
away...
Tools to update/download rulesets automatically:
ArachNIDS: http://www.whitehats.com/ids/
SnortCenter: http://users.pandora.be/larc/
Snort Enterprise Implementation document:
http://www.superhac.com

Logfile Monitoring
Monitor logfiles for strange entries, continuously or at regular
intervals (through cron)
Send mail to the sysadmin if certain entries appear
Examples:
Psionic LogSentry (formerly known as LogCheck)
(http://www.psionic.com/products/logsentry.html)
Swatch (ftp://ftp.stanford.edu/general/security-tools/swatch)

Swatch
Can analyze log files in batch or real-time
Can output to any scriptable interface
SMS, Pager!
Installation instructions:
Download from http://swatch.sourceforge.net
perl Makefile.PL
make
make install
Need selected modules from CPAN (Comprehensive Perl Archive
Network)
Usually included in distribution

Swatch Configuration
For each line of the log file, the configuration file is parsed from top
to bottom
Stop after first match
Default configuration file: ~/.swatchrc
Default log file: /var/log/messages

Swatch Configuration Options
ignore <regex>: Ignore these log lines
watchfor <regex>: Watch for these log lines and execute actions:
echo [<color>]: Echo on stdout
bell: Ring a bell
exec <command>: Execute a command
mail addresses=<recip>,subject=<subject>: Send e-mail
pipe <command>: Pipe to command
write <user>: Use write to alert user
throttle <limit>: Limit invocation amount
continue: Don't stop after match; continue searching through
config file for more matches

Swatch Batch Mode
swatch [-c <config file>] -f <log file>
Reads whole logfile and applies actions in config file
Suitable for daily log analysis
Typical configuration (negative search):
ignore /test/
ignore /modprobe/
ignore /this too, and more/
watchfor /.*/
echo

Swatch "tail -f" Mode
swatch [-c <config file>] [-t <log file>]
Suitable as a tail -f replacement
Typical configuration:
watchfor /panic/
echo red
bell
watchfor /apm/
echo green
watchfor /startup|shutdown/
echo blue
watchfor /.*/
echo

Swatch Daemon Mode
Similar to "tail -f" mode, but runs in background as a System V
service
No output to stdout. Instead, only send alerts via
mail/pager/SMS/write/wall for interesting events
Typical configuration:
watchfor /panic/
mail addresses=joe,pete,subject=panic
watchfor /snort/
exec "call_pager 7654321 NIDS Alert: $*"
throttle 00:05
ignore /.*/

General Logging Tips
Log to a remote host if possible
Make sure the log traffic cannot be seen (SuSE: /dev/tty8!?) or
sniffed (separate network, encryption, ...)
Maintain raw logfiles for at least 30 days
Publish MD5 sums of raw logfiles as soon as they're closed ->
proves that no tampering has occurred since
Even better: sign them with PGP/GPG (but that cannot be done
automatically due to passwords required)
Check logfiles and swatch configuration manually every now and
then
Don't be fooled by users playing tricks on you with the logger
command

Countering Attacks
Start a network trace (preferably on another system)
tcpdump -i eth0 -w file
Start script
script attack.log
Determine source of attack
Determine target of attack
Block source address
Disable or block target service
Check for damage on system
Plug the hole
Analyze, document

Deception
Emulate well-known services with security problems
Confuse and slow down attackers
Monitor attacker behavior
Retrieve information about attackers
Various tools available:
Deception ToolKit (http://all.net/dtk)
Honeynet Project:
http://project.honeynet.org/
Collection of honeypots for trend analysis
tcpdump traces of real-life attacks on their honeypots are put up
as challenges for people interested in gaining proficiency in
analyzing attacks

1. What is a baseline?
2. In which ways can you detect an attack on your system?
3. What are the steps when someone attacks your system?
4. What is meant by deception?

Unit Summary
Make a baseline of your system
Install tools to detect attacks
React to attacks
Deception

Welcome to:
Unit 13:
Good Practices

3.1
Unit Objectives
Discuss some good practices in maintaining computer security

Computer Security is a Way of Life
Computer Security is not a project, it's a way of life
A firewall alone does not make your network secure
Should be implemented everywhere
User education
Administrator education
Program design/development/test/implementation
Network and system setup
Day-to-day production

User Education
Use good passwords
At least six characters
Not a dictionary word, name, birthdate, license plate
Not easily guessable
Change frequently
Don't write them down
Don't tell anybody your password
Not even someone who claims to be an administrator
Don't download software from the Internet
Don't run any program that was sent to you by mail
Beware of macro viruses
Don't leave computers/sessions unattended
Password-protected screensaver

Administrator Education
Follow relevant courses
Read relevant documentation/books/articles/magazines
See bibliography
Keep current on security developments
General mailing lists: CERT, Bugtraq, FBI, IBM, ERS
Specific mailing lists: Every application you use, Linux distribution
Newsgroups: comp.security.*
IRC: fnet

Custom Programs and Scripts
Design:
Can it run with just user privileges?
Can it run chrooted?
Can it bind to just one interface?
Authentication? Encryption?
Development:
Buffer overflows
Don't assume a file/message will be formatted according to the
specifications: check first
Use logging extensively (using syslogd)
Documentation
Test:
Test behavior under stress conditions
Implementation:
File/directory permissions

Network and System Setup
Do-it-yourself or preinstalled?
Secure distributions
Hardening scripts
Add-on software
Documentation
Backups
Failover/fallback systems
Defense in depth
Disaster recovery plans

Day-to-Day Operations
Monitor system behavior
Logfiles
top
baseline
Test security regularly
Prepare for attacks
Prioritize services
Who needs to be informed, when and how?
Don't rely on any service that might be compromised
E-mail
SSH
Think about the worst-case scenario
Don't chase windmills
99% of attacks are script kiddies who discovered Nessus and
nmap

Unit Summary
Computer Security is not a project, it's a way of life

Linux Administrator - Linux Network Administration II

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Linux Administrator - Linux Network Administration II

Uploaded by

Copyright:

Available Formats

Welcome to:

Linux Network Administration II:

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Traffic is only allowed from a host on the Company

Copyright IBM Corporation 2004

Packet The Internet

Copyright IBM Corporation 2004

Packet The Internet

Copyright IBM Corporation 2004

DNS Packet The Internet

Packet The DNS server in the DMZ

Copyright IBM Corporation 2004

Packet The Internet

Copyright IBM Corporation 2004

With VPN, traffic between one network

Company Network Customer Network

Copyright IBM Corporation 2004

DNS Packet The Internet

Intranet Company Network Customer Network

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Technique Intranet Server Internet Server Firewall

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Note: Please don't do this in this class...

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

This system is for authorized users only. If you are not an

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004

binary: 00001001 10000100 01111011 10000101

Copyright IBM Corporation 2004

Copyright IBM Corporation 2004