Ask Slashdot: Security Digests For the Home Network Admin?

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?"

Comments

Reliability testing...

[Idbar]

When you're done with your setup. Post a story on Slashdot linking to your website, that's a fairly good stress test.

Bonus points if you add something like "My awesomely new bulletproof website!". That should kick off the reliability test engines from /.

Re:Reliability testing...

[rdwulfe]

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.

try this

[Anonymous Coward]

http://www.securityfocus.com/

Check your Internet Acceptable Use documents

[GeneralTurgidson]

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. Besides, with a dynamic IP any change to it will take your website offline until DNS catches up. Hosting is cheap, I don't see why you'd want to cancel it unless it's hurting the bank.

Re:Check your Internet Acceptable Use documents

[vux984]

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.

Re:Check your Internet Acceptable Use documents

[LordLucless]

Most American ISPs. The only Australian ISP I'm aware of who has this in their AUP is Telstra, and nobody who knows how to configure a setup like that would be using Telstra anyway. That's one of the advantages of a metered system - because the ISP gets paid more the more data you use, they have absolutely no motivation to try and limit your ability to move data. Whereas the US ISPs seem to spend more of their time figuring out how to block data-heavy protocols than actually trying to provide a service.

Re:Check your Internet Acceptable Use documents

[StormReaver]

Hosting is cheap, I don't see why you'd want to cancel it unless it's hurting the bank.

Simple: control.

I used pghoster for a while, because they provided PostgreSQL hosting. The service was fine until:

1) They switched my hosting from Linux to BSD. That unnecessarily broke all my cron jobs, which I fixed with a fair amount of grumbling about time I didn't have.

2) They made another infrastructure change. That unnecessarily broke all my cron jobs, which I fixed with a fair amount of grumbling about time I didn't have.

3) They made some other change which broke my PHP, which I fixed with a fair amount of grumbling about time I didn't have.

The bottom line was that they did not seek my input about what to change and when to change it. And their business model probably doesn't allow them to do so. After all, they have a lot of different users with a lot of conflicting demands. It's just the nature of shared hosting. I have no bad will towards the service, but the requirements of shared hosting are just incompatible with the requirements I have on my time.

So I bought a cheap block of static IP addresses ($20 extra per month) that put me into the business class of customer; the class with the terms of service explicitly allowing me to run my own servers. I've been doing this for about six years now, and I would hate to ever have to return to shared hosting.

And for those wondering why I didn't use a dynamic DNS service: I did, and they suck, suck, suck. But more importantly, I didn't want to find my Internet access sporadically terminated for violating terms of service.

So yes, there are very good reasons for wanting to avoid the major hassles of shared hosting. For me, shared hosting's lack of of control was a deal killer.

Re:Check your Internet Acceptable Use documents

[cayenne8]

Most ISPs do NOT allow this kind of stuff.

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.

most distros have a security list

[Xtifr]

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

Not too hard

[sirsnork]

The best place to start is here

http://www.us-cert.gov/cas/signup.html

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?

[Beeftopia]

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.

The single most useful thing

[taustin]

On a publicly visible web server is to set up set the directive for the default web site (the first one in the virtual host list) to default deny to everyone. Then put your web site on a different virtual host. 99.9% of the scans I see come in by IP address, which gets them the default site. Any legitimate traffice will come in by domain name. This set up not only denies the script kiddes access to any PHP forms you've got, it convinces their 'bots to give up very quickly, which means less of a toll on your bandwidth.

(As someone noted, the standard consumer highspeed account prohibits running servers. Many commercial accounts do, too, unless you told them you're running a server of some kind. You may also have to get them to unblock port 25 if you want to run your own mail server - be very careful if you do that, though. You don't want to be a spamfest rathole without knowing it.)

Re:Good starting list

[Bitsy Boffin]

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"