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

Перенаправление портов для самбы

Хорошо, вот настройка:

Интернет -> Модем -> WRT54G -> концентраторы -> рабочие станции winxp и smb сервер linux.

Это в основном домашняя установка распределенного подключения к Интернету, за исключением школы. Мне нужен удаленный доступ за пределами офиса. Я решил, что мне нужно выяснить, какие порты нужно перенаправить, а затем перенаправить их на сервер на маршрутизаторе. В другом вопросе по SF мне сказали, что для нескольких портов потребуется пересылка, и это несколько усложняется. Одна из вещей, которые мне нужно знать, - это то, какие порты требуют пересылки для этого, и какие сложности или уязвимости могут возникнуть в результате. Любая дополнительная информация, которую, по вашему мнению, мне следовало бы получить, прежде чем это делать, будет замечательно. Мне сказали, что SMB не поддерживает шифрование, и это нормально. Учитывая, что я настроил аутентификацию / контроль доступа, все это означает, что как только один из моих пользователей аутентифицируется и начинает загрузку данных, незашифрованный трафик может быть перехвачен и прочитан MITM, верный? При условии это единственная проблема, возникающая из-за отсутствия шифрованияменя это не волнует. Я предполагаю, что это также может означать, что MITM вводит ложные данные в поток данных, например: пользователь запрашивает файл A, MITM перехватывает и заменяет содержимое файла A некоторыми ложными данными. Это тоже не проблема, потому что мои пользователи будут знать, что что-то не так, и вряд ли у кого-то будет стимул делать это в любом случае.

Еще одна вещь, о которой мне сообщили, - это плохая реализация SMB в Microsoft и ее дрянной послужной список в плане безопасности. Применимо ли это, если только клиентская часть - это MS? Мой сервер - Linux.

Вы категорически не хотите этого делать ... по крайней мере, с окнами. порты для пересылки [и samba, и windows]: tcp 135, 139, 445. возможно - но не обязательно 135-139 udp.

часть для доступа к рабочей станции Windows

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

Я предлагаю вам перенаправить только порт 3389 tcp [удаленный рабочий стол] и использовать «совместное использование локальных ресурсов» дисков через подключение к удаленному рабочему столу. этот протокол, кажется, менее уязвим, чем smb / rpc от Microsoft. если возможно, используйте какой-либо другой порт, ограничьте соединения до диапазона IP-адресов доверенного источника и - желательно не делайте этого вообще, используйте, например, vpn openvpn.

часть для доступа к linux box

это другая история - я бы не так боялся эксплуатировать самбу, но все же - данные не будут зашифрованы через дикий Интернет. Я думаю, что действительно vpn завершено на Linux было бы неплохо. если это невозможно - просто смонтируйте общие ресурсы Windows в Linux, сделайте их доступными через scp из Linux, перенаправьте порт 22 на маршрутизаторе - вы можете использовать winscp для доступа к своим файлам, но при этом можете быть спокойны.

В минимум Для доступа к общим ресурсам Windows или Samba по сети необходим порт 139 TCP. Я использовал его для туннелирования соединений Samba через SSH-соединения несколько раз.

SMB не является зашифрованным протоколом, как вы уже выяснили, поэтому я настоятельно рекомендую не открывать его для внешнего мира напрямую, вместо того, чтобы разрешать пользователям подключаться через безопасный туннель, например, предоставляемый SSH или какой-либо другой формой более общего VPN. Я считаю, что используемый метод аутентификации безопасен для выполнения в обычном режиме (это механизм ответа на запрос, который не требует передачи учетных данных в виде простого текста), поэтому, если вы можете гарантировать, что контент в общих папках не является конфиденциальным, вы можете уйти без использования туннеля / VPN, но я бы все равно рекомендовал его как дополнительный уровень безопасности, хотя бы для того, чтобы вы могли контролировать, кто имеет доступ удаленно, отдельно от тех, кто имеет доступ вообще. Также туннель SSH или VPN может поддерживать сжатие, что снизит требования к пропускной способности при удаленном доступе к общим ресурсам.

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

Еще одна серьезная проблема - безопасность пароля пользователя. Если служба открыта и у пользователя ненадежный пароль (либо недостаточно сложный, либо пароль, который может угадать взломщик, и так далее), то у вас серьезная проблема. Поэтому вам нужно убедиться, что у вас есть хорошая политика паролей. Использование VPN, такой как OpenVPN, несколько смягчит это, поскольку людям также потребуется набор ключей для VPN, хотя вы также не можете гарантировать, что пользователь сохранит свой закрытый ключ в безопасности ...

Вам понадобится переадресация портов для 135,137-139 и 445.

У CIFS (и LANMAN и Ко) есть одна общая черта, когда вы публикуете их в Интернете:

Они ждут неприятностей.

  • LANMAN / SMB хеши можно легко сломать в разумные сроки
  • CIFS может по-прежнему подвергнуться атаке, как и любой другой сервис (словарь, брутфорс и т. д.)
  • Одна попытка войти в систему как администратор приведет к передаче хэша администратора, если вы используете LANMAN / SMB.
  • Ничто так не говорит о хакерской любви, как раскрытие службы, которая обеспечивает полный административный доступ к серверам (вместо сужения фокуса доступа).
  • Имея как пароль администратора (из упомянутой передачи / взлома), так и доступ к сервису, который с любовью примет этот пароль: бесценен.

Один из способов перенаправления CIFS и других протоколов - через SSH.

SSH позволяет использовать ключи и зашифрованную аутентификацию, а удобство adhoc-туннелирования TCP гарантирует, что вряд ли потребуется открывать какие-либо порты, кроме SSH (и, возможно, FTP и т. Д.) Через NAT.

Но если вам нужно постоянное SMB-соединение через WAN, лучше инвестировать в инфраструктуру VPN.