Ask Slashdot: Security Digests For the Home Network Admin? 123
New submitter halcyon1234 writes "I'm currently cutting the webhost cord, and setting up a simple webserver at home to host a couple hobby websites and a blog. The usual LAMP stuff. I have just enough knowledge to be dangerous; I know how to get everything set up and get it up to date, but not enough to be sure I'm not overlooking common, simple security configurations. And then there's the issue of new vulnerabilities being found that I'm not even aware of. The last thing I want is to contribute to someone's botnet or spam relay. What readings/subscriptions would you recommend for security discussions/heads up? Obviously I already read (too much) Slashdot daily, which I credit for hearing about some major security issues. Are there any RSS feeds or mailing lists you rely on for keeping up to date on security issues?"
try this (Score:5, Informative)
http://www.securityfocus.com/
Good starting list (Score:2, Informative)
You may (or may not) know to do these things:
Only allow SSH pubkey access for maintenance. Turn off remote passwords altogether in sshd_config.
Move SSH to some non-standard port (away from 22). Just makes it harder for outsiders to find the port.
Run something like denyhosts to kick off people trying brute force passwords on your server and to log their activity.
Consider only allowing SSL (port 443) access to the webserver and close down all other ports in iptables.
Just a few things (which may be obvious) to get you started.
most distros have a security list (Score:5, Informative)
You said LAMP--well, most L distros have a security list you can subscribe to to keep up-to-date on this sort of thing. Also, Linux Weekly News (lwn.net) regularly posts security announcements from most major distros
The Attempts are Expensive (Score:1, Informative)
I used to do this and stopped because there are so many attempts on a domain it seemed to slow down my internet connection. This was a long time ago, and it is possible there were some strategies I could have used with my router, but generally, it was pretty disruptive even though no actual breach occurred.
Of course, that doesn't mean you shouldn't try. Good luck!
Re:Use a long random password (Score:4, Informative)
"That seems to be enough"
Until you don't upgrade your kernel/sshd/apache and get hit by an exploit. Long password won't help you when there's an application exploit, which if you're using secure passwords, is the exploit you're likely to see.
I subscribe to oss-security which is quite useful in keeping abreast of things, but may be overkill for a home webserver.
Re:Check your Internet Acceptable Use documents (Score:5, Informative)
Most ISPs do NOT allow this kind of stuff. While it might fly under the radar, there is always the possibility they will shut off your access. /em
In my experience, most ISPs really don't care. And if your hobby site/blog goes offline for a couple days... its not the end of the world.
Also, in my experience with both the large local ISPs as well as 2 smaller ones, dynamic ip... on most broadband is essentially the same as static (*). You'll probably have the same IP address for years at a time (**) and they only change when they replace/upgrade the network and even if you are on static you will be assigned a new address occasionally as well due to network upgrades.
So in practice, dynamic ip addresses changes only slightly more often than static ones, and the only difference is that with static ones they'll usually make an effort to give you a few days notice that you'll be getting a new address before it happens. But you still have the downtime as DNS propagates.
(*) - I'm talking about static ip service on broadband. The static IP you get with a co-located server or T1 tends to be somewhat less likely to change than the static ip you get with a "Business ADSL" package, which still allocates your IP via DHCP, and the only difference real between static and dynamic is, as I said, they make some effort to give you a heads up before they change it on you.
(**) - As an aside, this fact makes tracking users/households by ip address for advertising purposes fairly reliable.
Get an AWS Micro Site (Score:2, Informative)
Forget running it at home, get an Amazon AWS Micro site; it's free and the default config is as secure as possible. IPTABLES is easy to configure via the AWS web gui or you can manually create better rules once on the system. AMZN keeps track of updates, you just have to remember to ssh in every once in a while.
Some links and tips? (Score:4, Informative)
some sites:
http://www.securitywizardry.com/radar.htm [securitywizardry.com]
(a little heavy on the java)
https://isc.sans.edu/ [sans.edu]
You could subscribe to the CERT messages, but they kinda lag. There are some good security related mail lists which
I can't remember at the moment...
Check available updates for packages and kernel...
Look at mod_security for apache
If you're running wordpress or some other CRM app, be careful on how much you rely on third party packages
If you have phpadmin or webadmin installed, you may want to limit what IP's have access to it.
If you're running sshd, you may want to block bruteforce attempts after a certain number of bad tries, You should
probably just use certificate based authentication instead of passwords.
Not too hard (Score:5, Informative)
The best place to start is here
http://www.us-cert.gov/cas/signup.html [us-cert.gov]
then onto the security announce list of whatever distro you use.
Those two alone will probably give you enough information to keep your system safe
So, what is security? (Score:5, Informative)
First: The only way to connect to your system is over a logical port. So, learn netfilter / IPtables and shut down all ports you don't need. The book "Running Linux" by Dalheimer and Welsh has a pretty good section on netfilter / IPtables. My recommendation - just leave port 22 and 80 (maybe 443 if you're having people log into your web application remotely). Default policy is drop packets unless it matches one of those ports.
Second: Turn off remote root login, typically found in sshd_config. This'll stop much of the probing.
Third: You don't want to allow someone to relentlessly try passwords. Get a program like Fail2ban. This will allow a certain number of login attempts before it bans the IP, just dropping the packets and not letting the password authentication module test them.
Fourth: Strong username/password combinations. The attacker has to guess the correct combination. Get jiggy with it. Unusual username and unusual passphrase password. Especially for the root user.
Fifth: Stop having Apache broadcast all of its version information. When someone is looking at response headers, they should see just that it's Apache and not Apache version XYZ. Apache loads several config files and reads them as one long config file (they're broken up for easier management). There's a setting in Apache to do that.
Sixth: In Apache's config files, turn off directory listings. Again, a simple configuration text file setting which eludes me at the moment. Apache The Definitive Guide by Laurie and Laurie is a good book to have. This info is also available on the web.
Seventh: Read your log files regularly. auth.log, error.log are very informative ones. Doing a lastlog command on a regular basis helps.
Finally - What is security?
1) You don't want people writing to where they shouldn't be writing.
2) You don't want people reading what they shouldn't be reading.
3) You don't want people executing what they shouldn't be executing.
Set up permissions well. Don't change them willy-nilly but if reading/writing most stuff on your box requires being part of the root group, that's pretty good security.
Finally, finally - keep reading various technical sites on the web for new security problems. Address as necessary.
Re:Good starting list (Score:5, Informative)
Because there will come a time when you are away from home and will think
"if only I had made SSH accessible I could fix the server right now using my mobile to ssh in, instead of having to go home"
1 (one) tip for you (Score:3, Informative)
It's called "staging".
F*ck comments. F*ck all the other interactive "web 2.0" sh*t. Do your Wordpress or whatever, then suck it out of the DB, convert to static HTML, and put it on the external webserver.
Problem (pretty much, well 99%) solved.
Try again? (Score:2, Informative)
Most ISPs offer business accounts that you can do whatever you want(to a degree).
Re:Check your Internet Acceptable Use documents (Score:5, Informative)
Do what I do...get a cheap business account with your ISP.
I have had mine with Cox cable business for about a decade now...even moving around different places, they move it for me.
It is only about $70/mo...I get about 10-15 down, and usually about 5-6 up for speed.
I can run whatever servers I want...web, email, you name it, no ports blocked. I also have no data caps.
I even get a low level SLA.....and the few times I"ve had trouble, I call in..if there is any wait, I just leave my name/number and usually it has never been more than about 6-10 minutes for them to call me back. Once..I found my connection had gone down a bit after midnight. I called, not expecting much...but damned if when we figured it WAS a line problem, they had a truck out there on the pole near my house in about an hour...freaking after 1am!??! The problem was solved that night (early morning).
Frankly, I dunno why most people bother with the consumer level ISP crap...just pay a few more dollars and get a real connection that you can do with as you please.
Bugtraq and Full Disclosure (Score:3, Informative)
Bugtraq [wikipedia.org] and Full Disclosure [wikipedia.org] mailing lists are a good read. Almost all new vulnerabilities are posted to one of these lists. In addition, many Linux distros post their security notices here (Ubuntu used to, but now only posts on their own list). The CERT list mentioned by previous commenters is also good, even if it can be a little slow at getting the news out. Microsoft, Apple and others report their security notices through this list.
Re:So, what is security? (Score:4, Informative)
Instead of disallowing root logins, turn off password-based authentication and use certificates instead. Also move your ssh port from 22 to a high unused port. Then install fail2ban (as the parent post suggested) or a set of iptables rules to ban excessive ssh connections.
Install logwatch and have it filter out much of the harmless information in the logs and report the interesting stuff to you.
Re:Reliability testing... (Score:4, Informative)
@halcyon1234 Honestly, all you *really* need to do at the OS security level is get a router and only forward the web and ssh ports then use iptables to block problem-ips. Just make sure you set up keypair login for ssh and DISABLE password login completely. Of course you'll need to secure your website itself, but you hopefully already did that when running on the shared server.
If you tend to get a fair bit of traffic (or attract unruly visitors), put your private lan on a second router that is connected to the one with the server (so the server has no access to the rest of your network). This way if the server DOES get compromised, your network is still safe
Cheap VPS (Score:3, Informative)
I've been using a VPS for $3/month from 123systems.net. I haven't done much with it yet, and I don't know how consistent it is, but so far I have no complaints. buyvm.net was another I was looking at that I believe has an even cheaper option ($15/yr!). Like someone else said, check out http://www.lowendbox.com/ [lowendbox.com] to become informed about the options. Of course, you get only a pittance of ram/cpu for these bargain basement prices (and often limited availability -- buyvm sounds like a bit of a lottery), but it is still nice to have full control over a linux system that I can pack it up and deploy it to another linux server with more resources/consistency if/when I need to, while playing around with it for cheap now. It's also nice to have a far away offsite backup in case my city gets EMP'ed / destroyed by aliens / etc.
Also, like someone else mentioned, I have run ssh/www for about 15 years on my home ISP since whenever I got broadband with no complaints from my ISP.
Re:So, what is security? (Score:3, Informative)
Third: You don't want to allow someone to relentlessly try passwords. Get a program like Fail2ban. This will allow a certain number of login attempts before it bans the IP, just dropping the packets and not letting the password authentication module test them.
I stopped using fail2ban a few years back when botnets had become so large that every attempt from an obviously coordinated attack came from a different IP address. To get rid of the flood of log messages about failed login attempts I added some simple rules to my iptable config:
iptables -A INPUT -p tcp --dport http -m string --algo kmp --string 'GET /some/page' -m recent --set --name KNOCK
iptables -A INPUT -p tcp --dport ssh -m recent --rcheck --seconds 30 --name KNOCK -j ACCEPT
This results in the ssh port being closed unless you have accessed a certain page on my web site (which doesn't actually have to exist) within 30 seconds before making the ssh connection from the same IP address. While it doesn't add any real security (it certainly is not a replacement for ssh authentication) it is very effective in fooling the botnets. To get in:
wget my.domain/some/page
ssh user@my.domain
Re:Reliability testing... (Score:4, Informative)
And move SSH off of the default port. It's amazing how much that cuts down on automated hacking attempts. It goes from a constant, 24 hour thing to... well, when I did it a year ago, I've seen perhaps 2 attempts made since.