Назад | Перейти на главную страницу

Windows Server 2003 W3SVC Failing, возможно, причина атаки грубой силы

На этой неделе мой сайт дважды пропадал без видимой причины. Я зашел на свой сервер (Windows Server 2003 Service Pack 2) и перезапустил службу World Web Publishing, веб-сайт все еще не работал. Я попытался перезапустить несколько других сервисов, таких как DNS и Cold Fusion, но сайт все еще не работал.

В конце концов я перезапустил сервер, и сайт снова появился.

Прошлой ночью сайт снова отключился. На этот раз я вошел в систему и посмотрел журнал событий.

СТРАШНАЯ ВЕЩЬ!

Таких было сотни:

Event Type: Information
Event Source:   TermService
Event Category: None
Event ID:   1012
Date:       30/01/2012
Time:       15:25:12
User:       N/A
Computer:   SERVER51338
Description:
Remote session from client name a exceeded the maximum allowed failed logon attempts. The session was forcibly terminated.

С частотой около 3-5 минут. Примерно в то время, когда мой веб-сайт умер, был один из них:

Event Type: Information
Event Source:   W3SVC
Event Category: None
Event ID:   1074
Date:       30/01/2012
Time:       19:36:14
User:       N/A
Computer:   SERVER51338
Description:
A worker process with process id of '6308' serving application pool 'DefaultAppPool' has requested a recycle because the worker process reached its allowed processing time limit.  

Это, очевидно, и убило веб-службу.

Таких тогда было несколько:

Event Type: Error
Event Source:   TermDD
Event Category: None
Event ID:   50
Date:       30/01/2012
Time:       20:32:51
User:       N/A
Computer:   SERVER51338
Description:
The RDP protocol component "DATA ENCRYPTION" detected an error in the protocol stream and has disconnected the client.

Data:
0000: 00 00 04 00 02 00 52 00   ......R.
0008: 00 00 00 00 32 00 0a c0   ....2..À
0010: 00 00 00 00 32 00 0a c0   ....2..À
0018: 00 00 00 00 00 00 00 00   ........
0020: 00 00 00 00 00 00 00 00   ........
0028: 92 01 00 00               ...    

Без ошибок первого типа.

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

Я не знаю, почему эта атака грубой силой привела к остановке веб-службы, и я не знаю, почему перезапуск службы не устранил проблему.

Что мне делать, чтобы убедиться, что мой сервер в безопасности, и что мне делать, чтобы веб-сервер больше не выходил из строя?

Спасибо.

Возможно, но относитесь к ним как к симптомам и убедитесь, что теория соответствует.

Событие утилизации - это просто сообщение «Пул приложений достиг предела в 1740 минут». Это означает, что ваш веб-сайт работал в течение 29 часов (при условии, что у него есть настройки утилизации по умолчанию), а затем сработал лимит времени утилизации.

При повторном использовании по умолчанию начинается новый процесс до того, как завершится старый. Это означает, что любое прерывание в обслуживании минимально (в зависимости от того, сколько времени требуется для инициализации вашего нового процесса), но оно не отсутствует.

Но это действительно очень сложно связать с какой-либо грубой силой RDP, не так ли? Есть что-то большее, чем корреляция событий?

Первое, что я хотел бы сделать, это изменить порт RDP по умолчанию, не использовать порт 3389 по умолчанию. Если сервер подключен к Интернету напрямую или через переадресацию портов, вы никогда не должны использовать порт RDP по умолчанию. Это просто напрашивается на неприятности. Изменение порта не сделает вас более защищенным - по крайней мере, технически - но предотвратит его обнаружение множеством червей / сканеров и т. Д.

Проверьте журнал событий безопасности, предполагая, что он не был изменен, и посмотрите, были ли успешные входы в систему через RDP. Это будет событие 528 с типом входа 10. Если был успешный вход в систему кем-то другим, а не вами, вы должны предположить, что сервер был скомпрометирован. Вероятно, целью вторжения будет установка вредоносного ПО на ваш веб-сервер. Если он скомпрометирован, вам придется либо переустановить, либо провести очень тщательную оценку, чтобы найти какой-либо корневой комплект, троян и т. Д.

Я бы также оценил журналы IIS, чтобы увидеть, откуда пришли атаки, и заблокировал бы этот IP-адрес на вашем брандмауэре, если он у вас есть. Есть устройства, которые всегда блокируют сомнительные диапазоны IP-адресов, что, очевидно, является лучшим подходом.

Наконец, я рекомендую установить продукт для мониторинга журнала событий. Мы создаем продукт под названием EventSentry, который отслеживает журналы событий в реальном времени. У нас есть бесплатная версия для сообщества под названием EventSentry Light, которая, по крайней мере, может предупреждать вас по электронной почте, когда генерируются обнаруженные вами события. Таким образом, вы можете либо выполнить автоматическое действие, либо предпринять немедленные действия.

Удачи.

Увеличьте ведение журнала IIS на сайтах. Вы должны уловить некоторую информацию.