[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian as My home firewall/router



On Sat, 27 Feb 2016 12:54:52 -0800
David Christensen <dpchrist@holgerdanske.com> wrote:

> On 02/27/2016 10:40 AM, Reco wrote:
> >
> > On Sat, 27 Feb 2016 09:41:47 -0800
> > David Christensen <dpchrist@holgerdanske.com> wrote:
> >>
> >> 1.  Where can we learn about the features the OP wants, and how to
> >> implement them in Debian?
> >
> > The only way way to learn all features the OP wants is to ask OP
> > himself (or herself, I cannot make it from the alias used).
> 
> The OP stated he is looking for firewall, network interface management, 
> NAT, VLAN, and DNS.  I believe Debian can do all of that, and more.

I agree on that. They did not call Debian the Universal OS for nothing.


> >> 2.  Where can we learn about the features that you say IPCop is missing
> >> and/or the problems that you say IPCop has?
> >
> > First, a good firewall host should not have anything that's unrelated
> > to its' primary function (i.e. filtering, routing, *maybe* tunnels). How
> > exactly a GUI font library and a bunch of assorted fonts are related to
> > this primary function is anyone's guess.
> >
> > Second, one should not re-invent the wheel on privilege escalation.
> > Ditching a good instrument for this (sudo) in favor of own homegrown
> > suid binaries is a fine example of bikeshedding, if you ask me.
> >
> > Third, a lack of DNSSEC support opens all kind of abuses for DNS
> > entries. Hence, if such host is to be used as FTP/HTTP/HTTPS gateway
> > (the presence of Squid in the distribution suggests such possibility),
> > the clients of such gateway can be lead anywhere given at most one
> > malicious DNS server on the outside.
> >
> > Fourth, any host that communicates to the outside world will be
> > compromised. It's only a matter of time. Such time can be extended by
> > applying security updates *and* configuring some sort of mandatory
> > access control (SELinux for example).
> >
> > Fifth, any host that communicates to the outside world will be
> > compromised. It's important to know how and when it'll happen. Hence
> > the need of IDS.
> 
> I've posted a link to this thread on the ipcop-user mailing list. 
> Hopefully, someone knowledgeable in IPCop will respond here.

Thank you for your effort, we'll see how it goes from here.


> > As for the Sourceforge itself - its reputation is forever tainted after
> > this:
> >
> > http://tech.slashdot.org/story/15/06/01/1241231/sourceforge-and-gimp-updated
> >
> > No amounts of "we're screwed up, sorry", "we're selling the site" will
> > fix it.
> 
> I vaguely remember that event.  The crux would seem to be whether or not 
> the software license allowed modification (including the distribution 
> file).  And, if so, whether or not the distributor (SourceForge) 
> identified the files as modified.  If the author answered "no" to the 
> first question, then the software is not "free" (as in freedom).  If the 
> author answered "yes" and SourceForge answered "no" to the second 
> question, then shame on SourceForge.  If both the author and SourceForge 
> answered "yes", then you accept the modification by downloading the 
> modified file.  If you want an unmodified file, then you need to get it 
> somewhere else.
> 
> As the saying goes, Caveat Emptor.

My point exactly. How am I supposed to trust a GNU/Linux distribution
if it comes from such a source?


> >> 3. What is your opinion of pfSense?
> >>
> >> 	https://pfsense.org/
> >
> > I'm by no means an expert on FreeBSD (from which pfSense is derived) so
> > I suggest to search more educated evaluation elsewhere.
> 
> I ran pfSense briefly on the Internet connection for my SOHO LAN.  There 
> are differences between BSD vocabulary and Linux vocabulary, but 
> functionality is pretty much the same.  pfSense seemed more 
> sophisticated and featureful than IPCop, but more brittle.

Now you picked my curiosity. In what ways pfSense is "more brittle"?


> > I suspect that pfSense lacks any meaningful mandatory access control
> > pre-installed (no *BSD family has it), but that's it.
> 
> According to McKusick [1], p. 34, "FreeBSD implements a framework for 
> kernel access-control extensibility, the MAC framework".

So it's so called capiscum framework. A nice sandbox effort, but it's
nowhere near SELinux capabilities. A direct analogy from the Linux
world is seccomp.

If they use it in pfSense - that's good. The main question is - how
meaningful is the use of this framework pfSense has?


> >> 4.  What is your opinion of Firewall Builder?
> >>
> >> 	https://sourceforge.net/projects/fwbuilder/
> >
> > Don't need it personally for two reasons.
> >
> > First, distributed firewall management based on iptables is not that
> > different from distributed management of any GNU/Linux OS. Hence
> > there are puppet or chef to fulfill this role.
> 
> I don't have enough machines to justify Puppet, etc..  I've done 
> iptables, etc., by hand in the past, and it was tedious.  Firewall 
> Builder mets my needs very nicely.

If it met your requirements, and did it correctly - it's a nice tool.
For me, I guess that if you have puppet - everything looks like a
puppet recipe :)


> Thank you for the information.  :-)

You're welcome.


Reco


Reply to: