Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


create a root - Page 2
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

create a root

2»

Comments

  • prometeusprometeus Member, Host Rep

    The rescue cd is the only safe choice. A compromised box would have installed stealth modules or trojan libs so even in single mode you are under high risks.

  • vedranvedran Veteran

    @DanielM said: Hence why i really wanted a backdoor.

    By creating a backdoor you're just giving another entry point to everyone else. Secure your root account as much as you can, if it gets compromised you will probably want to reinstall and restore your backup anyway. So what's the point?

  • @u4ia said: @Aldryic I agree that the wording of the original question sounds sketchy, but after some discussion isn't how to regain access to your compromised VPS valuable community information?

    In that case, why don't I start a topic on how to make mid-grade explosives from household goods? But, after some discussion we'll come to find out that I'm merely giving a refresher course on subbonding to those that would like to brush up on their chem knowledge.

    Sorry, but this is one of those cases where I look at the 'reason' for the question and can think of nothing but 'cheap excuse'. How to secure your VPS against remote attacks is valuable community information. How to plant backdoors and compromise a system goes against good security, and it sounds to me like someone is going to regret sharing a VM with one of these chaps down the road.

  • @Aldryic said: How to secure your VPS against remote attacks is valuable community information

    Best to trust LET rather than the so-called professionals on WHT.

    @Aldryic said: and it sounds to me like someone is going to regret sharing a VM with one of these chaps down the road

    Perhaps you could give some advice? or are you just trolling :D

  • miTgiBmiTgiB Member

    @DanielM said: are you just trolling

    Trolling in the morning is almost as good as the smell of napalm, which sticks to kids.

  • prometeusprometeus Member, Host Rep

    @miTgiB said: the smell of napalm

    Good Apocalypse now citation! :-)

  • AldryicAldryic Member
    edited June 2012

    @DanielM said: Perhaps you could give some advice? or are you just trolling :D

    No, not trolling at all. My advice would be to follow the three basic steps:

    1. Disable root login.
    2. Disable password login, setup RSA keys.
    3. Move SSH to a non-standard port.

    Follow those, and you've just eliminated 99.9% of brute attempts. Add in fail2ban if you want to go the extra mile and take care of that last tenth.

    For any daemons or services you run, get the -version info, and go a few google searches. Look for security guides, and any documented vulnerabilities, and you'll have a very good chance of preventing a compromise.

    Creating backdoors does nothing except leave an easy point of entry for anyone wanting to root your VPS. You should be keeping backups of critical information anyways; if you do get compromised, the first thing you want to do is completely shut down the VPS. If there's data you absolutely have to retrieve, explain the situation to your provider, and ask if they can tarball it for you (ovz), or put up a temporary liveCD ISO (KVM/etc) so that you can get to your data without the compromised VM coming back online.

    Thanked by 1HalfEatenPie
  • DamianDamian Member
    edited June 2012

    Additionally, what are you doing that would warrant needing to plan a backdoor?

    We have JIC network backdoors, but haven't found a need for server backdoors.

  • @Damian said: Additionally, what are you doing that would warrant needing to plan a backdoor?

    Someone needs server access specifically root access.

  • DamianDamian Member

    Why not use sudo then? Yes, it's a bit of a pain in the butt to use, but you can then limit what they do, and also, log their actions.

  • @DanielM said: Someone needs server access specifically root access.

    If you distrust them enough that you feel you need your own backdoor, then they don't need root :P

  • @Aldryic said: If you distrust them enough that you feel you need your own backdoor, then they don't need root :P

    I need server work doing. hence the problem.

  • vedranvedran Veteran

    Wait, I'm lost. Haven't you said you need root account to use only to recover if your server gets compromised? I don't like where this is going ...

  • DanielMDanielM Member
    edited June 2012

    @vedran said: Wait, I'm lost. Haven't you said you need root account to use only to recover if your server gets compromised? I don't like where this is going ...

    Well the guy who is going to be connected isnt exactly trustworthy (As in if he changes the root pass i wanted to be able to get access to the server incase of a lockout). I think i might just go ahead and hope for the best. Run a backup first etc.

  • Add him to sudoers and let him use commands he's likely to use. Disallow things like passwd etc

  • @DanielM said: Well the guy who is going to be connected isnt exactly trustworthy

    ...then why are you letting him on in the first place? Even if he doesn't change your root pass, what guarantee do you have that he won't leave exploits/etc?

    This sounds pretty damn shady to me.

  • @Aldryic said: ...then why are you letting him on in the first place? Even if he doesn't change your root pass, what guarantee do you have that he won't leave exploits/etc?

    I think its better taking the backup method or livecd method then. But its plainly because he offered the best price for the work that needed done.

  • netomxnetomx Moderator, Veteran

    Why dont you implement the 2 step verification with Google? You eliminate the "hacking" of your account.

    Also, idk if it is possible but I think it can: use Truecrypt. Make all your valuable information in the crypted drive, and manually mount it when it boots.

  • I dont see why you'd ever need a second root account.

    when I had several servers, I disabled root login, set SSH to a different port, installed Fail2Ban and moved it to only allow from a specific list of IP's (My other servers and myself. I also had a tiny VPS which was able to connect to everything, just incase my ISP started to change my static IP)

    Tl'dr -- Install anti-brute, keep software Up2Date, jail any other users, initiate "only from xxx.xxx.xxx.xxx ip".

    Simplest ways. Otherwise, once you're "hacked", you can always use the methods above. But personally, there's no need for a second root account.

  • NickMNickM Member

    A second root account can be useful if you give root a default shell that's located on a separate filesystem that may not be mounted when booting into single user mode (for example, /usr/local/bin/bash if you've compiled bash yourself and /usr is a separate partition). You can give the other root (UID 0) account a default shell that's in /bin so that you can always access a shell. FreeBSD used to do this, with an account called "toor", I believe.

Sign In or Register to comment.