OpenBSD Journal

PF enabled by default

Contributed by jj on from the drop-the-evil-bit-packets-too dept.

As seen here, PF is now enabled by default. The default pf.conf will now pass in all traffic, except for TCP port 6000 normally used by remote-X11.
By having the X server still listen on port 6000 but let PF block incoming packets that aren't coming from localhost you can still use local X sessions that needs to talk to the TCP port or runs through a port forward from remote, but at the same time don't expose your machine on the network.

Recent changes to PF, like having packet reassembly enabled on all packets by default, will now help clean incoming traffic.

With all the new code and features of PF in there, and the nice side effects it brings according to henning@ as seen below, it needs wider usage. 
CVSROOT:	/cvs
Module name:	src
Changes by:	henning@cvs.openbsd.org	2009/05/31 13:16:16

Modified files:
	etc            : rc.conf 

Log message:
enable pf by default.
turns bombs into flowers, water into beer and eradicts swine flu

(Comments are closed)

Comments

  1. By Jason Eggleston (68.4.61.243) on

    Why not just have X listen on 127.0.0.1?

    Comments

    1. By Anonymous Coward (115.166.19.176) on

      The whole '-nolisten tcp' thing has been done to death on the mailing lists (is this an FAQ yet?). But to be honest, I don't really see the difference between not listening, listening on localhost only, or blocking packets destined for the host/port. Use of a remote X requires manual configuration changes in any of these cases, which I thought was the point of leaving it accessible. Anyone care to enlighten me?

      Comments

      1. By Anonymous Coward (93.104.103.190) on

        > > > The whole '-nolisten tcp' thing has been done to death on the mailing lists (is this an FAQ yet?). But to be honest, I don't really see the difference between not listening, listening on localhost only, or blocking packets destined for the host/port. Use of a remote X requires manual configuration changes in any of these cases, which I thought was the point of leaving it accessible. Anyone care to enlighten me? > > > > PF ain't Bug free. > > The latest ICMP-Bug may proofed that to death. > > > > nolisten tcp is the only sane solution for this stuff. > > Also disabling inetd would be a bless. > > > You should maybe use Aeriebsd (www.aeriebsd.org) - I heard they > were going to disable inetd by default. > No, they're not. Check the archives.

        Comments

        1. By Anonymous Coward (128.171.90.200) on

          > You should maybe use Aeriebsd (www.aeriebsd.org) - I heard they
          > were going to disable inetd by default.

          I've been living under a rock, what is AerieBSD ?
          The website is a little light on information.

          Comments

          1. By Richard Toohey (121.72.23.150) on

            > > You should maybe use Aeriebsd (www.aeriebsd.org) - I heard they
            > > were going to disable inetd by default.
            >
            > I've been living under a rock, what is AerieBSD ?
            > The website is a little light on information.

            Looks like something mickey and one or two other ex(?)-OpenBSD guys are working on. Based on OpenBSD 4.4 from some of the comments here:

            http://blog.gmane.org/gmane.os.aeriebsd.general

            [I don't know anything more than what I read there; like you, I was curious.]

  2. By clvrmnky (69.196.152.39) clvrmnky.invalid@gmail.com on

    If this had been done last release the "Only ... holes in the default install ..." would have been blown away with that pf DoS.

    I hope regression testing is done on PF changes from now on ;)

    Well, the whole default install hole report is a bit of a dick-waving exercise anyway.

    Comments

    1. By Anonymous Coward (68.224.90.201) on

      > If this had been done last release the "Only ... holes in the default install ..." would have been blown away with that pf DoS.
      >
      > I hope regression testing is done on PF changes from now on ;)
      >
      > Well, the whole default install hole report is a bit of a dick-waving exercise anyway.

      Failure to detect difference between denial of service and remote hole detected!

    2. By Anonymous Coward (2a01:348:108:155:222:43ff:fe14:9b35) on

      > If this had been done last release the "Only ... holes in the default install ..." would have been blown away with that pf DoS.

      That's incorrect, it was a problem with certain NAT configurations only.

  3. By Anonymous Coward (68.224.90.201) on

    cue whining about how pf.conf isn't blocking everything by default in 3..2..1

    Comments

    1. By Anonymous Coward (71.197.168.146) on

      > cue whining about how pf.conf isn't blocking everything by default in 3..2..1

      Shouldn't the default policy be to block all? Isn't this supposed to be the most secure OS evar??!?!?!!!!!11oneone



      ;-)

      Comments

      1. By Matthew Dempsky (67.180.8.35) on

        A default "block all" rule would certainly help ensure OpenBSD remote security hole guarantee doesn't have to be changed ever again. :)

        Comments

        1. By Martin Toft (130.225.243.84) on

          > A default "block all" rule would certainly help ensure OpenBSD remote security hole guarantee doesn't have to be changed ever again. :)

          Hehe... But seriously... Why not someting along the lines of

          block in
          pass out

          and optionally

          pass in { inet inet6 } from any to any port ssh

          if the user answered yes to sshd during the install?

          Comments

          1. By Lennie (82.75.64.11) on

            > > A default "block all" rule would certainly help ensure OpenBSD remote security hole guarantee doesn't have to be changed ever again. :)
            >
            > Hehe... But seriously... Why not someting along the lines of
            >
            > block in
            > pass out
            >
            > and optionally
            >
            > pass in { inet inet6 } from any to any port ssh
            >
            > if the user answered yes to sshd during the install?

            Can we also add something like:

            pass in inet proto icmp icmp-type echoreq

            Comments

            1. By Anonymous Coward (85.19.213.88) on

              > > > A default "block all" rule would certainly help ensure OpenBSD remote security hole guarantee doesn't have to be changed ever again. :)
              > >
              > > Hehe... But seriously... Why not someting along the lines of
              > >
              > > block in
              > > pass out
              > >
              > > and optionally
              > >
              > > pass in { inet inet6 } from any to any port ssh
              > >
              > > if the user answered yes to sshd during the install?
              >
              > Can we also add something like:
              >
              > pass in inet proto icmp icmp-type echoreq
              >
              >

              Or `pass in inet proto icmp all'.

              Is there any reason to block any of the icmp types?

              Comments

              1. By Anonymous Coward (91.141.6.239) on

                > Is there any reason to block any of the icmp types?
                >

                Yes. I once hooked up a cheap Netgear SOHO Router on the LAN side of my network just for its switch part. Although its WAN port was not connected it sent out an ICMP Redirect which my OpenBSD gateway obeyed to. Quite the surprise.

                Comments

                1. By Cobalt (68.100.227.128) on

                  > > Is there any reason to block any of the icmp types?
                  > Yes. I once hooked up a cheap Netgear SOHO Router on the LAN side of my network just for its switch part. Although its WAN port was not connected it sent out an ICMP Redirect which my OpenBSD gateway obeyed to. Quite the surprise.


                  While I sympathize, is that a reason to block all icmp by default? Or to be overly specific about which ones go into a default pf.conf

                  (I like the notion that there could be a pf.conf.default that is the default, and that leaves the user to switch to pf.conf in the rc.conf.local -or take the .default out. Of course, like rc.conf. many users would probably just edit the pf.conf.default).

                  Comments

                  1. By Anonymous Coward (91.141.6.239) on

                    > > > Is there any reason to block any of the icmp types?
                    > > Yes. I once hooked up a cheap Netgear SOHO Router on the LAN side of my network just for its switch part. Although its WAN port was not connected it sent out an ICMP Redirect which my OpenBSD gateway obeyed to. Quite the surprise.
                    >
                    >
                    > While I sympathize, is that a reason to block all icmp by default? Or to be overly specific about which ones go into a default pf.conf

                    block any != block all

                    For the sake of discussion of a hypothetical sensible, safe and sane "default deny" rule set, ICMP needs to be looked at.

                    This discussion is about 'don't do anything until explicitly told to' network-wise. (Analogue to the base system approach.) Packets which change my routing topology break that.

                    But I'm not an expert or something, just wanted to throw in my observations.

                    Comments

                    1. By Anonymous Coward (85.158.45.32) on

                      > > > > Is there any reason to block any of the icmp types?
                      > > > Yes. I once hooked up a cheap Netgear SOHO Router on the LAN side of my network just for its switch part. Although its WAN port was not connected it sent out an ICMP Redirect which my OpenBSD gateway obeyed to. Quite the surprise.
                      > >
                      > >
                      > > While I sympathize, is that a reason to block all icmp by default? Or to be overly specific about which ones go into a default pf.conf
                      >
                      > block any != block all
                      >
                      > For the sake of discussion of a hypothetical sensible, safe and sane "default deny" rule set, ICMP needs to be looked at.
                      >
                      > This discussion is about 'don't do anything until explicitly told to' network-wise. (Analogue to the base system approach.) Packets which change my routing topology break that.

                      PF seems the wrong place to block these to me; syscgtl net.inet.icmp.rediraccept=0 is another possibility. Don't forget to lock down your ARP tables too if you want to prevent packets from changing your routing topology.

          2. By Henrik Kramshoej (2001:16d8:dd0f:cf0f:21c:b3ff:fec4:e1b6) hlk@kramse.dk on

            > > A default "block all" rule would certainly help ensure OpenBSD remote security hole guarantee doesn't have to be changed ever again. :)
            >
            > Hehe... But seriously... Why not someting along the lines of
            >
            > block in
            > pass out
            >
            > and optionally
            >
            > pass in { inet inet6 } from any to any port ssh
            >
            > if the user answered yes to sshd during the install?
            Actually since ICMPv6 includes Neighbor Discovery Protocol, NDP
            you should also make sure that a few messages like
            IPv6 ICMP - router solicitation (133) and router advertisement (134)
            IPv6 ICMP - neighbour discovery solicitation (135) and advertisement (136)
            are allowed, depending on your configuration.

            It is somewhat comparable to ARP and DHCP, where ARP is for IPv4, NDP is for IPv6, and DHCP addresses for IPv4 is mostly replaced by getting prefixes from routers in router advertisements. Some things might be configured using DHCP in IPv6, but lets not argue about that right now :-)

            I haven't brought my PF IPv6 firewall script, but you need something like:
            A router would need to allow 133 in and send 134, an autoconfigured client would need the opposite :-)

            They would all need 135 and 136.

            http://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol

      2. By Anonymous Coward (65.8.136.171) on

        > > cue whining about how pf.conf isn't blocking everything by default in 3..2..1
        >
        > Shouldn't the default policy be to block all? Isn't this supposed to be the most secure OS evar??!?!?!!!!!11oneone
        >
        >
        >
        > ;-)

        MOAR BLOKING PLZZZ!!!!!!

  4. By Steve Shockley (68.83.96.160) steve.shockley@shockley.net on

    It's true, I use pf, and I don't have the pig flu.

    Comments

    1. By Anonymous Coward (142.244.225.32) on

      > It's true, I use pf, and I don't have the pig flu.

      But I use pf, and the developers in the hack room gave me swine flu..
      (or at least blambert did when he hugged me..)

      Comments

      1. By Anonymous Coward (142.244.224.103) on

        > > It's true, I use pf, and I don't have the pig flu.
        >
        > But I use pf, and the developers in the hack room gave me swine flu..
        > (or at least blambert did when he hugged me..)
        >

        Don't act like you weren't aroused.

  5. By Anonymous Coward (85.19.213.88) on

    So, what does the new pf.conf look like? pass out quick on $cheap_gin?

    Comments

    1. By Anonymous Coward (173.75.247.211) on

      > So, what does the new pf.conf look like? pass out quick on $cheap_gin?

      That's the funniest PF joke I've ever heard....wait that's the only PF joke I've heard.

      I'll go next. What's a cat named Token say? MAU MAU MAU!

      Comments

      1. By Anonymous Coward (65.8.136.171) on

        > > So, what does the new pf.conf look like? pass out quick on $cheap_gin?
        >
        > That's the funniest PF joke I've ever heard....wait that's the only PF joke I've heard.
        >
        > I'll go next. What's a cat named Token say? MAU MAU MAU!

        I feel a meme thread developing here.

        I hope we don't have to block it.

        Comments

        1. By Ed Ahlsen-Girard (68.1.69.60) girarde@alum.rpi.edu on

          > > > So, what does the new pf.conf look like? pass out quick on $cheap_gin?
          > >
          > > That's the funniest PF joke I've ever heard....wait that's the only PF joke I've heard.
          > >
          > > I'll go next. What's a cat named Token say? MAU MAU MAU!
          >
          > I feel a meme thread developing here.
          >
          > I hope we don't have to block it.

          Q. How do you catch fish without causing them any pain?

          A. With an ethernet.

          Q. What track and field event involve criminals trying to blame each other?

          A. Frame relay.

          Comments

          1. By Anonymous Coward (166.68.134.174) on

            > > > > So, what does the new pf.conf look like? pass out quick on $cheap_gin?
            > > >
            > > > That's the funniest PF joke I've ever heard....wait that's the only PF joke I've heard.
            > > >
            > > > I'll go next. What's a cat named Token say? MAU MAU MAU!
            > >
            > > I feel a meme thread developing here.
            > >
            > > I hope we don't have to block it.
            >
            > Q. How do you catch fish without causing them any pain?
            >
            > A. With an ethernet.
            >
            > Q. What track and field event involve criminals trying to blame each other?
            >
            > A. Frame relay.

            Q. Who were those criminals, anyway?

            A. Part of a pick-pocket team, intercepted during packet switching.

            Comments

            1. By Ed Ahlsen-Girard (68.1.69.60) girarde@alum.rpi.edu on

              > > > > > So, what does the new pf.conf look like? pass out quick on $cheap_gin?
              > > > >
              > > > > That's the funniest PF joke I've ever heard....wait that's the only PF joke I've heard.
              > > > >
              > > > > I'll go next. What's a cat named Token say? MAU MAU MAU!
              > > >
              > > > I feel a meme thread developing here.
              > > >
              > > > I hope we don't have to block it.
              > >
              > > Q. How do you catch fish without causing them any pain?
              > >
              > > A. With an ethernet.
              > >
              > > Q. What track and field event involve criminals trying to blame each other?
              > >
              > > A. Frame relay.
              >
              > Q. Who were those criminals, anyway?
              >
              > A. Part of a pick-pocket team, intercepted during packet switching.

              Fortunately, thanks to good work by the Police Force, or PF, as they're known, the gang was routed.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]