Linux Slackware 7.0


    Dagmar d'Surreal found following.  Some of these might come as  an
    ugly  suprise  to  people  who  expected  things  to be 'just so'.
    These  really  only  apply  to  Slackware  7.0.   There  are three
    problems,  and  they  should  be  common  to pretty much any 2.2.x
    based distribution.

    IPV4 PACKET FORWARDING -- Should not be on by default
    There are three  problems that I  am aware of  at the moment,  and
    they're  all  in  /etc/rc.d/rc.inet2,  unfortunately.  Starting at
    around line  19 or  so is  the section  that deals  with IP packet
    forwarding, which  is being  turned ON  by default.   IMHO, that's
    incorrect,  because  it  really  shouldn't  be  _assumed_ that the
    machine is  supposed to  forward packets.   (According to  RFCs as
    well--thanks for pointing that out to  me Alan!)  On top of  this,
    the  default  configuration  scripts  only  allow for one ethernet
    interface, so  it doesn't  make a  lot of  sense to  turn this  on
    either.   Not much  could be  done about  exploiting with  without
    more than  one interface,  but people  dialing up  their ISP  with
    pppd who  have an  ethernet network  attaches to  that host  could
    possibly be exposing themselves to a bit of risk.

    RP_FILTER -- Probably incorrect assumption
    Just below the  section that turns  on IP forwarding  is a section
    that theoretically  turns on  rp_filter, which  is supposed  to do
    source validation  of incoming  packets to  prevent outside lusers
    from firing  spoofed packets  into your  local network.   This  is
    supposed to  go on  by default  once ip_forwarding  is turned  on,
    according  to  both  the  comments  in  the  script and the kernel
    documentation.  (Annoyingly enough, the interface for it in  /proc
    still emits a  0 when ip_forwarding  is turned on,  which leads to
    believe that something  might be missing  in the kernel,  although
    one might be the  only person that ever  tries to read proc  first
    to see what's on and what's off.)

    TCP_SYNCOOKIES -- Gobbled up by the 2.2.x kernel
    If  we're  going  to  be  messing  around  with parts of the /proc
    interface here  in /etc/rc.d/rc.inet2  then we  should really turn
    on SYN cookie support while  we're at it.  (Probably  log_martians
    as well, but can you see  where this would do anything other  than
    nada if the machine  has a default route,  or really burn up  disk
    space  logging  packets  if  someone  accidentally  forgot  to add
    themselves  a  default  route  and  exposed  the  machine  to live
    internet traffic.  Looks  useful for spotting oddities,  tho.) The
    default behaviour for syn-cookies went from having the  protection
    turned on by default in 2.0.x  to being turned off by default  for


    IPV4 PACKET FORWARDING -- Should not be on by default
    It's an easy fix.  Change




    in /etc/rc.d/rc.inet2 unless  you know what  you're doing.   Above
    is true for Slackware 4.0

    RP_FILTER -- Probably incorrect assumption
    Better to be safe than sorry and change the logic to stuff a 1  in
    there if IPV4_FORWARD is true, and a zero in there if it's  false.
    It also  applyes to  Slackware 4.0,  but it  isn't kernel problem.
    Kernel documentation says:

        # rp_filter
        #    Integer value deciding if source validation should be made.
        #    1 means yes, 0 means no. Disabled by default, but
        #    local/broadcast address spoofing is always on.

    "Disabled by default"!   Patrick Volkerding was noticed  long time
    before Slackware 7 (as soon as found in 4.0).

    TCP_SYNCOOKIES -- Gobbled up by the 2.2.x kernel
    Right-thinking admins should probably chuck in a subsection for it
    below the rp_filter stuff.  According to the

        If you  are SYN  flooded, the  source address  reported by the
        kernel is likely  to have been  forged by the  attacker; it is
        only  reported  as  an  aid  in  tracing  the packets to their
        actual source and should not be taken as absolute truth.

        SYN cookies  may prevent  correct error  reporting on  clients
        when  the  server  is  really  overloaded.  If  this   happens
        frequently better turn them off.

    It is a tool whereby the value of it's use is often outweighed by
    the "bug reports" and "kernel problems" or "this guy attacked  me"
    reports.  So....  SYN  cookies don't default to on  purely because
    they  are  strictly  not  "the  standard".   In  fact its normally
    standards compliant stuff that causes problems

        SACK    -    with buggy VJ compressors
        PAWS    -    with broken load balancers
        MTU discovery   -   with assholes who block all ICMP out   and
                            in (some  very big  names in  the business
                            meet this criteria btw)

    RST cookies were also in Linux 2.0, those did cause problems  with
    some setups and were dropped.