荔园在线
荔园之美,在春之萌芽,在夏之绽放,在秋之收获,在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: 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软件 网络书店