Transcript 13-secure-networks-3

SECURING NETWORKS: ADDITIONAL TOPICS
EN.600.424
Lecture Notes
Fall 2016
LET’S TALK ABOUT FIREWALLS
•
History:
• Gateways already required
• Gateways often define a natural change in security context
• The Gateway was a natural place to put security (Firewall)
•
Purpose:
• Informally (e.g. “marketing”), a firewall:
• “prevent modern threats”
• “block threats”
• More formally: enforce security policies on network traffic
REMEMBER, “SECURITY” IS MEANINGLESS
•
Firewalls, like every other tool, don’t “create security”
•
Consider the marketing descriptions
• What is a “threat”?
• What does it mean to “block”?
• They advertise IDS, but IDS is after the fact. Is that “blocking”?
•
As a security professional, how would you even evaluate these claims?
ENFORCING POLICY
•
Firewalls, like every other tool, are useful to the extent they can enforce a policy
•
Corollary: You can’t really secure a system if you don’t understand your policies
•
Forget firewalls for a minute, what security policies might you like to have?
• Example 1: No malware can enter the network
• Example 2: No unauthorized external networki services
• Example 3: External network services accessible only by authorized users
•
Once you have a policy, you can start looking for enforcement mechanisms.
LIMITATIONS OF IMPLEMENTATIONS
•
Policies should be implementation agnostic
•
HOWEVER, if a policy cannot be enforced, modified policies may be required
• I’ll call these “pragmatic” policies
• They depend on the “ideal” policies and should reference them
• Should still be implementation independent, even if implementation influenced
EARLY FIREWALL ENFORCEMENT
•
The first firewalls were LAYER 3 (IP level)
•
They could not enforce any of the ideal policies of the previous slide
•
However, assuming that legitimate users only come from pre-specified IP’s
• We can develop a pragmatic policy that approximates the ideal policy
• “Only traffic from authorized IP’s is permitted into the network”
•
Still not much you can do about the other two policies
LAYER 4 ENFORCEMENT MECHANISMS
•
Firewalls naturally enforced layer-3 because of gateway functions
•
But soon, they were modified to examine layer-4 as well
•
Enforcement of authorized services:
• Example: block all incoming traffic except to port 80 (web)
•
This is still used today. How effective is it?
• Doesn’t deal with reverse connections
• Doesn’t deal with a non-web service running on port 80
• Doesn’t deal with a non-web service encapsulated within HTTP
• But, it is a well understood enforcement mechanism for a well understood policy
EARLY APPLICATION LEVEL FIREWALLS
•
Layer-4 firewalls typically shut down all inbound ports, except those specified
•
This had the side effect of breaking two-port protocols like FTP
•
Soon, people started using “application proxies”
• An FTP Proxy would operate at the gateway/firewall
• It would forward an incoming FTP connection to the correct internal computer
• It would listen to the communication and dynamically open up a second port
• In other words, it was explicitly application protocol aware
• Sometimes called, “dynamic fw”, “content aware fw”, “application layer fw”
CONTENT INSPECTION
•
Soon, people realized that you could use this protocol scanner to enforce policies
•
For example, it could enforce access controls on FTP
• User A can read/write
• User B can read
•
These features were soon being built into the firewalls directly
•
Sometimes called
• “dynamic firewalls” (any firewall with dynamic rules)
• “content aware firewalls”
• “application layer firewalls”
CONTEMPORARY FIREWALLS
•
Although content inspection is twenty years old, extensive use is recent
•
Most modern firewall corps (Juniper, PAN, Cisco, Fortinet, and others)
• Provide a unified interface to specify layer-3, layer-4, and layer-7 rules
• Use custom hardware to make layer-7 inspection close to wire-speed
• (Layer 7 sometimes called “deep packet inspection”, or DPI)
• DPI also enables integration with malware scanning, IDS, and IPS
• Often market subscriptions to threat and protocol signatures
LIMITATIONS OF IMPLEMENTATIONS STILL
•
Consider, “No malware can enter the network”
• No known technologies can enforce this.
• Truthfully, we would probably need a more formal definition of “malware” anyway
• Identify pragmatic policies:
• No known malware can enter the network
• All network traffic is recorded and stored for 30 days
• Previously unknown malware is identified within 30 days of detection
STILL TOO BROAD?
•
Even these “pragmatic” policies are probably too broad.
•
How about these?
• No known malware can enter the network over unencrypted channels
• This can be enforced by:
• DPI on all incoming traffic
• If not known/allowed protocol, REJECT
• If tunneling protocol, decapsulate
• Perform content scanning
SECURITY FUNCTIONS ARE NOT POLICY
•
Even though you need enforcement of policy,
•
Even though implementation may influence policy,
•
Implementation is NOT policy
•
For example, blocking port “X” is not a policy.
• Resist management pressure to use a feature as a policy
• Focus on identifying the real policy, and how the feature enforces it
•
This is especially important because Firewalls are becoming swiss army knives
• One company even calls their device a “universal threat management”
• Most have VPN, virtual routing/switching, web portals, user authentication, etc
IDS: MITIGATION AND FUTURE PREVENTION
•
IDS stands for Intrusion Detection System
•
IPS is Intrusion Prevention System
•
IDS is far more common because IPS is just too hard (false positive and false negatives)
•
IDS assumes the attacker has already won
• The attacker has already succeeded in his objective and left (forensics)
• The attacker is in the system, but still moving toward a higher target (mitigation)
SIGNS OF BAD BEHAVIOR
•
Anomalies: unusual network traffic
• Port scanning (recon)
• Unusually large data transmissions (buffer overflow, etc)
• Unexpected traffic between machines
•
Surprisingly, this is still very much signature based
•
Various products have attempted to do statistics modeling but usually too noisy
IDS TYPES
•
Network Based IDS (NIDS)
• Monitor traffic on the network (often using the gateways/routers)
•
Host Based IDS (HIDS)
• Monitor traffic received at a host, and the effect thereof
• Sometimes helpful in simply monitoring the encrypted traffic
•
Hybrid systems
• Deploy host components and network componets
• Report all data back to a central server/dashboard
HONEYPOTS
•
An interesting IDS component
•
Create a fake system to draw attacker attention
•
Introduces components whose entire operation is an anomaly
TYPES OF HONEYPOTS
•
Low Interaction – port only, record traffic
• Purpose: logging
•
Medium Interaction – simulated/emulated service
• Purpose: delay/confuse
•
High Interaction – real services on real computers with real operating systems
• Purpose: maximum analysis of attacker behavior
•
Honeynet – multiple honeypots working together
•
Specialized variants:
• Malware Honeypots
• Spam Honeypots
DEPLOYING HONEYPOTS
•
Now part of larger “Enterprise Deception Operations” initiatives
•
Which type of honeypot makes the most sense?
• Perhaps counter-intuitively, “low interaction” for corporate
• “high interaction” for research
• In the corporate world, may be related to SLA (reaction time, not detail matters)
•
But all of this should come back to the security policy, should it not?
IDS AND SECURITY POLICY
•
What policy does IDS (including honeypot) enforce?
•
For many (all?) ideal policies, none. The attacker has already violated a policy.
•
Perhaps you could think of it as a meta-level policy (policies about policies)
•
Or, you could think about it as “enforcement-after-the-fact”
• That is, how quickly can we get back to compliance?
NETWORK HARDENING
•
What is “hardening”?
•
One company (trapx) defined these areas of hardening:
• Configuration is appropriate for the job
• O/S and applications are “up-to-date” to “stay ahead of attack code”
• Contemporary and ongoing
•
How big of a deal do you think configuration is?
CONFIGURATION NIGHTMARE
•
Trapx notes the following statistics:
• Network devices have, on average, 2000 lines of configuration code
• Device configs include hundreds of parameters across 20 IP-based protocols
• A Fortune 1000 enterprise can have over 50 million lines of configuration code
•
And gives these examples:
• The hardening guide for Oracle Solaris v11 has 55 critical configuration items
• The vmWare guide for vSphere 5 highlights 60 critical security items
• For Windows 2008, minimal system hardening includes 158 settings that need to be
immediately secured out of the box
WHAT ARE WE TRYING TO ACHIEVE?
•
“Hardening” is really marketing speak.
•
Generally, it’s synonymous with reducing attack surface
• Closing un-used ports
• Shutting down vulnerable applications
• Disabling unnecessary functionality
• Ensuring that an application is as up-to-date as possible (fewer vulnerabilities)
HOW IS THIS RELATED TO POLICY?
•
Don’t make the mistake of treating these kinds of things as policy.
•
Generally, you don’t have a policy that says, “Patch applications within 1 hour of release”
• What is the actual security policy you want to enforce?
• “No unauthorized access of services”
•
As another example, don’t have a policy that says, “No unnecessary ports open”
• What is the actual security policy you want to enforce?
• Still probably, “no unauthorized access of services”
• Although, you may want, “System does not provide any unauthorized services”
•
Don’t harden just to harden (making hardening the policy)
•
Harden to reduce how much enforcement of policy is required
CONCLUSION
•
We’ve discussed three different network security concepts today
• Firewalls
• IDS
• Hardening
•
But in all cases, their use should depend on policy
• Firewalls can enforce policy
• IDS can after-the-fact enforce policy
• Hardening can reduce the difficulty of enforcing policy