Re: Recording slow scans

["Paul D. Robertson" <proberts () clark net>]

On Sun, 4 Oct 1998, Darren Reed wrote:

> Something that this "slow scan" business brings to mind is that there is
> now an appropriate tool to use for detecting this - NFR - although I'm

Yep, NFR seems ideally suited to the task.

> guessing more people are seeing it as a means to implement an IDS.  Is
> anyone using NFR for the purpose of generating "long" histories and then
> examining those as a whole rather than using it to look for current events ?

Not yet, but once I get the time to implement, I'm going to be doing this.

> IDS's are more into answering the question of "is someone breaking in now ?"
> and seem to provide little (if any) capability for doing real statistical
> analysis of data.  Is anyone pumping IDS or NFR data into a real database
> (Oracle, etc) for later analysis ?

I've just got Sybase for Linux (what a download!) on a home system, and I 
expect to upgrade my FreeBSD box next to it so that I can start playing 
with it.  If anyone's gotten further, I'm interested in hearing about it.

> There's one other important issue to this and that is to keep track of all
> IP and port pairs which communicate, regardless of TCP flags, etc.  Whether
> or not your paranoia requires that level of effort is another thing...

I think that if you can aggragate the data sufficiently to not run out of 
space, it's worth having around.  I'm hoping that an NFR/DB combination 
will give me that.

> Btw, in the past people have often commented about attempts to cut the
> transmit ethernet cable.  This is usually so that a host is "invisible"
> to others at the ethernet level.  A recent acquisition of mine has been
> a UTP Y-adapter (2 sockets, 1 plug) which has an interesting side-effect
> of not allowing the two machines connected into the sockets to communicate
> _directly_ but they can both use it to communicate to/through whatever is
> being plugged into.  Not perfect but an interesting toy to play with for
> these purposes.

Ah, I've been looking at just ripping the transmit code out of a kernel, 
esp. for a syslog-only host.  Static ARP that sucker and let fly.

As an aside, has anyone looked into issues for broad- or multicast syslog?  
That might make for interesting syslog redundancy and bypass the ARP issue...

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () clark net      which may have no basis whatsoever in fact."
                                                                     PSB#9280