Re: Re: [fw-wiz] Firewalling at the domain users level instead of network level

From: Steve Lam (
Date: 07/20/04

  • Next message: Chuck Swiger: "Re: [fw-wiz] Firewalling at the domain users level instead of network level"
    To: Santos <>
    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.


    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***



    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
    <> 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 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
    > -----------------------------------------------------------------------------
    > Paul D. Robertson "My statements in this message are personal opinions
    > which may have no basis whatsoever in fact."
    > Director of Risk Assessment TruSecure Corporation
    > _______________________________________________
    > firewall-wizards mailing list

    Steve Lam
    firewall-wizards mailing list

  • Next message: Chuck Swiger: "Re: [fw-wiz] Firewalling at the domain users level instead of network level"