This website is deprecated, and remains online only for historic access to old issues and docs for historic versions of Virtualmin. It has been unmaintained for several years, and should not be relied on for up-to-date information. Please visit www.virtualmin.com instead.
I have read trough all posts and what I can see is that we never can be sure that a server is not compromised... in other words, to be 100% sure is to wipe the disks and start from scratch! I'm thinking of doing that since we got a backup server, but can we be sure that a new install will be clean. This is a massive work load to do this but to be honest, I would sleep better after all work is done, knowing that the "not knowing for sure" no longer is an issue... Or do you think this is the wrong path to take!
Only if you know your Server now has also lack of some newer en more modern cyphers , tls protocols and so more.
Then please check out with what apps / software and devices your Customers work and connect.
If possible installing new box then together with more and stricter security and so on makes more sense then only looking for this thing.
The Job if now on older such specs, must be done once in near future , so you spare that time and research to in one new clean install.
The Basic virtualmin webmin installation you have to change and update some.
in stead of 1024 / 2048 bit you could have new more future proof 4096 and so on.
Check you box with these sites for upto date protocols and more modern future proof settings:
The box that i'm thinking of reinstalling is a brand new hi end dedicated server, raid, and all possible security, IPMI for remote control as the server is in a secure data center 1000km from me. The box is fresh installed 4 month ago with the best possible security, r1soft backup twice a day, only "real" certificates, not LE certs... and dedicated IP's for every customer! I have been working on this box some time now to have it fine tuned and tightly secured... so it's not that fun to wipe it! But... i'm no a linux guy and for me to try to find what has (maybe) been compromised... no I don't think so! ;) For 15 years I have used and trusted Virtualmin Pro to be my GUI to linux, and they have done the job excellently!!! And I still trust and also will continue to use Virtualmin.
It's a tough situation and one I'd hate to give the wrong advice about. Is it possible for you to hire a Linux security guru to give it the once-over?
In my own case, I did run all the usual rootkit finders and the like, and they turned up nothing of concern. But all of the sites on the server in question are my own. Also, the timing and the fact that I never had password change enabled make it unlikely that it was affected, anyway. So I'm not 100 percent sure, but I'm 99 percent -- and all the data is mine and backed up. I'm not taking chances with other people's stuff.
Your situation is more difficult. Reformatting and starting over would cause a lot of work for you and at least some inconvenience for your clients, but not as much as a compromised server would. And tools like rkhunter do require a certain amount of interpretation. So it's a difficult decision.
The only advice I feel comfortable giving is to consider hiring a security guru to check out the server. You can never be 100 percent sure that a server is clean: but that's true even if you reinstalled it this morning. So if you can find someone who's willing to say they're 99 percent sure, maybe that's the best you can hope for.
The worrying part for me is that the malicious code was around about 3 month before the "password" setting had to be in a specific state, those 3 month before that the code didn't need the "password" setting, the code worked anyway. And another thing is that almost all our customers is government/state, so I can't settle for 99% if I can get 100%,
OK fair,
We have some work and scanning todo.
I'm only pointing out some knows from date 10-08-2019 and some 12-08-2019 that is probably why scam scans started before the 17-08-2019. ( on one of ours 14-08-2019)
So and also then for everyone if you look for .... on your boxes take in mind those dates to.
The first time an entry occurred in my webmin log was in January of 2018 on /session_login.cgi.
The next attempt was in July 2018, then 3 times in August of 2018.
After that nothing until August 2019 when there were many attempts on /password_change.cgi
Hi Joe, and others. Thanks for this update. I was on holiday in cyprus using google discover app on my phone and it was around 3 or 4 entries about this. as I was without laptop my hair grown in seconds :) now its all sorted on my end. I would like to thank you guys for very quick action. You are great!
Configuring/troubleshooting Debian servers is always great fun
Hi Joe,
I have read trough all posts and what I can see is that we never can be sure that a server is not compromised... in other words, to be 100% sure is to wipe the disks and start from scratch! I'm thinking of doing that since we got a backup server, but can we be sure that a new install will be clean. This is a massive work load to do this but to be honest, I would sleep better after all work is done, knowing that the "not knowing for sure" no longer is an issue... Or do you think this is the wrong path to take!
Best regards, Leffe
Hi Leffe, I don't know what todo for you.
Only if you know your Server now has also lack of some newer en more modern cyphers , tls protocols and so more. Then please check out with what apps / software and devices your Customers work and connect.
If possible installing new box then together with more and stricter security and so on makes more sense then only looking for this thing. The Job if now on older such specs, must be done once in near future , so you spare that time and research to in one new clean install.
The Basic virtualmin webmin installation you have to change and update some. in stead of 1024 / 2048 bit you could have new more future proof 4096 and so on.
Check you box with these sites for upto date protocols and more modern future proof settings:
https://discovery.cryptosense.com/
https://en.internet.nl/
and some more if you know, good luck. Also scan ofcourse DATA before backup and restore with some scanners.
But still i think only if you have such scam scans before this webmin update here, and the password function ... then yup for better sleep maybe.
Anyway good luck ;)
in some country tls 1.0 and 1.1 to be privacy proof you have to disable those 2
Thanks Jfro,
The box that i'm thinking of reinstalling is a brand new hi end dedicated server, raid, and all possible security, IPMI for remote control as the server is in a secure data center 1000km from me. The box is fresh installed 4 month ago with the best possible security, r1soft backup twice a day, only "real" certificates, not LE certs... and dedicated IP's for every customer! I have been working on this box some time now to have it fine tuned and tightly secured... so it's not that fun to wipe it! But... i'm no a linux guy and for me to try to find what has (maybe) been compromised... no I don't think so! ;) For 15 years I have used and trusted Virtualmin Pro to be my GUI to linux, and they have done the job excellently!!! And I still trust and also will continue to use Virtualmin.
Regards, Leffe
It's a tough situation and one I'd hate to give the wrong advice about. Is it possible for you to hire a Linux security guru to give it the once-over?
In my own case, I did run all the usual rootkit finders and the like, and they turned up nothing of concern. But all of the sites on the server in question are my own. Also, the timing and the fact that I never had password change enabled make it unlikely that it was affected, anyway. So I'm not 100 percent sure, but I'm 99 percent -- and all the data is mine and backed up. I'm not taking chances with other people's stuff.
Your situation is more difficult. Reformatting and starting over would cause a lot of work for you and at least some inconvenience for your clients, but not as much as a compromised server would. And tools like rkhunter do require a certain amount of interpretation. So it's a difficult decision.
The only advice I feel comfortable giving is to consider hiring a security guru to check out the server. You can never be 100 percent sure that a server is clean: but that's true even if you reinstalled it this morning. So if you can find someone who's willing to say they're 99 percent sure, maybe that's the best you can hope for.
--Richard
Thanks Richard,
The worrying part for me is that the malicious code was around about 3 month before the "password" setting had to be in a specific state, those 3 month before that the code didn't need the "password" setting, the code worked anyway. And another thing is that almost all our customers is government/state, so I can't settle for 99% if I can get 100%,
Best regards, Leffe
OK fair, We have some work and scanning todo. I'm only pointing out some knows from date 10-08-2019 and some 12-08-2019 that is probably why scam scans started before the 17-08-2019. ( on one of ours 14-08-2019)
So and also then for everyone if you look for .... on your boxes take in mind those dates to.
Succes you all.
The first time an entry occurred in my webmin log was in January of 2018 on /session_login.cgi. The next attempt was in July 2018, then 3 times in August of 2018. After that nothing until August 2019 when there were many attempts on /password_change.cgi
IP addresses involved:
52.119.118.14 89.248.171.57 188.166.105.121 51.38.184.92 85.214.205.222 92.63.192.239 95.154.243.4 45.76.66.122 51.158.68.1 192.3.70.143
There were no attempts in my usermin log
Hi Joe, and others. Thanks for this update. I was on holiday in cyprus using google discover app on my phone and it was around 3 or 4 entries about this. as I was without laptop my hair grown in seconds :) now its all sorted on my end. I would like to thank you guys for very quick action. You are great!
Configuring/troubleshooting Debian servers is always great fun
I was only able to search logs up to year old (from today), with an upper limit of Nov 23rd, 2018 (I update frequently).
I found 0 instances of
password_change.cgi
. Luckily I was only vulnerable during 1.89Pages