Bruce Ferrell wrote:

David C. Rankin wrote:

...

Listmates,

The work server seemed sluggish over the net tonight, so I checked the logs and they are filled with the little whackos running dictionary attacks against my server. But it looks like they have upgraded their scripts to make them come from different IPs.

What is that automated Block??? package that updates your hosts.deny file if you have x attempts in y minutes from an IP?

My logs are looking like this:

Nov 22 00:30:55 bonza sshd[31392]: Invalid user claudine from 61.4.210.33 Nov 22 00:30:55 bonza sshd[31392]: error: PAM: User not known to the underlying authentication module for illegal user claudine from 61.4.210.33 Nov 22 00:30:55 bonza sshd[31392]: Failed keyboard-interactive/pam for invalid user claudine from 61.4.210.33 port 22 ssh2 Nov 22 00:32:00 bonza sshd[31402]: Invalid user clemence from 192.25.133.82 Nov 22 00:32:01 bonza sshd[31402]: error: PAM: User not known to the underlying authentication module for illegal user clemence from at1.ftc.agilent.com Nov 22 00:32:01 bonza sshd[31402]: Failed keyboard-interactive/pam for invalid user clemence from 192.25.133.82 port 49704 ssh2 Nov 22 00:33:01 bonza sshd[31410]: Invalid user clemence from 193.224.241.4 Nov 22 00:33:01 bonza sshd[31410]: error: PAM: User not known to the underlying authentication module for illegal user clemence from 193.224.241.4 Nov 22 00:33:01 bonza sshd[31410]: Failed keyboard-interactive/pam for invalid user clemence from 193.224.241.4 port 42807 ssh2 Nov 22 00:34:12 bonza sshd[31436]: refused connect from 200.193.32.145 (200.193.32.145) Nov 22 00:35:22 bonza sshd[31443]: Invalid user clemence from 80.59.254.120 Nov 22 00:35:22 bonza sshd[31443]: error: PAM: User not known to the underlying authentication module for illegal user clemence from 120.red-80-59-254.staticip.rima-tde.net Nov 22 00:35:22 bonza sshd[31443]: Failed keyboard-interactive/pam for invalid user clemence from 80.59.254.120 port 34207 ssh2 Nov 22 00:36:20 bonza sshd[31453]: Invalid user clemence from 166.111.68.183 Nov 22 00:36:21 bonza sshd[31453]: error: PAM: User not known to the underlying authentication module for illegal user clemence from hpclab.cs.tsinghua.edu.cn Nov 22 00:36:21 bonza sshd[31453]: Failed keyboard-interactive/pam for invalid user clemence from 166.111.68.183 port 59241 ssh2 Nov 22 00:37:25 bonza sshd[31463]: refused connect from 123.14.10.64 (123.14.10.64) Nov 22 00:38:23 bonza sshd[31469]: refused connect from 201.253.105.21 (201.253.105.21) Nov 22 00:39:33 bonza sshd[31478]: refused connect from 83.222.222.201 (83.222.222.201) Nov 22 00:40:01 bonza /usr/sbin/cron[31484]: (assistance) CMD (/usr/local/bin/Learn_as_spam_cron) Nov 22 00:40:29 bonza sshd[31495]: Invalid user clemence from 59.125.200.51 Nov 22 00:40:29 bonza sshd[31495]: error: PAM: User not known to the underlying authentication module for illegal user clemence from 3w.upcc.com.tw Nov 22 00:40:29 bonza sshd[31495]: Failed keyboard-interactive/pam for invalid user clemence from 59.125.200.51 port 16790 ssh2 Nov 22 00:41:33 bonza sshd[31504]: Invalid user clemence from 81.83.10.149 Nov 22 00:41:33 bonza sshd[31504]: error: PAM: User not known to the underlying authentication module for illegal user clemence from d51530a95.access.telenet.be Nov 22 00:41:33 bonza sshd[31504]: Failed keyboard-interactive/pam for invalid user clemence from 81.83.10.149 port 55062 ssh2 Nov 22 00:42:36 bonza sshd[31514]: refused connect from 200.141.223.99 (200.141.223.99) Nov 22 00:43:48 bonza sshd[31521]: Invalid user colette from 85.207.120.188 Nov 22 00:43:48 bonza sshd[31521]: error: PAM: User not known to the underlying authentication module for illegal user colette from 188-120-207-85.vychcechy.adsl-llu.static.bluetone.cz Nov 22 00:43:48 bonza sshd[31521]: Failed keyboard-interactive/pam for invalid user colette from 85.207.120.188 port 45490 ssh2 Nov 22 00:44:45 bonza sshd[31530]: refused connect from 82.207.104.34 (82.207.104.34) Nov 22 00:45:48 bonza sshd[31576]: refused connect from 83.18.247.69 (83.18.247.69) Nov 22 00:46:59 bonza sshd[31587]: refused connect from 201.6.120.211 (201.6.120.211) Nov 22 00:48:04 bonza sshd[31600]: refused connect from 200.58.171.134 (200.58.171.134)

Perhaps you're thinking of this:

http://linuxmafia.com/pub/linux/security/sshd_sentry/

Yep, that was one of them, there is another called, Block'something'. I'll post it when it find it. -- David C. Rankin, J.D.,P.E. | Rankin Law Firm, PLLC | Countdown for openSuSE 11.1 510 Ochiltree Street | http://counter.opensuse.org/11.1/small Nacogdoches, Texas 75961 | Telephone: (936) 715-9333 | openSoftware und SystemEntwicklung Facsimile: (936) 715-9339 | http://www.opensuse.org/ www.rankinlawfirm.com | -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Dave Plater wrote:

Try fail2ban Fail2Ban scans log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address or executes user defined commands. Regards Dave P

Thanks Dave, I'll have a look, but I kinda liked my temporary solution for the immediate problem. But, I have to admit, hitting :w was kind of scary from the other end of the connection. I didn't know if I was going to nuke myself or not. Thankfully, linux is smarter than that and won't disconnect established connections on changes to hosts.allow (I know, I screwed up the logic the first two times ;-) -- David C. Rankin, J.D.,P.E. | Rankin Law Firm, PLLC | Countdown for openSuSE 11.1 510 Ochiltree Street | http://counter.opensuse.org/11.1/small Nacogdoches, Texas 75961 | Telephone: (936) 715-9333 | openSoftware und SystemEntwicklung Facsimile: (936) 715-9339 | http://www.opensuse.org/ www.rankinlawfirm.com | -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Joop Beris wrote:

On Saturday 22 November 2008, David C. Rankin wrote:

...

I'll have a look, but I kinda liked my temporary solution for the immediate problem. But, I have to admit, hitting :w was kind of scary from the other end of the connection. I didn't know if I was going to nuke myself or not. Thankfully, linux is smarter than that and won't disconnect established connections on changes to hosts.allow

Hi David,

Nice solution ;-)

I think what you are looking for, is the package denyhosts (http://denyhosts.sourceforge.net/). I used to use it for my sshd monitoring and it's actually very good at it, even exchanges blocked IP's with others if you want it to.

Then I discoverd fail2ban, which has an openSUSE rpm (is in the repos even) and also can monitor other servers, like ftp and http. When I learned that, I switched to fail2ban. But if you only need you ssh daemon monitored, there's no reason not to use denyhosts. It gets the job done.

HTH,

Joop

Thanks Joop, Looks like I have quite a bit of reading to do with fail2ban, denyhosts, sshd sentry, and SuSEFirewall2. Good stuff. -- David C. Rankin, J.D.,P.E. | Rankin Law Firm, PLLC | Countdown for openSuSE 11.1 www.rankinlawfirm.com | http://counter.opensuse.org/11.1/small -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

* Richard [11-22-08 12:15]:

What I like about Fail2Ban is that it resets the banned IP addresses after a user determined period of time so that you don't basically get a DOS situation by having all the bogus IPs banned forever without intervention. That and the ability to watch other services like FTP as well.

As does DenyHosts, reset after time, but not other services, iiuc. -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

David C. Rankin wrote:

David C. Rankin wrote:

My only question is why couldn't I make:

sshd : ALL EXCEPT LOCAL my.remote.ip : ALLOW

work instead of the two entries I ended up making?

The " ALL EXCEPT LOCAL my.remote.ip " string takes a bit of deciphering to understand why it didn't work. Breaking it down, the answer can be found: The examples in /etc/hosts.allow show: ALL EXCEPT LOCAL Which is really like a double-negative within a double-negative. The man page states: EXCEPT Intended use is of the form: `list_1 EXCEPT list_2´; this construct matches anything that matches list_1 unless it matches list_2. So at first look, it would seem that: sshd : ALL EXCEPT LOCAL : ALLOW Would, for ssh, match 'ALL' EXCEPT 'LOCAL' allowing 'ALL' access to ssh except local addresses. (clearly not what the example was trying to do) But: LOCAL Matches any host whose name does not contain a dot character. So what it is doing is saying match all IP addresses in the world but not any that do *not* contain a dot, then allow. Well, the only addresses, out of all the IP addresses in the world, that do not 'not contain a dot' are local IP addresses --> so allow them. GOD THIS IS TERRIBLE A TERRIBLE CHOICE OF WORDS FOR AN EXAMPLE. So sshd : ALL EXCEPT my.ip.address : ALLOW does just what it says it will do. It will allow ALL to connect but *block* my.ip.address from being able to connect. After two aspirin, I guess it would make more logical sense if the example actually said: sshd : ALL EXCEPT NOTLOCAL : ALLOW Two more aspirin needed.... -- David C. Rankin, J.D.,P.E. | openSoftware und SystemEntwicklung Rankin Law Firm, PLLC | Countdown for openSuSE 11.1 www.rankinlawfirm.com | http://counter.opensuse.org/11.1/small -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

On Saturday, 2008-11-22 at 00:52 -0600, David C. Rankin wrote:

...

What is that automated Block??? package that updates your hosts.deny file if you have x attempts in y minutes from an IP?

You can use the automated block mechanism included in susefirewall. Simply activate it.

-- Cheers, Carlos E. R.

Damn, when did that sneak in there? Thank you Carlos. You know, somehow it is just gratifying to take a peek at the logs now: Nov 22 03:06:57 bonza sshd[930]: twist astro.kursastro.net to /bin/echo -e "\n\n\tAccess Denied from astro.kursastro.net\tSo kindly FOADAH\n";sleep 10 Nov 22 03:08:11 bonza sshd[939]: twist bno-84-242-66-10.karneval.cz to /bin/echo -e "\n\n\tAccess Denied from bno-84-242-66-10.karneval.cz\tSo kindly FOADAH\n";sleep 10 Nov 22 03:09:06 bonza sshd[947]: twist ::ffff:90.190.110.51 to /bin/echo -e "\n\n\tAccess Denied from ::ffff:90.190.110.51\tSo kindly FOADAH\n";sleep 10 Nov 22 03:10:13 bonza sshd[957]: twist ::ffff:67.40.86.204 to /bin/echo -e "\n\n\tAccess Denied from ::ffff:67.40.86.204\tSo kindly FOADAH\n";sleep 10 Nov 22 03:11:15 bonza sshd[993]: twist adsl-75-22-172-193.dsl.sndg02.sbcglobal.net to /bin/echo -e "\n\n\tAccess Denied from adsl-75-22-172-193.dsl.sndg02.sbcglobal.net\tSo kindly FOADAH\n";sleep 10 Nov 22 03:12:20 bonza sshd[1002]: twist 200-170-141-134.static.ctbctelecom.com.br to /bin/echo -e "\n\n\tAccess Denied from 200-170-141-134.static.ctbctelecom.com.br\tSo kindly FOADAH\n";sleep 10 Nov 22 03:13:25 bonza sshd[1011]: twist hpclab.cs.tsinghua.edu.cn to /bin/echo -e "\n\n\tAccess Denied from hpclab.cs.tsinghua.edu.cn\tSo kindly FOADAH\n";sleep 10 Nov 22 03:14:30 bonza sshd[1020]: twist ::ffff:221.8.255.134 to /bin/echo -e "\n\n\tAccess Denied from ::ffff:221.8.255.134\tSo kindly FOADAH\n";sleep 10 Nov 22 03:15:01 bonza /usr/sbin/cron[1033]: (david) CMD (/home/david/linux/scripts/Learn_as_spam_cron) Nov 22 03:15:08 bonza syslog-ng[2863]: STATS: dropped 0 Nov 22 03:15:42 bonza sshd[1063]: twist correo.rufinocoop.com.ar to /bin/echo -e "\n\n\tAccess Denied from correo.rufinocoop.com.ar\tSo kindly FOADAH\n";sleep 10 Nov 22 03:16:50 bonza sshd[1072]: warning: /etc/hosts.allow, line 64: can't verify hostname: getaddrinfo(interacivenetworksinc.com.uy): Name or service not known Nov 22 03:16:50 bonza sshd[1072]: twist 200.40.169.190 to /bin/echo -e "\n\n\tAccess Denied from 200.40.169.190\tSo kindly FOADAH\n";sleep 10 Nov 22 03:17:53 bonza sshd[1081]: twist 89-97-62-16.ip16.fastwebnet.it to /bin/echo -e "\n\n\tAccess Denied from 89-97-62-16.ip16.fastwebnet.it\tSo kindly FOADAH\n";sleep 10 Nov 22 03:18:51 bonza sshd[1090]: twist ::ffff:221.8.255.134 to /bin/echo -e "\n\n\tAccess Denied from ::ffff:221.8.255.134\tSo kindly FOADAH\n";sleep 10 Nov 22 03:20:02 bonza sshd[1101]: twist bno-84-242-66-10.karneval.cz to /bin/echo -e "\n\n\tAccess Denied from bno-84-242-66-10.karneval.cz\tSo kindly FOADAH\n";sleep 10 Nov 22 03:21:02 bonza sshd[1110]: twist ::ffff:121.33.199.40 to /bin/echo -e "\n\n\tAccess Denied from ::ffff:121.33.199.40\tSo kindly FOADAH\n";sleep 10 -- David C. Rankin, J.D.,P.E. | Rankin Law Firm, PLLC | Countdown for openSuSE 11.1 www.rankinlawfirm.com | http://counter.opensuse.org/11.1/small -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2008-11-22 at 03:27 -0600, David C. Rankin wrote:

Carlos E. R. wrote:

You know, somehow it is just gratifying to take a peek at the logs now:

Nov 22 03:06:57 bonza sshd[930]: twist astro.kursastro.net to /bin/echo -e "\n\n\tAccess Denied from astro.kursastro.net\tSo kindly FOADAH\n";sleep 10 Nov 22 03:08:11 bonza sshd[939]: twist bno-84-242-66-10.karneval.cz to /bin/echo -e "\n\n\tAccess Denied from bno-84-242-66-10.karneval.cz\tSo kindly FOADAH\n";sleep 10

ROTFL! But where are they getting that string from? I tried adding your code, modified, to /etc/hosts.allow: #sshd : my.remote.ip : ALLOW #sshd : LOCAL : ALLOW sshd : ALL : twist /bin/echo -e "\n\n\tAccess Denied from %h\tSo kindly FOADAH\n";sleep 10 And when I try to log in, I see (with a delay): cer@nimrodel:~> ssh localhost ssh_exchange_identification: Connection closed by remote host cer@nimrodel:~> And the logs: Nov 22 12:27:43 nimrodel sshd[7056]: twist 127.0.0.1 to /bin/echo -e "\n\n\tAccess Denied from 127.0.0.1\tSo kindly FOADAH\n";sleep 10 So... the log entry is entirely local. They don't get any text message, but your log is filled with refuse :-p You'd better modify that line of yours ;-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkn7jQACgkQtTMYHG2NR9V8wQCfeXYRYUmkh4MpQh3SxBR9t9fM gZUAn0gFEbSRP1Vm9TYR/YMWnc9C1jxz =5Cag -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

...

And when I try to log in, I see (with a delay):

cer@nimrodel:~> ssh localhost ssh_exchange_identification: Connection closed by remote host cer@nimrodel:~>

And the logs:

Nov 22 12:27:43 nimrodel sshd[7056]: twist 127.0.0.1 to /bin/echo -e "\n\n\tAccess Denied from 127.0.0.1\tSo kindly FOADAH\n";sleep 10

So... the log entry is entirely local. They don't get any text message, but your log is filled with refuse :-p

You'd better modify that line of yours ;-)

-- Cheers, Carlos E. R.

Carlos,

I saw that too, but I figured that the examples in /etc/hosts.allow that show that format must be sending the string somewhere besides the log. Maybe, in the past, it did get sent back to the person attempting to gain access, but now due to either some suse setting or some change in how the ssh handshake works, they don't see it any more.

But it sure makes finding the stuff in the logs easy ;-)

Did carlos try connecting only with a real ssh client, or did he try connecting with telnet or netcat? Perhaps the string is sent back but ssh the client discards it since it's not valid ssh protocol? If that's the case, then I say it's still valid to leave the message in there. Except as someone else pointed out, it doesn't piss the bad guys off, rather the opposite, it just confirms that there is really a nice machine/target/victim there. Where simply dropping or refusing the connection tells them a lot less. I seem to remember one approch that holds the connection open for a long time, wasting the attackers time and available tcp ports (and using up tcp ports on your end too). I don't remember which package does that or if it was simply a combination of ordinary sshd_config settings. As for the susefirewall option, there is another problem. Some of these attacks do not come from one ip, they come one or a few connections each from a swarm of different ip's, each of which is an end-users windows pc desktop with a virus. IE: bot-net. I don't know of any good way to block those yet. Most of my servers very job in life is to accept ssh connections from several hundred end-users from any IP anywhere. Their natural traffic often produces spikes of connections-per-second from single ips (everyone in a large office behind a nat router) and from many ips. Like when everyone in a large office behind a nat router starts working in the AM, or when they all reconnect after their net connection flickers. I think the only way to allow those while still blocking bot-net attacks, besides simply using some other port besides 22 for my users, would be to configure a special client (like a hacked PuTTY) that does some sort of port-knocking, which you can configure iptables to recognize. -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

On Monday, 2008-11-24 at 11:55 -0500, Brian K. White wrote:

...

Did carlos try connecting only with a real ssh client, or did he try connecting with telnet or netcat?

Real ssh client.

...

Perhaps the string is sent back but ssh the client discards it since it's not valid ssh protocol?

Could be.

Reminds me... when is the file "/etc/issue.net" sent to the clients? I don't see it via ssh. Could be related?

-- Cheers, Carlos E. R.

FOUND IT! (it will take preventing access for a while, but....)

From man ssh

/etc/nologin If this file exists, sshd refuses to let anyone except root log in. The contents of the file are displayed to anyone trying to log in, and non-root connections are refused. The file should be world-readable. OK! cd /etc ln -s /usr/bin/mplayer nologin Now for a little fun.... ;-) -- David C. Rankin, J.D.,P.E. | openSoftware und SystemEntwicklung Rankin Law Firm, PLLC | Countdown for openSuSE 11.1 www.rankinlawfirm.com | http://counter.opensuse.org/11.1/small -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

----- Original Message ----- From: "David C. Rankin" To: "suse" Sent: Tuesday, November 25, 2008 7:27 PM Subject: Re: [opensuse] What is with the script kiddies tonight??

Carlos E. R. wrote:

...

On Monday, 2008-11-24 at 11:55 -0500, Brian K. White wrote:

...

Did carlos try connecting only with a real ssh client, or did he try connecting with telnet or netcat?

Real ssh client.

...

Perhaps the string is sent back but ssh the client discards it since it's not valid ssh protocol?

Could be.

Reminds me... when is the file "/etc/issue.net" sent to the clients? I don't see it via ssh. Could be related?

-- Cheers, Carlos E. R.

FOUND IT! (it will take preventing access for a while, but....)

From man ssh

/etc/nologin

If this file exists, sshd refuses to let anyone except root log in. The contents of the file are displayed to anyone trying to log in, and non-root connections are refused. The file should be world-readable.

OK!

cd /etc ln -s /usr/bin/mplayer nologin

Now for a little fun.... ;-)

That file is used by more than just sshd. it's a generic sort of file that many *ix os's use, sometimes just by a few lines in /etc/profile, meaning you have already logged in to some daemon or other by the time /etc/nologin comes into play. sshd does read it a little earlier than that though. I would NOT do the above symlink or put anything but text into that file. Also, usually, root is still allowed to log in even when there is a /etc/nologin. (unless the daemon in question has other config which disables direct root login, such as /etc/securetty for telnetd, and sshd_config for ssh, etc...) It's not the place to play that kind of game. really. IE: more likely to crash your own daemons than borther any hackers. The RBL approach sounds great. Automatically report any ip's that the filter gets triggered into blocking. Now if that would go a bit further to where it bothers the admins of isp's that provide the offending ip's... -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wednesday 26 November 2008, David C. Rankin wrote:

Of course you are correct. However, I was being a bit more facetious than serious. More a Tom Sawyer/Huck Finn daydream than an actual plan. My choice of mplayer was just a bit more embellishment, the icing on the cake, if you will. I asked myself what would be one of the biggest binaries I could send (other than video or the openSUSE DVD itself), so I just sorted /usr/bin by size and mplayer was among the top, widely recognized -- just right.

If you're serious about sending something back to the people connecting to your ssh daemon, have a look at sshd's banner directive. It allows you to specify a text file to send to the other side over the ssh connection. You'd be sure they'd get it. I'm sure with some "voodoo" you could do interesting stuff with it. But seriously, why bother? The "attack" is probably coming from some poor Winblows user who had his machine compromised and doesn't understand why the intarwebs are so slow these days. Or from some admin who doesn't realize their box has been owned. At best, you'll crash the offending program on their end or even their computer. Retaliating doesn't serve any purpose and might even land you in hot water if you retaliate against the wrong target (spoofed IP and/or rabid admin). It only gives you a temporary feeling of satisfaction. I've been seeing attacks against ssh for a long time. It's a fact of life that when you make a service available to the outside, some lowlife will come and try to abuse that service. If you don't like that, don't run any services on the outside or impose limits on who you allow to connect. If you must run services, take sufficient measures to prevent abuse. If someone connects and wants to rummage around with the locks or knock on the door, fine. It's all part of the "background radiation" of the internet. If someone seriously tries to get in or is very persistent, report them to their ISP. They'll mostly be grateful for the information. Retaliation is a waste of bandwidth at best, and could land you in trouble at worst. At any rate, you're just polluting the already polluted "pipes" of the "intarwebs". Just my 2 cents, Joop

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Neil wrote: <snip>

Well, you could use it to send the hacked windows system a message. Something that'll alert the user there is something terribly wrong and request him to install a firewall and a virusscanner (or switch to a different one). Something that will not damage the system or impare his work even further. It may even remove pollution.

Neil

I think this idea is the triumph of hope over experience... :-) - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkkuiTQACgkQasN0sSnLmgI5XwCgmQL2AtFFzoBU4bXC0Dhp6mb/ w0MAn1LgXhVMZLmk+dtWJY9Dli7I7JjB =LqNu -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thursday 27 November 2008 05:49:08 am G T Smith wrote:

I think this idea is the triumph of hope over experience... :-)

Right. Without intention to insult anybody, the majority that have such problem are clueless or/and careless. They will dismiss message, if they see any. There is many computer users that have computer just for fun. They know nothing about how it works, viruses, trojans, bot nets, licenses etc. They buy computer and go to Internet without ever updating OS, or activating antivirus software. They would be better off if those 2 things would happen without any notification that they can dismiss. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Brian K. White wrote:

Except as someone else pointed out, it doesn't piss the bad guys off, rather the opposite, it just confirms that there is really a nice machine/target/victim there. Where simply dropping or refusing the connection tells them a lot less.

Brian: I agree and I ultimately just went with the disconnect. ssh : mynormal.offsite.IP : ALLOW ssh : LOCAL : ALLOW ssh : ALL : DENY I sure do wish I could send something back though. Just for a few hours I would love to give them ssh : ALL : twist cat /usr/bin mplayer But alas, it doesn't look like you can send anything back of ssh attempts. Additionally, since it was over the weekend and I was the only one that would need ssh, I just turned the port off at the router. After being closed for 24 hours, the frequency of the attempts dropped a fair amount. Though it could have just been the Sunday factor instead of the Friday factor. I haven't taken any stats, but it seems that Thursday-Saturday is the most active time for attacks (generally). With the immensity of the problem, I wish there was something that could be done to curtail all the malicious attempts. (I guess we could outlaw windows) But seriously, something will need to be done in a globally coordinated way in the future.

I seem to remember one approch that holds the connection open for a long time, wasting the attackers time and available tcp ports (and using up tcp ports on your end too). I don't remember which package does that or if it was simply a combination of ordinary sshd_config settings.

As for the susefirewall option, there is another problem. Some of these attacks do not come from one ip, they come one or a few connections each from a swarm of different ip's, each of which is an end-users windows pc desktop with a virus. IE: bot-net. I don't know of any good way to block those yet. Most of my servers very job in life is to accept ssh connections from several hundred end-users from any IP anywhere. Their natural traffic often produces spikes of connections-per-second from single ips (everyone in a large office behind a nat router) and from many ips. Like when everyone in a large office behind a nat router starts working in the AM, or when they all reconnect after their net connection flickers. I think the only way to allow those while still blocking bot-net attacks, besides simply using some other port besides 22 for my users, would be to configure a special client (like a hacked PuTTY) that does some sort of port-knocking, which you can configure iptables to recognize.

I had been meaning to try ssh on a higher port and with all the little beggers attacking port 22, I was motivated to go ahead and try. So far, the logs and deathly quiet. I like it. For those that haven't moved ssh to a higher port, it is actually very simple. I put together a little cheat sheet, should you feel adventurous. To move ssh to a higher port on openSuSE, you need to edit two files: 1. /etc/services 2. /etc/ssh/sshd_config First open /etc/services and find an "Unassigned" high port the you would like to use. ('grep Unassigned /etc/services' works well) I would look between 5000 and 9999 so you are left with a four digit port and don't have to type 5 digit for the port. If you like typing, then just stay under 64,000. After you have found a port to use, then copy the lines for port 22, change the port to your desired port number and then comment out the port 22 lines: #ssh 22/tcp # SSH Remote Login Protocol dcr reassigned to 5129 #ssh 22/udp # SSH Remote Login Protocol #ssh 22/sctp # SSH ssh 5129/tcp # SSH Remote Login Protocol dcr reassigned from 22 ssh 5129/udp # SSH Remote Login Protocol ssh 5129/sctp # SSH When you move the port Then edit /etc/ssh/sshd_config and change the Port number: #Port 22 Port 5129 The restart sshd, as root, rcsshd restart. You are ready to access your new ssh port with the port specified in the ssh command: ssh -p 5129 you@your.host.com Then all I had to do was update all my ssh aliases in .bashrc and the fact that ssh is now on a different port is completely transparent. Of course you have to change the port in you router as well. One show stopper for me would have been if the change caused difficulties with fish:// However, fish works just fine. All you need to do is add ':portnumber' to the end of the hostname like: fish://user@somehost.com:port/ or to eliminate the password promt (if your not using public/private keys) fish://user:pass@somehost.com:port/ Thanks for your help again Brian -- David C. Rankin, J.D.,P.E. | openSoftware und SystemEntwicklung Rankin Law Firm, PLLC | Countdown for openSuSE 11.1 www.rankinlawfirm.com | http://counter.opensuse.org/11.1/small -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

David C. Rankin schreef:

David C. Rankin wrote: (snip)

...

ssh -p 5129 you@your.host.com

Then all I had to do was update all my ssh aliases in .bashrc and the fact that ssh is now on a different port is completely transparent. Of course you have to change the port in you router as well. One show stopper for me would have been if the change caused difficulties with fish:// However, fish works just fine. All you need to do is add ':portnumber' to the end of the hostname like:

fish://user@somehost.com:port/

or to eliminate the password promt (if your not using public/private keys)

fish://user:pass@somehost.com:port/

Thanks for your help again Brian

Additional Information for rsync:

For rsync to work with the alternate port, you must enclose the ssh command and desired port number in single quotes. Example:

rsync -av -e 'ssh -p 5129' yoursite.com:~/tmp/somefile.doc tmp/

Works like a champ.

And scp insists on a capital P for some reason: scp -P 5129 LOCAL_FILE REMOTE_FILE -- Jos van Kan registered Linux user #152704 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hans Witvliet wrote:

hi,

On Mon, 2008-11-24 at 18:53 -0600, David C. Rankin wrote:

<snip>

Except for running ssh at another port (allready mentioned) you could do a "reversed port knocking" at your own door: (It's not mine idea, but a friend reminded me of it.) There are many versions of it but this schema i like most:

1) normally, all traffic on port 22 is plainly dropped 2) if you perform a ping on some high unpriv port, rule-set is reloaded and port 22 got opened. 3) After a succesful ssh-login, chang the ruleset that on port 22 only established tcp-connections are allowed, no new connecions. 4) after a predefined time (just short, to allow you to login) you go back to stage 1

...

From what i remember, it was just two slightly modified copies of your firewall-ruleset, two "at" commando's and a dozen perl-lines for listening on a dedicated ip-port.

hw

The main problem with the blacklisting approach is that it can be used to effectively create a DoS attack on legitimate users by getting them blacklisted from a service they need to use (IP addresses can be spoofed). As someone pointed out some time ago on this list there can be also some issues about how the addresses are tracked in the logs. The principle advantage of the approach is the relatively low administrative overhead as it is largely automated. White listing, by establishing that a machine (or user) has a legitimate right to connect, either via negotiation from a another port (as above), or some form of Radius style service authentication on the external domain boundary/firewall is an alternative approach. This has the disadvantages of a larger administrative overhead as the administrator has to explicitly setup user access (however on a DS based authentication mechanism this may be less of an issue), a possible further barrier to the user community of a further level of authentication (though this level of authentication can be certificate based), and precludes by definition open access (though you could have a DMZ for this). As this usually is performed on dedicated machine, servers should not normally be affected by such script kiddy attacks. The attack is blocked at the door not in the room. - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkkry94ACgkQasN0sSnLmgJePwCffR46IA5HpLbhl8HfdLY7EfYY UGYAn3VFSfVm3Ye2jrUlyvleNYNKHLJg =HEK0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Saturday 22 November 2008 08:43:14 Carlos E. R. wrote:

On Saturday, 2008-11-22 at 00:52 -0600, David C. Rankin wrote:

...

What is that automated Block??? package that updates your hosts.deny file if you have x attempts in y minutes from an IP?

You can use the automated block mechanism included in susefirewall. Simply activate it.

-- Cheers, Carlos E. R.

Carlos, can you give chapter & verse on where to find the automated block mechanism, please? It's early morning and I'm not feeling very clever :( I've also been getting the attacks that David describes, mostly from addresses in China, but once from Brazil. But maybe they've been spoofed? Bob -- Registered Linux User #463880 FSFE Member #1300 GPG-FP: A6C1 457C 6DBA B13E 5524 F703 D12A FB79 926B 994E openSUSE 11.0, Kernel 2.6.25.18-0.2-default, KDE 4.1.3 Intel Celeron 2.53GHz, 2GB DDR RAM, nVidia GeForce 7600GS -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Saturday 22 November 2008 09:53:54 medwinz wrote:

On Sat, Nov 22, 2008 at 4:49 PM, Bob Williams

wrote:

...

On Saturday 22 November 2008 08:43:14 Carlos E. R. wrote:

...

On Saturday, 2008-11-22 at 00:52 -0600, David C. Rankin wrote:

...

What is that automated Block??? package that updates your hosts.deny file if you have x attempts in y minutes from an IP?

You can use the automated block mechanism included in susefirewall. Simply activate it.

-- Cheers, Carlos E. R.

Carlos, can you give chapter & verse on where to find the automated block mechanism, please? It's early morning and I'm not feeling very clever :(

I've also been getting the attacks that David describes, mostly from addresses in China, but once from Brazil. But maybe they've been spoofed?

Bob

This lines taken from /etc/sysconfig/SuSEfirewall2

## Type: string ## Default: # # Services to allow. This is a more generic form of FW_SERVICES_{IP,UDP,TCP} # and more specific than FW_TRUSTED_NETS # # Format: space separated list of net,protocol[,dport[,sport[,flags]]] # Example: "0/0,tcp,22" # # Supported flags are # hitcount=NUMBER : ipt_recent --hitcount parameter # blockseconds=NUMBER : ipt_recent --seconds parameter # recentname=NAME : ipt_recent --name parameter # Example: # Allow max three ssh connects per minute from the same IP address: # "0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh" # # The special value _rpc_ is recognized as protocol and means that dport is # interpreted as rpc service name. See FW_SERVICES_EXT_RPC for # details. #

FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentna me=ssh"

medwinz

--

Yogi Berra - "I never said most of the things I said."

Thanks medwinz, I'll take a look at that. Bob -- Registered Linux User #463880 FSFE Member #1300 GPG-FP: A6C1 457C 6DBA B13E 5524 F703 D12A FB79 926B 994E openSUSE 11.0, Kernel 2.6.25.18-0.2-default, KDE 4.1.3 Intel Celeron 2.53GHz, 2GB DDR RAM, nVidia GeForce 7600GS -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. skrev:

On Saturday, 2008-11-22 at 00:52 -0600, David C. Rankin wrote:

...

What is that automated Block??? package that updates your hosts.deny file if you have x attempts in y minutes from an IP?

You can use the automated block mechanism included in susefirewall. Simply activate it.

-- Cheers, Carlos E. R.

Hi list, I qoute: "You can use the automated block mechanism included in susefirewall. Simply activate it." ...eh how, where? (:-)) -- ------------------------------ Med venlig hilsen/Best regards Verner Kjærsgaard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

On Monday, 2008-11-24 at 16:26 +0100, Verner Kjærsgaard wrote:

...

Hi list,

...

I qoute: "You can use the automated block mechanism included in susefirewall. Simply activate it."

...

...eh how, where? (:-))

Just search the answers to that email, it was explained at least twice.

-- Cheers, Carlos E. R.

Carlos -- Is this what you're referring to? from Carlos <previously> at http://linux.derkeiler.com/Mailing-Lists/SuSE/2005-12/msg02391.html <quote> The Sunday 2005-12-25 at 23:17 +0200, Andre Truter wrote:

...

Why bother with the firewall, do it the easy way: sudo echo "PORT : IP_ADDY/NETMASK" >>/etc/hosts.deny && rcsshd restart done.

But won't this still cause my box to respond to their request - even to just say DENY?

Right. I just tried the trick I mentioned the other day, making use of the "recent" module for iptables, and it works. It allows me to try six times in a minute, and the seventh it blocks me. It can be adjusted. This is what I see on the log for failed tries: Dec 26 01:46:15 nimrodel kernel: SSH attack: IN=eth0 OUT= MAC=00:40:f4:2e:b1:21:00:30:84:0a:8b:f5:08:00 SRC=192.168.100.1 DST=192.168.100.2 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=50094 DF PROTO=TCP SPT=1048 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 It is as follows; edit /etc/sysconfig/scripts/SuSEfirewall2-custom; search for function "fw_custom_before_antispoofing()" near the beginning. Insert this: fw_custom_before_antispoofing() { # Blocking ssh attacks iptables -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack --update --seconds 60 --hitcount 6 -j LOG --log-prefix 'SSH attack: ' iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack --update --seconds 60 --hitcount 6 -j REJECT true } Then reload the firewall with the command "SuSEfirewall2": nimrodel:/etc/sysconfig/scripts # SuSEfirewall2 SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... SuSEfirewall2: Firewall customary rules loaded from /etc/sysconfig/scripts/SuSEfirewall2-custom SuSEfirewall2: Firewall rules successfully set nimrodel:/etc/sysconfig/scripts # I don't have a full time network connection, so I can't try this "out there", but I think it should work, it is easy and automatic, and efficient on the network, I suppose. And, I know almost nothing about iptables, so I don't know if the rule is perfect; for example, I don't know whether ith should better be "DROP" instead of "REJECT"... - -- Cheers, Carlos Robinson </quote> -- David C. Rankin, J.D.,P.E. | openSoftware und SystemEntwicklung Rankin Law Firm, PLLC | Countdown for openSuSE 11.1 www.rankinlawfirm.com | http://counter.opensuse.org/11.1/small -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On November Monday 24 2008, David C. Rankin scratched these words onto a coconut shell, hoping for an answer:

Carlos E. R. wrote:

...

On Monday, 2008-11-24 at 16:26 +0100, Verner Kjærsgaard wrote:

...

Hi list,

I qoute: "You can use the automated block mechanism included in susefirewall. Simply activate it."

...eh how, where? (:-))

Just search the answers to that email, it was explained at least twice.

-- Cheers, Carlos E. R.

Carlos -- Is this what you're referring to?

from Carlos <previously> at http://linux.derkeiler.com/Mailing-Lists/SuSE/2005-12/msg02391.html

<quote>

The Sunday 2005-12-25 at 23:17 +0200, Andre Truter wrote:

...

...

Why bother with the firewall, do it the easy way: sudo echo "PORT : IP_ADDY/NETMASK" >>/etc/hosts.deny && rcsshd restart done.

But won't this still cause my box to respond to their request - even to just say DENY?

Right.

I just tried the trick I mentioned the other day, making use of the "recent" module for iptables, and it works. It allows me to try six times in a minute, and the seventh it blocks me. It can be adjusted. This is what I see on the log for failed tries:

Dec 26 01:46:15 nimrodel kernel: SSH attack: IN=eth0 OUT= MAC=00:40:f4:2e:b1:21:00:30:84:0a:8b:f5:08:00 SRC=192.168.100.1 DST=192.168.100.2 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=50094 DF PROTO=TCP SPT=1048 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

It is as follows; edit /etc/sysconfig/scripts/SuSEfirewall2-custom; search for function "fw_custom_before_antispoofing()" near the beginning. Insert this:

fw_custom_before_antispoofing() {

# Blocking ssh attacks iptables -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack --update --seconds 60 --hitcount 6 -j LOG --log-prefix 'SSH attack: ' iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack --update --seconds 60 --hitcount 6 -j REJECT

true }

Then reload the firewall with the command "SuSEfirewall2":

nimrodel:/etc/sysconfig/scripts # SuSEfirewall2 SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... SuSEfirewall2: Firewall customary rules loaded from /etc/sysconfig/scripts/SuSEfirewall2-custom SuSEfirewall2: Firewall rules successfully set nimrodel:/etc/sysconfig/scripts #

I don't have a full time network connection, so I can't try this "out there", but I think it should work, it is easy and automatic, and efficient on the network, I suppose.

And, I know almost nothing about iptables, so I don't know if the rule is perfect; for example, I don't know whether ith should better be "DROP" instead of "REJECT"...

,snip> David, I think the program you asked about, which tied up the little dears for, well as long s the users wanted to, was a"quicksand" type of program, they tried to log into a computer that was basically a "honeypot" and found themselves stuck in the La Brea tarpit.. I think the program was actually called LaBrea Tarpit, or perhaps just tarpit. or something very like it. It is allegedly illegal to use in the US.. It "interferes" w/ someone else's use of their computer. It was years ago this program began.. nearly 10 yrs if my remembery mode is working at all. I never heard if the program or users ever got the thing in the courts, who would after some time issue a decision that would say it was or was not illegal to protect my computer, by making it so these little devils to pester folks, not to mention the illegality of what he was attempting to do, by connecting to my computer. <shrug> hope that helps someone -- j "Its like a song I can hear playing right in my ear That I cant sing I cant help listening" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Saturday 22 November 2008, Herbert Graeber wrote:

...

Nov 22 00:32:00 bonza sshd[31402]: Invalid user clemence from 192.25.133.82 Nov 22 00:32:01 bonza sshd[31402]: error: PAM: User not known to the underlying authentication module for illegal user clemence from at1.ftc.agilent.com Nov 22 00:32:01 bonza sshd[31402]: Failed keyboard-interactive/pam for invalid user clemence from 192.25.133.82 port 49704 ssh2 Nov 22 00:33:01 bonza sshd[31410]: Invalid user clemence from 193.224.241.4

Hey, I know a Clemence...and she's certainly not invalid...quite the contrary...I'd label her as extremely valid. :-) Apparently your ssh daemon doesn't know her, but it doesn't know what is's missing. Joop

Try denyhosts. SImilar to the kiddies making a distributed attack using multiple ip addresses, denyhosts collects these adresses on a server, to make them available to all denyhost users for a distributed defence.

Oooh! An ssh RBL! That answers the question in my last post. -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org