OMV3 Hacked (I have a rootkit installed)

1. offizieller Beitrag

    Hi, the subject explains the problem, I have a rootkit on my system, something quite similar (probably the same) as this guy :


    http://stackoverflow.com/quest…f-etc-are-starting-automa


    I want to remove but Im not able to, doesnt matter what I do it keeps on creating processes.


    So I dont mind to reinstall, the problem is that I created a raid1 (previous installation on another drive) in order to have a HA system drive, and I dont want to loose the raid 1, so there is some way to reinstall OMV3 without loosing the raids ?


    Current status is :
    2 drives , one small partition for boot, another partition for raid md1 where I have the system installed, and a third partition for raid md2 in order to use that for data.


    I would like to know if exist some commando like : set everything to fresh install

    • Offizieller Beitrag

    Since you have no idea the extent of the hacking, I would not use anything from the previous install. I would wipe the drive. If you have to have raid1 for the OS drive (which I don't understand why), install Debian Jessie first. That installer lets you create a raid 1 array. Then install OMV on top of that.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    How would something like this get on an OMV installation? Obviously there is no exact answer to this, but surely there is something that other OMV users can look out for to be certain that they are safe?

    Yes I analyzed with rkhunter, no match.


    Not sure if if was a rootkit or what, it had several scripts all along the system, and several process spawned at boot (not sure how, probably compromissing bins or injecting code on startups scripts).


    I know how it happened, previously I had a small nas server with OMV2, opened to internet, every has been fine for a couple of years, last week a disc failed and since I had in mind improving the nas with more space I bought 2 discs and installed OMV3 from scratch and began configuring things, the problem is that the new installation with default password was opened to the internet since the preovious nas was opened via napt in the router. So, someone scanned, discovered omv3 isntalled and tried the default password, it was my fault, I didnt think that would happen so fast.


    Now


    Zitat von ryecoaaron

    Since you have no idea the extent of the hacking, I would not use anything from the previous install. I would wipe the drive. If you have to have raid1 for the OS drive (which I don't understand why), install Debian Jessie first. That installer lets you create a raid 1 array. Then install OMV on top of that.

    I did a purge of the fs booting from a usb install and a rsync -ax fromthat USB install (OMV3) . Actually this is how I did the installation in the first time, installed default OMV3 to USB and from that OS USB created the raid 1 and rsynced the content. Well raid1 for system is because I wanted HA on system disks too.Thanks a lot for the help

    • Offizieller Beitrag
    Zitat von David B

    How would something like this get on an OMV installation? Obviously there is no exact answer to this, but surely there is something that other OMV users can look out for to be certain that they are safe?

    weak or common root password. Needless exposing the system to the internet. A plugin configured with weak security. Myself, I only expose a non-standard ssh port that only accepts ssh keys and no root login to the internet on most systems. I do have the nginx plugin serving web pages on port 80 but the OMV web interface is on a different port. You really should only expose the needed ports to the internet. All other ports should be blocked.


    As he mentions, he accidentally left the admin password at the default AND had the system exposed (guessing fully exposed) to the internet.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag
    Zitat von flechoide

    So, someone scanned, discovered omv3 isntalled and tried the default password, it was my fault, I didnt think that would happen so fast.

    As a matter of curiosity, roughly how long did you have your box exposed?

    Zitat von ryecoaaron

    weak or common root password. Needless exposing the system to the internet. A plugin configured with weak security. Myself, I only expose a non-standard ssh port that only accepts ssh keys and no root login to the internet on most systems. I do have the nginx plugin serving web pages on port 80 but the OMV web interface is on a different port. You really should only expose the needed ports to the internet. All other ports should be blocked.
    As he mentions, he accidentally left the admin password at the default AND had the system exposed (guessing fully exposed) to the internet.

    Okay, I was concerned that some vulnerability had been found in the OMV login page, as I have mine configured for access outside of my network. I would prefer to use a VPN to access it instead, but I need to be able to get the web UI when the VPN server fails, which has happened to me 2 or 3 times.

    Hi


    Check your OMV with the lynis tool (cisofy.com). The tool reports you the actual weakness of your Debian.


    I also full agree with the statement of ryecoaaron. Never expose a unsecured Linux to the internet. Only use SSH through another port (not 22) and with ssh key. Remove root access to SSH logon and never use weak passwords for the root account.


    The only way to secure your System in a acurate way is to place a Firewall (perimeter) facing the internet and use the right NAT and ruleset approach.


    I use for example Juniper and Sophos. In Sophos (which is free to download) is also an IPS, a reverse proxy and captive VPN portal integrated. Really easy to configure and well documented.


    Cheers Josh

    • Offizieller Beitrag
    Zitat von flechoide

    Just one day, it was quite fast .

    To watch all connected nodes, port scanning all of them that frequently (daily?), well, that must create significant network overhead. Since port scans of well known ports are obvious, one would think that ISP's could detect the activity and shut it down. (In a perfect world....)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden