Qualsiasi sito presente nel WEB deve prima o poi fare in conti con i bot "malevoli" e lo spam se non anche con tentativi di attacco al fine di infettare o compromettere lo stesso sito. L'enorme speculazione che si aggira dietro alle criptovalute dal 2016 ha reso il problema notevolmente preoccupante, anche solo per i continui tentativi di infettare i siti web allo scopo di distribuire a ignari visitatori programmi e script malevoli che hanno lo scopo di minare criptovalute. Il 2017 è stato peggiore del 2016 e il 2018 si riserva di non essere da meno. Da gennaio ho ricevuto diverse richieste d'assistenza e letto molto spesso sui forum di problemi relativi a questo fenomeno, da chi si lamenta di ricevere innumerevoli email in poche ore (esempio), a chi si lamenta di rilevare carrelli anomali e continui.

Anche senza questi campanelli d'allarme una discrepanza marcata tra le statistiche di PrestaShop e Analytics, oppure un tasso di conversione a 0.009 - o un importante decremento dello stesso valore - dovrebbe insospettire.

DIFFERENZE TRA LE STATISTICHE DI PRESTASHOP E ANALYTICS

Perchè i dati delle statistiche di PrestaShop discostano così tanto da quelli di Analytics? È una delle domande che spesso si possono leggere nei forum o possono essere posti dai propri clienti. Dietro a questa domanda si nasconde una delle più grandi piaghe della rete, centinaia di migliaia di computer, server e dispositivi infetti che non fanno altro che tentare qualche attività illecita, dal semplice invio di SPAM all'intrusione nei sistemi informatici allo scopo di rubare dati. Questi "bot" anche quando non riescono ad arrecare nessun danno ai nostri sistemi in quanto li abbiamo resi sufficientemente sicuri (non lo saranno mai in realtà soprattutto dove, come nel caso degli ecommerce, è necessario un compromesso tra funzionalità e sicurezza) sono comunque un problema in quanto sottraggono banda e risorse. Infatti spesso quando ci lamentiamo delle prestazioni del nostro hosting o server dedicato che sia, ci arroventiamo su PageSpeed, Pingdom, GT Metrix e altre utility di analisi, cercando di implementare i consigli senza ottenere reali risultati, nella realtà molte delle risorse e della banda è rubata da tentativi di intrusione e di spam, e in parte dal fenomeno del Hotlinking. Quindi anche quando questo traffco anomalo non crea danni comunque usa risorse e quindi ci procura un danno economico. Più il nostro ecommerce sarà importante e visitato più questo fenomeno diventa un grave problema, talmente grave che spesso si ricorre a servizi a pagamento come CloudFlare, spendere 200 dollari al mese solo per difendersi dal traffico spazzatura non è sostenibile ovviamente per un piccolo commerciante e la piccola impresa, ma a certi livelli diventa obbligatorio. 

Per i CMS Joomla e WordPress è possibile avvalersi in modo molto semplice di Project Honey Pot per il quale stiamo lavorando alla realizzazione di un modulo per la sua integrazione in PrestaShop.

COSA FARE?

PRIMA REGOLA: la prima cosa da fare è una bella scansione di tutti i dispositivi e computer che usiamo per operare sul nostro ecommerce. Tenere presente che "IO USO IL MAC" non è un valido antivirus, quindi dotate ogni vostro dispositivo di una software antivirus e antimalware che protegga da exploit, malware e ransomware. Evitate l'installazione di software pirata, chi lo distribuisce non lo fa senza uno scopo, la maggioranza contiene "piccoli regalini", quindi non è per paura di una visita da parte della BSA, ma per proteggere voi stessi. Molti dei software hanno anche alternative open source molto valide, per esempio LibreOffice e OpenOffice non solo sono un'ottima alternativa a Microsoft Office, ma gestiscono in modo molto più semplice i CSV.

Se i sistemi che usate per gestire l'ecommerce non sono sicuri, è inutile sprecare tempo a implementarne la sicurezza.

SECONDA REGOLA: prima di installare un modulo sul vostro ecommerce in PrestaShop verificatelo, soprattuto se il modulo è rilasciato gratuitamente o proviene da una fonte che non conoscete. Verificare un modulo è molto semplice e potete usare le stesse risorse che PrestaShop mette a disposizione a noi Developer. Quindi registratevi e usate: https://validator.prestashop.com controllate soprattutto la voce Errors e Security. Consiglio comunque di installare sempre il modulo in una copia non di produzione del vostro ecommerce con la modalità DEBUG attiva, è molto utile e indispensabile avere una copia di test del vostro ecommerce. Potete anche tenerla in locale sul vostro PC tramite AMPPS o similari. Consiglio anche di disattivare e disinstallare tutti i moduli non usati.

Fidatevi poco soprattuto di script PHP o moduli che mascherano parte del codice rendendo non leggibile (es. base64_encode).

TERZA REGOLA: indispensabili sono: Google Search Console*, Google Analitycs* (o altro servizio di statistiche) e soprattutto l'accesso in tempo reale ai file di log del vostro dominio. Il vostro ecommerce è il vostro business non lesinate sull'hosting, se non avete accesso in tempo reale ai file di log non avrete nessun modo di trovare l'origine di eventuali attacchi, né di trovare eventuali problemi. Molti servizi di hosting anche blasonati offrono la possibilità di consultare una copia dei log del giorno precedente, meglio di nulla, ma non sufficiente. Nella scelta del servizio controllare sempre che sia presente anche un sistema Anti-DDoS una delle necessità minime di sicurezza.

  • Google Search Console va consultato spesso non aspettate l'arrivo di avvisi.
  • Gogle Analytics dovreste controllarlo giornalmente anche quando non avete campagne attive.
  • File di log del server andrebbero controllati una volta alla settimana o almeno una volta al mese.

*) Consigliamo il nostro modulo Art Webmaster Tools Site Verification and Hreflang per attivare e includere questi servizi.

Cosa controllare: la presenza di errori 500, 502 e 503 possono essere causati anche da un'improvisa impennata del traffico spazzatura. Ecco qui che diventano importanti i file di log del server, in quanto registrano IP di chi ha effettuaro la richiesta della pagina che ha causato l'errore, la possibile causa dell'errore ed eventuali parametri passati nell'URL stesso. Spulciando i file di log troverete pure richieste del tipo: /phpmyadmin/scripts/setup.php, /wp-login.php queste richieste sono tutte effettuate da bot che cercano di sfruttare falle (exploit) conosciute dei sistemi (il più gettonato è WordPress). NOTE: ricordiamoci sempre di rigenerare il file robots.txt appena notiamo del traffico anomalo o riceviamo spam. Per farlo andiamo in: impostazioni > SEO & URLs nel backend del nostro ecommerce in PS.

NOTE: ricordiamoci sempre di rigenerare il file robots.txt appena notiamo del traffico anomalo o riceviamo spam. Per farlo andiamo in: impostazioni > SEO & URLs nel backend del nostro ecommerce in PS.

COSA FARE SE SI RICEVE SPAM?

Vediamo un caso pratico: cominciate a ricevere un bombardamento di email spazzatura, come nazione nelle richieste compare sempre francia.

Proprio in questi casi scopriamo che spendere qualche decina di euro in più può farci risparmiare molto tempo, se il vostro fornitore di hosting vi fornisce l'accesso ai file di log in tempo reale, individuate subito l'origine. Meglio ancora se il vostro servizio vi dà acesso a un pannelo evoluto come Plesk.

Dai file di log cercando appunto /fr/contattaci (parte dell'URL della pagina di richiesta supporto controllate la vostra URL) diviene palese che un bot con IP xxx.xxx.x55.29 e xxx.xxx.x55.29 sta inviando continue richieste di contatto. Possiamo controllare pure da dove arriva realmente l'attacco (sono molti i servizi disponibili nel WEB) per esempio: https://www.tcpiputils.com/

Se siete masochisti e non avete PLESK né altro pannello di controllo del vostro servizio potete scaricare il file di log in locale e usare l’utility glogg per effettuare le ricerche all’interno nello stesso file. Ammetto di aver imparato proprio lottando con risorse insufficienti e in periodi dove ogni singolo MB costava quanto un mese di stipendio, ma se il vostro scopo è fare business in rete con il vostro ecommerce non mi stuferò mai di dirlo: non lesinate, perché ve ne pentirete.

Non rimane che bloccare i due IP per farlo abbiamo varie opzioni usare uno dei tanti moduli disponibili per PrestaShop come "Block Bots / Users based on IP, Country or User-Agent" oppure modificare il file .htaccess operazione questa più complessa, vediamone un esempio:

INSERIAMO DOPO LA RIGA:

# ~~end~~ Do not remove this comment, Prestashop will keep automatically the code outside this comment when .htaccess will be generated again

LE SEGUENTI DIRETTIVE:

SetEnvIf Remote_Addr XXX.XXX.X55.31 bad_user
SetEnvIf Remote_Addr XXX.XXX.X55.29 bad_user
Deny from env=bad_user
ErrorDocument 403 /error403.html

Ovvero l'IP che vogliamo escludere, in questo modo riceverà la pagina di errore 403: accesso negato. Possiamo anche decidere di rendirizzare il traffico altrove. Nel caso Nell'esempio (che comunque è un caso reale) lo SPAM proveniva dal Sud Africa. In alternativa potremo anche scegliere, se non commercializziamo in quello stato e non abbiamo intenzione di farlo in futuro, di bloccare tutto il traffico proveniente da quel paese.

Per esludere un paese dobbiamo usare la sigla internazionale che identifica lo stesso nel caso del Sud Africa è ZA quindi:

SetEnvIf GEOIP_COUNTRY_CODE ZA bad_user
Deny from env=bad_user
ErrorDocument 403 /error403.html

Note: il ban per coutry richiede che sul vostro hosting sia attivo il mod_geoip.

Per mettere tutto al sicuro: una volta bannati gli IP responsabili dello SPAM automaticamente non ne riceverete più. Però è sempre meglio prevenire che curare poichè se il bot cambiasse IP automaticamente il problema si ripresenterebbe, quindi è consigliabile inserire direttamente un reCAPTCHA nel form di contatto di PrestaShop. Anche per questo esiste un ottimo modulo Add Google reCAPTCHA to store forms sviluppato da InnovaDeluxe. È importante aggiornare al versione di PrestaShop, su alcune versioni datate anche l'aggiunta di un filtro reCAPTCHA non risolverà il problema.

Se vi chiedete perché non limitarsi al semplice inserimento del reCAPCHA il motivo è molto semplice. Questi Bot non controllano l'esito dell'invio, quindi il programmino automatico continuerebbe a tentare di inviare lo SPAM consumando risorse perché ad ogni invio il nostro SERVER elaborerà la richiesta. Bannando IP consumeremo dunque meno risorse, lasciandole disponibili per quel traffico di qualità che ci porta conversioni.

NOTE: molto più grave e fastidioso è quando ad essere preso di mira è il modulo "INVIA A UN AMICO" che consiglio di disinstallare completamente, non basta disattivarlo. Una bot che sfrutti questo modulo può portarvi alla sospensione temporanea dell'account di posta che avete configurato in prestashop fino a un ban del IP del vostro server. Quindi se ricevete molti delivery failed nella vostra casella postale che usate per il vostro ecommerce corrette subito ai ripari.

CONCLUSIONI

Se malgrado l'uso di reCAPCHA ricevete ancora delle email di spam e sporattutto se l'attacco ricevuto è stato molto intenso con centinaia di email al giorno, può significarte che a monte del vostro server non vi è nessun filtro Anti-DDoS quindi avete un serio problema di sicurezza. Non è necessario dotarsi di un firewall hw anche se consigliato, ma un sistema Anti-DDoS anche basilare è d'obbligo. Se non siete su un server dedicato, ma su un hosting chiedete al vostro fornitore come attivare il firewall, per esempio OVH permette di attivare il firewall con un semplice click dal pannello di controllo dell'hosting stesso.

Autore: Loris Modena

SENIOR DEVELOPER

Per Ind Loris Modena titolare di Arte e Informatica, inizia a lavorare nel settore informatico nel 1989 quale sistemista addetto alla manutenzione e installazione di sistemi informatici. Inizia a programmare per il web nel 1997 occupandosi di programmazione CGI in PERL e successivamente passando alla programmazione in PHP e JavaScript. In questo periodo si avvicina al mondo Open source e alla gestione di server Linux. 

prodotto aggiunto alla lista