Stak

В общем, поставили в тестовую эксплуатацию фильтр в виде связки bgp(квагга), iptables+string, и скрипта, работающего с nfqueue. Будем посмотреть, что из этого получится.

Ну насчёт хардкора - это просто шутка) Хотя перенос refit на efi-раздел, и переразбивка диска на живую, без бекапа, обеспечила на выходе немало кирпичей :) П.С.: мне явно в другой котёл, там заметно просторнее должн быть :)

вы сами ставили? Сам и ставил. Не к ИТ-шникам же идти :)

Наконец то избавился от Macos на макбукэйре, выпилил её подчистую. Теперь только linux, только хардкор ) тут спрашивали, как не него бубунта ставится, и про время работы от батареи: так вот 12.04 ставится без проблем, но немного специальным путём (https://help.ubuntu.com/community/MacBookAir4-2), время работы субъективно немного поменьше чем на макосе.

Как-то, будучи в командировке, рядом с Купертино, соблазнился MacBook Air 13", и таскаю его с собой уже около года. Плюсы: Лёгкий. Корпус люминевый, SSD, уронить не страшно. Довольно долго живёт на батарее. Разъём подзарядки с магнитиком, удобно. Тачпад хороший. Минусы: Греется. Нет езернета на борту. Мак-ос - так и не смог привыкнуть, стоит Бубунта. встроенное видео - УГ, WoT тормозит. Всего 2 USB дырки. В целом - вполне приличная рабочая машинка.

Из Комстара есть тут кто? Ходят сытные слухи, что вы что-то подобное реализовали http://forum.nag.ru/forum/index.php?showtopic=79836&view=findpost&p=773720. Если не секрет, поделитесь результатами :)

работает только inline? или на ассиметричном (аплинк онли) трафике тоже?

SCE-шку, как и любой другой DPI , на ассиметричный трафик не повесить. Значит, даунлинк придётся гнать через неё. И про лимит в 100к записей не забываем....

пока не проверяли. Но что мешает их сконверитровать в unicode?

Моделировали экстремальные условия? Я не гуру в этих ваших iptables , но мне почему-то мыслится, что при over 9000 ссылках в этом месте сервер сложится. Буду рад ошибиться, бо сейчас тоже думаю в этом направлении: не очень нравится идея PBR'ить по километровым ACLам или лопатить весь HTTP в качестве альтернативы. По числу обрабатывающих серверов (next hop в bgp) маштабируется хорошо. По числу параллельных процессов-обработчиков - тоже должно неплохо, у NFQUEUE возможно 65К идентификаторов. Но нагрузочных тестов мы пока не проводили.

А что произойдет, если на какой-то странице на том же 'плохом' IP прямо в тексте страницы (а не в http обмене) будет "GET <плохой URL>"? Вы забыли, что смотрим мы только аплинк трафик (от абонента к серверу). Хотя могу предположить прикольную ситуацию - абонент пытается, к примеру, запостить на форум, размещённый на том "же плохом ip", некий текст с искомым URL, а его редиректит на сайт надзора :) P/S: кстати, string в iptables max.128 символов. Хотя вроде бы при сборке можно задать больше.

Наверное, я тормоз, но никак не могу понять, как в таком случае избежать маршрутной петли. Квагга анонсит more specific, транспорт кидает пакет серверу; тот, к примеру, решает, что ничего в пакете трогать не надо и отдает его обратно в транспорт; транспорт получает пакет от сервера и по идее должен снова вернуть его серверу согласно таблице роутинга. Петля, не? Или на серверном SVI висит роут-мап? Остальное более или менее понятно. Зависит от топологии сети, могут быть разные варианты. У нас например, входной и выходной интерфейсы сервера в разных vrf. Cоответственно, на внутреннюю ногу принимаем по бгп абонентские сети, а анонсим плохие ип, на внешнюю - принимаем дефолт, и ничего не анонсируем.

А что будет, когда клиенты увидят поддельный сертификат? И чем это лучше бана по IP ? Они не увидят поддельного сертификата. Это тупо блокировка https на данные ip, с показом forbidden-странички. А как оно будет работать для HTTP/1.1 с keepalive, когда GET /blabla будет не в начале TCP соединения, а на несколько мегабайт "глубже" ? Ну и новая мода с протоколом http://ru.wikipedia.org/wiki/SPDY ... Точно также оно будет работать. iptables ищет матч строки в теле всех tcp пакетов c dport 80 , которые попали на этот сервер. И кидаеет их в NFQUEUE. А по поводу SPDY - если без шифрования - то редеректа не покажет, но и на сайт не пустит. А если шифрованный - будем блокировать, как и https. Или есть другие предложения?

Кто там просил iptables конфигурацию для матча по строке? Она тривиальная: *mangle :PREROUTING ACCEPT [515896:28987359] :INPUT ACCEPT [514357:28806292] :FORWARD ACCEPT [1374:147744] :OUTPUT ACCEPT [1066767:144759434] :POSTROUTING ACCEPT [1067940:144880593] -A PREROUTING -p tcp -m string --string "/art/01/03" --algo bm --to 65535 -j NFQUEUE --queue-num 0 COMMIT Скрипт для отсылки редиректа (пока это просто маленький грязный хак, без оптимизации): #!/usr/bin/perl # # see http://search.cpan.org/~atrak/NetPacket-0.04/ #use strict; BEGIN { push @INC,"perl"; push @INC,"build/perl"; push @INC,"NetPacket-0.04"; }; use nfqueue; use NetPacket::IP qw(IP_PROTO_TCP); use NetPacket::TCP; use Socket qw(AF_INET AF_INET6); use Data::Dumper; use Net::RawIP; use CGI; my $cgi = CGI->new(); my $q; sub cleanup() { print "unbind\n"; $q->unbind(AF_INET); print "close\n"; $q->close(); } sub swap_values { my ( $src, $dst ) = @_; my $old_dst = $dst; $dst = $src; $src = $old_dst; return ( $src, $dst ); } sub create_packet { my ( $payload ) = @_; my $ip_obj = NetPacket::IP->decode($payload->get_data()); if($ip_obj->{proto} == IP_PROTO_TCP) { # decode the TCP header my $tcp_obj = NetPacket::TCP->decode($ip_obj->{data}); my $data_len = 0; if ($tcp_obj->{flags} & NetPacket::TCP::PSH && length($tcp_obj->{data})) { $data_len = length( $tcp_obj->{data} ); } $tcp_obj->{data} = $cgi->redirect( -uri => 'http://zapret-info.gov.ru/', -status => 301, -nph => 1, ); $tcp_obj->{checksum} = 0; $ip_obj->{checksum} = 0; ( $tcp_obj->{seqnum}, $tcp_obj->{acknum} ) = swap_values( $tcp_obj->{seqnum}, $tcp_obj->{acknum} ); $tcp_obj->{acknum} = $tcp_obj->{acknum} + $data_len; ( $ip_obj->{src_ip}, $ip_obj->{dest_ip} ) = swap_values( $ip_obj->{src_ip}, $ip_obj->{dest_ip} ); ( $tcp_obj->{src_port}, $tcp_obj->{dest_port} ) = swap_values( $tcp_obj->{src_port}, $tcp_obj->{dest_port} ); $ip_obj->{data} = $tcp_obj->encode($ip_obj); my $modified_payload = $ip_obj->encode(); my $packet = new Net::RawIP; $packet->set({ ip => { saddr => $ip_obj->{src_ip}, daddr => $ip_obj->{dest_ip}, }, tcp => { source => $tcp_obj->{src_port}, dest => $tcp_obj->{dest_port}, seq => $tcp_obj->{seqnum}, ack_seq => $tcp_obj->{acknum}, ack => 1, syn => 0, fin => 0, psh => 0, } }); $packet->send; my $ip2 = NetPacket::IP->decode($modified_payload); my $tcp2 = NetPacket::TCP->decode($ip2->{data}); my $ret = $payload->set_verdict_modified($nfqueue::NF_ACCEPT,$modified_payload,length($modified_payload)); return; } $payload->set_verdict($nfqueue::NF_ACCEPT); return; } sub cb() { my ($dummy,$payload) = @_; print "Perl callback called!\n"; print "dummy is $dummy\n" if $dummy; if ($payload) { create_packet( $payload ); } $payload->set_verdict($nfqueue::NF_ACCEPT); } $q = new nfqueue::queue(); $SIG{INT} = "cleanup"; print "setting callback\n"; $q->set_callback(\&cb); print "open\n"; $q->fast_open(0, AF_INET); print "trying to run\n"; $q->try_run();

Сейчас в лабе дорабатываем напильником следующее решение по организации фильтрации (без мега DPI:)) 1. берём список с сайта Роскомнадзора. 2. Парсим, получаем пары ip+URL 3. Полученые ip анонсим (кваггой) по бгп в наш транспорт. 4. В результате аплинк-трафик на данные адреса отправляется на фильтрующий сервер. Даунлинк при этом идёт мимо. 5. На сервере с помошью iptables (string matсh) перекидываем пакетики, в которых есть соответствующий URL (из п.2) в NFQUEUE. tcp handshake и другой трафик на эти адреса пролетает насквозь. Т.е. матчится только GET запрос. 6. из NFQUEUE их ловит перловый (пока) скрипт, который делает tcp hijacking (т.е. отвечает от имени удалённого сервера двумя пакетами: АСК-ом, и 301 редиректом на страницу блокировки. 7. для трафика на 443й порт, делаем редирект на локальный nginx, опять же отдающий редирект на страницу блокировки. П.п. 3,4,5,6 уже работают, остальное - думаю, также скоро допилим. Покритикуйте, может быть есть более интересные идеи.

+1 за VDSL. если есть телефонная проводка - работать будет очень даже неплохо. а про PLC - лучше забыть, стабильности никакой.

у меня wowwiki.comне открывается. Аплинки уже выпилили адрес?

если не проксировать - то не с одного.

Хорошая идея, кстати. Детали уже продумывали (проксируем или нет, какой софт использовать...)?

Кстати, пора тему то переименовать. Не будет, а уже есть :)

Уточнил у безопасников: Печалька. ФСБ нам это дело зарубило - формально ссылаются на 538 приказ (необходимо логгировать СОЕДИНЕНИЯ), Кстати, использование NAT (без логгирования по сессиям) этому приказу так же противоречит. Т.е. в текущих российских реалиях - внедрять Port Block Allocation или Deterministic NAT (РАТ) - нельзя. Точнее, можно, но логи по сессиям (с конкретным dst адресом) всё равно собирать надо.

Реализация Deterministic NAT (РАТ) была бы также интересной. http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-04

Ага, при при одном абоненте на секторе.

SyncE не решает задачу уменьшения джиттера. Он предназначен для передачи синхронизации по езернет сети.

Кто?? Дайте ж подробности. УФСБ - эти говорят - мол, запускайте что хотите, хоть ipv9, но нам злодеев ловить надо. Вендоры СОРМа. Омега, СОРМович... просят бабла за реализацию ipv6 в своих чудо-продуктах. Итого, для сохранения взаимопонимания с первыми - нужно либо занести бабла вторым, либо отложить внедрение ipv6 на неопределённый срок.