Securing SSH

Guillermo Garron ggarron at alketech.com
Wed May 24 04:10:39 UTC 2006


Yes you are right, you can get completly blocked if you missed your 
options... what i do for this , is to have a second door. (another Linux 
box) to wich i can go to.. and from this to the first and unblock me :)

but it depends on everyone wich option to take, anyway you are right,,, 
mine is a little bit dangerous. :)

regards,

Guillermo.


jdow escribió:
> That is NOT what I consider a comfortable idea while I am on the road,
> guillermo. The configuration I have simply rate limits attempts. So if
> I screw up due to a keyboard with no capslock on it that I use with my
> laptop, I am not permanently locked out. I can wait a couple minutes
> and get in. (I also do this with pop3s and imaps. I REALLY want to be
> able to get in from wherever I am likely to travel. Erm, I do tend to
> lock out parts of the world I do not expect to visit. Most of Asia is
> now blocked in front of my little tool as I discover netblocks that
> make the attempts. It's interesting that few if any other parts of
> the world seem to be running attacks. For every one attempt from say
> the US I get two dozen from Asia. I'll have to unblock Southern
> China soon. My partner's makeing a trip there for business in the
> near future. I also maintain a permanent hole to ONE other address
> on the net where I have a shell account. I figure that's safe and my
> next level backup for getting in when I have to.)
>
> I also trust the iptables firewall more than tcpwrappers, although I
> keep both in the "circuit."
>
> {^_^}    Joanne, color me paranoid.
> ----- Original Message ----- From: "Guillermo Garron" 
> <ggarron at alketech.com>
>
>
>> I can also recommend denyhosts
>>
>> yum install denyhosts
>>
>> when you fail n time the login via SSH your IP will be added to the 
>> /etc/hosts.deny/ you can configure the "n" ...
>>
>> you can also configure it to avoid adding the IP of your office to 
>> the /etc/hosts.deny/ even if you fail the logging, no matter how many 
>> times.
>>
>> This should mantain the hacker out of your system if you have a 
>> strong password for all your users, and limit the "n"to a small 
>> number no dictionary attack should have success.
>>
>> hope it helps.
>>
>> regards,
>>
>> guillermo.
>>
>>
>> jdow escribió:
>>> From: "Brian D. McGrew" <brian at visionpro.com>
>>>
>>>> Good morning,
>>>>
>>>> I'm looking to tighten up my ssh configuration.  I have to have SSH 
>>>> open
>>>> on the box at home so I can get to it from the office.  I've found
>>>> several articles on securing ssh that include deny root access and
>>>> require 'wheel' group membership for su.
>>>>
>>>> Is changing the port to something non-standard a good idea?  What else
>>>> can I do; can someone point me to a good write up on it?
>>>
>>> At the risk of being tendentious about it this is the trick I found
>>> works very well:
>>>
>>> ===8<---
>>> $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 \
>>>  --rcheck --seconds 120 --hitcount 3 -j LOG --log-prefix 'SSH REJECT: '
>>> $IPTABLES -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \
>>>  --rcheck --seconds 120 --hitcount 3 -j REJECT --reject-with tcp-reset
>>> ===8<---
>>>
>>> Modify it to match your defines and names. I built my own set of rules
>>> that have some special capabilities in them that I need. (I open a 
>>> video
>>> streaming hole when needed from another host on the system, for 
>>> example.)
>>>
>>> What this does is prevent any site from making more than two tries in
>>> 120 seconds. So far all attacks have been steady streams at VERY high
>>> rates of connection attempt. They all get blocked after the first two.
>>> Barring a cosmic accident with the right password being guessed right
>>> off there's no chance of a break in even with ABCDefg as a password
>>> before the Earth is engulfed by the Sun as the Sun ages. Even if they
>>> get the 120 second rythmn going a decent password would be good just
>>> an awesome long time. So it's not worth their efforts.
>>>
>>> {^_^}   Joanne
>>>
>>
>> -- 
>> fedora-list mailing list
>> fedora-list at redhat.com
>> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list 
>




More information about the fedora-list mailing list