Date: Mon, 30 Aug 2004 00:38:33 -0400 From: James <haesu@towardex.com> To: "Simon L. Nielsen" <simon@FreeBSD.org> Cc: FreeBSD - ipfw <freebsd-ipfw@freebsd.org> Subject: Re: Denying multiple IP's Message-ID: <20040830043833.GA41637@scylla.towardex.com> In-Reply-To: <20040824205513.GJ760@zaphod.nitro.dk> References: <412B6A23.1000708@makeworld.com> <20040824205513.GJ760@zaphod.nitro.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 24, 2004 at 10:55:13PM +0200, Simon L. Nielsen wrote:
> On 2004.08.24 11:17:39 -0500, Chris wrote:
> > I'm working with a friend of mine w/ipfw. Below are IP's that are trying
> > to hack in via ssh. I suggested to use something in the form of:
> >
> > # Allow in SFTP, SSH, and SCP from public Internet
> > ${fwcmd} add 090 pass log tcp from xxx.xxx.xxx.xxx/29 to ${ip} 22 setup
> > limit src-addr 4
> >
> > But he mentions that he needs access to his box from potential client
> > sites where the IP is unknown.
> >
> > There has to be a better way to block the below - suggestions?
>
> If you use FreeBSD -CURRENT or -STABLE (newer than 4.10 and 5.2) you
> could use the new table feature. Otherwise if you use ipfw2 you could
> use "or-blocks" e.g.
>
> ipfw deny ip from { 1.2.4.5 or 1.2.4.7 or 1.2.5.7 } to any
Good call, but unfortunately, this is not very good in performance either..
If you use latest kernel, your ipfw2 should have the lookup tables patch which
uses radix lookup. { blah or bleh or x or y or z } list is a linear lookup,
causing the system to lookup twice in linear fassion to come to a match. It is
not exactly any better in terms of performance efficiency than adding hundreds
of straight ipfw rules each with a ip address specification.
Try this if you have tables feature:
ipfw table 1 add x.x.x.x/32
ipfw table 1 add x.x.x.x/32
ipfw table 1 add x.x.x.x/32
ipfw table 1 add x.x.x.x/32
ipfw table 1 add x.x.x.x/32
ipfw table 1 add x.x.x.x/32
ipfw table 1 add x.x.x.x/32
ipfw table 1 add x.x.x.x/32
ipfw table 1 add x.x.x.x/32
ipfw table 1 add x.x.x.x/32
ipfw table 1 add x.x.x.x/32
ipfw add 300 deny ip from table(1) to any
No matter how many elements you got in table 1, due to radix/patricia trie
lookup as with kernel routing table, the time spent in looking thru firewall
elements is O(32) constant.
To demonstrate the efficiency:
Test #1: Start with 1 ipfw rule (the last rule 65535 being allow all) that
denies one ip address on the DUT. Flood the remote tester device that is not
denied by the ipfw rule. Start the test, and increment the ipfw rules from 1
to 10. Result:
1 rule: 140kpps
2 rule: 140kpps
3 rule: 138kpps
4 rule: 137kpps
5 rule: 135kpps
6 rule: 135kpps
7 rule: 132kpps
8 rule: 133kpps
9 rule: 131kpps
10 rule: 129kpps
Test #2: Perform the exact same test above, however use a lookup table to store
the elements from 1 to 10:
1 element in table: 140kpps
2 element in table: 140kpps
3 element in table: 140kpps
4 element in table: 141kpps
5 element in table: 140kpps
6 element in table: 139kpps
7 element in table: 140kpps
8 element in table: 142kpps
9 element in table: 140kpps
10 element in table: 140kpps
>
> or something like that.
>
> In any case there is probably no need to have sperate tcp/udp rules,
> you could just use "ip" and block all traffic from the IP's.
>
> > #
> > # IPs that seem to want to get in REALLY bad... deny all tcp/udp from IPs.
> > #
> >
> > ${fwcmd} add 300 deny tcp from 24.79.68.179 to any
> > ${fwcmd} add 301 deny udp from 24.79.68.179 to any
> > ${fwcmd} add 302 deny tcp from 64.246.20.123 to any
> > ${fwcmd} add 303 deny udp from 64.246.20.123 to any
> > ${fwcmd} add 304 deny tcp from 81.223.99.90 to any
> > ${fwcmd} add 305 deny udp from 81.223.99.90 to any
> > ${fwcmd} add 306 deny tcp from 140.112.124.123 to any
> > ${fwcmd} add 307 deny udp from 140.112.124.123 to any
> > ${fwcmd} add 308 deny tcp from 193.145.87.3 to any
> > ${fwcmd} add 309 deny udp from 193.145.87.3 to any
> > ${fwcmd} add 310 deny tcp from 203.186.157.37 to any
> > ${fwcmd} add 311 deny udp from 203.186.157.37 to any
> > ${fwcmd} add 312 deny tcp from 210.204.129.11 to any
> > ${fwcmd} add 313 deny udp from 210.204.129.11 to any
> > ${fwcmd} add 314 deny tcp from 211.60.219.250 to any
> > ${fwcmd} add 315 deny udp from 211.60.219.250 to any
> > ${fwcmd} add 316 deny tcp from 211.252.9.126 to any
> > ${fwcmd} add 317 deny udp from 211.252.9.126 to any
> > ${fwcmd} add 318 deny tcp from 218.21.129.105 to any
> > ${fwcmd} add 319 deny udp from 218.21.129.105 to any
> > ${fwcmd} add 320 deny tcp from 218.49.183.17 to any
> > ${fwcmd} add 321 deny udp from 218.49.183.17 to any
> > ${fwcmd} add 322 deny tcp from 218.102.19.78 to any
> > ${fwcmd} add 323 deny udp from 218.102.19.78 to any
> > ${fwcmd} add 324 deny tcp from 218.237.66.152 to any
> > ${fwcmd} add 325 deny udp from 218.237.66.152 to any
> > ${fwcmd} add 326 deny tcp from 221.3.131.80 to any
> > ${fwcmd} add 327 deny udp from 221.3.131.80 to any
> >
> > # Everything else is denied by default
>
> --
> Simon L. Nielsen
> FreeBSD Documentation Team
--
James Jun TowardEX Technologies, Inc.
Technical Lead Network Design, Consulting, IT Outsourcing
james@towardex.com Boston-based Colocation & Bandwidth Services
cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040830043833.GA41637>