Date: Thu, 19 Jan 2006 14:27:53 -0800 From: "jdow" <jdow@earthlink.net> To: <freebsd-questions@freebsd.org> Subject: Re: How to tell if IPF is running? Message-ID: <006001c61d47$973bccc0$1225a8c0@kittycat>
next in thread | raw e-mail | index | archive | help
From: "Erik Norgaard" <norgaard@locolomo.org>
Nce writeup. I do have one question at the bottom.
> I used IPF on FBSD until there was some bug in IPF for 5.x some version
> that forced me to switch after an upgrade. The bug has been fixed since
> but I have found no reason to go back.
>
> There are two things I miss from IPF:
>
> a) proper accounting: You can't count traffic correctly with stateful
> filtering on pf, pf will count when a rule is matched but once a state
> is established packets for that state are not matched and hence not counted.
>
> b) an active and inactive ruleset: To load a new ruleset you'll have to
> flush everything. You can check syntax of rules before loading and pf
> loads all or nothing, so if there is a syntax error in your ruleset it
> won't be loaded. BUT: You may make syntactically correct changes that
> yet contain errors: Just say you wrote:
>
> block in all from 10.0.0.0/2
>
> but meant
>
> block in all from 10.0.0.0/24
>
> In IPF I always used:
>
> # ipf -s && sleep 60 && ipf -s
>
> to give me 60 seconds to verify that I didn't lock myself out.
>
> Now, that is compensated by in PF you can flush and reload the rules
> only, keeping existing states, so the connection you use for maintenance
> is not torn down.
>
> The pros for PF are some features to prevent DDoS against servers behind
> your firewall, and advanced queuing features and CARP. The use of macros
> and tables makes it easier to maintain rules, but the lack of groups
> means you have to be more careful structuring your ruleset:
>
> Rules are read top down _always_ in IPF I really liked groups, even
> though I always kept rules together. It just made it more explicit that
> rules went the same place. PF uses some clever skip ahead to gain the
> speed that proper use of groups give in IPF, and tests have shown that
> pf is faster than IPF in particular when rulesets grow large.
>
> but you need to be careful writing rules:
>
> IPF sample:
>
> block in quick from 10.0.0.0/24 to any head 10
> pass in quick from 10.0.0.0/24 to 192.168.0.0/24 group 10
>
> PF sample:
>
> block in from 10.0.0.0/24 to any
> pass in quick from 10.0.0.0/24 to 192.168.0.0/24
> block in quick from 10.0.0.0/24 to any
>
> The thing is that in the first line of the IPF sample, a default action
> is made for that group. packets matching the head rule but no rules in
> the group will take that action.
>
> In PF you'll have to include that extra rule in the end to get the same
> behavior.
>
> So, in short, ipf is really simple and comparatively easy to work with,
> the lack of macros means you generally have to write more but this also
> makes it more explicit what happens as packets traverse the ruleset.
>
> pf has some really nice features in particular in more complex setups.
> The use of macros means that you can create compact rulesets that can
> easily be adopted to other systems or setups.
>
> Use what you feel most comfortable with.
OK, I am coming from a Linux iptables world. I have a nicely working
firewall in that realm including the following nice little tidbit that
allows me to be anywhere in the world and ssh into the machine while
making ssh dictionary attacks really "expensive".
===8<---
$IPTABLES -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set
$IPTABLES -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \
--rcheck --seconds 120 --hitcount 3 -j LOG --log-prefix 'SSH REJECT: '
$IPTABLES -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \
--rcheck --seconds 120 --hitcount 3 -j REJECT --reject-with tcp-reset
===8<---
The trap allows up to three tries within a 120 second period before blocking
the IP address responsible until the tries within the last 120 seconds is
below 3. I've found that attacks will start. Then they will simply spend
an hour or two generating log entries for the rejects. (I then add the
net block for the source to another rule that blocks it entirely for ssh.)
I have similar blocks on pop3s and imaps.
Which tool would be able to do this sort of thing best and how might it
have been done.
{^_^} Joanne, getting tired of the Linux perpetual beta test.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?006001c61d47$973bccc0$1225a8c0>