> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, 27 July 2000 10:46 PM
> To: [EMAIL PROTECTED]
> Subject: What is the best linux platform for security
>
>
> A general question that could lead to interesting things....
>
> If anyone here were able to start, from scratch, their own firewall,
I'm going to assume that you mean developing a new firewall solution, since
that's a more interesting question.
> specifically designed on a Linux platform,
I'd probably not use Linux. I don't trust the integrity of the code in any
of the distros enough. If I had to start building on a mainstream OS I'd
look at OpenBSD - it's had pro-active code review. If I had even more time
I'd like to look at the RSBAC[1] stuff for Linux that Paul Robertson is
usually so vocally enthusiatic about.
> what would you
> select as the
> flavour, taking into consideration the following requirements:
>
> 1) Security, something stripped-down and tight
Check out the RSBAC stuff and think about Mandatory Access Control in a
firewall context. You should be able to design something that is
next-to-impossible (at a design level) to compromise remotely _even if you
write a dud ALG that needs system privileges_. I assume that you're
developing software, so you're not going to be able to mandate things like
read-only media for the kernel and other important firewall binaries, but if
you're building a "black box" then this sort of thing is cool.
In terms of approach I'd probably like to see a stateful packet filter,
app-level gateway, application _delivery_ hybrid. I would love to see a
solution that could (scalably) run browser threads on a secure box and just
deliver screen images to the user via a remote-control client. In terms of
scalability you'd almost certainly want this to be _outside_ your firewall
box though.
DNS should be ALG'ed. Think about ways to secure DNS. FTP should be ALG'ed.
SMTP should be ALG'ed. You will probably also need to support a whole lot of
the ugly protocols (H.323, nasty dynamic RPC stuff etc etc). These are good
candidates for a SPF, but control-channel inspection is a must.
> 2) Performance, as that is always an issue
Screw performance. No, really. Don't write ugly code and performance will
take care of itself.
> 3) Popularity, a flavor everyone likes
Ditto.
> 4) Future scope, something everyone will like for a long time to come
Single Points of Enforcement for TCP/IP security is a poor model for our
evolving networks. If you're writing choke-point style security solutions
then be prepared to have the market evolve away from you. This is not to say
that it's going to happen tomorrow or that there's no place for more good
tools.
> 5) Flexibility and Ease, something easy to use and without limitations
Feh. GUIs. I spit upon them ;)
If you were writing a SPF / ALG hybrid then you should be able to come up
with a fairly simple interface. I think one should be able to _configure_
whether application sessions "cut through" to a state-table entry. I also
think one should be able to configure some state-table variables (aggressive
half open timeouts, faster FIN-WAIT closes, quick shutdown of aborted
connections, sensible handling of frags etc). This will help mitigate lots
of DoS attacks. Finally, if you could have a glass-case on your application
level gateway parser so that clueful people could code in protection from
new attacks as they happened it would be even better.
>
> So if anyone here, had the power to do it, and do it right,
> what would be
> YOUR flavour?
Salty.
>
> :)
>
>
>
> Daniel Duguay
> Systems Administrator
> Firewall and Secure Systems Development
> * Tel: (613) 944-2351
> * Fax: (613) 944-0044
> * Email: [EMAIL PROTECTED]
Cheers,
[1] www.rsbac.org - great looking stuff.
--
Ben Nagy
Network Consultant, Volante IT
PGP Key ID: 0x1A86E304 Mobile: +61 414 411 520
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
