full-disclosure - PC Firewall Choices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060118105736.GA13236@melpomene.jschipper.dynalias.net>
Date: Wed Jan 18 10:57:43 2006
From: j.schipper at math.uu.nl (Joachim Schipper)
Subject: PC Firewall Choices

On Wed, Jan 18, 2006 at 10:28:51AM +0000, Juliao Duartenn wrote:
> On Tue, 2006-01-17 at 23:33 -0500, greybrimstone@....com wrote:
> > Thats assuming that malware isn't being designed for that firewall. I'm 
> > sure you already know that software is software regardless of the 
> > hardware that it is running on. Likewise a vulnerability is still a 
> > vulnerability...
> > 
> > I suppose you could r/o the system... but you need to write the confs 
> > somewhere right?
> > 
> > -Adriel
> > 
> 
> Configuration on a hardware firewall is usually a pretty stable thing -
> you don't go around opening ports at random every day, now do you?
> 
> Most modern {linux|bsd} firewall implementations can now run from a
> read-only device, namely CD-ROM, and also write their configuration to a
> removable device that you can manually set RW or RO - floppy, USB pen,
> etc.
> 
> Of course, since most implementations mount parts of the filesystem into
> RAM, you're still vulnerable to attacks, they are merely non-permanent,
> if you reboot you are clean again, albeit with the original hole still
> present, i'd say.
> 
> There are, of course, solutions for that too, but I still haven't seen
> one that really works - meaning that it can detect and prevent tampering
> in real-time. The best thing I can remember is running tripwire against
> a RO database on CD, but that can still be tampered with. Any thoughts?

Well, if someone manages to get access to the kernel (don't forget that
root has such access), any program on the system can be made to do
pretty much anything - in particular, tripwire can be made to report
that all is well.

The easy solution involves using a recent kernel that has no known or
suspected vulnerabilities. Some intrusion detection - like tripwire -
might be valuable, but there is a limit to that.

		Joachim