On Saturday, February 19, 2011 04:28:11 am Anne Wilson wrote:
> On Saturday 19 February 2011 10:20:30 Tim wrote:
> > On Fri, 2011-02-18 at 16:07 -0500, Alex wrote:
> > > I'd like to move it to a higher port to avoid the normal doorknob
> > > rattling that occurs with ssh running on a public server.
> >
> > Even with it on a different port, you'd probably want to implement some
> > firewalling that auto-bans an IP after few failed attempts. That stops
> > them from continually trying to get through.
> >
> > I think there was a package called fail2ban, or something similar, that
> > did that automatically.
>
> Fail2ban is easy to set up, and I've seen it stop attempts here.
>
> Anne
The one time I suffered a rootkit on Linux was when someone
used a bug in ssh to get into my system. Fortunately, for me,
I discovered the rootkit within hours of it happening and reloaded.
I am paranoid about ssh and welcome suggestions that increase my ssh
security configuration, in particular, and overall security, in general.
Currently, for ssh on my system, I do the following:
1) in my /etc/ssh/sshd_config file
a) I specify which users can use ssh (AllowUsers rsewill ...)
b) I explicitly specified only protocol 2 could be used until that
was the default in later versions of ssh. (Protocol 2)
c) I switch to a non-standard port (Port ...)
d) I do not permit root logins, (PermitRootLogin no)
e) I ignore user known hosts (IgnoreUserKnownHosts yes)
f) I do not permit password authentication (PasswordAuthentication no)
I do not permit kerberos authentication.
This leaves public key authentication.
Please make sure the key bits are large enough, default is 2048 for RSA,
and make sure the person, with the private key, protects the private key.
2) in iptables
a) I whitelist the IP addresses of those I permit coming in through ssh.
If one can't whitelist IP addresses,one might try blacklisting
IP address ranges. For example, if one lives in Europe, one might not
expect an ssh connection from the United States or Russia or China.
Please note, I do not believe blacklisting is that effective.
First, the zombie PCs can be anywhere, in any country.
Second, people can use proxy services to get around country blacklists.
If you still want to try to blacklist countries,
please do a google search, China IP range, to get some sites
that list IP address ranges for various countries.
I can't/won't recommend any particular site, but can list a few
examples from this google search:
http://www.ipaddresslocation.org/ip_ranges/get_ranges.php
http://www.countryipblocks.net/country-blocks/select-formats/
http://www.find-ip-address.org/ip-country/
With the advent of IPv6, you need to start whitelisting and
blacklisting IPv6 addresses when your ISP switches to IPv6.
The default, for most ports, is to drop incoming connects.
IPSec seems to be an exception. I'm not sure I like having
IPSec as an exception unless I expect IPSec traffic.
Why aren't there iptables filters that allow outgoing IPSec
connections, but not incoming IPSec connections....
The normal IPv4 iptables filters also allow IPSec connections.
Is this the "default" or have I accidentally enabled IPSec?
b) I set up my iptables filters to drop packets from a source that
fails to connect in <n> attempts over a certain period of time.
I would suggest doing a google search: "ssh-evil" iptables
for examples. If you are not comfortable with iptables and
iptables filters, please get a trusted friend to help you.
The iptables filters are your firewall; you want all filters correct,
and in the correct order, or you leave yourself open to attack.
It sounds like fail2ban scans log files for break-in attempts, not just
for ssh, but for other protocols as well. It would be a welcome addition.
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
