[MLUG] [ot] Looking for high performance open source firewall

[Jean-Francois Theroux]

Having dealt in the past with DDoS and SYN attacks, I recommend the
following: don't bother. If you ever get attacked that way, pick up the
phone and call Videotron. They have the gear to filter that crap in a much
more efficient manner that you ever could. They deal with that on a weekly
basis.

It's better to block those attacks a level above you anyway. The reason is
simple, it has to be blocked before it reaches your network to be 100%
effective.

-jf

On Thu, Dec 18, 2008 at 8:32 AM, David Filion <david at filiontech.com> wrote:

>
> Just for the record, I had simplified things.  Our setup actually looks
> like:
>
>   FIBRE    FIBRE
>     ||       ||
>   CISCO----CISCO
>     \\     //
>      ||   //
>      SWITCH===OTHER STUFF ON SWITCH
>      //  \\
>     LB    LB
>     ||    ||
>     SWITCH(ES)
>     // || \\
>   S E R V E R S
>
>
> As Jen-Francois said, "Videotron doesn't allow you to terminate your
> loop into something that doesn't belong to them.  Their router is the
> demarc."  The routers belong to Videotron, I have no control over or
> access to them.  Only one fibre is active at a time, spanning tree is
> used to switch between them is one of the routers/fires fails.
>
> My goal was to try and get a synproxy setup somewhere in front of the
> load balancers so that if a syn attacked occurred,  we'd be saving our
> servers behind the load balancers from getting overloaded with SYNs.
> So far, getting more servers, breaking TCPs timeout settings,  and/or
> replacing our Linux load balancers with a version of BSD seem to be the
> only solutions.
>
> Iptables is setup on the load balancers.  Iptables doesn't help because
> it lets the SYNs go right through to the servers because it doesn't know
> the incoming SYN is an invalid SYN.  The only thing it can provide it
> rate limiting, but that is not currently an option.
>
> Seems a "drop in" solution is not in my future.  Oh well.
>
> Thanks to all that answered/suggested.
>
> David
>
>
> Andy Pintar wrote:
> > I'd say that the solution has presented itself.  As far as I see it, you
> > only have to readdress your load balancers. If you have a big block of
> IPs
> > you won't have to run NAT on your firewall.  I'm guessing it looks like
> > this:
> >
> >      FIBRE
> >        ||
> >      CISCO
> >        ||
> >      SWITCH===OTHER STUFF ON SWITCH
> >        ||
> >      LOAD BALANCER
> >      ||   ||   ||
> >          LVS
> >
> >
> > Why don't you hook up a firewall between the cisco and the switch, give
> it
> > a public IP, and forget about it?  Sure you'll have to reconfig your
> > routing a bit but all traffic will *NOT* look like it came from a private
> > IP space.  I mean, even in the basic home user NAT case where you have a
> > single dynamic IP, incoming traffic doesn't look like it's from inside
> the
> > network.  So if you have a big enough IP space and don't need NAT anyway,
> > then you won't need to run NAT with the firewall operational.  In this
> > case you can run any of the expensive ones (checkpoint) or just use PF
> > with the syn proxy on.
> >
> > Please anyone correct me if I've misunderstood/miscommunicated.
> > Thanks;
> > -Andy.
> >
> > On Wed, 17 Dec 2008, David Filion wrote:
> > ...
> >
> >> OK, I'll keep it simple.
> >>
> >> ISP's fibre comes into our server room.  It's connected to a Cisco 3xxx
> >> series router.  That router is plugged into a switch.  Also plugged into
> >> the switch in a load balancer running Linux+LVS.  The side of the router
> >> facing us is providing our live ips, it's not NATing.  I'm assuming the
> >> interface facing the ISP is a 10.0.0.0/8 or something similar.   This
> >> results in us being able to assign our live IPs to our load balancer(s)
> >> and other server as needed.
> >>
> > ...
> >
> >> I was just hoping to find something to filter out some of the garbage
> >> traffic before it hit our systems.  I didn't want to add an additional
> >> layer of NATing because to our web servers, everything would look like
> >> it came from an private IP space and not from the real client.
> >>
> > _______________________________________________
> > mlug mailing list
> > mlug at listserv.mlug.ca
> >
> https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca
> >
>
> _______________________________________________
> mlug mailing list
> mlug at listserv.mlug.ca
> https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca
>



-- 
Jean-François Théroux
Linux/network security consultant
http://www.theroux.ca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mlug-listserv.mlug.ca/attachments/20081218/d21e5f87/attachment.htm