Лично мне нравится устанавливать политики по умолчанию для INPUT и Цепочка FORWARD в DROP

iptables -P INOUT DROP
iptables -P FORWARD DROP

Затем разрешить только тот трафик, который мне нужен - так я нахожу меньше сюрпризов и уверен, что только то, что я разрешаю, идет туда, куда я его направляю.

Если вы не хотите, чтобы ваши клиенты просто обращались к http {s} сайтам без прокси, вы можете просто DROP или REJECT переадресованные пакеты к портам 80 и 443:

IPTABLES -I FORWARD -i eth1 -p tcp -m multiport --dports 80,443 -j REJECT

Где eth1 - ваш внутренний интерфейс. Поступая таким образом, вам не придется возиться с другими портами / доступом.

Каждый раз, когда вы видите, что что-то, что должно работать, не работает, вы должны спросить, есть ли какой-то другой фактор, которого вы не видите. Правило

sudo iptables -A INPUT -p tcp ! --dport 8080 -j REJECT

Похоже, оно должно работать, но вы добавили его в цепочку INPUT, поэтому оно, вероятно, обойдено предыдущим правилом в цепочке. Это правило должно быть адекватным само по себе, поскольку цепочка INPUT - это первая цепочка, в которую попадают входящие пакеты. Если они отклоняются в цепочке INPUT, они никогда не попадают в цепочки FORWARD или OUTPUT. Конечно, это правило заблокирует все TCP, которые не предназначены для порта 8080, что, вероятно, не то, что вам действительно нужно в конце, если только прокси на 8080 не является единственной службой на машине, и вы только регистрируете в консоли.

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

sudo iptables -L

Если ваш брандмауэр использует обратное преобразование NAT, вам также следует указать таблицу NAT.

sudo iptables -L -t nat

После этого попробуйте поместив то же правило в начало цепочки:

sudo iptables -I INPUT -p tcp ! --dport 8080 -j REJECT

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

попробуйте поместить то же правило в начало цепочки:

sudo iptables -I INPUT -p tcp ! --dport 8080 -j REJECT

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

попробуйте поместить то же правило в начало цепочки:

sudo iptables -I INPUT -p tcp ! --dport 8080 -j REJECT

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

так что делать это нужно только с консоли. Для безопасной работы удаленно см. Сообщение моего коллеги Эли Розенкрафта о настройке межсетевых экранов удаленно .

так что делать это нужно только с консоли. Для безопасной работы удаленно см. Сообщение моего коллеги Эли Розенкрафта о настройке межсетевых экранов удаленно .

Сначала прочтите немного документации iptables - в частности, вам нужно хотя бы знать, в какие цепочки, в какие таблицы войдет пакет (см. Здесь: http : //www.iptables.info/en/structure-of-iptables.html ).

Вам придется балансировать между двумя вещами: вашей целью заставить всех использовать прокси-сервер и удобством для всех. С одной стороны, вы можете вообще запретить пересылку любых пакетов (вы даже можете отключить флаг ip_forwarding в ядре). Таким образом, локальные компьютеры будут иметь доступ в Интернет только через ваш прокси-сервер. Но даже это не помешает всем использовать туннельное соединение через ваш http-прокси (а с https это еще проще). Таким образом, вы не сможете полностью контролировать или ограничивать использование Интернета.

С другой стороны, вы можете использовать еще более мягкий подход: просто ограничьте исходящий трафик до порта 80. В этом случае программному обеспечению, которое не использует http (например, Skype), не нужно будет туннелировать трафик в http, а хороший -ведущие клиенты будут иметь все преимущества локального http-кеша (более быстрый доступ к сайтам).

Ваша текущая конфигурация похожа на первый вариант выше. Но у вас есть ненужные правила ACCEPTing в цепочке FORWARD. Вы не хотите, чтобы маршрутизатор пересылал какие-либо пакеты. Локальные компьютеры подключаются к вашему прокси (пакеты проходят через цепочку INPUT), а не к удаленным хостам. При ваших текущих настройках кто-то может найти прокси-сервер, прослушивающий порт 8080 в любом месте в Интернете, и использовать его вместо вашего прокси.

t использовать http (например, skype) не нужно будет туннелировать трафик в http, и клиенты с хорошим поведением будут иметь все преимущества локального http-кеша (более быстрый доступ к сайтам).

Ваша текущая конфигурация выглядит как первый вариант над. Но у вас есть ненужные правила ACCEPTing в цепочке FORWARD. Вы не хотите, чтобы маршрутизатор пересылал какие-либо пакеты. Локальные компьютеры подключаются к вашему прокси (пакеты проходят через цепочку INPUT), а не к удаленным хостам. При ваших текущих настройках кто-то может найти прокси-сервер, прослушивающий порт 8080 в любом месте в Интернете, и использовать его вместо вашего прокси.

t использовать http (например, skype) не нужно будет туннелировать трафик в http, и клиенты с хорошим поведением будут иметь все преимущества локального http-кеша (более быстрый доступ к сайтам).

Ваша текущая конфигурация выглядит как первый вариант над. Но у вас есть ненужные правила ACCEPTing в цепочке FORWARD. Вы не хотите, чтобы маршрутизатор пересылал какие-либо пакеты. Локальные компьютеры подключаются к вашему прокси (пакеты проходят через цепочку INPUT), а не к удаленным хостам. При ваших текущих настройках кто-то может найти прокси-сервер, прослушивающий порт 8080 в любом месте в Интернете, и использовать его вместо вашего прокси.

Но у вас есть ненужные правила ACCEPTing в цепочке FORWARD. Вы не хотите, чтобы маршрутизатор пересылал какие-либо пакеты. Локальные компьютеры подключаются к вашему прокси (пакеты проходят через цепочку INPUT), а не к удаленным хостам. При ваших текущих настройках кто-то может найти прокси-сервер, прослушивающий порт 8080 в любом месте в Интернете, и использовать его вместо вашего прокси.

Но у вас есть ненужные правила ACCEPTing в цепочке FORWARD. Вы не хотите, чтобы маршрутизатор пересылал какие-либо пакеты. Локальные компьютеры подключаются к вашему прокси (пакеты проходят через цепочку INPUT), а не к удаленным хостам. При ваших текущих настройках кто-то может найти прокси-сервер, прослушивающий порт 8080 в любом месте в Интернете, и использовать его вместо вашего прокси.

Стандарт

Отдельная (определяемая пользователем) цепочка может помочь.

# create a chain just for user 100 (192.168.1.100)
iptables -N custom_user_100

# redirect all traffic FROM user 100 to custom chain
iptables -A INPUT -p tcp -s 192.168.1.100 -j custom_user_100

# return from user chain for valid traffic, drop all other
iptables -A custom_user_100 -p tcp --dport 8080 -j RETURN
iptables -A custom_user_100 -j DROP

Итак, это перенаправляет любой трафик из 192.168.1.100 в настраиваемую цепочку. Эта настраиваемая (определяемая пользователем) цепочка просто возвращается, если найдено допустимое совпадение (трафик, предназначенный для порта 8080). Весь другой несоответствующий трафик, который не приводит к возврату из цепочки, отброшен .

Позже вы можете просмотреть статистику таблиц, чтобы убедиться, что именно произошло:

iptables -L -v -n

Пересылка

Теперь, на случай, если вы обрабатываете пересылаемый трафик, будет другой набор правил, но идея использования настраиваемой (определяемой пользователем) цепочки такая же. Мне нравится ссылаться на схему по этой ссылке: http://www.csie.ntu.edu.tw/~b93070/CNL/v4.0/CNLv4.0.files/Page697.htm когда пытаюсь понять поток пакетов.

В этом случае вы можете сделать что-то вроде следующего:

# create a chain just for user 100 (192.168.1.100)
iptables -N custom_user_100

# redirect all traffic FROM user 100 to custom chain
iptables -A FORWARD -p tcp -s 192.168.1.100 -j custom_user_100

# return from user chain for valid traffic, drop all other
iptables -A custom_user_100 -p tcp --dport 8080 -j RETURN
iptables -A custom_user_100 -j DROP

Это идентично первому, за исключением того, что правило, примененное к цепочке INPUT, вместо этого применяется к цепочке FORWARD.

Обновить 2013-05-24

Я перечитал ваш вопрос. Итак, начнем сначала.

Предположим, ваш «прокси» на самом деле является маршрутизатором. То есть - он передает все пакеты от одного интерфейса к другому - возможно, с использованием NAT. Это означает, что все интересующие пакеты проходят через цепочку FORWARD.

Далее: вы говорите, что настроите всех клиентов, использующих порт 8080, для обращения к самому прокси. Хорошо. Это означает, что все эти пакеты войдут в «прокси» через цепочку INPUT.

Итак: вы просто хотите запретить кому-либо выходить из порта 8080 в цепочке FORWARD.

iptables -A FORWARD -p tcp --dport 8080 -j REJECT

Это правило гарантирует, что все, что должно быть перенаправлено на порт назначения 8080, будет отклонено (ICMP-пакет будет отправлен клиенту, который попытался передать пакет через прокси).

После того, как вы реализуете это Правило ВАЖНО, если вы протестируете это, попытавшись установить такое запрещенное соединение, - затем вы перечислите правила, набрав:

iptables -L -v -n |grep 8080

и убедитесь, что счетчик увеличился. В противном случае что-то не так с конфигурацией маршрутизатора.