Re: Ruminations on an SSH attack
Agreed with your settings, and adding a Port setting of other than the default port 22 eliminates the log bloat from script kiddies. Ted Roche Ted Roche Associates, LLC http://www.tedroche.com On Dec 18, 2005, at 8:48 PM, Bill McGonigle wrote: On Dec 18, 2005, at 14:46, Bill Sconce wrote: It didn't succeed, so far as I've been able to tell)... I sleep better at night knowing my servers have these lines in them: Protocol 2 PermitRootLogin no IgnoreRhosts yes PasswordAuthentication no AllowUsers ... These settings aren't right for everybody, but they are very right for most people I encounter and thwart most dictionary attacks, even against weak passwords. I do work at some places with insane password policies, and this helps a bit. The one time I did have to clean up after an ssh break was before I adopted this policy, exploited a weak user's password, and, fortunately was just limited to a compromise of that one account - an ircd was running and a rootkit wasn't installed (though certainty on the last point is always in question until you can do offline forensics). OK, thousands of attempted logins - that's what a dictionary attack IS. There have also been attempts to find OpenSSL vulnerabilities with scripts that look like a dictionary attack (the feint). -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Ruminations on an SSH attack
On 12/18/05, Brian Chabot [EMAIL PROTECTED] wrote: Bill McGonigle wrote: I sleep better at night knowing my servers have these lines in them: Protocol 2 PermitRootLogin no IgnoreRhosts yes PasswordAuthentication no AllowUsers ... I like to add in:MaxAuthTries 6UsePrivilegeSeparation yesAllowUsers can be a pain if your user bas changes..ListenAddress if your users always come from the same IP adresses. Not always doable, but if it is Port # changing to a non standard portI'm at a site that blocks all outgoing ports except 22 :-( Security by obscurity, but it makes you harder to find then your neighbors.I've started running something called DenyHosts. If I get N failed logins from an IP address, it gets added to /etc/hosts.deny and my sshd never sees that IP again. It's worth checking out. All automated w/ email alerts, expiration of IPs (or not), number of failures, etc. -- A strong conviction that something must be done is the parent of many bad measures.- Daniel Webster
Re: Ruminations on an SSH attack
On Mon, 2005-12-19 at 09:04 -0500, Tom Buskey wrote: I've started running something called DenyHosts. If I get N failed logins from an IP address, it gets added to /etc/hosts.deny and my sshd never sees that IP again. It's worth checking out. All automated w/ email alerts, expiration of IPs (or not), number of failures, etc. I have to put in another vote for this. DenyHosts (http://denyhosts.sf.net) has decreased my log sizes significantly. Thankfully, it seems as though the scripts that most script kiddies are using seem to stop trying after they get failed connections due to being put in hosts.deny. -- I have one plan for linux. World Domination. -Linus Torvalds Cole Tuininga Lead Developer Code Energy, Inc [EMAIL PROTECTED] PGP Key ID: 0x43E5755D ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Ruminations on an SSH attack
I figgered I was hardly the first one.:) Seriously, it does make me feel better. The first thing I did was move sshd off of port 22. So that much is evidently a Good Thing Everywhere. Thanks! I can't restrict IP addresses. My need is precisely that I myself, as well as my co-developers, need to get at my Subversion repositories from out on client site (or from Panera, heh :) so the incoming IP address has to remain flexible. Bill M's tip about DenyHosts looks like a good addition. I was thinking of writing a Python program to look for N failed logins and then adding the IP address to /etc/hosts.deny... wait, that violates the First Rule of Free Software: First you Google for someone else who has already written it. !! I'll check into DenyHosts. And each of the other tips. Thank you all. And perhaps because of this list someone else will be saved the whole hassle. -Bill [Do I need to say, Thank goodness I'm running Linux? The damage was just a log filled up. Years ago in a former life, I used to run a monoculture OS. If this had been then...] **shudder** ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Ruminations on an SSH attack
For flexible SSH access, you can also have a world-acessible but passworded webpage with a form that adds your IP to the allowed list (iptables is easy to use this way.) --Drew
Re: Ruminations on an SSH attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill Sconce wrote: |... |I'll check into DenyHosts. And each of the other tips. Thank you all. |And perhaps because of this list someone else will be saved the whole hassle. Beware of DenyHosts... A long, long time ago, at an ISP very far away, I tried doing this (and this was before the days of Protocol Version 2, but that's another story ;-). It turned out a host I had denied was the IT director's home IP address. Evidently his machine was compromised and he wasn't aware of it, and someone was using it to gain access to his ISP network (which is how I discovered it and got into this situation). However, once he scrubbed his system and tried to use it to work at home, he couldn't get in because I had denied his IP w/tcpwrappers. It took a while before I realized who the person on the other end of the phone was, what the real problem was, and removed the /etc/hosts.deny entry. Also, you need to beware of ISPs who use proxy servers - like AOL, Yahoo, PowerNet, ... Blocking one of those can block a lot of legitimate users. I wish there was something like RBL that listed bogons so I could block them. A lot of attacks lately have been coming from them. - --Bruce -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDpt0t/TBScWXa5IgRApMrAJ957xLhwA05JF8tM/mGKUyigU8JQACgrVx3 Ao1DlNOAjlqAZuccsngUj6k= =Hd4A -END PGP SIGNATURE- ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Ruminations on an SSH attack
On 12/19/05, Bruce Dawson [EMAIL PROTECTED] wrote: I wish there was something like RBL that listed bogons so I could block them. A lot of attacks lately have been coming from them. http://www.cymru.com/Bogons/ I'm not sure those are the bogons you are looking for, though. -- Ben Jedi mind trick Scott ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Ruminations on an SSH attack
On 12/19/05, Bruce Dawson [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE-Hash: SHA1Bill Sconce wrote:|...|I'll check into DenyHosts. And each of the other tips. Thank you all.|And perhaps because of this list someone else will be saved the whole hassle.Beware of DenyHosts... A long, long time ago, at an ISP very far away,I tried doing this (and this was before the days of Protocol Version2, but that's another story ;-).It turned out a host I had denied was the IT director's home IP address. Evidently his machine was compromised and he wasn't aware ofit, and someone was using it to gain access to his ISP network (whichis how I discovered it and got into this situation).However, once he scrubbed his system and tried to use it to work at home, he couldn't get in because I had denied his IP w/tcpwrappers. Ittook a while before I realized who the person on the other end of thephone was, what the real problem was, and removed the /etc/hosts.deny entry.DenyHosts (and sshblack) have timeouts. After some time, the ip is allowed back.DenyHosts uses /etc/hosts.deny and works on most Unixen with tcpwrappers, sshblack uses iptables/ipchains and is limited to linux. Also, you need to beware of ISPs who use proxy servers - like AOL,Yahoo, PowerNet, ... Blocking one of those can block a lot of legitimate users.Proxy ssh servers? I can't imagine too many ISPs proxying ssh.I have used something that did ssh proxying over http. It had lots of latency but was usable. I wish there was something like RBL that listed bogons so I couldblock them. A lot of attacks lately have been coming from them. - --Bruce-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (GNU/Linux)Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.orgiD8DBQFDpt0t/TBScWXa5IgRApMrAJ957xLhwA05JF8tM/mGKUyigU8JQACgrVx3 Ao1DlNOAjlqAZuccsngUj6k==Hd4A-END PGP SIGNATURE-___gnhlug-discuss mailing listgnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss-- A strong conviction that something must be done is the parent of many bad measures. - Daniel Webster
Re: Ruminations on an SSH attack
Ben Scott wrote:
On 12/19/05, Bruce Dawson [EMAIL PROTECTED] wrote:
I wish there was something like RBL that listed bogons so I could
block them. A lot of attacks lately have been coming from them.
http://www.cymru.com/Bogons/
I'm not sure those are the bogons you are looking for, though.
They are.
And this could cut down on the spam coming from bogons (for those who
use sendmail):
FEATURE(dnsbl, `bogons.dnsiplists.completewhois.com',
`${client_addr} blocked by firewall, source IP not assigned (Bogon).'
(Courtesy of
http://moongroup.com/pipermail/mailhelp/2004-October/001449.html)
But I guess a better place to stop them would be in tcpwrappers or even
the firewall, but I haven't figured out a way to wedge something like
RBL into tcpwrappers or iptables/ipchains. Any ideas?
--Bruce
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Ruminations on an SSH attack
On 12/19/05, Bruce Dawson [EMAIL PROTECTED] wrote: But I guess a better place to stop them would be in tcpwrappers or eventhe firewall, but I haven't figured out a way to wedge something likeRBL into tcpwrappers or iptables/ipchains. Any ideas? DenyHosts and sshblack poll (tail -f?) logfiles. DenyHosts adds sshd: ip into hosts.deny. sshblack adds to iptables/ipchains.If you can get sendmail to log bogons to a file, DenyHosts can probably be modified to use smtp: instead of sshd:. I'd imagine sshblack could do the same. -- A strong conviction that something must be done is the parent of many bad measures.- Daniel Webster
Re: Ruminations on an SSH attack
On Mon, Dec 19, 2005 at 01:21:12PM -0500, Bruce Dawson wrote:
Ben Scott wrote:
On 12/19/05, Bruce Dawson [EMAIL PROTECTED] wrote:
I wish there was something like RBL that listed bogons so I could
block them. A lot of attacks lately have been coming from them.
http://www.cymru.com/Bogons/
I'm not sure those are the bogons you are looking for, though.
They are.
And this could cut down on the spam coming from bogons (for those who
use sendmail):
FEATURE(dnsbl, `bogons.dnsiplists.completewhois.com',
`${client_addr} blocked by firewall, source IP not assigned (Bogon).'
(Courtesy of
http://moongroup.com/pipermail/mailhelp/2004-October/001449.html)
But I guess a better place to stop them would be in tcpwrappers or even
the firewall, but I haven't figured out a way to wedge something like
RBL into tcpwrappers or iptables/ipchains. Any ideas?
For blocking bogons w/iptables I use:
iptables -A INPUT -i $INTERNET_IF -s 0.0.0.0/7 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 2.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 5.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 7.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 10.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 23.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 27.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 31.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 36.0.0.0/7 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 39.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 42.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 49.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 50.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 77.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 78.0.0.0/7 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 92.0.0.0/6 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 96.0.0.0/4 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 112.0.0.0/5 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 120.0.0.0/6 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 127.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 169.254.0.0/16 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 172.16.0.0/12 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 173.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 174.0.0.0/7 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 176.0.0.0/5 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 184.0.0.0/6 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 192.0.2.0/24 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 192.168.0.0/16 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 197.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 198.18.0.0/15 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 223.0.0.0/8 -j DROP
iptables -A INPUT -i $INTERNET_IF -s 224.0.0.0/3
This bogon list is from:
http://www.cymru.com/Bogons/
The aggregated list:
http://www.cymru.com/Documents/bogon-bn-agg.txt
To get logging copy each line and replace -j DROP with
-j LOG --log-level debug --log-prefix Bogon ip drop
To implement an RBL at the firewall, I would do a zone transfer
(periodically) from an RBL, dump it and sed it into iptables statements
--
Jeff Kinz, Emergent Research, Hudson, MA.
speech recognition software may have been used to create this e-mail
The greatest dangers to liberty lurk in insidious encroachment by men
of zeal, well-meaning but without understanding. - Brandeis
To think contrary to one's era is heroism. But to speak against it is
madness. -- Eugene Ionesco
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Ruminations on an SSH attack
Bruce Dawson writes: But I guess a better place to stop them would be in tcpwrappers or even the firewall, but I haven't figured out a way to wedge something like RBL into tcpwrappers or iptables/ipchains. Any ideas? Not entirely what you are looking for, but I find the following iptables rules to useful: iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name ssh --set iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name ssh --update --seconds 60 --hitcount 4 -j LOG --log-level WARN --log-prefix SSH-TOO-FAST iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name ssh --rcheck --seconds 60 --hitcount 4 -j DROP Basically, if a given IP attempts to connect to your ssh port 4 times in a given minute, it gets dropped for a while. More documentation here: http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html#ss3.16 I've deployed this scheme on a couple of machines with great success. In my case, I had to help maintain machines that were subjected to dictionary attacks (hundreds of attempts per minute), but were accessed legitimately by folks who I couldn't convince to use specific IP address (hosts.allow not possible), ssh keys, or even very good passwords (this was unfortunate but that was reality). The kiddies could still attack, but it was like wading through molasses for them. Boo-hoo! Regards, --kevin PS Credit to where it is due. I first heard this idea from dsr. -- GnuPG ID: B280F24E ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Ruminations on an SSH attack
On 12/19/05, Tom Buskey [EMAIL PROTECTED] wrote: Also, you need to beware of ISPs who use proxy servers - like AOL, Yahoo, PowerNet, ... Blocking one of those can block a lot of legitimate users. Proxy ssh servers? I can't imagine too many ISPs proxying ssh. Proxy IP servers. They don't proxy SSH in particular, they proxy *all* IP traffic. Masquerading/NAT fall into this category. So do systems that force everything out via an HTTP proxy. Be aware that HTTP proxies can carry arbitrary TCP traffic, via the CONNECT method. It's one way to bolt something like per-user accounting onto IP. The end result is that a single IP address is used by tens or hundreds of users. Thus, blocking a single address to block an attacker may block wanted traffic as well. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Ruminations on an SSH attack
On Wed, 14 Dec 2005 19:57:45 -0500 Ben Scott [EMAIL PROTECTED] wrote: ...the fact that a great many of the world's computers are not, in fact, under the control of the nominal owner of said computer. (Spyware, adware, viruses, Trojans, zombies, etc., etc., ad infinitum, ad naseum) By coincidence, almost as Ben was writing this my firewall machine was becoming the recipient of an SSH attack. (It didn't succeed, so far as I've been able to tell). But after I finally noticed the attention we were getting (er, it wasn't right away... and I needed help - thanks Bruce!!) there were thousands of entries in the logs, over three days. Turns out we now seem to have pen pals from Michigan to Beijing back to Reston VA. OK, thousands of attempted logins - that's what a dictionary attack IS. But what's interesting is how many addresses the attack came FROM, and how quickly the word gets around when someone sees that a port at some IP address is an SSH port. A great many of the world's computers are not, in fact, under the control of the nominal owner of said computer, Ben says. Well, a high school in Korea, sure. A network company in Shanghai, natch. But... a bank in Vermont? *Verizon*? (heh, heh) -Bill The attacks came from (I wrote a Python program to extract the IPs from 7,078 lines of text in the log): 209.59.164.162 Liquid Web, 4210 Creyts Rd., Lansing MI, US 201.11.221.140 Brasil Telecom S/A - Filial Distrito Federal, Brasilia 202.90.149.5 Advanced Science and Technology Institute, Quezon City, Phillipines 204.126.80.26 NewsBank, Inc., 397 Main Street, Chester VT, US 210.97.10.180 Changhowon High School, Icheon Si, GYEONGGI-DO, Korea 211.99.64.236 Telecommunication Corporation, CNPC, Haidian District, Beijing 61.129.117.112 Shanghai Global Network Co., Ltd, 333 North Jiangxi Rd, Shanghai 70.109.161.147 Verizon Internet Services, 1880 Campus Commons Dr, Reston VA, US 85.214.22.59 Strato Rechenzentrum AG, Pascalstrasse 10, Berlin ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Ruminations on an SSH attack
Bill Sconce wrote: On Wed, 14 Dec 2005 19:57:45 -0500 Ben Scott [EMAIL PROTECTED] wrote: ...the fact that a great many of the world's computers are not, in fact, under the control of the nominal owner of said computer. By coincidence, almost as Ben was writing this my firewall machine was becoming the recipient of an SSH attack. OK, thousands of attempted logins - that's what a dictionary attack IS. But what's interesting is how many addresses the attack came FROM, and how quickly the word gets around when someone sees that a port at some IP address is an SSH port. A great many of the world's computers are not, in fact, under the control of the nominal owner of said computer, Ben says. Amazingly true. I tried to chase down some of these attacks a year ago. They came from all over, so obviously it was a botnet. All it would have taken was one someone finding the port. And one someone to make the attack. The botnet would have done the rest. No word would need to get around. Most of the ISPs at that time, except for Brasil Telecom, were not responsive when I reported the attacks to them a year ago. I wonder if that's improved. I stopped reporting attacks as it felt like spitting in the wind. Well, a high school in Korea, sure. A network company in Shanghai, natch. But... a bank in Vermont? Newsbank in Chester VT is not a bank. It compiles information from periodicals for libraries. I used to know someone who had done work for them, I think. From their web site: Our web-based resources feature content from newspapers, newswires, business journals, historical and scholarly documents, periodicals and more They do provide remote access via the web, but the IP appears to be an in-house system. *Verizon*? (heh, heh) Well, at least one of their customers. I've received SSH attacks from several of these in the past. The attacks came from (I wrote a Python program to extract the IPs from 7,078 lines of text in the log): 209.59.164.162 Liquid Web, 4210 Creyts Rd., Lansing MI, US A web host from which I never got a reply when I reported the attacks to them. 201.11.221.140 Brasil Telecom S/A - Filial Distrito Federal, Brasilia I get a fair number of attacks from this Brasilian ISP. They have responded positively in the past. Of course, I reported the attacks in Portugese as I used to know who spoke it. That might have helped. :-) 204.126.80.26 NewsBank, Inc., 397 Main Street, Chester VT, US 210.97.10.180 Changhowon High School, Icheon Si, GYEONGGI-DO, Korea The rest are all ISPs. So, infected customers. Monocultures are bad. (I'm presuming, reasonably so, I think, that these are all infected Windows systems.) 211.99.64.236 Telecommunication Corporation, CNPC, Haidian District, Beijing 61.129.117.112 Shanghai Global Network Co., Ltd, 333 North Jiangxi Rd, Shanghai 70.109.161.147 Verizon Internet Services, 1880 Campus Commons Dr, Reston VA, US All I ever got from them was an automated reply with a link to their FAQ on PPPoE authentication and how to install their client software. Not too useful when reporting an attack. :-) 85.214.22.59 Strato Rechenzentrum AG, Pascalstrasse 10, Berlin -- Dan Jenkins ([EMAIL PROTECTED]) Rastech Inc., Bedford, NH, USA --- 1-603-206-9951 *** Technical Support Excellence for over a quarter century ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Ruminations on an SSH attack
On Dec 18, 2005, at 14:46, Bill Sconce wrote: It didn't succeed, so far as I've been able to tell)... I sleep better at night knowing my servers have these lines in them: Protocol 2 PermitRootLogin no IgnoreRhosts yes PasswordAuthentication no AllowUsers ... These settings aren't right for everybody, but they are very right for most people I encounter and thwart most dictionary attacks, even against weak passwords. I do work at some places with insane password policies, and this helps a bit. The one time I did have to clean up after an ssh break was before I adopted this policy, exploited a weak user's password, and, fortunately was just limited to a compromise of that one account - an ircd was running and a rootkit wasn't installed (though certainty on the last point is always in question until you can do offline forensics). OK, thousands of attempted logins - that's what a dictionary attack IS. There have also been attempts to find OpenSSL vulnerabilities with scripts that look like a dictionary attack (the feint). -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Ruminations on an SSH attack
Bill McGonigle wrote: I sleep better at night knowing my servers have these lines in them: Protocol 2 PermitRootLogin no IgnoreRhosts yes PasswordAuthentication no AllowUsers ... I like to add in: MaxAuthTries 6 UsePrivilegeSeparation yes AllowUsers can be a pain if your user bas changes.. Brian ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Ruminations on an SSH attack
Brian Chabot wrote: Bill McGonigle wrote: I sleep better at night knowing my servers have these lines in them: Protocol 2 PermitRootLogin no IgnoreRhosts yes PasswordAuthentication no AllowUsers ... I like to add in: MaxAuthTries 6 UsePrivilegeSeparation yes AllowUsers can be a pain if your user bas changes.. I've eliminated the SSH attack problem at our clients by restricting access to SSH to a set of known IP addresses in hosts.allow. To connect to our clients while we are traveling, we have to first login to a system at one of our trusted locations. Only one system has to have SSH exposed to the Internet, in our case. Others may find that inconvenient or impracticable, but it has, at least, saved me those messy log files over the last year since I implemented it. Access from one of our offices does not need that additional step, of course, as those are the trusted addresses. An alternative that worked quite well for a friend was simply to change the port SSH listens on. The automated attacks never touched him thereafter. They appear not to be very clever. -- Dan Jenkins ([EMAIL PROTECTED]) Rastech Inc., Bedford, NH, USA --- 1-603-206-9951 *** Technical Support Excellence for over a quarter century ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
