Transcript Session Code Title of Presentation

SEC 470
Using ISA Server for Application
Layer Firewalling
Frederico Baumhardt
Senior Consultant – Infrastructure and Security
Microsoft UK
Call to Action
• A quantum shift in thinking is needed to
avoid a cataclysmic failure in global
network security
• I don’t have all the answers in this
session, lots of questions
• We have all been lucky major global
worms have not carried class 0 (evil evil)
payloads like format disk and flash BIOS
• Question all “experts” you hear and draw
your own conclusion
Agenda
•
•
•
•
•
The roots of the Internet and security
The problem with conventional firewalls
Advantage of application layer inspection
Application inspection with ISA server
• Pre-authentication (OWA + IIS + Apache)
• Inbound SSL termination and inspection
• Filtration of HTTP content and URLs
• Other Application Filters
Putting it all together
Internet Security Roots
• Lets be honest – from a security perspective:
IPv4 is not great – not designed for Security
• The Internet used to require Security clearance to
•
use – physical access was restricted – no need
for protocol security
Resistance to Nuclear attack was more important
than protecting traffic
Everyone on the network was trusted
•
• TCP/IP was thus designed without security in
mind – added as a bolt-on
Typical Protocol Security Evolution
• Protocol suite created – TCP/IP
• We invent some sort of security (IPSEC)
• We run out of addresses so we NAT instead of
CIDR (NAT apparently is better security )
• NAT breaks IPSEC
• So we argue over standard to encapsulate NAT
traffic in UDP (fix IPSEC) – NAT-T emerges
• We then say IPSEC could be insecure as traffic
cant be inspected – whitepapers confirm both
views as accurate and definitive
Tunneling
• When someone puts some sort of data in
one port/socket– encapsulates it in some
sort of packet – and sends it do a
destination you allow (because you think
it is doing something else)
• Example – HTTP-TUNNEL.com where
you stick your terminal service traffic
(otherwise blocked)- in TCP 80 and for
19.95 a month, they send it to the server
you really want to talk to.
Demonstration of Tunneling
Some Common Network Security Myths
• People play by the rules (we trust our users)
• Internal Users are always nice – outside bad
• People will always use ports as a statement
of intent (TCP 80== HTTP – right ??? )
• I shouldn’t allow encrypted traffic through my
firewall (as it cant inspect it)
• Tunneling through one port is far more
secure than opening several others
But Its OK – I got a Firewall…
• False – fake – and irrelevant sense of
security to people who don’t understand
security (big boss says FW=Sec job done)
• ALF is not big enough to most customers
• Most firewalls don’t protect internally –
conventional wisdom is you don’t have to
• End to End Security – and encryption
invalidates most FW and IDS
But an expert told me….
• Not to bother with firewalls or
segmentation – they don’t work
• VLANs aren't useful as they cant
guarantee total segmentation
• Performance cant keep up
• IPV6 is coming, and it will be harder to
firewall that wont it ?
• Listen to what we all have to say. Draw
your own conclusions
Lets Rip open a packet
• Currently – most firewalls check only basic packet information
• Real world equivalent of looking at the number and destination of
a bus – and not looking at the passengers
Fundamental Assumptions L3/L4
• We trust that traffic on a port is what we think it should
•
•
•
•
•
be (TCP80==HTTP)
We implicitly trust that the traffic going through is
clean (as we admit we cant scan it)
We don’t place these devices to protect from internal
networks as our users are trusted
The user in machine 1.2.3.4 must be the one that
always uses that machine
TCP 80 is almost always open to everywhere – The
Universal Firewall Bypass and Avoidance Protocol
Most of these mistakes result in a security breach
which is usually blamed on the OS, or the app – but
came over network
Security and HTTP
• We assume that HTTP is good business
•
•
•
•
protocol–block almost all others outbound SO:
Developers start using tunnelling over port 80to deliver apps and data- call it web services
Microsoft does it with Outlook and Exchange
2003 – we call it a feature (easy Outlook Conn)
Joe Smith tunnels and uploads your HR
database to your competition – you call him a
hacker
More concerned at blocking porn (by dest) than
checking that the content is valid (by deep insp)
OK Guys, how would you do it ?
• Some keys to application inspection
• Segmentation of Logical Components in network –
•
•
ALF can only inspect to/from somewhere
Encryption only where required – with trusted
context – it usually invalidates inspection, IDS
Understanding the purpose of the traffic you are
trying to filter, and blocking non consistent traffic
• Strategic depth-countermeasures covering entire
•
classes of attacks, especially against worms
Heuristical systems supplemented with
behavioural systems, and intelligence
RPC – A typical ALF challenge
RPC 101
Client accesses
Client connects
application
over to
portmapper
on server
Client knows
UUID port
learned
(port 135/tcp)
of service it wants
Portmapper responds
Client asks,
“What
with the
port and closes
port is associated
the connection
with my UUID?”
4402/tcp
135/tcp
Service
234-1111…}
RPC client
(Outlook)
Port
Exchange
UUID
4402/tcp
{12341234-1111…
AD replication
{01020304-4444…
3544
MMC
RPC server
{19283746-7777…
9233
4402
(Exchange)
Serverto
matches
UUID to nature of RPC, this is not
• Due
the random
the current port…
RPCfeasible
services grab
random
over
the Internet
high ports when they start,
64,512table
high ports & port
serverAll
maintains
•
traditional firewalls
135 must be opened on
RPC Filter Security
Learn the protocol and use its features to improve security
• Firewall only allows specific UUIDs
• Only DC Replication, or Only Exchange/Outlook
• Not defined UUIDs such as MMC, Printing blocked
• Takes back control of RPC behaviour
• Tunneling not allowed – as syntax is checked
• Exchange specific – like enforce client encryption
RPC
External
network
Exchange
/ RPC
Server
Internal
network
ISA Server with
Feature Pack 1
Outlook/
RPC
Client
Protecting HTTPS
Basic authentication
delegation
URLScan
for ISA Server
ISA Server can
Webinspect
server
for stop
ISA Server pre-authenticates
URLScan
for ISAprompts
Server can
decrypt
and
authentication
— any edge,
users, eliminating multiple
…which
allowsatviruses
Web
the network
SSL attacks
traffic
URLScan
Internet
user for
can SSL
dialog boxes and only allowing
andeven
worms
to encrypted
pass
over
this prompt
valid traffic through throughaccess
undetected…
ISA
Server
SSL
SSL
SSL or
HTTP
Internet
client
Traditional
ISA
Server with
firewall
Feature
Pack 1
Web
Srv/
OWA
SSL tunnels through
traditional firewalls
inspected …and
traffic infect
can beinternal
sent toservers!
the internal
because it is encrypted…
server re-encrypted or in the clear.
Pre-Authentication
• No L7 password = no access to internal system
– excellent failsafe
• Potential attackers go from 7 Billion to the number
•
of people who have credentials to your network
Worms will not have your credentials (hopefully
)
• ISA 2000 can also do this by RSA secure ID for
HTTP (though not for RPC/HTTP with sec ID)
• Cookie means also under development by
market
Protecting HTTP and (S) cont.
The Big Picture
• Understanding the protocol – how it
works, what its rules are, and what to
expect is critical
• Inbound HTTPS termination is easy (you
control the cert) outbound is difficult
• Human behaviour is easy – FW admins
close all ports so we use 80, thus we
need to learn now to filter 80
Web Publishing Protection (DNS)
• Worms usually go by IP or network range, they
seldom know the FQDN (yet)
• Publish by FQDN https://mail.yc.com/exchange
• Nothing gets in unless it asks firewall for the exact
•
URL (in HTTP language) not just
212.30.12.1@TCP80
Nimda, CodeRed etc, would not have infected my
ISA server systems that published FQDNs
Use URLScan in ISA to filter more sophisticated
•
• Next Generation HTTP filtration is on the way,
use it when it arrives
Web Publishing FQDN filtration
•Run the Nimda Attack
Vector against this – does
it work?
•Viruses don’t do reverse
lookups (yet), they also
don’t usually ask for an
explicit path
•Only something asking for
exchange.lkm.ch/exchange
will be connected
•Powerful and simple
DNS Protection
• Rudimentary
protection
• General antitunneling
protection
through T/U 53
Mail Protection
• Lots of Antispam and antivirus vendors cover
the relay points- what about:
• IS TCP 25 really SMTP?
• Is someone sending a buffer overflow to the
RCPT: command ?
Can I block someone using the VRFY command ?
Can I strip an attachment, or block a user
•
•
• Why not do the Protocol level protection at the
network device, use the firewall to add a layer
of defence for the mail system.
Mail Filtration Examples
• Requires another box
to do the storage of
mail
• Must link the box to
ISA via RPC
• Applies Protocol
validation and some
keyword and
attachment stripping
• Def in Dep – not
primary mail solution
Encapsulated Traffic
• IPSEC (AH and ESP), PPTP etc can not
be scanned at ISA server if published or
allowed through
• If you tunnel traffic through these ports
ISA will log the tunnel – can not look
inside
• Your call – open more ports with app
filters or tunnel traffic through with no
inspection – most DC protocols have no
filters
• Be aware of the implications of NAT
Extending The Platform
• Firewalls are placed in different locations
for different reasons. Understand the
requirement and filter accordingly
• Extend core functionality with protocol
filters covering your specific scenario
• No one device will ever be the silver
bullet, solutions are more important than
devices
One Vision for Secure Networking
Internet
Redundant Routers
First Tier Firewalls
URL Filtering for OWA
RPC Termination for Outlook
ISA Firewalls
NIC teams/2 switches
VLAN
Intrusion Detection
VLAN
.
Intrusion Detection
VLAN
Intrusion Detection
VLAN
Front-end
DC + Infrastructure
Backend
One or more Switches Implement VLANs and Control Inter-VLAN Traffic like
Firewalls do – VLANs are not bullet proof (but neither are servers)
Traffic is allowed or blocked based on requirements of the application, filters
understand and enforce these requirements
Debunking Network Security Myths
• People DON’T play by the rules – unless you make
•
them and ports are not intent – you need to check
Hardware devices are NOT more secure – they are
more convenient – that’s all
• Invest in getting to know the device, what it can/t do –
don’t buy what you know – buy what you need
• Don’t let just the network people control and
•
purchase firewalls – it takes application awareness
We will increasingly need the performance of
software devices to handle the traffic coming
evaluations
© 2003 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.