From: Tom H. <to...@wh...> - 2013-04-18 09:03:20
|
On 04/18/2013 10:10 AM, Yoyo Yoyomaster wrote: > > Hello, > > Once again thanks to take some time to help me. > I saw an example of regexp here : > http://blog.pastoutafait.org/billets/Prot%C3%A9ger-un-serveur-avec-Fail2ban > The guy uses this type of regexp : > > <HOST> - - \[.*?\] ".*(PMA|phpmyadmin|myadmin|mysql|mysqladmin|sqladmin|mypma|admin|xampp|mysqldb|mydb|db|dbadmin|pmadb|phpmyadmin1|myadmin2).*" 301 .* > > I like this way to write a regexp in my case because with only one > regexp I would be able to filter the great part of attacks my company's > server receive. > So for example, I would like to use this type of regexp : > <HOST> - - \[.*?\] > ".*(c_id=|concat|phpinfo|gif\.php|proxy|port=|protocol=|select\/|insert\/|update\/|delete\//from\/|=import|\*\*|w00tw00t|PMA|myadmin|mysql|mysql|sql|mypma|admin|xampp|mydb|dbadmin).*".* > And so on... > I want to add other patterns to increase the efficiency of the regexp. > I don't really want to writer 1 regexp for 1 pattern, even if it is less > readable. This is a bad idea. You originally said that you are not that good with regular expressions, and now you want to make the regexes you use a lot more difficult because you want to 'optimize' stuff that probably doesn't need optimisation. Only after you see that fail2ban actually slows down because of your regexes, and you can actually prove (by profiling the code) that it's the regexes that create a performance bottleneck (and not f.i. i/o related to accessing the log files which is a low more probable), you should improve efficiency of the regexes. See [1] for details. Please write the regexes in a way that keeps them understandable to the person maintaining them (i.e. you!). In case of an emergency (f.i. a false positive), you'll need to fix the regex quickly or disable everything. You probably won't have time to consult this list for help. Also, it would be better if you'd kept separate regexes or jails for separate offences: an sql injection attack is something else than testing for a non-updated web application. It's nice to see which attacks are actually happening, and if you make one jail that blocks everything (named php-badguys-trying-all-kinds-of-shit or equivalent) you won't be able to differentiate between the different issues. [1] https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize Kind regards, Tom |