Informiamo tutti i clienti che sulle nuove macchine stiamo installando la nuova versione di apache 2.2.x con il modulo mod_suphp: tale modulo serve per far girare le singole pagine php di un utente specifico con i permessi di quest’ultimo eliminando il fastidioso problema dell’utenza nobody con il quale, fino ad oggi, giravano le pagine degli utenti.

Il modulo risolve, quindi, anche il problema dei permessi sui file: non serve più avere il chmod ad una cartella o ad un file per avere accesso via php a tale filesystem. Ora si dovranno impostare semplicemente i chmod a 755 per le cartelle e a 644 per i files.

Le nuove disposizioni in sicurezza sono state scelte per avere una maggiore protezione sulle macchine in hosting condiviso: per questo siamo giunti alla conclusione di attivare e disattivare alcune funzionalità di php tra cui il register_globals.

Per chi avesse problemi con questa modifica, può contattarci al supporto tecnico. Per tutti coloro che hanno script che non funzionano con questa nuova disposizione,  sicuramente troverà una soluzione alternativa per lo script stesso o comunque può richiedere assistenza al supporto tecnico.

La possibilità per l’utente di creare e gestire i propri cronjobs rappresenta una caratteristica fondamentale del nostro hosting. Permette di poter schedulare l’esecuzione degli script, come ad esempio l’invio di una newsletter o la pulizia di un database.

Il cPanel offre una sezione dedicata alla creazione dei cronjobs, con inserimento facilitato dei dati necessari.Come verifica sull’esecuzione del cronjob, si può impostare l’invio via mail dell’output dello script, così da verificare la presenza di eventuali errori. Un errore cui si può andare incontro è il seguente:

Your Terminal type is unknown!

Enter a terminal type: [vt100]
TERMINAL TYPE IS SET TO vt100

L’errore indicato dipende dal percorso specificato per l’esecuzione del cronjob. Specificando il percorso tramite url, infatti, il cronjob non viene eseguito e va in errore. Per tale motivo, il percorso dello script deve essere indicato tramite path assoluto, ovvero:

Esempio:

• script da eseguire: cronjob.php
• url dello script: http://www.dominio.com/cronjob.php
• path dello script: /home/dominio/public_html/cronjob.php

Nel caso definito dall’esempio, nel cron andrà indicato il path dello script e non la url. In tal modo, l’esecuzione avverrà senza errori e si potrà ricevere il giusto output nella propria casella di posta.

In Joomla 1.5 c’è un problema con il salvataggio di alcune pagine (es. Configurazione sito).

Alcuni utenti hanno riscontrato la restituzione da parte di apache di questo errore:

406 Not Acceptable
An appropriate representation of the requested resource /joomladir/administrator/index.php could not be found on this server.

Il problema è una regola di mod_security “standard” che mette, generalmente, l’installazione base di quest’ultimo pacchetto per apache 2.2.x (easyapache di cPanel utilizza queste regole standard).

Per eliminare il problema, basta commentare la regola:

#SecRule REQUEST_URI|REQUEST_BODY “xmlrpc”

e sostituirla con la seguente:

########################################
#MTS
#XML-RPC generic attack sigs
SecRule REQUEST_HEADERS “^Content-Type\: application/xml” chain
SecRule REQUEST_BODY “(\<.*xml)” chain
SecRule REQUEST_BODY “(echo( |\(|\’).*\;|chr|fwrite|fopen|system|echr|passthru|popen|proc_open|shell_exec|exec|proc_nice|proc_terminate|proc_get_status|proc_close|pfsockopen|leak|apache_child_terminate|posix_kill|posix_mkfifo|posix_setpgid|posix_setsid|posix_setuid|phpinfo)\(.*\)\;” chain
SecRule REQUEST_BODY “methodCall\>”

#Specific XML-RPC attacks on xmlrpc.php
SecRule REQUEST_URI “(xmlrpc|xmlrpc.*)\.php” chain
SecRule REQUEST_BODY “(\<.*xml)” chain
SecRule REQUEST_BODY “(echo( |\(|\’).*\;|chr|fwrite|fopen|system|echr|passthru|popen|proc_open|shell_exec|exec|proc_nice|proc_terminate|proc_get_status|proc_close|pfsockopen|leak|apache_child_terminate|posix_kill|posix_mkfifo|posix_setpgid|posix_setsid|posix_setuid|phpinfo)\(.*\)\;”

#Too generic, unless you know you won’t see this in any of the fields of an XMLRPC message on your system
#SecRule REQUEST_URI “/xmlrpc\.php” chain
#SecRule “(cd|perl |python |rpm |yum |apt-get |emerge |lynx |links |mkdir |elinks |cmd|pwd|wget |id|uname |cvs |svn |(s|r)(cp|sh) |rexec |smbclient |t?ftp |ncftp |curl |telnet |gcc |cc |g\+\+ |\./)”

#XML-RPC SQL injection generic signature
SecRule REQUEST_URI “(xmlrpc|xmlrpc_.*)\.php” chain
SecRule REQUEST_BODY “.*.*.*(select|grant|delete|insert|drop|do|alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9|\*| |,]+[[:space:]](from|into|table|database|index|view).*methodName\>”
##########################################

Molti di voi si saranno chiesti: “Il sistema di statistiche dato da cPanel è ottimo. Ma se volessi dare accesso a queste statistiche a terzi utenti senza dare loro username/password del cPanel?”

Ebbene, si possono trovare diverse soluzioni per ovviare a questo problemi.

Ve ne illustrermo una in particolare.

Scarichiamo questo file ed editiamolo. Cambiamo i parametri:

$user = ‘username’;//your cpanel username
$pass = ‘password’;//your cpanel password
$domain = ‘mydomain.com’;//do not include ‘http://’ or ‘www.’

Uploaddiamo sul server all’interno di public_html dove vogliamo e con qualsiasi nome.
Accediamo, quindi, via web alla pagina appena uploaddata e vedremo le statistiche di AWStats senza accedere a cPanel.
A Sua volta possiamo proteggere il file in una cartella qualsiasi tramite username e password che impostiamo tramite .htaccess oppure dal cPanel nell’aposita sezione.

Tutto lo staff di Serverplan vi da il benvenuto sul nuovo blog dell’azienda.

Tra non molto cominceremo a chidervi la vostra su tutti i servizi che offriamo e pubblicheremo vari HOWTO e guide di carattere tecnico che riguarderà sia i servizi che offriamo, sia linguaggi di programmazione (php/asp/perl/bash/c/c++/…), sistemistica, networking e via così.

Tornateci a trovare presto