荔园在线

荔园之美,在春之萌芽,在夏之绽放,在秋之收获,在冬之沉淀

[回到开始] [上一篇][下一篇]


发信人: georgehill (清风浮云 人生), 信区: Linux
标  题: ipfilter-howto(4-6)(转寄)
发信站: BBS 荔园晨风站 (Thu Nov  2 23:07:24 2000), 站内信件

【 以下文字转载自 georgehill 的信箱 】
【 原文由 georgehill.bbs@smth.org 所发表 】
发信人: snofe ([听潮阁主人]), 信区: FreeBSD
标  题: ipfilter-howto(4-6)(转寄)
发信站: BBS 水木清华站 (Tue Oct 31 13:42:49 2000)

                            -4-


A packet comes in the interface and it's time to go to work.
It  takes a look at the packet, it takes a look at the first
rule:

    block in all

"So far I think I will block  this  packet"  says  IPF.   It
takes a look at the second rule:

    pass  in all

"So far I think I will pass this packet" says IPF.  It takes
a look at a third rule.  There is no third rule, so it  goes
with  what  its  last  motivation  was,  to  pass the packet
onward.

It's a good time to point out that even if the  ruleset  had
been

    block in all
    block in all
    block in all
    block in all
    pass  in all

that  the packet would still have gone through.  There is no
cumulative effect.  The  last  matching  rule  always  takes
precedence.

2.3.  Controlling Rule Processing

     If  you  have experience with other packet filters, you
may find this layout to be confusing, and you may be  specu-
lating  that  there are problems with portability with other
filters and speed of rule matching.  Imagine if you had  100
rules  and  most  of  the applicable ones were the first 10.
There would be a terrible overhead for every  packet  coming
in  to  go through 100 rules every time.  Fortunately, there
is a simple keyword you can add to any rule  that  makes  it
take action at that match.  That keyword is quick.

Here's  a  modified  copy  of the original ruleset using the
quick keyword:

    block in quick all
    pass  in       all

In this case, IPF looks at the first rule:

    block in quick all

The packet matches and the search is over.   The  packet  is
expunged  without a peep.  There are no notices, no logs, no
memorial service.  Cake will not be served.  So  what  about









                             -5-


the next rule?

    pass  in       all

     This  rule is never encountered.  It could just as eas-
ily not be in the config file at all.  The sweeping match of
all  and  the  terminal keyword quick from the previous rule
make certain that no rules are followed afterward.

     Having half a config file laid to  waste  is  rarely  a
desirable  state.   On  the other hand, IPF is here to block
packets and as configured,  it's  doing  a  very  good  job.
Nonetheless,  IPF  is also here to let some packets through,
so a change to the ruleset to make this possible  is  called
for.

2.4.  Basic filtering by IP address

     IPF  will match packets on many criteria.  The one that
we most commonly think of is the IP address.  There are some
blocks of address space from which we should never get traf-
fic.  One such  block  is  from   the  unroutable  networks,
192.168.0.0/16 (/16 is the CIDR notation for a netmask.  You
may  be  more  familiar  with  the  dotted  decimal  format,
255.255.0.0.   IPF  accepts  both).   If you wanted to block
192.168.0.0/16, this is one way to do it:

    block in quick from 192.168.0.0/16 to any
    pass  in       all

Now we have a less  stringent  ruleset  that  actually  does
something  for  us.   Lets  imagine  a  packet comes in from
1.2.3.4.  The first rule is applied:

    block in quick from 192.168.0.0/16 to any

The packet is from 1.2.3.4, not 192.168.*.*, so there is  no
match.  The second rule is applied:

    pass  in       all

The  packet from 1.2.3.4 is definitely a part of all, so the
packet is sent to whatever it's destination happened to  be.

     On  the other hand, suppose we have a packet that comes
in from 192.168.1.2.  The first rule is applied:

    block in quick from 192.168.0.0/16 to any

There's a match, the packet is dropped, and that's the  end.
Again,  it doesn't move to the second rule because the first
rule matches and contains the quick keyword.











                             -6-


     At this point you can build a fairly extensive  set  of
definitive  addresses  which  are  passed or blocked.  Since
we've already started blocking private  address  space  from
entering our firewall, lets take care of the rest of it:

    block in quick from 192.168.0.0/16 to any
    block in quick from 172.16.0.0/12 to any
    block in quick from 10.0.0.0/8 to any
    pass  in       all

The first three address blocks are the unroutable IP space.

2.5.  Controlling Your Interfaces

     It seems very frequent  that  companies  have  internal
networks  before  they want a link to the outside world.  In
fact, it's probably reasonable to say that's the main reason
people  consider  firewalls in the first place.  The machine
that bridges the outside world to the inside world and  vice
versa  is  the  router.   What separates the router from any
other machine is simple: It has more than one interface.

     Every packet you recieve comes from  a  network  inter-
face;  every  packet  you transmit goes out a network inter-
face.  Say your machine has 3  interfaces,  lo0  (loopback),
xl0  (3com  ethernet),  and  tun0  (FreeBSD's generic tunnel
interface that PPP uses), but you don't want packets  coming
in on the tun0 interface?

    block in quick on tun0 all
    pass  in               all

In  this case, the on keyword means that that data is coming
in on the named interface.  If a packet comes  in  on  tun0,
the  first  rule will block it.  If a packet comes in on lo0
or in on xl0, the first rule will not match, the second rule
will, the packet will be passed.

2.6.  Using IP Address and Interface Together

     It's  an  odd state of affairs when one decides it best
to have the tun0 interface up, but not allow any data to  be
recieved  from  it.   The more criteria the firewall matches
against, the tighter (or looser) the  firewall  can  become.
Maybe  you want data from tun0, but not from 192.168.0.0/16?
This is the start of a powerful firewall.

    block in quick on tun0 from 192.168.0.0/16 to any
    pass  in       all


-----------
             See             rfc1918            at
<http://www.faqs.org/rfcs/rfc1918.html>

--

※ 来源:·BBS 水木清华站 smth.org·[FROM: 202.199.66.62]
--
※ 转载:·BBS 荔园晨风站 bbs.szu.edu.cn·[FROM: 192.168.1.115]


[回到开始] [上一篇][下一篇]

荔园在线首页 友情链接:深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店