Yeah we've stopped allowing users to enter passwords and get emailed about it etc too. Was too risky.
HOW-TO: Protect from recent SolusVM exploits.
- Thread starter KuJoe
- Start date
turfhosting
New Member
Great idea. Thanks for sharing.
Not sure what you're getting at about MT. In case it wasn't clear, Mersenne Twister is a fast RNG intended for stuff like statistical simulations, not security. For stuff like passwords, it's better to use the urandom device.
http://php.net/manual/en/function.openssl-random-pseudo-bytes.php is an alternative interface, more or less.
Looking at some of these exploits I think PHP should be ditched entirely for these purposes.
Last edited by a moderator:
Shados
Professional Snake Miner
I'm one of those people who tends to think PHP should be ditched entirely for all purposes. It wasn't built as a programming language, or even a scripting language - it was built as a thin wrapper tool around a set of C libraries - and it's only ever really been added on to in an increasingly hacky manner ever since.
Not php though, but the coders. Having said that, do prefer Java server side.
Shados
Professional Snake Miner
Yeah, sure, it's possible to write good code in most languages, even the bad ones, if you are a good coder. However, environment influences behaviour & cognition, and we programmers are a lazy bunch, so one will tend to use whatever solutions are simplest/easiest/most obvious/best fit the language you are working in. When that language is PHP, the solutions tend to be fairly shite. In other words, the majority of programmers who just aren't /that/ good will tend to write bad code when using a bad language.
DaringHost
New Member
I didn't see it listed in this thread, but you can also shut down lighttpd:
Last edited by a moderator:
Tux
DigitialOcean? lel
Python master race
You would need to make sure all of your staff have SSH access to turn it back on when needed though, or manually control the VPS's.
chown -R nobody.nobody /usr/local/solusvm/www
Will prevent write access to public directory and eliminate dangerous RFIs and good part of RCEs. If the attacker has no ability to upload his scripts to the master, it will make his job much much harder.
Run PHPIDS in font of Solus, or nginx reverse proxy + naxsi. It will block common web attacks such as SQL injectioins etc. Sure, this can still be bypassed if you use default rules but nothing is 100% secure these days.
Will prevent write access to public directory and eliminate dangerous RFIs and good part of RCEs. If the attacker has no ability to upload his scripts to the master, it will make his job much much harder.
Run PHPIDS in font of Solus, or nginx reverse proxy + naxsi. It will block common web attacks such as SQL injectioins etc. Sure, this can still be bypassed if you use default rules but nothing is 100% secure these days.
Doing that will break WHMCS automation and prevent staff from accessing SolusVM.
What exactly would break WHMcs automation? Because I tested this setup and it worked like a charm. Solus does not need to write to /www in normal conditions besides update, but you chown back to solusvm.solusvm during the update process.
You would use WHMcs to connect directly to Solus, clients would be proxied via nginx reverse proxy + naxsi. Only nginx proxy, WHMcs and staff IPs would be whitelisted on the Solus master.
User graphs.
PHPIDS does NOT prevent SQL Injections or XSS, it simply allows YOU the ability to detect and protect against it.
