LINUX.ORG.RU
решено Форум — Admin  

Как заблокировать выход с локальной сети, через OpenVPN сервер, на OpenVPN клиента.

 , , ,


0

1

Доброго времени суток. Бьюсь уже достаточно долго, пробовал много вариантов, но не один не дает результата.

Водные данные - Есть локальная сеть офиса. В локальной сети офиса есть два RDP сервера. Есть шлюз (CentOS), через него офис выходит в интернет. На шлюзе работает OpenVPN сервер Есть удаленные сотрудники (другой город), которые подключаясь к VPN сети могут видеть локальную сеть офиса (разграничение кому что можно видеть работает). Офисная сеть видит всех OpenVPN клиентов подключенных к серверу.

Задача - Выборочно запретить выход с офисной сети на VPN клиентов.

Буквально - Маша (в другом городе), заходит через VPN на RDP сервер №1 офисной сети. По умолчанию, она может видеть свой компьютер по IP назначенному VPN сервером. Но нужно сделать так, чтобы с RDP сервера №1 она не могла видеть свой локальные компьютер. Но с офисного RDP сервера №2 - могла.

Вопрос как можно решить задачу и вообще реально ли? Варианты конфига iptables которые я пробовал результата не приносят.



Последнее исправление: starget (всего исправлений: 1)

Ответ на: комментарий от ziemin

Неn, каждый VPN клиент получает свои настройки с сервера OpenVPN. и у VPN своя подсеть. VPN - 192.168.11.0/24 Офиса - 192.168.1.0/24

starget
() автор топика

реально ли?

да

Варианты конфига iptables которые я пробовал результата не приносят.

[src ip], [dst ip] -j DROP

andrew667 ★★★★★
()
Ответ на: комментарий от andrew667 
iptables -A PREROUTING -s $LANR -d $VPNR -j DROP
iptables -A INPUT -s $LANR -d $VPNR -j DROP
iptables -A OUTPUT -s $LANR -d $VPNR -j DROP

такие варианты не катят. Могу выложить конфиги.

starget
() автор топика

делайте маскарадинг и related,established для клиентов при при dst = ip rdp сервера #1, тогда подключиться к нему они сможут, а вот от него обратно - нет. (обратной трансляции не будет)

zgen ★★★★★
()
Ответ на: комментарий от zgen

Она подключается спокойно, но мне нужно чтобы с одного из терминальных серверов она не могла увидеть свой компьютер (пинговать или зайти на «шару»), с которого она, через OpenVPN, подключается к данному серверу.

starget
() автор топика
Ответ на: комментарий от starget

спасибо, я понял с первого раза. Перечитайте еще раз ВНИМАТЕЛЬНО моё сообщение. И еще раз, если не дойдет со второго.

zgen ★★★★★
()
Ответ на: комментарий от zgen 

echo "1" > /proc/sys/net/ipv4/ip_forward
modprobe ip_conntrack ip_nat_ftp ip_conntrack_ftp

export WAN=eth0
export LAN=eth1
export VPN=tun0

export WANIP=192.168.33.250		# сеть перед модемом
export LANIP=192.168.1.1		# сеть офиса
export VPNIP=192.168.11.1		# сеть OpenVPN

export LANR=192.168.1.0/24		# Локальная подсеть 
export WANR=192.168.33.0/24		# Локальная подсеть 
export VPNR=192.168.11.0/24		# OpenVPN подсеть


#############################

iptables -F
iptables -X
iptables -t nat -F
iptables -t mangle -F

iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP

iptables -A INPUT -i $WAN -s $LANR -j DROP					# Пакеты с поддельными IP-адресами, приходящие eth0 будут отбрасываться

iptables -A INPUT -i lo -j ACCEPT						# разрешаем все входящие на lo
iptables -A INPUT -i $LAN -j ACCEPT						# разрешаем все входящие на LAN
iptables -A INPUT -i $VPN -j ACCEPT						# разрешаем все входящие на VPN

iptables -A INPUT -m conntrack --ctstate NEW -p tcp ! --syn -j DROP		# Защита от попытки открыть входящее соединение TCP не через SYN

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT		# Принимать все пакеты, которые инициированы из уже установленного
										# соединения, и имеющим признак ESTABLISHED. Состояние ESTABLISHED
										# говорит о том, что это не первый пакет в соединении.

iptables -A INPUT -i $WAN -p tcp --dport 1221 -j ACCEPT				# SSH
iptables -A INPUT -i $WAN -p tcp --dport 80 -j ACCEPT				# HTTP
iptables -A INPUT -i $WAN -p udp --dport 5000 -j ACCEPT				# OpenVPN

iptables -A INPUT -p udp -i $WAN -m multiport --dports 137,138 -j ACCEPT	# SAMBA
iptables -A INPUT -p tcp -i $WAN -m multiport --dports 139,445 -j ACCEPT	# SAMBA

iptables -A INPUT -p icmp -f -j DROP 						# Закрываемся от кривого icmp
iptables -A INPUT -i $WAN -p icmp --icmp-type 0 -j ACCEPT			# PING (эхо запрос - эхо ответ)
iptables -A INPUT -i $WAN -p icmp --icmp-type 8 -j ACCEPT			# PING (эхо запрос - эхо ответ)

iptables -A INPUT -i $VPN -p tcp --dport 3128 -j DROP				# Запрещаем доступ к прокси серверу с VPN сети

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT		


# ===========================================================================================================================
#					Интернет шлюз

iptables -t nat -A POSTROUTING -o $WAN -j MASQUERADE				# Подменяем адрес внутреннего отправителя на внешней сети.
iptables -A FORWARD -s $LANR -j ACCEPT						# Выход в интернет через NAT





#Разрешаем доступ с всего VPN на всю внутреннию сеть. 
iptables -A FORWARD -i $VPN -s $VPNR -d $LANR -j ACCEPT




service iptables save
service iptables restart
starget
() автор топика
Ответ на: комментарий от ziemin

Если поместить в самое начало вот это: 

iptables -A INPUT -s 192.168.1.10 -d 192.168.11.0/24 -j DROP
То сам VPN сервер по его VPN адресу (192.168.11.1) я не вижу - не пингуется, а вот клиенты VPN сети спокойно.

Получается, что управление пакетами уходит где-то в самом начале.

starget
() автор топика
Ответ на: комментарий от zgen

Вы правы. Если убрать маскарадинг вообще и сделать только как вы написала - все работает как надо, за исключением выхода в интернет для остальных компьютеров офиса.

Все пакеты «затыкаются» на шлюзе. Сейчас подумаю как их пропихнуть дальше.

starget
() автор топика
Ответ на: комментарий от zgen

После чего она к RDP серверу не подключится.

Подключится. Это смотря где правила применять. А маскарад тут нафиг не надо, когда вся сетка комании на роутинге. На кой черт заходить на терминальный сервер, чтобы попасть на свой комп...ТС нагородил ненужный огород.

andrew667 ★★★★★
()
Ответ на: комментарий от starget

такие варианты не катят. Могу выложить конфиги

Дроп на RDP1 или компьютере пользователся или транзитном узле (шлюзе) очень даже катит. Ты схему нарисуй, таблицы маршуртизации распиши, и правила для FW.

Выборочно запретить выход с офисной сети на VPN клиентов.

никаких проблем зная ip-адреса vpn клиентов и офисных компов

andrew667 ★★★★★
()
Ответ на: комментарий от andrew667

Зачем? Да банально, чтобы не было возможности списать на свой ПК что-либо, файл, базу данных и т.д. Вариантов применения масса.

starget
() автор топика
Ответ на: комментарий от andrew667

Конфиг фаервола я выше выложил.

Фаерфолом со стороны клиента рубит конечно на 100%. Но суть проблемы в том, чтобы управлять политикой с одного места.

Если исходить из [src ip], [dst ip] -j DROP, то правило 

 iptables -A INPUT -s 192.168.1.10 -d 192.168.11.41 -J DROP
не работает, не зависимо от места расположения строчки.

192.168.1.10 - сервер терминалов; 192.168.11.1 - tun0 адаптер сервера; 192.168.11.41 - VPN адрес клиента.

starget
() автор топика

Задачу решил. Ранее ошибался с расположением запрещающего правила.

Нужно было ставить вот так:

iptables -t nat -A POSTROUTING -o $WAN -j MASQUERADE
iptables -A FORWARD -s 192.168.1.0/24 -d 192.168.11.41 -j DROP
iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT

Где 192.168.11.41 VPN клиент, которого не должны видеть с локальной сети 192.168.1.0/24.

Если сначала ставить разрешающие правило, то пакет на себя забирает служба OpenVPN и далее iptables его уже не видят.

Всем спасибо кто откликнулся.

starget
() автор топика
Ответ на: комментарий от anton_jugatsu

Это с другого двора. Смотрите задачу в топике.

starget
() автор топика
Ответ на: комментарий от pianolender

Конечно. Задачей топика было запретить возможность видеть с офисной сети клиентов VPN, не более того. Все что идет через RDP сессию можно резать политикой на самом сервере.

Задача комплектного урезания возможности «выноса» информации с сервера это совершенно другая история со своими страшилками.

starget
() автор топика
Ответ на: комментарий от starget

Зачем? Да банально, чтобы не было возможности списать на свой ПК что-либо, файл, базу данных и т.д.

У тебя все дома или ты прикидываешься? Почитай про такое слово TELEWORKER, и как грамотно реализуется такое, а то у тебя как-то наполовину сделано. Сетку внутреннюю настрой сначала, или у тебя обычные сотрудники со своего компа ходят по RDP на сервер, и на нем работают? Слив данных делается элементарно через транзитный узел, который общедоступен для рабочего и временного компа через, например Интернет.

andrew667 ★★★★★
()
Ответ на: комментарий от andrew667

Умник да? Открою секрет, если кому-то нужно вынести информацию - он ее внесет. И ему до попы будут твоя настроенная сетка и сертификаты Циски и другая «лобуда». Если человек имеет доступ к информации то он уже ее владеет, хоть карандашом перепишет на листик, хоть просто с рабочего места «перефотографирует» монитор с нужной ему информацией или просто запомнит :)

Вопросы безопасности данных решаются в комплексе, начиная с юридического закрепления коммерческой тайны и ответственности за ее распространение или вынос, технической защитой данных (превысил лимит запросов - сообщение в отдел безопасности), кончая грамотно построенной работы отдела безопасности.

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

Первое, перед тем как «блеснуть» умом, растопырить пальцы и обзывать всех недалекими, полезно узнать область где будет реализовано это решения и почему так эффективнее, чем строит огороды.

Второе, конфиг с тестового полигона, а не с рабочей среды.

Третье, научись давать грамотные советы. «[src ip], [dst ip] -j DROP» абсолютно верно, но без это как автомат без патронов - просто палка. Но если бы ты написал, что если пакет попадает с сервис OpenVPN, то iptales'ом ты ему уже ничего не сделаешь, так как далее управление на себя забрала служба это был бы более ценный совет. А грамотный специалист, который хочет помочь, а не «блеснуть умом», но в тоже время не давать «все на блюдечке» - порекомендовал бы проверить tcpdump'om маршрут движения пакета.

Четвертое, за «[src ip], [dst ip] -j DROP» спасибо.

ИМХО

starget
() автор топика
Ответ на: комментарий от starget

Хорошо сказал. Правило по-умолчанию должно быть DROP.

ziemin ★★
()
Ответ на: комментарий от starget

написал, что если пакет попадает с сервис OpenVPN, то iptales'ом ты ему уже ничего не сделаешь, так как далее управление на себя забрала служба это был бы более ценный совет

Ты написал бред. Осиль порядок обработки пакетов. OpenVPN вообще к этому отношения не имеет.

порекомендовал бы проверить tcpdump'om маршрут движения пакета

Маршрут движения пакета дампом не проверяют.

Третье, научись давать грамотные советы. «[src ip], [dst ip] -j DROP» абсолютно верно, но без это как автомат без патронов - просто палка.

Ты ж бил себя в грудь, и писал, что где бы не написал правила - не работает.

P.S. Ничего, и к остальному придешь.

andrew667 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin