Comments 32
На каких дистрибутивах Линукса запустится такой сервер?
И на каких версия Windows будет работать клиент?
Мы выпустили для него сертификат, открыли наружу 443/UDP и одной командой включили SMB over QUIC. В тот же вечер пользователи филиала просто открыли в Проводнике
\\
files.company.com
\common
и... всё заработало. Без VPN, без обрывов, с нормальной скоростью.
А могли давным давно просто сделать WebDAV и всего-то
Сервер запустится на дистрибутивах Linux со свежим ядром и Samba 4.23 или новее. В первую очередь это Arch, openSUSE и последние версии Fedora.
Клиент будет работать на Windows 11 и Windows Server 2025. Поддержки в Windows 10 нет.
Извините, а можно уточнить ?
Если у меня выделенный адрес на микротик, далее мне какие шаги предпринять ? Приобрести портов, но не пойму как это взаимодействовать с именем, вместо адреса
И сразу вопросы:
а с безопасностью что? иногда ж smb в VPN суют из-за того что дырки находятся переодически
как это в России работает, с учетом что QUIC в России часто работает....своебразно
Это надёжно. Весь SMB-трафик, включая аутентификацию, полностью шифруется туннелем TLS 1.3. Атакующий извне не видит сам протокол SMB, чтобы его атаковать. Дополнительно можно включить проверку клиентских сертификатов, что защитит от кражи пароля.
В России нужно обязательно тестировать. Из-за особенностей работы провайдеров и систем фильтрации (ТСПУ), QUIC может работать нестабильно, со снижением скорости или обрывами. Перед внедрением проведите пилот на сотрудниках с разными интернет-провайдерами.
Спасибо не надо!
Самба - боль, как в части безопасности, с регулярными уязвимостями.
Чем вас sftp не устроило?
на виндовом ФС + 22 порт открыть в интернет? для ИБ будет прям праздник.
SFTP неудобен для рядовых пользователей, так как требует отдельного клиента (вроде FileZilla) и ручного скачивания/загрузки файлов.
SMB работает прозрачно как обычный сетевой диск в «Проводнике», позволяя редактировать файлы прямо на сервере. При этом SMB over QUIC решает исторические проблемы безопасности, шифруя весь трафик в туннеле TLS 1.3.
Tls решает только проблему чтения и/или модификации трафика посторонними. От дыр в smb он не защищает, а их за всë время столько было, что smb уже никто не доверяет. Потому и прячут за VPN.
Упомянута возможность проверять клиентские сертификаты, но как это включить, настроить и проверить - не увидел. Хотя это наверное самое важное с точки зрения безопасности.
Вы абсолютно правы, TLS сам по себе не лечит уязвимости в коде Samba или Windows. Его задача — защитить канал.
Ключевое отличие SMB over QUIC в том, что атакующий не может добраться до уязвимого кода SMB до аутентификации. Весь процесс, включая согласование диалектов и аутентификацию (самые опасные фазы в старых атаках), происходит внутри уже установленного туннеля TLS 1.3. Внешний сканер не видит SMB-сервер — он видит только зашифрованный UDP-поток. Это принципиально снижает поверхность атаки по сравнению с открытым портом 445/TCP.
Вот краткая инструкция для Windows Server (все команды в PowerShell):
# 1. Требуем от клиентов предъявлять сертификат
Set-SmbServerCertificateMapping -Name files.company.com -RequireClientAuthentication $true
# 2. Разрешаем доступ конкретному клиенту по SHA256-хешу его сертификата
Grant-SmbClientAccessToServer -Name files.company.com -IdentifierType SHA256 -Identifier "хеш_сертификата"
# 3. Включаем аудит, чтобы видеть в логах, кто и как подключается
Set-SmbServerConfiguration -AuditClientCertificateAccess $true
Вот ВООБЩЕ не проблема! Не скажу за windows, но в любом Линуксе sftp монтируется как обычная папка, более того можно сделать так что пользователь даже знать не будет что эта папка сетевая и висит где то в сети....она выглядеть будет как самая обычная папка. Думаю в windows плюс-минус тоже самое можно реализовать.....через GPO монтировать сетевой диск вроде он такое умеет....но неточно, могу ошибаться, в windows я неочень
В Windows более менее штатными средствами можно webdav...но как же он гемморойный (ну или не все его умеют готовить). Как sftp смонтировать на windows...я вот способа без допсофта не знаю.
Если решение в статье позволит без проблем выставлять SMB в интернет без рисков безопасности и оно еще и работать будет нормально хотя бы в пределах страны - это очень хорошо.
Я не поленился и посмотрел можно ли примонтировать сетевой диск при использовании sftp в Windows...и да....можно....Конечно придется софт установить, но для пользователя это будет как обычная сетевая папка (/или сетевой диск)....так что не самбой единой. Более того я только в очередной раз убедился что самбу использовать нежелательно, когда существуют в природе "нормальные" протоколы.
И дааа....sftp я лишь для примера привел в комментарии выше, он просто попался "под руку"....а есть еще более красивый протокол ssh, по которому так же можно гонять файлы, короче было бы желание разобраться...
SFTP итак поверх ssh работает, можно конечно пробросить любой порт через ssh, но это отнюдь не элегантно и удобно. Да и по скорости уступает samba и прочим...
Вообще то по скорости оно сопоставимо, вы наверное не разобрались и в однопоточном режиме использовали sftp и без ускорения aes шифрования которое во всех современных процессорах есть.
Что-то не понял, а при чем протокол и скорость? Корреляции не наблюдаю...нули и еденицы что так летят, что эдак летят...это немного разные уровни модели ISO/OSI; вы попутали красное с кислым....ну или пушистое с мягким...
Штатных средств для WebDAV в Windows скоро не будет. Фича деприкейтед и скоро будет выпилена, если ещё не...
А между линуксами можно 10гбит развить? Какая скорость будет если с шары на линуксе копировать в Винду?
У меня он был. Маленький офис, где интернет-провайдер наглухо блокировал всё, кроме 80/443 портов. О VPN речи не шло — «дорого, сложно, а у нас тут три бухгалтера».
Ну т.е. SSTP не захотели разворачивать Вы, а виноват офис?
Исторически Samba и Windows шли рука об руку
Эээээ.... что?!
https://www.samba.org/samba/PFIF/
ТОже не понял:
"VPN речи не шло — «дорого, сложно, а у нас тут три бухгалтера»."
Почему дорого? Почему сложно? Да и не важно сколько там юзверей сидит, да хоть один - поднять тоннель дело 20 минут с перекурами.
Только хотел написать что статья для админов типа next next next и есть SSTP, вы меня опередили.
ну sstp это ещё тот тормоз -) , но для маленького офиса вполне годно... и таки да, пролезает практически везду, что является весомым плюсом.
Я бы не стал называть это VPN-less. Да, безопасное соединение. Но не очень понятно с безопасностью подключения к таким серверам из Internet.
В случае VPN будет два уровня защиты - как средствами самой VPN, так и средствами сервера внутри сети после "прохода" по VPN. И, скорее всего, в этом случае будет использоваться внутренняя корпоративная зона DNS, которая не видна снаружи, а также внутренняя подсеть, опять же снаружи не маршрутизируемая.
В описанном в статье случае этот сервер должен иметь легальный IP-адрес с легальным DNS-именем. То есть его нужно ставить либо напрямую с доступом в Internet, либо, хотя бы в DMZ. То есть он будет доступен для возможных атак напрямую только с одним уровнем защиты - самого сервера. Да, в принципе перед ним тоже можно поставить внешний Firewall, но сам факт выноса такого сервера из внутренней сети во внешнюю вызывает дополнительные опасения в безопасности.
P. S. И я понимаю, что это решение красиво смотрится с точки зрения идеологии Azure.
В статье упоминается соединение с терминальным сервером в центральном офисе по RDP в отсутствие VPN. Как у Вас реализована защита этого подключения?
Если порт 443 на стороне сервера уже занят, можно ли SMB over QUIC повесить на другой порт? Не в смысле DNAT на роутере, а на самом Windows Server 2025? И на клиенте можно ли использовать порт для подключения к серверу?
интересная статья, спасибо. Но пока есть возможность использовать ipsec, стоит его использовать. Раз настроил и забыл. Скорость (если железо позволяет), надёжность, стабильность. Если бы полупокеры не дергали рубильники, то вообще проблем бы не было...
SMB over QUIC на всех платформах: «VPN-less» файловые шары в 2025 (Windows Server 2025 + Samba 4.23)