Логи аудита win 2008 R2

[gaiwer]

Заметил сегодня в логах вот такую хрень [spoilerсама хрень]Имя журнала: Security
Подача: Microsoft-Windows-Security-Auditing
Дата: 20.02.2013 7:57:09
Код события: 4625
Категория задачи:Вход в систему
Уровень: Сведения
Ключевые слова:Сбой аудита
Пользователь: Н/Д
Компьютер: server2.shattl.local
Описание:
Учетной записи не удалось выполнить вход в систему.

Субъект:
ИД безопасности: SYSTEM
Имя учетной записи: SERVER2$
Домен учетной записи: SHATTL
Код входа: 0x3e7

Тип входа: 10

Учетная запись, которой не удалось выполнить вход:
ИД безопасности: NULL SID
Имя учетной записи: user
Домен учетной записи: SERVER2

Сведения об ошибке:
Причина ошибки: Неизвестное имя пользователя или неверный пароль.
Состояние: 0xc000006d
Подсостояние: 0xc0000064

Сведения о процессе:
Идентификатор процесса вызывающей стороны: 0x1734
Имя процесса вызывающей стороны: C:\Windows\System32\winlogon.exe

Сведения о сети:
Имя рабочей станции: SERVER2
Сетевой адрес источника: 192.168.0.66
Порт источника: 53444

Сведения о проверке подлинности:
Процесс входа: User32
Пакет проверки подлинности: Negotiate
Промежуточные службы: -
Имя пакета (только NTLM): -
Длина ключа: 0

Данное событие возникает при неудачной попытке входа. Оно регистрируется на компьютере, попытка доступа к которому была выполнена.

Поля "Субъект" указывают на учетную запись локальной системы, запросившую вход. Обычно это служба, например служба "Сервер", или локальный процесс, такой как Winlogon.exe или Services.exe.

В поле "Тип входа" указан тип выполненного входа. Наиболее распространенными являются типы 2 (интерактивный) и 3 (сетевой).

В полях "Сведения о процессе" указано, какая учетная запись и процесс в системе выполнили запрос на вход.

Поля "Сведения о сети" указывают на источник запроса на удаленный вход. Имя рабочей станции доступно не всегда, и в некоторых случаях это поле может оставаться незаполненным.

Поля сведений о проверке подлинности содержат подробные данные о конкретном запросе на вход.
- В поле "Промежуточные службы" указано, какие промежуточные службы участвовали в данном запросе на вход.
- Поле "Имя пакета" указывает на подпротокол, использованный с протоколами NTLM.
- Поле "Длина ключа" содержит длину созданного ключа сеанса. Это поле может иметь значение "0", если ключ сеанса не запрашивался.
Xml события:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
<EventID>4625</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>12544</Task>
<Opcode>0</Opcode>
<Keywords>0x8010000000000000</Keywords>
<TimeCreated SystemTime="2013-02-20T01:57:09.756Z" />
<EventRecordID>73034</EventRecordID>
<Correlation />
<Execution ProcessID="660" ThreadID="7092" />
<Channel>Security</Channel>
<Computer>server2.shattl.local</Computer>
<Security />
</System>
<EventData>
<Data Name="SubjectUserSid">S-1-5-18</Data>
<Data Name="SubjectUserName">SERVER2$</Data>
<Data Name="SubjectDomainName">SHATTL</Data>
<Data Name="SubjectLogonId">0x3e7</Data>
<Data Name="TargetUserSid">S-1-0-0</Data>
<Data Name="TargetUserName">user</Data>
<Data Name="TargetDomainName">SERVER2</Data>
<Data Name="Status">0xc000006d</Data>
<Data Name="FailureReason">%%2313</Data>
<Data Name="SubStatus">0xc0000064</Data>
<Data Name="LogonType">10</Data>
<Data Name="LogonProcessName">User32 </Data>
<Data Name="AuthenticationPackageName">Negotiate</Data>
<Data Name="WorkstationName">SERVER2</Data>
<Data Name="TransmittedServices">-</Data>
<Data Name="LmPackageName">-</Data>
<Data Name="KeyLength">0</Data>
<Data Name="ProcessId">0x1734</Data>
<Data Name="ProcessName">C:\Windows\System32\winlogon.exe</Data>
<Data Name="IpAddress">192.168.0.66</Data>
<Data Name="IpPort">53444</Data>
</EventData>
</Event>[/spoiler]
Это как один из вариантов, и таких логов с вечера штук 200 набежало. Это значит попытка взлома была что-ли? Или вирусня какая то?
192.168.0.66 это ИП прокси сервера. В логах прокси вход был по RDP. Так как многие работают по удаленке, я не могу закрыть RDP доступ. Что можно предпринять в данном случае?

[Infernal Flame]

Что можно предпринять в данном случае?

Самый простой способ - перевесить RDP-сервер на другой порт. Если был тупой перебор, то скорее всего работал бот, а не человек, а они чаще всего нестандартные порты не умеют использовать.

[gaiwer]

А после смены порта нужно всех обзвонить и подсказать как изменить порт при подключении, или можно как то автоматизировать процесс?

[Raven]

Вероятно что все же придется(

[Infernal Flame]

gaiwer
Увы, но автоматизировать процесс смены настроек подключения я вариантов не вижу. Скорее всего придется всем обратившимся подсказывать про две точки и номер порта после них в строке подключения

[Phantom]

Я так понял RDP бежит снаружи через проброс внутрь?
Очень надеюсь, что шлюз собран под unix подобной системой
Ну а что если попробовать автобан таких бомбил ?

Код: Выделить всё

iptables -I FORWARD 1 -t filter -i ppp0 -o eth0 -p tcp -m tcp --dport 3389 -m state --state NEW -m hashlimit --hashlimit-upto 1/hour --hashlimit-burst 6 --hashlimit-mode srcip --hashlimit-name RDP --hashlimit-htable-expire 300000 -j ACCEPT
iptables -I FORWARD 2 -t filter -ippp0 -o eth0 -p tcp -d "IP RDP сервера" --dport 3389 -m state --state NEW -j DROP

За дурачком можно наблюдать в /proc/sys/ip_hashlimit/RDP
Вроде там.
Или немного иначе и без автобана.

Код: Выделить всё

iptables -I FORWARD 1 -t filter -i ppp0 -o eth0 -p tcp --syn --dport 3389 -m recent --name RDP --set
iptables -I FORWARD 2 -t filter -i ppp0 -o eth0 -p tcp --syn --dport 3389 -m recent --name RDP --update --seconds 60 --hitcount 6 -j DROP

Ну и напоследок...OpenVPN наше все. Конечно сложнее но.... Покурить немного манов и форумов и пусть долбят RDP. Долбилка быстрее сломается.
З.Ы Если не помог или напоролся на исключительно windows way уж прошу прощения. Чем мог.