~~~~~

Question

Я хочу провести открытоеТормаршрутизатор.

Моя политика выхода будет схожа сСокращенная политика выхода.

Но я также хочу, чтобы сети Tor было сложнее злоупотреблять моими ресурсами.

Случаи, которые я хочу запретить клиентам делать через Tor:

• Нагрузка на один сайт очень большим количеством пакетов.
• Агрессивное сетевое сканирование целых блоков IP-адресов

Случаи, которые я НЕ хочу запрещать клиентам делать через Tor:

• загрузка нескольких сотен файлов изображений в облако
• раздача торрента

Мой вопрос: возможно ли это вообще сделать и как?

Первой моей мыслью был какой-нибудь брандмауэр (Linux/iptables или *BSD/ipfw/pf), но он, вероятно, будет бесполезен из-за внутренних свойств маршрутизатора Onion.

Ведутся ли какие-либо текущие разработки команды torproject по этой теме?

Я также прошу дать общие рекомендации по обеспечению безопасности выходных узлов Tor.

Обновление (сентябрь 2012 г.)

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

Лучшее, что вы можете сделать, чтобы помешать людям злоупотреблять выходным узлом для участия в DDOS-атаках, — это обнаружить очень частые пакеты, направляемые на один IP-адрес.

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

Обновление (декабрь 2014 г.)

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

Чтобы избежать отключения сервиса, мне пришлось использовать следующий набор iptablesправил ( ONEWэто цепочка для исходящих пакетов TCP SYN (они же NEW):

Я не уверен, что этого будет достаточно, но вот:

-A ONEW -o lo -j ACCEPT
-A ONEW -p udp --dport 53 -m limit --limit 2/sec --limit-burst 5 -j ACCEPT
-A ONEW -m hashlimit --hashlimit-upto 1/second --hashlimit-mode dstip --hashlimit-dstmask 24 --hashlimit-name ONEW -j ACCEPT
-A ONEW -m limit --limit 1/sec -j LOG --log-prefix "REJECTED: "
-A ONEW -j REJECT --reject-with icmp-admin-prohibited

Answer 1

Имейте в виду, что:

• Клиенты Tor переключают виртуальные каналы каждые 10 минут или около того, насколько я понимаю. Это означает, что исходный IP-адрес меняется примерно в этот промежуток времени. Вы вряд ли сможете предотвратить любое поведение, которое вы считаете вредоносным, дольше этого периода.

• Обратите внимание: тот факт, что Tor проксирует только трафик TCP, а не какой-либо другой протокол, значительно ограничивает возможности злоупотреблений.

iptablesможет позволить вам обрабатывать новые исходящие TCP-соединения иначе, чем существующие. Все, что ESTABLISHED,RELATEDдолжно быть ACCEPTEDили проходить через цепочку "существующих TCP-соединений", и исходящий TCP, который не попадает в нее, может быть ограничен по скорости. Любой исходящий трафик Tor должен быть предметом этого.

Я считаю, что лучшее, что вы можете сделать, это сделать между вышеизложенным и применением «Политики сокращенного выхода».

В идеале не запускайте на своем компьютере Tor ничего, кроме:

• По крайней мере, у вас, скорее всего, будет включен SSH, просто установите его на порт, отличный от 22.
• Вероятно, вам захочется запустить простой веб-сервер для отображенияэта страница. mini-httpdЭкземпляр chroot'ed должен подойти. Не используйте inetd.

Не запускайте Tor на коробке, которая используется для чего-то еще. Убедитесь, что вы прочитали раздел "Exit Relays"часто задаваемые юридические вопросы Torи полностью понимать его последствия. Такжепрочитайте и сделайте все это.

Answer 2

Будет сложнее, чем обычно, предотвратить эти атаки, поскольку исходный IP не постоянен. Однако, насколько мне известно, маршруты в Tor меняются только каждые несколько минут или около того.

Таким образом, вы по-прежнему можете развернуть некоторые стандартные правила ограничения/фильтрации, но с более высоким порогом, поскольку вы должны предполагать, что за вашими исходными IP-адресами стоит целая сеть.

Вы можете фильтровать:

• плохие или типичные пакеты идентификации/сканирования (плохие флаги TCP/IP, XMAS, большинство типов ICMP и т. д.)
• НЕДОПУСТИМЫЕ пакеты, которые не подходят для текущих или новых соединений (состояние -m)
• НОВЫЕ соединения, начинающиеся с довольно высокого порога

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

Также для ограничения скорости НОВЫХ (или не имеющих состояния) пакетов вы можете рассмотреть более сложную схему, где отклоненные (никогда не ОТБРАСЫВАЕМЫЕ, если это явно не атака!) пакеты рандомизируются. Таким образом, обычный пользователь может просто попытаться нажать перезагрузку и ему повезет, даже если общая скорость в настоящее время находится на пределе, в то время как параллельный сканер портов не сможет обойти ваше ограничение скорости.

Также спрашивайте в почтовых рассылках Tor, вы, вероятно, не первый, у кого возникли такие мысли:https://lists.torproject.org/cgi-bin/mailman/listinfo

Answer 3

Во-первых, я бы не советовал использовать iptables для решения всех этих проблем. На самом деле, идеальный выходной узел Tor будет загружать балансирующий трафик через несколько VPN-туннелей, чтобы отвлечь внимание интернет-провайдера от пакетов и истинного назначения, и/или использовать кэширующий прокси-сервер для сохранения исходящих повторных запросов на популярныестатическийсодержание к минимуму... пока рассматриваю эти варианты, вотлейкопластырьдля решения проблем с жалобами на злоупотребления;

Источники использованной информации

http://www.ossramblings.com/using_iptables_rate_limiting_to_prevent_portscans

http://blog.nintechnet.com/how-to-block-w00tw00t-at-isc-sans-dfind-and-other-web-vulnerability-scanners/

Объединение двух исходных ссылок в правила, которые можно использовать для того, чтобы помешать ботам, пытающимся использовать ваш выходной узел Tor для сканирования портов. Обратите внимание, что это может сильно расстроить хакеров, использующих ваш выходной узел, поскольку эти правила вызывают зависание nmap.

#!/bin/bash
## Network interface used by Tor exit daemon
_tor_iface="eth1"
## Ports that Tor exit daemon binds to, maybe comma or space sepperated.
_tor_ports="9050,9051"
## Time to ban connections out in secconds, default equates to 10 minutes, same as default Tor cercut.
_ban_time="600"
## How long to monitor conections in seconds, default equates to 10 minutes.
_outgoing_tcp_update_seconds="600"
## How many new connections can be placed to a server in aloted update time limits. May nead to increes this depending on exit node usage and remote servers usages.
_outgoing_tcp_hitcount="8"
## How long to monitor connections for in minuets, default is 15 minutes but could be lessoned.
_outgoing_tcp_burst_minute="15"
## Hom many connections to accept untill un-matched
_outgoing_tcp_burst_limit="1000"

iptables -N out_temp_ban -m comment --comment "Make custom chain for tracking ban time limits" || exit 1
iptables -A out_temp_ban -m recent --set --name temp_tcp_ban -p TCP -j DROP -m comment --comment "Ban any TCP packet coming to this chain" || exit 1

iptables -N out_vuln_scan -m comment --comment "Make custom chain for mitigating port scans originating from ${_tor_iface}" || exit 1
for _tor_port in ${_tor_ports//,/ }; do
    iptables -A out_vuln_scan -p TCP -o ${_tor_iface} --sport ${_tor_port} -m recent --name temp_tcp_ban --update --seconds ${_ban_time} -j DROP -m comment --comment "Update ban time if IP address is found in temp_tcp_ban list" || exit 1
    iptables -A out_vuln_scan -p TCP -o ${_tor_iface} --sport ${_tor_port} -m state --state NEW -m recent --set -m comment --comment "Monitor number of new conncetions to ${_server_iface}" || exit 1
    iptables -A out_vuln_scan -p TCP -o ${_tor_iface} --sport ${_tor_port} -m state --state NEW -m recent --update --seconds 30 --hitcout 10 -j out_temp_ban -m comment --comment "Ban address when to many new connections are attempted on ${_tor_iface}" || exit 1
done
iptables -A out_vuln_scan -j RETURN -m comment --comment "Return un-matched packets for further processing" || exit 1

## Add rules to accept/allow outbound packets
iptables -N tor_out -m comment --comment "Make custom chain for allowing Tor exit node services" || exit 1
for _tor_port in ${_tor_ports//,/ }; do
    iptables -A tor_out -p TCP -o ${_tor_iface} --sport ${_tor_port} -m state --state NEW -m recent --set --name limit_${_tor_port} -m comment --comment "Track out-going tcp connections from port ${_tor_port}" || exit 1
    iptables -A tor_out -p TCP -o ${_tor_iface} --sport ${_tor_port} -m state --state NEW -m recent --update --seconds ${_outgoing_tcp_update_seconds:-60} --hitcount ${_outgoing_tcp_hitcount:-8} --rttl --name limit_${_tor_port} -j LOG --log-prefix "TCP flooding port ${_tor_port}" -m comment --comment "Log atempts to flood port ${_tor_port} from your server" || exit 1
    iptables -A tor_out -p TCP -o ${_tor_iface} --sport ${_tor_port} -m state --state NEW -m recent --update --seconds ${_outgoing_tcp_update_seconds:-60} --hitcount ${_outgoing_tcp_hitcount:-8} --rttl --name limit_${_tor_port} -j DROP -m comment --comment "Drop attempts to flood port ${_tor_port} from your server" || exit 1
    iptables -A tor_out -p TCP -o ${_tor_iface} --sport ${_tor_port} -m limit --limit ${_outgoing_tcp_burst_minute:-15}/minute --limit-burst ${_outgoing_tcp_burst_limit:-1000} -j ACCEPT -m comment --comment "Accept with conditions new connections from port ${_tor_port} from your server" || exit 1
done
iptables -A tor_out -j RETURN -m comment ---comment "Reurn un-matched packets for further filtering or default polices to take effect." || exit 1
## Activate jumps from default output chain to new custom filtering chains
iptables -A OUTPUT -p TCP -o ${_tor_iface} -j out_vuln_scan -m comment --comment "Jump outbound packets through vulnerability scaning mitigation" || exit 1
iptables -A OUTPUT -p TCP -o ${_tor_iface} -j tor_out -m comment --comment "Jump outbound packets through conditional acceptance" || exit 1

Запустите вышеприведенную команду, bashчтобы применить магию к переменным с помощью ,cammas, например:

user@host~# bash iptables_limit_tor.sh

Вот еще раз список переменных.

_tor_iface="eth1"
_tor_ports="9050,9051"
_ban_time="600"
_outgoing_tcp_update_seconds="600"
_outgoing_tcp_hitcount="8"
_outgoing_tcp_burst_minute="15"
_outgoing_tcp_burst_limit="1000"

Обратите внимание, что вы также можете захотеть отфильтровать новые исходящие соединения по -m state NEW ! --synтипамзабавныйбизнес, используемый некоторыми ботами для поиска уязвимых серверов. Вот пример цепочки, которую вы могли бы использовать в качестве префикса для двух предыдущих для дальнейшей фильтрации такого вредоносного чата.

iptables -N out_bad_packets -m comment --comment "Make new chain for filtering malformed packets" || exit 1
iptables -A out_bad_packets -p TCP --fragment -j out_temp_ban -m comment --comment "Drop all fragmented packets" || exit 1
iptables -A out_bad_packets -p TCP -m state --state INVALID -j out_temp_ban -m comment --comment "Drop all invalid packets" || exit 1
iptables -A out_bad_packets -p TCP ! --syn -m state --state NEW -j out_temp_ban -m comment --comment "Drop new non-syn packets" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL NONE -j out_temp_ban -m comment --comment "Drop NULL scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL ALL -j out_temp_ban -m comment --comment "Drop XMAS scan"|| exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL FIN,URG,PSH -j out_temp_ban -m comment --comment "Drop stealth scan 1" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL SYN,RST,ACK,FIN,URG -j out_temp_ban -m comment --comment "Drop pscan 1"|| exit 1
iptables -A out_bad_packets -p TCP --tcp-flags SYN,FIN SYN,FIN -j out_temp_ban -m comment --comment "Drop pscan 2" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags FIN,RST FIN,RST -j out_temp_ban -m comment --comment "Drop pscan 3" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags SYN,RST SYN,RST -j out_temp_ban -m comment --comment "Drop SYN-RST scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ACK,URG URG -j out_temp_ban -m comment --comment "Drop URG scans" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL SYN,FIN -j out_temp_ban -m comment --comment "Drop SYNFIN scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL URG,PSH,FIN -j out_temp_ban -m comment --comment "Drop nmap Xmas scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL FIN -j out_temp_ban -m comment --comment "Drop FIN scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL URG,PSH,SYN,FIN -j out_temp_ban -m comment --comment "Drop nmap-id scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags RST RST -o ${_tor_iface} --sport ${_tor_port} -m limit --limit 2/second --limit-burst 3 -j out_temp_ban -m comment --comment "Mitigate Smurf attacks from excesive RST packets"
iptables -A out_bad_packets -p TCP --tcp-flags RST RST -o ${_tor_iface} --sport ${_tor_port} -m limit --limit 2/second --limit-burst 2 -j RETURN -m comment --comment "Ban Smurf attacks using excesive RST packets"
iptables -A out_bad_packets -j RETURN -m comment --comment "Return un-matched packets for further processing." || exit 1

Однако, указанная выше цепочка будет очень ограничительной, поскольку любой соответствующий пакет будет иметь IP-адрес, запрещенный (возможно, измененный -j out_temp_banна -j DROPили -j REJECTдля тестирования) на столько секунд, сколько выбрано в правилах этой цепочки. Этот набор правил также может вызывать ложные срабатывания, когда плохо закодированные приложения на стороне клиента повторно подключаются через новый Tor cercut.

~~~~~

Программное обеспечение для дальнейшего шейпинга трафика Проверьте firejailLinux, исходный код находится на Github и Source forge, а страницы руководства можно найти на старой домашней странице, поддомене WordPress, и у DigitalOcean есть руководство для Nginx с PHP и Firejail, которое с небольшими изменениями может дать вам гораздо больше информации о том, где сеть должна быть ограничена. Существуют и другие инструменты, такие как, KVMкоторые можно использовать для сохранения определенных служб в рабочих границах, поэтомумагазинarround, чтобы найти тот, который лучше всего подходит для вашей системы.

Еще один вариант — запустить его fail2banтаким образом, чтобы при попытке сумасшедшего системного администратора установить http- или ssl-подключение к вашему IP-адресу добавлялось правило для сброса -m state --state NEWподключений к тем, кто запрашивает вашу страницу уведомления о выходе. В сочетании с разумными временными ограничениями разбана это может позволить удаленному серверу отдохнуть, пока их системный администратор бормочет о загрязнении журнала ;-) Однако это выходит за рамки текущего ответа и зависит от того, какое программное обеспечение вы используете для обслуживания страниц уведомления о выходе; намек, что и nginx, и apache будут обслуживать первый блок vhost или server в ваших конфигурациях, если был запрошен текущий URL-адрес. Если вы используете что-то другое, кроме apache или nginx, вам нужно будет обратиться к страницам руководства, но для меня это было так же просто, как настроить первый vhost для ведения журнала в другой файл и заставить fail2ban добавлять любые IP-адреса из этого журнала во временный список банов; Это также отлично подходит для блокировки ботов на публичных серверах, поскольку они обычно используют IP-адрес, и если не предоставить запрос домена, сервер сработает как ловушка для ботов или, в данном случае, выдаст уведомление о выходе.

Я бы склонился к тому, чтобы запустить ограниченную политику выхода Tor (кажется, вы с этим разобрались), а затем протолкнуть трафик через VPN-туннели, дополнительные кредитные баллы для балансировки нагрузки между несколькими туннелями. Потому что это вызовет меньше помех в сетевом трафике Tor и сохранит глаза вашего интернет-провайдера закрытыми от того факта, что вы используете выходной узел... если только они не захотят признаться в прослушивании и взломе вашего VPN-трафика. Это потому, что запуск правил, которые временно запрещают или позволяют удаленному хосту самостоятельно блокировать, может привести к нарушению конфиденциальности клиентов вашего узла, тогда как проталкивание трафика через VPN (или несколько) поможет конфиденциальности вашего клиента и убережет вашего интернет-провайдера от преследованияЗапросыдля журналов сетевого трафика любым правительством, способным вести whois www.some.domain.

~~~~

Изменения/Обновления

~~~~

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

Вот jail.localстрофа fail2ban

[apache-ipscan]
enabled  = true
port = http,https
filter = apache-ipscan
logpath = /var/log/apache*/*error_ip*
action = iptables-repeater[name=ipscan]
maxretry = 1

А вот и apache-ipscan.confфайл фильтра

[DEFAULT]
_apache_error_msg = \[[^]]*\] \[\S*:error\] \[pid \d+\] \[client <HOST>(:\d{1,5})?\]
[Definition]
failregex = \[client <HOST>\] client denied by server .*(?i)/.*
#^<HOST>.*GET*.*(?!)/.*
#   ^%(_apache_error_msg)s (AH0\d+: )?client denied by server configuration: (uri )?.*$
#            ^%(_apache_error_msg)s script '\S+' not found or unable to stat(, referer: \S+)?\s*$
ignoreregex = 
# DEV Notes: 
# the web server only responds to clients with a valid Host: 
# header. anyone who tries using IP only will get shunted into 
# the dummy-error.log and get a client-denied message
#
# the second regex catches folks with otherwise valid CGI paths but no good Host: header
#
# Author: Paul Heinlein

А вот iptables-repeater.confфайл действий

# Fail2Ban configuration file
#
# Author: Phil Hagen <[email protected]>
# Author: Cyril Jaquier
# Modified by Yaroslav Halchenko for multiport banning and Lukas Camenzind for persistent banning
# Modified by S0AndS0 to combine features of previous Authors and Modders
#
[Definition]
# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart = iptables -N fail2ban-BADIPS-<name>
              iptables -A fail2ban-BADIPS-<name> -j RETURN
          iptables -I INPUT -j fail2ban-BADIPS-<name>
          ## Comment above line and uncomment bello line to use multiport and protocol in addition to named jails
          #iptables -I INPUT -p <protocol> -m multiport --dports <port> -j fail2ban-BADIPS-<name>
          # set up from the static file
          #cat /etc/fail2ban/ip.blocklist.<name> |grep -v ^\s*#|awk '{print $1}' | while read IP; do iptables -I fail2ban-BADIPS-<name> 1 -s $IP -j DROP; done
          cat /etc/fail2ban/ip.blocklist.<name> |grep -v ^\s*#|awk '{print $1}' | while read IP; do iptables -I fail2ban-BADIPS-<name> 1 -d $IP -j DROP; done
          ## Comment above line and uncomment bellow line to check if there are blacklist files to load before attempting to load them
          # if [ -f /etc/fail2ban/ip.blacklist.<name> ]; then cat /etc/fail2ban/ip.blacklist.<name> | grep -e <name>$ | cut -d "," -s -f 1 | while read IP; do iptables -I fail2ban-BADIPS-<name> 1 -s $IP -j DROP; done; fi
# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#
actionstop = iptables -D INPUT -p <protocol> -m multiport --dports <port> -j fail2ban-BADIPS-<name>
         iptables -F fail2ban-BADIPS-<name> 
         iptables -X fail2ban-BADIPS-<name>
# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
#actioncheck = iptables -n -L INPUT | grep -q fail2ban-BADIPS-<name>
actioncheck = iptables -n -L OUTPUT | grep -q fail2ban-BADIPS-<name>
# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
#
#actionban = if ! iptables -C fail2ban-BADIPS-<name> -s <ip> -j DROP; then iptables -I fail2ban-BADIPS-<name> 1 -s <ip> -j DROP; fi
actionban = if ! iptables -C fail2ban-BADIPS-<name> -d <ip> -j DROP; then iptables -I fail2ban-BADIPS-<name> 1 -d <ip> -j DROP; fi
# Add offenders to local blacklist, if not already there
        if ! grep -Fxq '<ip>,<name>' /etc/fail2ban/ip.blocklist.<name>; then echo "<ip>,<name> # fail2ban/$( date '+%%Y-%%m-%%d %%T' ): auto-add for BadIP offender" >> /etc/fail2ban/ip.blocklist.<name>; fi
# Report offenders to badips.com
#        wget -q -O /dev/null www.badips.com/add/<name>/<ip>
# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
#
#actionunban = iptables -D fail2ban-REPEAT-<name> -s <ip> -j DROP
actionunban = iptables -D fail2ban-REPEAT-<name> -d <ip> -j DROP
# Disabled clearing out entry from ip.blacklist (somehow happens after each stop of fail2ban)
#sed --in-place '/<ip>,<name>/d' /etc/fail2ban/ip.blacklist.<name>
[Init]
# Defaut name of the chain
# 
# Defaut name of the chain
name = BADIPS
# Option:  port
# Notes.:  specifies port to monitor
# Values:  [ NUM | STRING ]  Default:
# 
#port = ssh
# Option:  protocol
# Notes.:  internally used by config reader for interpolations.
# Values:  [ tcp | udp | icmp | all ] Default: tcp

Обратите внимание, что фильтр выше был отредактирован для блокировки OUTPUTдействий запуска/остановки, но вам все равно нужно будет добавить конфигурации -p TCP -m state --state NEWв каждую строку, чтобы запрещать только новые исходящие соединения с зарегистрированного IP-адреса.

Последнее — настройка конфигурации Apache vHost, которая направляет тех, кто не запрашивает домен, в указанный журнал доступа и ошибок и настройка разрешенного и запрещенного доступа таким образом, чтобы он всегда выдавал ошибки, даже петля не должна была бы вытаскивать страницу без появления ошибок. Последнее, но не менее важное — настройка страницы ошибок для Apache на уведомление о выходе по умолчанию из Tor, чтобы оно подавалось вместо 503обычных 404сообщений. Или, если вы добавили строки состояния в действия iptables для fail2ban, вы могли бы просто указать на тот же файл журнала, который используется вашим уведомлением о выходе. Результатом будет то, что ваш сервер не сможет устанавливать новые соединения с IP-адресом сервера, который проверял ваш IP-адрес, но установленные и связанные соединения по-прежнему будут разрешены, т. е. они по-прежнему смогут просматривать ваши другие страницы, но вы не сможете просматривать их.

Answer 4

У меня есть лучшее решение: сервер кэширования squid. Сервер кэширования squid доступен для настройки, определяя aclи вас denyили acceptкаждого acl. Очень интересно, что команда squid определяет набор правил в своей вики, что ваш вопрос нашелтам iptables,PFили другие не могут выполнять вашу работу, потому что просто работают на других уровнях.