[Snort-users] Snort with three interfaces attached to diferent network segment

Bennett Todd bet at ...6163...
Wed Jun 18 12:39:17 EDT 2003

2003-06-18T14:02:53 artiman at ...9501...:
> I just have one machine to monitor the activity on three diferent
> network segments (Redhat 9), so I plan to to install 3 NIC on the
> snort machine, setup the interfaces on promiscous mode without IP
> information and start to listen each segment, [...]

Not too atypical a setup. Many of us would have N+1 interfaces, so
we could have a numbered interface for remote management and for
emitting alerts; this one might live on a fairly tightly secured
admin LAN segment in the firewall plant.

> [...] I'm kinda worried for the security implications because I'm
> creating a physcial path between the Internet, DMZ and MZ zones,
> so in theory there is a small probablity of bypass the Firewall
> using the snort machine.

Yup. Snort has had security problems in previous versions, which
might have been in principle exploitable (I don't know if any of
'em ever got exploits actually coded and used in the wild), and if
an attacker could (a) craft an exploit, (b) arrange to deliver it
across one of your snorting interfaces, and (c) have the payload
either set up a remote-control connection of some sort back, or
mount additional attacks outbound, your scenario would come to pass.

Linux's routing code won't route packets out an unnumbered
interface, but in theory the payload could include libnet or
something like it to send packets out a raw interface bypassing the
normal OS networking code.

> Can somebody explain what is the risk that I'm facing using this
> architecture, How can I make sure 100% that the Linux will not
> route packet between different segments, In wich ways a Hacker can
> exploit my network ???

Many of us would rate this risk as quite low, since a successful
breach would require a pretty big payload, but the possibility can't
be ruled out in theory.

The risk can be further lowered by making sure you use some
appropriate software configuration management strategy --- I favour
rpm packaging myself --- to simplify automating updating your
software, and aggressively tracking and deploying security bugfixes;
as long as such bugs are discovered by whitehats and fixes shipped
before exploits make it into the wild, you can avoid getting

But if you want to reduce the risk right down to zero, 100% perfect
guaranteed security, the choice I'd recommend is network taps.
There are many vendors, I haven't heard anybody say anything bad
about any of 'em, I've personally worked with Netoptics gear, and
been pleased both by their product and by their support. Taps aren't
that expensive, and they make it truly impossible for a compromised
piggie to send packets back out onto these DMZs you're touching.

Other hacks could make such an exploit harder to the point of
being completely improbable; e.g. a modification to the kernel
to prohibit sending over these interfaces. This would require
an additional level of work for an exploiter to get around the
barrier. Combined with running snort as a non-root user, and you'll
force the attacker's exploit payload to exploit some local root bug
to escalate privs enough to then bypass your OS mod. Chroot the
snort and that's vastly harder, if not impossible. Strip suid bits
off every program on the system and ensure that no files outside
snort's logdir are writeable by snort and it's starting to sound
pretty nearly impossible that an exploit could bypass a modified
kernel that wasn't willing to send packets.

But a kernel is a complex beast, and so is a snort.

It's easy to get close enough for any context I can imagine with
software tweaks and config details, but I can't see making a
guarantee that it's really 100% perfectly impossible to break across
the snort box from one DMZ to another without external help. Taps
are simple, and that's why they can achieve a higher level of trust.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20030618/a6f63367/attachment.sig>

More information about the Snort-users mailing list