I don't think that you would have to arp for the IP if your switches support a "sniffer port". In foundry it is called a mirror-monitor port and in cisco I think it is called a span port but the concept is the same. You configure the switch to forward all traffic from a set of ports to another port. Depending on the number of hosts on that switch you may want to put your logger on gig and the rest on 100mb. This part of it I have used extensively on Cisco's and foundry's for use with snort as a standard ids. If your switch doesn't support this capability then you may have a problem... Gino -----Original Message----- From: James Lee Bell [mailto:nuclear-cowboyat_private] Sent: Wednesday, November 06, 2002 8:38 AM To: Gino Pietro Guidi; forensicsat_private Subject: Re: Remote Syslogd I remember reading something about this as well. The (unvoiced) question I had then, as now, is what does this rig do to actual network traffic? Specifically, won't something along the way end up generating ICMP-host unreachables at some point for every log packet to the phantom logging host? Thinking this through, you know that the following hardware config isn't going to get packets pushed out the "correct" interface (where the snort box is hiding) without something ARPing for the phantom ip, a default gateway pointing inside (unlikely), or the phantom ip being some internal network that "int dev" is advertising as such. | ext dev | +-- Snort | int dev In any of these cases, at some point "int dev" is going to be generating ICMP-"something" unreachables for every single syslog packet. Or am I missing something? Gino Pietro Guidi wrote: >I have recently came across an article that described secure logging >using snort. Basically snort was configured to dump the contents of all >syslog packets sent to a fake ip. Then that ip was set up as the loghost >ip on the remote hosts. With this configuration, in theory, you wouldn't >be able to hack into it provided the snort box had no ip's on ANY >interface and simply listened. It was interesting but I haven't gotten >around to trying it yet. It sounds pretty strong to me though. I think >it was in Linux Journal that I read about it. I could probably find the >reference if anyone is interested... > >Gino Guidi >gguidiat_private > >-----Original Message----- >From: Tom Perrine [mailto:tepat_private] >Sent: Friday, November 01, 2002 10:22 AM >To: paulat_private >Cc: msconzoat_private; forensicsat_private >Subject: Re: Remote Syslogd > > > >>>>>>On 30 Oct 2002 11:18:04 -0500, Paul Timmins <paulat_private> >>>>>> >>>>>> >said: > > PT> Another option I've employed at one point is to direct security >logs to > PT> /dev/lp0 and throw a dot matrix printer with a continuous feed >of paper > PT> on the parallel port (I did this on Linux, I'm sure it works on >other > PT> OSs). > PT> Once they get into the machine, there's no way they can delete >the logs. > PT> I mean, they can move the paper back a line or two with the >epson > PT> control sequences and try to print over it, but combined with a >remote > PT> logging server, you have evidence that is likely alot easier to >prove > PT> wasn't tampered with (IANAL). > PT> My $0.02. > PT> -Paul > >We used to do that. Way back when, e.g. 1994, we hooked up a >DecWriter III (LA-120) to log all system logs that hit our loghost, to >paper. As the volume picked up, we started only logging the >authentication stuff. By 1996 or so, the volume was going through a >box of fanfold or worse every shift. > >I've often wanted to build a box that did the functional equivalent >with a CD-burner, e.g. burn log records to CD (or DVD?) in real time. > > > ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Fri Nov 08 2002 - 21:11:32 PST