Argus-2.0 Clients

[Peter Van Epp]

<snip>
> > You give me too much credit :) Since the number of TCP/IP 
> combinations is
> > almost infinite, it's really hard to say what people are going to do to
> > disguise traffic in the long run.  So, I think adding an expression filter
> > where you can specify events (as in a chain of TCP/IP packets) and an
> > action.
> 
> That's the conclusion I came to too. As I have said before, the best 
> way that argus can help with this problem is too report *all* packets 
> that don't fit into established tcp streams, cause illegal state 
> transitions or are illegal in some other way.
> 
> Another way of stating this is that it is easier to enumerate the legal 
> states (be they flag combination or state transitions) than the 
> illegal. 
> 
> hmmmm... I guess what Carter is asking for is samples of illegal 
> traffic from know tools that should be flagged so he can build up a 
> test test that can be used for regression testing.  If that is the case 
> then we need to keep it up to date as new tools and techniques emerge.
> 
> I have already volunteered to get some samples of nmap scans and finger 
> printing.  Are there any other tools which we need samples from?
> 

	Nessus, BO2k, sub7, fragrouter would be a start. Fragrouter (although
I haven't played with it yet) produces those interesting fragment types needed
to fool your typical IDS by changing ttls so some frags get lost and running
the offset count backwards to overwrite data that passed the router filters
with new data that wouldn't have etc. That would be one useful thing, keep 
track of fragment offsets and flag ones where there is offset overlap 
(especially negative) with a previous fragment. We probably want those 
complete packets out of the capture buffer. On interesting trick would be 
to steal VJ header compression from PPP. I.e if the packet matches prediction,
just count it because it isn't interesting. If it doesn't push it in to the 
exception buffer to be forwarded (given a buffer of seen packets I'd be in
favor of outputing its entire stream of packets for analysis). 
	As I said earlier I can now apparantly generate traffic at a full
100 (at least half duplex) from disk. I seem to lose packets in the kernel
at much less than full speed on capture. I want to poke at that and see if
I can get the speed up somehow (OpenBSD, the Linux experimental zero copy 
kernel, something!). I don't like any of the sniffer products I've seen so
I'm looking for something to capture at a full hundred to feed to our old
sniffer at a low enough speed it can keep up :-). Of course then everone here
went on vacation and left me all the problems :-)
	One of my many projects is to collect copies of every crack I can find
and feed them to a test bed machine and capture them with tcpdump for replay
to commercial IDS systems (and probably snort, shadow and bro) to see how well
commerical packages work (and how fast). Both the NFR and Dragon folks are
chomping at the bit to give me eval copies. That (and active directory) are
why I got my test machines. It however is still at the "think" stage due to
more urgent fires.

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada