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]
Date: Thu Jan 19 18:23:23 2006
From: greybrimstone at aim.com (greybrimstone@....com)
Subject: PC Firewall Choices

All very good points.  I am not certain as to how viable of an option 
this "idea" would be, but what about a totally R/O firewall after 
configuration? Incorporate some sort of memory protection into that, 
such as stack and heap protection. You'd then have a pretty secure 
firewall... but then again... if its passing traffic to an insecure 
box... you're screwed anyway.

-Adriel

-----Original Message-----
From: Juliao Duartenn <juliao.duartenn@...og.pt>
To: greybrimstone@....com
Cc: Valdis.Kletnieks@...edu; me@...t.org; 
full-disclosure@...ts.grok.org.uk
Sent: Wed, 18 Jan 2006 10:28:51 +0000
Subject: Re: [Full-disclosure] PC Firewall Choices

  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?

Juliao


> -----Original Message-----
> From: Valdis.Kletnieks@...edu
> To: Nick Hyatt <me@...t.org>
> Cc: full-disclosure@...ts.grok.org.uk
> Sent: Tue, 17 Jan 2006 21:08:39 -0500
> Subject: Re: [Full-disclosure] PC Firewall Choices
>
>   On Tue, 17 Jan 2006 18:59:52 MST, Nick Hyatt said:
> > Given the choice between one of those selections and a standard
> Linksys
> > router / firewall combo, wouldn't it be safer to go with the 
hardware
> > firewall? I find the configuration options to be quite a bit more
> in-depth,
> > and the hardware firewall doesn't get itself as stuck in the system
> as say,
> > ZA does.
>
> Even more important, a hardware firewall can't be compromised as 
easily
> by malware that's on a host behind the firewall.  It's easy for a
> program
> on a PC to tell ZA to look the other way.  It's a little harder for 
it
> to
> tell a hardware firewall to look the other way.
>
> Unless of course, the firewall implements the UPnP "Pants Down!" 
RPC..
> ;)
>



________________________________________________________________________
Check Out the new free AIM(R) Mail -- 2 GB of storage and 
industry-leading spam and email virus protection.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ