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

Re: [K12OSN] Safety of Allowing Access from Internet



On Thu, Dec 05, 2002 at 03:11:53PM -0500, 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...)

There are ways to tightening it good enough.

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

A. If you have a ethernet connection from home, then you could add the
MAC address as an additional layer of security, so that only packets
from that MAC address will be accepted by the firewall.

B. If you have a static IP at home (I had until recently), then you
can add that layer too, so only packets from you static IP will be
accepted.

While both can be faked, those go a long way, since for an attacker
the server will not even be visible (if s/he doesn't know, AND is able
to fake your MAC address and your IP)

C. Configure sshd to only accept autentication by keys, not passwords
(you must set both PasswordAuthentication and
PAMAuthenticationViaKbdInt to "no") When you have done that, it is
more secure to login as root, rather than login as a normal user and
escalating to root priviledges with su or sudo, since IF your normal
user account is hacked (by a local user) it is very easy for them to
get the root password when you type it (you don't check your aliases
and your $PATH everytime you login, do you?).

D. Keep your private keys PRIVATE (e.g. by using a good passphrase).

E. If you can use A and/or B, then you could open up a bit more, e.g.
ICMP ping is good to have.

> 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.)

Let them have easier passwords when they authenticate in school, don't
allow passwords AT ALL for ssh logins from internet. (I THINK that you
could even generate keys for them with a passphrase and place the
public key in $HOME/.ssh/authorized_keys and make that file
root.[user] 644, thus making it impossible for them to add a key that
has no passphrase. I haven't tested that though.)

-- 
Hans Ekbrand (http://sociologi.cjb.net) <hans sociologi cjb net>
GnuPG key: 1024D/7050614E (currently active subkey 03CE8884)
Fingerprint: 1408 C8D5 1E7D 4C9C C27E  014F 7C2C 872A 7050 614E
Key available at keyserver.kjsl.com   Encrypted emails prefered.

Attachment: pgp00006.pgp
Description: PGP signature


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