On Sat, 27 Feb 2016 12:54:52 -0800 David Christensen <dpchr...@holgerdanske.com> wrote:
> On 02/27/2016 10:40 AM, Reco wrote: > > > > On Sat, 27 Feb 2016 09:41:47 -0800 > > David Christensen <dpchr...@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
