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

Re: [K12OSN] Safety of Allowing Access from Internet



Hans Ekbrand wrote:


Hi Hans, thanks for your feedback.



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.


Absolutely. I mean, "whatever service you open to the 'Net makes you vulnerable to some extent."


The most secure place for a server is *buried underground*, which of course is rather pointless. Opening *any* service to the internet is a risk of sorts.. We can take steps to secure it, but the fact is, we are never entirely free from risk, and if we believe we are, then the risk is greatest.

We can only adopt the best possible security position, but never be completely free of risk.

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.


Agreed - especially if the server is 100% up-to-date. Physical access - well, it depends on your people.. I agree the problem of physical access is often overlooked - or is it that the server O/S is *so* secure, that physical access is more of a concern ? If so, that says a lot for Linux.


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.


Thanks for that. Perception duly modified. 8-)



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


as above. point well taken.



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.



I am suggesting that once an attacker is 'in' as a normal user, their quest for 'root' privelege is mostly won. It is important to make sure that the attackers' path towards 'root' is a dead-end, ie, a chroot jail.


8-/ I am assuming readers are famailiar with a chroot jail... (where a program is executed in it's own environment using the `chroot` command.)
This way, it is impossible for any application (ie, FTP Server) to `cd ../../` back directories to get to the *actual* / directory - and therefore impossible for system access except what is specifically copied to the chroot'ed directory.


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.


point also well taken. I should have known that.



Thank you. 8-)


/steve






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