Download TCP/IP for Security Administrators

SEC400
TCP/IP for Security Administrators
Steve Riley
Security Program Manager
Microsoft Corporation
[email protected]
Overall Event Sponsor:
Why are we here?
Copenhagen in November seems like a good
thing to do
Better than cold cloudy wet Seattle
Oh, um, er…
You’re a conference junkie and living high on
what’s left of your expense account
The venerable Mark Russinovich is here, so shouldn’t
we be here, too?
For some of us that’s a disincentive!
You are a Microsoft groupie
Well now, just who isn’t? Off with their heads!
Now be serious!
Security is (or will be) your job. Security is your life.
You are security for your org.
If you wanna be good, there are things you have
gotta know—
How to say “I don’t know”
How to say “That’s not allowed” without giving away
the fact that you really don’t know
How to look innocent—or mean—really, it’s situational
How to say “It’s not my fault” even though you
screwed up the configuration really good
How to deflect blame toward others
How to speak the language of network
communications
Protocols? IANAG!
Ah but yes you are 
Acknowledgement is the first step toward recovery
You’re in a room filled with like-minded Gs
“How do I become a security expert?”
Learn everything you can about how network
devices talk to each other
Attend more conferences like this one
Dream in TCP/IP (lucid/IP?)
Importance
Our goal today: to thoroughly understand
important network protocols (and to boldly split infinitives)
We will explore—
How the protocols work
How attackers abuse them
How to defend them
We will not—
Have any marketing content
Prepare you for passing some exam
Be entirely actionable today
But you’ll thank me later! 
The OSI model
7. application
6. presentation
5. session
4. transport
3. network
2. link
1. physical
The real world
Four layers
are sufficiently representative
4. application
3. transport
HTTP, FTP, TFTP, telnet, ping, SMTP,
POP3, IMAP4, RPC, SMB, NTP, DNS, …
2. network
TCP, UDP, IPsec
IP, ICMP, IGMP
1. interface
ARP, RARP
Presentation conventions
“A” and “B” represent networked hosts
Protocol format diagrams look like this:
0
8
element
16
24
element
Some protocol dump examples
31
element
Interface Layer Protocols
ARP
Address Resolution Protocol
RFC 826
MAC addresses are 48 bits. IP addresses are 32
bits. How to encode MAC in IP?
ARP to the rescue: resolves IP to MAC
Simple two-frame conversation
Broadcast question; unicast response
Replies kept in a cache to reduce number of
broadcasts
Cache implements timeout because addresses do
change (default 20 minutes)
ARP format
0
8
hardware type
HA length
16
24
protocol type
PA length
31
operation
sender MAC address (bytes 0-3)
sender MAC address (bytes 4-5)
sender IP address (bytes 0-1)
sender IP address (bytes 2-3)
target MAC address (bytes 0-1)
target MAC address (bytes 2-5)
target IP address (bytes 0-3)
operation: 1 = ARP request, 2 = ARP reply
ARP operation
1.1.1.1
1.1.1.2 is-at 00:11:22:33:44:55:66
1.1.1.2
ARP conversations
Normal: B saves A’s ARP info in cache, ready for replies
Other machines on same subnet also save A’s ARP
00:80:c8:f8:4a:51 ff:ff:ff:ff:ff:ff: arp who-has 192.168.99.254 tell 192.168.99.35
00:80:c8:f8:5c:73 00:80:c8:f8:4a:51: arp reply 192.168.99.254 is-at 00:80:c8:f8:5c:73
Gratuitous: reply sent before a host is asked
Often addressed to an upstream router or LB device
arp reply 192.168.99.35 is-at 0:80:c8:f8:4a:51 (0:80:c8:f8:4a:51)
Unsolicited: broadcast by host owning an IP address; usually
at boot time
Also good for detecting duplicate IP addresses
00:80:c8:f8:4a:51 ff:ff:ff:ff:ff:ff: arp who-has 192.168.99.35 tell 192.168.99.35
ARP operation
1.1.1.1
1.1.1.2 is-at 00:11:22:33:44:55:66
1.1.1.2
ARP conversations
Normal: B saves A’s ARP info in cache, ready for replies
Other machines on same subnet also save A’s ARP
00:80:c8:f8:4a:51 ff:ff:ff:ff:ff:ff: arp who-has 192.168.99.254 tell 192.168.99.35
00:80:c8:f8:5c:73 00:80:c8:f8:4a:51: arp reply 192.168.99.254 is-at 00:80:c8:f8:5c:73
Gratuitous: reply sent before a host is asked
Often addressed to an upstream router or LB device
arp reply 192.168.99.35 is-at 0:80:c8:f8:4a:51 (0:80:c8:f8:4a:51)
Unsolicited: broadcast by host owning an IP address; usually
at boot time
Also good for detecting duplicate IP addresses
00:80:c8:f8:4a:51 ff:ff:ff:ff:ff:ff: arp who-has 192.168.99.35 tell 192.168.99.35
ARP security issues
ARP spoofing
ARP replies are honored and cached, whether normal
or gratuitous
Can poison a host’s ARP cache with spoofed entries
to force redirection
Proxy ARP (routers) does this legitimately
ARP flooding (how to turn a switch into a hub)
Fill a switch’s memory with bogus mappings
Switch will flood all ports with all traffic since it
doesn’t know where hosts are
ARP Man In The Middle attack
1.1.1.1
1.1.1.2 is-at 00:11:22:33:44:55:66
1.1.1.2
ARP defenses
None built into protocol
arpwatch: Monitoring tool
Must mirror all traffic on one switch port
Switch features
Allow only one MAC address per port
Stops people from using hubs
Compare requests and replies to other mapping
information
Acquired from DHCP servers, DHCP snooping,
manual configuration (avoid)
Network Layer Protocols
IP
Internet Protocol
IP is a lousy network protocol!
Unreliable: no delivery guarantees
Send ICMP message to source if delivery fails
Connectionless: no state maintained
Datagrams routed independently and in no order
Best-effort: packets not dropped capriciously
Has one job: to route datagrams
Relies on transport layer for improvements
Hosts must implement error detection and
correction and recovery
RFC 791
IP format
0
version
header
length
8
16
type of service
identification
time to live
24
datagram length
flags
next protocol
31
fragment offset
header checksum
source IP address
destination IP address
options, if any (variable length)
(padding)
version: 4
TOS: differentiated services codepoints (no guarantee of honoring)
dg length, ID, flags, offset: for fragmentation (will examine later)
TTL: max. hops through network (decremented by routers); usually 32
next protocol: TCP, 6 | UDP, 17 | ICMP, 1 | IPsec AH, 51 | IPsec ESP, 50
header checksum: 16-bit one’s compliment of sum
options: restrictions, record route, record timestamp, source-routing
IP routing
Two types of network nodes—
Hosts
Don’t forward datagrams between interfaces
Routers
Do forward datagrams between interfaces
Hosts can be routers if appropriate software is
installed and enabled
Presents security risks
IP routing operation
search routing
Is it totable
and decrement
my IP?TTL
Datagra
m
for
1.1.1.5
9.8.7.6
1.1.1.1
1.1.1.254
network
1.1.1.0/24
1.1.1.2
1.1.1.3
1.1.1.4
Is it to
my IP?
1.1.1.5
Basic routing algorithm
Extract destination address D from datagram
Compute network prefix N
If N matches any directly-connected network address
Deliver datagram to D over that network
Else if routing table contains a host-specific route for D
Send datagram to next hop specified in table
Else if routing table contains a route for N
Send datagram to next hop specified in table
Else if routing table contains a default route
Send datagram to default router specified in table
Else declare a routing error
Route processing
routing
daemon
route
netstat
command command
UDP
ICMP
routing
table
TCP
yes
IP output:
calculate next
hop router
(if necessary)
our packet
no (one of our IP
addresses or
broadcast)?
process IP options
IP input queue
IP layer
network interfaces
IP security issues
Mostly involve spoofed addresses
Unsigned and unencrypted in the headers
Therefore: they are unreliable identifiers
Not useful for hiding IP addresses
Is useful for:
Misdirecting connections (“MITM”)
Source routing
Denial-of-service attacks (“flooding”)
Network attacks that don’t need to see responses
(“blind spoofing”)
IP checksum is not security
Attacker:
Intercepts datagram
Spoofs addresses
Computes new checksum
Intended for error detection only
A computes and adds to header
B computes and compares to included sum
If mismatch: B silently drops
Denial-of-service attacks
Let’s wait until we talk about ICMP…
Source routing
131.107.0.254
10.0.0.254
10.0.0.1
SA: <doesn’t matter>
DA: 10.0.0.1
SR: via 131.107.0.254
IP fragmentation
Some payloads might exceed physical frame size
(MTU)
IP will fragment data if necessary
Reassembled only at destination
Transparent to transport layer
Each fragment is separate datagram
(Possibly) independently routed
No delivery order guarantee
One could get lost
All fragments must then be retransmitted
IP format—fragmentation
0
version
header
length
8
16
type of service
identification
time to live
24
datagram length
flags
next protocol
31
fragment offset
header checksum
source IP address
destination IP address
options, if any (variable length)
(padding)
ID: unique for each datagram; copied into each fragment
flag1: one bit for “more fragments”; off in final fragment
flag2: one bit for “don’t fragment”; if set, IP discards datagram and
returns ICMP error
offset: from beginning of original datagram (8-byte multiples)
length: of this fragment only
Fragmentation example
IP header next hdr
(20 bytes)
(20 bytes)
IP header next hdr
(20 bytes)
(20 bytes)
payload
(1473 bytes)
payload
(1472 bytes)
IP header payload
(20 bytes)
(1 byte)
Note no TCP/UDP header!
Many firewalls will allow fragments through…hmm!
Fragmentation example
A.1234 > B.500: udp 1473
(frag 26304:1480@0+)
A > B: (frag 26304:1@1480)
frame size = 1501; must fragment
identification field
1472 (payload) + 8 (UDP header)
0 offset = beginning; + = more fragments
no port info
fragment number @ byte offset
IP defenses
Can block nearly all attacks at border
Need five rules
Block all inbound where SA in internal nets
Block all outbound where SA not in internal nets
Block all in/out where SA | DA in RFC1918 or APIPA
Block all source-routed datagrams
Block all datagram fragments
ICMP
Internet Control Message Protocol
RFC 792
IP’s “message delivery” service
Reports errors
Asks and answers questions
Encapsulated in IP
Messages might need to be routed
Considered a network layer protocol
Error reports always include first 64 bits of errorcausing datagram
Helps determine which protocol and application
caused the error
ICMP format
0
8
type
16
code
24
checksum
content (variable length; depends on type and code)
type: message type
code: sub-message type
31
ICMP messages
Type
0
3
4
5
8
9
10
11
12
13
14
15
16
17
18
Code Description
0
echo reply
destination unreachable
0
network unreachable
1
host unreachable
2
protocol unreachable
3
port unreachable
4
fragmentation needed but don’tfragment bit is set
5
source route failed
6
7
0
0
1
0
0
0
0
0
0
0
0
0
0
0
destination network unknown
destination host unknown
source quench
redirect
for network
for host
echo request
router advertisement
router solicitation
time exceeded
TTL = 0 during transit
parameter problem
IP header bad (catchall error)
timestamp request
timestamp reply
information request (obsolete)
information reply (obsolete)
address mask request
address mask reply
Code Description
8
9
10
11
12
source host isolated (obsolete)
destination network administratively prohibited
destination host administratively prohibited
network unreachable for DiffServ
host unreachable for DiffServ
13
communication administratively
prohibited by filtering
14
15
host precedence violation
precedence cutoff in effect
2
3
Query

Error



for DiffServ and network
for DiffServ and host



1
TTL = 0 during reassembly
1
required option missing








ICMP echo
0
8
16
type
code
identifier
24
checksum
sequence number
optional data (variable length)
type: 8 = request, 0 = reply
code: 0
identifier, sequence number: for matching replies to requests
data: returned to sender
31
ICMP reconnaissance attacks
“Port unreachable” = port closed
“Host unreachable” = host doesn’t exist
ICMP redirect attacks
Advise hosts of better routes
Difficult to spoof
Can come only from host’s existing DG
Must be tied to an existing connection
Can’t be used for unsolicited route table updates
Redirects generally aren’t used
Best to block them
Useful only on LANs with multiple gateways to the
Internet
ICMP DoS attacks
Ping attacks
Forged source address can create havoc when replies
arrive
Unreachable attacks
Forged messages can be used to reset existing
connections
netstat gives the attacker everything necessary to
generate messages
DDoS constellation (“smurf” var.)
Wake up!
Ping!
Reply!
ICMP scanning
ICMP’s implementation-specific responses to
certain queries helps attackers learn about a
network
Ofir Arkin’s work
http://www.sys-security.com/html/projects/icmp.html
http://www.sys-security.com/html/projects/X.html
ICMP defenses
Limit which ICMP types and codes you allow into
your network
Avoid those which are little used and have better
alternatives
Redirects
Router solicitations and advertisements
Timestamps
Don’t permit “unreachable” messages outside
your border
Let the absence of a reply imply a problem
Transport LayerProtocols
UDP
User Datagram Protocol
RFC 768
Datagram-oriented
vs. TCP’s stream orientation (later)
No transport reliability
No delivery guarantees
Some applications work better with app-level error
handling
UDP format
0
8
source port
16
length
24
destination port
31
checksum
data (variable length)
checksum: computed over source and destination IP addresses,
protocol number, length, and entire UDP packet (header and data)
UDP app responsibilities
Handle all error detection and correction
Understand size of underlying MTU to avoid
packet fragmentation
Recover from out-of-order delivery
Track communications state between peers
UDP security issues
Streaming media and VoIP often use dynamic
ports
Lack of a connection makes it difficult to
determine flows
Port loopback attack (“pingpong”)
Spoof!
from A:19/udp (chargen)
to B:7/udp (echo)
UDP defenses
Use application-aware proxies to improve
security
Don’t expose applications that you don’t need
echo
daytime
chargen
TCP
Transmission Control Protocol
RFC 793
Connection-oriented, reliable, full-duplex byte
stream transport service
Many decisions are made by the protocol, not
the applications
Segment size (amount of data per packet)
Acknowledgement of packet receipt
Retransmittal of unacknowledged packets
Resequencing of out-of-order packets
Flow control
TCP format
0
8
source port
16
24
destination port
31
sequence number
acknowledgement number
header
length
reserved
flags
checksum
window size
urgent pointer
options (if any) (variable length)
data (variable length)
seq/ack numbers: track session state; indicate which byte we’re on
flags: urgent | acknowledge | push | reset | synchronize | finish
window size: flow control
checksum: computed over source and destination IP addresses,
protocol number, length, and entire TCP packet (header and data)
TCP connection establishment
(“three-way handshake”)
B sends
sends packet
packet to
to A
A
B with:
• SYN with
set B’s SYN+1
•ACK
Destination
port number
• B’s
ISN
• ACK
with(initial
A’s SYN+1
A’s ISN
sequence
number)
TCP connection establishment
A.1037 > B.23: S 1415531521:1415531521 (0)
win 4096 <mss 1024>
B.23 > A.1037: S 1823083521:1823083521 (0)
ack 1415531522
win 4096 <mss 1024>
A.1037 > B.23: . ack 1823083522 win 4096
A’s sequence number + 1
B’s sequence number + 1
TCP connection termination
(“four-way close”)
B sends
sends packet
packet to
to A
A
B with:
• FIN with
set•ACK
with A’s SYN+1
•ACK
B’s SYN+1
•A’s next
•B’s
next sequence
sequence number
number
TCP connection termination
A.1037 > B.23: F 1415531522:1415531522 (0)
ack 1823083522 win 4096
B.23 > A.1037: . ack 1415531523 win 4096
B.23 > A.1037: F 1823083522:1823083522 (0)
ack 1415531523 win 4096
A.1037 > B.23: . ack 1823083523 win 4096
TCP connection reset
An immediate “go away”
Never acknowledged
B sends packet to A with:
• RST set
• B’s next sequence number
• ACK with A’s SYN+1
MSS (maximum segment size)
Largest “chunk” of data TCP sends
Each side announces; lower of two is chosen
Can go as high as 1460
TCP packet payload (data): 1460 bytes
IP datagram payload (TCP): 1480 bytes
Ethernet frame payload (IP): 1500 bytes
Total length: 1536 bytes
TCP security issues
SYN flooding
Consume memory with many half-opens
Session hijacking
Source-routed packets
Sniffing
Predictable sequence numbers
Sequence number prediction
SYN
ACKset
B (predicted!)
ISN
source=A
E
source=A
Huh?
SYN
RSTset
ISN A
SYN
SYNset
set
ISN
ISNBB
ACK
ACKEA
TCP defenses
Better sequence number generation
Random
Cryptographic
Changes to implementations
Don’t allocate resources until complete open
Router rules to block spoofed packets
TCP attacks are almost always spoofed
IPsec
Big improvement
Eliminates conditions that permit attacks
Authenticates peers first
Preshared key, digital certificate, Kerberos
Authenticates and optionally encrypts each
packet during the security association
Community Resources
Community Resources
http://www.microsoft.com/communities/default.mspx
Most Valuable Professional (MVP)
http://www.microsoft.com/communities/mvp
Newsgroups
Converse online with Microsoft Newsgroups,
including Worldwide
http://communities2.microsoft.com/communities
/newsgroups/en-us/default.aspx
User Groups - Meet and learn with your peers
http://www.microsoft.com/communities/usergroups
default.mspx
Microsoft Learning Security Resources for IT Professionals
Free Online Skills Assessments
Introduction to Microsoft
Security Guidance
Hands-On Instructor-Led Training
Course 2823
Managing the Deployment of
Service Packs and Security
Updates
Protecting the Perimeter of
Networks
Free Self-Paced E-Learning Clinics
Clinic 2801
Clinic 2802
Microsoft Security Guidance
Training I (1 day)
Microsoft Security Guidance
Training II (1 day)
Implementing and Administering
Security in a Windows Server
2003 Network (5 days)
Hands On Labs 2811
Applying Microsoft Security
Guidance (1 day)
Course 2830
Designing Security for
Microsoft
Networks (3 days)
Course 2824
Implementing Internet Security
and Acceleration Server 2004
(4 days)
Microsoft Certified Professional Specializations
Self-Paced Microsoft Press Reference Books
Assessing Network
Security
Microsoft Windows
Security
Resource Kit
ISBN: 0-7356-1868-2
ISBN: 0-7356-2033-4
Microsoft Windows
Server 2003 PKI and
Certificate Security
ISBN: 0-7356-2021-0
© 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only.
MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.