| 1 |
Dale <rdalek1967@×××××.com> wrote: |
| 2 |
|
| 3 |
> Michael Orlitzky wrote: |
| 4 |
> > On 11/10/2015 04:11 PM, wabenbau@×××××.com wrote: |
| 5 |
> >> You can disable password login for that user on the server. Then |
| 6 |
> >> he can only login via ssh key. Only with the knowledge of the root |
| 7 |
> >> password it is not possible to gain root access to the server. An |
| 8 |
> >> attacker also needs the ssh key. And with a camera, keylogger, or |
| 9 |
> >> measuring radiation he can not fetch that key. |
| 10 |
> >> |
| 11 |
> > This is pretty close to what I originally asked for, thank you. |
| 12 |
> > If you disable all password logins to the server AND disable remote |
| 13 |
> > root logins altogether, then you can stop someone from gaining root |
| 14 |
> > by peeking over your shoulder as you type. |
| 15 |
> > |
| 16 |
> > Unless they bash you over the head and swipe your laptop. But still, |
| 17 |
> > I'll take it. |
| 18 |
> > |
| 19 |
> > |
| 20 |
> > |
| 21 |
> |
| 22 |
> Now I'm curious. Just how often does all this stuff take place? I |
| 23 |
> figure when hackers attack, they go straight for root access anyway. |
| 24 |
> If that access is disabled then they will never get in, no matter how |
| 25 |
> long they try. From what little I know, even if they have the root |
| 26 |
> password they still can't get in unless they also have the other user |
| 27 |
> account to login with first. |
| 28 |
|
| 29 |
A server is called is called a server because it has has something to |
| 30 |
serve. ;-) If these services (web, ftp, mail, file or whatever else) |
| 31 |
are accessible through a public network (Internet, Intranet, WLAN) |
| 32 |
then attackers are are looking for vulnerabilities in these services. |
| 33 |
Often they use exploit-kits like blackhole for that. If they find a |
| 34 |
vulnerability, they trying to exploit it. If the attackers are |
| 35 |
successful or not, depends also on how good the server is hardened, |
| 36 |
that means how good it is protected against such vulnerable services. |
| 37 |
|
| 38 |
There are different mechanisms for such protections. For example |
| 39 |
simple chroot()jails or, much more complex, access control systems |
| 40 |
like apparmor and selinux for isolating services, and SSP and PAX for |
| 41 |
protection against stack- and bufferoverflow based exploits. |
| 42 |
|
| 43 |
-- |
| 44 |
Regards |
| 45 |
wabe |
Archives