David:
Hello! Some thoughts:
> > Yes, agreed. Taking this to an extreme, you could wrap a user login
> > for, say, ~firewall, into a custom shell that had nothing *but*
> > compiled firewall configuration commands.
>
> > I'm working with some others to build something like this now,
> > tying it closely with ssh host-authentication for remote-management
> > capability. Seems promising...
>
> This is very interesting. I'm thinking that writing a program in
> Ruby to handle this would be a good way to go - except that Ruby
> doesn't run under LEAF yet, and is huge by LEAF standards. It
> wouldn't be that hard to create a login under LEAF that would act as
> a network transfer agent, then receive only firewall commands via an
> ssh-encrypted session.
Yes, exactly.
> Only thing is, I'm not sure of the security implications of being
> able to do this. Sounds scary to me - configuring the firewall on
> the fly via the network? One sure way to bring down a firewall if it
> can be configured from the outside....
From my pov, that's not so much the "weakest link" in the
idea, as much as it is (importantly) the *only* weak link. I've
been focusing a lot on building a security policy for the setup
that's at least as secure as what's commonplace now: where people
SSH'ing into their firewall as a non-root user, and su to root
to affect changes.
So when I started building on the idea, I asked/read around
to gauge the confidence in an SSH-based host-auth'd security model.
What I took away from this investigation was that if you combine
host-auth with a strong login password, and you dismiss 'carelessness'
which sinks any ship, then it's a better starting-point than anything
else (it's scalable to include one-time passwords or biometrics).
Progress wise, the shell is in alpha prototype, and I've
solved for the tricky bit of getting a webserver process to initiate
and sustain a persistent SSH channel to it. Besides finishing the
basic vocabulary and parsing of the shell, the "things to do" list for
the shell includes:
1. Actually making host-auth and passwd-auth work *together* (sshv1
allows one or the other but not both).
2. Implementing a masq-table state-check (ie, if I'm using a web-based
service to admin the firewall, check to see that there is a browser
on my LAN actually pointed to that server).
3. Implement a low-CPU tripwire-like hash check on the core binaries
that a cracker would corrupt. So, a "check if I've been hacked"
feature.
As far as activating the firewall that was "built" this
way, there could be problems with doing so "on the fly", especially
if the user rolled-their-own firewall via a flexible builder, and
the first firewall rule activated was "ignore everything else". :)
It'd be better to leave the construction result as a root-only
script. So after the web-session, the user logs in as root, and actually
gives the server-generated script the kickoff.
-Scott
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
