Comments 48
Отключение ICMP -очень плохая практика, не надо его отключать ради какой-то выдуманной безопасности. Nmap порты просканирует и без пинга.
А в локальной сети, где обычно находятся Windows-серверва — только усложните себе жизнь при сетевой диагностике, например.
В локальных, наверное, эта проблема совсем не стоит.
Если же мы говорим про VDS/VPS тогда больше смысла в том, чтобы хотя бы спрятать RDP на нестандартный порт не говоря уже о том чтобы за VPN, чем отключать ICMP.
И если RDP торчит открытым наружу, то почему рекомендуете закрыть ICMP вместо того, чтобы закрыть/защитить RDP? Для старых версий windows был 2x Secure RDP 4.0 — он затруднял перебор паролей. Возможно еще работает, на новых версиях windows не проверял.
По своему опыту могу сказать от логирования в данном случае мало проку. Журнал безопасности быстро забивается запросами, размер ограничен, работает медленно. А бот задорно продолжает перебор в несколько потоков. И ничего с ним сделать нельзя если нет нормального фаевола и чего-то похожего на fail2ban. Но те у кого это есть уже наверняка позаботились об удаленном доступе через vpn.
безопасность надо строить по слоям модели TCP/IP:
1. RDP это уровень приложения
2. OpenVPN это безопасность на транспортном уровне.
3. Также если известны диапазоны серых ИП-адресов провайдеров, которые используются клиентами, то их тоже надо внести в правила на фаерволе — это будет безопасность на сетевом уровне. Лучше закрыть доступ на несколько обширных диапазонов, чем открывать себя на весь мир
пример с ICMP не понял если честно, никакого профита он не даст, т.к. никакой сервер не должен полностью смотреть в мир однозначно, только принцип наименьших привилегий.
— 2FA Через Ажур или с прикрученным Duo или еще как (NPS)
— TLS
А плюсы эшелонированной защиты по слоям, что уязвимость в одном слое не приведет к такой сильному падению безопасности — это лучшие практики безопасности которые все вендоры ИБ рекомендуют
Вот так и взламывают компании, которые надеются на одну тулзу и не строят эшелонированную безопасность на нескольких независимых уровнях
А помните Wannacry, который гулял через SMB1? SMB первой версии до сих пор является стандартным компонентом Windows Server и установлен по умолчанию в каждой редакции. Обязательно удалите этот компонент, если он все еще установлен на вашем сервере.
А вот тут я бы не стал такие радикальные заявления делать. Наверно, M$ неспроста его по умолчанию включает, а из соображений совместимости. Лично встречал легаси-системы, которые умели только по SMB1. Поэтому лучше вначале помониторить наличие SMB1-клиентов и, убедившись, что ничего бизнес-критичного на этих клиентах не завязано, отключать устаревший протокол.
В статье, так же не видел рекомендации отключения SMB1. Хотя она много где включена и используется, особенно на старых компьютерах или насах. А раз в 4-5 лет, появляются критические уязвимости в этой службе, которые и приводят к массовым заражениям.
Controlled folder access это больше для пользовательских компьютеров, чем для серверов ИМХО, хотя на сервере терминалов может пригодится.
В статье, так же не видел рекомендации отключения SMB1.
3ий пункт статьи же.
Поэтому правильнее отключать эту возможность у всех юзеров и не заводить отдельного юзера для добавления компьютеров в домен. А завести группу с ролью добавления компьютеров и включать в неё пользователя только тогда, когда надо ввести компьютер в домен и после добавления компьютера очищать группу. Мало того, стоит изменить OU Computers, используемое по умолчанию для новых компьютеров на другое OU, на которое наложить предварительные групповые политики по безопасности, если существует практика ввода компьютеров с уже установленной Виндой не из эталонного образа.
А ещё лучше, чтобы нельзя было создавать новые объекты типа компьютер, а только добавлять компьютеры с именем по шаблону обновляя уже существующую учётку компьютера.
1. (Создайте шлюз – Для управления большой инфраструктурой лучше всего обезопасить себя имея единую точку входа.) — Я даже не представляю — разве существуют вменяемые компании у которых без шлюза стоят виндовые сервера?
2.(Устанавливайте обновления. В особенности, на боевые сервера.) — с поправкой — с опозданием в две недели. Обычно за этот срок уже все проблемы с обновлениями вылазят и понятно что можно ставить а что нет.
3. — согласен.
4. (Используйте Server Core, он имеет наименьшую площадь атаки… ) — абсолютное большинство Виндовых серверов ставится как Домен Контроллер + сервер терминалов или Hyper-V и Домен Контроллер + сервер терминалов, еще чуток под Exchange, SQL-server, про Dynamix и Lynk — молчу — эти звери у нас практически не используются. И работать без оболочки с AD ,Hyper-V, Exchange — ну мягко говоря не удобно. Да и экономии никакой нет.
5. (Сервер удаленных рабочих столов на несколько пользователей – плохая идея...) — Вы серьёзно !? Сервер терминалов это основа безопасной работы пользователей! А тысячи бухгалтеров и менеджеров, которые работают с 1с…
6. + принцип 3-2-1
И работать без оболочки с AD ,Hyper-V, Exchange — ну мягко говоря не удобно. С AD и Hyper-V соглашусь, а вот с Exchange как раз все наоборот. На данный момент на самом Exchange уже давно остался только powershell, а все остальное управление идет через веб
В статью стоит добавить какие переменные за что отвечают:
$Last — выводить данные за последние несколько часов
$Attempts — минимальный порог попыток логина
$ShowRDNS=«True» резолвить ли IP адреса атакующего
а еще лучше сделать передачу через параметры
Расскажите про альтернативу терминальному серверу на 50 человек, которым нужен доступ к 1с и корпоративным ресурсам. И чем вам так не нравится один сервер на кучу народа?
К сожалению, разговоры о том, что «Мы просто не дадим им права администраторов» могут или, заканчиваются именно тем, что их выдают.
К сожалению, разговоры о том, что «Мы просто не дадим им права администраторов» могут или, заканчиваются именно тем, что их выдают.
Простите, это ерунда. В компаниях с нормальным IT абсолютное большинство пользователей администраторских прав даже на своих ноутбуках не имеет, а чтобы получить административные права на сервере, надо, для начала, быть сотрудником IT-отдела, да ещё и получить одобрение заявки на получение соответствующих прав от ответственных лиц.
Nischebrod way — QEMU на Proxmox с отдельными Windows-узлами и поднятием из мастер-диска или PXE. Но накладные расходы огромны. Но степень изоляции выше.
Чтобы юзер запустил на терминале шифровальщик, надо чтобы шифровальщик туда попал.
Если это терминалка под 1с — вообще никак. От слова совсем.
Шифровальщик попадает либо с почты, либо с флешек. И то, и другое на терминалах не надо. И сразу все сильно проще.
Ну хоть как заизолируйся — общая папка пользователю все равно доступна для шифрования.
Отдельные виртуалки — сильно оверхед. Проще держать резервные копии (терминал, профили, общие ресурсы), тем более они все равно должны быть.
Время восстановления — до получаса. Запустивший шифровальщика — известен. Для небольшой компании вполне нормально.
Для большой — дак там и админов несколько больше. И на каждое ответственное направление можно выделить как минимум одного. Включая само обнаружение атаки.
Шифровальщик попадает либо с почты, либо с флешек. И то, и другое на терминалах не надо. И сразу все сильно проще.
Это вы просто малость не в курсе. Почитайте, как распространялся WannaCry, например (Пункт «How does WannaCry infect PCs»). Будете неприятно удивлены. Ни флэшек, ни почты в его векторе нет.
На терминале не должно быть сервера smb. На терминале вообще наружу ничего кроме rdp смотреть не должно. А в идеале вообще смотреть через шлюз.
А страшный wannacry я вживую видел, но только в виде отдельных компов и попыток сканировать сеть (собственно попытки сканирования сети в поисках открытых портов smb и выдали заражённых)
smb-сервер на терминале не нужен. smb-сервер должен быть на другой машине, со своими политиками резервного копирования.
таким образом получается схема, где наружу смотрит терминальный сервер, а smb-сервер находится внутри защищенного периметра и вполне доступен с терминального, но недоступен из-вне внутренней сети.
я видел реализации, когда на терминале сразу есть и smb-сервер, и сервер 1с, и сервер sql, и веб-сервер, и контроллер домена (еще и единственный). и резервные копии делаются на отдельный диск в этом сервере. но такое делается либо от небольшого опыта, либо от недостатка финансов, что оправданием не является. и очень редко живет сколько-нибудь долго выставленное в интернет.
Придерживайтесь принципа один человек или служба – один сервер.
(Поперхнувшись чаем) Что?!
Сами по себе 32 битные приложения более уязвимые, 64-битные программы не поддаются атаке на переполнение буфера и через них гораздо труднее исполнить код который этими программами не предусмотрен.
Уязвимость программ к атакам переполнение буфера никак не зависит от размера адресного пространства. 64-битные программы точно также уязвимы
'Сервер удаленных рабочих столов на несколько пользователей – плохая идея. Придерживайтесь принципа один человек или служба – один сервер.'
Ну и про x32/x64 приложения без комментариев.
Нет: docs.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows
В образе WS 2016 еще не было этого фикса, а в образе WS 2019 уязвимость пропатчили.
PS C:\Windows\system32> Get-WindowsFeature FS-SMB1
Display Name Name Install State
— — — [ ] SMB 1.0/CIFS File Sharing Support FS-SMB1 Available
PS C:\Windows\system32>
Да, на вин2016 и вин2019 компоненты установлены, но по умолчанию отключены политикой.
Придерживайтесь принципа один человек или служба – один сервер.Никаких денег не хватит.
Делаем Windows Server безопаснее