riel	I guess it is almost time
riel	unless you are arrigo or one of the organisers, you will no longer be able to talk here
riel	if you have questions during the presentation, you can ask them in #qc
riel	spanish translations are always in #redes
riel	this presentation is done by Arrigo Triulzi, from Switzerland
riel	Arrigo is a SANS instructor in IDS
riel	he also is CSO and co-founder of an IDS company
riel	since I don't know anything about the IDS tools for ipv6, I will be silent now ... listening to Arrigo's presentation
riel	Arrigo, the channel is all yours ;)
arrigo	Thanks riel ;-)
arrigo	So, first of all thanks to the organisers.
riel	(if you have questions or want to discuss what Arrigo says ... you can do so in #qc)
arrigo	jose_n who pulled me into this, ismak for changing the time when it messed up with ante-natal classes and riel for guidance on IRC.
arrigo	I apologise in advance for a) the mess caused by changing the time and b) the fact that I don't really use IRC
arrigo	You can get the slides for this talk from http://www.alchemistowl.org/arrigo/Papers/IDS-and-IPv6-slides.pdf
arrigo	Please be gentle, it is only an ADSL link.
arrigo	Those who want the real stuff can get the paper at http://www.alchemistowl.org/arrigo/Papers/SPI2003-IDS-and-IPv6.pdf
arrigo	The talk is actually split in two parts: one is about IPv6 and what is cool about it.
arrigo	The second is about IDS and where it should be going given that one day IPv6 will be here.
arrigo	To begin with a bit of history...
arrigo	Few people know that the first real IDS stuff was done in 1988 at UC Davis
arrigo	Somewhere in sunny California (I am told)
arrigo	It was called "Network Security Monitor" and was written for LLNL.
arrigo	This evolved into NID, always under the "control" of a chap called Todd Heberlein
arrigo	Which then became "The NIDS" for the military.
arrigo	In 1996 Stephen Northcutt et al wrote something called Shadow.
arrigo	Shadow had the interesting peculiarity (by modern standards) that it was based on two things:
arrigo	1) full-fidelity (i.e. collect every packet you see)
arrigo	2) lots of semi-trained personnel
arrigo	Basically the packets came in, they were all stored and through some simple filtering "interesting stuff" came out.
arrigo	This was sent to "operator consoles" which were nothing other than elisted personnel trained to see simple patterns.
arrigo	If they saw a pattern they would "escalate", i.e. press a button and send the packets off to Stephen & Co.
arrigo	They solved the "false positive" issue by throwing manpower at it which is pretty much the standard answer of the military to any
arrigo	So what followed?  Well, pretty much everyone and his dog wrote an IDS (even I did!)
arrigo	But quite a few of the lessons learned in Shadow were lost in the process.
arrigo	On a similar historical note IPv6 has been around for a long time.
arrigo	The first RFC is dated 1990 (RFC1550) asking for ideas for IPng
arrigo	(At the time I was still reading e-mail with UUCP...)
arrigo	The first actual version was published in RFC1883 (1995)
arrigo	and then the world sat on it...
arrigo	The image portrayed by IPv6 is that of something that "will come eventually", with standards still in flux (e.g. AAAA and A6)
arrigo	A trivial example:  I have been accepting SMTP over IPv6 since December 2001.
arrigo	So far I've had about ten SMTP connections via IPv6...
arrigo	That isn't exactly Earth-shattering numbers for a server which handles about 100Mb mail/month.
arrigo	So, what's so special about IPv6?
arrigo	A simplified header, a laaaarge address space, authentication and encryption from day 0, simplified routing, no checksums and no frags
arrigo	Most people read this list and say "so what?"
arrigo	Well, let us begin from the header.
arrigo	The IPv4 header was designed to pack as much information as possible into it.
arrigo	This meant using every bit and then counting on the TCP/IP stacks to decode it by suitable bit shifting and masking.
arrigo	This was all very well when CPUs were mostly CISC and good at this jiggery-pockery.
arrigo	But on a RISC chip actually taking an IPv4 header apart is not funny.
arrigo	For those with a bit of knowledge of Alpha chips you should try and get a sneak at the source for the TCP/IP stack in Tru64 Unix.
arrigo	It is not pretty, nor is the assembly which comes out of it.
arrigo	So the cunning plan for IPv6 was to align everything as much as possible on 32-bit quantities.
arrigo	For those with my PDF slides page 6 is a pretty comparison.
arrigo	The larger address space is a bit of a given and they decided to pre-partition it.
arrigo	That means that even without whois you can make educated guesses.
arrigo	There is also an apparent organisation in the address space in the form of TLA (Top-Level-Aggregators)
arrigo	I say apparent because only time will tell if it is any better than the old Class A,B,C of IPv4.
arrigo	More interesting is support for what is effectively IPsec.
arrigo	The idea is that if you want authentication then you slap onto your IPv6 header an "authentication header" (AH) as an "extension".
arrigo	Then everything after the AH is authenticated in the same way as IPsec AH (RFC2402 for the pedantic)
arrigo	Want encryption?  Same trick: extension ESP header.
arrigo	A minor note is that the ESP need not be the first extension header after the IPv6 header.
arrigo	You might have some routing or frag extension headers first for some reason and only encrypt the final payload.
arrigo	That's RFC2406 for the pedantic...
arrigo	Quick word on routing - classless from day 0.
arrigo	And no checksums in the header! Why? Well, if you want a checksum then you want a real one and you should use AH.
arrigo	Otherwise the protocols (TCP, for example) already checksum the data.
arrigo	No point in spending hours checksumming.
arrigo	Finally fragments: if you want frags then you need an extension header.
arrigo	The base IPv6 header doesn't support fragments.
arrigo	This means you don't need to carry around extra weight if you never fragment.
arrigo	Now that we've rushed through IPv6 let's talk IDS.
arrigo	For starters I am only talking about NIDS, i.e. Network-based IDS.
arrigo	I would like to discuss the following: white-listing, ubiquity, data management, network knowledge and finally deployment on IPv6.
arrigo	First of all whitelisting.
arrigo	Almost all current NIDS use blacklisting as the way the rules are written.
arrigo	That is to say that you define "badness", for example "all incoming traffic from the Internet on port tcp/137 is bad".
arrigo	Or, "any packet to port 25 containing the string WIZARD" is bad.
arrigo	and so on.
arrigo	The last time I counted there were about 2000 rules in Snort.
arrigo	Now, if I write a new attack which uses the Sendmail MSP port do you have a rule?
arrigo	No, you don't because you haven't seen my attack yet!
arrigo	So happy users of any IDS with standard rules are completely blind to any new attack.
arrigo	And if I am smart enough and don't circulate my attack then a lot of the world will remain vulnerable for a long long time.
arrigo	So the point is that with blacklisting: if you don't have the rule then you don't catch anything.
arrigo	Now think of a night club.
arrigo	The bouncer at a night club has a list of authorised guests.
arrigo	If you are not on the list you don't get in.
arrigo	Which is exactly how firewalls should work, incidentally.
arrigo	So why do IDS systems attempt to list every single person _not_ allowed in the night club?
arrigo	If the real world worked like that you would have a list with a few billion names.
arrigo	So the point I am making is that badness is an infinite concept - there will always be a new blacklist rule.
arrigo	And, as a corollary, you will never catch a 0-day xploit with blacklisting rules.
arrigo	What should really be done is to configure your IDS to pass traffic which is known-good.
arrigo	And alert on everything else.
arrigo	At this point I normally get lots of shouts from the audience telling me I am a cretin.
arrigo	Which is of course quite possible.
arrigo	But the point is the following: if you don't know your network well enough to be able to define acceptable traffic flows then you
arrigo	The other amazing discovery is that the number of authorised flows is _much_ smaller than you think.
arrigo	So writing whitelisting rules is just a boring job.
arrigo	Why don't people do it?
arrigo	Because it is terribly boring.
arrigo	Let me describe two options:
arrigo	1) you get the lab of your dreams, packed with kit, you get to try xploits all day and write rules to catch them.
arrigo	2) you get to stick a laptop on each segment and run tcpdump. Then collate the data and write whitelisting rules.
arrigo	Which option do you take?
arrigo	Incidentally, riel asked: "it would require updating the IDS for many different new network protocols, though"
arrigo	That is true but in theory you don't have new protocols being installed on a continuous basis.
arrigo	And in theory you should also control their deployment on your network...
arrigo	Another question from riel: "would it be possible to automatically train a whitelist ?"
arrigo	riel suggests using bayesian filters (like Spamassassin for me ;-))
arrigo	I don't see why not.
arrigo	It sounds like a perfectly viable thing to do _if_ someone wrote the code to do it.
arrigo	It would definitely remove the problem of people getting bored writing whitelists...
arrigo	The key advantage with whitelisting is that you stop playing catch-up all the time.
arrigo	And you have a sporting chance of getting 0-day exploits.
arrigo	The next issue is that of ubiquity.
arrigo	At the moment people install a NIDS box outside their perimeter.
arrigo	And then look at the packets.
arrigo	But the biggest problem is that of people crying wolf from their IDS data because they cannot see the context.
arrigo	When I get alerts on my Snort boxes I spend more time looking at other logs (Squid, Apache, etc.) than breaking up the packet.
arrigo	For example about two years ago I spent two days trying to understand why Demon Internet in the UK was attacking my box on a daily
arrigo	It turns out that one of their DNS boxes was in fact behind a buggy load-balancer whic then sent back all sorts of rubbish.
arrigo	This gets even worse when to understand the extent of a problem you really need, for example, to know about traffic behind your
arrigo	If you only have one IDS box you will never know!
arrigo	So another little thing I've been working on is Differential Firewall Analysis.
arrigo	You stick an IDS before and after each firewall.
arrigo	You program the IDS with the same rules as the firewall.
arrigo	If a packet gets through which theoretically violates the firewall rules you get an alert.
arrigo	Why is this useful?  Well, all the firewall vendors (esp. the commerical ones) tell you that their firewalls are "secure".
arrigo	But if there is a bug in their rule engine they don't normally send a message to the logs with "sorry, the rules engine went fut and
arrigo	They are nice and quiet.
arrigo	So something got through and you don't know.
arrigo	Oops.
arrigo	So this isn't just a fix for badly interpreted rules (writing rules more than once in different lingos helps) but also for downright
arrigo	A good reference is to ask the happy owners of Cisco PIX or Checkpoint FW-1...
arrigo	The other point is that you need to monitor all your sites.
arrigo	I was helping out a company a while back and they had a marvellous IDS at their main Internet link but nothing at all their satellite
arrigo	But of course there was a VPN between them all.
arrigo	So you break into the branch office, then VPN into the main office and the IDS is blind.
arrigo	Finally when you have IDS sensors placed all over your network the neat trick is that you can start correlating.
arrigo	For example: if there is a surge in port 80 traffic you don't need to see the packets to tell that there is a problem.
arrigo	If the problem is all over your network then perhaps this is a DDoS attack.
arrigo	Similarly for Port 25 outbound - it could well be a new Outlook virus...
arrigo	But if you don't have data collection points everywhere then you cannot perform the correlations.
arrigo	So the bottom line is: "see the bigger picture".
arrigo	What next?  Data management.
arrigo	There is too much data.
arrigo	Which means that nobody looks at it.
arrigo	On average the first day everyone goes "cool, I have an IDS, I want to see the logs".
arrigo	The second day "oh, it is a bit boring".
arrigo	The third day "ah, yes, I'll look at the logs tomorrow".
arrigo	By the end of the week "IDS? Ah, yes, in the corner there".
arrigo	So not only do you have too much data but nobody looks at it.
arrigo	Fine situation when you want to detect intrusions...
arrigo	The other problemette is when you get 40,000 alerts.
arrigo	If they are all the same all that does is drown the useful data.
arrigo	If you don't see the single attacks underneath you make the wrong decisions and nuke the wrong IP.
arrigo	Oops.
arrigo	What is needed is a data-reducton system.
arrigo	If you have 40000 identical alerts then surely you should get a single alert and a pretty message saying "you have 40,000 of these
arrigo	Similarly if you have 10 IDS sensors why do you keep all the logs separate?
arrigo	Surely having all the information in one place is a good idea?
arrigo	Once it is all in the same place you can finally perform  historical analysis.
arrigo	and more sophisticated pattern matching.
arrigo	To make it all work you also need to understand the network you are defending.
arrigo	A classic is an IDS which continues alerting on Nimda on a networ which has only Apache web servers.
arrigo	What is the point?  Why is the rule there?
arrigo	If you don't run IIS then all those rules do is slow down the IDS engine.
arrigo	A NIDS should escalate and handle alerts based on the context - an Apache alert against an Apache server is more of an issue than an
arrigo	On top, if you are a large company you should send the alerts to the right people!  I've seen places where the alerts go to absolutely
arrigo	The first thing that happens is "ah, not my problem, X will look at it".
arrigo	Pity that _everyone_ says the same thing so the alert drops on the floor.
arrigo	The next problem is that the Unix guy doesn't see a Unix alert because it is in the middle of all the Windows alerts which he doesn't
arrigo	Really efficient.
arrigo	Simply splitting the alerts with grep made them about 100% more productive!
arrigo	Finally severity.
arrigo	If you call every alert "red" then red becomes normality and nobody jumps any more...
arrigo	So you need to set up appropriate escalation.
arrigo	Good question has just come through...
arrigo	m101 says: "all your ways to fix the problem are a bit more complicated than your general idiot admin would probably understand, and
arrigo	Well, there was an answer...
arrigo	The answer was that the system I designed and built did exactly what I've been talking about now.
arrigo	Disadvantages: 1) price tag @ $1M a pop (hardware + software)
arrigo	2) we didn't sell a single one since 2000 :-)
arrigo	So, there is a solution but at the moment it is too expensive.
arrigo	The other solution is that in theory this could (and should) be done by MSS (Managed Security Services) providers.
arrigo	They could deploy arrays of sensors into customers and perform all the relevant analysis.
arrigo	Counterpane in the USA is doing it, although not to the extent I have been describing.
arrigo	Now we move to IPv6...
arrigo	Before we do so I have a cartoon, courtesy of jose_n, which is required viewing: http://www.ibiblio.org/Dave/Dr-Fun/df200306/df20030604
arrigo	Why the cartoon?
arrigo	Well, very simply put one of the ideas behind IPv6 is that there will be enough addresses to give every square metre of the Earth
arrigo	So companies are thinking of "Internet enabling" stuff like fridges, washing machines, etc.
arrigo	The small problem is: when all your Kelvinator (or Miele or whatever your brand) fridges have the same vulnerability what happens?
arrigo	What happens is that it is quite possible for millions of embedded systems, Internet connected, to be used to attack you.
arrigo	What about patching you ask? <maniacal laugher>  yeah, right.
arrigo	Like windowsupdate?
arrigo	So someone redirects it somewhere else and all the fridges are loaded with FridgeRootkit 1.0 automatically?
arrigo	Basically it is an insoluble problem, at least with current technology.
arrigo	So you need to start doing IDS _now_ not wait until IPv6 is all over the world.
arrigo	To do so you don't need much:
arrigo	1) a Linux or *BSD box with an IPv6 stack.
arrigo	2) either a friend to drop you a bit of IPv6 address space of an IPv6 tunnel (see, for example, Hurricane Electric)
arrigo	Even better: just do it internally, then if you make a mistake nobody will ever know!
arrigo	Put real services on the systems.
arrigo	Like Apache, SSH, Sendmail
arrigo	Start sending traffic through and use tcpdump to learn about it.
arrigo	Are the IPv6 NIDS systems?
arrigo	Yes, there is a Snort experimental branch.
arrigo	So far I've not had anything interesting on my IPv6 link - why? Because script kiddies haven't learned about IPv6 yet.
arrigo	Or at least they haven't been able to download a nice rootkit from somewhere to do it for them :-)
arrigo	The structure of IPv6 is such that it is actually easier to write an IDS yourselves than for IPv4.
arrigo	I use libpcap happily without any problem and do the decoding myself (in C).
arrigo	When you've written it you should try to play something nasty against it.
arrigo	I wrote a simple tool for this called iploonie
arrigo	which generates random packets for both IPv4 and IPv6.
arrigo	You can get it from http://www.alchemistowl.org/arrigo
arrigo	You play them back with tcpreplay and see what happens to your IDS.
arrigo	Guarantees hours of fun.
arrigo	Now, a few observations:  IPv6 eventually will be here and it won't be as "sysadmin friendly" as IPv4 before Windows had a TCP/IP
arrigo	It has a nicer structure which means two things: you can make IDSes faster but more data will be pumped your way.
arrigo	There is also going to be the issue of loads of encrypted data (ESP) which is going to be easier to send.
arrigo	This means that you need to come up with a nice trick to decode that.
arrigo	If you are in a company the only way to do it is:  hardware crypto accelerator, snarf keys from the keyserver.
arrigo	So your IPsec gateway has a modified ISAKMP server which sends a copy of the private key to the IDS.
arrigo	Not Nice(tm) but so far the only way.
arrigo	Similarly for Apache + SSL.
arrigo	As more and more traffic becomes encrypted (at least in the dreams of the implementors of IPv6) it will be more and more difficult to
arrigo	And that will mean that your security people will become more and more blind.
arrigo	There is a much worse downside.
arrigo	The IDS systems on the market are beocming _less_ sophisticated?
arrigo	Why?  Because they have to be used by anyone.
arrigo	As m101 remarked earlier that is the main problem.
arrigo	IDS is too sophisticated
arrigo	Then install it on a box
arrigo	For those in the EU look
arrigo	http://www.privacy.org/pi/i
arrigo	This then becomes the Data
arrigo	It actually mandates that
arrigo	It doesn't actually say
arrigo	[Note: link broken, try
arrigo	[Note: the EU link is
arrigo	So in Italy, for example,
arrigo	But they are in compliance
arrigo	And if that sounds stupid
arrigo	So the bottom line is: as
arrigo	The only serious IDS
arrigo	Well, that's pretty much
arrigo	Any questions?
Vegas	clpa clap clap clap clap
Zippo	gracias....
Night_Cra	well done
Night_Cra	nice
MJesus	clap clap clap clap clap
MJesus	clap clap clap clap clap
MJesus	clap clap clap clap clap
MJesus	clap clap clap clap clap
Norwat	cool
Vegas	thanks really much arrigo
Vegas	it was really interesting
Aerian	thx for all arrigo
garoeda	clap clap clap clap clap
MJesus	clap clap clap clap clap
MJesus	clap clap clap clap clap
MJesus	clap clap clap clap clap
Loco_dmc	really very very interesti
arrigo	Thank you folks - bit
aktin0s	really interesting talk
MJesus	the question are at #qc
m101	your time was much appreciated
arrigo	Feel free to reach me at
MJesus	Muchas gracias arrigo !
Rothen	hi
jcea	thanks for the tank, arrigo
jcea	taLk
jcea	:)
arrigo	I wish I had a tank to
qkolnek	thanks for the time

Generated by irclog2html.pl 2.1 by Jeff Waugh - find it at freshmeat.net!