[Modsecurity] Rules for rulsets

Sat Jun 24 01:22:20 EDT 2006

Hello, and thank you for taking the time to respond...
Quoting Brian Rectanus:

> On 6/23/06, Chris H. wrote:
>> Hello,
>> I also wondered a little about beginning and ending IP's with 2,
>> as well as 1 IP. Given your experience, can I assume that since I
>> begin and end this list with 3 that those in the middle won't run
>> into trouble eg; matching additional numbers at either end of their range?
>> Here's my current list:
>>
>> SecFilterSelective REMOTE_ADDR \
>> "^(194.72.238.10|194.72.238.13|194.72.238.14|194.72.238.15|194.72.238.16|194.72.238.19|194.72.238.62|194.72.238.61|83.138.189.100|83.138.190.203|194.72.238.11|69.20.95.4|65.61.188.4|216.145.17.190|66.249.4.251|64.246.161.26|209.59.193.17|64.246.165.245|69.28.247.250|61.54.16.6|164.125.118.29|66.34.236.1|219.84.169.236|62.29.136.20|81.176.76.47|66.49.214.139|12.215.94.57|80.239.107.45|194.72.238.62|82.135.33.98|82.127.23.55|219.64.36.34|69.60.110.111|202.159.115.138|221.217.184.131|60.239.12.98|222.107.35.143|82.83.212.125|199.227.64.94|203.250.148.13|84.97.214.143|69.120.1.128|210.224.164.36|162.129.37.180|80.53.80.182|80.81.122.177|83.16.187.6|82.134.230.32|62.40.150.221|219.83.54.52|193.92.9.19|202.84.115.11|209.121.67.172|124.0.225.70|62.40.150.221|219.134.212.207|222.51.213.172|220.162.129.197|140.125.20.107|202.58.85.6|203.200.93.155|194.68.63.142|62.20.220.70|66.77.128.77|195.205.178.230|208.138.21.64|200.27.187.52|66.224.214.11|218.11.207.244|210.87.251.106|213.114!
 .21!
>>  
>> .63|200.61.183.237|201.12.106.2|62.178.210.9|204.83.56.144|69.95.136.131|84.58.232.52|207.90.211.54|70.168.74.193|69.17.157.154|210.3.4.193|68.87.72.169|66.161.95.147|217.58.71.101|69.94.80.15|172.192.99.104|147.202.43.153|216.7.168.224|83.14.11.178|81.7.76.61|212.100.254.113|206.71.166.2|85.14.216.209|210.253.120.121|81.91.225.142|211.115.70.163|59.49.233.25|69.13.31.57|129.8.238.39|211.100.33.61|211.115.70.163|211.100.33.61|61.183.15.41|132.248.200.16|200.46.107.131|61.97.32.12|69.17.157.154|70.168.74.193|207.90.211.54|220.170.53.194|220.123.171.125|61.60.21.226|61.135.159.152|61.135.170.153|81.223.25.117|69.19.225.155|61.134.32.18|61.185.208.83|59.124.127.103|164.77.238.114|66.34.240.128|211.214.161.239|61.183.15.41|211.100.33.61|85.112.145.11|220.64.88.9|24.128.223.238|66.77.128.77|67.50.47.52|62.116.40.112|150.101.121.80|62.116.40.112|200.122.153.10|68.87.76.152|69.41.54.49|12.193.208.2|212.68.193.242|196.40.43.78|199.170.103.17|218.189.215.178|80.53.0.29|201.243.180!
 .1!
>>  28|60.236.29.243|203.177.167.195|201.45.178.36|61.178.21.179|2!
>>  16.102.2
>> 12.115|131.220.92.80|65.40.8.141|220.181.9.119|210.82.46.66|207.210.86.105|202.83.32.124|66.81.231.52|66.17.15.154|38.99.203.110|201.18.140.207|62.252.64.30|203.124.171.20|38.99.203.110|61.97.32.12|192.91.171.36|219.117.251.138|72.18.195.161|38.99.203.110|212.36.65.144|72.18.195.161|68.185.24.2|220.227.125.124|220.194.57.112|216.235.153.4|203.125.140.52|82.231.38.27|61.135.170.159|83.138.146.85|64.91.231.91|202.138.112.252|209.97.203.36|64.92.201.114)$"
>>
>> Is it safe?
>>
>> Thank you for your consideration.
>>
>> --Chris
>>
>
> As long as you use ^ and $ and \. there cannot be any additional
> matching by pre/appending digits.
Understood. I'm pretty good with RE after all these years. But I'm
always working on too many things at once and am afraid I'm going to
overlook something. I'm /especially/ concerned in this case; as I
could so easily block an _enormeous_ number of innocent hosts/ IP's.
So I always feel more comfortable getting a second opinion.
>
> I don't think it is any faster (and may be slower) to used a large OR
> list like that.  In any case, I would split them up into single rules,
> each blocked with ^ and $ just because it is more maintainable and
> less prone to miss some small error in the RE.  I *do* think that
> using the ^ and $ *is* faster than without, though, because often you
> can short circuit the match on the first character instead of trying
> to shift the RE around for an internal match.
Agreed. The reason I was more inclined to use such a long OR here,
is that I was able to use a long unescaped, space seperated string
on a directory access rule set in Apache. And, since I maintained it
chronolocically, left to right. It made it easy to retire the older
ones. It was also a snap to convert it to a RE rule in my editor with
a search and replace RE; replacing the spaces with the OR (pipe).
>
> If you want better speed, and don't care for maintenance, then try
> something like this for each subnet (untested):
>
> SecFilterSelective REMOTE_ADDR "^194\.72\.238\." chain
> SecFilterSelective REMOTE_ADDR "(?:1[034569]|6[12])$"
Agreed. I'm only in need of two blocks which I'm implimenting
in just such a fashon. But instead of a small 8 I need to block
an entire C block (255 IP's).
>
> Which would (more efficiently?) match all of these:
>
> 194.72.238.10
> 194.72.238.13
> 194.72.238.14
> 194.72.238.15
> 194.72.238.16
> 194.72.238.19
> 194.72.238.61
> 194.72.238.62
>
> But, is *much* less readable then 8 separate rules and going to be
> more prone to errors.  As Mike wrote, RBLs are the way to go for large
> lists, though.
Indeed. It might interest you to know that I'm setting up a box
at this momment that will be providing a PRBL for just such actions.
I should have it live no later than Monday. DNS is our primary service
so this seemed a natural. However, I also have to upgrade our other
50 servers and build custom kernels for them at the same time. So
now perhaps you might understand what I meant by "always doing too
many things at once" - see; my plate is full. ;)

Thank you very much for taking the time to respond.

--Chris

>
> -B
> _______________________________________________
> Modsecurity mailing list
> Modsecurity at gotroot.com
> http://lists.gotroot.com/mailman/listinfo/modsecurity
>

-- 
panic: kernel trap (ignored)

-----------------------------------------------------------------
FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006
/////////////////////////////////////////////////////////////////

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: PGP Digital Signature
Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20060623/5f903ca9/attachment.bin 