Transcript John Kristoff - DePaul University

Computer and Network Security
John Kristoff
[email protected]
+1 312 362-5878
DePaul University
Chicago, IL 60604
IPD - November 3, 2001
John Kristoff - DePaul University
1
What are you trying to secure?
•
•
•
Confidentiality
•
•
Avoid snooping
•
Encryption?
•
•
Integrity
Deletes, changes
•
Backups
•
(D)DoS attacks
No denying it
Access control
•
Availability
IPD - November 3, 2001
•
Is that you?
Nonrepudiation
•
•
•
Authentication
Hands off!
Reputation
•
Name = MUD
John Kristoff - DePaul University
2
Internet security really bites
•
LOTS of hosts are hard to secure
•
Bad default configurations
•
Poor software implementations
•
Fixes/patches rarely applied
•
Average user/admin is security clueless
•
It is difficult to coordinate among sites
•
Any weak link can break the security chain
IPD - November 3, 2001
John Kristoff - DePaul University
3
Why doesn't telco security bite?
Telco
Internet
•
Central authority
•
No central authority
•
Network intelligence
•
End host intelligence
•
Billing records per call
•
No packet accounting
•
Legalese understood
•
Legalese fuzzy
•
Wiretapping laws
•
Privacy issues
•
Circuit connections
•
Ease of anonymity
IPD - November 3, 2001
John Kristoff - DePaul University
4
So where do you put security?
IPD - November 3, 2001
John Kristoff - DePaul University
5
Physical security
•
Trash bins
•
Social engineering
•
•
It's easier to trust a face/voice than a packet
Protect from the whoops!
•
Don't trip over the power cord
•
Don't spill your coffee
•
Hit the right switch
•
Software really can kill hardware
IPD - November 3, 2001
John Kristoff - DePaul University
6
End host security
•
The end-to-end argument
•
This is usually where the problem is
•
But, ultimately you want to protect data
•
End hosts are in control of data
•
Users are in control of hosts
•
Users often don't secure hosts sufficiently
•
There are LOT of hosts and LOTS of users
IPD - November 3, 2001
John Kristoff - DePaul University
7
Network security
•
Inspect and act on packets as they go
•
Boy, this is really hard!
•
•
Evasive tactics like tunneling get through
•
Uh-oh... encryption
•
What am I breaking?
•
Can I relay, inspect and act fast enough?
This might help, but its not a panacea
IPD - November 3, 2001
John Kristoff - DePaul University
8
Probably need layered defenses
•
The belt and suspenders approach
•
Attackers might hit a layer they can't break
•
Multiple layers tend to slow attacks down
•
Use the laws of statistics
•
If defense A stops 90% of all attacks,
•
And if defense B stops 90% of all attacks,
•
Then combined they may stop 99% of all attacks
•
(1-.9)*(1-.9) = .01, 1 - .01 = .99 or 99%
IPD - November 3, 2001
John Kristoff - DePaul University
9
The network is just a highway
•
How do you secure the highway
•
Police patrol
•
Toll booths
•
Licensed drivers
•
Vehicle inspections and standards
•
Rules of the road
•
Are the highways completely safe now?
IPD - November 3, 2001
John Kristoff - DePaul University
10
Perimeter security
"
Separate trusted net from untrusted net
"
Define the boundary
IPD - November 3, 2001
John Kristoff - DePaul University
11
What network firewalls do
•
Define untrusted and trusted boundaries
•
Inspect traffic traversing firewall boundary
•
Limit communication traversing boundary
•
Help shield insecure hosts
IPD - November 3, 2001
John Kristoff - DePaul University
12
Network firewalls illustrated
IPD - November 3, 2001
John Kristoff - DePaul University
13
Key ideas
•
Firewalls should be unnecessary
•
They're a network solution to a host problem
•
They don't solve the real problem and...
•
..make it hard/impossible to do certain things
•
Ultimate control of hosts is out of our hands
•
Securing a LOT of hosts is hard!
•
But.. network solutions are *sigh* necessary
IPD - November 3, 2001
John Kristoff - DePaul University
14
Packet filtering firewalls
•
Filter everything - not very useful
•
Filter by IP address
•
Filter by application type (TCP, UDP)
•
Filter on field/flag settings (source route)
•
Filter invalid packets (SYN/FIN packets)
•
Other pattern match
IPD - November 3, 2001
John Kristoff - DePaul University
15
Screened subnet implementation
IPD - November 3, 2001
John Kristoff - DePaul University
16
Application Layer Gateway (ALG)
•
Also commonly called a proxy firewall
•
These permit no direct communication
•
Firewall intercepts all traffic in each direction
•
Very intelligent device...
•
...must understand what a user is doing
•
Difficult to install if it doesn't currently exist
IPD - November 3, 2001
John Kristoff - DePaul University
17
Proxy/ALG illustrated
IPD - November 3, 2001
John Kristoff - DePaul University
18
Other common firewall features
•
Stateful inspection
•
Network address translation (NAT)
•
Authenticaton (VPNs)
•
Dynamic triggers
•
Reporting, logging and IDS support
IPD - November 3, 2001
John Kristoff - DePaul University
19
Example: Linux ipchains
Don't want to see packets with private IP addresses
-A input -s 192.168.0.0/255.255.0.0 -d 0.0.0.0/0.0.0.0 -j DENY
-A input -s 172.0.0.0/255.240.0.0 -d 0.0.0.0/0.0.0.0 -j DENY
-A input -s 10.0.0.0/255.0.0.0 -d 0.0.0.0/0.0.0.0 -j DENY
Let SSH, established TCP connections, FTP data, UDP and BOOTP/DHCP in
-A
-A
-A
-A
-A
input
input
input
input
input
-s
-s
-s
-s
-s
0.0.0.0/0.0.0.0
0.0.0.0/0.0.0.0
0.0.0.0/0.0.0.0
0.0.0.0/0.0.0.0
0.0.0.0/0.0.0.0
-d a.b.c.d/255.255.255.255 22:22 -p 6 -j ACCEPT
-d a.b.c.d/255.255.255.255 1024:65535 -p 6 ! -y -j ACCEPT
20:20 -d 0.0.0.0/0.0.0.0 1024:65535 -p 6 -y -j ACCEPT
-d 0.0.0.0/0.0.0.0 1024:65535 -p 17 -j ACCEPT
-d 0.0.0.0/0.0.0.0 67:67 -p 17 -j ACCEPT
Drop any packets that don't have our source IP and log those attempts
-A output -s 140.192.0.1/255.255.255.255 -d 0.0.0.0/0.0.0.0 -j DENY -l
IPD - November 3, 2001
John Kristoff - DePaul University
20
Example: Cisco ACL
Block private IP addresses
access-list 100 deny
access-list 100 deny
access-list 100 deny
ip 192.168.0.0 0.0.255.255 any
ip 172.0.0.0 0.15.255.255 any
ip 10.0.0.0 0.255.255.255 any
Block reserved, loopback and Class E IP addresses
access-list 100 deny
access-list 100 deny
access-list 100 deny
ip 0.0.0.0 0.255.255.255 any
ip 127.0.0.0 0.255.255.255 any
ip 224.0.0.0 31.255.255.255 any
Block source port of 111 from going anywhere
access-list 100 deny
access-list 100 deny
tcp any eq sunrpc any
udp any eq sunrpc any
Allow DNS and TELNET (log it) to 1.2.3.4, deny everything else
access-list 100 permit tcp any host 1.2.3.4 eq domain
access-list 100 permit tcp any host 1.2.3.5 eq telnet log
IPD - November
3, 2001
John
Kristoff
- DePaul University
access-list
100
deny
ip
any
any
21
What can't a network firewall stop?
•
Bad packets that look good
•
Denial of service (DoS) attacks
•
Well, they can stop them at the firewall
•
But then the firewall has just been DoS'd
•
Stupid user tricks
•
Things that go around the firewall
•
Things that don't cross the firewall boundary
IPD - November 3, 2001
John Kristoff - DePaul University
22
So you're saying...?
•
It would be nice if all hosts could be secured
•
Network solutions can help
•
Malicious insiders can get by anything you got
•
A holistic approach is needed. Including:
•
Audits, detection and response
•
Education
•
Standards and best practices
IPD - November 3, 2001
John Kristoff - DePaul University
23
Intrusion Detection Systems
•
Interesting, but immature technology
•
Provides lots of data/information
•
Generally doesn't interfere with
communications
•
Anything that improves security...
IPD - November 3, 2001
John Kristoff - DePaul University
24
What is IDS?
•
Ideally, immediately identifies successful attacks
•
Should have a immediate notification system
•
Out-of-band from the attack if possible
•
Probably can also monitor attack attempts too
•
Might have attack diagnosis, recommendation
and/or automated attack mitigation response
•
Lofty goals:
•
0% false positive rate
•
0% false negative rate
IPD - November 3, 2001
John Kristoff - DePaul University
25
Privacy issues
•
Does an IDS violate privacy?
•
Are packet headers (protocols) private?
•
Is identification (an address) private?
•
Are packet contents private (payload)?
•
Are communications (flows/sessions) private?
•
Where is the IDS?
•
Who manages the IDS?
•
How is the IDS data handled and managed?
IPD - November 3, 2001
John Kristoff - DePaul University
26
Storage, mining and presentation
•
IDSs can collect LOTS of information
•
What is useful data?
•
What are you looking for?
•
Data correlation within/outside of the IDS?
•
What does the admin see?
•
Where and for how long do you keep data?
•
How do you secure access to IDS data?
IPD - November 3, 2001
John Kristoff - DePaul University
27
Host IDS
•
An integral part of an end-system
•
System log monitor
•
Kernel level packet monitor
•
Application specific
•
A very good place to put security
•
Distributed management issues
•
Not all end systems will support an IDS
•
Will be as useful as the end user is cluefull
IPD - November 3, 2001
John Kristoff - DePaul University
28
Network IDS
•
An add-on to the communications system
•
Generally passive and invisible to the ends
•
May see things a host IDS cannot easily see
•
•
May not understand network traffic
•
•
Fragmentation, other host attacks (correlation)
Unknown protocols/applications, encryption
May miss things that don't cross its boundary
IPD - November 3, 2001
John Kristoff - DePaul University
29
Anomaly detection
•
A form of artificial intelligence
•
Learn what is normal for a network/system
•
If an event is not normal, generate alert
•
May catch new attacks not seen before
•
For a simple, but effective example see:
• Detecting Backdoors, Y. Zhang and V. Paxson, 9th USENIX
Security Symposium
•
An area of active research
IPD - November 3, 2001
John Kristoff - DePaul University
30
Signature matching
•
Know what an attack looks like and look for it
•
Very easy to implement
•
Low false positive rate
•
Most current IDSs are of this type
•
Easy to fool
•
Signatures must be added/updated regularly
IPD - November 3, 2001
John Kristoff - DePaul University
31
Honeypots
•
A system that welcomes attacks
•
Unbeknownst to the attacker generally
•
The system is very closely monitored
•
Can be used to test new technology/systems
•
Generally educational in nature
•
Helpful as trend monitor for that system type
•
Be careful honeypot doesn't become liability
IPD - November 3, 2001
John Kristoff - DePaul University
32
Possible IDS failure modes
•
Fragmentation, state and high-speeds
•
•
Requires lots of CPU, memory and bandwidth
Inability to decode message/transaction
•
t^Hrr^Hm56^H^H //^H -u^Hrf
•
Background noise
•
Tunnelling/encryption
•
IDS path evasion
•
Stupid user tricks
IPD - November 3, 2001
John Kristoff - DePaul University
33
The poor man's Network IDS
•
Setup a router subnet and unix host
•
Block all outgoing/incoming packets
•
access-list 100 deny ip any any log
•
Log packets (filter matches) with syslog
•
Use perl/grep/uniq/... to build simple reports
•
Total violations:
468
•
Top source host:
badguy.org
•
Top dest. TCP port:
21 (ftp)
IPD - November 3, 2001
John Kristoff - DePaul University
34
The poor man's host IDS
•
Use snort (http://www.snort.org) or...
•
Turn on all logging and do log reporting
•
Install fake service and monitor
•
•
Use diff (or equivalent), monitor file changes
•
•
tcp_wrappers, back officer friendly
Keep copies of data/configs elsewhere
Use Tripwire or equivalent
IPD - November 3, 2001
John Kristoff - DePaul University
35
Encryption or Fodszqujpo
•
Try to make something readable, unreadable
•
Usually math intensive
•
Plain text to cipher text to plain text
•
Need strong algorithms and secure keys
•
Public versus private keys
•
How do you exchange keys securely?
•
Key escrow, recovery and trusted 3rd parties
IPD - November 3, 2001
John Kristoff - DePaul University
36
Shared secret key
•
Each party knows the secret key
•
The secret key decrypts the cipher text
•
Book = Ulysses
•
Key = 7, 23, 4
•
...or page 7, line 23, word 4
•
Ulysses is the secret key, don't tell anyone!
•
How do the trusted parties learn the key?
IPD - November 3, 2001
John Kristoff - DePaul University
37
Shared secret key illustrated
IPD - November 3, 2001
John Kristoff - DePaul University
38
Public key cryptography
•
•
•
Advertise your well known public key
•
Everyone uses it to encrypt messages to you
•
Once encrypted, no one can decrypt it
Private key
•
Only you have the private key
•
Private key decrypts the public key encryption
Keyrings and secure public key distribution
IPD - November 3, 2001
John Kristoff - DePaul University
39
Public key illustrated
IPD - November 3, 2001
John Kristoff - DePaul University
40
Pretty Good Privacy (PGP)
•
Crypto software for mail, files and disks
•
Uses public (and private) key technology
•
Supports digital signatures
•
Public key servers maintain public keys
•
Free for non-commercial use
•
http://web.mit.edu/network/pgp.html
IPD - November 3, 2001
John Kristoff - DePaul University
41
Virtual Private Networks (VPNs)
•
Make an insecure public network secure
•
Use Internet instead of building your own net
•
Secure/encrypted tunnels between endpoints
•
Endpoints must be secure
•
Sound like a host security problem? Yep.
•
Many challenges and trade-offs
IPD - November 3, 2001
John Kristoff - DePaul University
42
VPNs illustrated
IPD - November 3, 2001
John Kristoff - DePaul University
43
Potential VPN problem
IPD - November 3, 2001
John Kristoff - DePaul University
44
IP Security (IPSec)
•
Standardized by IETF
•
Authentication Header (AH)
•
•
Encapsulating Security Payload (ESP)
•
•
Encrypts data before transmission
Internet Key Exchange (IKE)
•
•
Authenticates sender and packet contents
Governs exchange of keys between end hosts
IPSec is often used in VPNs
IPD - November 3, 2001
John Kristoff - DePaul University
45
Kerberos
•
Popular for network based authentication
•
Also for authorization
•
Also used to encrypt network traffic
•
Uses the concept of issuing tickets to users
•
Uses centralized server for management
•
•
Must be secure of course!
Been around for awhile, becoming popular
IPD - November 3, 2001
John Kristoff - DePaul University
46
Network Address Translation
•
Meant to be a IPv4 address depletion solution
•
NAT is wrongly applied as a security solution
•
Deployment of NAT has hurt the Internet
•
Using NAT is expensive
•
NAT breaks many things
•
If you have addresses, don't use NAT
•
I don't like NAT - can you tell?
IPD - November 3, 2001
John Kristoff - DePaul University
47
NAT illustrated
IPD - November 3, 2001
John Kristoff - DePaul University
48
Enough already, how do we hack?
•
We'll focus on over the network attacks
•
Password cracking
•
•
OS/Application attacks
•
•
Buffer overflows, cgi-bin attacks, email exploits
Protocol abuses
•
•
Brute force, keystroke capture, sniff
Spoofs, hijacks, redirects, man-in-the-middle
Denial of service attacks
IPD - November 3, 2001
John Kristoff - DePaul University
49
Anatomy of a typical compromise
•
Do some reconnaissance work, scan, probe
•
Launch the exploit
•
Maintain compromised access with backdoors
•
Fix system so no one else gets in
•
Use/abuse system
•
Make it look like you were never there
•
Sometimes a few of these steps are skipped
IPD - November 3, 2001
John Kristoff - DePaul University
50
Network scanning/mapping
•
PING, traceroute
•
DNS information
•
rpcinfo -p <hostname>
•
nmap
•
nbtstat, net use commands
•
Search engines, newsgroups, web sites
•
If you're on the Internet, you've been scanned
IPD - November 3, 2001
John Kristoff - DePaul University
51
Session hijacking
•
Pretend to be someone you're not
•
Take over or insert commands into a session
•
You may need to
•
Know IP addresses
•
Predict TCP sequence numbers
•
Keep one end of the real session busy
•
Run blind for awhile
IPD - November 3, 2001
John Kristoff - DePaul University
52
Session hijacking illustrated
IPD - November 3, 2001
John Kristoff - DePaul University
53
Password cracking
• Encrypted passwords can be broken
•
•
•
If nothing else, by brute force
•
Don't let passwords be the only line of defense
Sending logins in plain text over net is bad!
•
Many apps do this (e.g. FTP, TELNET)
•
Even HTTP!
Things like kerberos, SSL and SSH help a lot
IPD - November 3, 2001
John Kristoff - DePaul University
54
Viruses and worms
• Programs whose goal is to spread
•
...and possibly cause you a great deal of grief
•
Worms are common (e.g. ILOVEYOU)
•
Viruses infect other programs
•
Somehow code has to be executed
•
Proves users are too trusting
•
Some feature-full apps are becoming problems
•
e.g. Microsoft getting burned regularly here
IPD - November 3, 2001
John Kristoff - DePaul University
55
Weak input validation
•
Buffer overflows and format string attacks
•
strcpy(destvar, srcvar) type of stuff
•
Try to get your overflowed data to execute
•
If program was running as root/Admin...
•
...and you can successfully overflow a buffer...
•
It's probably game over for said system.
•
Remote overflows are very possible/popular
IPD - November 3, 2001
John Kristoff - DePaul University
56
Denial of service (DoS) attacks
•
Prevents or impairs standard service
•
SYN flooding
•
SMURF attacks
•
Distributed DoS attacks
•
Source address spoofing helps attacker
•
How to discern valid data from DoS packets?
•
No perfect solution exists today
IPD - November 3, 2001
John Kristoff - DePaul University
57
DoS attack illustrated
IPD - November 3, 2001
John Kristoff - DePaul University
58
DDoS attack illustrated
IPD - November 3, 2001
John Kristoff - DePaul University
59
Partial (D)DoS solutions
•
Gotta find the sources - not trivial if spoofed!
•
Ingress/egress filtering
•
ICMP traceback (itrace)
•
Packet marking (pushback)
•
Rate limiting
•
Shunning and black hole routing
•
Work with upstream provider
IPD - November 3, 2001
John Kristoff - DePaul University
60
How do I secure Windows?
•
echo Y | del c:\*.* Just kidding...
•
Keep up to date on patches
•
Run Windows Update
•
Remove unnecessary protocols like NETBIOS
•
Be very wary of running unknown programs
•
Do not use file/print sharing
•
Install and use virus protection, security tools
IPD - November 3, 2001
John Kristoff - DePaul University
61
How do I secure UNIX/Linux?
•
Remove unnecessary services
•
Empty out inetd.conf if possible
•
Start removing rc.d scripts and programs
•
Keep up to date on patches
•
Avoid RPC, wu-ftpd, BIND, sendmail
•
•
And others that continue to have probs
Use security tools
IPD - November 3, 2001
John Kristoff - DePaul University
62
How do I secure network devices?
•
Remove unnecessary services
•
Disable directed broadcasts
•
Install spoofing filters
•
Put device IP on secured management net
•
Secure routing protocols
•
Secure logs, time sync, snmp, etc.
•
Keep up to date on system software
IPD - November 3, 2001
John Kristoff - DePaul University
63
How do I secure ...?
•
Web servers
•
FTP servers
•
Mail (SMTP/POP/IMAP) servers
•
Printers, webcams, toasters
•
Others...?
IPD - November 3, 2001
John Kristoff - DePaul University
64
Any last bit of advice?
•
Use the Network Time Protocol (NTP)
•
syslog like you've never syslog'd before
•
SSH is your friend
•
Learn and make use of perl
•
Find a good mailing lists/digests/URLs
•
Know your netstat -an |more output
•
Please do not attack DePaul's network
IPD - November 3, 2001
John Kristoff - DePaul University
65
References
http://networks.depaul.edu/security/
http://condor.depaul.edu/~jkristof/
news://news.depaul.edu/dpu.security
http://www.cert.org
http://www.sans.org
http://www.cerias.purdue.edu
http://www.neohapsis.com
http://www.securityfocus.com
IPD - November 3, 2001
John Kristoff - DePaul University
66