Il linguaggio di programmazione PHP
 

scrittura ******* su wp-content/uploads

Roberto Tagliaferri 19 Dic 2016 09:22
Hola, ho un cliente con wordpress tutto aggiornato (4.7), 2 amministratori
con user non admin ma ogni tanto (spesso) vengono scritti dei ******* .php che
poi vengono utilizzati per inviare phish o spam.
Non utilizzo wp quindi a parte un po' di manutenzione spicciola
(aggiornamenti, backup ed installazione di qualche ******* di controllo,
ithemes secutiry) non riesco ad arginare la cosa: come scrivono dentro la
uploads?
I commenti sono disattivati, la registrazione pure.
Ho letto che è un attacco su scala molto vasta ( https://goo.gl/yiLHIl )
cosa potrei provare?


--
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)tosnet.it
www.robyt.eu
ciccio 20 Dic 2016 10:43
Roberto Tagliaferri <tagliaferri@bofhland.org> ha scritto:

> Hola, ho un cliente con wordpress tutto aggiornato (4.7), 2 amministratori
> con user non admin ma ogni tanto (spesso) vengono scritti dei ******* .php che

> poi vengono utilizzati per inviare phish o spam.
> Non utilizzo wp quindi a parte un po' di manutenzione spicciola
> (aggiornamenti, backup ed installazione di qualche ******* di controllo,
> ithemes secutiry) non riesco ad arginare la cosa: come scrivono dentro la
> uploads?
> I commenti sono disattivati, la registrazione pure.
> Ho letto che è un attacco su scala molto vasta ( https://goo.gl/yiLHIl )
> cosa potrei provare?

il cliente ha i dati di accesso FTP? Quest'ultimo e gli
altri che hanno accesso a wordpress hanno un antivirus decente
e aggiornato, con scansione del loro pc fatta e 0 schifezze trovate?
Roberto Tagliaferri 20 Dic 2016 10:48
ciccio wrote:

> Roberto Tagliaferri <tagliaferri@bofhland.org> ha scritto:
>
>> Hola, ho un cliente con wordpress tutto aggiornato (4.7), 2
>> amministratori con user non admin ma ogni tanto (spesso) vengono scritti
>> dei ******* .php che poi vengono utilizzati per inviare phish o spam.
>> Non utilizzo wp quindi a parte un po' di manutenzione spicciola
>> (aggiornamenti, backup ed installazione di qualche ******* di controllo,
>> ithemes secutiry) non riesco ad arginare la cosa: come scrivono dentro la
>> uploads?
>> I commenti sono disattivati, la registrazione pure.
>> Ho letto che è un attacco su scala molto vasta ( https://goo.gl/yiLHIl )
>> cosa potrei provare?
>
> il cliente ha i dati di accesso FTP? Quest'ultimo e gli
> altri che hanno accesso a wordpress hanno un antivirus decente
> e aggiornato, con scansione del loro pc fatta e 0 schifezze trovate?
Le schifezze sono tutte uploadate tramite http, niente ftp.
Non ho *****izzato troppo la questione ma sono migliaia di accessi verso
xmlrpc.php
Ora ho tolto il permesso di scrittura alla uploads ed è tornato tutto a
posto.

--
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)tosnet.it
www.robyt.eu
Alessandro Pellizzari 20 Dic 2016 12:05
On 20/12/2016 09:48, Roberto Tagliaferri wrote:

> Le schifezze sono tutte uploadate tramite http, niente ftp.
> Non ho *****izzato troppo la questione ma sono migliaia di accessi verso
> xmlrpc.php

Quel ******* serve solo per fare amministrazione remota (tipo con client
standalone invece che web), se ricordo bene.

Qualche anno fa qualcuno consigliava addirittura di cancellarlo, ma non
so se nel frattempo la struttura di WP è cambiata tanto da renderlo
necessario.

Visto che hai tolto i permessi di scrittura in upload, probabilmente
puoi anche provare a rinominare xmlrpc.php e vedere se si rompe
qualcosa, e nel caso ridare i permessi di scrittura ad upload
(altrimenti non potranno più caricare immagini dal backend).

Bye.
Roberto Tagliaferri 20 Dic 2016 15:29
Alessandro Pellizzari wrote:
> Quel ******* serve solo per fare amministrazione remota (tipo con client
> standalone invece che web), se ricordo bene.
>
> Qualche anno fa qualcuno consigliava addirittura di cancellarlo, ma non
> so se nel frattempo la struttura di WP è cambiata tanto da renderlo
> necessario.
>
> Visto che hai tolto i permessi di scrittura in upload, probabilmente
> puoi anche provare a rinominare xmlrpc.php e vedere se si rompe
> qualcosa, e nel caso ridare i permessi di scrittura ad upload
> (altrimenti non potranno più caricare immagini dal backend).
>
grazie, faccio 2 prove. Però che par di palle wordpress. Capisco sia comodo
ma mi sembra un po' colabrodo

> Bye.

--
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)tosnet.it
www.robyt.eu
ciccio 21 Dic 2016 11:29
Roberto Tagliaferri <tagliaferri@bofhland.org> ha scritto:

> Alessandro Pellizzari wrote:
>> Quel ******* serve solo per fare amministrazione remota (tipo con client
>> standalone invece che web), se ricordo bene.
>>
>> Qualche anno fa qualcuno consigliava addirittura di cancellarlo, ma non
>> so se nel frattempo la struttura di WP è cambiata tanto da renderlo
>> necessario.
>>
>> Visto che hai tolto i permessi di scrittura in upload, probabilmente
>> puoi anche provare a rinominare xmlrpc.php e vedere se si rompe
>> qualcosa, e nel caso ridare i permessi di scrittura ad upload
>> (altrimenti non potranno più caricare immagini dal backend).
>>
> grazie, faccio 2 prove. Però che par di palle wordpress. Capisco sia comodo
> ma mi sembra un po' colabrodo

è il rovescio della medaglia: vero che wordpress è facile e comodo,
ma è anche target di attacchi e problemi vari. Per cui bisogna
stargli sempre dietro e spendere tempo in continui aggiornamenti
e controlli vari. Il problema è che i webmastella sbattono
wordpress dovunque vendendolo ad ignari clienti, e poi "dimenticano"
di seguirlo, con conseguenze spesso disastrose...
Roberto Tagliaferri 21 Dic 2016 18:47
ciccio wrote:

> Roberto Tagliaferri <tagliaferri@bofhland.org> ha scritto:

> è il rovescio della medaglia: vero che wordpress è facile e comodo,
> ma è anche target di attacchi e problemi vari. Per cui bisogna
> stargli sempre dietro e spendere tempo in continui aggiornamenti
> e controlli vari. Il problema è che i webmastella sbattono
> wordpress dovunque vendendolo ad ignari clienti, e poi "dimenticano"
> di seguirlo, con conseguenze spesso disastrose...
straquoto. Io faccio tutto a manella e da una parte ci vuole più tempo (e
costo), dall'altra ho sicuramente meno problemi

--
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)tosnet.it
www.robyt.eu
g4b0 22 Dic 2016 09:13
On 21/12/2016 18:47, Roberto Tagliaferri wrote:
> straquoto. Io faccio tutto a manella e da una parte ci vuole più tempo (e
> costo), dall'altra ho sicuramente meno problemi

Non sono daccordo al 100%. Tra Wordpress e fare tutto a mano esiste una
saggia via di mezzo, anzi ne esistono a tonnellate (Laravel, per dirne
una molto di moda ai giorni nostri).

--
g4b0, linux user n. 369000
http://brosulo.net
Enrico Maria Chellini 31 Dic 2016 10:05
g4b0 wrote:

>
> On 21/12/2016 18:47, Roberto Tagliaferri wrote:
>> straquoto. Io faccio tutto a manella e da una parte ci vuole più tempo (e
>> costo), dall'altra ho sicuramente meno problemi
>
> Non sono daccordo al 100%. Tra Wordpress e fare tutto a mano esiste una
> saggia via di mezzo, anzi ne esistono a tonnellate (Laravel, per dirne
> una molto di moda ai giorni nostri).
>
Bisogna stare attenti a non confondere i CMS con i framework.

adesso io non ho mai lavorato su framework, ma credo che il prodotto
finale,
debba essere residente in un server dove c'è il framework stesso per girare.
O sbaglio?

in questo caso devi avere un clouds, o un vps o un server, altrimenti dove
lo fai girare il sito , su un hosting da 50 euro? dove wordpress ci sta
senza problemi.

sbaglio?
Enrico Maria Chellini 31 Dic 2016 10:25
>>
>> il cliente ha i dati di accesso FTP? Quest'ultimo e gli
>> altri che hanno accesso a wordpress hanno un antivirus decente
>> e aggiornato, con scansione del loro pc fatta e 0 schifezze trovate?
> Le schifezze sono tutte uploadate tramite http, niente ftp.
> Non ho *****izzato troppo la questione ma sono migliaia di accessi verso
> xmlrpc.php
> Ora ho tolto il permesso di scrittura alla uploads ed è tornato tutto a
> posto.
>

Ho affrontato questo problema già su linux.sys

allora quello che faccio su i mie script, che non credo riuscirai a fare su
wordpress è cambiare i permessi alla cartella prima di fare l'upgrade del
******* e ricambiarli una volta caricato il ******* .
il proprietario delle cartelle è apache.
#in upload utente lettura e scrittura, gruppo lettura e scrittura
#finito l'upload utente lettura e scrittura, gruppo lettura

pero essendo apache il proprietario tramite un ignection possono comuque
ricambiarti i permessi e ricaricarti i ******* sempre tramite ignection .

wordpress genera le cartelle pertanto il proprietario delle cartelle è
apache.

se le carichi in ftp invece il proprietario è user ftp.

a quel punto, puoi fare fare a php un'azione in ftp, che cambia i permessi
delle cartelle prima e dopo l'upload.
#in upload utente lettura e scrittura, gruppo lettura e scrittura
#finito l'upload utente lettura e scrittura, gruppo lettura

attenzione: devi caricare in un ******* ben protetto login e password ftp per
farle utilizare a php per fare l'operazione.

da apache, non essendo proprietario, non puoi ricambiare i permesis alle
cartelle, quindi cartelle insolo lettura, tranne che non conosci password e
login di ftp

ma con wordpress, non credo riesci a farlo

Comunque , pare anche sia un bag di una verisone di php, devo dire che una
volta aggiornato le ultime verioni di php, non mi è mai ricapitato.

Se qualcuno conosce una best pratic , posti pure.

enrico
Alessandro Pellizzari 31 Dic 2016 17:35
Il Sat, 31 Dec 2016 10:05:45 +0100, Enrico Maria Chellini ha scritto:

> adesso io non ho mai lavorato su framework, ma credo che il prodotto
> finale,
> debba essere residente in un server dove c'è il framework stesso per
> girare.
> O sbaglio?

No. Oggi praticamente tutti i framework si installano tramite composer,
quindi finiscono dentro la cartella vendor/ nel tuo progetto. Basta fare
l'upload di quella e hai il framework.

Certo che, per motivi di sicurezza, è sempre meglio avere la possibilità
di far puntare il virtual-host in una cartella (di solito public/) del
progetto, e non alla root del progetto stesso, e questo non tutti gli
hosting lo permettono.

Bye.
Enrico Maria Chellini 2 Gen 2017 09:15
Alessandro Pellizzari wrote:

> Il Sat, 31 Dec 2016 10:05:45 +0100, Enrico Maria Chellini ha scritto:
>
>> adesso io non ho mai lavorato su framework, ma credo che il prodotto
>> finale,
>> debba essere residente in un server dove c'è il framework stesso per
>> girare.
>> O sbaglio?
>
> No. Oggi praticamente tutti i framework si installano tramite composer,
> quindi finiscono dentro la cartella vendor/ nel tuo progetto. Basta fare
> l'upload di quella e hai il framework.

scusa ma in ogni caso saranno dentro installati come applicazione appunto
dentro la cartella vendor; in somma siamo sicuri che le risorse necessarie
per un framework corrispondano a quelle di un hosting a basso costo?


> Certo che, per motivi di sicurezza, è sempre meglio avere la possibilità
> di far puntare il virtual-host in una cartella (di solito public/) del
> progetto, e non alla root del progetto stesso, e questo non tutti gli
> hosting lo permettono.

problema di sicurezza da non poco.


quindi io la vedo così:

se progetto a basso costo: no framework ma al limite cms

se progetto a costi da me***** a infinito, dipende da:
# il volume del codice che devi scrivere
# livello sicurezza e aggiornamenti

se devo usare un framework è perchè ho da scrivere un grosso volume di
codice, con parti che evito di scrivere e prendo da montare.
perchè per far prima mi voglio ""occupare solo dell'output""

vorrei però che per motivi di sicurezza il framework fosse continuamente
aggiornato con varie patch meglio se allineate a aggiornamenti di sistema.
li vorrei un sistemista che mi cura e mi armonizza tutta la sicurezza.

mio modesto parere

enrico
ciccio 2 Gen 2017 10:56
Enrico Maria Chellini <bitit@bitit.it> ha scritto:

> Alessandro Pellizzari wrote:
>
>> Il Sat, 31 Dec 2016 10:05:45 +0100, Enrico Maria Chellini ha scritto:
>>
>>> adesso io non ho mai lavorato su framework, ma credo che il prodotto
>>> finale,
>>> debba essere residente in un server dove c'Ú il framework stesso per
>>> girare.
>>> O sbaglio?
>>
>> No. Oggi praticamente tutti i framework si installano tramite composer,
>> quindi finiscono dentro la cartella vendor/ nel tuo progetto. Basta fare
>> l'upload di quella e hai il framework.
>
> scusa ma in ogni caso saranno dentro installati come applicazione appunto
> dentro la cartella vendor; in somma siamo sicuri che le risorse necessarie
> per un framework corrispondano a quelle di un hosting a basso costo?
>
>
>> Certo che, per motivi di sicurezza, Ú sempre meglio avere la
possibilità
>> di far puntare il virtual-host in una cartella (di solito public/) del
>> progetto, e non alla root del progetto stesso, e questo non tutti gli
>> hosting lo permettono.
>
> problema di sicurezza da non poco.
>
>
> quindi io la vedo così:
>
> se progetto a basso costo: no framework ma al limite cms
>
> se progetto a costi da me***** a infinito, dipende da:
> # il volume del codice che devi scrivere
> # livello sicurezza e aggiornamenti
>
> se devo usare un framework Ú perchÚ ho da scrivere un grosso volume di
> codice, con parti che evito di scrivere e prendo da montare.
> perchÚ per far prima mi voglio ""occupare solo dell'output""
>
> vorrei però che per motivi di sicurezza il framework fosse continuamente
> aggiornato con varie patch meglio se allineate a aggiornamenti di sistema.
> li vorrei un sistemista che mi cura e mi armonizza tutta la sicurezza.

Allora se ti serve un sistemista, assumi un sistemista.
Semplice, lineare e logico.

;-D

> mio modesto parere

Altrettanto.
Alessandro Pellizzari 2 Gen 2017 11:00
Il Mon, 02 Jan 2017 09:15:44 +0100, Enrico Maria Chellini ha scritto:

> Alessandro Pellizzari wrote:

>> No. Oggi praticamente tutti i framework si installano tramite composer,
>> quindi finiscono dentro la cartella vendor/ nel tuo progetto. Basta
>> fare l'upload di quella e hai il framework.
>
> scusa ma in ogni caso saranno dentro installati come applicazione
> appunto dentro la cartella vendor; in somma siamo sicuri che le risorse
> necessarie per un framework corrispondano a quelle di un hosting a
> basso costo?

Un framework di suo consuma ben poche risorse. Qualche centesimo di
secondo in più ad ogni richiesta.

Alcuni framework occupano parecchio spazio disco (anche 20-30 MB), ma è
comunque enormemente inferiore rispetto a quanto richiesto, per esempio,
da un'installazione di Node.js + Express (200-300 MB)

Naturalmente poi dipende da come lo usi.

Ho visto progetti "tirare dentro" 1 GB di ******* tramite composer, perché
ci avevano infilato anche le fixture per il database per la prima
installazione del software, ma non è il caso normale.

Per mia esperienza, per esempio, Wordpress non si installa(va)
sull'hosting base di register.it, perché superava il numero di query al
minuto sul DB.

>> Certo che, per motivi di sicurezza, è sempre meglio avere la
>> possibilità di far puntare il virtual-host in una cartella (di solito
>> public/) del progetto, e non alla root del progetto stesso, e questo
>> non tutti gli hosting lo permettono.
>
> problema di sicurezza da non poco.

Sarebbe una buona pratica di sicurezza per qualsiasi sito, in PHP come in
qualsiasi altro linguaggio, con o senza framework, che permette, per
esempio, di tenere il ******* di config con le password fuori dal
virtualhost, in modo che sia comunque impossibile da raggiungere anche in
caso di problemi, per esempio con la configurazione di PHP sul webserver.

Sempre prendendo Wordpress: le password di accesso al DB sono in un *******
nella root. Se per qualsiasi motivo (aggiornamento andato male, per
esempio) PHP viene disabilitato, e tu accedi a www.miosito.it/
wp_config.php, puoi vedere le credenziali in chiaro.

Se punti il virtualhost dentro una cartella e lasci le credenziali nella
root, non hai modo di accederci dal webserver.

> quindi io la vedo così:
>
> se progetto a basso costo: no framework ma al limite cms
> ...
> se devo usare un framework è perchè ho da scrivere un grosso volume di
> codice, con parti che evito di scrivere e prendo da montare.
> perchè per far prima mi voglio ""occupare solo dell'output""

Con un CMS dipendi totalmente da quello che il CMS ti permette di fare.
Più il CMS è automatizzato, meno cose puoi fare, anche con i *******
Oppure puoi farle ma a costo di una complessità enorme.

> vorrei però che per motivi di sicurezza il framework fosse continuamente
> aggiornato con varie patch meglio se allineate a aggiornamenti di
> sistema.

Il framework te lo aggiorni tu nel tuo progetto tramite "composer
update", lo testi in locale e, quando funziona, fai l'upload di tutto il
sito (framework compreso).

E, siccome hai fatto tu tutto l'accesso ai dati, sicuramente avrai anche
dei test e dei sistemi per l'upgradel del DB.

Aggiornare un CMS (o anche solo un ******* di un CMS) è una cosa diversa,
e sei completamente nelle mani ******* chi ha scritto il codice. Se ha
modificato il DB senza prevedere uno script di aggiornamento dello
schema, o se magari hai aspettato troppo ad aggiornare e gli script non
supportano l'upgrade dalla tua versione, sei fregato.

La procedura corretta sarebbe fare un clone di tutto il server su un
secondo server (o virtual machine), fare l'upgrade del CMS (o ******* e,
se tutto funziona, fare un backup del server (di nuovo) e poi aggiornare.

Un minimo di una giornata di lavoro per ogni upgrade.

> li vorrei un sistemista che mi cura e mi armonizza tutta la sicurezza.

Per esperienza personale, un sistemista nel 90% dei casi non sa niente
della sicurezza delle applicazioni user-facing, soprattutto dei CMS.

Lui si occupa della sicurezza del S.O. e dei server (Apache, Nginx, al
massimo PHP, ecc.), ma se gli chiedi di tenerti aggiornato Wordpress (o,
peggio, Drupal :P) ti ride in faccia.

O almeno io lo farei (o ti chiederei TANTI soldi) se fossi ancora
SysAdmin.

La figura del DevOps è nata anche per quel motivo: fondere sistemisti
(Op) e sviluppatori (Dev) in modo che l'applicazione sia adattata ai
server e viceversa.

Ma questo raramente funziona coi CMS, perché è difficile adattarli
all'infrstruttura su cui girano, essendo molto orizzontali di loro.


Alla fine è una questione di cosa stai facendo, di quanto vuoi spenderci,
di quanto tempo hai, di quali competenze hai e di quali risorse hai.

È impossibile generalizzare.

Bye.
Enrico Maria Chellini 2 Gen 2017 14:05
> Alla fine è una questione di cosa stai facendo, di quanto vuoi spenderci,
> di quanto tempo hai, di quali competenze hai e di quali risorse hai.
>
> È impossibile generalizzare.


mi sa che ero rimasto un po' indietro a phpzend , mi ha dato de buoni motivi
per ridare un occhiata ai framework.

grazie
enrico

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Il linguaggio di programmazione PHP | Tutti i gruppi | it.comp.www.php | Notizie e discussioni php | Php Mobile | Servizio di consultazione news.