Hey,
I’ve seen many posts about how to speed up user name\password requests for sshd, but I what I want is a delay. Main reason for this delay is, as we all know, there are not very nice people on the internet and many want into my machine.
So what I want is someone logins and then there is a 5 second wait (or something like that) so that the number of attacks becomes bottlenecked. I think I read how I can limit the number of connections from one IP, but I’m less concerned with that as I am slowing them down.
On 09/21/2011 05:16 PM, sailorcire wrote:
> Any Suggestions?
just put sshd on a non-ssh-standard (high) port, and all the
script-kiddies and WinBots won’t likely find that door to knock
on…and, then when a real person (like maybe you) walk up to the
correct door, you won’t have to wait for some timer to run down…
–
DD Caveat
openSUSE®, the “German Automobiles” of operating systems
On Wed, 21 Sep 2011 15:16:02 +0000, sailorcire wrote:
> Hey,
> I’ve seen many posts about how to speed up user name\password requests
> for sshd, but I what I want is a delay. Main reason for this delay is,
> as we all know, there are not very nice people on the internet and many
> want into my machine.
>
> So what I want is someone logins and then there is a 5 second wait (or
> something like that) so that the number of attacks becomes bottlenecked.
> I think I read how I can limit the number of connections from one IP,
> but I’m less concerned with that as I am slowing them down.
>
> Any Suggestions?
Check out “blockhosts” - I’ve found that to be a very good alternative.
Using a non-standard port will also help, but ultimately, blocking
invalid logins and using just public key authentication will secure the
system best.
It provides an awful lot of super handy tools in one very easy to use suite. If you configure LFD too, then the offending IP is blocked after the specified number of logins.
Oh - another super fun trick is port knocking. The SSH port is closed until you knock, at which time the knocking IP is allowed.
Never heard of that but the name implies interesting Would You care to explain how does it work or where to find appropriate information on the topic ?
There are some parameters there to tighten. Check for MaxAuthTries, MaxSessions, MaxStartups.
You can disable PasswordAuthentication completely and work with keys. This would lock out all script kiddies. In case you are in the comfortable position to connect to your ssh server from fixed IP numbers only, you can disable the ssh port (or whatever port you are using) in SuSEfirewall2 and allow it for certain client hosts with FW_TRUSTED_NETS=“2.2.2.2,tcp,22” (example).
Wow, I wasn’t expecting so many respondents. Thanks!
It is a public server, so moving SSH isn’t the best option.
I like the idea of port knocking, but haven’t had a good chance to look at it
I also will look at MaxAuthTries and bumping that down to 3 (I think the default is 6?), but the MaxSessions I don’t think will work, because I’m expecting a lot of a lot of connections from one IP, luckily it is static if there is a way to set that.
Distribution of keys scare the **** out of me, especially if one of the keys get in the wrong hands. I can destroy the account, but who knows what damage can be done? I know good passwords and stuff, but still if the bad guy is in then they are in.
I might, just to wear a belt and suspenders [to keep my pants from falling down], put snort or some other IDS just to be a paranoid penguin.
On Fri, 23 Sep 2011 15:16:02 +0000, sailorcire wrote:
> Distribution of keys scare the **** out of me, especially if one of the
> keys get in the wrong hands. I can destroy the account, but who knows
> what damage can be done? I know good passwords and stuff, but still if
> the bad guy is in then they are in.
The key getting in the wrong hands is no different than the password
getting in the wrong hands…And is probably less likely as it’s not
something that you can just write down and put on a post-it note on the
monitor (well, I suppose you could but that wouldn’t be very useful).
If a system is compromised, regardless of whether a public key is
compromised or a password is compromised, you have the same issues to
address.
I apparently need to clean up my language on the forums.
Yes, it’s 6 vs a half dozen on keys vs passwords I think, with the smaller number going to keys. I don’t know just feel better with passwords even though they are more vulnerable to social engineering attacks ricks.
On Fri, 23 Sep 2011 19:56:02 +0000, sailorcire wrote:
> hendersj;2386994 Wrote:
>> On Fri, 23 Sep 2011 15:16:02 +0000, sailorcire wrote:
>>
>> > Distribution of keys scare the **** out of me, especially if one of
>> the
>>
>>
> I apparently need to clean up my language on the forums.
We try to maintain a family-friendly atmosphere - openSUSE is used by a
wide variety of people around the world, and not just the geek crowd.
> Yes, it’s 6 vs a half dozen on keys vs passwords I think, with the
> smaller number going to keys. I don’t know just feel better with
> passwords even though they are more vulnerable to social engineering
> attacks ricks.
It’s natural to feel better with something one is more comfortable/
familiar with. That doesn’t mean it isn’t a good change to make, though.
I’ve used keys myself for years, and as long as you keep the key secure,
you’re going to be secure.
I still see attempts on my ssh server with passwords (blockhosts shows
currently 12 hosts blocked, hmmm, I need to see why one of them has a
count of over 1000 attempts, though, that shouldn’t have happened with my
config), but they only get ‘n’ attempts from any given IP address.
denyhosts - Python program that automatically blocks ssh attacks by adding entries to /etc/hosts.deny. DenyHosts will also inform Linux administrators about offending hosts, attacked users and suspicious logins.
fail2ban - Bans IP addresses that make too many authenticaion failures
Both those apps can at least prevent persistent hammering from a single host.
Remember that apps like this can also be a problem, if the attacker masquerades as a legitimate host, you’ll probably end up blocking legitimate hosts.
On 08.10.2011 01:06, tsu2 wrote:
>
> Here’s a couple recommendations to the OP,
>
> A couple apps which can enhance your security
>
> denyhosts - Python program that automatically blocks ssh attacks by
> adding entries to /etc/hosts.deny. DenyHosts will also inform Linux
> administrators about offending hosts, attacked users and suspicious
> logins.
>
> fail2ban - Bans IP addresses that make too many authenticaion failures
>
> Both those apps can at least prevent persistent hammering from a single
> host.
> Remember that apps like this can also be a problem, if the attacker
> masquerades as a legitimate host, you’ll probably end up blocking
> legitimate hosts.
>
How would that happen? Just curious.
I’ve had a script here called ‘blockhosts’ for years and I’m quite
pleased with it.
When a certain (adjustable) number of failed log in attempts occurr
the address it’s coming from is blocked for a certain (adjustable)
number of hours.
> On 08.10.2011 01:06, tsu2 wrote:
>>
>> Here’s a couple recommendations to the OP,
>>
>> A couple apps which can enhance your security
>>
>> denyhosts - Python program that automatically blocks ssh attacks by
>> adding entries to /etc/hosts.deny. DenyHosts will also inform Linux
>> administrators about offending hosts, attacked users and suspicious
>> logins.
>>
>> fail2ban - Bans IP addresses that make too many authenticaion failures
>>
>> Both those apps can at least prevent persistent hammering from a single
>> host.
>> Remember that apps like this can also be a problem, if the attacker
>> masquerades as a legitimate host, you’ll probably end up blocking
>> legitimate hosts.
>>
> How would that happen? Just curious.
> I’ve had a script here called ‘blockhosts’ for years and I’m quite
> pleased with it.
>
> When a certain (adjustable) number of failed log in attempts occurr the
> address it’s coming from is blocked for a certain (adjustable) number of
> hours.
>
> http://www.aczoom.com/blockhosts
>
> How could such an arrangement block legitimate hosts?
A DOS specifically crafted against something like blockhosts could in
theory consist of specially crafted IP packets that the DOS’er (the one
initiating the DOS) builds to masquerade as a legitimate IP address.
Then a number of failed logins from that apparently legit source address
would lock out the actual legit address.
In such an event, the attacker wouldn’t be trying to break into the
system, but to prevent your own legitimate access to the system.
They would need to know where you normally connect from. If they know
where you work, for example, they could send fake source packages
spoofing that netblock and effectively prevent you from getting into your
own system.
It’s quite rare (because it requires some pretty specific knowledge about
the system owner), but it is possible.
On 08.10.2011 13:44, Jim Henderson wrote:
> On Sat, 08 Oct 2011 05:17:24 +0000, Vahis wrote:
>> I’ve had a script here called ‘blockhosts’ for years and I’m quite
>> pleased with it.
>>
>> When a certain (adjustable) number of failed log in attempts occurr the
>> address it’s coming from is blocked for a certain (adjustable) number of
>> hours.
>>
>> http://www.aczoom.com/blockhosts
>>
>> How could such an arrangement block legitimate hosts?
>
> In such an event, the attacker wouldn’t be trying to break into the
> system, but to prevent your own legitimate access to the system.
OK, I understand. That is possible if I have a fixed IP I always connect
from and “they” know it.
I could still connect to my host say over UMTS and edit the block file
if it went to this.
I can also white list my own address.
Then again also “they” could use that address.
I could also use a proxy to connect if “they” made it impossible for me
to log in from my regular address.
I think in very rare situations like this I probably would use port
knocking.
> They would need to know where you normally connect from. If they know
> where you work, for example, they could send fake source packages
> spoofing that netblock and effectively prevent you from getting into your
> own system.
>
> It’s quite rare (because it requires some pretty specific knowledge about
> the system owner), but it is possible.
Everything that is not impossible is possible
Still I think that to recommend scripts like blockhosts, which I happen
to like very much, is a good piece of advise for a user who needs to ask.
Vahis
openSUSE 11.4 (x86_64) 2.6.37.6-0.7-default main host main host
openSUSE 12.1 Beta 1 (x86_64) 3.1.0-rc7-3-desktop in VBox
openSUSE 11.4 (i586) 3.0.4-43-desktop “Tumbleweed” in EeePC 900
Would You care to explain how does it work or where to find appropriate information on the topic ?
Thanks guys.