Re: Re: [fw-wiz] Firewalling at the domain users level instead of network level
From: Steve Lam (steve.lyk_at_gmail.com)
To: Santos <firstname.lastname@example.org> Date: Tue, 20 Jul 2004 18:34:20 +0800
You can try checking out OpenBSD's pf firewall, more specifically the
authpf potion of PF. I believe that it has the features which you are
looking for. Additionally, the firewall also comes with passive
firewall fingerprinting which allows the firewall to identify the OS
from which the traffic is orginating from.
That would mean having a seperate set of credentials to access the
Authpf(8) is a user shell for authenticating gateways. An
authenticating gateway is just like a regular network gateway (a.k.a.
a router) except that users must first authenticate themselves to the
gateway before it will allow traffic to pass through it. When a user's
shell is set to /usr/sbin/authpf (i.e., instead of setting a user's
shell to ksh(1), csh(1), etc) and the user logs in using SSH, authpf
will make the necessary changes to the active pf(4) ruleset so that
the user's traffic is passed through the filter and/or translated
using Network Address Translation or redirection. Once the user logs
out or their session is disconnected, authpf will remove any rules
loaded for the user and kill any stateful connections the user has
open. Because of this, the ability of the user to pass traffic through
the gateway only exists while the user keeps their SSH session open.
Authpf alters the pf(4) ruleset by adding rules to a named ruleset
attached to an anchor point. Each time a user authenticates, authpf
creates a new named ruleset and loads the preconfigured filter, nat,
binat, and rdr rules into it. The rules that authpf loads can be
configured on a per-user or global basis.
Example uses of authpf include:
* Requiring users to authenticate before allowing Internet access.
* Granting certain users -- such as administrators -- access to
restricted parts of the network.
* Allowing only known users to access the rest of the network or
Internet from a wireless network segment.
* Allowing workers from home, on the road, etc., access to
resources on the company network. Users outside the office can not
only open access to the company network, but can also be redirected to
particular resources (e.g., their own desktop) based on the username
they authenticate with.
* In a setting such as a library or other place with public
Internet terminals, PF may be configured to allow limited Internet
access to guest users. Authpf can then be used to provide registered
users with complete access.
Authpf logs the username and IP address of each user who authenticates
successfully as well as the start and end times of their login session
via syslogd(8). By using this information, an administrator can
determine who was logged in when and also make users accountable for
their network traffic.
Passive Operating System Fingerprinting
Passive OS Fingerprinting (OSFP) is a method for passively detecting
the operating system of a remote host based on certain characteristics
within that host's TCP SYN packets. This information can then be used
as criteria within filter rules.
PF determines the remote operating system by comparing characteristics
of a TCP SYN packet against the fingerprints file, which by default is
/etc/pf.os. Once PF is enabled, the current fingerprint list can be
viewed with this command:
# pfctl -s osfp
Within a filter rule, a fingerprint may be specified by OS class,
version, or subtype/patch level. Each of these items is listed in the
output of the pfctl command shown above. To specify a fingerprint in a
filter rule, the os keyword is used:
pass in on $ext_if any os OpenBSD keep state
block in on $ext_if any os "Windows 2000"
block in on $ext_if any os "Linux 2.4 ts"
block in on $ext_if any os unknown
The special operating system class unknown allows for matching packets
when the OS fingerprint is not known.
TAKE NOTE of the following:
* Operating system fingerprints are occasionally wrong due to
spoofed and/or crafted packets that are made to look like they
originated from a specific operating system.
* Certain revisions or patchlevels of an operating system may
change the stack's behavior and cause it to either not match what's in
the fingerprints file or to match another entry altogether.
* OSFP only works on the TCP SYN packet; it will not work on other
protocols or on already established connections.
On Mon, 19 Jul 2004 20:56:02 -0400 (EDT), Paul D. Robertson
> On Mon, 19 Jul 2004, Chuck Swiger wrote:
> [snip what I agree with...]
> > The second concern is a matter of policy: why do you want your firewall
> > to treat users differently? If it's a bad idea for person A to do some
> > type of network connection, why should it be OK for person B to do so?
> There are a multitude of reasons, including Person B being more clued than
> Person A.
> We don't tout the "Principle of equal privilege"
> Principle of least privilege works for people, applications and systems.
> If you restrict things so that only the services which you trust all
> > users to do are permitted, your security is likely to be much improved
> > compared to a policy based on an ever-growing pile of per-user rules
> > and exceptions.
> If you let one user have the Administrator password, why not all of them!?
> Paul D. Robertson "My statements in this message are personal opinions
> email@example.com which may have no basis whatsoever in fact."
> firstname.lastname@example.org Director of Risk Assessment TruSecure Corporation
> firewall-wizards mailing list
-- Regards, Steve Lam _______________________________________________ firewall-wizards mailing list email@example.com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards