Комментарии 48
Отключение ICMP -очень плохая практика, не надо его отключать ради какой-то выдуманной безопасности. Nmap порты просканирует и без пинга.
Согласен, я тоже не поддерживаю отключение ICMP. Ладно ещё на публично доступных интерфейсах, там это можно как-то оправдать. Ито я бы ещё дважды подумал, какие именно ICMP сообщения отключать, и возможно разрешил бы его для внутренних сетей типа 192.168.0.0/16 и т.д.
А в локальной сети, где обычно находятся Windows-серверва — только усложните себе жизнь при сетевой диагностике, например.
А в локальной сети, где обычно находятся Windows-серверва — только усложните себе жизнь при сетевой диагностике, например.
Нам стоило оговориться, что отключать ICMP стоит именно в публичных сетях.
В локальных, наверное, эта проблема совсем не стоит.
В локальных, наверное, эта проблема совсем не стоит.
Не имеет никакого смысла и в публичных сетях, т. к. не имеет смысла выставлять сервер с Windows напрямую в интернет, ну а нормальный firewall сумеет решить проблему со script kiddie.
Если же мы говорим про VDS/VPS тогда больше смысла в том, чтобы хотя бы спрятать RDP на нестандартный порт не говоря уже о том чтобы за VPN, чем отключать ICMP.
Если же мы говорим про VDS/VPS тогда больше смысла в том, чтобы хотя бы спрятать RDP на нестандартный порт не говоря уже о том чтобы за VPN, чем отключать ICMP.
Рекомендация дана на основе случаев с нашими клиентами. Часто офисы не имеют белых IP адресов, а бухгалтера на аутсорсе, у которых так же нет белых ip адресов, поэтому на серверах удаленных рабочих столов порт RDP открыт для всего интернета.
Если у сервера нет белого адреса, то как же к нему по RDP подключаются? Через NAT провайдера?
И если RDP торчит открытым наружу, то почему рекомендуете закрыть ICMP вместо того, чтобы закрыть/защитить RDP? Для старых версий windows был 2x Secure RDP 4.0 — он затруднял перебор паролей. Возможно еще работает, на новых версиях windows не проверял.
По своему опыту могу сказать от логирования в данном случае мало проку. Журнал безопасности быстро забивается запросами, размер ограничен, работает медленно. А бот задорно продолжает перебор в несколько потоков. И ничего с ним сделать нельзя если нет нормального фаевола и чего-то похожего на fail2ban. Но те у кого это есть уже наверняка позаботились об удаленном доступе через vpn.
И если RDP торчит открытым наружу, то почему рекомендуете закрыть ICMP вместо того, чтобы закрыть/защитить RDP? Для старых версий windows был 2x Secure RDP 4.0 — он затруднял перебор паролей. Возможно еще работает, на новых версиях windows не проверял.
По своему опыту могу сказать от логирования в данном случае мало проку. Журнал безопасности быстро забивается запросами, размер ограничен, работает медленно. А бот задорно продолжает перебор в несколько потоков. И ничего с ним сделать нельзя если нет нормального фаевола и чего-то похожего на fail2ban. Но те у кого это есть уже наверняка позаботились об удаленном доступе через vpn.
офисам надо завести VPN хотя бы, бухгалтерам поставить OpenVPN клиент и авторизацию по сертификату.
безопасность надо строить по слоям модели TCP/IP:
1. RDP это уровень приложения
2. OpenVPN это безопасность на транспортном уровне.
3. Также если известны диапазоны серых ИП-адресов провайдеров, которые используются клиентами, то их тоже надо внести в правила на фаерволе — это будет безопасность на сетевом уровне. Лучше закрыть доступ на несколько обширных диапазонов, чем открывать себя на весь мир
пример с ICMP не понял если честно, никакого профита он не даст, т.к. никакой сервер не должен полностью смотреть в мир однозначно, только принцип наименьших привилегий.
безопасность надо строить по слоям модели TCP/IP:
1. RDP это уровень приложения
2. OpenVPN это безопасность на транспортном уровне.
3. Также если известны диапазоны серых ИП-адресов провайдеров, которые используются клиентами, то их тоже надо внести в правила на фаерволе — это будет безопасность на сетевом уровне. Лучше закрыть доступ на несколько обширных диапазонов, чем открывать себя на весь мир
пример с ICMP не понял если честно, никакого профита он не даст, т.к. никакой сервер не должен полностью смотреть в мир однозначно, только принцип наименьших привилегий.
Есть альтернатива, куда более простая и нативная для Win, однако, более дорогая — RD Gateway. Она как раз и призвана защитить RDP без довешивания VPN.
— 2FA Через Ажур или с прикрученным Duo или еще как (NPS)
— TLS
— 2FA Через Ажур или с прикрученным Duo или еще как (NPS)
— TLS
все равно не стоит полагаться на один софт для защиты, если в RD Gateway будет уязвимость или 0day — то вся защита посыпется.
А плюсы эшелонированной защиты по слоям, что уязвимость в одном слое не приведет к такой сильному падению безопасности — это лучшие практики безопасности которые все вендоры ИБ рекомендуют
А плюсы эшелонированной защиты по слоям, что уязвимость в одном слое не приведет к такой сильному падению безопасности — это лучшие практики безопасности которые все вендоры ИБ рекомендуют
кстати вот буквально пару дней назад вышла новая уязвимость для RD Gateway (CVE-2020-0610) с рейтингом опасности 9.8 из 10. security.berkeley.edu/news/patch-immediately-microsoft-remote-desktop-gateway-remote-code-execution-vulnerability-cve-2020
Вот так и взламывают компании, которые надеются на одну тулзу и не строят эшелонированную безопасность на нескольких независимых уровнях
Вот так и взламывают компании, которые надеются на одну тулзу и не строят эшелонированную безопасность на нескольких независимых уровнях
Для ввода в домен достаточно обычной юзерской учетки, нужно только увеличивать число вводимых машин
Про controlled folder access не знал — надо будет поковырять.
А вот тут я бы не стал такие радикальные заявления делать. Наверно, M$ неспроста его по умолчанию включает, а из соображений совместимости. Лично встречал легаси-системы, которые умели только по SMB1. Поэтому лучше вначале помониторить наличие SMB1-клиентов и, убедившись, что ничего бизнес-критичного на этих клиентах не завязано, отключать устаревший протокол.
А помните Wannacry, который гулял через SMB1? SMB первой версии до сих пор является стандартным компонентом Windows Server и установлен по умолчанию в каждой редакции. Обязательно удалите этот компонент, если он все еще установлен на вашем сервере.
А вот тут я бы не стал такие радикальные заявления делать. Наверно, M$ неспроста его по умолчанию включает, а из соображений совместимости. Лично встречал легаси-системы, которые умели только по SMB1. Поэтому лучше вначале помониторить наличие SMB1-клиентов и, убедившись, что ничего бизнес-критичного на этих клиентах не завязано, отключать устаревший протокол.
Брутфорс RDP, это плохое оправдание отключения ICMP. Я использую шлюз удаленных рабочих столов, для подключения по RDP. Это решает проблему с перебором паролей по RDP. А пинги действительно самый простой способ мониторинга.
В статье, так же не видел рекомендации отключения SMB1. Хотя она много где включена и используется, особенно на старых компьютерах или насах. А раз в 4-5 лет, появляются критические уязвимости в этой службе, которые и приводят к массовым заражениям.
Controlled folder access это больше для пользовательских компьютеров, чем для серверов ИМХО, хотя на сервере терминалов может пригодится.
В статье, так же не видел рекомендации отключения SMB1. Хотя она много где включена и используется, особенно на старых компьютерах или насах. А раз в 4-5 лет, появляются критические уязвимости в этой службе, которые и приводят к массовым заражениям.
Controlled folder access это больше для пользовательских компьютеров, чем для серверов ИМХО, хотя на сервере терминалов может пригодится.
В статье, так же не видел рекомендации отключения SMB1.
3ий пункт статьи же.
К слову, брокер терминальной фермы определяет доступность подконтрольных RDSH-нод с помощью пингов (кому интересно, детали описаны тут). И если неаккуратно запретить на RDSH-нодах пинги, можно положить всю инфраструктуру рабочих столов.
Любой юзер в домене может ввести до 10 компьютеров в домен — добавленный в домен компьютер может быть компьютером атакующего, а когда твой компьютер в домене, то и стараться попасть в домен уже меньше надо.
Поэтому правильнее отключать эту возможность у всех юзеров и не заводить отдельного юзера для добавления компьютеров в домен. А завести группу с ролью добавления компьютеров и включать в неё пользователя только тогда, когда надо ввести компьютер в домен и после добавления компьютера очищать группу. Мало того, стоит изменить OU Computers, используемое по умолчанию для новых компьютеров на другое OU, на которое наложить предварительные групповые политики по безопасности, если существует практика ввода компьютеров с уже установленной Виндой не из эталонного образа.
А ещё лучше, чтобы нельзя было создавать новые объекты типа компьютер, а только добавлять компьютеры с именем по шаблону обновляя уже существующую учётку компьютера.
Поэтому правильнее отключать эту возможность у всех юзеров и не заводить отдельного юзера для добавления компьютеров в домен. А завести группу с ролью добавления компьютеров и включать в неё пользователя только тогда, когда надо ввести компьютер в домен и после добавления компьютера очищать группу. Мало того, стоит изменить OU Computers, используемое по умолчанию для новых компьютеров на другое OU, на которое наложить предварительные групповые политики по безопасности, если существует практика ввода компьютеров с уже установленной Виндой не из эталонного образа.
А ещё лучше, чтобы нельзя было создавать новые объекты типа компьютер, а только добавлять компьютеры с именем по шаблону обновляя уже существующую учётку компьютера.
К Пункту 6. — ну практически везде не согласен — объясняю:
1. (Создайте шлюз – Для управления большой инфраструктурой лучше всего обезопасить себя имея единую точку входа.) — Я даже не представляю — разве существуют вменяемые компании у которых без шлюза стоят виндовые сервера?
2.(Устанавливайте обновления. В особенности, на боевые сервера.) — с поправкой — с опозданием в две недели. Обычно за этот срок уже все проблемы с обновлениями вылазят и понятно что можно ставить а что нет.
3. — согласен.
4. (Используйте Server Core, он имеет наименьшую площадь атаки… ) — абсолютное большинство Виндовых серверов ставится как Домен Контроллер + сервер терминалов или Hyper-V и Домен Контроллер + сервер терминалов, еще чуток под Exchange, SQL-server, про Dynamix и Lynk — молчу — эти звери у нас практически не используются. И работать без оболочки с AD ,Hyper-V, Exchange — ну мягко говоря не удобно. Да и экономии никакой нет.
5. (Сервер удаленных рабочих столов на несколько пользователей – плохая идея...) — Вы серьёзно !? Сервер терминалов это основа безопасной работы пользователей! А тысячи бухгалтеров и менеджеров, которые работают с 1с…
6. + принцип 3-2-1
1. (Создайте шлюз – Для управления большой инфраструктурой лучше всего обезопасить себя имея единую точку входа.) — Я даже не представляю — разве существуют вменяемые компании у которых без шлюза стоят виндовые сервера?
2.(Устанавливайте обновления. В особенности, на боевые сервера.) — с поправкой — с опозданием в две недели. Обычно за этот срок уже все проблемы с обновлениями вылазят и понятно что можно ставить а что нет.
3. — согласен.
4. (Используйте Server Core, он имеет наименьшую площадь атаки… ) — абсолютное большинство Виндовых серверов ставится как Домен Контроллер + сервер терминалов или Hyper-V и Домен Контроллер + сервер терминалов, еще чуток под Exchange, SQL-server, про Dynamix и Lynk — молчу — эти звери у нас практически не используются. И работать без оболочки с AD ,Hyper-V, Exchange — ну мягко говоря не удобно. Да и экономии никакой нет.
5. (Сервер удаленных рабочих столов на несколько пользователей – плохая идея...) — Вы серьёзно !? Сервер терминалов это основа безопасной работы пользователей! А тысячи бухгалтеров и менеджеров, которые работают с 1с…
6. + принцип 3-2-1
По поводу server core — на обычную машину можно установить RSAT и полноценно управлять всеми сервисами.
И работать без оболочки с AD ,Hyper-V, Exchange — ну мягко говоря не удобно. С AD и Hyper-V соглашусь, а вот с Exchange как раз все наоборот. На данный момент на самом Exchange уже давно остался только powershell, а все остальное управление идет через веб
Спасибо за скрипты, сохранил себе. Перепишу их для диагностики удаленных серверов.
В статью стоит добавить какие переменные за что отвечают:
$Last — выводить данные за последние несколько часов
$Attempts — минимальный порог попыток логина
$ShowRDNS=«True» резолвить ли IP адреса атакующего
а еще лучше сделать передачу через параметры
Расскажите про альтернативу терминальному серверу на 50 человек, которым нужен доступ к 1с и корпоративным ресурсам. И чем вам так не нравится один сервер на кучу народа?
В статью стоит добавить какие переменные за что отвечают:
$Last — выводить данные за последние несколько часов
$Attempts — минимальный порог попыток логина
$ShowRDNS=«True» резолвить ли IP адреса атакующего
а еще лучше сделать передачу через параметры
Расскажите про альтернативу терминальному серверу на 50 человек, которым нужен доступ к 1с и корпоративным ресурсам. И чем вам так не нравится один сервер на кучу народа?
Чтобы содержимое диска сервера рабочих столов было зашифровано, достаточно лишь одного пользователя совершившего ошибку.
К сожалению, разговоры о том, что «Мы просто не дадим им права администраторов» могут или, заканчиваются именно тем, что их выдают.
К сожалению, разговоры о том, что «Мы просто не дадим им права администраторов» могут или, заканчиваются именно тем, что их выдают.
К сожалению, разговоры о том, что «Мы просто не дадим им права администраторов» могут или, заканчиваются именно тем, что их выдают.
Простите, это ерунда. В компаниях с нормальным IT абсолютное большинство пользователей администраторских прав даже на своих ноутбуках не имеет, а чтобы получить административные права на сервере, надо, для начала, быть сотрудником IT-отдела, да ещё и получить одобрение заявки на получение соответствующих прав от ответственных лиц.
CItrix?
Nischebrod way — QEMU на Proxmox с отдельными Windows-узлами и поднятием из мастер-диска или PXE. Но накладные расходы огромны. Но степень изоляции выше.
Nischebrod way — QEMU на Proxmox с отдельными Windows-узлами и поднятием из мастер-диска или PXE. Но накладные расходы огромны. Но степень изоляции выше.
Именно об этом и шла речь. Один пользователь — одна виртуальная машина.
Чтобы юзер запустил на терминале шифровальщик, надо чтобы шифровальщик туда попал.
Если это терминалка под 1с — вообще никак. От слова совсем.
Шифровальщик попадает либо с почты, либо с флешек. И то, и другое на терминалах не надо. И сразу все сильно проще.
Ну хоть как заизолируйся — общая папка пользователю все равно доступна для шифрования.
Отдельные виртуалки — сильно оверхед. Проще держать резервные копии (терминал, профили, общие ресурсы), тем более они все равно должны быть.
Время восстановления — до получаса. Запустивший шифровальщика — известен. Для небольшой компании вполне нормально.
Для большой — дак там и админов несколько больше. И на каждое ответственное направление можно выделить как минимум одного. Включая само обнаружение атаки.
Шифровальщик попадает либо с почты, либо с флешек. И то, и другое на терминалах не надо. И сразу все сильно проще.
Это вы просто малость не в курсе. Почитайте, как распространялся WannaCry, например (Пункт «How does WannaCry infect PCs»). Будете неприятно удивлены. Ни флэшек, ни почты в его векторе нет.
На терминале не должно быть сервера smb. На терминале вообще наружу ничего кроме rdp смотреть не должно. А в идеале вообще смотреть через шлюз.
А страшный wannacry я вживую видел, но только в виде отдельных компов и попыток сканировать сеть (собственно попытки сканирования сети в поисках открытых портов smb и выдали заражённых)
а как файлами с терминалом обмениваться? например с отчётами? то, что на терминале не нужно smb это весьма смелое заявление.
smb-сервер на терминале не нужен. smb-сервер должен быть на другой машине, со своими политиками резервного копирования.
таким образом получается схема, где наружу смотрит терминальный сервер, а smb-сервер находится внутри защищенного периметра и вполне доступен с терминального, но недоступен из-вне внутренней сети.
я видел реализации, когда на терминале сразу есть и smb-сервер, и сервер 1с, и сервер sql, и веб-сервер, и контроллер домена (еще и единственный). и резервные копии делаются на отдельный диск в этом сервере. но такое делается либо от небольшого опыта, либо от недостатка финансов, что оправданием не является. и очень редко живет сколько-нибудь долго выставленное в интернет.
Вдумайтесь — зачем вообще вводить в домен компьютер на котором возможно есть вредоносное ПО? Ну и далее по тексту там тоже такое себе.
Придерживайтесь принципа один человек или служба – один сервер.
(Поперхнувшись чаем) Что?!
Сами по себе 32 битные приложения более уязвимые, 64-битные программы не поддаются атаке на переполнение буфера и через них гораздо труднее исполнить код который этими программами не предусмотрен.
Уязвимость программ к атакам переполнение буфера никак не зависит от размера адресного пространства. 64-битные программы точно также уязвимы
Вы серьезно, да?) На кого рассчитана эта статья??
'Сервер удаленных рабочих столов на несколько пользователей – плохая идея. Придерживайтесь принципа один человек или служба – один сервер.'
Ну и про x32/x64 приложения без комментариев.
'Сервер удаленных рабочих столов на несколько пользователей – плохая идея. Придерживайтесь принципа один человек или служба – один сервер.'
Ну и про x32/x64 приложения без комментариев.
> SMB первой версии до сих пор является стандартным компонентом Windows Server и установлен по умолчанию в каждой редакции.
Нет: docs.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows
Нет: docs.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows
Прежде чем что либо утверждать, информация была верифицирована. Были установлены две виртуальные машины на WS 2016 и WS 2019. Компонент был установлен по умолчанию.
В образе WS 2016 еще не было этого фикса, а в образе WS 2019 уязвимость пропатчили.
В образе WS 2016 еще не было этого фикса, а в образе WS 2019 уязвимость пропатчили.
Странно, у себя на 2019 datacenter не увидел, чтобы она была включена по дефолту.
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>
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>
А 1909 проверяли? ;)
Да, на вин2016 и вин2019 компоненты установлены, но по умолчанию отключены политикой.
Придерживайтесь принципа один человек или служба – один сервер.Никаких денег не хватит.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Делаем Windows Server безопаснее