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

Re: [K12OSN] Safety of Allowing Access from Internet

On Fri, Dec 06, 2002 at 10:07:45AM +1300, Steve Wright wrote:
> Todd O'Bryan wrote:


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

"open to the Internet" does not mean open to all ip:s or all MAC
adresses, see my other post.

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

The additional security risk for opening a -tiny- hole for internet
access can be VERY small, OTOH physical access is THE security problem
number one.

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

I think you are mistaken here. root logins via ssh and key
autentication are MORE secure than normal user login escalating to
root priviledges with su OR sudo. Again, see my other post, and note
that the normal user account might be already hacked by a local user.

> 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-/

Let the students do scp (or rsync over ssh) with key-based

> >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,

Or disable password logins to ssh totally, which IMHO is a better


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

I don't get what you mean here.

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

Disagreed. Free software is made MORE secure by making the security
mechanisms public. Security by obscurity is not the way to go.

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: pgp00007.pgp
Description: PGP signature

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