Bug#330827: IP vetting is weak, allowing targetted DoS via usernames
On Mon, Oct 03, 2005 at 10:20:23PM -0700, Joshua Rodman wrote:
> What was done before was the line was scanned for anything which
> resembles an IP address. What I am suggesting is a regex which
> specifies where in the line the IP address should be.
how would you specify "where"? if you are thinking about something like
from or fixed position, that will not work, because
intruder can provide a login name with "from " and log line is
Oct 4 09:41:14 sonyboy sshd[18226]: Invalid user from 10.0.0.1 from 127.0.0.1
Oct 4 09:41:14 sonyboy sshd[18226]: Failed none for invalid user from 10.0.0.1
from 127.0.0.1 port 52417 ssh2
So, as I said, I don't see a generic way around that besides using fully
specified regex'es. May be upstream will have something nice in mind
To say the truth python regexes are not that diificult. May be I should
provide a "crash-course" on them in 5-10 lines in the config file
describing used by me constructs. Something like
Symbols:
[...] -- set of symbols
\S -- non-space symbol
. -- any symbol
Enumerators:
? -- 0 or 1 occurance of patter
* -- 0 or more occurances of previous regex
{n,m} -- from n to m occurances of the pattern
Grouping:
| -- logical OR -- matching any of the mentioned patterns within a
group
(?:...) -- group which doesn't enter the set of numbered/named groups
(?P...) -- named as "name1" group. Curently all named groups are
considered as placeholders of IP addresses
Would it make easier to grasp failregex'es now?
--
.-.
=-- /v\ =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
pgpq4pDQIGgUq.pgp
Description: PGP signature
Bug#330827: IP vetting is weak, allowing targetted DoS via usernames
On Mon, Oct 03, 2005 at 10:24:09PM -0400, Yaroslav Halchenko wrote: > Besides that regular users or sysadmins are not even supposed to "tune" > failregex to have basic functionality to be performed. Me (and the upstream) > author are going to incorporate or at least include in the package more > of the configurations for different servers (imap, smtp, etc). Perhaps, but maybe i'm maintaining my own ssh, or I add an additional service not managed by debian. Admittedly I'd really like to have it "just work" and not think about it too much. > > Is this a reasonable approach? > > > 1) Regex which identifies a false login. This can be as simple as > > before. If someone logs in as "illegal user" to create a false > > positive, so be it. > > > 2) Second pattern which simply identifies the IP address component > > of the line. > > Well - that is how it was done before, and lead to the security breach. What was done before was the line was scanned for anything which resembles an IP address. What I am suggesting is a regex which specifies where in the line the IP address should be. I am assuming that these errors place the IP address in an obvious and known location, and that seperating this scan from the identification of the lines with the error will simplify such a regex. This assumption might be wrong. -josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330827: IP vetting is weak, allowing targetted DoS via usernames
On Mon, Oct 03, 2005 at 06:37:36PM -0700, Joshua Rodman wrote: > 1) The package does not on install make it clear (at least with my > debian configuration) that replacing the configuration file is > necessary to close the bug. Totally agree - I should've at least "echo" warning in postinst script. Heh heh... that is sad that I'm not a DD yet, so all my uploads have to go through a sponsor, and that delays uploads some times and I don't want to bother him too often. I will add notification but it I am not sure when new version makes its way to the Debian repository. At least anyone who uses my local repository will get it ;-) > I'm not even sure how this would be done in the debian world, save > perhaps an email to the system owner? I think that it is common to just produce a warning message to the stdout. I need to check, may be dev debian documents or policy has something regarding such cases > 2) The regex is not verifiable nor even understandable by me. I > accept that sophisticated regex has its place, but it is effectively a > bit of a programming language, and I think configfiles should not > really contain significant chunks of code, especially ones that are > moderately opaque. Indeed... it is a bit cryptic because I am damn pragmatic programmer, so I hate code duplication. That is why I had such approach to build regexp as well -- now I don't have 3 or 4 simpler failregex'es with the common base, which I would need to correct in all of them if I detect a bug. Rather I have a single regex. Besides that, using full-featured regexp engine of python provides another advantage of being able to create complex match patterns if such are necessary. May be I should place txt2regex among "Suggest:"? That one is quite nice to help anyone to build a regexp (including for python) Besides that regular users or sysadmins are not even supposed to "tune" failregex to have basic functionality to be performed. Me (and the upstream) author are going to incorporate or at least include in the package more of the configurations for different servers (imap, smtp, etc). > Is this a reasonable approach? > 1) Regex which identifies a false login. This can be as simple as > before. If someone logs in as "illegal user" to create a false > positive, so be it. > 2) Second pattern which simply identifies the IP address component > of the line. Well - that is how it was done before, and lead to the security breach. 2nd pattern was a generic pattern for an IP address, and that is why all substrings containing IP address were matched, including in the placeholders of the usernames. I don't see sufficiently generic way to employ in 2) besides scanning the whole line for IP address, unless I use full regexp as I did. By employing regexp to match the logged line, I eliminated such possibility and made it more or less generic, thus I had minimal amount of real code of fail2ban to change to make it work. I open for more specific suggestions on how to make it work in a cleaner way ;-) > Should I be sending these to the upstream author, or will he/she > probably see all this anyway. I will update him as soon as he gets back in touch (he is away at the moment), so it would be better if you just trust be on that ;-) He might have some better idea on how to handle this case as well ;-) > Aside: Many thanks to my debian maintainers. I should buy you all a > beer. cyber-beer -- yammy ;-)) Thanx -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpoCZWXxZYVE.pgp Description: PGP signature
Bug#330827: IP vetting is weak, allowing targetted DoS via usernames
On Sat, Oct 01, 2005 at 03:04:20AM -0400, Yaroslav Halchenko wrote: > Hi Joshua, > > Thank you for you feedback. If you have a moment > could you please give a try to the "fixed" revision. I've placed in > changelog entry which states that it is necessary to update config file > to have the breach closed > > http://itanix.rutgers.edu/rumba/dists/unstable/perspect/binary-all/net/fail2ban_0.5.4-5pre1_all.deb > > Do you think that the solution I've proposed is sufficient to close the > bug? Hi Yaroslav, sorry for my uselessly late reply. The approach should work but I have two concerns. Please consider them yourself. 1) The package does not on install make it clear (at least with my debian configuration) that replacing the configuration file is necessary to close the bug. I'm not even sure how this would be done in the debian world, save perhaps an email to the system owner? 2) The regex is not verifiable nor even understandable by me. I accept that sophisticated regex has its place, but it is effectively a bit of a programming language, and I think configfiles should not really contain significant chunks of code, especially ones that are moderately opaque. I'm sure I could go to some effort to read the python regex docs to find out what is going on there, but I was hoping for something that would be apparent to any admin so it could be vetted and/or updated as necessary. Is this a reasonable approach? 1) Regex which identifies a false login. This can be as simple as before. If someone logs in as "illegal user" to create a false positive, so be it. 2) Second pattern which simply identifies the IP address component of the line. I think these can both be kept simple. Should I be sending these to the upstream author, or will he/she probably see all this anyway. Aside: Many thanks to my debian maintainers. I should buy you all a beer. -josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330827: IP vetting is weak, allowing targetted DoS via usernames
Hi Joshua, Thank you for you feedback. If you have a moment could you please give a try to the "fixed" revision. I've placed in changelog entry which states that it is necessary to update config file to have the breach closed http://itanix.rutgers.edu/rumba/dists/unstable/perspect/binary-all/net/fail2ban_0.5.4-5pre1_all.deb Do you think that the solution I've proposed is sufficient to close the bug? Thank you in advance for your reply -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpdtBElGrOGj.pgp Description: PGP signature
Bug#330827: IP vetting is weak, allowing targetted DoS via usernames
> Thank you for raising the issue. Indeed that is a grave problem. > Unfortunately upstream author is away for a week or two, thus I will try > to resolve the issue on my own. I think that I will simply incorporate > regex for IPs inside failregex config options, thus IP addresses will > not be harvested blindly from the log line, but rather provided by the > failregex's group(). Do you see any possible problems with such > approach? Please advise. If it sounds feasable I will have the bug fixed > asap I don't mean to sound overly alarmist with my choice of grave. It's just the lowest level I saw security concerns listed. I suspect the approach followed by this app will have other minor security concerns and is probably not viable for production grade deployment at this time. I almost feel the docs should warn this, but whatever. I think essentially the log watcher should be sufficiently constrained to match the line as closely as possible. I am not certain how changable log file formats are, but I perhaps a regex rule that matches just the IP address section of the particular log format is in order? Personally I have a strong distrust for complex regex though. This isn't very useful. If I had a clearer productive plan for how to fix it I probably would ahve contributed patches. Sorry. -josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330827: IP vetting is weak, allowing targetted DoS via usernames
Dear Joshua, Thank you for raising the issue. Indeed that is a grave problem. Unfortunately upstream author is away for a week or two, thus I will try to resolve the issue on my own. I think that I will simply incorporate regex for IPs inside failregex config options, thus IP addresses will not be harvested blindly from the log line, but rather provided by the failregex's group(). Do you see any possible problems with such approach? Please advise. If it sounds feasable I will have the bug fixed asap -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpjETsyGIR7u.pgp Description: PGP signature
Bug#330827: IP vetting is weak, allowing targetted DoS via usernames
Package: fail2ban Version: 0.5.2-4 Severity: grave fail2ban's approach to identifying an IP address in a login failure line is to scan the line for all IP addresses. Since it is possible to generate false logins from accounts such as 10.2.28.2, it is possible to force fail2ban to block access to addresses which are not attempting to connect to the system. For each IP address available to the attacker, a desired ip address may be blocked. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.10-jsr Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US.iso88591) Versions of packages fail2ban depends on: ii iptables 1.3.3-2Linux kernel 2.4+ iptables adminis ii python2.3.5-3An interactive high-level object-o fail2ban recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
