Download Techniques for and Conquences of Packet Filtering, Interception

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

TCP congestion control wikipedia , lookup

Computer security wikipedia , lookup

Piggybacking (Internet access) wikipedia , lookup

Asynchronous Transfer Mode wikipedia , lookup

Multiprotocol Label Switching wikipedia , lookup

IEEE 1355 wikipedia , lookup

Computer network wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

RapidIO wikipedia , lookup

Net bias wikipedia , lookup

Airborne Networking wikipedia , lookup

Network tap wikipedia , lookup

Zero-configuration networking wikipedia , lookup

Distributed firewall wikipedia , lookup

Packet switching wikipedia , lookup

Deep packet inspection wikipedia , lookup

Wake-on-LAN wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Transcript
Techniques and Consequences of
Packet Filtering, Interception
and Mangling
John Kristoff
[email protected]
EDUCAUSE SPC 2015
John Kristoff
1
Editorial Note
What follows is largely based on personal perspective
and interpretation of the topic, likely an imperfect one. I
don't expect to be exhaustive nor authoritative, but
simply to provoke discussion and challenge dogma.
EDUCAUSE SPC 2015
John Kristoff
2
Underlying Assumptions
•
Our communications system is packet-switched
•
The entire system is a set of autonomous subsystems
•
At least some communication between subsystems is
desirable
EDUCAUSE SPC 2015
John Kristoff
3
Assumption #1 – Packet Switched
•
Perhaps no longer obvious, but there are alternatives
•
Advantages may include:
•
•
Economical use of resources
•
Network path flexibility
Disadvantages too:
•
Access control and accounting functions diluted
•
Grazing of the commons phenomenons
EDUCAUSE SPC 2015
John Kristoff
4
Assumption #2 – Autonomy
•
There is very little central coordination
•
Even where there is, little legal enforcement of it
•
Bottom line, each subsystem is a little different
•
•
… and the lowest common denominator is too low
But this diversity can be good, especially for capitalists
EDUCAUSE SPC 2015
John Kristoff
5
Assumption #3 – Interconnection
•
Islands of communication systems are of limited utility
•
You might be able to live without it, but probably won't
•
There is a strong desire and need to limit, but not
eliminate interconnection, but see assumption #1
EDUCAUSE SPC 2015
John Kristoff
6
Packet Network (Internet) Canon
•
End-to-end Arguments in System Design
•
The Design Philosophy of the DARPA Internet
Protocols
•
Perhaps a small subset of IETF RFCs and related
presentations
•
Early influences: Baran, Kahn, Cert, etc.
EDUCAUSE SPC 2015
John Kristoff
7
End-to-end Arguments
in System Design
•
Argument / Principle / An Approach
•
Where “functionality” best located in the system?
•
Conversely, where might it might undesirable?
•
It argues for moving functionality outward and upward
•
“A great deal of information about system
implementation is needed to make this choice
intelligently.”
•
Thought experiment: What does e2e say about
dealing with DDoS attacks?
EDUCAUSE SPC 2015
John Kristoff
8
Misleading E2E-inspired dogma
•
The stupid network
•
NAT #@*&!
•
Network-based security (e.g. firewall) is unnecessary
•
( __ fill in the blank __ ) contradicts the e2e model
EDUCAUSE SPC 2015
John Kristoff
9
Snappy security comebacks to
network transparency
•
Our users do not need to use that feature/function
•
I have never seen that used for anything legitimate
•
We've blocked it and no one has complained
EDUCAUSE SPC 2015
John Kristoff
10
Network people, Security people
Generally network people don't like perturbing packets
once they are put into the communication system.
Generally security people want to be able to do all sorts
of things with packets at any point in the system,
especially at obvious subsystem boundaries.
EDUCAUSE SPC 2015
John Kristoff
11
Packet perturbation
•
Traditionally, packet switch devices essentially just:
•
•
Perform route look up and forward packets
Technically they could and often do much more:
•
Filter on any arbitrary combination of packets bits
•
Rewrite packet contents based on a set of rules
•
Alter forwarding behavior based on some bits
•
Impersonate / hijack an end of the communication
EDUCAUSE SPC 2015
John Kristoff
12
Other per-packet operations
•
Network devices might also:
•
Log, copy or summarize packets for monitoring
•
Discover, reverse engineer and maintain e2e state
•
React to exceeded thresholds
EDUCAUSE SPC 2015
John Kristoff
13
LAN bridges/switches
•
Operate at Layer 2 (L2)
•
Typically this means Ethernet
•
source address, destination address, type
•
Learning (source address)
•
Forwarding decision (destination)
•
Could act on type field, but not commonly done
•
What are the trade-offs of additional functionality?
EDUCAUSE SPC 2015
John Kristoff
14
IP routers
•
Provide end-to-end communications between subnets
•
Minimal functionality is similar to LAN bridges/switches
•
Forwarding based on destination (an id an locator)
•
Some parts are rewritten at each hop
•
TTL (hop limit) and checksum
•
More fields at this device's disposal
•
Examining more fields and more layers isn't free
•
Keeping track (“state”) of packets is inherently difficult
EDUCAUSE SPC 2015
John Kristoff
15
IP routers
•
Provide end-to-end communications between subnets
•
Minimal functionality is similar to LAN bridges/switches
•
Forwarding based on destination (an id an locator)
•
Some parts are rewritten at each hop
•
TTL (hop limit) and checksum
•
More fields at this device's disposal
•
Examining more fields and more layers isn't free
•
Keeping track (“state”) of packets is inherently difficult
EDUCAUSE SPC 2015
John Kristoff
16
Consider IPv4
EDUCAUSE SPC 2015
John Kristoff
17
Middle Box
•
Something in the network with additional functionality
•
Here we can only infer or make generalizations
•
Per-packet examination
•
Note: Minimal IPv4+TCP header ~ 1.72 x 10^69
possible packets
•
•
Yes, we can reduce this significantly
•
IPv4 address + protocol + port ~ few quadrillion
Has your IPS/PacketShaper/Firewall even fallen over?
•
Now you know why, they will never fully scale
EDUCAUSE SPC 2015
John Kristoff
18
But, Default Deny!
•
The problem space can be significantly simplified
•
Many fewer combinations of things to permit than deny
•
Maybe
•
Even if you allow just one protocol and one port
•
You still have 4 billion+ addresses to worry about
•
You can do it, but it isn't as simple as you may think
•
You've also severely eliminated functionality
•
You'll also see apps/people “route” around obstacles
EDUCAUSE SPC 2015
John Kristoff
19
Port blocking
•
Many problems associated with “troublesome port”
•
Simple solution, block the port at the border
•
Do you block the destination port, source port or both?
•
Is the port ever used for anything else?
•
•
If for no other reason, thanks to NAT/NAPT, yes
Consider DNS, NTP and web server communications
EDUCAUSE SPC 2015
John Kristoff
20
What happens when a legit app
has its port blocked?
•
Mail - time out, retry later, eventually works
•
DNS – time out, retry later, eventually works
•
WWW – timeout, probably fails until user retries
EDUCAUSE SPC 2015
John Kristoff
21
Traffic “shaping”
•
Alter TCP window
•
ACK pacing
•
Adjust Inter-packet gaps
EDUCAUSE SPC 2015
John Kristoff
22
Intrusion Prevention
•
Real-time response to active communications
•
Responses may be adaptive to rate or behavior
•
IPS often impersonate an end
EDUCAUSE SPC 2015
John Kristoff
23
Why do we prefer network-based
security solutions?
•
Easy and quick to deploy (control!)
•
Easier to sell
•
Works for well defined problems and average cases
EDUCAUSE SPC 2015
John Kristoff
24
Has the packet mangling helped?
•
Impossible to quantify
•
But some anecdotal evidence shows mixed results
•
Comparing two networks I know
•
No obvious or practical security benefit either way
•
The packet mangling averse network has far fewer
network-wide problems
EDUCAUSE SPC 2015
John Kristoff
25
An updated network canon?
•
Can we reconcile e2e with all this mistrust?
•
I don't see an easy way forward
•
Eventually an entirely new model may be needed
•
There aren't really any serious, radical ideas here :-(
EDUCAUSE SPC 2015
John Kristoff
26
Well that sounds like bad news
•
In the meantime...
•
What are your network's guiding principles?
•
If you had to do it over, what would your network
look like?
•
There are alternative approaches to security
problems without whack-a-moling magic bit
combinations
EDUCAUSE SPC 2015
John Kristoff
27
Example Areas of Discussion
•
•
Instead of banning a port (application) outright:
•
Provide users with restricted / open option
•
They will often choose restricted
Push packet mangling outwards and upwards
•
•
•
When a border middle box fails, it hurts everyone
Improve your tool set and your ability to use tools
•
Can you disable a port / address automatically?
•
How much TCP port number X traffic do you have?
How do you deal with DDoS?
EDUCAUSE SPC 2015
John Kristoff
28
My Closing Argument
•
Packet mangling often just makes our job harder
•
There are multiple approaches to network security
•
•
Packet mangling isn't necessarily best
•
It is an expedient solution
Try to solve a network security problem without packet
mangling sometime
•
It can be hard initially, but is often a good ROI
EDUCAUSE SPC 2015
John Kristoff
29
The End
EDUCAUSE SPC 2015
John Kristoff
30