gtaylor at riverviewtech
Aug 28, 2007, 9:59 PM
Post #3 of 4
On 8/27/2007 9:45 AM, quesera2 wrote:
Re: Implement single firewall login for access to all ports on LAN?
[In reply to]
> My thoughts are to have a strong challenge/response login from a
> client to the firewall. This could be done via https to a
> non-standard port on the firewall. If this login succeeded, all (or
> configurable) ports would be available from the client to services
> inside the firewall as long as the 'session' was active. The session
> would be based on the client's IP and would have an inactivity
> time-out. The original https login would not need to stay active.
Ok, seems close to reasonable enough. I'm not sure that the web page
needs to be on a standard port or that it even should be if you are
trying to make this idiot proof. I personally do not see any reason why
the page(s) in question can not be on standard port 80. You may or may
not want to use HTAccess or the likes to protect the login page its
self. This would provide a two factor login with HTAccess and your
> Valid user logins could be either via statically configured tables on
> the firewall or via LDAP, etc.
I'd say that you would want to use a combination of both and / or one
derived from the other. Here are some things that I could consider if
designing such a system.
- Jump to a sub-chain to do the conditional checks.
- Possibly have a sub-chain for each authenticating user.
- Use a match extension that will react based on time.
- Time match extension from Patch-O-Matic-NG
- Recent match extension
- Use the comment match extension to put a label in rules.
I don't think I would have the authentication page(s) edit your firewall
directly, just think what could happen if someone managed to find an
exploit in your authentication page(s). Rather I would have the
authentication page(s) queue change requests that include authenticating
party's credentials, requested change(s), authentication page /
mechanism credentials that is requesting the change(s) on behalf of the
authenticating party, and last but not least, a checksum. I would
probably be tempted to encrypt the request as well. There is no reason
that the authentication page(s) can not validate the credentials and the
requested change to report feedback to the requesting party immediately.
However I would double check any and all queued change requests for
obvious security reasons. I might even make the change requests only
good for a specific length of time. That is to say that a change
request is only valid for a few minutes (queue cycle), even if the
requested change would be valid for longer than that. This should help
prevent replay attacks with your queued change requests.
With the above security out of the way the problem is now down to what
option(s) do you want the page(s) to present to the authenticating party.
> I think I remember a scheme like this when I was using the Wingate
> proxy server. Is this available using iptables?
IPTables is a low level filtering structure, not a higher level
management system. You can easily create a management system around /
on top of IPTables though.
Grant. . . .