Andrew van der Stock

Download Report

Transcript Andrew van der Stock

litmus
a risk reduced alternative to honey pots
Andrew van der Stock
Senior Architect
esecure
Secure in a networked world
Agenda





Introduction
10 reasons why honey pots suck
Demo of dtk vs s’kiddie
10 things you can do instead
Demo of litmus and snort vs s’kiddie
Introduction



Who is that fat bugger?
Where is Australia?
How does e-Secure fit into this talk?
Andrew van der Stock





Senior Security Architect
Cat slave and MCSE (NT/2K)
Contributor to various open source
projects, such as NetBSD, XFree86 and
pnm2ppa
Immediate Past SAGE-AU President
On auDA’s DNS Competition Panel
Where is Australia?
Who are e-Secure?




They employ me, and more importantly,
they paid for me to be here
We are one of Australia’s largest specialist
security consulting firms
We don’t sell product, and we are platform
and vendor neutral
We have offices along the east coast of
Australia
Why do I think you are here?





Most of you will have excellent ITIL security
processes
All your hosts are patched and secure
Your internal staff are absolutely trustworthy
You have a large risk management group and an
even larger security group, all of whom are
extremely clueful and proactive
Your major risk is from unknown sources and
you need to know when they occur
Nothing could be more wrong



Most organizations spend far too much on
defending against the wrong risks
Some risks are over-hyped and get far too
much press
Most (>95%) organizations are not even
able to repeat a simple secure host
installation let alone trust their staff
What’s wrong with honey pots?

Greater security profile



If you can run almost every corporate network on
three visible ports, why add more?
You don’t learn anything new
All software has defects



Best practice says that software can only hope to
have as few as one defect per 1 KLOC
Normal code has 5-15 bugs per 1000 lines
dtk 0.9 has 14978 lines with comments, or 9279 lines
without comments. Do the math
What’s wrong with honey pots?



The insurance model will not allow you to
take unnecessary risks without a substantial
increase in premium
Risk management says that honey pots
increase risk for demonstrably invalid
reasons
You can learn more by using better
instrumentation
What’s wrong with honey pots?




The threat reality is that most attackers are
morons and will attack with DoS if denied real
access
Honey pots must be kept up to date but in general
aren’t
Honey pots must act like the host operating
system
Fix current problems rather than generating new
ones
Demo: dtk vs. s’kiddie
Or why out of date software is useless
Risk Management 101
Or if everyone did the right thing,
why would there still be so many
vulnerable hosts?
Guess!
Too many hosts to secure

Most operating systems and network devices are
insecure out of the box




This must change
Operating systems maintained by normal users
must be set to take care of themselves by default
Growth of the net will be the single largest factor
as to why there are so many vulnerable systems
It is unrealistic to assume that the net will ever be
safe
Risk Management
Risk  1
factors
impact  likelihood
Risk Management



Large corporations use risk management to
reduce risk to their operations
Risk management is not absolute and is not
“every risk is eradicated”
Most likelihoods are subjective



Generally expressed as “once in every x years”
It is possible to determine likelihood (insurance
companies do, for example), so you should try
Most impacts can be relatively accurately
expressed in $ per incident

The dollar figure ranges from zero to millions
Risk model
Cost of attack vs frequency of attack
f
$
Risk model – excess
f
$
Risk model – self insuring
f
$
Risk model – catastrophic
f
$
Insurance 101
Or why insurance will not reduce
famous defacements
Insurance – the SME experience
Insurance – the SME experience




Small to medium enterprises (4-100 employees)
make up the majority of all corporations
They will have little choice but to take out
insurance products once they are developed
Sometimes, there will be “no insurance at any
price” if certain things aren’t done (think GPS
trackers for regularly stolen cars, and apply…)
The excess will still be there
Insurance – Mega Corps



In large corporations, insurance is a method to
assign the risk of catastrophic events to another
entity
Most large corporations are self insuring for most
risks (for example, one of my clients simply pays
for all car accidents; it’s just cheaper that way)
Most large corporations do not see the point in
insuring an intangible risk such as a web
defacement, but they might insure good will.
Threat models
Or why a s’kiddie is more of a threat
than extremely well funded or
knowledgeable attackers
Old thinking: external threats



Old thinking: Seasoned attacker with
extreme skills will be attacking me every
time
Reality #1: s’kiddies will launch zillions of
RDS attacks at you, even though you might
be running Solaris
Reality #2: your staff are much more of a
risk than the s’kiddies of this world
Anatomy of a s’kiddie attack
Collect tools
Tag & Brag
Attack victims
Anatomy of a gifted amateur
attack
Collect tools
Develop skills
Gather info
Attack victim
Anatomy of a strong attack
Platform mastery
Gather info
Develop tools
Identify targets
Attack victim
Internet age threats



Real threats arise from people with motive
Most external attacks are simple, but not all
Most successful attacks are essentially internal
fraud


Audit controls will help
It is nearly always easier to socially engineer
from within than attack a system from without
once minimum defenses are added
Intrusion Detection Systems
Are generally useless in most
environments
Where does IDS fit?




IDS are useful as an additional layer of defense,
no more
IDS are helpful when advanced attackers are
attacking you with new attacks
Two major types today: network IDS (snort) and
host IDS (AIDE, log watcher, etc)
Missing IDS type: application IDS


eEye’s SecureIIS might be a precursor, but has been
proven flawed already
AZN-API is a useful new direction for authorization
issues
Generic issues with IDS


It’s either an AI issue or yet another system that
has to be monitored
Yet another set of logs that will be ignored




Too verbose?
Not sensitive enough?
Not enough eyes to monitor all your systems?
The “three cries and you’re out” problem

No one likes being woken up continuously at 3 am
Host IDS




Host based IDS perform a range of useful
integrity tests, such as tracking file system
changes
WinNT/2K: prefer auditing to tripwire (or maybe
use both) – auditing is real time, and you know
which user caused the event as they are doing it
Tripwire and AIDE are non-real time and only let
you know something has happened after the fact
Commercial host IDS do way more than open
source IDS today, but expect this to change soon
Network IDS





Usually has one or more interfaces in
promiscuous mode – which makes them
detectable in certain circumstances (see anti-sniff)
Useful to spot unusual traffic trends
Even with the fastest processors, most
commercial and non-commercial network IDS
cannot cope with > 100 Mb/s traffic
Good example: snort
Issue: useful only if you can monitor it and the
alarms have been calibrated to suit your needs
Application IDS



Doesn’t exist … but should!
Requires the assistance of applications to really
function correctly
Typical nascent example: eEye’s SecureIIS
product



More of a shim than real protection
A good first start, except…
There isn’t a general purpose API to implement
this, and many product writers believe that they
are writing secure software, so…
Where to deploy IDS



The typical place is in the DMZ or behind
the firewall
There’s too many lame attacks for IDS to
be out in no man’s land
Much more useful to see those attacks that
have penetrated your firewall or are in a
sensitive network
Call to Action
Or what you can do to visibly
improve your site’s security
Do the fundamentals first…



If you don’t do the basics, don’t bother
with any form of honey pot or a real IDS as
you already have many fine examples in
your production network
To prevent most s’kiddies, reduce your
security profile
To prevent real loss, improve your security
processes
Deter, Defend, Delay





Defense in depth
Deter: warning banners, low profile, high
prosecution profile
Defend: keep up to date, install security helpers
such as firewalls
Delay: keep the attacker from causing any lasting
damage
Destroy: if you can identify your attacker in real
life, if you’re big enough, you can cause real pain
to them (ie deny service if you’re a telco)
Passive Defense

Traditional security mainstays:






Firewalls
Bastion hosts
IDS
Logs
Deny all unless permitted
The above are necessary, nice and shiny, but
insufficient to cope with modern security threats
Active Defense

Counterattack




Intelligence gathering


At best – misguided. Breaking the law does not help
you
illegal in most countries with infosec laws
your ISP will dump you if they catch you
worthwhile but handle evidence properly
Prosecution


Costly but worthwhile if the scumbag is in your
jurisdiction AND you have enforceable infosec laws
(see !Philippines )
The Top 10 things you can do
If you only do one of them, do the
first one…
Keep up with patches



If your vendor ships an update to a known
vulnerability, test it and patch your hosts
Nearly all scripted attacks can be warded
off by this very simple measure
Even advanced attackers prefer to use
known vulnerabilities rather than develop
new ones
Automated Software Distribution



Without automated software distribution, you
cannot look after your hosts in a time of crisis
Test any solution you put in, including OS
upgrades (along with the requisite reboot)
Ensure that the distribution point(s) are secure,
are controlled by you, and allow you to constrain
what is deployed on your network

ie, don’t update from a local Debian mirror blindly
Business Recovery Planning




This encompasses many, many things, including
disaster recovery plans and incident response
Thinking through a fully fledged BRP will help in
times of real crisis
Include news media handling in the BRP if you
are publicly traded or rely heavily on lots of
customers
In a crisis where real damage is caused, you must
keep your customers informed and allow them to
report events to you in a timely fashion
Backups




Always have a recent backup
Always verify … there is no excuse
Keep off-sites
Practice restores diligently

use different tapes and drives to ensure that
you have media compatibility
Constantly Improve Processes

Continuous improvement is the only
acceptable option



if you use 1990 levels of security knowledge,
you will be successfully attacked
Security is a continuous process of
learning, mitigating and defending
When you learn something, incorporate it
Harden Critical Hosts


Adopt a router or switch today!
Most operating systems have various
security postures out of the box or have
third party guides to assist with lockdowns




Use them
Test the result
Come back and do it again next week
Repeat ad nauseam
Reduce Your Security Profile



Make as many DMZ or extranet hosts
invisible to the Internet
For most corporations, only three ports
need to be visible (tcp/25, tcp/80, udp/53)
Make a map of your network; you’d be
surprised at the number of exceptions. Fix
them!
Create a security policy




Adopt a security posture suitable for your
line of business and business culture
Be reasonable about it – humans will work
around any fascistic control you might
think desirable
Use ISO 17799 as a guide
Once adopted, identify systems and
processes at risk and fix them
Subscribe to security mailing lists



Not only to bugtraq, ntbugtraq,
Win2kSecAdvice, but also to your vendor’s
patch announcements
Most lists are a good source of new and
upcoming vulnerabilities
Sometimes overwhelming in terms of
volume and usefulness

Delegate someone to summarize each day
Counterattack when you can



The only legal active defense open to you is
prosecution
Learn about forensic data preservation (you
cannot prosecute without a strong chain of
untampered evidence) and practice regularly. Fix
those systems that are forensic-proof
When a s’kiddie or attacker really gets you, help
law enforcement all the way. If you get a rep as a
hard target with real consequences, hopefully
more people will stay away

This can backfire (see US Military or Microsoft)
Note what wasn’t mentioned




No mention of IDS
IDS are really only suitable once you have a
really top notch security environment and you
want an additional layer of defense
Still better to spend money on self-repairing
content checkers, backups, and other security
items
An IDS in an immature environment is worse
than the immature environment. It gives a false
sense of security where none exists
litmus





Is simply a passive configuration of IP Filter,
running under NetBSD coupled to a log scanner
for escalation
Portable to other operating systems who also use
IP Filter (OpenBSD, FreeBSD, Solaris)
Since IP Filter is IPv6 native, so is litmus
Not promiscuous – harder to detect, particularly if
you run it on hosts that actually have a function
Limited use – it’s only a litmus test
Demo: litmus vs s’kiddy
Snort is better
Conclusion



Honey pots are never the right answer for
any corporate network under any
circumstance
Judicious use of various types of IDS can
be used to some effect, but…
You must cover the fundamentals first or
you will waste money on baubles
finis
Thanks for listening.
Questions?