Re: How to run multiple instances of snort inline and daq and multiple interfaces (firewall)

[Stanford Prescott <stan.prescott () gmail com>]

Security onion sounds like a very nice option but is beyond the scope of
what I am trying to do which is what can I reasonably do on our firewall
distribution?

I would like to be able to use snort inline on the firewall and use DAQ to
enable the converting of sids from alerts to drops which seems more
efficient to me than our present implementation of placing the IPs from
alerts into an ipblock file.

On Wed, Mar 29, 2017 at 9:12 PM, <wkitty42 () windstream net> wrote:

> On 03/29/2017 07:14 PM, Stanford Prescott wrote:
> > Maybe I am going about this all wrong. If snort is going to monitor each
> LAN
> > interface is it really necessary for snort to also monitor the WAN
> > interface?
>
> if you don't monitor the WAN interface, how can you catch inbound attacks
> before
> they get into the firewall mechanisms? is it not best to stop the cr4p
> /before/
> it can enter the system? why waste resources transporting it all over your
> LAN(s) before flushing it?
>
> > If all traffic goes from the WAN interface to one or the other of the LAN
> > interfaces it seems that monitoring the WAN interface, too would be
> "double"
> > monitoring the same traffic?
>
> with what you appear to be attempting to do, it will absolutely be double
> monitoring... that's understandable and expected... however, if you are
> monitoring the LAN side and catch something there, you can stop it from
> getting
> out (eg: phone home malware or the exfiltration of identity
> information)... same
> for monitoring inbound traffic on the WAN interface... using bridging is
> only to
> put snort in the position of gendarme and eliminate "our" active response
> system...
>
> aside: why do you think that i've not carried "our" snort/active response
> implementation on "our" firewall product any further over all these years?
> it
> gets really deep really quickly and it is much easier to implement another
> solution for this monitoring rather than to put it all on the perimeter
> firewall... especially when solutions like Security Onion already and are
> easily
> implemented in another dedicated device like ""our"" perimeter firewall...
> trying to use snort for the same purpose as "our" active response system is
> going to be rough for one interface (the tuning and reactions are not able
> to be
> the same [eg: timed blocking]) but when you start trying to tie up to four
> interfaces into the monitoring, all hades rises up...
>
> from my previous example, you can see where a four interface setup (WAN,
> LAN1,
> LAN2, LAN3) easily becomes an eight interface setup (two per main pipe so
> that
> snort can be in the middle of them for its monitoring and dropping of
> unwanted
> traffic) and the whole thing is now four times as complicated... just
> build a
> security onion box with its own five interfaces (management plus one for
> each
> network connection to be monitored) and let it ride on the side passively
> sniffing the traffic and stuffing it into whatever database with analytical
> software is available... /then/ come up with some way for SO to talk to the
> perimeter firewall device so that it can adjust its traffic rules to block
> (or
> allow after some period of time) traffic to/from bad players... OR
> whenever it
> happens and the VMs that have been spoken about finally come to reality,
> have
> one of them as a SO VM but there's still the needed communication from SO
> to the
> perimeter firewall product to tell it to block or remove a block...
>
> > On Wed, Mar 29, 2017 at 3:46 PM, Stanford Prescott <
> stan.prescott () gmail com>
> > wrote:
> >
> > > Yes, I figured you would see me, wkitty42. Thank you for trying to
> help. ;)
> > > I did see that reference about the interfaces in colon separated pairs
> > > when using DAQ for inline mode. I am having trouble conceptualizing how
> > > that bridging works on a Linux firewall where one interface is the WAN
> and
> > > up to three additional interfaces are each a separate LAN in its own
> > > distinct non-overlapping private subnet. As with a typical NAT router
> > > firewall all WAN traffic is NATd to the appropriate LAN.
> > >
> > > My limited understanding is in order to have snort sniff and alert on
> > > traffic at each interface that multiple instances of snort running
> inline
> > > are required in order to have "bidirectional" monitoring.
> > >
> > > The present setup I am dealing with is that snort is installed on the
> > > firewall box and only sniffs traffic arriving on the WAN interface from
> the
> > > ISP or incoming traffic. Snort is unable to sniff outgoing traffic from
> the
> > > internal LANs and be able to tell where the traffic is coming from
> because
> > > by the time traffic from the internal LANs arrives on the WAN interface,
> > > snort does not have access to where the originating outgoing traffic is
> > > from.  I know that is a poor explanation, sorry.
> > >
> > > Anyway, perhaps a diagram of the flow of traffic using multiple
> instances
> > > of snort running on a firewall distro would help describe how the
> > > interfaces need to be bridged. Does anyone know where a diagram like
> that
> > > might be?
> > >
> > >
> > >
> > > On Wed, Mar 29, 2017 at 3:07 PM, James Lay <jlay () slave-tothe-box net>
> > > wrote:
> > >
> > > > On 2017-03-29 13:27, wkitty42 () windstream net wrote:
> > > > > On 03/29/2017 02:15 PM, Stanford Prescott wrote:
> > > > > > I need to know if the  multiple interfaces can all be bridged to the
> > > > > > WAN
> > > > > > interface such that:
> > > > > >  WAN eth0 <---inline snort 1 -->LAN eth1
> > > > > >
> > > > > > WAN eth0 <---inline snort 2 -->LAN eth2
> > > > > >
> > > > > > etc.
> > > > > >
> > > > > > Can it be done?
> > > > >
> > > > > i don't think it can be done like that... likely it should be more
> like
> > > > > this...
> > > > >
> > > > > WAN0(eth0) -> snort0 -> WAN0(eth1) -> current path for WAN0 to LANs
> > > > > LAN0(eth2) -> snort1 -> LAN0(eth3) -> current path for LAN0 to LANs &
> > > > > WAN0
> > > > > LAN1(eth4) -> snort2 -> LAN1(eth5) -> current path for LAN1 to LANs &
> > > > > WAN0
> > > > > LAN2(eth6) -> snort3 -> LAN2(eth7) -> current path for LAN2 to LANs &
> > > > > WAN0
> > > > >
> > > > > each snort instance has to have its own two interfaces to bridge...
> > > > > remember,
> > > > > each bridge is a dedicated tunnel from one entry point to the exit
> > > > > point with
> > > > > snort processing the data traveling through the tunnel...
> > > > >
> > > > > something else to think about: each snort should also have its own
> > > > > configs...
> > > > > some parts of the configs can be common and shared between all snort
> > > > > instances
> > > > > while others must be discrete and separate... one should also consider
> > > > > the need
> > > > > for different rules to be in effect for the different snort
> > > > > instances...
> > > > >
> > > > > eg: LAN0 may allow TOR traffic but TOR is denied on LAN1 and LAN2...
> > > > >
> > > > >
> > > > > PS: i see you ;)
> > > > >
> > > > >
> > > > > > On Tue, Mar 28, 2017 at 1:20 PM, Stanford Prescott
> > > > > > <stan.prescott () gmail com>
> > > > > > wrote:
> > > > > >
> > > > > > > I am trying to learn some of the ins and outs of snort. Is there a
> > > > > > > tutorial somewhere that outlines how to setup snort in inline mode
> > > > > > > using
> > > > > > > daq on a Linux netfilter firewall. It is a typical firewall setup
> > > > > > > with
> > > > > > > interfaces of, for example:
> > > > > > >
> > > > > > > eth0 -> WAN interface with public IP address
> > > > > > > eth1 -> 1st protected LAN interface with unique subnet
> > > > > > > eth2 -> 2nd protected LAN interface with unique subnet
> > > > > > > etc....
> > > > > > >
> > > > > > > I would need multiple instances of snort with
> > > > > > >
> > > > > > > instance1 eth0 <---> eth1 (bidirectional)
> > > > > > > instance2 eth0 <---> eth2        "
> > > > > > > etc.
> > > > > > >
> > > > > > > Thank you!
> > > >
> > > > And per the daq README:
> > > >
> > > > AFPACKET Module
> > > > ===============
> > > >
> > > > afpacket functions similar to the pcap DAQ but with better performance:
> > > >
> > > >      ./snort --daq afpacket -i <device>
> > > >              [--daq-var buffer_size_mb=<#MB>]
> > > >              [--daq-var debug]
> > > >
> > > > If you want to run afpacket in inline mode, you must craft the device
> > > > string as
> > > > one or more interface pairs, where each member of a pair is separated
> by
> > > > a
> > > > single colon and each pair is separated by a double colon like this:
> > > >
> > > >      eth0:eth1
> > > >
> > > > or this:
> > > >
> > > >      eth0:eth1::eth2:eth3
> > > >
> > > > This applies to PF_RING as well.
> > > >
> > > > James
> > > >
> > > > ------------------------------------------------------------
> > > > ------------------
> > > > Check out the vibrant tech community on one of the world's most
> > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > _______________________________________________
> > > > Snort-users mailing list
> > > > Snort-users () lists sourceforge net
> > > > Go to this URL to change user options or unsubscribe:
> > > > https://lists.sourceforge.net/lists/listinfo/snort-users
> > > > Snort-users list archive:
> > > > http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users
> > > >
> > > > Please visit http://blog.snort.org to stay current on all the latest
> > > > Snort news!
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Snort-users mailing list
> > Snort-users () lists sourceforge net
> > Go to this URL to change user options or unsubscribe:
> > https://lists.sourceforge.net/lists/listinfo/snort-users
> > Snort-users list archive:
> > http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users
> >
> > Please visit http://blog.snort.org to stay current on all the latest
> Snort news!
> >
>
>
> --
>   NOTE: No off-list assistance is given without prior approval.
>         *Please keep mailing list traffic on the list* unless
>         private contact is specifically requested and granted.
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Snort-users mailing list
> Snort-users () lists sourceforge net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users
>
> Please visit http://blog.snort.org to stay current on all the latest
> Snort news!
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!