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

Можно ли использовать iptables NAT с внешней стороны?

Не могли бы вы коротко взглянуть на эту простую iptables / NAT-Setup, я считаю, что она имеет довольно серьезную проблему безопасности (из-за того, что она слишком проста).

В этой сети есть одна подключенная к Интернету машина (под управлением Debian Squeeze / 2.6.32-5 с iptables 1.4.8), действующая как NAT / шлюз для нескольких клиентов в 192.168 / 24.

У машины две NIC:

eth0: internet-faced
eth1: LAN-faced, 192.168.0.1, the default GW for 192.168/24

Таблица маршрутизации - по умолчанию с двумя сетевыми адаптерами без ручных изменений:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
(externalNet)   0.0.0.0         255.255.252.0   U     0      0        0 eth0
0.0.0.0         (externalGW)    0.0.0.0         UG    0      0        0 eth0

Затем включается NAT. только и просто этими действиями больше нет правил iptables:

echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# (all iptables policies are ACCEPT)

Это работает, но я упускаю здесь несколько вещей, которые, как мне кажется, могут быть проблемой безопасности:

  1. нет никаких ограничений относительно разрешенные исходные интерфейсы или исходные сети вообще

  2. нет такой части брандмауэра, как:

    (установите политики на DROP)
    / sbin / iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED, ESTABLISHED -j ACCEPT
    / sbin / iptables -A ВПЕРЕД -i eth1 -o eth0 -j ПРИНЯТЬ

Итак, вопросы о моих бессонных ночах, а первый для меня важнее:

  1. Доступен ли этот NAT-сервис всем в той же подсети ISP, который устанавливает этот компьютер в качестве своего шлюза по умолчанию?
    Я бы сказал, что да, потому что нет ничего, указывающего на то, что входящее внешнее соединение (через eth0) должно обрабатываться иначе, чем входящее внутреннее соединение (через eth1), пока выходной интерфейс - eth0 - и с точки зрения маршрутизации это верно как для внешних, так и для внутренних клиентов, которым нужен доступ в Интернет. Так что если я прав, любой может использовать эту машину как открытый прокси с помощью NAT его пакетов здесь. Так что скажите, пожалуйста, правильно ли это или почему нет.
    В качестве «исправления» я добавил параметр «-s 192.168.0.0/24» к команде запуска NAT. Я хотел бы знать, действительно ли неиспользование этой опции было проблемой безопасности или просто неуместным благодаря некоторому механизму, о котором я не знаю.

  2. Поскольку все политики ПРИНЯТЫ, в настоящее время нет ограничений на пересылку eth1 на eth0 (от внутреннего к внешнему). Но каковы эффективные последствия отсутствия в настоящее время ограничения, согласно которому только состояния RELATED и ESTABLISHED пересылаются с eth0 на eth1 (от внешнего к внутреннему)?
    Другими словами, следует ли мне изменить политику на DROP и применить два упомянутых выше правила «брандмауэра», или их отсутствие не влияет на безопасность?

Спасибо за разъяснение!

1) короткий ответ «весь мир» - нет, люди во внешней сети, да.

Вы можете установить шлюз только в вашей текущей локальной сети, поэтому любой из externalNet может установить ваш ящик в качестве шлюза и даже получить доступ к машинам за ним (например, он может получить доступ 192.168.0.2 за NAT - пакеты будут перенаправлены, но возвращаемые пакеты будут NAT externalNet-ip, который ему придется переводить снова - и это выполнимо).

Правило "-s" устранит проблему с прокси, но вы также должны заблокировать все пакеты, приходящие на eth0 с участием 192.168.0.0/24 как пункт назначения.

2) Это зависит от обстоятельств. Если вы доверяете клиентам, находящимся за NAT, и не хотите иметь никаких ограничений, тогда все в порядке. Если вы хотите заблокировать / разрешить только определенные службы, вы должны заблокировать их (например, разрешить только целевые tcp-порты 80,443 и tcp / udp-порт 53 и т. Д. И заблокировать все остальное).

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

  1. Да, однако, машина должна находиться в той же подсети, что и вы на стороне провайдера. Но в этом случае злоумышленник может просто подделать свои исходные IP-адреса как ваши или использовать вместо этого нераспределенный адрес. Однако, поскольку ваши правила написаны, внешний злоумышленник может просматривать вашу локальную сеть, однако ему придется справиться с тем фактом, что ваш сервер может маскировать пакеты на обратном пути. Таким образом, вы должны отбрасывать пакеты, идущие на 192.168.0 / 16 от eth0, используя iptables (нет, использовать политику маршрутизации здесь слишком поздно).

  2. Пересылка недопустимых пакетов может привести к утечке частных адресов в Интернете или к тому, что непереведенные пакеты достигнут хостов. MASQUERADE может отказаться маскировать / демаскировать недопустимые пакеты, или эти недопустимые пакеты могут даже не попасть в таблицу nat. Как правило, рекомендуется, по крайней мере, отбрасывать пакеты в состоянии INVALID. Затем принимайте только пакеты от eth0 в состоянии ESTABLISHED или RELATED. Я не думаю, что это может иметь какие-либо проблемы с безопасностью, если хосты в вашей локальной сети ведут себя правильно, но я бы все равно сделал это.

Если я правильно понимаю, предполагая, что вы должны были ввести эти предложенные правила, это должно облегчить ваше беспокойство.

У вас есть политика по умолчанию, чтобы отбрасывать все, что попадает в цепочку INPUT или FORWARD.

Затем вы разрешаете пересылку только СВЯЗАННЫХ, УСТАНОВЛЕННЫХ пакетов, которые поступают на ваш внешний интерфейс и уходят через ваш внутренний интерфейс.

Таким образом, единственный способ пересылки НОВЫХ пакетов подпадают под последнее правило: будут пересылаться только те пакеты, которые входят через ваш внутренний интерфейс и уходят через внешний интерфейс.

Таким образом, даже если хост во внешней сети попытался использовать ваш хост в качестве шлюза, НОВЫЙ пакет придет на eth0, попадет в цепочку пересылки и затем будет сброшен, потому что он не удовлетворяет никакому правилу.

1) Ага. Часть Ethernet ISP - MAC-адрес используется для транспорта шлюза.

2) Я бы рекомендовал взглянуть на конфигурацию по умолчанию в дистрибутивах RedHat / Fedora / CentOS, они знают, что и зачем они это делают: https://fedoraproject.org/wiki/How_to_edit_iptables_rules?rd=User_talk:Rforlot

Кстати: НЕ ИСПОЛЬЗУЙТЕ REJECT С ПЕРЕДНЕЙ ЦЕПОЧКОЙ http://bugs.centos.org/view.php?id=5636