From: David H. <dho...@gm...> - 2009-07-03 15:02:27
|
On Fri, Jul 3, 2009 at 5:35 AM, Mij<mi...@bi...> wrote: > Shalom, > > few months of delay are not too bad :) > > for paste #1: please do > 1) verify "yacc" and "lex" (or bison/flex) are available on your system > 2) in sshguard dir, do make clean > 3) remove src/attack_parser.c src/attack_parser.h and src/ > attack_scanner.c > 4) re- ./configure with your relevant params > 5) make > > then re-try. > > > paste #2 is more subtle and interesting: > notice the following excerpt: > >> $1 = token HOSTADDR () >> Could not resolve hostname 'tech.dyn.berkeley.edu >> <http://tech.dyn.berkeley.edu>' in IPv4 address: Unknown host. >> Could not resolve hostname 'tech.dyn.berkeley.edu >> <http://tech.dyn.berkeley.edu>' in IPv6 address: Unknown host. >> Could not resolve hostname 'tech.dyn.berkeley.edu >> <http://tech.dyn.berkeley.edu>' in IPv4 nor IPv6 address! >> Stack now 0 1 6 > > the parser of SSHGuard distinguishes when addresses are provided as > host names, as in this case. As eventually firewalls want raw > addresses, not > hostnames, SSHGuard resolves in real time the hostnames it finds to > their > IP. > In this case, there's some strange stuff going on on your machine: > 1) your sshd receives a connection from a machine > 2) for log readability, it reverse-translates the IP address to its > hostname. > 3) presumably your DNS server reverses such IP address to > "tech.dyn.berkeley.edu <http://tech.dyn.berkeley.edu>", which is not a > proper > domain name. > 4) therefore, when you try to resolve the domain again to the address, > this > fails. Of course, SSHGuard can't then do anything about it. There are some interesting things going on here, and I have seen this behavior on my machine as well. Here are the case scenarios I have found. 1) Attacking host (IPv4 or IPv6) has a reverse name associated, (.in.addr.arpa/ip6.arpa), but no forward address (A/AAAA) record. Very easy to setup for the attacker in either ipv4 or ipv6 address scenarios. 2) Attacking host (IPv4) has a reverse name associated, (.in.addr.arpa), but only a forward address using IPv6 (AAAA) record. 3) Attacking host (IPv6) has a reverse name associated, (.ip6.arpa), and both a (IPv4) A record, and a (IPv6) AAAA record, sshguard prefers the ipv4 record, thus the block fails since the attack is happening over IPv6. 4) Attacking host (IPv4 or IPv6) has a reverse name associated for SOMEONE ELSES host (say www.google.com), (.in.addr.arpa/ip6.arpa), causing a potential (depending on firewall used) denial of service by disallowing communications with OTHER sites. This is the really sneaky/evil one. Of course there is a simple solution (although not elegant yet) of adding the following directive to sshd_config for those using openssh: LogLevel DEBUG2 This causes sshd to NOT perform reverse lookups on entries sent to "AUTH" syslog facility, and just provides raw addresses. Of course DEBUG2 causes lots of other log entries and can be quite noisy, so watch your log sizes and setup a sane log archive config. I have been meaning to dig into the openssh code and see if there is some other directive that would just do what is needed without the full DEBUG2 logging, but have not had the time yet. Good Luck -_Dave > > > On Apr 22, 2009, at 24:32 , Adam Cohen wrote: > >> sshguard 1.4rc3 on rhel5 >> >> My first host is up and running great and today I went to install to a >> second host. But I must have missed documenting a step in my process >> because I'm having an issue. Looks like the IP address isn't being >> parsed out the log message correctly. Here's a simple example, >> running >> from the command line with debug: >> >> [root@ebi-prod01 sbin]# sshguard -d -a 2 -p 10 >> Started successfully [(a,p,s)=(2, 10, 1200)], now ready to scan. >> Apr 21 14:11:00 ebi-prod01 sshd[21594]: Failed password for adam from >> 128.32.152.8 port 61158 ssh2 >> Starting parse >> Entering state 0 >> Reading a token: --accepting rule at line 96 ("Apr 21 14:11:00 >> ebi-prod01 sshd[21594]:") >> Next token is token SYSLOG_BANNER_PID () >> Shifting token SYSLOG_BANNER_PID () >> Entering state 1 >> Reading a token: --accepting rule at line 169 (" ") >> --accepting rule at line 113 ("Failed password for adam from ") >> Next token is token SSH_LOGINERR_PREF () >> Shifting token SSH_LOGINERR_PREF () >> Entering state 6 >> Reading a token: --accepting rule at line 159 ("128") >> Next token is token INTEGER () >> Error: popping token SSH_LOGINERR_PREF () >> Stack now 0 1 >> Error: popping token SYSLOG_BANNER_PID () >> Stack now 0 >> Cleanup: discarding lookahead token INTEGER () >> Stack now 0 >> >> I've tried modifying the input but only get a reasonable response >> when I >> use a hostname: >> >> [root@ebi-prod01 sbin]# sshguard -d -a 2 -p 10 >> Started successfully [(a,p,s)=(2, 10, 1200)], now ready to scan. >> Apr 21 14:11:00 ebi-prod01 sshd[21594]: Failed password for adam from >> tech.dyn.berkeley.edu <http://tech.dyn.berkeley.edu> port 51152 ssh2 >> Starting parse >> Entering state 0 >> Reading a token: --accepting rule at line 96 ("Apr 21 14:11:00 >> ebi-prod01 sshd[21594]:") >> Next token is token SYSLOG_BANNER_PID () >> Shifting token SYSLOG_BANNER_PID () >> Entering state 1 >> Reading a token: --accepting rule at line 169 (" ") >> --accepting rule at line 113 ("Failed password for adam from ") >> Next token is token SSH_LOGINERR_PREF () >> Shifting token SSH_LOGINERR_PREF () >> Entering state 6 >> Reading a token: --accepting rule at line 158 ("tech.dyn.berkeley.edu >> <http://tech.dyn.berkeley.edu>") >> Next token is token HOSTADDR () >> Shifting token HOSTADDR () >> Entering state 40 >> Reducing stack by rule 18 (line 115): >> $1 = token HOSTADDR () >> Could not resolve hostname 'tech.dyn.berkeley.edu >> <http://tech.dyn.berkeley.edu>' in IPv4 address: Unknown host. >> Could not resolve hostname 'tech.dyn.berkeley.edu >> <http://tech.dyn.berkeley.edu>' in IPv6 address: Unknown host. >> Could not resolve hostname 'tech.dyn.berkeley.edu >> <http://tech.dyn.berkeley.edu>' in IPv4 nor IPv6 address! >> Stack now 0 1 6 >> Cleanup: popping token SSH_LOGINERR_PREF () >> Cleanup: popping token SYSLOG_BANNER_PID () >> >> I've also recompiled and replaced the binary to no avail. I am afraid >> that I did see this symptom at one point during my first installation >> but I have no notes on what cleared the problem. Any suggestions? >> >> thanks >> Adam >> >> -- >> Adam Cohen / IT Manager >> Energy Biosciences Institute / UC Berkeley >> 109 Calvin Lab / 510-642-7709 >> >> >> ------------------------------------------------------------------------------ >> Stay on top of everything new and different, both inside and >> around Java (TM) technology - register by April 22, and save >> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. >> 300 plus technical and hands-on sessions. Register today. >> Use priority code J9JMT32. http://p.sf.net/sfu/p >> _______________________________________________ >> Sshguard-users mailing list >> Ssh...@li... >> https://lists.sourceforge.net/lists/listinfo/sshguard-users > > > ------------------------------------------------------------------------------ > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users > |