[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] Safety of Allowing Access from Internet

Todd O'Bryan wrote:

Forgive the stupid question, but how dangerous is it to have a k12ltsp server visible from the internet? (A recent thread has made me wonder...)

not at all unsafe. *provided* that machine is 100% up to date with the latest packages.

It is a fact, that *any* server open to the Internet has an element of risk - that is just how the Internet is..

If your server provides critical internal services, I would *not* open it to the Internet at all.. I would look for a solution along the lines of ;

Rsync /home+UIDs+GIDs to a seperate machine, and allow ssh+vnc to that machine - not your internal Terminal Server. This way, if that machine were attacked, it will not take down your entire network. It will be inconvenient, but that is all. If your Terminal Server System is attacked, you have a lot to lose.

I'm thinking of allowing ssh access (only) so that I could administer the machine from home and, if that goes well, maybe allowing the kids to access the machine to work from home, especially to backup their work from school.

To access the system yourself, for admin duties, you will need the highest security possible, and than means carrying your digital key with you and taking all possible steps to protect it.

ssh from your home machine to the "Internet Access" box using your digital key, and then ssh, with substantial passphrase to the Internal network, and then `sudo` *only*. `su -` must NOT work, and all logins as 'root' on *any* machine must be dis-allowed on *any* console except the local Server Console.

There must be no way that an attacker can get *any* admin priveledge on your network.

It goes without saying that telnet will be disabled.

For student access, consider having your webserver publish their ~/public_html/ directory... <wince> though I don't think the county IT office will let you do that.. 8-/ nor do I think it will particularly accomplish anything. You will also create for yourself the task of "Securing Apache" which is a science in itself. 8-/

Currently, this isn't allowed by the county's IT office, and getting it set up will involve much begging and pleading, preferably with some decent facts to back myself up. Given that no login names or passwords would be sent in clear text and the machine would have an IP address but no hostname, am I really opening myself up to major scariness?

no, not really.

Security is about two things ;

1.) Placing a service on-line that people *want* to exploit, and usually means a domain-name, and a webserver. If you do not *have* a domain name, *or* a webserver, then there is effectively nothing to exploit.

2.) Securing the services that you do present, which leads us onto your next point ;

On the same topic, the system tells people when they pick a bad password, but it will let them do it in spite of that. Is there a way to enforce good password selection using the system already in place? (I look over my kids' shoulders when they first create accounts and make them pick a good password, but there's nothing to stop them from changing them to something easy later.)

For any publicly accessable service to the Internet, you must make sure that your passwords are secure, and that means having the system regularly attempt to crack its' own passwords. There is Linux software to do this, and at times when your server is lightly loaded you should run `crack` against your own password database. Any accounts that fail and have their passwords cracked, immediately get suspended and the sysadmin advised. Your users will soon learn to use appropriate passwords. If `crack` can't guess/calculate the password, even after looking at /etc/shadow, then no one else is likely to either.

Consider also, that if an attacker gains entry to a user acount - can they then get 'root' privelege on that machine, and the next machine in the network. This must not happen. The classic way of securing FTP was to run the FTP daemon in a 'chroot jail.' This way, the attacker can `cd /` and they don't get your root directory. 8-) The same could be done for your /home directory, I am sure.

*PLEASE, would others with experience on this subject add their constructive criticism to this document. I am aware that I may have "defined *a* standard" that may(will?) have holes in it, and since this email will be widely indexed (by Google) it needs to be correct. (And not published at all to be the most secure - security policy and mechanisms should not be published.)*

HTH regards, Steve

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]