61–70 of 355 posts
I've never understood the point of fail2ban if you disable ssh password authentication. Yeah, it might eliminate some spam in the logs, but if you only allow key-based authentication that doesn't really matter.
Keys can be brute-forced.
Earlier quoted context omitted.
Sure, it'll not stop dedicated manual intrusion attempts, but it will actually prevent a ton of automated bots from even just trying to connect with common passwords through SSH.
Which is irrelevant if you have any one of: strong passwords, no passwords, fail2ban
> The days of passwords are over. You’ll enhance security and ease of use in one fell swoop by ditching those passwords and employing public key authentication for your user accounts.
ssh keys are better than passwords only because they contain (and require) more information. On the other hand, if your dev's machine is lost or stolen or compromised, so is your ssh key. This is especially a problem in environments with a shared account with full access, as you have. So, it's probably a good idea to make sure you're using a passphrase with your ssh key (during ssh-keygen), unless you need a passwordless login for a shell script or other automated remote system.
> passwd deploy: Set a complex password - you can either store it somewhere secure or make it something memorable to the team. This is the password you'll use to sudo.
Not necessarily. Anybody with access to the "deploy" account can use "passwd" to change its password to anything they like. (Edit: I'm wrong on this! passwd does require your current password; I've just gotten used to doing it for other accounts via sudo, which doesn't.) Changing the passwd on your own account doesn't require sudo. For this reason, I think it's better to simply give deploy nopasswd access to everything, and then delete and lock deploy's password to prevent it from being used at all (passwd -d -l deploy). You'll have effectively the same amount of security, but this way nobody will need to remember or retrieve a complex password, and you'll prevent, say, some accident in /etc/ssh/sshd_config from making deploy remotely accessible via a password.
You can do something better than this though, but it takes a little effort. Deployment is often the same steps over and over again (an rsync or an occasional apachectl graceful in my case). You can give the deploy user nopasswd access to only a shell script that's writable only by root; this way, deploy can still do 90% or more of their job without ever being given system administrator rights. You do have to be a little careful writing shell scripts though -- $* and "$@" still trip me up once in a while.
> Logwatch is a daemon that monitors your logs and emails them to you. This is useful for tracking and detecting intrusion.
This seems of dubious security value to me -- probably better as a generic sysadmin tool, so that you get annoyed by noisy logs and seek out and fix minor problems instead of ignoring them. Thing is, if someone does get access to your server, you pretty much can't trust it at all anymore. With services like Linode, you're really better off just launching a clean new instance, re-running your setup script (if you have one), and moving your data over.
I had to deal with the occasional intrusion in some pretty icky servers at an ISP once upon a time. We used rkhunter for a while, but I learned pretty quick that successful attacks against Linux servers are plenty enough sophisticated to alter all the basic tools that you would use to detect and remove the rootkit.
There is one caveat: I've been playing around with the idea of setting up rsyslogd to route syslog messages to mysql, and then using mysql replication to have an up-to-the-second offsite copy. I'd combine that with Snoopy (https://github.com/a2o/snoopy) or something similar. The point isn't to try to clean up an intrusion, it's to see how the intrusion happened so that I could close that hole. I haven't gotten around to setting this up yet, so I can't say anything terribly smart about it.
Finally: if you're going to have a problem with unauthorized access to your Linux or BSD server, it's probably going to be via one of its services, not via brute force ssh or anything similar. So, if you're concerned about this kind of stuff (and if you're being paid to be a sysadmin, you have to be), then you need to spend most of your attention making sure that your various services are set up correctly (apache/php/mysql/postfix/dovecot/spamassassin/etc. in my case).
Why install fail2ban and logwatch instead of csf?
Looking through the responses here, I'm hopeful that someone will launch a "Sysacademy" variant for system administration training. There are tutorials scattered around the web, but (at least for those of us who don't know where to look), there doesn't seem to be one place that puts in under one umbrella.
I had fun this past November with Snori74's Grep101 course.
I don't think it's open right now, but when it runs, it's a great stab at exactly what you're describing.
Initial blog: http://grep101.blogspot.com/
I also recommend changing the default SSH port.
Don't do this. It adds almost no extra security and makes it hard for routers that prioritizes port 22 traffic as interactive.
Looking through the responses here, I'm hopeful that someone will launch a "Sysacademy" variant for system administration training. There are tutorials scattered around the web, but (at least for those of us who don't know where to look), there doesn't seem to be one place that puts in under one umbrella.
While I agree these practices seem pretty safe/standard, it's still enough manual work that many people will just skip half of it out of laziness for small projects. Does anyone have good reusable Puppet (or bash scripts) published that they use on all new servers?
Here's something I wrote very quickly (bash script): https://github.com/vahek/vSetup It does most of the stuff mentioned in the post, however doesn't setup automatic updates or Logwatch.
* Puppet, Chef, Ansible, Salt, CFEngine, etc.