Skip site navigation (1)Skip section navigation (2)
Date:      6 Apr 2003 22:37:37 +0200
From:      "clemens fischer" <ino-qc@spotteswoode.de.eu.org>
To:        "Sereciya Kurdistani" <sereciya@kurdistan.ath.cx>
Cc:        freebsd-ipfw@freebsd.org
Subject:   Re: Quick IPFW Question Concerning Sendmail
Message-ID:  <1y0fl5v2.fsf@ID-23066.news.dfncis.de>
In-Reply-To: <20030406162735.GA2797@kurdistan.ath.cx> (Sereciya Kurdistani's message of "Sun, 6 Apr 2003 09:27:35 -0700")
References:  <20030403182847.GC23675@kurdistan.ath.cx> <20030403135048.D92663-100000@diana.northnetworks.ca> <20030405174853.GA94738@kurdistan.ath.cx> <wui77g76.fsf@ID-23066.news.dfncis.de> <20030406162735.GA2797@kurdistan.ath.cx>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Sereciya Kurdistani <sereciya@kurdistan.ath.cx>:

>   ...Actually, I do have some facility for anti-spoofing rules, here they are:
>
>   ipfw add NNNN skipto NEXT_BLOCK all from     ${myhost} to not ${myhost} out via ${oif_1}
>   ipfw add NNNN skipto NEXT_BLOCK all from not ${myhost} to     ${myhost} in  via ${oif_1}
>
>   Do you mean I should check/filter for the private IP Addresses also?

i'm not familiar with ipfw2 and just can't get these rules into my
head.  to me this looks like they do nothing:  no blocking or
passing, this depends on what follows.

i have this in old ipfw (edited for a single workstation):

  #
  # traffic from PPP peer?  shouldn't happen!
  #
  add deny $Llog ip from any to ${opip}
  add deny $Llog ip from ${opip} to any
  #
  # Stop spoofing, allow internal traffic via loopback
  #
  add deny $Llog all from 127.0.0.0/8 to any via ${oif1}
  add deny $Llog all from any to 127.0.0.0/8 via ${oif1}
  add deny $Llog all from ${oip} to any in via lo0
  #
  # Stop RFC1918 nets on the outside interface
  # Stop draft-manning-dsua-01.txt nets on the outside interface
  # Title:  SANS Resources - Help Defeat Denial of Service Attacks: Step-by-Step
  # URL:    http://www.sans.org/dosstep/index.htm
  # 169.254.0.0/16      - Link Local Networks
  # 172.16.0.0/12       - RFC 1918 Private Network
  # 192.0.2.0/24        - TEST-NET
  # 192.168.0.0/16      - RFC 1918 Private Network
  # 224.0.0.0/4         - Class D Multicast
  # 240.0.0.0/5         - Class E Reserved
  # 248.0.0.0/5         - Unallocated
  # 255.255.255.255/32  - Broadcast
  #
  add deny $Llog all from 0.0.0.0/8 to any via ${oif1}
  add deny $Llog all from any to 0.0.0.0/8 via ${oif1}
  add deny $Llog all from 169.254.0.0/16 to any via ${oif1}
  add deny $Llog all from any to 169.254.0.0/16 via ${oif1}
  add deny $Llog all from 172.16.0.0/12 to any via ${oif1}
  add deny $Llog all from any to 172.16.0.0/12 via ${oif1}
  add deny $Llog all from 192.0.2.0/24 to any via ${oif1}
  add deny $Llog all from any to 192.0.2.0/24 via ${oif1}
  add deny $Llog all from 192.168.0.0/16 to any via ${oif1}
  add deny $Llog all from any to 192.168.0.0/16 via ${oif1}
  add deny $Llog all from 224.0.0.0/4 to any via ${oif1}
  add deny $Llog all from any to 224.0.0.0/4 via ${oif1}
  add deny $Llog all from 240.0.0.0/5 to any via ${oif1}
  add deny $Llog all from any to 240.0.0.0/5 via ${oif1}
  add deny $Llog all from 248.0.0.0/5 to any via ${oif1}
  add deny $Llog all from any to 248.0.0.0/5 via ${oif1}
  add deny $Llog all from 255.255.255.255/32 to any via ${oif1}
  add deny $Llog all from any to 255.255.255.255/32 via ${oif1}
  #
  # outgoing packets _must_ have our source IP!
  add deny $Llog all from not ${oip} to any $Xmit
  # incoming packets _must_ have our destination IP!
  add deny $Llog all from any to not ${oip} $Recv

Xmit is "xmit out $oif1", Recv the reverse.

>   Incoming SMTP is handled with a rule like:
>
>   ipfw add NNNN pipe N log tcp from any to any smtp,smtps in via ${oif}

where is the pipe handled?

>> i imagine your rules allowing _you_ to query others for AUTH data,
>> but you don't allow others this privilege.
>
>   That's correct.  Am I breaking a netiquette rule that I may not be
>   familiar with?

that's entirely up to you, but paranoid users may deny doing business
with you if you allow your setup to take security measures you deny
them.

> | Welat xwe ava nake, dest bidin hevdu, pist nedin tu dijminÓ...

with a big signature like this, it's certainly netiquette to also
provide an english translation.  i asked you in private email for
this, but you didn't reply.  if you want to tell your fellow
countrymen something, there are more appropriate channels.  lists like
this one keep politics and tech stuff apart.

  clemens



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?1y0fl5v2.fsf>