Re: SSH Brute Force Attacks Abound - and thanks!
On 1/10/08, Ken [EMAIL PROTECTED] wrote: snip I never see anything like that, since my pf rules only allow me to ssh back to home from my work IP range. In the space of about 15 minutes before I enabled pf all of the following users were tried, probably by an automated script: snip It appears to just be some bot going around that masks itself under various IP's and nothing more intelligent. When I moved my SSH port to port 23 (via pf and a redirect), all of that stopped. While moving the SSH port doesn't help much against anyone running an nmap scan, it stops blind port 22 scans that run generic password hacks and filling your logs with crap, --Kenny
Re: SSH Brute Force Attacks Abound - and thanks!
Kennith Mann III wrote: ... While moving the SSH port doesn't help much against anyone running an nmap scan, it stops blind port 22 scans that run generic password hacks and filling your logs with crap, Overloads help a bit: pass in on $ext_if proto tcp to ($ext_if) port ssh flags S/SA keep state (max-src-conn 4, \ max-src-conn-rate 2/60, overload bruteforce \ flush global) Regarding the logs, one thing that worked in the past was giving the netblock owner a hard time. It's their responsibility. It's not too hard to make up a shellscript (or use another scripting language) which automates a daily report and the complaint. Regards, -Lars
Re: : SSH Brute Force Attacks Abound - and thanks!
On Fri, Jan 11, 2008 at 09:28:57AM +, Khalid Schofield wrote: put this in pf.conf Is not this missing from the recipe:? block quick from ssh-bruteforce pass in on $ext_if proto tcp from any to ($ext_if) port ssh \ flags S/SA keep state \ (max-src-conn-rate 3/30, overload ssh-bruteforce flush global) :) enjoy On 10 Jan 2008, at 21:53, Ken wrote: A practical example, real life, last night. I was replacing my hard drive on my home broadband OBSD firewall, and it was taking a few minutes to copy over the old pf.conf and enable the firewall. I had installed the latest snapshot as a fresh image and restarted. It took a little while to set up the local networks, and I was connected to the Internet, so I could download packages. I copied over the pf.conf from my backup host and enabled it, not thinking much more about it. Then this morning I looked at /var/log/authlog to see stuff like this: Jan 9 18:00:01 home-fw newsyslog[6065]: logfile turned over Jan 9 18:03:03 home-fw sshd[29544]: Invalid user andrew from 125.16.26.123 Jan 9 18:03:03 home-fw sshd[240]: input_userauth_request: invalid user andrew Jan 9 18:03:03 home-fw sshd[29544]: Failed password for invalid user andrew from 125.16.26.123 port 52447 ssh2 Jan 9 18:03:03 home-fw sshd[240]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:06 home-fw sshd[19514]: Invalid user adam from 125.16.26.123 Jan 9 18:03:06 home-fw sshd[15864]: input_userauth_request: invalid user adam Jan 9 18:03:06 home-fw sshd[19514]: Failed password for invalid user adam from 125.16.26.123 port 52651 ssh2 Jan 9 18:03:06 home-fw sshd[15864]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:08 home-fw sshd[18110]: Invalid user trial from 125.16.26.123 Jan 9 18:03:08 home-fw sshd[22493]: input_userauth_request: invalid user trial Jan 9 18:03:09 home-fw sshd[18110]: Failed password for invalid user trial from 125.16.26.123 port 52821 ssh2 Jan 9 18:03:09 home-fw sshd[22493]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:11 home-fw sshd[20596]: Invalid user calendar from 125.16.26.123 Jan 9 18:03:11 home-fw sshd[8582]: input_userauth_request: invalid user calendar Jan 9 18:03:11 home-fw sshd[20596]: Failed password for invalid user calendar from 125.16.26.123 port 53011 ssh2 Jan 9 18:03:12 home-fw sshd[8582]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:14 home-fw sshd[22151]: Invalid user poq from 125.16.26.123 Jan 9 18:03:14 home-fw sshd[17137]: input_userauth_request: invalid user poq Jan 9 18:03:14 home-fw sshd[22151]: Failed password for invalid user poq from 125.16.26.123 port 53199 ssh2 I never see anything like that, since my pf rules only allow me to ssh back to home from my work IP range. In the space of about 15 minutes before I enabled pf all of the following users were tried, probably by an automated script: AaliyahAaron Aba Abel Exit Jewel Zmeu Zmeu adam adam add adm admin admin admin admin admin admin admin adminsadminsadrian alan alex alin alina alinusamanda andreiandrew angel apachearon at backupbnc bran brett cafe calendar cap cgi ch cmd com danny data david dulap fernando fluffyftpgames george getguest guest hacker haxor hk http httpd hyid ident if info info internet ircisit john kathi kaytenldap library linux lp luis mail mail mailman master maxmichael michael michi mikaelmike mike mysql mysql netnetwork news news nick octavio open oper oracle orgparty paul paul pepgsql pgsql plplay poqpostfix postmaster print psybncradu resin rex richard richardrobertrpm sales samba sara search sef sex sgisharonshell shell shop squid sshstan station stef stephen stevensunny sunsunsusan suva suzukitavi technicom telnettest test test test test trial trib uk unix unseenus user user username username users webwebadmin webmaster webmaster webpopword www-data wwwrunwwwrun yahoo za What a cesspool the internet is! Good passwords, limit access to where it is necessary, and run an ironclad OS. Thanks for making it all possible. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: SSH Brute Force Attacks Abound - and thanks!
On Fri, Jan 11 2008 at 24:11, Lars Nood?n wrote: Kennith Mann III wrote: ... While moving the SSH port doesn't help much against anyone running an nmap scan, it stops blind port 22 scans that run generic password hacks and filling your logs with crap, Overloads help a bit: pass in on $ext_if proto tcp to ($ext_if) port ssh flags S/SA keep state (max-src-conn 4, \ max-src-conn-rate 2/60, overload bruteforce \ flush global) Regarding the logs, one thing that worked in the past was giving the netblock owner a hard time. It's their responsibility. It's not too hard to make up a shellscript (or use another scripting language) which automates a daily report and the complaint. I always hesitate to use this trick. Could you please develop more the implications of this method? Is it still effective? Thanks! Claer
Re: SSH Brute Force Attacks Abound - and thanks!
Claer [EMAIL PROTECTED] writes: I always hesitate to use this trick. Could you please develop more the implications of this method? Is it still effective? Yes, it's still effective. You need to put in whatever values you feel are appropriate for your network and users. In Lars' example, pass in on $ext_if proto tcp to ($ext_if) port ssh flags S/SA keep state (max-src-conn 4, \ max-src-conn-rate 2/60, overload bruteforce \ flush global) any host with more than 4 simultaneous ssh connections OR that connects more than twice during any 60-second period has all their existing connections terminated, their address put into the bruteforce table and their address no longer matches the criteria for the pass rule. Those values are low enough that you might risk tripping up legitimate connections if there are enough users coming in from behind a NATing gateway, but that scenario may not be relevant for your case. What happens to connections from addresses in the bruteforce table is up to you, but I suspect a rule involving 'block quick' is very common. And yes, it's in the tutorial[1] and covered in that little book of mine[2]. - Peter [1] http://home.nuug.no/~peter/pf/en/bruteforce.html goes right to this topic, http://home.nuug.no/~peter/pf/ for a choice of formats [2] http://nostarch.com/pf.htm -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: SSH Brute Force Attacks Abound - and thanks!
http://home.nuug.no/~peter/pf/en/long-firewall.html#BRUTEFORCE Best Martin
Re: SSH Brute Force Attacks Abound - and thanks!
On Fri, Jan 11 2008 at 47:11, Peter N. M. Hansteen wrote: Claer [EMAIL PROTECTED] writes: I always hesitate to use this trick. Could you please develop more the implications of this method? Is it still effective? Yes, it's still effective. You need to put in whatever values you feel are appropriate for your network and users. In Lars' example, Sorry for not being that clear. I was talking about auto mailing whois address block abuse contacts. I already uses rate filtering. Its true that this method is still effective. Some bots starts to distribute the attacks, so the effectiveness is eroding with time. For the record, I also tried the os fingerprint trick. This one is not effective for ssh bruteforce but for antispam. For the moment, only windows 2000 os is matched frequently (around once a day for my dsl connection). Anyway, thanks for your long explanation :) Regards, pass in on $ext_if proto tcp to ($ext_if) port ssh flags S/SA keep state (max-src-conn 4, \ max-src-conn-rate 2/60, overload bruteforce \ flush global) any host with more than 4 simultaneous ssh connections OR that connects more than twice during any 60-second period has all their existing connections terminated, their address put into the bruteforce table and their address no longer matches the criteria for the pass rule. Those values are low enough that you might risk tripping up legitimate connections if there are enough users coming in from behind a NATing gateway, but that scenario may not be relevant for your case. What happens to connections from addresses in the bruteforce table is up to you, but I suspect a rule involving 'block quick' is very common. And yes, it's in the tutorial[1] and covered in that little book of mine[2]. - Peter [1] http://home.nuug.no/~peter/pf/en/bruteforce.html goes right to this topic, http://home.nuug.no/~peter/pf/ for a choice of formats [2] http://nostarch.com/pf.htm -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: SSH Brute Force Attacks Abound - and thanks!
On 2008/01/11 12:33, Lars Noodin wrote: I suppose another option is to use pf to filter out all incoming traffic to the servers originating from Windows computers you can take a look for yourself with tcpdump -O, but I think you'll find the ssh scans are more likely to be from some variety of unix. an inclusive match is usually better e.g. pass proto tcp from any os OpenBSD to port ssh
Re: SSH Brute Force Attacks Abound - and thanks!
put this in pf.conf pass in on $ext_if proto tcp from any to ($ext_if) port ssh \ flags S/SA keep state \ (max-src-conn-rate 3/30, overload ssh-bruteforce flush global) :) enjoy On 10 Jan 2008, at 21:53, Ken wrote: A practical example, real life, last night. I was replacing my hard drive on my home broadband OBSD firewall, and it was taking a few minutes to copy over the old pf.conf and enable the firewall. I had installed the latest snapshot as a fresh image and restarted. It took a little while to set up the local networks, and I was connected to the Internet, so I could download packages. I copied over the pf.conf from my backup host and enabled it, not thinking much more about it. Then this morning I looked at /var/log/authlog to see stuff like this: Jan 9 18:00:01 home-fw newsyslog[6065]: logfile turned over Jan 9 18:03:03 home-fw sshd[29544]: Invalid user andrew from 125.16.26.123 Jan 9 18:03:03 home-fw sshd[240]: input_userauth_request: invalid user andrew Jan 9 18:03:03 home-fw sshd[29544]: Failed password for invalid user andrew from 125.16.26.123 port 52447 ssh2 Jan 9 18:03:03 home-fw sshd[240]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:06 home-fw sshd[19514]: Invalid user adam from 125.16.26.123 Jan 9 18:03:06 home-fw sshd[15864]: input_userauth_request: invalid user adam Jan 9 18:03:06 home-fw sshd[19514]: Failed password for invalid user adam from 125.16.26.123 port 52651 ssh2 Jan 9 18:03:06 home-fw sshd[15864]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:08 home-fw sshd[18110]: Invalid user trial from 125.16.26.123 Jan 9 18:03:08 home-fw sshd[22493]: input_userauth_request: invalid user trial Jan 9 18:03:09 home-fw sshd[18110]: Failed password for invalid user trial from 125.16.26.123 port 52821 ssh2 Jan 9 18:03:09 home-fw sshd[22493]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:11 home-fw sshd[20596]: Invalid user calendar from 125.16.26.123 Jan 9 18:03:11 home-fw sshd[8582]: input_userauth_request: invalid user calendar Jan 9 18:03:11 home-fw sshd[20596]: Failed password for invalid user calendar from 125.16.26.123 port 53011 ssh2 Jan 9 18:03:12 home-fw sshd[8582]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:14 home-fw sshd[22151]: Invalid user poq from 125.16.26.123 Jan 9 18:03:14 home-fw sshd[17137]: input_userauth_request: invalid user poq Jan 9 18:03:14 home-fw sshd[22151]: Failed password for invalid user poq from 125.16.26.123 port 53199 ssh2 I never see anything like that, since my pf rules only allow me to ssh back to home from my work IP range. In the space of about 15 minutes before I enabled pf all of the following users were tried, probably by an automated script: AaliyahAaron Aba Abel Exit Jewel Zmeu Zmeu adam adam add adm admin admin admin admin admin admin admin adminsadminsadrian alan alex alin alina alinusamanda andreiandrew angel apachearon at backupbnc bran brett cafe calendar cap cgi ch cmd com danny data david dulap fernando fluffyftpgames george getguest guest hacker haxor hk http httpd hyid ident if info info internet ircisit john kathi kaytenldap library linux lp luis mail mail mailman master maxmichael michael michi mikaelmike mike mysql mysql netnetwork news news nick octavio open oper oracle orgparty paul paul pepgsql pgsql plplay poqpostfix postmaster print psybncradu resin rex richard richardrobertrpm sales samba sara search sef sex sgisharonshell shell shop squid sshstan station stef stephen stevensunny sunsunsusan suva suzukitavi technicom telnettest test test test test trial trib uk unix unseenus user user username username users webwebadmin webmaster webmaster webpopword www-data wwwrunwwwrun yahoo za What a cesspool the internet is! Good passwords, limit access to where it is necessary, and run an ironclad OS. Thanks for making it all possible.
Re: SSH Brute Force Attacks Abound - and thanks!
dam you seconds ahead of my reply with the same info :) On 11 Jan 2008, at 09:24, Lars Noodin wrote: Kennith Mann III wrote: ... While moving the SSH port doesn't help much against anyone running an nmap scan, it stops blind port 22 scans that run generic password hacks and filling your logs with crap, Overloads help a bit: pass in on $ext_if proto tcp to ($ext_if) port ssh flags S/SA keep state (max-src-conn 4, \ max-src-conn-rate 2/60, overload bruteforce \ flush global) Regarding the logs, one thing that worked in the past was giving the netblock owner a hard time. It's their responsibility. It's not too hard to make up a shellscript (or use another scripting language) which automates a daily report and the complaint. Regards, -Lars
Re: SSH Brute Force Attacks Abound - and thanks!
Claer wrote: On Fri, Jan 11 2008 at 24:11, Lars Nood?n wrote: ... Regarding the logs, one thing that worked in the past was giving the netblock owner a hard time. It's their responsibility. It's not too hard to make up a shellscript (or use another scripting language) which automates a daily report and the complaint. I always hesitate to use this trick. Could you please develop more the implications of this method? Is it still effective? Does it *still* work? I don't know yet, it looks like I will have to try it again though. Used to work well. But you have to establish responsiveness on the ISPs end first, usually by phone. e.g. Get a shrill, technically knowledgable woman to give them an earful a few times / break their balls. Giving the police report number helps. Once that is established then they'll be relieved to have the messages rather than the phone calls. I hadn't needed for a few years. Though back then, the number of attacks plummeted quickly. I suppose another option is to use pf to filter out all incoming traffic to the servers originating from Windows computers maybe except to relevant services like http port or https. If we could see a blanket ban on connecting Windows machines to the net, things would improve drastically. Regards -Lars
Re: SSH Brute Force Attacks Abound - and thanks!
On Fri, Jan 11, 2008 at 10:51:41AM +, Stuart Henderson wrote: On 2008/01/11 12:33, Lars Noodin wrote: I suppose another option is to use pf to filter out all incoming traffic to the servers originating from Windows computers you can take a look for yourself with tcpdump -O, but I think you'll find the ssh scans are more likely to be from some variety of unix. an inclusive match is usually better e.g. pass proto tcp from any os OpenBSD to port ssh that could be less useful if you have ipv6 connections in, no? since pf.os(5) claims only to be able to fingerprint hosts that originate an IPv4 TCP connection. but maybe the ssh client will fall back to using ipv4 if it meets that. i am unsure. jmc
Re: SSH Brute Force Attacks Abound - and thanks!
Peter N. M. Hansteen wrote: Claer [EMAIL PROTECTED] writes: I always hesitate to use this trick. Could you please develop more the implications of this method? Is it still effective? Yes, it's still effective. You need to put in whatever values you feel are appropriate for your network and users. In Lars' example, pass in on $ext_if proto tcp to ($ext_if) port ssh flags S/SA keep state (max-src-conn 4, \ max-src-conn-rate 2/60, overload bruteforce \ flush global) Actually, it's originally your example ;) since I got it from the copy of your tutorial that I printed and bound this autumn. It's been invaluable. I have your book on order via work since a while back and have been looking forward to it. ... Those values are low enough that you might risk tripping up legitimate connections if there are enough users ... I had higher for a while but have adjusted them downwards several times. Regarding NAT, FUNET apparently has complete IPv6 support and I'm waiting on info from Sonera. - Peter [1] http://home.nuug.no/~peter/pf/en/bruteforce.html goes right to this topic, http://home.nuug.no/~peter/pf/ for a choice of formats [2] http://nostarch.com/pf.htm BTW the 2008 NORDUnet conference will be in Espoo: http://www.nordu.net/conference/ndn2008web/home.html It would be a good context to promote your book, PF, and OpenBSD. Regards, -Lars
Re: : SSH Brute Force Attacks Abound - and thanks!
Yes, it more correctly needs to be one of the two following... block in log quick on $ext_if from ssh-bruteforce label BLOCKBRUTES pass in on $ext_if inet proto tcp \ from any to ($ext_if) port ssh \ flags S/SA keep state \ (max-src-conn-rate 3/30, overload ssh-bruteforce flush global) \ label BLOCKBRUTES -or- pass in on $ext_if inet proto tcp \ from !ssh-bruteforce to ($ext_if) port ssh \ flags S/SA keep state \ (max-src-conn-rate 3/30, overload ssh-bruteforce flush global) The block-pass pair has the advantage of logging the blocks. The pass notssh-bruteforce variant logs successful passes only. /Scott -Original Message- From: Raimo Niskanen [EMAIL PROTECTED] To: misc@openbsd.org Subject: Re: : SSH Brute Force Attacks Abound - and thanks! Date: Fri, 11 Jan 2008 11:12:00 +0100 Mailer: Mutt/1.5.9i Delivered-To: [EMAIL PROTECTED] On Fri, Jan 11, 2008 at 09:28:57AM +, Khalid Schofield wrote: put this in pf.conf Is not this missing from the recipe:? block quick from ssh-bruteforce pass in on $ext_if proto tcp from any to ($ext_if) port ssh \ flags S/SA keep state \ (max-src-conn-rate 3/30, overload ssh-bruteforce flush global) :) enjoy On 10 Jan 2008, at 21:53, Ken wrote: A practical example, real life, last night. I was replacing my hard drive on my home broadband OBSD firewall, and it was taking a few minutes to copy over the old pf.conf and enable the firewall. I had installed the latest snapshot as a fresh image and restarted. It took a little while to set up the local networks, and I was connected to the Internet, so I could download packages. I copied over the pf.conf from my backup host and enabled it, not thinking much more about it. Then this morning I looked at /var/log/authlog to see stuff like this: Jan 9 18:00:01 home-fw newsyslog[6065]: logfile turned over Jan 9 18:03:03 home-fw sshd[29544]: Invalid user andrew from 125.16.26.123 Jan 9 18:03:03 home-fw sshd[240]: input_userauth_request: invalid user andrew Jan 9 18:03:03 home-fw sshd[29544]: Failed password for invalid user andrew from 125.16.26.123 port 52447 ssh2 Jan 9 18:03:03 home-fw sshd[240]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:06 home-fw sshd[19514]: Invalid user adam from 125.16.26.123 Jan 9 18:03:06 home-fw sshd[15864]: input_userauth_request: invalid user adam Jan 9 18:03:06 home-fw sshd[19514]: Failed password for invalid user adam from 125.16.26.123 port 52651 ssh2 Jan 9 18:03:06 home-fw sshd[15864]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:08 home-fw sshd[18110]: Invalid user trial from 125.16.26.123 Jan 9 18:03:08 home-fw sshd[22493]: input_userauth_request: invalid user trial Jan 9 18:03:09 home-fw sshd[18110]: Failed password for invalid user trial from 125.16.26.123 port 52821 ssh2 Jan 9 18:03:09 home-fw sshd[22493]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:11 home-fw sshd[20596]: Invalid user calendar from 125.16.26.123 Jan 9 18:03:11 home-fw sshd[8582]: input_userauth_request: invalid user calendar Jan 9 18:03:11 home-fw sshd[20596]: Failed password for invalid user calendar from 125.16.26.123 port 53011 ssh2 Jan 9 18:03:12 home-fw sshd[8582]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:14 home-fw sshd[22151]: Invalid user poq from 125.16.26.123 Jan 9 18:03:14 home-fw sshd[17137]: input_userauth_request: invalid user poq Jan 9 18:03:14 home-fw sshd[22151]: Failed password for invalid user poq from 125.16.26.123 port 53199 ssh2 I never see anything like that, since my pf rules only allow me to ssh back to home from my work IP range. In the space of about 15 minutes before I enabled pf all of the following users were tried, probably by an automated script: AaliyahAaron Aba Abel Exit Jewel Zmeu Zmeu adam adam add adm admin admin admin admin admin admin admin adminsadminsadrian alan alex alin alina alinusamanda andreiandrew angel apachearon at backupbnc bran brett cafe calendar cap cgi ch cmd com danny data david dulap fernando fluffyftpgames george getguest guest hacker haxor hk http httpd hyid ident if info info internet ircisit john kathi kaytenldap library linux lp luis mail mail mailman master maxmichael michael michi mikaelmike mike mysql mysql netnetwork news news nick octavio open oper oracle orgparty paul paul pepgsql pgsql plplay poq
Re: SSH Brute Force Attacks Abound - and thanks!
On Fri, Jan 11, 2008 at 11:07:49AM +0001, Jason McIntyre wrote: | an inclusive match is usually better e.g. | pass proto tcp from any os OpenBSD to port ssh | | that could be less useful if you have ipv6 connections in, no? since | pf.os(5) claims only to be able to fingerprint hosts that originate an | IPv4 TCP connection. | | but maybe the ssh client will fall back to using ipv4 if it meets that. | i am unsure. It should fall back to v4 connections, but this is generally not what you want. In my experience (from my logs) I see that all these brute forcing lunixtics use v4 so a rule to pass v6 ssh traffic without the limitations you have for v4 should help there. You'll need to revisit that once brute forcers start using v6 but you'll be good for some time. It's like spam : I've *NEVER* seen a spammer use IPv6 so I don't filter IPv6 mail until I do. Cheers, Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: SSH Brute Force Attacks Abound - and thanks!
Re: SSH Brute Force Attacks Abound - and thanks!
Lars NoodC)n wrote: I suppose another option is to use pf to filter out all incoming traffic to the servers originating from Windows computers maybe except to relevant services like http port or https. If we could see a blanket ban on connecting Windows machines to the net, things would improve drastically. Regards -Lars In the case of ssh these days, it seems to be nearly 100% zombied Linux machines sourcing the attacks. I use a combination of overload and a Linux os block and I only have about 1-3 attackers a month that make it past the os block, then they get snared in the overload after their six tries. block drop log quick on $ext_if proto tcp from any os Linux to any port ssh label Block ssh from Linux hosts block drop log quick on $ext_if from ssh-bruteforce pass in on $ext_if proto tcp from any to $ext_if port ssh \ flags S/SA keep state \ (max-src-conn-rate 6/60, overload ssh-bruteforce flush global) YMMV. If you actually need to connect to your machines from linux, then exceptions will have to be made.
Re: SSH Brute Force Attacks Abound - and thanks!
On 2008/01/11 11:07, Jason McIntyre wrote: On Fri, Jan 11, 2008 at 10:51:41AM +, Stuart Henderson wrote: On 2008/01/11 12:33, Lars Noodin wrote: I suppose another option is to use pf to filter out all incoming traffic to the servers originating from Windows computers you can take a look for yourself with tcpdump -O, but I think you'll find the ssh scans are more likely to be from some variety of unix. an inclusive match is usually better e.g. pass proto tcp from any os OpenBSD to port ssh that could be less useful if you have ipv6 connections in, no? since pf.os(5) claims only to be able to fingerprint hosts that originate an IPv4 TCP connection. I didn't notice that about pf.os before but it's not a big surprise. random address space scans are a bit less of a problem in ipv6 though so pass in inet6 proto tcp to port ssh might be acceptable. but maybe the ssh client will fall back to using ipv4 if it meets that. i am unsure. it should do; if packets are dropped on the floor i.e. block drop it will take some time to notice (like connecting to undeadly from v6 until occaid's sixxs tunnels are back up ;-) if it's block return it should be fast.
Re: SSH Brute Force Attacks Abound - and thanks!
On 2008/01/11 12:18, Claer wrote: Sorry for not being that clear. I was talking about auto mailing whois address block abuse contacts. maybe you could get it to auto-mail *you* with the details to make it easier to send that onwards, but don't auto-mail whois contacts. you're asking people to spend time tracking down a problem and usually they will need to contact other people to get it fixed. the least you can do is manually verify that you're addressing the right person.
SSH Brute Force Attacks Abound - and thanks!
A practical example, real life, last night. I was replacing my hard drive on my home broadband OBSD firewall, and it was taking a few minutes to copy over the old pf.conf and enable the firewall. I had installed the latest snapshot as a fresh image and restarted. It took a little while to set up the local networks, and I was connected to the Internet, so I could download packages. I copied over the pf.conf from my backup host and enabled it, not thinking much more about it. Then this morning I looked at /var/log/authlog to see stuff like this: Jan 9 18:00:01 home-fw newsyslog[6065]: logfile turned over Jan 9 18:03:03 home-fw sshd[29544]: Invalid user andrew from 125.16.26.123 Jan 9 18:03:03 home-fw sshd[240]: input_userauth_request: invalid user andrew Jan 9 18:03:03 home-fw sshd[29544]: Failed password for invalid user andrew from 125.16.26.123 port 52447 ssh2 Jan 9 18:03:03 home-fw sshd[240]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:06 home-fw sshd[19514]: Invalid user adam from 125.16.26.123 Jan 9 18:03:06 home-fw sshd[15864]: input_userauth_request: invalid user adam Jan 9 18:03:06 home-fw sshd[19514]: Failed password for invalid user adam from 125.16.26.123 port 52651 ssh2 Jan 9 18:03:06 home-fw sshd[15864]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:08 home-fw sshd[18110]: Invalid user trial from 125.16.26.123 Jan 9 18:03:08 home-fw sshd[22493]: input_userauth_request: invalid user trial Jan 9 18:03:09 home-fw sshd[18110]: Failed password for invalid user trial from 125.16.26.123 port 52821 ssh2 Jan 9 18:03:09 home-fw sshd[22493]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:11 home-fw sshd[20596]: Invalid user calendar from 125.16.26.123 Jan 9 18:03:11 home-fw sshd[8582]: input_userauth_request: invalid user calendar Jan 9 18:03:11 home-fw sshd[20596]: Failed password for invalid user calendar from 125.16.26.123 port 53011 ssh2 Jan 9 18:03:12 home-fw sshd[8582]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:14 home-fw sshd[22151]: Invalid user poq from 125.16.26.123 Jan 9 18:03:14 home-fw sshd[17137]: input_userauth_request: invalid user poq Jan 9 18:03:14 home-fw sshd[22151]: Failed password for invalid user poq from 125.16.26.123 port 53199 ssh2 I never see anything like that, since my pf rules only allow me to ssh back to home from my work IP range. In the space of about 15 minutes before I enabled pf all of the following users were tried, probably by an automated script: AaliyahAaron Aba Abel Exit Jewel Zmeu Zmeu adam adam add adm admin admin admin admin admin admin admin adminsadminsadrian alan alex alin alina alinusamanda andreiandrew angel apachearon at backupbnc bran brett cafe calendar cap cgi ch cmd com danny data david dulap fernando fluffyftpgames george getguest guest hacker haxor hk http httpd hyid ident if info info internet ircisit john kathi kaytenldap library linux lp luis mail mail mailman master maxmichael michael michi mikaelmike mike mysql mysql netnetwork news news nick octavio open oper oracle orgparty paul paul pepgsql pgsql plplay poqpostfix postmaster print psybncradu resin rex richard richardrobertrpm sales samba sara search sef sex sgisharonshell shell shop squid sshstan station stef stephen stevensunny sunsunsusan suva suzukitavi technicom telnettest test test test test trial trib uk unix unseenus user user username username users webwebadmin webmaster webmaster webpopword www-data wwwrunwwwrun yahoo za What a cesspool the internet is! Good passwords, limit access to where it is necessary, and run an ironclad OS. Thanks for making it all possible.
Re: SSH Brute Force Attacks Abound - and thanks!
Wow, I read your email and checked my authlog and was astounded by the number hack attempts. Thankfully, I configured my OpenBSD firewall with recommended access controls. Thanks to all the dedicated OpenBSD developers and community! Support the project and encourage the purchase of more OpenBSD CD's and direct donations to the Foundation! --- Ken [EMAIL PROTECTED] wrote: A practical example, real life, last night. I was replacing my hard drive on my home broadband OBSD firewall, and it was taking a few minutes to copy over the old pf.conf and enable the firewall. I had installed the latest snapshot as a fresh image and restarted. It took a little while to set up the local networks, and I was connected to the Internet, so I could download packages. I copied over the pf.conf from my backup host and enabled it, not thinking much more about it. Then this morning I looked at /var/log/authlog to see stuff like this: Jan 9 18:00:01 home-fw newsyslog[6065]: logfile turned over Jan 9 18:03:03 home-fw sshd[29544]: Invalid user andrew from 125.16.26.123 Jan 9 18:03:03 home-fw sshd[240]: input_userauth_request: invalid user andrew Jan 9 18:03:03 home-fw sshd[29544]: Failed password for invalid user andrew from 125.16.26.123 port 52447 ssh2 Jan 9 18:03:03 home-fw sshd[240]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:06 home-fw sshd[19514]: Invalid user adam from 125.16.26.123 Jan 9 18:03:06 home-fw sshd[15864]: input_userauth_request: invalid user adam Jan 9 18:03:06 home-fw sshd[19514]: Failed password for invalid user adam from 125.16.26.123 port 52651 ssh2 Jan 9 18:03:06 home-fw sshd[15864]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:08 home-fw sshd[18110]: Invalid user trial from 125.16.26.123 Jan 9 18:03:08 home-fw sshd[22493]: input_userauth_request: invalid user trial Jan 9 18:03:09 home-fw sshd[18110]: Failed password for invalid user trial from 125.16.26.123 port 52821 ssh2 Jan 9 18:03:09 home-fw sshd[22493]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:11 home-fw sshd[20596]: Invalid user calendar from 125.16.26.123 Jan 9 18:03:11 home-fw sshd[8582]: input_userauth_request: invalid user calendar Jan 9 18:03:11 home-fw sshd[20596]: Failed password for invalid user calendar from 125.16.26.123 port 53011 ssh2 Jan 9 18:03:12 home-fw sshd[8582]: Received disconnect from 125.16.26.123: 11: Bye Bye Jan 9 18:03:14 home-fw sshd[22151]: Invalid user poq from 125.16.26.123 Jan 9 18:03:14 home-fw sshd[17137]: input_userauth_request: invalid user poq Jan 9 18:03:14 home-fw sshd[22151]: Failed password for invalid user poq from 125.16.26.123 port 53199 ssh2 I never see anything like that, since my pf rules only allow me to ssh back to home from my work IP range. In the space of about 15 minutes before I enabled pf all of the following users were tried, probably by an automated script: AaliyahAaron Aba Abel Exit Jewel Zmeu Zmeu adam adam add adm admin admin admin admin admin admin admin adminsadminsadrian alan alex alin alina alinusamanda andrei andrew angel apachearon at backup bnc bran brett cafe calendar cap cgi ch cmd com danny data david dulap fernando fluffyftpgames george getguest guest hacker haxor hk http httpd hyid ident if info info internet ircis it john kathi kaytenldap library linux lp luis mail mail mailman master maxmichael michael michi mikael mike mike mysql mysql netnetwork news news nick octavio open oper oracle orgparty paul paul pe pgsql pgsql plplay poqpostfix postmaster print psybncradu resin rex richard richardrobertrpm sales samba sara search sef sex sgisharon shell shell shop squid sshstan station stef stephen stevensunny sunsun susan suva suzukitavi technicom telnet test test test test test trial trib uk unix unseenus user user username username users webwebadmin webmaster webmaster webpopword www-data wwwrun wwwrun yahoo za What a cesspool the internet is! Good passwords, limit access to where it is necessary, and run an ironclad OS. Thanks for making it all possible. Never
Re: SSH brute force attacks no longer being caught by PF rule
On 2007/08/09 12:22, Joachim Schipper wrote: # Define some variable for clarity SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $ext_if inet proto tcp from ! scanners \ to $ext_if port ssh flags S/SA keep state \ $SSH_LIMIT I've added something like this to pf.conf but it's only partially successful. I would appreciate any clues as to why it's not blocking all brute-force attempts. You would probably be better served by a clue about why this is a terribly bad idea, but you'll most likely have heard all the arguments already. Or maybe not - 'flush' enables an attacker to not only prevent you connecting, but actually to log you out as well. This still needs a 3-way handshake to be completed, it's not so easy to blindly spoof. Main problem is if the attacker comes from the same IP address as a legitimate user (NAT etc). Plus, SSH scans are about as dangerous as some skiddie scanning for old versions of PHPMyAdmin, and we don't take steps to prevent the latter either. Depends how much CPU is spent handling the connections. Finally, Subversion over SSH uses lots of connections, should you ever want to use that. connection multiplexing can be useful for this sort of thing.
Re: SSH brute force attacks no longer being caught by PF rule
On 2007/08/13 12:14, Joachim Schipper wrote: This still needs a 3-way handshake to be completed, it's not so easy to blindly spoof. Main problem is if the attacker comes from the same IP address as a legitimate user (NAT etc). Yes, that is one of the main problems. The other is that it takes time to set up which would be better spent doing something useful - like setting up a log watcher. Well, this *is* useful, and much safer than some log watchers. See e.g. http://www.ossec.net/en/attacking-loganalysis.html which closes with these lines: Please be aware that a few other tools also block ssh scans, but some of them are so vulnerable that I didn't even bother mentioning. My advice is don't use tools that are shell-script based or have not been updated in a while. Not only they are vulnerable to remote DoS, but also to command execution via hosts.deny (yes, you can configure it to execute programs) and other means. Plus, SSH scans are about as dangerous as some skiddie scanning for old versions of PHPMyAdmin, and we don't take steps to prevent the latter either. Depends how much CPU is spent handling the connections. I'm fairly sure that on a modern system attached to a 100 Mbps link network capacity will run out before this becomes a problem. Between the disk writes for logging, and the crypto setup, this can bring an otherwise-useful machine to it's knees, with much less than a 100Mbps. Been there, done that, written the PF rules, at least for the affected boxes that need SSH open from all locations (note to readers: for machines where you can restrict SSH to certain IP/IPv6 addresses only, it is a Good Idea to do so). Finally, Subversion over SSH uses lots of connections, should you ever want to use that. connection multiplexing can be useful for this sort of thing. Yes, it would be, but I never got it to work reliably (Subversion likes to close connections before opening the next one, etc). Did you? If so, could you share the script/... you used? I haven't tried with svn, but you can probably ssh -N host first and leave that open until you're finished.
Re: SSH brute force attacks no longer being caught by PF rule
- Original Message - From: Stuart Henderson [EMAIL PROTECTED] To: OpenBSD misc@openbsd.org Sent: Monday, August 13, 2007 1:30 PM Subject: Re: [misc] SSH brute force attacks no longer being caught by PF rule On 2007/08/13 12:14, Joachim Schipper wrote: This still needs a 3-way handshake to be completed, it's not so easy to blindly spoof. Main problem is if the attacker comes from the same IP address as a legitimate user (NAT etc). Yes, that is one of the main problems. The other is that it takes time to set up which would be better spent doing something useful - like setting up a log watcher. Well, this *is* useful, and much safer than some log watchers. See e.g. http://www.ossec.net/en/attacking-loganalysis.html which closes with these lines: Please be aware that a few other tools also block ssh scans, but some of them are so vulnerable that I didn't even bother mentioning. My advice is don't use tools that are shell-script based or have not been updated in a while. Not only they are vulnerable to remote DoS, but also to command execution via hosts.deny (yes, you can configure it to execute programs) and other means. Plus, SSH scans are about as dangerous as some skiddie scanning for old versions of PHPMyAdmin, and we don't take steps to prevent the latter either. Depends how much CPU is spent handling the connections. I'm fairly sure that on a modern system attached to a 100 Mbps link network capacity will run out before this becomes a problem. Between the disk writes for logging, and the crypto setup, this can bring an otherwise-useful machine to it's knees, with much less than a 100Mbps. Been there, done that, written the PF rules, at least for the affected boxes that need SSH open from all locations (note to readers: for machines where you can restrict SSH to certain IP/IPv6 addresses only, it is a Good Idea to do so). Finally, Subversion over SSH uses lots of connections, should you ever want to use that. connection multiplexing can be useful for this sort of thing. Yes, it would be, but I never got it to work reliably (Subversion likes to close connections before opening the next one, etc). Did you? If so, could you share the script/... you used? I haven't tried with svn, but you can probably ssh -N host first and leave that open until you're finished. maybe somewhat off-topic, but: why don't you just switch your ssh port to a different one. we've been running with this configuration since years and a log examination of the ssh-logs and connection logs from the firewall shows that there was not even 1 (!) connect to the ssh-port from bad IPs.
Re: SSH brute force attacks no longer being caught by PF rule
* Joachim Schipper [EMAIL PROTECTED] [2007-08-13 12:25]: connection multiplexing can be useful for this sort of thing. Yes, it would be, but I never got it to work reliably (Subversion likes to close connections before opening the next one, etc). Did you? If so, could you share the script/... you used? not using subversion, but in a script that scps a lot fo files individually (possibly thousands), I use the following, which even works with older ssh without connection mux support: T=`mktemp -u /tmp/.csock-whatever-XX` sshcm=-oControlPath=$T -oControlMaster=auto ssh -N -f $sshcm $DST 2/dev/null ssh $sshcm -O check $DST 2/dev/null if [ $? -ne 0 ]; then # might be older ssh sshcm=; fi for file in ... scp $sshcm ... [error handling snipped] done ssh $sshcm -O exit $DST 2/dev/null -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: SSH brute force attacks no longer being caught by PF rule
On 2007/08/13 13:51, [EMAIL PROTECTED]@mgedv.net wrote: why don't you just switch your ssh port to a different one. In my case, because it annoys me, and max-src-conn-rate doesn't.
Re: SSH brute force attacks no longer being caught by PF rule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/13/07 5:25 AM, Stuart Henderson wrote: On 2007/08/13 13:51, [EMAIL PROTECTED]@mgedv.net wrote: why don't you just switch your ssh port to a different one. In my case, because it annoys me, and max-src-conn-rate doesn't. I concur, and would add that this fails the security-by-obscurity test. In any event, max-src-conn-rate and max-src-conn are now keeping the skiddies (or whomever) at bay. Thanks all who responded. dn iD8DBQFGwPm/yPxGVjntI4IRAib4AKCEn0kDDWy0qr9MjMcYVlRKCwVFRACgyB0i 8gwsRtzc+M0W/RwHLYNbXm0= =56Ag -END PGP SIGNATURE-
Re: SSH brute force attacks no longer being caught by PF rule
On Wed, Aug 08, 2007 at 10:26:11AM -0700, David Newman wrote:
On 6/27/07 10:39 PM, Daniel Ouellet wrote:
Put quickly as an example, but [to block SSH scans] you can try:
# Define some variable for clarity
SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global)
## SSH Hackers - blocked IPs
table scanners persist file /etc/tables/scanners
# Block ssh access to bad ssh scanner
block drop in log quick on $ext_if inet proto tcp \
from scanners to any port ssh
# Allow quick valid traffic to ssh but log all attempts as well
pass in log quick on $ext_if inet proto tcp from ! scanners \
to $ext_if port ssh flags S/SA keep state \
$SSH_LIMIT
I've added something like this to pf.conf but it's only partially
successful. I would appreciate any clues as to why it's not blocking all
brute-force attempts.
You would probably be better served by a clue about why this is a
terribly bad idea, but you'll most likely have heard all the arguments
already. Or maybe not - 'flush' enables an attacker to not only prevent
you connecting, but actually to log you out as well. (And 'global' just
makes no sense, given your ruleset.)
Plus, SSH scans are about as dangerous as some skiddie scanning for old
versions of PHPMyAdmin, and we don't take steps to prevent the latter
either.
Finally, Subversion over SSH uses lots of connections, should you ever
want to use that.
On an OBSD 4.1 box, here's what I added to pf.conf ($unpro is the
Internet-facing interface):
#
# Define limit of ssh connection rates
SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global)
# SSH scanners - blocked IPs
table scanners persist
block drop in log quick on $unpro inet proto tcp \
from scanners to any port ssh
# Allow quick valid traffic to ssh but log all attempts as well
pass in log quick on $unpro inet proto tcp from ! scanners \
to $unpro port ssh $SSH_LIMIT
Skip '! scanners' unless it's intended as documentation; you have
already filtered this traffic in the rule above.
It's not surprising that this rule fails to limit ssh connections to
another host; that's what 'to $unpro' tells pf to do, after all. If you
do remove 'to $unpro', you might want to add something like 'from !
$unpro:network'. (Do note that 'from ! { $unpro:network scanners }' is
legal syntax, but not sensible.)
#
And it appears to be working, at least in part:
[EMAIL PROTECTED] ~ 501$ sudo pfctl -t scanners -T show
5 IP addresses
#
But some hosts on the protected side of the firewall still report
brute-force ssh login attempts exceeding the 3/30 rate:
Aug 7 10:16:00 mail sshd[21608]: Invalid user trash from 201.18.81.8
23 more login attempts
Thanks in advance for suggestions as to how to reduce these kind of
login attempts.
Don't, just use public keys, or if you really must, good passwords.
Joachim
--
TFMotD: ssh-add (1) - adds RSA or DSA identities to the authentication
agent
Re: SSH brute force attacks no longer being caught by PF rule
2007/7/2, Steve B [EMAIL PROTECTED]: I'm the one who started this thread. If I can block them for an hour without a table that would be even better.. I was using the file to store the IP's as they were identified by the rule and had been planning to use the expiretable package to start clearing the table via Cron. Currently I just do it manually about once a week or so. I've read the man page for pf.confbut did not see how I could block them for a set period of time. Could someone elaborate on how this is done? expiretable: http://expiretable.fnord.se/ -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/
Re: SSH brute force attacks no longer being caught by PF rule
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/9/07 3:22 AM, Joachim Schipper wrote:
# Allow quick valid traffic to ssh but log all attempts as well
pass in log quick on $unpro inet proto tcp from ! scanners \
to $unpro port ssh $SSH_LIMIT
Skip '! scanners' unless it's intended as documentation; you have
already filtered this traffic in the rule above.
It's not surprising that this rule fails to limit ssh connections to
another host; that's what 'to $unpro' tells pf to do, after all.
Couple of clarification questions:
1. When you say skip something, you mean just delete the string '!
scanners' and not the whole rule, correct?
If you
do remove 'to $unpro', you might want to add something like 'from !
$unpro:network'. (Do note that 'from ! { $unpro:network scanners }' is
legal syntax, but not sensible.)
2. Shouldn't it be 'to $unpro:network' here since we're substituting one
'to' condition with another?
Thanks -- your comments make great sense.
dn
iD8DBQFGu03dyPxGVjntI4IRAhPoAKDW76FJ9ftepAkjUmDEnQglo0GLVACg7AV9
OzXICCdBU1TMBG3UyCbBOH4=
=yHYM
-END PGP SIGNATURE-
Re: SSH brute force attacks no longer being caught by PF rule
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/9/07 10:24 AM, David Newman wrote:
On 8/9/07 3:22 AM, Joachim Schipper wrote:
# Allow quick valid traffic to ssh but log all attempts as well
pass in log quick on $unpro inet proto tcp from ! scanners \
to $unpro port ssh $SSH_LIMIT
Skip '! scanners' unless it's intended as documentation; you have
already filtered this traffic in the rule above.
It's not surprising that this rule fails to limit ssh connections to
another host; that's what 'to $unpro' tells pf to do, after all.
Couple of clarification questions:
1. When you say skip something, you mean just delete the string '!
scanners' and not the whole rule, correct?
If you
do remove 'to $unpro', you might want to add something like 'from !
$unpro:network'. (Do note that 'from ! { $unpro:network scanners }' is
legal syntax, but not sensible.)
2. Shouldn't it be 'to $unpro:network' here since we're substituting one
'to' condition with another?
Thanks -- your comments make great sense.
Sorry, scratch question 2. Obviously 'from' is correct.
Is this what you meant:
pass in log quick on $unpro inet proto tcp \
from ! $unpro:network port ssh flags S/SA \
keep state $SSH_LIMIT
thanks
undercaffeineated dn
iD8DBQFGu07uyPxGVjntI4IRAmDFAJ0Qsd626rzFWWzexZ9AYpgL3/gXZQCg/yyG
b9Syg5d+MNO5t+yAg45t3Dw=
=/g8E
-END PGP SIGNATURE-
Re: SSH brute force attacks no longer being caught by PF rule
On Thu, Aug 09, 2007 at 10:29:19AM -0700, David Newman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/9/07 10:24 AM, David Newman wrote:
On 8/9/07 3:22 AM, Joachim Schipper wrote:
# Allow quick valid traffic to ssh but log all attempts as well
pass in log quick on $unpro inet proto tcp from ! scanners \
to $unpro port ssh $SSH_LIMIT
Skip '! scanners' unless it's intended as documentation; you have
already filtered this traffic in the rule above.
It's not surprising that this rule fails to limit ssh connections to
another host; that's what 'to $unpro' tells pf to do, after all.
Couple of clarification questions:
1. When you say skip something, you mean just delete the string '!
scanners' and not the whole rule, correct?
Yes.
If you
do remove 'to $unpro', you might want to add something like 'from !
$unpro:network'. (Do note that 'from ! { $unpro:network scanners }' is
legal syntax, but not sensible.)
2. Shouldn't it be 'to $unpro:network' here since we're substituting one
'to' condition with another?
Thanks -- your comments make great sense.
Sorry, scratch question 2. Obviously 'from' is correct.
Is this what you meant:
pass in log quick on $unpro inet proto tcp \
from ! $unpro:network port ssh flags S/SA \
keep state $SSH_LIMIT
No, more along the lines of
pass in log quick on $unpro inet proto tcp \
to port ssh keep state $SSH_LIMIT
(Note that 'flags S/SA' and 'keep state' are the default in 4.1 and
later, but 'keep state' must be explicitly given for $SSH_LIMIT -
'(max-src-conn-rate 3/30, overload scanners)' - to be legal.)
Or, if you want to add ! $unpro:network,
pass in log quick on $unpro inet proto tcp \
from ! $unpro:network to port ssh keep state $SSH_LIMIT
where my $SSH_LIMIT is different from yours, missing 'flush global'.
All of this looks a lot like IPTables-in-pf, though [1]. And only works
because you have a 'default allow' policy (the above rule does not match
on traffic from the local network, but with a 'default deny' policy this
would mean you would be unable to ssh from the local network at all.
Which is not what you want.) The way I'd write this rule would be
pass in on $unpro inet proto tcp to port ssh \
keep state (max-src-conn-rate 3/30, overload scanners)
pass in on $unpro inet proto tcp from $unpro:network to port ssh
which a) works with a 'default deny' policy, should you ever implement
one, and b) also avoid defining a macro that's only used once and does
not necessarily clarify matters.
Joachim
[1] I should know, I spent half the day writing pf-in-IPTables. Debian
is fine, for some values of fine, for webservers, but firewalls... well,
just note there's no MoTD below.
--
It can be difficult to translate into iptables the artistic intent of a
pf rule that says pass out quick on $cheap_gin
-- Anthony de Boer, in ASR
Re: SSH brute force attacks no longer being caught by PF rule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/27/07 10:39 PM, Daniel Ouellet wrote: Steve B wrote: The rule I've had in my pf.conf file to catch and block forceful SSH attempts no longer appears to be working. I see the entries in my authlog, but the IPs are no longer getting added to my table. I suspect I screwed something up, but so far I am at a loss to see where. Could someone pass another set of eyes over the relevant parts of my pf.conf? Put quickly as an example, but you can try: # Define some variable for clarity SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) ## SSH Hackers - blocked IPs table scanners persist file /etc/tables/scanners # Block ssh access to bad ssh scanner block drop in log quick on $ext_if inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $ext_if inet proto tcp from ! scanners \ to $ext_if port ssh flags S/SA keep state \ $SSH_LIMIT I've added something like this to pf.conf but it's only partially successful. I would appreciate any clues as to why it's not blocking all brute-force attempts. On an OBSD 4.1 box, here's what I added to pf.conf ($unpro is the Internet-facing interface): # # Define limit of ssh connection rates SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) # SSH scanners - blocked IPs table scanners persist block drop in log quick on $unpro inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $unpro inet proto tcp from ! scanners \ to $unpro port ssh $SSH_LIMIT # And it appears to be working, at least in part: [EMAIL PROTECTED] ~ 501$ sudo pfctl -t scanners -T show 61.146.178.13 61.189.145.103 67.76.237.190 161.200.144.108 193.254.31.194 # But some hosts on the protected side of the firewall still report brute-force ssh login attempts exceeding the 3/30 rate: Aug 7 10:16:00 mail sshd[21608]: Invalid user trash from 201.18.81.8 Aug 7 10:16:08 mail sshd[21610]: Invalid user aaron from 201.18.81.8 Aug 7 10:16:11 mail sshd[21612]: Invalid user gt05 from 201.18.81.8 Aug 7 10:16:18 mail sshd[21614]: Invalid user william from 201.18.81.8 Aug 7 10:16:22 mail sshd[21616]: Invalid user stephanie from 201.18.81.8 Aug 7 10:16:59 mail sshd[21628]: Invalid user gary from 201.18.81.8 Aug 7 10:17:07 mail sshd[21632]: Invalid user guest from 201.18.81.8 Aug 7 10:17:11 mail sshd[21634]: Invalid user test from 201.18.81.8 Aug 7 10:17:17 mail sshd[21636]: Invalid user oracle from 201.18.81.8 Aug 7 10:19:24 mail sshd[21717]: Invalid user apache from 201.18.81.8 Aug 7 10:19:43 mail sshd[21723]: Invalid user lab from 201.18.81.8 Aug 7 10:19:55 mail sshd[21729]: Invalid user oracle from 201.18.81.8 Aug 7 10:20:00 mail sshd[21736]: Invalid user svn from 201.18.81.8 Aug 7 10:20:06 mail sshd[21745]: Invalid user iraf from 201.18.81.8 Aug 7 10:20:13 mail sshd[21747]: Invalid user swsoft from 201.18.81.8 Aug 7 10:20:18 mail sshd[21749]: Invalid user production from 201.18.81.8 Aug 7 10:20:23 mail sshd[21751]: Invalid user guest from 201.18.81.8 Aug 7 10:20:28 mail sshd[21753]: Invalid user gast from 201.18.81.8 Aug 7 10:20:34 mail sshd[21755]: Invalid user gast from 201.18.81.8 Aug 7 10:20:40 mail sshd[21762]: Invalid user oliver from 201.18.81.8 Aug 7 10:20:45 mail sshd[21767]: Invalid user sirsi from 201.18.81.8 Aug 7 10:20:50 mail sshd[21769]: Invalid user nagios from 201.18.81.8 Aug 7 10:20:55 mail sshd[21771]: Invalid user nagios from 201.18.81.8 Aug 7 10:20:59 mail sshd[21773]: Invalid user nagios from 201.18.81.8 Thanks in advance for suggestions as to how to reduce these kind of login attempts. dn iD8DBQFGufyzyPxGVjntI4IRAty2AJ9WDCqLqkWyhx/KuciGINow6Upb5wCfUuP+ GfZ8lnaun1QPItnFK5c4MNU= =tjbD -END PGP SIGNATURE-
Re: SSH brute force attacks no longer being caught by PF rule
Although this doesn't answer your actual pf question, you might try using a tool called Grok (http://www.semicomplete.com/projects/grok/). It's a pretty decent log watcher written in Perl, designed to do exactly this sort of thing. You define matches and reactions in its config file (match = Illegal user %USERNAME% from %IP%; reaction = pfctl -t scanners -T add %IP%;). It does have a few quirks though. We've encountered problems with having multiple rules watching the same log. But, all in all, probably a better way to do what it looks like you want to do. - R. On 8/8/07, David Newman [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/27/07 10:39 PM, Daniel Ouellet wrote: Steve B wrote: The rule I've had in my pf.conf file to catch and block forceful SSH attempts no longer appears to be working. I see the entries in my authlog, but the IPs are no longer getting added to my table. I suspect I screwed something up, but so far I am at a loss to see where. Could someone pass another set of eyes over the relevant parts of my pf.conf? Put quickly as an example, but you can try: # Define some variable for clarity SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) ## SSH Hackers - blocked IPs table scanners persist file /etc/tables/scanners # Block ssh access to bad ssh scanner block drop in log quick on $ext_if inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $ext_if inet proto tcp from ! scanners \ to $ext_if port ssh flags S/SA keep state \ $SSH_LIMIT I've added something like this to pf.conf but it's only partially successful. I would appreciate any clues as to why it's not blocking all brute-force attempts. On an OBSD 4.1 box, here's what I added to pf.conf ($unpro is the Internet-facing interface): # # Define limit of ssh connection rates SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) # SSH scanners - blocked IPs table scanners persist block drop in log quick on $unpro inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $unpro inet proto tcp from ! scanners \ to $unpro port ssh $SSH_LIMIT # And it appears to be working, at least in part: [EMAIL PROTECTED] ~ 501$ sudo pfctl -t scanners -T show 61.146.178.13 61.189.145.103 67.76.237.190 161.200.144.108 193.254.31.194 # But some hosts on the protected side of the firewall still report brute-force ssh login attempts exceeding the 3/30 rate: Aug 7 10:16:00 mail sshd[21608]: Invalid user trash from 201.18.81.8 Aug 7 10:16:08 mail sshd[21610]: Invalid user aaron from 201.18.81.8 Aug 7 10:16:11 mail sshd[21612]: Invalid user gt05 from 201.18.81.8 Aug 7 10:16:18 mail sshd[21614]: Invalid user william from 201.18.81.8 Aug 7 10:16:22 mail sshd[21616]: Invalid user stephanie from 201.18.81.8 Aug 7 10:16:59 mail sshd[21628]: Invalid user gary from 201.18.81.8 Aug 7 10:17:07 mail sshd[21632]: Invalid user guest from 201.18.81.8 Aug 7 10:17:11 mail sshd[21634]: Invalid user test from 201.18.81.8 Aug 7 10:17:17 mail sshd[21636]: Invalid user oracle from 201.18.81.8 Aug 7 10:19:24 mail sshd[21717]: Invalid user apache from 201.18.81.8 Aug 7 10:19:43 mail sshd[21723]: Invalid user lab from 201.18.81.8 Aug 7 10:19:55 mail sshd[21729]: Invalid user oracle from 201.18.81.8 Aug 7 10:20:00 mail sshd[21736]: Invalid user svn from 201.18.81.8 Aug 7 10:20:06 mail sshd[21745]: Invalid user iraf from 201.18.81.8 Aug 7 10:20:13 mail sshd[21747]: Invalid user swsoft from 201.18.81.8 Aug 7 10:20:18 mail sshd[21749]: Invalid user production from 201.18.81.8 Aug 7 10:20:23 mail sshd[21751]: Invalid user guest from 201.18.81.8 Aug 7 10:20:28 mail sshd[21753]: Invalid user gast from 201.18.81.8 Aug 7 10:20:34 mail sshd[21755]: Invalid user gast from 201.18.81.8 Aug 7 10:20:40 mail sshd[21762]: Invalid user oliver from 201.18.81.8 Aug 7 10:20:45 mail sshd[21767]: Invalid user sirsi from 201.18.81.8 Aug 7 10:20:50 mail sshd[21769]: Invalid user nagios from 201.18.81.8 Aug 7 10:20:55 mail sshd[21771]: Invalid user nagios from 201.18.81.8 Aug 7 10:20:59 mail sshd[21773]: Invalid user nagios from 201.18.81.8 Thanks in advance for suggestions as to how to reduce these kind of login attempts. dn iD8DBQFGufyzyPxGVjntI4IRAty2AJ9WDCqLqkWyhx/KuciGINow6Upb5wCfUuP+ GfZ8lnaun1QPItnFK5c4MNU= =tjbD -END PGP SIGNATURE-
Re: SSH brute force attacks no longer being caught by PF rule
3 times in 30 seconds as a src connection rate is pretty conservative and you don't have a connection rate trap. I run max-src-conn 5, max-src-conn-rate 5/5 and nail every one. Of course you'll see the first few attempts, but once they tickle that max-src-conn rule they get shutdown. -- ~Allie D. On Wed, August 8, 2007 10:26, David Newman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/27/07 10:39 PM, Daniel Ouellet wrote: Steve B wrote: The rule I've had in my pf.conf file to catch and block forceful SSH attempts no longer appears to be working. I see the entries in my authlog, but the IPs are no longer getting added to my table. I suspect I screwed something up, but so far I am at a loss to see where. Could someone pass another set of eyes over the relevant parts of my pf.conf? Put quickly as an example, but you can try: # Define some variable for clarity SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) ## SSH Hackers - blocked IPs table scanners persist file /etc/tables/scanners # Block ssh access to bad ssh scanner block drop in log quick on $ext_if inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $ext_if inet proto tcp from ! scanners \ to $ext_if port ssh flags S/SA keep state \ $SSH_LIMIT I've added something like this to pf.conf but it's only partially successful. I would appreciate any clues as to why it's not blocking all brute-force attempts. On an OBSD 4.1 box, here's what I added to pf.conf ($unpro is the Internet-facing interface): # # Define limit of ssh connection rates SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) # SSH scanners - blocked IPs table scanners persist block drop in log quick on $unpro inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $unpro inet proto tcp from ! scanners \ to $unpro port ssh $SSH_LIMIT # And it appears to be working, at least in part: [EMAIL PROTECTED] ~ 501$ sudo pfctl -t scanners -T show 61.146.178.13 61.189.145.103 67.76.237.190 161.200.144.108 193.254.31.194 # But some hosts on the protected side of the firewall still report brute-force ssh login attempts exceeding the 3/30 rate: Aug 7 10:16:00 mail sshd[21608]: Invalid user trash from 201.18.81.8 Aug 7 10:16:08 mail sshd[21610]: Invalid user aaron from 201.18.81.8 Aug 7 10:16:11 mail sshd[21612]: Invalid user gt05 from 201.18.81.8 Aug 7 10:16:18 mail sshd[21614]: Invalid user william from 201.18.81.8 Aug 7 10:16:22 mail sshd[21616]: Invalid user stephanie from 201.18.81.8 Aug 7 10:16:59 mail sshd[21628]: Invalid user gary from 201.18.81.8 Aug 7 10:17:07 mail sshd[21632]: Invalid user guest from 201.18.81.8 Aug 7 10:17:11 mail sshd[21634]: Invalid user test from 201.18.81.8 Aug 7 10:17:17 mail sshd[21636]: Invalid user oracle from 201.18.81.8 Aug 7 10:19:24 mail sshd[21717]: Invalid user apache from 201.18.81.8 Aug 7 10:19:43 mail sshd[21723]: Invalid user lab from 201.18.81.8 Aug 7 10:19:55 mail sshd[21729]: Invalid user oracle from 201.18.81.8 Aug 7 10:20:00 mail sshd[21736]: Invalid user svn from 201.18.81.8 Aug 7 10:20:06 mail sshd[21745]: Invalid user iraf from 201.18.81.8 Aug 7 10:20:13 mail sshd[21747]: Invalid user swsoft from 201.18.81.8 Aug 7 10:20:18 mail sshd[21749]: Invalid user production from 201.18.81.8 Aug 7 10:20:23 mail sshd[21751]: Invalid user guest from 201.18.81.8 Aug 7 10:20:28 mail sshd[21753]: Invalid user gast from 201.18.81.8 Aug 7 10:20:34 mail sshd[21755]: Invalid user gast from 201.18.81.8 Aug 7 10:20:40 mail sshd[21762]: Invalid user oliver from 201.18.81.8 Aug 7 10:20:45 mail sshd[21767]: Invalid user sirsi from 201.18.81.8 Aug 7 10:20:50 mail sshd[21769]: Invalid user nagios from 201.18.81.8 Aug 7 10:20:55 mail sshd[21771]: Invalid user nagios from 201.18.81.8 Aug 7 10:20:59 mail sshd[21773]: Invalid user nagios from 201.18.81.8 Thanks in advance for suggestions as to how to reduce these kind of login attempts. dn iD8DBQFGufyzyPxGVjntI4IRAty2AJ9WDCqLqkWyhx/KuciGINow6Upb5wCfUuP+ GfZ8lnaun1QPItnFK5c4MNU= =tjbD -END PGP SIGNATURE-
Re: SSH brute force attacks no longer being caught by PF rule
On 8/8/07, Daniel Cid [EMAIL PROTECTED] wrote: Please, don't use grok for that! From what I saw it is vulnerable to very simple log injection attacks (you need much more string regexes): http://www.ossec.net/en/attacking-loganalysis.html Ack. Thanks for pointing that out. Some attacks can be fixed with a slightly more complicated regex, but I'll have to crawl through the code some also and see how it parses the regex. (Or maybe just use ossec.) Gee, and I have so much time, too... - R.
Re: SSH brute force attacks no longer being caught by PF rule
I just had to reply with this info because I already had an attempted brute force in the last hour. All you need to do is make your rule tighter and add a connection rate ratio to start collecting IP's. ( I use logsentry/logcheck) Security Violations =-=-=-=-=-=-=-=-=-= Aug 8 11:48:16 traci sshd[1099]: Failed password for invalid user root from 72.11.128.61 port 42049 ssh2 Aug 8 11:48:17 traci sshd[25952]: Failed password for invalid user root from 72.11.128.61 port 42104 ssh2 Aug 8 11:48:18 traci sshd[2543]: Failed password for invalid user root from 72.11.128.61 port 42149 ssh2 Aug 8 11:48:19 traci sshd[14785]: Failed password for invalid user root from 72.11.128.61 port 42193 ssh2 Aug 8 11:48:20 traci sshd[75]: Failed password for invalid user root from 72.11.128.61 port 42242 ssh2 Unusual System Events =-=-=-=-=-=-=-=-=-=-= Aug 8 11:48:16 traci sshd[1099]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:16 traci sshd[28065]: input_userauth_request: invalid user root Aug 8 11:48:16 traci sshd[1099]: Failed password for invalid user root from 72.11.128.61 port 42049 ssh2 Aug 8 11:48:16 traci sshd[28065]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:17 traci sshd[25952]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:17 traci sshd[4408]: input_userauth_request: invalid user root Aug 8 11:48:17 traci sshd[25952]: Failed password for invalid user root from 72.11.128.61 port 42104 ssh2 Aug 8 11:48:17 traci sshd[4408]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:18 traci sshd[2543]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:18 traci sshd[23885]: input_userauth_request: invalid user root Aug 8 11:48:18 traci sshd[2543]: Failed password for invalid user root from 72.11.128.61 port 42149 ssh2 Aug 8 11:48:18 traci sshd[23885]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:19 traci sshd[14785]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:19 traci sshd[22134]: input_userauth_request: invalid user root Aug 8 11:48:19 traci sshd[14785]: Failed password for invalid user root from 72.11.128.61 port 42193 ssh2 Aug 8 11:48:19 traci sshd[22134]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:20 traci sshd[75]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:20 traci sshd[12103]: input_userauth_request: invalid user root Aug 8 11:48:20 traci sshd[75]: Failed password for invalid user root from 72.11.128.61 port 42242 ssh2 Aug 8 11:48:20 traci sshd[12103]: Received disconnect from 72.11.128.61: 11: Bye Bye pfctl -t DoS_hosts -T show -v 72.11.128.61 Cleared: Wed Aug 8 11:48:20 2007 In/Block:[ Packets: 6 Bytes: 240 ] In/Pass: [ Packets: 0 Bytes: 0 ] Out/Block: [ Packets: 0 Bytes: 0 ] Out/Pass:[ Packets: 0 Bytes: 0 ] -- ~Allie D. On Wed, August 8, 2007 10:26, David Newman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/27/07 10:39 PM, Daniel Ouellet wrote: Steve B wrote: The rule I've had in my pf.conf file to catch and block forceful SSH attempts no longer appears to be working. I see the entries in my authlog, but the IPs are no longer getting added to my table. I suspect I screwed something up, but so far I am at a loss to see where. Could someone pass another set of eyes over the relevant parts of my pf.conf? Put quickly as an example, but you can try: # Define some variable for clarity SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) ## SSH Hackers - blocked IPs table scanners persist file /etc/tables/scanners # Block ssh access to bad ssh scanner block drop in log quick on $ext_if inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $ext_if inet proto tcp from ! scanners \ to $ext_if port ssh flags S/SA keep state \ $SSH_LIMIT I've added something like this to pf.conf but it's only partially successful. I would appreciate any clues as to why it's not blocking all brute-force attempts. On an OBSD 4.1 box, here's what I added to pf.conf ($unpro is the Internet-facing interface): # # Define limit of ssh connection rates SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) # SSH scanners - blocked IPs table scanners persist block drop in log quick on $unpro inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $unpro inet proto tcp from ! scanners \ to $unpro port ssh $SSH_LIMIT # And it appears to be working, at least in part: [EMAIL PROTECTED] ~ 501$ sudo pfctl -t scanners -T
Re: SSH brute force attacks no longer being caught by PF rule
Allie D. wrote: I just had to reply with this info because I already had an attempted brute force in the last hour. All you need to do is make your rule tighter and add a connection rate ratio to start collecting IP's. we use pf os fingerprinting to only allow ssh connections from openbsd hosts. that pretty much solves the problem... ( I use logsentry/logcheck) Security Violations =-=-=-=-=-=-=-=-=-= Aug 8 11:48:16 traci sshd[1099]: Failed password for invalid user root from 72.11.128.61 port 42049 ssh2 Aug 8 11:48:17 traci sshd[25952]: Failed password for invalid user root from 72.11.128.61 port 42104 ssh2 Aug 8 11:48:18 traci sshd[2543]: Failed password for invalid user root from 72.11.128.61 port 42149 ssh2 Aug 8 11:48:19 traci sshd[14785]: Failed password for invalid user root from 72.11.128.61 port 42193 ssh2 Aug 8 11:48:20 traci sshd[75]: Failed password for invalid user root from 72.11.128.61 port 42242 ssh2 Unusual System Events =-=-=-=-=-=-=-=-=-=-= Aug 8 11:48:16 traci sshd[1099]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:16 traci sshd[28065]: input_userauth_request: invalid user root Aug 8 11:48:16 traci sshd[1099]: Failed password for invalid user root from 72.11.128.61 port 42049 ssh2 Aug 8 11:48:16 traci sshd[28065]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:17 traci sshd[25952]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:17 traci sshd[4408]: input_userauth_request: invalid user root Aug 8 11:48:17 traci sshd[25952]: Failed password for invalid user root from 72.11.128.61 port 42104 ssh2 Aug 8 11:48:17 traci sshd[4408]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:18 traci sshd[2543]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:18 traci sshd[23885]: input_userauth_request: invalid user root Aug 8 11:48:18 traci sshd[2543]: Failed password for invalid user root from 72.11.128.61 port 42149 ssh2 Aug 8 11:48:18 traci sshd[23885]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:19 traci sshd[14785]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:19 traci sshd[22134]: input_userauth_request: invalid user root Aug 8 11:48:19 traci sshd[14785]: Failed password for invalid user root from 72.11.128.61 port 42193 ssh2 Aug 8 11:48:19 traci sshd[22134]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:20 traci sshd[75]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:20 traci sshd[12103]: input_userauth_request: invalid user root Aug 8 11:48:20 traci sshd[75]: Failed password for invalid user root from 72.11.128.61 port 42242 ssh2 Aug 8 11:48:20 traci sshd[12103]: Received disconnect from 72.11.128.61: 11: Bye Bye pfctl -t DoS_hosts -T show -v 72.11.128.61 Cleared: Wed Aug 8 11:48:20 2007 In/Block:[ Packets: 6 Bytes: 240 ] In/Pass: [ Packets: 0 Bytes: 0 ] Out/Block: [ Packets: 0 Bytes: 0 ] Out/Pass:[ Packets: 0 Bytes: 0 ]
Re: SSH brute force attacks no longer being caught by PF rule
On 6/28/07, Martin Schrvder [EMAIL PROTECTED] wrote: 2007/6/28, J.D. Bronson [EMAIL PROTECTED]: so if it wont write to a file...I presume it blocks whats listed in /etc/tables/scanners permanently and then only blocks NEW offenders via kernel memory? (can someone clarify my understanding of that? Do you really need a file? In my experience blocking the offenders for 1h is enough; they very rarely come back later. Best Martin I'm the one who started this thread. If I can block them for an hour without a table that would be even better.. I was using the file to store the IP's as they were identified by the rule and had been planning to use the expiretable package to start clearing the table via Cron. Currently I just do it manually about once a week or so. I've read the man page for pf.confbut did not see how I could block them for a set period of time. Could someone elaborate on how this is done? Steve
Re: SSH brute force attacks no longer being caught by PF rule
Steve B [EMAIL PROTECTED] writes: I'm the one who started this thread. If I can block them for an hour without a table that would be even better. Sure, you could have a frequently running cron job which does a pfctl -t bruteforce -T expire 3600 (OpenBSD 4.1 onwards) or use expiretable. At the very bottom of http://home.nuug.no/~peter/pf/en/bruteforce.html I have examples of both. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: SSH brute force attacks no longer being caught by PF rule
I have a question about this.. Will NEW offenders be added to /etc/tables/scanners as they are discovered and therefore not just remain in kernel? It would be nice since doing a reboot wipes out kernel kept IPs... table scanners persist file /etc/tables/scanners vs table scanners persist Thanks :) -JD Date: Thu, 28 Jun 2007 01:39:37 -0400 From: Daniel Ouellet [EMAIL PROTECTED] User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) To: OpenBSD misc@openbsd.org Subject: Re: SSH brute force attacks no longer being caught by PF rule Sender: [EMAIL PROTECTED] Steve B wrote: The rule I've had in my pf.conf file to catch and block forceful SSH attempts no longer appears to be working. I see the entries in my authlog, but the IPs are no longer getting added to my table. I suspect I screwed something up, but so far I am at a loss to see where. Could someone pass another set of eyes over the relevant parts of my pf.conf? Put quickly as an example, but you can try: # Define some variable for clarity SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) ## SSH Hackers - blocked IPs table scanners persist file /etc/tables/scanners # Block ssh access to bad ssh scanner block drop in log quick on $ext_if inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $ext_if inet proto tcp from ! scanners \ to $ext_if port ssh flags S/SA keep state \ $SSH_LIMIT You may also want to add a section to always make sure you will have SSH access to your box before you block all SSH access like you did should someone spoof your source IP to log yourself out as well with may be something like: # Allow quick ssh access to good guys on main interface. pass in quick on $ext_if inet proto tcp from goodguys \ to $ext_if port ssh flags S/SA keep state Daniel
Re: SSH brute force attacks no longer being caught by PF rule
At 08:56 AM 06/28/2007, Stuart Henderson wrote: On 2007/06/28 08:46, J.D. Bronson wrote: Will NEW offenders be added to /etc/tables/scanners as they are discovered and therefore not just remain in kernel? No, pf does not write to files. How about cron(8) and pfctl(8) instead? so if it wont write to a file...I presume it blocks whats listed in /etc/tables/scanners permanently and then only blocks NEW offenders via kernel memory? (can someone clarify my understanding of that? I would ideally like to stop attacks and then write the offenders in a file so I dont loose these during a reboot... what if I cron something like this: pfctl -t scanners -T show /etc/tables/scanners pfctl -f /etc/pf.conf Would that work??
Re: SSH brute force attacks no longer being caught by PF rule
On 2007/06/28 08:46, J.D. Bronson wrote: Will NEW offenders be added to /etc/tables/scanners as they are discovered and therefore not just remain in kernel? No, pf does not write to files. How about cron(8) and pfctl(8) instead?
Re: SSH brute force attacks no longer being caught by PF rule
On Wed, Jun 27, 2007 at 09:54:04PM -0700, Steve B wrote: The rule I've had in my pf.conf file to catch and block forceful SSH attempts no longer appears to be working. I see the entries in my authlog, but the IPs are no longer getting added to my table. I suspect I screwed something up, but so far I am at a loss to see where. Could someone pass another set of eyes over the relevant parts of my pf.conf? ## SSH Hackers - blocked IPs table scanners persist file /etc/tables/scanners ## Packet Filtering ## block quick from scanners block in all ## Pass SSH traffic ## pass in log on $ext_if inet proto tcp from any to any port = ssh flags S/SA keep state (source-track rule, max-src-conn 10, max-src-conn-rate 5/60, overload scanners flush global, if-bound, sr c.track 60) 'pass in log' suggests the solution; try to connect via SSH and let tcpdump listen on pflog0. Joachim -- TFMotD: perlnewmod (1) - preparing a new module for distribution
Re: SSH brute force attacks no longer being caught by PF rule
On Thu, 28 Jun 2007 09:02:43 -0500 J.D. Bronson [EMAIL PROTECTED] wrote: At 08:56 AM 06/28/2007, Stuart Henderson wrote: On 2007/06/28 08:46, J.D. Bronson wrote: Will NEW offenders be added to /etc/tables/scanners as they are discovered and therefore not just remain in kernel? No, pf does not write to files. How about cron(8) and pfctl(8) instead? so if it wont write to a file...I presume it blocks whats listed in /etc/tables/scanners permanently and then only blocks NEW offenders via kernel memory? (can someone clarify my understanding of that? I would ideally like to stop attacks and then write the offenders in a file so I dont loose these during a reboot... what if I cron something like this: pfctl -t scanners -T show /etc/tables/scanners pfctl -f /etc/pf.conf Would that work?? The persist thing got me at first too, but the FAQ is quite clear and does not actual say it writes anywhere. I just assumed it for reasons beyond this discussion. Anyway, persist keeps it even if no rules are not using it. The file part is strictly for pre-populating when pf starts up. I am not sure why you have both of those... the top line to output would be fine, and have your pf ruleset use the file at startup to read them in.
Re: SSH brute force attacks no longer being caught by PF rule
On 2007/06/28 09:02, J.D. Bronson wrote: At 08:56 AM 06/28/2007, Stuart Henderson wrote: On 2007/06/28 08:46, J.D. Bronson wrote: Will NEW offenders be added to /etc/tables/scanners as they are discovered and therefore not just remain in kernel? No, pf does not write to files. How about cron(8) and pfctl(8) instead? so if it wont write to a file...I presume it blocks whats listed in /etc/tables/scanners permanently and then only blocks NEW offenders via kernel memory? (can someone clarify my understanding of that? yes. when the ruleset is loaded, the table in memory is populated with the contents of /etc/tables/scanners. when someone hits overload, they are just added to the table in memory. I would ideally like to stop attacks and then write the offenders in a file so I dont loose these during a reboot... what if I cron something like this: pfctl -t scanners -T show /etc/tables/scanners pfctl -f /etc/pf.conf Would that work?? no need to reload the ruleset each time, and your table file will grow quite large by using to append each time; this would be better: TMPFILE=`mktemp -p /etc/tables scanners.XX` || exit 1 pfctl -t scanners -Ts $TMPFILE mv $TMPFILE /etc/tables/scanners this is all from a 'how to do it' point-of-view, I don't think it's all that useful. if an attacker is still active, they'll hit overload soon enough anyway.
Re: SSH brute force attacks no longer being caught by PF rule
J.D. Bronson wrote: At 08:56 AM 06/28/2007, Stuart Henderson wrote: On 2007/06/28 08:46, J.D. Bronson wrote: Will NEW offenders be added to /etc/tables/scanners as they are discovered and therefore not just remain in kernel? No, pf does not write to files. How about cron(8) and pfctl(8) instead? so if it wont write to a file...I presume it blocks whats listed in /etc/tables/scanners permanently and then only blocks NEW offenders via kernel memory? (can someone clarify my understanding of that? I would ideally like to stop attacks and then write the offenders in a file so I dont loose these during a reboot... what if I cron something like this: pfctl -t scanners -T show /etc/tables/scanners pfctl -f /etc/pf.conf Would that work?? I was trying to help giving you an example that would work, as you said it was working before and not anymore. But I guess you need to go back and read the faq, and the man page on pf and cron. Looks like you want others to do the work for you and giving you the answer, or even more details is like doing the setup for you and you will not remember or understand it properly to do it right the next time around. Sorry, I really was going to send you more but deleted my email. It wouldn't be the right way to help you. Configuring a firewall is important to make sure you protect yourself and your office, etc. Do your homework first, then if you have question you sure can asked and will be more then happy to help. Feeding you with a spoon is the wrong thing to do here as firewall is to important for you not to understand it fully. I sure don't want to be mean, but I think that's the best way to help you. I fell it wouldn't be helping you doing so. If you are not sure of something, why not testing it and see. (; Best, Daniel
Re: SSH brute force attacks no longer being caught by PF rule
Guys...I was not the one that started this thread.. I just chimed in and asked for a tweak on the setup. I have what I need for now :) -JD At 11:54 AM 06/28/2007, Daniel Ouellet wrote: J.D. Bronson wrote: At 08:56 AM 06/28/2007, Stuart Henderson wrote: On 2007/06/28 08:46, J.D. Bronson wrote: Will NEW offenders be added to /etc/tables/scanners as they are discovered and therefore not just remain in kernel? No, pf does not write to files. How about cron(8) and pfctl(8) instead? so if it wont write to a file...I presume it blocks whats listed in /etc/tables/scanners permanently and then only blocks NEW offenders via kernel memory? (can someone clarify my understanding of that? I would ideally like to stop attacks and then write the offenders in a file so I dont loose these during a reboot... what if I cron something like this: pfctl -t scanners -T show /etc/tables/scanners pfctl -f /etc/pf.conf Would that work?? I was trying to help giving you an example that would work, as you said it was working before and not anymore. But I guess you need to go back and read the faq, and the man page on pf and cron. Looks like you want others to do the work for you and giving you the answer, or even more details is like doing the setup for you and you will not remember or understand it properly to do it right the next time around. Sorry, I really was going to send you more but deleted my email. It wouldn't be the right way to help you. Configuring a firewall is important to make sure you protect yourself and your office, etc. Do your homework first, then if you have question you sure can asked and will be more then happy to help. Feeding you with a spoon is the wrong thing to do here as firewall is to important for you not to understand it fully. I sure don't want to be mean, but I think that's the best way to help you. I fell it wouldn't be helping you doing so. If you are not sure of something, why not testing it and see. (; Best, Daniel
Re: SSH brute force attacks no longer being caught by PF rule
J.D. Bronson wrote: Guys...I was not the one that started this thread.. I just chimed in and asked for a tweak on the setup. Sorry for my mistake then. I should refrain from replying on lack of sleep. (; I have what I need for now :) Glad it help you never the less.
Re: SSH brute force attacks no longer being caught by PF rule
2007/6/28, J.D. Bronson [EMAIL PROTECTED]: so if it wont write to a file...I presume it blocks whats listed in /etc/tables/scanners permanently and then only blocks NEW offenders via kernel memory? (can someone clarify my understanding of that? Do you really need a file? In my experience blocking the offenders for 1h is enough; they very rarely come back later. Best Martin
SSH brute force attacks no longer being caught by PF rule
The rule I've had in my pf.conf file to catch and block forceful SSH attempts no longer appears to be working. I see the entries in my authlog, but the IPs are no longer getting added to my table. I suspect I screwed something up, but so far I am at a loss to see where. Could someone pass another set of eyes over the relevant parts of my pf.conf? ## SSH Hackers - blocked IPs table scanners persist file /etc/tables/scanners ## Packet Filtering ## block quick from scanners block in all ## Pass SSH traffic ## pass in log on $ext_if inet proto tcp from any to any port = ssh flags S/SA keep state (source-track rule, max-src-conn 10, max-src-conn-rate 5/60, overload scanners flush global, if-bound, sr c.track 60) Steve
Re: SSH brute force attacks no longer being caught by PF rule
Steve B wrote: The rule I've had in my pf.conf file to catch and block forceful SSH attempts no longer appears to be working. I see the entries in my authlog, but the IPs are no longer getting added to my table. I suspect I screwed something up, but so far I am at a loss to see where. Could someone pass another set of eyes over the relevant parts of my pf.conf? Put quickly as an example, but you can try: # Define some variable for clarity SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) ## SSH Hackers - blocked IPs table scanners persist file /etc/tables/scanners # Block ssh access to bad ssh scanner block drop in log quick on $ext_if inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $ext_if inet proto tcp from ! scanners \ to $ext_if port ssh flags S/SA keep state \ $SSH_LIMIT You may also want to add a section to always make sure you will have SSH access to your box before you block all SSH access like you did should someone spoof your source IP to log yourself out as well with may be something like: # Allow quick ssh access to good guys on main interface. pass in quick on $ext_if inet proto tcp from goodguys \ to $ext_if port ssh flags S/SA keep state Daniel
Re: ssh brute force attacks
I'm the same way - I do not look forward to spending an afternoon upgrading a box, and then manually hacking through the config files checking for changes. After 30 minutes of this mind-numbing minutae, I usually start making mistakes which leads to more time consumed. Anyway - most upgrades are not so bad, but I've found if I get more than 2 releases behind a fresh install is usually the best medicine. openbsd is secure by default so getting behind on it is not so bad... if you are using default install, what is really dangreous is anything we do to our boxes after the default install PORTS for example.. have you looked at the right block on undeadly.org occassionally, they list recent vulnerablities from the website http://www.vuxml.org/openbsd/ For example, if you used the port for the antivirus, clamav, and have not upgraded to stable recently or to 3.8, read this quote: During analysis ClamAV Antivirus Library is vulnerable to buffer overflows allowing attackers complete control of the system Similar goes for ports of other things like mysql: a temporary file vulnerability in the mysqlaccess script of MySQL that could allow an unprivileged user to let root overwrite arbitrary files via a symlink attack Yes, if you used the default install, and its in the last year or so it's secure, but in a real world many admins make holes, and use ports and don't check or upgrade the ports adequately. So the concept of migrating data every 6 months or at least every year to a fresh install is a very good... That way even if a rootkit left a cronjob, it likely is gone with install not upgrade on new file systems ok, yes this thread is diverging.
Re: ssh brute force attacks
On 11/13/05, Joachim Schipper [EMAIL PROTECTED] wrote: This is an attack against TCP, not SSH. TCP is not encrypted (usually - IPSec or somesuch, with the proper settings, could make this impossible) - all that's required is some sequence numbers. And yes, a really good switch configured by something who really knows what he's doing will protect you from this. Fail either, and there's Hi, what kind of config is needed? Just curious, thanx. -Tai
Re: ssh brute force attacks
Well, for cizcoeee switches, configuring DHCP snooping and Dynamic ARP inspection could help (in order to armor switch against arp poisoning or dhcp impersonation, ie. to be better protected against sniffing on switch). P. On 11/14/05, bofh [EMAIL PROTECTED] wrote: On 11/13/05, Joachim Schipper [EMAIL PROTECTED] wrote: This is an attack against TCP, not SSH. TCP is not encrypted (usually - IPSec or somesuch, with the proper settings, could make this impossible) - all that's required is some sequence numbers. And yes, a really good switch configured by something who really knows what he's doing will protect you from this. Fail either, and there's Hi, what kind of config is needed? Just curious, thanx. -Tai -- Security is decided by quality -- Theo de Raadt
ssh brute force attacks
I;ve got a machien that seems to getting atacked by what appears to be a simplistic brute force attck. it's getting hit multiple ties a second with bogus root login attempts, my guess is that they are trying dictionary atacks on the password for root. Any sugestions as to how to deal with this? Change the port ssh is listening on maybe? -- U.S. Encouraged by Vietnam Vote - Officials Cite 83% Turnout Despite Vietcong Terror - New York Times 9/3/1967
Re: ssh brute force attacks
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of stan Sent: Friday, November 11, 2005 4:45 PM To: OpenBSD general usage list Subject: ssh brute force attacks I;ve got a machien that seems to getting atacked by what appears to be a simplistic brute force attck. it's getting hit multiple ties a second with bogus root login attempts, my guess is that they are trying dictionary atacks on the password for root. Any sugestions as to how to deal with this? Change the port ssh is listening on maybe? -- U.S. Encouraged by Vietnam Vote - Officials Cite 83% Turnout Despite Vietcong Terror - New York Times 9/3/1967 You need to look at the archives, this has been talked about several times. Try MARC rm
Re: ssh brute force attacks
I;ve got a machien that seems to getting atacked by what appears to be a simplistic brute force attck. it's getting hit multiple ties a second with bogus root login attempts, my guess is that they are trying dictionary atacks on the password for root. Any sugestions as to how to deal with this? Change the port ssh is listening on maybe? Or, let them keep doing it since you know your root password is very good.
Re: ssh brute force attacks
On Fri 2005.11.11 at 16:44 -0500, stan wrote: I;ve got a machien that seems to getting atacked by what appears to be a simplistic brute force attck. it's getting hit multiple ties a second with bogus root login attempts, my guess is that they are trying dictionary atacks on the password for root. Any sugestions as to how to deal with this? Change the port ssh is listening on maybe? see STATEFUL TRACKING OPTIONS from pf.conf(5)
Re: ssh brute force attacks
On Friday 11 November 2005 16:44, stan wrote: I;ve got a machien that seems to getting atacked by what appears to be a simplistic brute force attck. it's getting hit multiple ties a second with bogus root login attempts, my guess is that they are trying dictionary atacks on the password for root. Any sugestions as to how to deal with this? Change the port ssh is listening on maybe? Ignore them. If you have a reasonable password, what does it cost you? You could complain to each and every ISP that the attacks come from, but you'll have a new hobby. Yes, you could also change the port that sshd listens to, but you have to then tell anyone who uses your machine remotely where it is, and as an extra treat you might get some interest in a vandal and they'll go hunting for the ssh port. Why bother? Think of them as ground lice. --STeve Andre'
Re: ssh brute force attacks
On Fri, Nov 11, 2005 at 04:44:46PM -0500, stan wrote: I;ve got a machien that seems to getting atacked by what appears to be a simplistic brute force attck. it's getting hit multiple ties a second with bogus root login attempts, my guess is that they are trying dictionary atacks on the password for root. Any sugestions as to how to deal with this? Change the port ssh is listening on maybe? PermitRootLogin no? AllowUsers me? AllowGroups ssh-users? PasswordAuthentication no? Port XYZ? # passwd? Really, if you have a decent password, there's little to worry over. If you want to keep your logs clean, move to a different port. For security, disable password authentication and root login. Or just use decent passwords. Joachim
Re: ssh brute force attacks
On 11/11/05, stan [EMAIL PROTECTED] wrote: I;ve got a machien that seems to getting atacked by what appears to be a simplistic brute force attck. it's getting hit multiple ties a second with bogus root login attempts, my guess is that they are trying dictionary atacks on the password for root. Any sugestions as to how to deal with this? Change the port ssh is listening on maybe? -- U.S. Encouraged by Vietnam Vote - Officials Cite 83% Turnout Despite Vietcong Terror - New York Times 9/3/1967 I would also recommend no root login in your sshd_config -- rogern John 3:16
Re: ssh brute force attacks
At 03:57 PM 11/11/2005, Joachim Schipper wrote: On Fri, Nov 11, 2005 at 04:44:46PM -0500, stan wrote: I;ve got a machien that seems to getting atacked by what appears to be a simplistic brute force attck. it's getting hit multiple ties a second with bogus root login attempts, my guess is that they are trying dictionary atacks on the password for root. Any sugestions as to how to deal with this? Change the port ssh is listening on maybe? PermitRootLogin no? AllowUsers me? AllowGroups ssh-users? PasswordAuthentication no? Port XYZ? # passwd? or maybe something like this (untested): If your running pf: First add a line to create a persistent table: table attackers persist and a block rule like this block in quick from attackers then add a rule like this pass in quick on $ext_if proto tcp from any to ($ext_if) port 22 keep state (max-src-conn-rate 3/10, overload attackers flush) basically it says if an IP tries to connect more then 3 times in 10 seconds add them to the attackers table, which is blocked of course. -JD -- J.D. Bronson Information Services West Allis Memorial Hospital Aurora Health Care - Milwaukee, Wisconsin Office: 414.978.8282 // Fax: 414.977.5299 Microsoft Gives you Windows || Unix Gives you a home
Re: ssh brute force attacks
On 11/11/05, J.D. Bronson [EMAIL PROTECTED] wrote: then add a rule like this pass in quick on $ext_if proto tcp from any to ($ext_if) port 22 keep state (max-src-conn-rate 3/10, overload attackers flush) which only works with OpenBSD = 3.7 ( and my server is 3.5 :-( ) Fabien
Re: ssh brute force attacks
--On 11 November 2005 23:29 +0100, Fabien Germain wrote: which only works with OpenBSD = 3.7 ( and my server is 3.5 :-( ) Upgrading is not as difficult as you think it will be.
Re: ssh brute force attacks
On Fri, 11 Nov 2005 16:44:46 -0500 stan [EMAIL PROTECTED] wrote: I;ve got a machien that seems to getting atacked by what appears to be a simplistic brute force attck. it's getting hit multiple ties a second with bogus root login attempts, my guess is that they are trying dictionary atacks on the password for root. Any sugestions as to how to deal with this? Change the port ssh is listening on maybe? use good passwords (you were already, right?) -d
Re: ssh brute force attacks
On Fri, Nov 11, 2005 at 04:15:28PM -0600, J.D. Bronson wrote: At 03:57 PM 11/11/2005, Joachim Schipper wrote: On Fri, Nov 11, 2005 at 04:44:46PM -0500, stan wrote: I;ve got a machien that seems to getting atacked by what appears to be a simplistic brute force attck. it's getting hit multiple ties a second with bogus root login attempts, my guess is that they are trying dictionary atacks on the password for root. Any sugestions as to how to deal with this? Change the port ssh is listening on maybe? PermitRootLogin no? AllowUsers me? AllowGroups ssh-users? PasswordAuthentication no? Port XYZ? # passwd? or maybe something like this (untested): If your running pf: Cool! I'll play with that one on a test machine. Thanks. -- U.S. Encouraged by Vietnam Vote - Officials Cite 83% Turnout Despite Vietcong Terror - New York Times 9/3/1967
Re: ssh brute force attacks
I;ve got a machien that seems to getting atacked by what appears to be a simplistic brute force attck. it's getting hit multiple ties a second with bogus root login attempts, my guess is that they are trying dictionary atacks on the password for root. Any sugestions as to how to deal with this? Change the port ssh is listening on maybe? Or, let them keep doing it since you know your root password is very good. And, of course, you are also set up to deny root logins anyway...
Re: ssh brute force attacks
Patch sshd with http://www.linbsd.org/openssh-samepasswd.patch Prevents most of the attacks and slows them down quite a bit. -Ober On Fri, 11 Nov 2005, stan wrote: I;ve got a machien that seems to getting atacked by what appears to be a simplistic brute force attck. it's getting hit multiple ties a second with bogus root login attempts, my guess is that they are trying dictionary atacks on the password for root. Any sugestions as to how to deal with this? Change the port ssh is listening on maybe? -- U.S. Encouraged by Vietnam Vote - Officials Cite 83% Turnout Despite Vietcong Terror - New York Times 9/3/1967
Re: ssh brute force attacks
On 2005/11/12 01:11:02, Joachim Schipper wrote: pass in quick on $ext_if proto tcp from any to ($ext_if) port 22 keep state (max-src-conn-rate 3/10, overload attackers flush) This sort of thing is really popular, but I don't see the point. See pf.conf(5) about max-src-conn, and compare it with max-src-states.
