should we allow custom php.ini or turn on ini_set:?
i had to post this because it seems that more and more we receive feed back to the need to close down portions of code, scripts and other hacker enabling software. no longer is hosting simple. it now is a 48 hr job per day due to advances in hacking.
it is amazing that known security holes being locked down delivers all this nonsense about software vs hardware. server side is where it begins. certain php calls are known mine fields. i began oline 1992, with polygon, first hosting 1995 first dedicated 1998 blue rackshack, full ensim then cpanel.
fact is, just because programs can be hacked does not mean you do not try to denie and shut down lockup and shut up.
allowing a custom php.ini is stupid careless and inviting to the wrong people.
while drupal and others continue to produce software requiring hacker enabling code like ini_set.. we are spending 40% gross for security and repair on the server side, cxs cfs modsec and every thing else are only part of the battle.
the physical time is incredible, 1000 server emailsa day!
when we discover a known hole or a known enabler we close it down. period. it effects us also -but better that then a restore...
equating the person who fails to upgrade their kernel to shutting down these functions is a joke art least:
these are no nose likr cut it off..
show_source, system, ini_set, shell_exec, passthru, exec, phpinfo, popen, proc_open, allow_url_fopen
like saying having insurance means you do not have to drive carefully ????
all it takes is one person and one minute hole..
we all have literally tens of thousands of hits from hackers every day. non stop.
here are some of server checks:
Check whether csf is enabled OK
Check csf is running OK
Check whether csf is in TESTING mode OK
Check csf AUTO_UPDATES option OK
Check whether lfd is enabled OK
Check incoming MySQL port OK
Check csf SMTP_BLOCK option OK
Check csf LF_SCRIPT_ALERT option OK
Check csf LF_SSHD option OK
Check csf LF_FTPD option OK
Check csf LF_SMTPAUTH option OK
Check csf LF_POP3D option OK
Check csf LF_IMAPD option OK
Check csf LF_HTACCESS option OK
Check csf LF_MODSEC option OK
Check csf LF_CPANEL option OK
Check csf LF_CPANEL_ALERT option OK
Check csf SYSLOG_CHECK option OK
Check csf FASTSTART option OK
Check csf RESTRICT_UI option OK
Check csf LF_DIRWATCH option OK
Check csf LF_INTEGRITY option OK
Check csf PT_SKIP_HTTP option OK
Check csf PT_ALL_USERS option OK
Server Check Status Comment
Check /tmp permissions OK
Check /tmp ownership OK
Check /var/tmp permissions OK
Check /var/tmp ownership OK
Check /usr/tmp permissions OK
Check /usr/tmp ownership OK
Check for DNS recursion restrictions OK
Check for DNS random query source port OK
Check server runlevel OK
Check nobody cron OK
Check Operating System support OK
Check perl version OK
Check MySQL version OK
Check MySQL LOAD DATA disallows LOCAL OK
Check SUPERUSER accounts OK
Check for cxs OK
Check for IPv6 OK
Check for kernel logger OK
Check for dhclient OK
Check for swap file OK
SSH/Telnet Check Status Comment
Check SSHv1 is disabled OK
Check SSH on non-standard port OK
Check SSH PasswordAuthentication OK
Check SSH UseDNS OK
Check telnet port 23 is not in use OK
Check shell limits OK
Check Background Process Killer OK
Mail Check Status Comment
Check root forwarder OK
Check exim for extended logging (log_selector) OK
Check exim weak SSL/TLS Ciphers (tls_require_ciphers) OK
Check for maildir conversion OK
Apache Check Status Comment
Check apache version OK
Check apache for mod_security OK
Check apache for FrontPage OK
Check Apache weak SSL/TLS Ciphers (SSLCipherSuite) OK
Check apache for TraceEnable OK
Check apache for ServerSignature OK
Check apache for ServerTokens OK
Check apache for FileETag OK
Check mod_userdir protection OK
Check suPHP OK
Check Suexec OK
PHP Check Status Comment
Check php version (/usr/local/bin/php) OK
Check php for enable_dl or disabled dl() OK
Check php for disable_functions OK
Check php for ini_set disabled OK
Check php open_basedir protection OK
WHM Settings Check Status Comment
Check cPanel login is SSL only OK
Check boxtrapper is disabled OK
Check antirelayd is disabled OK
Check max emails per hour is set OK
Check whether users can reset passwords via email OK
Check whether native cPanel SSL is enabled OK
Check compilers OK
Check Anonymous FTP Logins OK
Check Anonymous FTP Uploads OK
Check pure-ftpd weak SSL/TLS Ciphers (TLSCipherSuite) OK
Check FTP Logins with Root Password OK
Check allow remote domains OK
Check block common domains OK
Check allow park domains OK
Check proxy subdomains OK
Check cPAddons update email to owner OK
Check cPAddons update email to root OK
Check cPanel tree OK
Check cPanel updates OK
Check package updates OK
Check security updates OK
Check Accounts that can access a cPanel user account OK
Check cPanel php for register_globals OK
Check cPanel php.ini file for register_globals OK
Check cPanel passwords in email OK
Check core dumps OK
Check Cookie IP Validation OK
Check MD5 passwords with Apache OK
Check Referrer Blank Security OK
Check Referrer Security OK
Check HTTP Authentication OK
Check Parent Security OK
Check Domain Lookup Security OK
Check Password ENV variable OK
Check SMTP Tweak OK
Check nameservers OK
Check AppConfig Required OK
Check AppConfig as root OK
Check AppConfig ACLs OK
Check AppConfig Feature List OK
Check Security Tokens OK
Server Services Check Status Comment
Check server startup for cups OK
Check server startup for xfs OK
Check server startup for nfslock OK
Check server startup for canna OK
Check server startup for FreeWnn OK
Check server startup for cups-config-daemon OK
Check server startup for iiim OK
Check server startup for mDNSResponder OK
Check server startup for nifd OK
Check server startup for rpcidmapd OK
Check server startup for bluetooth OK
Check server startup for anacron OK
Check server startup for gpm OK
Check server startup for saslauthd OK
Check server startup for avahi-daemon OK
Check server startup for avahi-dnsconfd OK
Check server startup for hidd OK
Check server startup for pcscd OK
Check server startup for sbadm OK
Check server startup for xinetd OK
Check server startup for qpidd OK
Check server startup for portreserve OK
Check server startup for rpcbind
then we have server keys
force level 75 passwords
cphulk brute force
and more w/emails to boot..
providing services is no longer easy!
and we still get hacks..
had two oct 13th full server restores each 200 gigs data
then one at softlayer!!!!!!!! our admin account
2 at onlinenic-- they changed our name servers dec 24th 13
and here you are berating those that host and protect you
imagine.. it is you who scream hey turn it back on so some lax individual who does not know a thing about htaccess can setup drupal and custom php.ini and take down a server!
maybe you should be responsible for the cost of a restore!@
man,the list goes on
i tell my peeps move on with our blessings.after all i am protecting the flock.
question should be is cloud the answer to use of ini set? [i would call it cloud-9 if it were better at holding off hackers] and has it experienced heavy production use over a period of time , i do not know..
while i have experience in most phases of server administration, the fact is, it is the programmers whom create the software. i on the other hand must choose what program to utilize based on "revue of use". In a production environment, well utilized software and hardware is the choice. to be honest, i learn from postings and experience. yet i cannot inform anyone why ini_set has security flaws. one must know how they work to negate the problems.
my time is spent keeping the servers up and proper. as it stands fighting hackers consumes 50% of my time and costs. From off site backup, to free and premium scripts, to restores and upgrades.
they hit two servers oct 15
they hit our name service nov 15
they hit sof--yer portal, placed a profile change and it was done!!! even though a ticket for a full profile change on two separate servers anywhere else would have resulted in a call or email before being implemented. they actually changed a 30 character tough pass to "iloveyou#1" pass!.
DEC 24 2013 they hit the name service again. the last time they changed pass and were halted and after gaining access again i went and in ssl changed it to a 30 to 40 mix match character pass
i did not email it and did not store it anywhere but on a thumb drive on my neck ..
yet, again, Dec 24 2013, they not only gained access but switched 60 accounts to new name servers and then hijacked one of our main 12 year old server domains..
took 3 24th/25/26/27th/ days of sending id, pictures, every even email from 2002 to to gain access... 30 tickets! yet hackers had it easy...
note: lucky they were able to reclaim our hijacked domain on the 29th.
we run just about all major programs, and then examine results and logs every 24hr. this is where it hurts. when something is discovered , not implemented, just discovered, we have to search it..... hours and hours!
with chrook rkhunter cxs csf logwatch modsec tripwire, key only shell access with one ip and user, ftpsl encrypted up/down mail scanner w/clamav/ we are no longer free to run a business.
over 60 mod-security/brute force denials per half hour...
while ini-set and drupal [among many scripts] are a must, to allow anything that even squeaks a possibility of danger means shutting it down
i forgot... cloud states app 10,000 servers are in production mode. i would like to see a comparison to other distributions in same amount randomly selected as to down time due to hacking. i read the info, impressed me. each account more or less are in their own container.
sounds great to me. but i would like to know how they compare. from open source software to resistance to server wide hacking
now, i know there must be posts so when i have time i will see.
Changing of the root password is not a solution here.. in cases such as these, hackers upload their own sshd files in some other locations than the default ones and use them to gain access so even if you lock down SSH access to certain ports/IPs, they can login in again.
You have to look for any malicious process running on your server, check out each process carefully to see under whose ownership are they running. You will definitely find something helpful. Rkhunter/Chkrootkit isn't a great help these days so don't rely on its output only.
If you are offering Shared hosting, you should definitely block php functions that are use to execute server side commands. There are ways, where you can have separate php.ini for each domain outside of the clients access but in such a case, you have to manage their php.ini file.
| Server Setup | Security | Optimization | Troubleshooting | Server Migration
| Monthly and Task basis services.
| MSN : madaboutlinux[at]hotmail.com | Skype : madaboutlinux