Techniques and Consequences of Packet Filtering ... · EDUCAUSE SPC 2015 John Kristoff 16 IP...

EDUCAUSE SPC 2015 John Kristoff 1

Techniques and Consequences of Packet Filtering, Interception

and Mangling

John [email protected]

mailto:[email protected]


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.


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


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


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


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


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.


End-to-end Argumentsin 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?


Misleading E2E-inspired dogma

• The stupid network

• NAT #@*&!

• Network-based security (e.g. firewall) is unnecessary

• ( __ fill in the blank __ ) contradicts the e2e model


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


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.


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


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


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?


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


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


Consider IPv4


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


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


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


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


Traffic “shaping”

• Alter TCP window

• ACK pacing

• Adjust Inter-packet gaps


Intrusion Prevention

• Real-time response to active communications

• Responses may be adaptive to rate or behavior

• IPS often impersonate an end


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


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


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 :-(


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


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?


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


The End

Date post:	10-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Techniques and Consequences of Packet Filtering ... · EDUCAUSE SPC 2015 John Kristoff 16 IP...

Documents