IPTables+tcpdump
Пользователи, просматривающие топик: none
|
Зашли как: Guest
|
Имя  |
| Сообщение |
<< Старые топики Новые топики >> |
|
|
IPTables+tcpdump - 2010-03-09 16:20:03.950000
|
|
|
surgutor
Сообщений: 627
Оценки: 0
Присоединился: 2008-05-29 11:42:15.623333
|
Вот необходимо написать фильтр…
Чтобы зверьки не ползали на всякие одноклассники-вконтакте ни на прямую, ни на через прокси. Как можно отсеивать пакеты? Что-то обчитался манов, никак не придумаю как прокси резать
|
|
|
|
|
RE: IPTables+tcpdump - 2010-03-09 17:03:18.710000
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
В смысле? Отфильтровать запросы на шлюзе?
Я делал так.
1. squid, ставим и настраиваем как transparent proxy. Настраиваем всю фильтрацию.
2. iptables'ом заворачиваем весь трафик уходящий на порты 80, 8080, 3128… на ip:port squid'а.
А. Во! Полез искать команду iptables нашёл http://www.faqs.org/docs/Linux-mini/TransparentProxy.html
Я вероятно по этому документу и делал. =)
Только потом я ещё в гугле и яндексе искал webproxy, и с первых нескольких страниц результатов делал блеклист вебпроксей.
|
|
|
|
|
RE: IPTables+tcpdump - 2010-03-09 17:14:10.863333
|
|
|
surgutor
Сообщений: 627
Оценки: 0
Присоединился: 2008-05-29 11:42:15.623333
|
Не, блеклист это понятно. Я хтел что-нибудь наподобие алгоритма "смотрим url запрашиваемого хоста-проверяем его по рег выражениям-если есть совпадение, то банка"
|
|
|
|
|
RE: IPTables+tcpdump - 2010-03-09 18:11:49.856666
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
squid умеет и по регекспам принимать решения. Да там и блеклист, по-сути регекспами строится. Если бы было надо просто домены блочить, то это проще делать dns-серваком.
|
|
|
|
|
RE: IPTables+tcpdump - 2010-03-10 17:45:54.096666
|
|
|
fippo
Сообщений: 127
Оценки: 0
Присоединился: 2008-12-28 13:14:06.130000
|
quote:
это проще делать dns-серваком
Ага, разве что там одни блондинки сидят. Что мешает гугловский днс выставить, например? iptables + модуль string, проще некуда.
|
|
|
|
|
RE: IPTables+tcpdump - 2010-03-11 07:50:26.816666
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
quote:
ORIGINAL: fippo
quote:
это проще делать dns-серваком
Ага, разве что там одни блондинки сидят. Что мешает гугловский днс выставить, например? iptables + модуль string, проще некуда.
Как эти не-блондинки будут получать админские права на машине, чтобы сменить днс в настройках соединения?
А когда получат и сменят, как они будут связываться с гугловским серваком, если 53-й порт не форвардится из локалки в инет?
У не-блондинок получиться объехать местный днс-сервер, только если по своей неблондинистости они обойдут одмина. Но в такой ситуации одмину ничто не поможет.
|
|
|
|
|
RE: IPTables+tcpdump - 2010-03-13 17:03:02.860000
|
|
|
WinLinux
Сообщений: 491
Оценки: 0
Присоединился: 2008-07-18 14:06:33.563333
|
quote:
ORIGINAL: rgo
squid умеет и по регекспам принимать решения. Да там и блеклист, по-сути регекспами строится. Если бы было надо просто домены блочить, то это проще делать dns-серваком.
Закрыть можно, но анонимайзеры все не отследишь, у нас в организации половина людей так и продолжает выходить на развлекательные сайты, а блокировали все эти сайты через squid, если нужно будет могу скинуть правила, которые это позволяют делать…
|
|
|
|
|
RE: IPTables+tcpdump - 2010-03-14 07:05:29.896666
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
quote:
ORIGINAL: WinLinux
quote:
ORIGINAL: rgo
squid умеет и по регекспам принимать решения. Да там и блеклист, по-сути регекспами строится. Если бы было надо просто домены блочить, то это проще делать dns-серваком.
Закрыть можно, но анонимайзеры все не отследишь, у нас в организации половина людей так и продолжает выходить на развлекательные сайты, а блокировали все эти сайты через squid, если нужно будет могу скинуть правила, которые это позволяют делать…
Блин, вы читаете вообще о чём я? Ну мать перемать… А? Ну что такое. Там сказано "если бы надо было просто домены блочить…". Так ведь? Сослагательное наклонение видим? Я где-нибудь говорил что в данной задаче действительно можно обойтись dns сервером? Нет не говорил. Так откуда же вы такие умные все вылезли?
Правила можешь не выкладывать. Я создавал такие правила, и я знаю как их сделать так, чтобы никто не прорвался. И чтобы известные анонимайзеры не работали. И чтобы другие не найти было. Плавали. Знаем. Надо просто потратить пару рабочих дней на сочинение блеклистов и регекспов. И ещё денёк на настройку анализа логов squid'а, чтобы потом, тратя десять минут в день на изучение логов, можно было бы извлекать из них все новые найденные анонимайзеры и дополнять блеклисты. Попытки и бесплодные поиски прекращаются через пару недель.
Хуже всего в этом бесит поведение гугла, который запрос может принять с ошибкой, может принять если он записан не в той раскладке клавиатуры, или если он записан транслитом. В плане составления регекспов – убиццо. Я даже скрипт какой-то писал, который брал слово, и делал кучу регекспов, чтобы это слово не прошло бы через прокси и не попало бы в гугл. Тут бы конечно модуль к squid'у не помешал бы. Модуль anti-google.
|
|
|
|
|
RE: IPTables+tcpdump - 2010-03-16 14:46:18.646666
|
|
|
harrier
Сообщений: 19
Оценки: 0
Присоединился: 2009-07-24 19:11:07.173333
|
quote:
ORIGINAL: rgo
В смысле? Отфильтровать запросы на шлюзе?
Я делал так.
1. squid, ставим и настраиваем как transparent proxy. Настраиваем всю фильтрацию.
2. iptables'ом заворачиваем весь трафик уходящий на порты 80, 8080, 3128… на ip:port squid'а.
А. Во! Полез искать команду iptables нашёл http://www.faqs.org/docs/Linux-mini/TransparentProxy.html
Я вероятно по этому документу и делал. =)
Только потом я ещё в гугле и яндексе искал webproxy, и с первых нескольких страниц результатов делал блеклист вебпроксей.
Блокировка нежелательных URL с помощью iptables
Вот маленькая вырезка
"Иногда может возникнуть необходимость заблокировать доступ к некоторым сайтам, и внесение их адресов или даже подсетей в фаервол не приносит желаемых результатов, так как продуманные пользователи продолжают посещать их используя веб прокси количество которых так велико что о блокировке их не может быть и речи…. Есть конечно и явные минусы этого способа, но в моем случае минусы приниматься во внимание не стали. Из плюсов стоит отметить полную блокировку сайтов, они не будут работать даже через веб и обычные прокси сервера, с них не будет доставлятся почта и "…. далее
|
|
|
|
|
RE: IPTables+tcpdump - 2010-03-16 15:27:36.690000
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
quote:
ORIGINAL: harrier
продуманные пользователи продолжают посещать их используя веб прокси количество которых так велико что о блокировке их не может быть и речи….
Враньё. Абсолютно непонятно как сделан логический вывод. Об этом стоит говорить, и стоит подыскивать способы блокировать все вебпрокси. Тем более что это единственный корректный способ.
Их ведь действительно возможно блокировать, и главная проблема не в их количестве, а в том что их списки постоянно меняются. Но правильный подоход к вопросу может решить эти проблемы. Во-первых можно просто пробежаться по спискам вебпроксей, на которые можно попасть с первых страниц разных запросов гугла. Очень, кстати, действенно. Особенно если отфильтровать разные вариации слов anonymizer и web-proxy в POST и GET данных.
Во-вторых, можно написать скрипт, который каждый день пробегается по всем этим страницам, выискивая там новые прокси, и добавляя их в список запрещённых доменов.
И, наконец, в-третьих, если админ готов не только задницу просиживать, но и делать что-то, то ему стоит просматривать логи сквида. Причём, желательно вооружившись скриптами-фильтрами. Более того, на мой взгляд, это достаточно перспективный путь, который помимо прочего может позволить отлавливать не только вебпрокси, но так же и прочие сайты, на которые пользователям лучше бы не появляться. И скажем мне, было бы очень интересно увидеть связку скриптов, позволяющую быстро просматривать список посещённых пользователями сайтов, и классифицировать их на несколько классов, причём с автоматической генерацией правил для сквида. Причём, естественно, чтобы эти скрипты позволяли бы обойтись без просмотра сайтов уже признанных допустимыми. Я много думал о такой связке, но руки так и не дошли. Ни до поиска в гугле, ни до самостоятельной реализации всего этого. А вот это было бы действительно интересно и действительно было бы в тему.
А блокирование айпитэйблесом – это на аварийный случай. Когда надо сделать быстро. Когда скорость важнее чистоты и эффективности решения. В статье написано о том, что будут заблокированы все сайты, на который упомянут vkontakte.ru. Но это лишь половина проблемы, ведь самое интересное, что если webproxy, кодирует жабаскриптом все post-данные в base64 или в urlencode, то iptables ничего не заблокирует. То есть, то что не надо блокировать будет блокироваться, а то что надо – нет. Хуже не придумаешь.
|
|
|
|
|
RE: IPTables+tcpdump - 2010-04-16 17:48:02.720000
|
|
|
surgutor
Сообщений: 627
Оценки: 0
Присоединился: 2008-05-29 11:42:15.623333
|
Я замучался…
Есть шлюз на дебе. iptables правила рописаны так
#!/bin/sh
sysctl net.ipv4.ip_forward=1
# Чистим цепочку FORWARD
iptables -F FORWARD
# Разрешаем проходить пакетам по уже установленным соединениям
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Разрешаем исходящие соединения из локальной сети к интернет-хостам
#iptables -A FORWARD -m conntrack --ctstate NEW -i eth1 -s 10.0.0.0/24 -j ACCEPT
# Весь остальной транзитный трафик — запрещаем
#iptables -P FORWARD DROP
# На всякий случай очистим цепочку POSTROUTING и PREROUTING таблицы nat
iptables -t nat -F POSTROUTING
iptables -t nat -F PREROUTING
#"Заварачиваем" весь исходящий из локальной сети трафик на 3128 порт, где висит SQIUD
iptables -t nat -A PREROUTING -i eth1 -p tcp -j REDIRECT --to-port 3128
# Маскарадим весь трафик, идущий через eth0
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 193.124.133.163
все элементарно… по идее весь трафик из подсети 10.0.0.0/24 должен отправляться на порт 3128, где висит сквид.
конфиг сквида простой (почти по умолчанию, только мною подредактированный)
acl all src all
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl localnet src 10.0.0.0/24 # RFC1918 possible internal network
acl SSL_ports port 443 # https
acl SSL_ports port 563 # snews
acl SSL_ports port 873 # rsync
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 631 # cups
acl Safe_ports port 873 # rsync
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny all
icp_access allow localnet
icp_access deny all
#Proxy-port
http_port 3128 transparent
hierarchy_stoplist cgi-bin ?
#Cache parametres
cache_mem 64 MB
cache_dir ufs /var/spool/squid 1024 16 256
cache_mgr specops2006@narod.ru
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern (Release|Package(.gz)*)$ 0 20% 2880
refresh_pattern . 0 20% 4320
logformat squid %ts %6tr %>a %>p %Ss/%Hs %<st %rm %ru %un %mt
access_log /var/log/squid/squid_access.log squid
logformat squidmime %ts %6tr %>a %>p %Ss/%Hs %<st %rm %ru %un %mt
access_log /var/log/squid/squid_mime.log squidmime
acl shoutcast rep_header X-HTTP09-First-Line ^ICY\s[0-9]
upgrade_http0.9 deny shoutcast
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache
extension_methods REPORT MERGE MKACTIVITY CHECKOUT
hosts_file /etc/hosts
coredump_dir /var/spool/squid
acl localhost src 127.0.0.1/32
http_access allow manager localhost
по идее эти две строки разрешают доступ в сеть клиенту 10.0.0.2. Но Облом, не пускает и никаких ошибок не выдает.
ЗЫ. в настройках оперы на 10.0.0.2 не прописан адрес и порт прокси сервера. по идее он не нужн, тк iptables сам заворачивает трафик на нужный порт
Где я и в чем не прав? я уже 2 недели занимаюсь сексом с этим долбанным сквидом
|
|
|
|
|
RE: IPTables+tcpdump - 2010-04-16 20:23:34.550000
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
Ты завернул весь трафик, и dns в том числе. А броузер ведь начинает с того, что выясняет dns адрес, причём с учётом правил он dns запрос отправляет сквиду. Мне кажется дело в этом.
|
|
|
|
|
RE: IPTables+tcpdump - 2010-04-16 21:48:13.016666
|
|
|
surgutor
Сообщений: 627
Оценки: 0
Присоединился: 2008-05-29 11:42:15.623333
|
я же не делаю каких либо ограничений для запросов от клиентов в сквиде? я же ничего не режу… почему он не пропускает днс запросы… даже если я набираю ip адрес, тоже самое
|
|
|
|
|
RE: IPTables+tcpdump - 2010-04-16 22:28:06.230000
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
Мне почему-то кажется, что сквид не умеет работать как dns-прокси. Даже, подумав, я скажу что он не справится с этим. Ведь с его точки зрения, всё выглядит будто к нему на порт 3128 стучатся клиенты и выдают http запросы. Когда клиент начинает выдавать dns запросы, сквид конечно же не понимает, что с этим запросом надо работать как с dns запросом, а не как с http.
Но даже если бы сквид слушал бы ещё другой порт, и туда мы бы отправляли dns запросы. Есть ли в конфиге сквида опции, которые позволяют настроить прослушиваемый порт как dns? По-моему нет. По-моему squid может работать как http, ftp, https прокси, но как днс-прокси он не умеет.
Тут, на мой взгляд, есть два варианта: либо позволять dns трафику проходить через ядро наружу к dns серверу (то есть трафик на 53-й порт форвардить наружу через NAT). Либо поставить свой кэширующий днс-сервер, и пускай клиенты из локалки пользуются им (но это опять же подразумевает, что трафик на 53-й порт не надо редиректить в сквид). Для bind, кстати, в инете прям готовые конфиги лежат, которые делают из него чисто кэширующий днс сервер.
quote:
даже если я набираю ip адрес, тоже самое
А вот это уже загадочнее. Надо локализовывать проблему. Попробуй вырубить все эти редиректы в iptables, и слово transparent из squid'а убери. А потом в опере настрой прокси и посмотри работает сквид или нет.
Если работает, то надо копать iptables.
|
|
|
|
|
RE: IPTables+tcpdump - 2010-05-07 18:03:09.606666
|
|
|
surgutor
Сообщений: 627
Оценки: 0
Присоединился: 2008-05-29 11:42:15.623333
|
Вот опять прошу помощи. Хочу чтобы шлюз пробрасывал ssh соединения на 22ой порт на 10.0.0.02
Сам демон ссша висит на шлюзе на 18257 порту.
Хочу чтобы при ссш-соединении на 193.124.133.163 он перебросывал на 10.0.0.2. Надеюсь нормально объяснил.
Вот конфиг
bla-bla-bla
# Разрешаем транзитные внутрь и наружу SSH-пакеты, 22 порт по протоколу TCP
iptables -t filter -A FORWARD -m conntrack --ctstate NEW -i eth0 -d 193.124.133.163 -p tcp --dport 22 -j ACCEPT
iptables -t filter -A FORWARD -m conntrack --ctstate NEW -i eth1 -s 10.0.0.0/24 -p tcp --dport 22 -j ACCEPT
bla-bla-bla
# Делаем проброс пакетов на определенные порты на 10.0.0.2
iptables -t nat -A PREROUTING -i eth0 -d 193.124.133.163 -p tcp -m multiport --dport 22,80,443,1234,8080:10000 -j DNAT --to-destination 10.0.0.2
iptables -t nat -A PREROUTING -i eth0 -d 193.124.133.163 -p udp -m multiport --dport 22,80,443,1234,8080:10000 -j DNAT --to-destination 10.0.0.2
Проброса нет, то есть пакеты проходят только на eth0 и все, кирдык. Изнутри тоже самое. Но ыыш на шлюз на 18257ой порт работают
|
|
|
|
|
RE: IPTables+tcpdump - 2010-05-12 09:16:30.596666
|
|
|
Kavabango
Сообщений: 80
Оценки: 0
Присоединился: 2008-10-20 18:36:46.690000
|
# iptables -t nat -A PREROUTING -p tcp –dport 22 -i ${WAN} -j DNAT –to 10.0.0.2:22
|
|
|
|
|
RE: IPTables+tcpdump - 2010-05-14 21:34:44.133333
|
|
|
surgutor
Сообщений: 627
Оценки: 0
Присоединился: 2008-05-29 11:42:15.623333
|
Блин…
Маразм… Две недели убил на осмысление элементарной вещи.
Правило PREROUTINGа работает ДО правила FORWARD. В результате этого, в качестве адреса назначения получалось 10.0.0.2, а не 193.124.133.163. И правило FORWARD резало его…
Мораль сей басни такова-ВНИМАТЕЛЬНО НАДО ЧИТАТЬ МАНЫ…
Хотя с точки зрения логики не совсем понятно…
Вроде пакет, который предназначен для транзита должен СНАЧАЛА приняться на порту eth0, а уже потом обработаться правилом PREROUTINGа. А на деле наоборот. Все равно, что удалять зубы через жопу…. ИМХО.
|
|
|
|
|
RE: IPTables+tcpdump - 2010-05-15 02:47:28.300000
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
quote:
ORIGINAL: surgutor
Хотя с точки зрения логики не совсем понятно…
Вроде пакет, который предназначен для транзита должен СНАЧАЛА приняться на порту eth0, а уже потом обработаться правилом PREROUTINGа. А на деле наоборот. Все равно, что удалять зубы через жопу…. ИМХО.
Во: http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES
На самом деле надо было сразу выдать эту ссылку, там есть очень приятная картинка, объясняющая прохождение пакета через файрвол. Всё на самом деле очень логично, если вникнуть.
|
|
|
|
|
|
