On Thu, Dec 29, 2011 at 4:51 PM, Thijs Kinkhorst <th...@debian.org> wrote: > On Thu, December 29, 2011 16:37, Nicolas Carusso wrote: >> >> How about creating a Referense list with all the suggestions that we are >> doing? >> If all of you agree, Let's start now. >> >> SECURITY LIST >> ****************** > > There's already the Securing Debian HOWTO: > http://www.debian.org/doc/manuals/securing-debian-howto/ > > Perhaps it's an idea to see if your suggestions are in there, and if not, > to suggest additions/changes/patches to the Debian Documentation project. > You can get in contact through debian-...@lists.debian.org.
chroot is done other way than the guide now days, so the patch is indeed needed. I've seen the "change port 22" tip since I know ssh, and I still see servers "hacked" in 2012. Also, I see neither in the guide, neither in the points stated here, talk about disabling unneeded forwarding. I think one big step, is to try to understand each option in the sshd_config man page, and to test the results in each environment, and each admin evaluate each option to _house_ policies. SSH in the main firewall? is this the policy? AllowTcpForwarding Specifies whether TCP forwarding is permitted. The default is “yes”....... By fortune, the default for GatewayPorts is "no", but if that is not your policy... But maybe other defaults doesn't like you: MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6. MaxSessions Specifies the maximum number of open sessions permitted per net‐ work connection. The default is 10. There are lot of other options, about timeouts, MaxStartups, PermitEmptyPasswords, PermitTunnel, StrictModes Maybe that if you read the manual of the tool just installed, you start finding incomplete "security lists", etc. Anyway... at the end... As well as you can search for filezilla XMLs indexed online (ip/user/pass of lot of environments), I've seen public+private keys (+amazon IDs) in bitbucket pushed as "mydotfiles" and indexed by search engines. While the sysadmin fights to secure ARP, TCP, IP, DNS, SSL and then the services over, and the ssh developer does privilege separations and its security stuf, the web developer will index the credentials in a search engine. Put the credentials in a plain email, worldwide messenger service, post-it in the tasks table or in a shared folder with anonymous access for a co-worker. Step one to know how to secure a service in your server: do you know how to attack such service ? Do you know the common threats available in the net to attack such service ? then play chess Not every SSH attack will be "a worm that exploits a code fault in port 22 of random network ranges". But maybe you get an attack of just another tech person like you trying to do "it" (DoS the service (or the server), be root, do the machine heat ram and kill other process, etc). Or maybe you get someone that just got the credentials from anyplace. That young student doing practices by 1 month has access to all company backups ? And... last but not least: system/security updates is not enough in some environments, so maybe add to the list: * maintenance (renew ssh keys periodically or on events, delete rules for old users/groups/hosts, etc) As well as, if you follow best practices and makes some cpu parse your logs by you... "report attackers" maybe other "task" of the maintenance process. You "can" report any abuse to the responsible internet providers, but that does not implies "results". Some attacks will be in the ssh log, and others in the iptables ulogd. Did you already configured your firewalls, network, and sshd_config? good job! next chapter: your desktop ~/.ssh/config also allow the same and more options (disable unused protos, ciphers, methods, etc). If you're root of ssh client machines, you should do the same in each one. Greetings, this mail is too long to see if I can DoS Debian servers delivering it. ;-P -- Iñigo -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakdtd8s_e7h_nsygnvczzdytb+k9djbi8ucxh5mxy8ulx-r...@mail.gmail.com