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

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 работает так, чтобы вы могли завершить свой набор правил. Если вы работаете на этом хосте удаленно, мое предложение отключит вас, поэтому вам следует делать это только с консоли. Чтобы безопасно работать удаленно, обратитесь к моему коллеге Сообщение Эли Розенкрафта о настройке брандмауэров удаленно.

Стандарт

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

# 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

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

Мои 2 цента:

Что касается HTTP: наличие брандмауэра, прозрачно перенаправляющего трафик порта 80 на прокси / фильтр, - это самый простой способ сделать что-то. Нет необходимости в настройке клиента, + вы можете освободить любой хост / подсеть от использования прокси без необходимости изменения конфигурации клиента. Только так вы можете быть уверены, что все, что должно проходить через прокси, есть.

Любой метод, кроме блокировки всего исходящего трафика HTTPS 443 и разрешения только подмножества сайтов на основе IP, разрешенного для исходящего порта 443, не будет работать должным образом. Защищенный протокол HTTPS разработан (за исключением нескольких недостатков) для предотвращения атак Man-In-The-Middle (прокси-серверы ЯВЛЯЮТСЯ «законными» MITM). Таким образом, HTTPS может делать то, для чего он был разработан. Однако если вы хотите ИГНОРИРОВАТЬ HTTPS, вы должны настроить свой squid на использование DIRECT и не использовать CONNECT (нажатие), но даже если это так, вы все равно можете столкнуться с проблемными веб-сайтами со смешанными частями HTTP / HTTPS. Таким образом, ваш прокси-сервер Squid также будет управлять HTTPS. Это также должно быть отражено в прозрачной части пересылки вашего брандмауэра.

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

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

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

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

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

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

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

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

iptables -P INOUT DROP
iptables -P FORWARD DROP

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