Firewall Wizards mailing list archives
Re: Re: Firewalling at the domain users level instead of network level
From: Steve Lam <steve.lyk () gmail com>
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 internet thou.
From http://www.openbsd.org/faq/pf/authpf.html
***SNIP*** 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. *** SNIP***
From http://www.openbsd.org/faq/pf/filter.html#osfp
***SNIP*** 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. ***SNIP*** On Mon, 19 Jul 2004 20:56:02 -0400 (EDT), Paul D. Robertson <paul () compuwar net> wrote:
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 allusers 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 ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions paul () compuwar net which may have no basis whatsoever in fact." probertson () trusecure com Director of Risk Assessment TruSecure Corporation _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
-- Regards, Steve Lam _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Firewalling at the domain users level instead of network level Santos (Jul 19)
- Re: Firewalling at the domain users level instead of network level Luca Berra (Jul 19)
- Re: Firewalling at the domain users level instead of network level Devdas Bhagat (Jul 19)
- Re: Firewalling at the domain users level instead of network level Paul D. Robertson (Jul 19)
- Re: Firewalling at the domain users level instead of network level Chuck Swiger (Jul 19)
- Re: Firewalling at the domain users level instead of network level Paul D. Robertson (Jul 19)
- Re: Re: Firewalling at the domain users level instead of network level Steve Lam (Jul 20)
- Re: Firewalling at the domain users level instead of network level Chuck Swiger (Jul 20)
- Re: Firewalling at the domain users level instead of network level Paul D. Robertson (Jul 20)
- Re: Firewalling at the domain users level instead of network level Paul D. Robertson (Jul 19)
- <Possible follow-ups>
- RE: Firewalling at the domain users level instead of network level Melson, Paul (Jul 19)