Hi. On Mon, Feb 29, 2016 at 05:42:26AM -0300, Renaud OLGIATI wrote: > Having posted Roco's comments on an IPCop list, I got these comments
Neat. I'm lazy to post my comments there, so I'll keep'em here for the sake of completeness. > Hi Ron, > > On Sun, 28 Feb 2016, Renaud (Ron) OLGIATI wrote: > > > Would any IPCop guru care to comment ? > > I wouldn't call myself an IPCop guru, but (as you know) I've been using > it a while and occasionally I modify it and build my own versions of it. > I've sometimes had ten or a dozen IPCop firewalls active at once, but I > only run three or four at the moment. They've all been installed more > than a decade. Despite a large number of attacks, none has failed me. > I run one Smoothwall box, and I can say the same about it as about IPCop. > I'm not saying there's nothing better, but I'm not feeling the need to > rush out and find something better. So, to sum it up - a distribution user, not a developer. Nowhere a bad thing, mind you. > > Reco <.....@gmail.com> wrote: > > Well I guess you didn't mean me to comment on this, but my business > doesn't accept mail from gmail accounts. If I need to do business - I have several another e-mails. GMail was suitable for Debian maillists so far. > >> 1) No meaningful DNSSEC capability. > > Neither, to my knowledge, has any UK bank, and none of my customers > has ever heard of it except from me. My customers think that if my > tiny business uses DNSSEC but their bank doesn't, then I must crazy. > (And one of my major suppliers has *two* SPF records, but I digress.) > > There's no need for IPCop to do much more than route DNSSEC packets. > All my nameservers run DNSSEC and two of them are behind IPCop firewalls. > See also my reply to Reco's 4) below. Ah, my favorite "I don't need it = nobody needs it" motto. How quaint. Still. dnsmasq by itself has the ability to query and verify SPF *if* it's built with DNSSEC support. Deliberately disabling it during the compilation *lowers* overall security. Correct way to do it is to enable DNSSEC and have the distribution user to decide if it's needed or not. The real value of this comment, of course, is don't trust any UK bank with your money. > >> 2) Presence of libfontconfig.so *and* fonts for no good reason. > > I'm sure that there are bigger nits to pick than this one. ??? Sticking a random library into distribution without any meaningful way to remove it is a wrong way to talk about overall distribution security. Especially if the library is known to have some vulnerabilities in the past. > >> 3) Bunch of questionable quality root-owner SUID binaries in > >> /usr/local/bin, intended to be called from Web-interface. > > To something as nebulous as this I can make no useful reply except > that (a) I very rarely use the IPCop Web interface, and (b) on my > IPCop boxes, nobody else on the planet ever uses the Web interface > (nor a shell). Sly, but does not improve overall quality of said binaries in any way. Nor the quality of design decisions that lead to putting those binaries instead of conventional privilege escalation mechanisms in the first place. > >> 4) Lack of any pre-installed IDS. > > I think Reco's 2) above was intended to imply that features == security holes > and I would agree with that; so this seems like schizophrenia. No. See parallel part of this thread for the real explanation of the need of IDS. > >> 5) Outdated kernel 3.4, configured *without* SELinux, Apparmor or tomoyo > >> support. > > I'm still using kernel 2.4.36 without all that, and I'm quite > comfortable with things as they are. I like to avoid the latest > and greatest (especially Debian latest and greatest, vide infra). My only comment on this is - I hope that such position is a rare exception along the users of this fine distribution. Because the only meaningful way to interpret such statement is - 'I know that the distribution does not care about my security, and I don't care too'. > >> ... suggesting putting *this* to serve as a firewall from an Internet is a > >> joke. > > Perhaps Reco will tell us how many IPCop boxes he's compromised, Exactly zero. Such activity is a punishable criminal offence where I live. Even if I did - I would never admitted it. > or he's seen compromised, Exactly zero. Here we refrain from using solutions of questionable security quality in matters requiring actual security. > or heard rumours might have been compromised. And that part is really interesting. You see, dear list, a really good distribution tries to play it nice once it is known that a part of distribution is affected by known security vulnerability. They make security advisories. They go to popular mailing list (bugtraq, for instance), and publish such advisories for anyone to see. They fix what's broken, after all. Because the bird is out of the cage already, and the best one can do is to update. A bad distribution is going into 'lalala-cant-hear-you' mode. > And given Reco's tone, I also wonder if he can remember this: > > https://www.schneier.com/blog/archives/2008/05/random_number_b.html > > after which I found several of my own Debian-generated private keys > published on the Internet. Thankfully I was pro-active enough not > to suffer any compromise as a result, but it didn't have to be so. And that part is really interesting too. Of all real security troubles that affected Debian in past 10 years that person choose a really old one that's actual Debian fault. Not bash's Shellshock (IPCop is using cgi-bin). Not openssl's Heartbleed (sshd is there). Not recent GNU libc's DNS troubles (IPCop is using plain GNU libc). And I find it only fitting that Debian blacklisted problematic SSH keys, IPCop did not even bother. Reco
