Jump to content
Калькуляторы

Реализация блокировки некошерной инфо с помощью Squid3 прошу подсказать

Всем привет, есть вопрос по сабжу, для начала опишу схему:

Для определенной группы абонентов с белыми адресами понадобилась более правильная реализация схемы блокировки, с подсовыванием мажорной странички, на которой всё расписано, почему нельзя и кто он по жизни.

Решили реализовать это схемой, где в конце будет tproxy от squid3. В клиентский vrf подгружаются маршруты /32 на некошерные ресурсы, где nexthop`ом будет адрес виртуалки с кваггой и сквидом, iptables заворачивает все пакеты с dst-port 80 на порт сквида. В сам сквид подгружается список с url`ми плохих парней и с помощью его acl - блокируются данные url. Ну, это вкратце о схеме, а теперь ниже, суть проблемы:

дальше сквида ничего не улетает и в логи сквида сыпятся сообщения, типа

TCP_MISS_ABORTED/000 0 GET http://blablabla_url

или

TCP_MISS/503 3745 GET http://blablabla_url

Более ничего криминального в логах сквида не появляется, бывает, что пролетает TCP_MISS/200 или 302, но не более и редко.

IPTABLES

echo 1 > /proc/sys/net/ipv4/ip_forward
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100 
/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -F INPUT
/sbin/iptables -P OUTPUT ACCEPT
/sbin/iptables -F OUTPUT
/sbin/iptables -P FORWARD DROP
/sbin/iptables -F FORWARD
/sbin/iptables -F PREROUTING
/sbin/iptables -t nat -F
/sbin/iptables -t mangle -F
/sbin/iptables -F
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu
/sbin/iptables -t mangle -N DIVERT
/sbin/iptables -t mangle -A DIVERT -j MARK --set-mark 1
/sbin/iptables -t mangle -A DIVERT -j ACCEPT
/sbin/iptables  -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3129

 

И конфигурация сквида

 

cat /etc/squid3/squid.conf |grep -v -E "#|^$"
acl blocksites url_regex "/etc/squid3/block_url"
acl our_networks src x.x.x.x/21
http_access deny blocksites
acl SSL_ports port 443
acl CONNECT method CONNECT
acl GET method GET
acl POST method POST
cache deny all
dns_v4_first on
http_access allow our_networks CONNECT
http_access allow our_networks GET
http_access allow our_networks POST
http_access allow our_networks Safe_ports
http_access allow our_networks all
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access deny all
http_port 0.0.0.0:3128
http_port 0.0.0.0:3129 tproxy
cache_dir ufs /var/spool/squid3 100 16 256
access_log daemon:/var/log/squid3/access.log squid
logfile_rotate 4
coredump_dir /var/spool/squid3
refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern -i (/cgi-bin/|\?) 0	0%	0
refresh_pattern (Release|Packages(.gz)*)$      0       20%     2880
refresh_pattern .		0	20%	4320
deny_info http://url_to_denyinfo_page blocksites
nonhierarchical_direct off
dns_nameservers x.x.x.x y.y.y.y

 

Если, к примеру, клиент набирает url из некошерного списка

http://zepic.org/2013/04/loli-i-tentakli/

, то в логе сквида все хорошо,

TCP_DENIED/302 347 GET http://zepic.org/2013/04/loli-i-tentakli/ - HIER_NONE/- text/html

. Но, если набрать не блокированный адрес, http://zepic.org/, то через некоторое время ожидания сквид выдаст в лог

 TCP_MISS/503 2451 GET http://zepic.org/ - HIER_DIRECT/104.28.8.117 text/html

и клиенту отдается страница с ошибкой.

С помощью tcpdump, на исходящем интерфейсе, было выяснено, что имеет место быть неверная контрольная сумма

 

tcpdump -i eth1 -vvvv host zepic.org
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
10:58:01.213056 IP (tos 0x0, ttl 64, id 65022, offset 0, flags [DF], proto TCP (6), length 60)
   ip216-194.isp_xxx.ru.49799 > 104.28.8.117.http: Flags [s], cksum 0x786d (incorrect -> 0xe0df), seq 2638483124, win 29200, options [mss 1460,sackOK,TS val 448197450 ecr 0,nop,wscale 7], length 0

 

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

 

uname -a
Linux quagga 3.13.0-49-generic #83-Ubuntu SMP Fri Apr 10 20:11:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

squid3 -v
Squid Cache: Version 3.3.8
Ubuntu
configure options:  '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' 
'--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=${prefix}/lib/squid3' '--srcdir=.' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' 
'--datadir=/usr/share/squid3' '--sysconfdir=/etc/squid3' '--mandir=/usr/share/man' '--enable-inline' '--enable-async-io=8' '--enable-storeio=ufs,aufs,diskd,rock' 
'--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-underscores' '--enable-icap-client' '--enable-follow-x-forwarded-for'
'--enable-auth-basic=DB,fake,getpwnam,LDAP,MSNT,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB' '--enable-auth-digest=file,LDAP' '--enable-auth-negotiate=kerberos,wrapper'
'--enable-auth-ntlm=fake,smb_lm' '--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group' 
'--enable-url-rewrite-helpers=fake' '--enable-eui' '--enable-esi' '--enable-icmp' '--enable-zph-qos' '--enable-ecap' '--disable-translation' 
'--with-swapdir=/var/spool/squid3' '--with-logdir=/var/log/squid3' '--with-pidfile=/var/run/squid3.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' 
'--enable-linux-netfilter' 'build_alias=x86_64-linux-gnu'
'CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall'
'LDFLAGS=-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 
'CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security'


iptables v1.4.21

Edited by ilili

Share this post


Link to post
Share on other sites

А страница-заглушка всегда одинаковая или ее содержимое зависит от клиента и целевого URL?

Share this post


Link to post
Share on other sites

А страница-заглушка всегда одинаковая или ее содержимое зависит от клиента и целевого URL?

Всегда одинаковая и находится на другом сервере. Но пробовал поднимать lighttpd на этом же сервере с сквид и редиректить туда же - не помогло.

Share this post


Link to post
Share on other sites

А возврат траффика с этих сайтов идет тоже через squid? src ip (блокированные) src port 80

Ибо в схеме tproxy - запрос дальше пойдет с ip клиента - но он уже "не такой" и возвращаться должен через сквид

Share this post


Link to post
Share on other sites

А возврат траффика с этих сайтов идет тоже через squid? src ip (блокированные) src port 80

Ибо в схеме tproxy - запрос дальше пойдет с ip клиента - но он уже "не такой" и возвращаться должен через сквид

Возврат траффика идет непосредственно на src ip клиента, в этом то вся и проблема, как я думаю, т.к. ожидается ответ на src ip прокси.

Что делать, шеф ? ))

Edited by ilili

Share this post


Link to post
Share on other sites

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

Tproxy действительно принципиален?

Share this post


Link to post
Share on other sites

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

Tproxy действительно принципиален?

Альтернативы есть? Вы реализовали без опции tproxy, перенаправляя запросы на обычный порт сквида ?

Share this post


Link to post
Share on other sites

Да, обычный прозрачный проксик, который себя никак не прячет - делает редирект на заглушку при блокировке и молча отдаёт остальное запрошенное. В случае таймаутов видно (почти) дефолтную сквидовскую страничку, но это редко, и проблемы никто в этом не видит.

Share this post


Link to post
Share on other sites

Да, обычный прозрачный проксик, который себя никак не прячет - делает редирект на заглушку при блокировке и молча отдаёт остальное запрошенное. В случае таймаутов видно (почти) дефолтную сквидовскую страничку, но это редко, и проблемы никто в этом не видит.

Т.е. не сквид3, какой-то другой, как я Вас понял. Подскажете название ?

[edit] или вы вообще весь трафик заворачиваете на этот проксик ?

Edited by ilili

Share this post


Link to post
Share on other sites

Squid3 в режиме transparent, схема почти такая же, как у вас.

Ну, то есть у нас сбоку от бордера прокся, которая на бордер по bgp заливает маршруты на фильтруемые ресурсы, и прозрачно проксирует весь http.

Share this post


Link to post
Share on other sites

Squid3 в режиме transparent, схема почти такая же, как у вас.

Ну, то есть у нас сбоку от бордера прокся, которая на бордер по bgp заливает маршруты на фильтруемые ресурсы, и прозрачно проксирует весь http.

ну ведь это ж и есть режим tproxy, он раньше intercept назывался

Share this post


Link to post
Share on other sites

Показательные строчки конфигов:

squid.conf

http_port 10.10.100.74:3128 transparent

iptables

-A INPUT -i eth0 -p tcp -m tcp --dport 3128 -j ACCEPT

И никаких излишеств.

 

Ну, то есть, я допускаю, что всё держится на deprecated-опциях, но оно работает, жрать не просит добавляем в полгода по ~200M памяти на виртуалку.

Edited by Sergeylo

Share this post


Link to post
Share on other sites

Показательные строчки конфигов:

squid.conf

http_port 10.10.100.74:3128 transparent

iptables

-A INPUT -i eth0 -p tcp -m tcp --dport 3128 -j ACCEPT

И никаких излишеств.

 

Ну, то есть, я допускаю, что всё держится на deprecated-опциях, но оно работает, жрать не просит добавляем в полгода по ~200M памяти на виртуалку.

ОК, попробую без излишеств :)

Share this post


Link to post
Share on other sites

-A INPUT -i eth0 -p tcp -m tcp --dport 3128 -j ACCEPT

 

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

Edited by ilili

Share this post


Link to post
Share on other sites

Я не большой спец в линухе, но вместо INPUT просится FORWARD.

Share this post


Link to post
Share on other sites

Возврат траффика идет непосредственно на src ip клиента, в этом то вся и проблема, как я думаю, т.к. ожидается ответ на src ip прокси.

Что делать, шеф ? ))

Отключать transparent и работать по схеме с обычным прокси. Но тогда будет виден IP прокси, а не клиента.

 

Или все таки возвращать с запрещенных IP и пропускать через squid по той же схеме.

Когда вы перехватываете соединение, даже если оно выглядит похоже (ip src/dst, port src/dst) - оно уже "другое", TCP sequence и прочее - отличаются. Соответственно это соединение "принадлежит" сквиду, и только он знает, как развернуть его в настоящее соединение клиента.

Тут решайте, как вам подойдет и пишите - расскажу, как сделать.

Share this post


Link to post
Share on other sites

Значимые строки iptables

-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A POSTROUTING -o eth1 -j MASQUERADE
-A INPUT -i eth0 -m state --state NEW -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 10.10.100.73/32 -i eth0 -j ACCEPT

Share this post


Link to post
Share on other sites

У нас схема со сквидом прозрачным, редиректором и квагой стабильно работает.

Может Вам обработку запрещенных url отдать сквидгварду или другому редиректору?

Share this post


Link to post
Share on other sites

Понимаю, что времени прошло очень много, но как-то раз решение было найдено :)

 

В сквиде нет необходимости использовать опцию tproxy, как это делал я, достаточно

http_port $ip:3129 intercept

$ip это адрес интерфейса, который слушает squid

Ну и в iptables

/sbin/iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to 3129
/sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE --random

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this