![[Home]](/static/root.gif)
Cлучайно наткнулся тут на тестирование велосипедных цепей на разрыв, чучуть более актуальное чем гост советских времен Connex_Breaking_Load_Test_Results.pdf, вобщем по сравнению с гостом все даже получше стало, что вобщем то не сильно меня удивило учитывая современные тракторные передачи.
--- Уязвимости в Cisco RV32x были устранены через блокировку запросов от утилиты curl.
Исследователи из компании RedTeam Pentesting обнаружили, что компания Cisco лишь создала видимость устранения уязвимостей в выпущенном в январе обновлении прошивки к маршрутизаторам Cisco RV320 и RV325. Вместо реального устранения проблем в скриптах web-интерфейса, в обновлении прошивки были внесены изменения в настройки http-сервера nginx, блокирующие обращение при помощи утилиты curl, которая использовалась в прототипе эксплоита и примерах для проверки наличия уязвимости.
После установки обновления прошивки с "устранением" проблем, устройства Cisco RV32x как и раньше остаются уязвимыми. Для атаки достаточно сменить значение User-Agent при помощи ключа "-A", например:
curl -s -k -A kurl -X POST --data 'submitbkconfig=0' https://192.168.1.1/cgi-bin/config.exp
Неисправленными остаются три уязвимости. Две проблемы (CVE-2019-1653) позволяют без аутентификации обратиться к скриптам config.exp или export_debug_msg.exp с флагом "submitbkconfig" и получить содержимое файла конфигурации устройства, включая хэши паролей доступа, и ключи к VPN и IPsec. При запросе через export_debug_msg.exp конфигурация отдаётся в зашифрованном виде, но для шифрования использован фиксированный пароль, присутствующий в прошивке ('NKDebug12#$%'). Третья уязвимость (CVE-2019-1652) позволяет выполнить любую команду в системном окружении устройства через манипуляции с параметрами в форме генерации сертфикатов (например, вместо имени можно указать "'a\$(ping -c 4 192.168.1.2)'b").
Поражает наивность реакции Cisco:
Предполагаю, что под "complete fix" они понимают блокировку User-Agent "kurl", используемый в новом примере атаки😊
И заметье, на подготовку такого патча им потребовалось полгода:
Ещё доставляет реклама этих рутеров на сайте Cisco:
Хоть это и мыльница и скорее всего ваще не их но тем не менее Ебаныйстыд!!!
Лазал я тут по ебею, и неожиданно попался моему взору juniper J 4350, за 5 тыщь вместе с доставкой - погуглил/почитал - по сути своей это софтроутер, по железу ни что иное как обычный четвертый пень в немного необычном конструктиве, унутри сплошной тантал - ломаца можно сказать нечему, за пару баксов с того же ебея можно туда вотнуть проц на 3.8GHz и памяти до 4 гигов, правда заюзать можно только 3.5 ибо i686, ну да не суть и того хватает с головой, вобщем во всех отношениях пиздатый аппарат😊 voip только можно сказать отсутствует, но с этим у жуниреров всегда было никак, есть какието платы пашущие тока с аваевским CM который мне нах не нужен, но с этим я решил смирица приставив сбоку циску с голосовыми портами, ктому же она у меня итак есть, ну и взял я его вобщем.
До него у меня дома роутером была cisco 2851, впринципе никаких проблем с ней небыло - всем хороша, кроме ната - больное место всех бранчевых кошек, торренты нисчадно его насиловали плодя тысячи сессий как я гайки(таймауты) там ни закручивал - всеравно периодически это ушатывало ее сраный процессор от калькулятора ситизен в полку😊 Это тоже от части способствовало покупке жунипера, у него заявлено 225килопакетов/с и 250к сессий на коробку с 2 гигами оперативы и какаято умопомрачительная по цискиным меркам цифра в 10000 новых сессий в секунду😊 у кошки просто 10000 сессий на нате уже проблема, если в секунду это уже пиздец ей в ту же секунду😊 Ну нада думать, калькулятор VS четвертый пень, хоть и селерон там на 2.53GHz но всеравно небо и земля😊 На практике вобщем то так и получилось - он этих торентов ваще никак не ощющает - что есть что нет - разница в загрузке плавает в районе 5 процентов. Кучу времени потратил на поиски софта - роутер приехал с убитой флешкой, не мог даже загрузица, заменить не проблема - там обычная CF на гиг-два пойдет а вот софт найти оказалось не так просто - довольно таки древний аппарат который вытеснили SRX'ы у которых ноги вобщем то и растут из J серии, точнее так то он по сути не сильно древний - поддержку дропнули тока в 2018 году, и софт есть на торрентах, но это архивы для установки уже поверх существующей системы, а вот чтоп с нуля на флэшку можно было закатать пришлось поискать, но в итоге все получилось - Juniper links все работает, после недельного траха с тоннелем на работу😊 Об этом и хочу рассказать😊
Вобщем нужен мне тоннель на работу, поверх которого у меня BGP почти прямо в кору в бэкбон. Дома у меня динамический серый IP. Все было легко и просто когда была кошка, так как с другой стороны тоже была кошка - все работало сполпинка поверх dmvpn что не удивительно ибо кошка с кошкой и кошковский dmvpn для такого и предназначен😊 Но тут вместо кошки жунипер - и резко возникает вопрос - КАК БЛЯТЬ ТЕПЕРЬ ЗДЕЛАТЬ этот сраный тоннель😊 Я не спец по всяким бранчевым решениям, у меня большие сети, большие маршрутизаторы, и физические каналы, а всякие vpn это все не мое, но тем не менее я сетевик - почитал порыл - задолбался - милионы блять howto и примеров как зделать практически любые тоннели между кошкой и джунипером да и не тока, но без динамических IP и ната - ну да блять, там и делать то нехер - прописал с двух сторон хоть гре хоть ipip да что угодно - и постят эти howto кругом, кому они нах нужны тока, а вот с динамикой из за ната уже все не так просто😊 В итоге я понял что блять единственный интероперабельный вариант в такой ситуации это IPSEC в туннельном режиме. Никогда до этого не ковырял IPSEC, попробовал вывернуца приставив сбоку кошку за джунипером - но DMVPN споткнулся на двойном нате, пришлось таки в срочном порядке осваивать IPSEC😊
На джунипере как ни странно все оказалось достаточно просто, а вот со стороны кошки постоянно получались какието косяки😊 Собственно сам IPSEC поднять получилось без проблем, проблемы возникали с тоннелем😊 У кошки вариантов этого ипсека тьма на все случаи жизни, если с другой стороны кошковское же решение😊 а вот если нет то начинаюца нестыковки😊
Сначала затык вышел с IPSEC внутри VRF😊 У меня там по сути был так называемый Front Door VPN - тоесть один конец тоннеля торчит в VRF c интернетом, другой в VRF с бэкбоном, так вот IPSEC в VRF не заработал, в global работал, в VRF нет - видать баг иоса какой то потому что дома так работал как и написано у кошки, а где нада нет😊
Так как там где нада это была не основная задача а иос подбираеца под основную таки - пришлось все это дело оттуда вообще вынести на какуюнить другую подходящую хрень😊 Подходящая хрень в виде древней ободранной и страшной как сама моя жизнь циски 3725 нашлась под чьим то столом, в состоянии "пинали лет 5 ногами" пока она там валялась, но тем не менее она включилась, матерясь на хренова крутящиеся вентиляторы, нада отдать ей должное😊 вентиляторы смазал😊 через пару дней смазка видать попала куда нада и мат убрался😊 В добавок таким образом надобность в одном vrf отпала и интернет я засунул в global дабы не усложнять себе жизнь😊
В итоге первое что реально заработало на ней собсно IPSEC через cryptomap на интерфейсе, с двумя ip на концах и поверх этого GRE тоннель - работает, но не красиво ибо умом то понимаеш что GRE тут лишний оверхед, а мне и сам IPSEC тоже лишний оверхед ибо шифровать мне там нечего - нужен только транспорт - нада убрать значит😊 Начал искать как - нарыл кошкин DVTI aka Dynamic Virtula Interface - вроде бы что нужно - жунипер судя по всему имеет то же самое и может гонять routing protocol прямо поверх тунельного интерфейса.
Но и тут вышел косяк - если в proxy identify вписать какой то конкретный ip то все работает, но со стороны жунипера шифруеца не весь траффик попадающий в интерфейс а только тот что попадает в proxy identify - тоесть route based VPN нихрена не получается. Если в proxy identify поставить 0.0.0.0/0 как и должно быть то интерфейс поднимался, но без роутинга - тоесть кошка без понятия какие адреса на встречном конце - ситуация сама по себе прикольная - интерфейс есть, а маршрута через него нет😊 И ниче с этим сделать нельзя - интерфейс динамический - берет настройки с virtual-template, ip с лупбэка через unnumbered - тоесть никак в конфигурации маршрут через него указать нельзя, как и адреса на другом конце😊 Можно настроить xauth и раздавать адреа из пула, но у меня там BGP и нужен статический IP, а создавать пул из 1 адреса тоже как то не красиво😊 Хрен его знает каким образом это работает между кошками но судя по howto и примерам в интернете как то работает. Я нашол только одно упоминание что такая проблема между кошками имеет место быть, и там же нашол решение - запустить до кучи какойнить мульткастовый routing протокол на интерфейсе, конкретно там был rip, но не нравица мне он и я попробовал ospf - и прокатило😊 По ospf кошка быстро снюхалась с жунипером и выяснила какой адрес на другом конце тоннеля, после чего уже стало возможным поднять BGP😊 но это просто на словах, а по факту есть куча ньюансов😊
Первый это собсно вообще наличие ospf на данном участке - учитывая что тоннель домой, роутер домашний и посему как правило на нем есть дефолт, и на бэкбоне есть дефолт😊 и вдобавок да малоли что я там наконфигурю из сетей, и учитывая что ospf фильтрации можно сказать не поддается - нада как то это изолировать от бэкбона, в котором тоже собсно ospf, а бэкбон изолировать от этого участка, ибо если я проанонсирую случайно дефлот в бэкбон из дома это будет ни что иное как пиздец😊 Благо решение нашлось и быстро.
cisco может имеить кучу ospf процессов, причем не связанных друг с другом, посему делаем так - для туннельного интерфейса отдельный ospf процесс, с distance 210, и все - его задача только выяснить что на другом конце тоннеля, ну и до кучи проанонсировать свою сторону но жуниперу это не нужно - там можно статически написать как локальный так и удаленный ip на туннельном интерфейсе, но малоли - может кому еще понадобица.
Тем не менее нам нада как то обмениваца маршрутами с маршрутизаторами входящими в бэкбон. Так как по ospf нельзя ибо как написано выше опастно делать мы это будем по протоколу BGP ибо фильтруеца он как угодно, а на кошке будем делать двухстороннюю редистрибьюцию bgw<->ospf 1.
Juniper как циско иметь кучу независимых ospf процессов не может, зато может по другому - там есть виртуальные роутеры - чтото типа кошкиных VRF тока круче😊 И ospf можно засунуть в такой виртуальный роутер дабы он не анонсировал что ни попадя, и че бы он там ни принял эти анонсы в этом виртуальном роутере так и остануца и не попадут в глобальную таблицу маршрутизации.
Вроде бы на этом все мои страдания по скрещиванию законьчилис, теперь собственно
version 12.4 service nagle no service pad service tcp-keepalives-in service tcp-keepalives-out service timestamps debug datetime msec localtime service timestamps log datetime msec localtime service password-encryption service sequence-numbers no service dhcp ! hostname frontdoor-vpn ! boot-start-marker boot-end-marker ! logging userinfo logging buffered 8192 debugging logging rate-limit 100 except warnings no logging monitor enable secret 5 хервам enable password 7 херасдваопять ! no aaa new-model clock timezone MSK 3 no ip source-route ip arp proxy disable no ip gratuitous-arps ip icmp rate-limit unreachable 1000 ip icmp rate-limit unreachable DF 100 ip cef ! ! ! ! ip vrf backbone rd 42916:1 ! no ip bootp server ip domain timeout 1 ip name-server 91.193.236.3 ip auth-proxy max-nodata-conns 3 ip admission max-nodata-conns 3 login on-failure log ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ip tcp ecn ip tcp selective-ack ip tcp synwait-time 10 ip tcp path-mtu-discovery ! crypto keyring DVTI-KEYRING local-address FastEthernet0/0 pre-shared-key address 0.0.0.0 0.0.0.0 key херасдвавамтрианесеркерткей crypto logging session ! crypto isakmp policy 10 encr aes authentication pre-share ! crypto isakmp policy 20 hash md5 authentication pre-share ! crypto isakmp policy 30 authentication pre-share crypto isakmp invalid-spi-recovery crypto isakmp keepalive 20 periodic crypto isakmp profile DVTI-ISAKMP-PROF keyring DVTI-KEYRING match identity address 0.0.0.0 virtual-template 1 ! crypto ipsec security-association replay disable ! crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac crypto ipsec transform-set ESP-AES-SHA esp-aes esp-sha-hmac crypto ipsec transform-set ESP-NULL-MD5 esp-null esp-md5-hmac crypto ipsec transform-set ESP-NULL-SHA esp-null esp-sha-hmac crypto ipsec transform-set ESP-DES esp-des crypto ipsec fragmentation after-encryption ! crypto ipsec profile IPSEC-PROF set transform-set ESP-DES-MD5 ESP-DES-SHA ESP-AES-SHA ESP-NULL-SHA ESP-NULL-MD5 ESP-DES set isakmp-profile DVTI-ISAKMP-PROF ! ! buffers tune automatic ! ! ! interface Loopback0 ip vrf forwarding backbone ip address 100.64.6.1 255.255.255.224 ! interface FastEthernet0/0 ip address 91.193.236.27 255.255.255.248 duplex auto speed auto no mop enabled hold-queue 512 in ! interface FastEthernet0/1 ip vrf forwarding backbone ip address 91.195.204.250 255.255.255.128 ip verify unicast source reachable-via rx ip ospf 1 area 0.0.0.0 duplex auto speed auto no mop enabled hold-queue 512 in ! interface Virtual-Template1 type tunnel ip vrf forwarding backbone ip unnumbered Loopback0 ip mtu 1492 ip tcp adjust-mss 1328 ip ospf network point-to-point ip ospf 2 area 0.0.0.0 tunnel source FastEthernet0/0 tunnel mode ipsec ipv4 tunnel protection ipsec profile IPSEC-PROF hold-queue 256 out ! router ospf 2 vrf backbone router-id 100.64.6.1 log-adjacency-changes passive-interface default no passive-interface Virtual-Template1 distance 210 ! router ospf 1 vrf backbone router-id 91.195.204.250 log-adjacency-changes redistribute connected subnets redistribute bgp 42916 subnets passive-interface default no passive-interface FastEthernet0/1 ! router bgp 42916 bgp router-id 91.193.236.27 bgp log-neighbor-changes neighbor 91.193.236.25 remote-as 42916 neighbor 91.193.236.25 description uplink_to_bgw0 neighbor 91.193.236.30 remote-as 42916 neighbor 91.193.236.30 description uplink_to_bgw1 maximum-paths ibgp 2 ! address-family ipv4 redistribute connected neighbor 91.193.236.25 activate neighbor 91.193.236.25 maximum-prefix 32 50 restart 1 neighbor 91.193.236.30 activate neighbor 91.193.236.30 maximum-prefix 32 50 restart 1 maximum-paths ibgp 2 no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf backbone redistribute connected redistribute ospf 1 vrf backbone match internal external 1 external 2 nssa-external 1 nssa-external 2 neighbor 100.64.6.2 remote-as 42916 neighbor 100.64.6.2 transport connection-mode passive neighbor 100.64.6.2 update-source Loopback0 neighbor 100.64.6.2 activate neighbor 100.64.6.2 next-hop-self neighbor 100.64.6.2 prefix-list no-default-route in neighbor 100.64.6.2 prefix-list no-default-route out neighbor 100.64.6.2 route-map vpn_bgp_out out neighbor 100.64.6.2 maximum-prefix 32 16 restart 10 no synchronization bgp redistribute-internal exit-address-family ! no ip forward-protocol nd no ip forward-protocol udp nameserver no ip forward-protocol udp domain no ip forward-protocol udp time no ip forward-protocol udp netbios-ns no ip forward-protocol udp netbios-dgm no ip forward-protocol udp tacacs ! ! no ip http server no ip http secure-server ! ip access-list standard REMOTE-CONSOLE permit 10.32.75.177 permit 91.193.236.32 0.0.0.31 ! ! ip prefix-list no-default-route seq 5 permit 0.0.0.0/0 ge 1 logging filter flash:logfilter.tcl ! route-map vpn_bgp_out permit 10 set origin igp ! ! ! control-plane ! ! ! ! ! ! ! ! ! ! line con 0 line aux 0 line vty 0 4 access-class REMOTE-CONSOLE in vrf-also exec-timeout 35791 0 password 7 даскокажтутапаролейтоблять:) login transport input all ! process cpu statistics limit entry-percentage 30 size 600 ntp clock-period 17180646 ntp server 91.193.236.10 ntp server 91.193.237.1 ! end
Впринципе тут все понятно - vrf backbone это собственно vrf воткнутый в бэкбон через FastEthernet0/1, на нем поднят ospf процесс номер 1 по которому и происходит обмен маршрутами с маршрутизаторами входящими в бэкбон.
Интернет в глобале по BGP с двух бордеров, через FastEthernet0/0, Он собсно и на бэкбоне есть но сделано так потому что в случае какой либо аварии пока жив хоть один бордер и комутаторы на аплинках интернет будет работать и тоннель соотвественно тоже, и я смогу попасть в сеть на работе. В этом и весь смысл Front Door VPN.
дальше чуть подробней по части самого ipsec:
crypto keyring DVTI-KEYRING local-address FastEthernet0/0 pre-shared-key address 0.0.0.0 0.0.0.0 key херасдвавамтрианесеркерткей
Авторизация и обмен ключами - слушать IKE на интерфейсе FastEthernet0/0 который смотрит на бордеры, ну и авторизация по pre shared key - "херасдвавамтрианесеркерткей" по сути чтото вроде пароля - должен быть одинаковым с ообоих сторон, вместо 0.0.0.0 0.0.0.0 можно задать адрес/подсеть для которых этот pre shared key будет применяца, ну а с нулями будет один на всех.
crypto isakmp policy 10 encr aes authentication pre-share ! crypto isakmp policy 20 hash md5 authentication pre-share ! crypto isakmp policy 30 authentication pre-share
Политики шифрования и хеширования для phase 1 ipsec, применяюца последовательно пока чтото не найдеца чтото общее с удаленной стороной. Я в итоге шифрование отключил вообще, отключил бы и хеширование но нельзя, по стандарту если отключено и то и то то включается и то и то что то там по дефолту😊 но это все лучше чем и то и то учитывая что на этой 3724 криптоакселератора нет и даже без шифрования с md5 хешированием она выдает всего мегабит 20 при этом гордо стоя колом/раком - проц в полку и на консоль отвечает с задержкой секунд в 10😊 но нада отдать должное - ни bgp ни ospf при этом не валяца как я ее не мучал😊 Впринципе дело даже не в мегабитах а в задержках - моя работа сводица практически к ssh терминалам 99% - для этого и 1 мегабита достаточно, а вот задержки чем меньше тем лучше, так вот с шифрованием задержки были порядка 6 ms, с отключенным 1.5-2 ms. С aes было еще хуже. Ну и вдобавок у меня по этому тоннелю еще и голос ходит на рабочий телефон дома, впринципе ему эти 6 мс тоже долампочи но почему бы не сократить если можно😊
crypto isakmp profile DVTI-ISAKMP-PROF keyring DVTI-KEYRING match identity address 0.0.0.0 virtual-template 1
Собсно IKE профиль, применяеца потом в итоге в IPSEC профиле, который в свою очередь применяется уже к интерфейсу, самое значимое тут для нас это virtual-template 1 - номер virtual-template интерфейса с которого клонируются настройки реального интерфейса когда соединение установица.
crypto ipsec security-association replay disable
отключаем защиту от replay атак - лишняя нагрузка на процессор - пусть атакуют я всеравно там ниче не шифрую😊
crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac crypto ipsec transform-set ESP-AES-SHA esp-aes esp-sha-hmac crypto ipsec transform-set ESP-NULL-MD5 esp-null esp-md5-hmac crypto ipsec transform-set ESP-NULL-SHA esp-null esp-sha-hmac crypto ipsec transform-set ESP-DES esp-des
Так называемый у кошки transform-set, по сути набор алгоритмов которыми можно шифровать/хешировать траффик, по сути это уже phase 2 ипсека, тут просто то что сложилось в ходе экспериментов😊
crypto ipsec profile IPSEC-PROF set transform-set ESP-DES-MD5 ESP-DES-SHA ESP-AES-SHA ESP-NULL-SHA ESP-NULL-MD5 ESP-DES set isakmp-profile DVTI-ISAKMP-PROF
ipsec профиль - обьединяет pase 1 и pase 2 в одну кучу, и применяется потом уже на virtual-template интерфейсе.
interface Loopback0 ip vrf forwarding backbone ip address 100.64.6.1 255.255.255.224
Петлевой интерфейс - используется в качестве unnumbered на virtula-template и соотвественно на туннельном тоже, поэтому он в vrf backbone, адреса на другом конце туннеля следует брать из этого диапазона.
interface Virtual-Template1 type tunnel ip vrf forwarding backbone ip unnumbered Loopback0 ip mtu 1492 ip tcp adjust-mss 1328 ip ospf network point-to-point ip ospf 2 area 0.0.0.0 tunnel source FastEthernet0/0 tunnel mode ipsec ipv4 tunnel protection ipsec profile IPSEC-PROF hold-queue 256 out
Virtual-template для туннельных интерфейсов, тут собственно применяется ipsec профиль который IPSEC-PROF, так же прописан ospf процесс 2 с area 0 для выяснения адресов на удаленной стороне тоннеля, сам интерфейс в vrf backbone тоже, ну ip unnumbered с петлевого интерфейса, и самое интересное - ip mtu 1492 и ip tcp adjust-mss 1328, их задача убрать фрагментацию, ipsec вносит оверхед, mtu 1492 потому что дома у меня pppoe до провайдера, ip tcp adjust-mss 1328 потому что оно точно пролезит в mtu 1492 и еще потому что я гдето нарыл умную статью по поводу ipsec performance в которой было опытным путем доказано и теоретически обосновано почему 1328 наиболее оптимально в случае ipsec не смотря на то что оно чуть меньше чем можно было бы сделать, если без подробностей то там еще играет роль выравниевание пакета по границам, и 1328 в этом плане золотая середина😊
router ospf 2 vrf backbone router-id 100.64.6.1 log-adjacency-changes passive-interface default no passive-interface Virtual-Template1 distance 210 ! router ospf 1 vrf backbone router-id 91.195.204.250 log-adjacency-changes redistribute connected subnets redistribute bgp 42916 subnets passive-interface default no passive-interface FastEthernet0/1
OSPF процессы - первый работает на туннельных интерфейсах, второй в бэкбоне, redistribute bgp 42916 subnets - какрас редистрибьюция из bgp в ospf, 42916 процесс BGP по номеру автономной системы как это принято. distance 210 в ospf 2 еще одна предосторожность - даже если мы чето всосем и это пересечется с тем что уже есть маршрут не будет замещен потому что distance больше чем у остальных протоколов.
router bgp 42916 bgp router-id 91.193.236.27 bgp log-neighbor-changes neighbor 91.193.236.25 remote-as 42916 neighbor 91.193.236.25 description uplink_to_bgw0 neighbor 91.193.236.30 remote-as 42916 neighbor 91.193.236.30 description uplink_to_bgw1 maximum-paths ibgp 2 ! address-family ipv4 redistribute connected neighbor 91.193.236.25 activate neighbor 91.193.236.25 maximum-prefix 32 50 restart 1 neighbor 91.193.236.30 activate neighbor 91.193.236.30 maximum-prefix 32 50 restart 1 maximum-paths ibgp 2 no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf backbone redistribute connected redistribute ospf 1 vrf backbone match internal external 1 external 2 nssa-external 1 nssa-external 2 neighbor 100.64.6.2 remote-as 42916 neighbor 100.64.6.2 transport connection-mode passive neighbor 100.64.6.2 update-source Loopback0 neighbor 100.64.6.2 activate neighbor 100.64.6.2 next-hop-self neighbor 100.64.6.2 prefix-list no-default-route in neighbor 100.64.6.2 prefix-list no-default-route out neighbor 100.64.6.2 route-map vpn_bgp_out out neighbor 100.64.6.2 maximum-prefix 32 16 restart 10 no synchronization bgp redistribute-internal exit-address-family
BGP часть, 2 сессии к бордерам в глобале - 91.193.236.25 и 91.193.236.30, от них принимаем дефолт, анонсировать ниче не нада так как directly connected и маршруты до нас на них итак есть.
А под address-family ipv4 vrf backbone собственно конфигурация сессии с juniper.
ip prefix-list no-default-route seq 5 permit 0.0.0.0/0 ge 1 ! route-map vpn_bgp_out permit 10 set origin igp !
Ну собсно route-map меняющий origin и префикс-лист описанные выше.
С кошкой вроде все, дальше juniper кусками, ибо у меня там накручено помимо этого еще дохрена чего и все целиком портянка та еще и слишком будет лишним перегружено.
root@J> show configuration interfaces
st0 {
no-traps;
unit 0 {
description IPSEC-VPN_to_AS42916;
family inet {
mtu 1492;
address 100.64.6.2/32 {
destination 100.64.6.1;
}
}
}
}
Это собственно туннельный интерфейс, mtu такой же как с другой стороны, хоть juniper и не рекомендует его менять, а вместо этого крутить mss тем не менее причин для этого не вижу, вдобавок если мту не совпадет то ospf со стороны кошки не поднимеца пока ей не сказать игнорировать сей факт, а у джунипера там иту по дефолту аж 9k, так что учитывая отсутствие внятного обьяснения причин рекомендации не менять со стороны juniper у меня будет так. Так же нет внятного обьяснения ПОЧЕМУ БЛЯТЬ на туннельном интерфейсе отсутствует reverce path filtering как класс? на других есть тут нет - забыли чтоли😊 junos bla bla lba... extensive continuous testing bla bla lba... ага... пиздатая лапша доширак😊
root@J> show configuration routing-options
static {
route 91.193.236.27/32 {
next-hop pp0.0;
no-readvertise;
}
route 172.16.0.0/12 {
discard;
no-readvertise;
}
route 10.0.0.0/8 {
discard;
no-readvertise;
}
route 100.64.0.0/10 {
discard;
no-readvertise;
}
route 169.254.0.0/16 {
discard;
no-readvertise;
}
route 192.168.0.0/16 {
discard;
no-readvertise;
}
route 0.0.0.0/0 next-hop pp0.0;
}
router-id 100.64.5.5;
forwarding-table {
no-indirect-next-hop;
}
instance-import import-from-inst-AS42916-VPN;
root@J> show configuration protocols bgp
traceoptions {
file bgp.log size 4m files 4;
}
hold-time 180;
no-advertise-peer-as;
mtu-discovery;
log-updown;
local-as 42916;
group iBGP {
type internal;
description "AS internal peers";
neighbor 100.64.6.1 {
description "IPSEC VPN to AS42916 on work";
import [ default-route-reject nexthop-peer ];
export [ default-route-reject reject-uplink nexthop-self redistribute-directly-connected redistribute-ospf ];
peer-as 42916;
}
}
BGP в сторону кошки - тут впринципе все стандартно, ну разьве что не обращайте внимания на redistribute-ospf - как я говорил выше у меня там много чего еще, в том числе и оспф никак не связанный с этой кошкой и тоннелем. hold-time я подкрутил до кошкиного значения. Тем не менее так скажем - идеология настройки BGP у juniper немного другая нежели у cisco, и на мой взгляд лучше, тем что на корню отсекает распиздяйство😊 тут нельзя просто взять и влепить пир - нада создать группу, указать тип группы - iBGP/eBGP, и уже только в группе можно сконфигурировать пир, на cisco тоже так можно, и я к этому и пришол со временем, еще за долго до знакомства с junos вообще, ибо на тех же бордерах где куча пиров конфигурация превращаеца в длиннющую портянку, что:
Вот только на циске можно != обязан, поэтому нужна некоторая дисциплина чтоп не допускать такого, а тут хош не хош а придется.
root@J> show configuration policy-options
policy-statement default-route-reject {
from {
route-filter 0.0.0.0/0 exact;
}
then reject;
}
policy-statement import-from-inst-AS42916-VPN {
term instance {
from instance AS42916-VPN;
}
term local {
from protocol local;
then accept;
}
term direct {
from protocol direct;
then accept;
}
then reject;
}
policy-statement nexthop-peer {
then {
next-hop peer-address;
}
}
policy-statement nexthop-self {
then {
next-hop self;
}
}
policy-statement redistribute-directly-connected {
term direct {
from protocol direct;
then accept;
}
term local {
from protocol local;
then accept;
}
}
policy-statement redistribute-ospf {
term ospf {
from protocol ospf;
then accept;
}
}
policy-statement reject-uplink {
term to_pp0.0 {
to interface pp0.0;
then reject;
}
term from_pp0.0 {
from interface pp0.0;
then reject;
}
}
Собственно политики фильтрации анонсов, а так же импорта маршрутов с виртуального роутера. Разжовывать тут вобщем то нефиг - итак все понятно, ну и все есть в документации если че.
root@J> show configuration security ike
respond-bad-spi 5;
proposal AS42916_IKE-PROPOSAL {
authentication-method pre-shared-keys;
dh-group group1;
authentication-algorithm md5;
encryption-algorithm des-cbc;
lifetime-seconds 86400;
}
policy AS42916_IKE-POLICY {
mode main;
proposals AS42916_IKE-PROPOSAL;
pre-shared-key ascii-text "херасдвавамтрианесеркерткей"; ## SECRET-DATA
}
gateway AS42916-BACKBONE_IKE_GW {
ike-policy AS42916_IKE-POLICY;
address 91.193.236.27;
dead-peer-detection {
interval 10;
threshold 2;
}
nat-keepalive 20;
local-identity inet 100.64.6.2;
external-interface pp0;
}
root@J> show configuration security ipsec
vpn-monitor-options {
interval 60;
threshold 3;
}
proposal AS42916_IPSEC-PROPOSAL {
protocol esp;
authentication-algorithm hmac-md5-96;
}
policy AS42916_IPSEC-POLICY {
perfect-forward-secrecy {
keys group1;
}
proposals AS42916_IPSEC-PROPOSAL;
}
vpn AS42916-BACKBONE {
bind-interface st0.0;
df-bit copy;
vpn-monitor {
optimized;
destination-ip 100.64.5.1;
}
ike {
gateway AS42916-BACKBONE_IKE_GW;
no-anti-replay;
ipsec-policy AS42916_IPSEC-POLICY;
}
establish-tunnels immediately;
}
Весь IPSEC - phase 1 и 2 в одном флаконе😊 Тоже особо разжовывать нечего - 91.193.236.27 адрес кошки с которой пытаемся поднять тоннель, st0.0 - тунельный интерфейс описанный выше, establish-tunnels immediately - поднять тоннель сразу не дожидаясь траффика через него - ибо мы и не дождемся туда никакова траффика без маршрутизации по bgp, н разьве что сам bgp туда начнет ломица дабы поднять сессию, но и то не факт если интерфейс в дауне. и как я уже говорил я убрал шифрование, делается это убиранием encryption-algorithm из proposal AS42916_IPSEC-PROPOSAL... неожиданно😊 ну и плюс настроены dead peer detection и vpn монитор. Так же здесь ньюанс касательно фрагментации опять таки - в vpn AS42916-BACKBONE df-bit copy; - копирует dont fragment бит из нешифрованного пакета в уже шифрованный и инкапсулированный, и если тот потом не лезит в mtu шлет icmp источнику пакета с намеком что нужно пакет помельче😊 А по дефолту он сам их начинает нарезать и фрагментировать, а df срезает, тоесть при таком раскладе pmtu discovery работать не будет, да и производительность страдает, поэтому делаем так.
root@J> show configuration security flow
route-change-timeout 60;
tcp-mss {
all-tcp {
mss 1452;
}
ipsec-vpn {
mss 1328;
}
}
Аналог кошкиного ip tcp adjust-mss, тоесть на стадии tcp хэндшейка правит MSS в пакете, тут у жунипера тоже другая идеология, и на мой взгляд малость ебнутая на всю сука башку по сравнению с кошкой - нельзя выставить эту хрень для интерфейса - можно только для всех - то что all-tcp, и для ipsec - то что в ipsec-vpn, а то что у меня там еще 16 гигабитных интерфейсов с нормальным мту в 1500 или с junbo frame в 9000 с 6 подсетями их неебет ниразу - сказали всем 1452 - значит 1452 блять. Я блять канешна понимаю что можно отмазаца сказав это блять ZBF а не роутер, на что скажу я вам ПНХ!!! - по джуниперовской диаграмке прохождения пакета через сей девайс в flow режиме маршрутизация происходит ДО создания сессии, так что mss с интерфейса выхватить можно, да и если его передернуть в packet mode то это сука роутер, чистокровный блять не подкопаешся, более того тока таким он и был до версии junos 9.четотам, пока туда не начали вкорячивать функционал screenos, а с MPLS он и по сей день может работать только в packet-mode, видать при портировании чето пошло не так, возможно отсутствие MPLS в screenos как класса😊 ЧЕМ ДУМАЛИ хуйзнает вобщем.
ладна возвращаясь к значениям - all-tcp mss 1452 потому что как уже говорил - к провайдеру у меня pppoe, у которого mtu 1492, mss соответственно за вычетом ip заголовков получается 1452. ну а про mss для ipsec я уже писал когда комментировал конфигурацию кошки.
root@J> show configuration routing-instances
AS42916-VPN {
instance-type no-forwarding;
interface st0.0;
routing-options {
router-id 100.64.6.2;
}
protocols {
ospf {
export redistribute-directly-connected;
area 0.0.0.0 {
interface st0.0;
}
}
}
}
А это тот самый виртуальный роутер с ospf в сторону кошки. особо разжовывать вобщем то нечего, делаете виртуальный роутер, instance-type no-forwarding потому что роутить мы там ниче не будим, нам нада просто изолировать ospf процесс, засовываете в него туннельный интерфейс который st0.0, ospf как обычно, и экспортируете потом оттуда directly connected маршруты в основную таблицу, иначе не будет работать маршрутизауия через st0.0 в основном таблице так как его там не будет, и вобщем то все. Надо заметить значительно элегантней, проще и понятнее чем чрезжопный route-leaking между vrf'ами ака кусками MPLS'а притянутого зауши в кошках.
Зоны и межзоновые политики расписывать не буду - итак примеров милион, вдобавок пока вы это не сделаете никакой ipsec вас волновать не будет все равно😊 единственное что для ipsec в зоне с внешним интерфейсом необходимо разрешить сервис ike а в зоне с st0.0 протоколы ospf и bgp, иначе не взлетят ipsec/ospf/bgp, примерно так:
root@J> show configuration security zones
security-zone untrust {
screen untrust-screen;
host-inbound-traffic {
system-services {
ike;
}
}
interfaces {
pp0.0;
ge-0/0/3.0;
}
}
security-zone AS42916-VPN {
screen vpn-screen;
host-inbound-traffic {
system-services {
ping;
traceroute;
}
protocols {
ospf;
bgp;
}
}
interfaces {
st0.0;
}
}
позырить ассоциации:
frontdoor-vpn#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.
25 91.193.236.27 217.170.124.98 ACTIVE des md5 psk 1 14:40:59 DN
Connection-id:Engine-id = 25:1(software)
24 91.193.236.27 217.170.124.98 ACTIVE des md5 psk 1 13:51:59 DN
Connection-id:Engine-id = 24:1(software)
frontdoor-vpn#
это phase 1
frontdoor-vpn#show crypto session detail
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, X - IKE Extended Authentication
Interface: Virtual-Access3
Session status: UP-ACTIVE
Peer: 217.170.124.98 port 4500 fvrf: (none) ivrf: (none)
Phase1_id: 100.64.6.2
Desc: (none)
IKE SA: local 91.193.236.27/4500 remote 217.170.124.98/4500 Active
Capabilities:DN connid:25 lifetime:14:40:18
IKE SA: local 91.193.236.27/4500 remote 217.170.124.98/4500 Active
Capabilities:DN connid:24 lifetime:13:51:19
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 7205856 drop 888 life (KB/Sec) 4505494/2776
Outbound: #pkts enc'ed 5749529 drop 0 life (KB/Sec) 4511285/2776
frontdoor-vpn#
это phase 2
обе можно без detail.
show log kmd, если мало то выткаем trace options в security ike/ipsec, по другому никак.
root@J> show security ike security-associations detail IKE peer 91.193.236.27, Index 8220970, Role: Responder, State: UP Initiator cookie: b0a109742b07d571, Responder cookie: 082e78874ec9c94a Exchange type: Main, Authentication method: Pre-shared-keys Local: 10.245.255.2:4500, Remote: 91.193.236.27:4500 Lifetime: Expires in 49543 seconds Peer ike-id: 91.193.236.27 Xauth assigned IP: 0.0.0.0 Algorithms: Authentication : md5 Encryption : des-cbc Pseudo random function: hmac-md5 Traffic statistics: Input bytes : 1368 Output bytes : 552 Input packets: 15 Output packets: 3 Flags: Caller notification sent IPSec security associations: 0 created, 12 deleted Phase 2 negotiations in progress: 0 IKE peer 91.193.236.27, Index 8220971, Role: Initiator, State: UP Initiator cookie: f187e6faaf5a084d, Responder cookie: d1a9b4a8057f4c27 Exchange type: Main, Authentication method: Pre-shared-keys Local: 10.245.255.2:4500, Remote: 91.193.236.27:4500 Lifetime: Expires in 52483 seconds Peer ike-id: 91.193.236.27 Xauth assigned IP: 0.0.0.0 Algorithms: Authentication : md5 Encryption : des-cbc Pseudo random function: hmac-md5 Traffic statistics: Input bytes : 3940 Output bytes : 4784 Input packets: 15 Output packets: 27 Flags: Caller notification sent IPSec security associations: 12 created, 0 deleted Phase 2 negotiations in progress: 0 root@J>
посмотреть phase 1.
root@J> show security ipsec security-associations detail
Virtual-system: root
Local Gateway: 10.245.255.2, Remote Gateway: 91.193.236.27
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
DF-bit: copy
Direction: inbound, SPI: 9bef1366, AUX-SPI: 0
, VPN Monitoring: UP
Hard lifetime: Expires in 2405 seconds
Lifesize Remaining: 4598873 kilobytes
Soft lifetime: Expires in 1790 seconds
Mode: tunnel, Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-md5-96, Encryption: None
Anti-replay service: disabled
Direction: outbound, SPI: 1cbddc78, AUX-SPI: 0
, VPN Monitoring: UP
Hard lifetime: Expires in 2405 seconds
Lifesize Remaining: 4598873 kilobytes
Soft lifetime: Expires in 1790 seconds
Mode: tunnel, Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-md5-96, Encryption: None
Anti-replay service: disabled
root@J>
посмотреть phase 2.
Итак пока я сыграв в русскую рулетку с каким то долбаебом на шоссере вывихнул себе правое плече и получил трещину в ребре благодаря чему появилось время продолжить написание данной писанинки продолжим😊
Cвязка squid + c-icap с моими любимыми шлюхами и блэкджеками (ака контент фильтрация) для себя любимого у меня стояла уже лет 10 как в качестве банерорезки и кеша, После начала позора роскомнадзора со своими блокировками я добавил в эту схему tor для обхода блокировок, и i2pd до кучи - хз зачем но пускай будет. Но я все время искал чем бы заменить сквид с его sslbump ибо для одного юзверя это даже не из пушки по воробьям а чето ближе к ядерной боеголовке. И не особо то находил, а без sslbump все это не имеет смысла, большая часть траффика идет по https, и его необходимо расковыривать для фильтрации баннеров и кеширования тоже. Плюс сквид это тот еще монстр и часто заточить его на чтото что вызывает standart violation без рашпиля (ковыряния в исходниках) бывает невозможно. Не для персонального использования он создан, он может не чхая переварить полгига траффика и тысячи юзверей - я правда проверял - может😊 но при этом иногда заставить его к примеру закешировать чтото что по стандарту кешироваца не должно весьма проблематично.
И тут, недавно, не помню уже с чего вдруг гдето выплыл выплыл у меня в поиске [[Glossary_wwwoffle?|wwwoffle]], который заточен какрас для персонального использования в противовес сквиду, и почемуто я решил на него глянуть, не помню уже почему - мошт просто делать нехер было. И полной неожиданностью оказалось что оно умеет mitm ака sslbump в сквиде типа из коропки, причем уже много лет, и кешировать https тоже умеет, ну и еще кучу всяких standart violation для которых squid нада затачивать что не всегда тривиально, а тут типа все есть. ну и сразу же я решил сие дело посмотреть и опробовать.
Вообще так как все это нужно для 1-2-3 добашних клиентов, требования ко всему этому очень просты:
Оно умеет далеко не все что нужно и списка выше. пойдем с конца:
Остальное все умеет, и кое чего сверху по мелочи. И да - оно маленькое и простое, и кривое😊
В gentoo оказалась довольно древняя версия, поэтому засунул на ее основе последнюю с сайта в свой локальный оверлей и благополучно собрал, и вроде бы все зашибись, кроме одного но - вылез какой то raice condition при генерации фейковых сертификатов, каким то образом получалось что одновременно 2 процесса генерируют пару ключ-сертификат для даного сайта, и один заканьчивает раньше другого, в итоге ключь к самому сертификату не подходит и естественно ничего не работает - бида пичаль.
Врубил логгинг на все - по его строкам нашол процедуру которая генерит сертификаты - в src/certificates.c
static gnutls_certificate_credentials_t GetCredentials(const char *hostname,int server)
посмотрел наискосок - вникать не стал - криво оно конечно реализовано ну да ладна - до того я еще успел нагуглить чтото типа форка wwwoffle-par, чувак долго и много чего там дорабатывал, влоб поставил на проверку - raice отсуствует - тупо скопипастил тело процедуры к себе, сделал патчь, пересобрал с оригинальной версией - raice исчез - алилуя - можно пробовать юзать дальше😊
а дальше, наткнулся на SVN, посмотрел что там, и решил подняца до него - хуже не будет, так родился второй патч😊 Попутно портировал фичу session cookies only из ветки -par, так родился третий патч, ну а четвертый мелкий фикс ворнинга - до кучи😊 Нну и пошло-поехало😊
Собсно сами патчи:
На генте все эти патчи можно сложить в
/etc/portage/patches/net-proxy/wwwoffle
и они применяца автоматом при сборке, ЕСЛИ! в ебилде вызов epatch_user в src_prepare(), а есть он блять не везде.. поэтому гдето это работает а гдето нет. Но есть способ сделать чтоп работало всегда и везде.
Вобщем наигравшись с исходниками и добившись какой-никакой но приемлемой работы я принялся играца с конфигурацией😊 Итак:
Собственно конфигурация wwwoffle находица в
/etc/wwwoffle/wwwoffle.conf
Я уже точно не помню что по дефолту а что я менял так что опишу что посчитаю нужным посекционно так как конциоурация у wwwoffle секционная, есть же документация в конце концов😊 итак:
StartUp
{
bind-ipv4 = 127.0.0.1
bind-ipv6 = none
http-port = 3128
https-port = 3129
wwwoffle-port = 8081
spool-dir = /var/spool/wwwoffle
run-uid = wwwoffle
run-gid = wwwoffle
use-syslog = yes
password = none
max-servers = 16
max-fetch-servers = 1
}
Тут ничего особенного - слушаем все порты на локалхосте так как оно лиш для меня любимого, для меня любимого не на локалхосте там сбоку приставлен socks5 через который я и работаю когда не на локалхосте😊
Собственно сам http прокси живет на 3128 порту, там же и https через метод коннект, тоесть в бравзере прописывается localhost:3128 и фтыкаеца галка юзать его для всех протоколов и на этом все.
Options
{
log-level = info
socket-timeout = 120
dns-timeout = 60
connect-timeout = 30
connect-retry = no
dir-perm = 0755
file-perm = 0644
lock-files = yes
reply-compressed-data = no
reply-chunked-data = yes
#exec-cgi = /local/cgi-bin/*
#exec-cgi = /local/*.cgi
}
OnlineOptions
{
<*://*/*.js?*> request-changed = 10m
<*://*/*.css?*> request-changed = 10m
<*://*/*.json> request-changed = 10m
<*://*/*.css> request-changed = 6w
<*://*/*.css> pragma-no-cache = no
<*://*/*.css> cache-control-no-cache = no
<*://*/*.css> cache-control-max-age-0 = no
<*://*/*.css> request-no-cache = no
<*://*/*.js> request-changed = 6w
<*://*/*.js> pragma-no-cache = no
<*://*/*.js> cache-control-no-cache = no
<*://*/*.js> cache-control-max-age-0 = no
<*://*/*.js> request-no-cache = no
<*://*/*.png> request-changed = 6w
<*://*/*.png> pragma-no-cache = no
<*://*/*.png> cache-control-no-cache = no
<*://*/*.png> cache-control-max-age-0 = no
<*://*/*.png> request-no-cache = no
<*://*/*.jpg> request-changed = 6w
<*://*/*.jpg> pragma-no-cache = no
<*://*/*.jpg> cache-control-no-cache = no
<*://*/*.jpg> cache-control-max-age-0 = no
<*://*/*.jpg> request-no-cache = no
<*://*/*.jpeg> request-changed = 6w
<*://*/*.jpeg> pragma-no-cache = no
<*://*/*.jpeg> cache-control-no-cache = no
<*://*/*.jpeg> cache-control-max-age-0 = no
<*://*/*.jpeg> request-no-cache = no
<*://*/*.gif> request-changed = 6w
<*://*/*.gif> pragma-no-cache = no
<*://*/*.gif> cache-control-no-cache = no
<*://*/*.gif> cache-control-max-age-0 = no
<*://*/*.gif> request-no-cache = no
<*://*/*.ico> request-changed = 6w
<*://*/*.ico> pragma-no-cache = no
<*://*/*.ico> cache-control-no-cache = no
<*://*/*.ico> cache-control-max-age-0 = no
<*://*/*.ico> request-no-cache = no
<*://*/*.swf> request-changed = 6w
<*://*/*.swf> pragma-no-cache = no
<*://*/*.swf> cache-control-no-cache = no
<*://*/*.swf> cache-control-max-age-0 = no
<*://*/*.swf> request-no-cache = no
<*://*/*.pdf> request-changed = 6w
pragma-no-cache = yes
cache-control-no-cache = yes
cache-control-max-age-0 = yes
request-changed = 10m
request-changed-once = yes
request-expired = yes
request-no-cache = no
request-redirection = no
request-conditional = yes
validate-with-etag = no
try-without-password = yes
intr-download-keep = no
intr-download-size = 1
intr-download-percent = 80
timeout-download-keep = no
keep-cache-if-not-found = yes
request-compressed-data = yes
request-chunked-data = yes
}
OfflineOptions
{
pragma-no-cache = yes
cache-control-no-cache = yes
cache-control-max-age-0 = yes
confirm-requests = no
# Dont request any URLs at all when offline.
<*://*/*> dont-request = yes
}
Тут только расскоментировал <*:*/*> dont-request = yes - зачем чтото запрашивать в оффлайне?
SSLOptions
{
enable-caching = yes
quick-key-gen = yes
disallow-cache = *.googlevideo.com:443
allow-tunnel = *.googlevideo.com:443
allow-cache = *:443
}
Вотанон - святой грааль - https mitm ака sslbump в сквиде😊
FetchOptions
{
stylesheets = yes
images = yes
frames = yes
iframes = yes
scripts = no
objects = no
webbug-images = no
icon-images = no
only-same-host-images = no
}
Тут не помню - помоему ниче не трогал, но эта секция какрас отвечает за скачивание запроенных страниц в оффлайне или вручную.
IndexOptions
{
create-history-indexes = yes
cycle-indexes-daily = yes
#### Example ####
# Do index files from /good/ in the barfoo.com domain.
# <*://*.barfoo.com/good/*> list-any = yes
# Don't index any hosts in the barfoo.com domain.
# <*://*.barfoo.com> list-any = no
# Don't index any gif or jpg files in the lasttime index.
# <*://*/*.gif> list-latest = no
# <*://*/*.jpg> list-latest = no
}
Так и не понял что это и зачем вообще, ниче не трогал😊
ModifyHTML
{
enable-modify-html = yes
#site specific fixes
<*://srv.lan> disable-meta-set-cookie = no
<*://*.lostfilm.tv/*> disable-meta-refresh = no
<*://*.lostfilm.tv/*> disable-meta-set-cookie = no
<*://*.google.*/recaptcha/*> disable-meta-set-cookie = no
<*://*.gstatic.com/recaptcha/*> disable-meta-set-cookie = no
<*://*.phoronix.com> disable-meta-set-cookie = no
<*://forum.mtbtula.ru> disable-meta-set-cookie = no
<*://forum.nag.ru> disable-meta-set-cookie = no
<*://*.chipdip.ru> disable-meta-set-cookie = no
<*://*.ripe.net> disable-meta-set-cookie = no
#end site specific fixes
add-cache-info = no
#anchor-cached-begin = <font color="#00B000">
#anchor-cached-end = </font>
#anchor-requested-begin = <font color="#B0B000">
#anchor-requested-end = </font>
#anchor-not-cached-begin = <font color="#B00000">
#anchor-not-cached-end = </font>
disable-script = no
disable-applet = no
disable-style = no
disable-blink = no
disable-marquee = no
disable-flash = no
disable-meta-refresh = yes
disable-meta-refresh-self = yes
disable-meta-set-cookie = yes
disable-dontget-links = yes
replace-dontget-images = yes
replacement-dontget-image = /local/dontget/replacement.gif
replace-webbug-images = yes
replacement-webbug-image = /local/dontget/replacement.gif
disable-dontget-iframes = yes
demoronise-ms-chars = no
fix-mixed-cyrillic = no
disable-animated-gif = no
}
Эта секция позволяет делать некоторые манипуляции непосредственно с контентом страницы.
LocalHost
{
localhost
}
Собсно хост на котором крутица wwwoffle😊
LocalNet
{
srv.lan
megaprovider.ru
icf.org.ru
icf.bofh.ru
*.icf.org.ru
*.icf.bofh.ru
}
Локальные сервера, можно с масками как видим. Они не кешируются вообще и считаются всегда доступными, тоесть даже в оффлайн режиме.
AllowedConnectHosts
{
}
Суда можно вписать имена хостов или ip в [] скобках с которых будет доступ к wwwoffle если он нужен не только на локалхосте, мне такого не нужно так что пусто.
AllowedConnectUsers
{
}
Суда можно вписать юзеров с паролями имеющих доступ к wwwoffle, так как я один мне это тоже нах не нада и потому пусто.
DontCache [ dontcache.list ]
А суда можно вписать урлы которые ненада кешировать, или заинклудить файл с ними сменив скобки с {} на [], в таком случае wwwoffle ищет этот файл в той же директории где и конфигурационный, никакие другие пути не поддерживаются.
Содержимое dontcache.list:
# Don't cache any dynamic pages *://*/*/*?* # Don't cache any archive files. *://*/*.gz *://*/*.tar *://*/*.bz *://*/*.bz2 *://*/*.Z *://*/*.zip *://*/*.rar *://*/*.tgz *://*/*.xz *://*/*.rpm *://*/*.deb # Don't cache any video files. *://*/*.webm *://*/*.mp4 *://*/*.avi *://*/*.ts *://*/*.m3u8 *://*/*/video/* *://*/*/videoplayback *://*.googlevideo.com/* # Don't cache any audio files. *://*/*.mp3 *://*/*.ogg *://*/*.m4s #other misc files *://*/*.torrent # other misc sites *://*.adblockplus.org *://easylist.to *://raw.githubusercontent.com/zpacman/Blockzilla/master/* *://addons.palemoon.org
Собсно тут мы запрещаем кешировать динамику, ато до этого у меня набролось куча закешированных урлов вида http://www.google.ru/url?q=http://wiki.icf.org.ru/2018-07-09_Networking-Blog&sa=U&ved=0ahUKEwiG5ffFnbHcAhVGliwKHZTbCIgQFggnMAM&usg=AOvVaw3UIUcZ1F3FUgGUcx2qYU23 благодаря ебучему гуголу которому сцуко нада следить за мною и куда я жму тоже, и по этому он отдает ссылки с поиска тока редиректом, ну и не тока ебучий гугол ебучий гугол, есть еще много других ебучих сайтов делающих примерно так же, в итоге у меня за неделю с небольшим с полгига такого дерьма закешировалось - пришлось запретить😊 Так же запрещаем кешировать всякие архивы, видео, музыку и прочую такую дрочь. Ну и несколько сайтов с которых нада получать свежак всегда, addblock листы в частности и аддоны бравзера.
DontGet [ adblock-list-justdomains.txt adguarddns-justdomains.txt advblock-justdomains.txt adwarefilters-justdomains.txt antiadblockfilters-justdomains.txt bitblockext-justdomains.txt Blockzilla-justdomains.txt cjx-annoyance-justdomains.txt cntblock-justdomains.txt easylistchina-justdomains.txt easyprivacy-justdomains.txt fanboy-annoyance-justdomains.txt malwaredomains_full-justdomains.txt nocoin-justdomains.txt ruadlist+easylist-justdomains.txt dontget.list ]
А вот и секция DontGet со списками что не нужно запрашивать совсем, иначе говоря зарезать. Списки подгружаюца так же из отдельных файликов. Единственный редактируемый вручную файл тут это dontget.list, остальные генеряца автоматически по различным блэклистам.
собсно содержимое dontget.list:
#favicons
*://*/favicon.ico
<*://*/favicon.ico> replacement = /local/dontget/favicon.ico
*://*/favicon.png
<*://*/favicon.png> replacement = /local/dontget/replacement.png
*://*/*favicon*.png
<*://*/*favicon*.png> replacement = /local/dontget/replacement.png
#annoing sheet
*://*/*/twitter.png
*://node.chathelp.ru/*
*://*.apphb.com/signalr/*
*://*.hypercomments.com/*
*://*.google-analytics.com/*
*://accounts.google.com/*
*://*.google.*/complete/search*
*://*.google.*/logos/doodles/*
<*://*.google.*/logos/doodles/*> replacement = /local/dontget/replacement.gif
*://*.googletagservices.com/*
*://*.googletagmanager.com/*
*://*.google.com/ads/measurement*
*://*.google.*/*/generate_204
*://*google.*/*/client_204?*
*://*.google.*/coop/cse/*
#http://yandex.st/share/share.js
*://api.github.com/_private/browser/*
*://api.rnet.plus/*
*://softdatasystemru.webim.ru/*
*://*.digitaltarget.ru/*
*://*.scorecardresearch.com/*
*://service.maxymiser.net/*
*://*.facebook.com/plugins/*
*://*.smartadcheck.de
*://*.reddit.com/*?!POST:*
*://*.redditmedia.com/gtm*
*://*.redditstatic.com/desktop2x/*.js
*://*.mamydirect.com
*://ssp.rambler.ru/acp/*
*://zdstatic.speedtest.net/*/zdconsent.js
*://*.cdnst.net/javascript/prebid.*.min.js
*://*/ajax/setcookie.php?*
*://*/*/cookie_policy.css
*://*/*/cookieconsent.min.css
*://*/*/*.gif?*
*://*/*/*.svg?*
*://*/*/*.png?*
#annoing js
*://*/*/raven.min.js*
*://*/*/raven.js*
*://*/*/adriver.js*
*://*/*/adriver.core.2.js*
*://*/*/ads.js*
*://*/*/gtm.js*
*://*/*/twemoji.min.js*
#AD
*://ad.3dnews.ru/*
*://ad.mail.ru/*
*://ad.trialsport.ru/*
*://ad.velomania.ru/*
*://ads.adfox.ru/*
*://ads.exoclick.com/*
*://ads.servebom.com/*
*://*.ads.claw.ru/*
*://adservice.google.*/*
*://pagead2.googlesyndication.com/*
*://adx.com.ru/*
*://*.doubleclick.net/*
*://cdn.sstatic.net/clc/clc.ie.min.js
*://cdn.sstatic.net/Js/stub.en.js
*://*.opennet.ru/cgi-bin/opennet/hints.cgi*
*://www.opennet.ru/img/*
*://www.opennet.ru/img/ihor_but.png
*://*.linux.org.ru/adv/*
*://*.linux.org.ru/linuxpiter/*
*://dr.habracdn.net/*/advertise.js*
*://dr.habracdn.net/*/highlight.pack.js*
*://special.habrahabr.ru/api/toplink/*
*://cdnjs.cloudflare.com/*/MathJax.js*
*://cdn.onthe.io/io.js*
*://static.criteo.net/js/*
*://*.amazon-adsystem.com/*
*://*.trafficfactory.biz/*
*://*.advertur.ru/*
*://*.acint.net/*
*://seal.alphassl.com/*
*://*.betsonsport.ru/banners/*
*://robinbob.in
*://static.t-ru.org/templates/*/*lib.min.js
*://*.actionteaser.ru/*
*://*.directadvert.ru/*
#COUNTERS
*://*counter*/*
*://x.cnt.my/*
*://cnt.vvv.ru/*
*://server.comagic.ru/comagic/*
*://tracker.comagic.ru/*
*://collector.githubapp.com/*
*://my-hit.org/scripts/js/metrika/metrika.js*
*://rules.quantcount.com/*.js*
*://*/*counter*?*
<*://*/*/*.js> replacement = /local/dontget/replacement.js
<*://*/*/*.png> replacement = /local/dontget/replacement.png
<*://*/*/*.gif> replacement = /local/dontget/replacement.gif
<*://*/*/*.jpg> replacement = /local/dontget/replacement.gif
<*://*/*/*.svg> replacement = /local/dontget/replacement.gif
location-error = no
Это собственно то что я вручную прирезал ибо нехуй😊 Ну вот не понимаю и не принимаю я изьебов с favicon, с generate_204, с автоподсказками в поиске итд.
Остальное генерица вот этой вот штукой - https://github.com/justdomains/ci немного модифицированной, у нее на выхлопе просто списки доменов, нам же нужны маски понимаемые wwwoffle, ну Patch_justdomains.patch патч тривиальный😊
Патченный convertlists.py и lists.json находяца в /etc/wwwoffle/scripts, запускаеца это дело по крону вот так:
BLOCK_LOGFILE="/tmp/adblock.log"
@daily cd /etc/wwwoffle/scripts && /etc/wwwoffle/scripts/convertlists.py -v /etc/wwwoffle/scripts/lists.json /etc/wwwoffle &>>${BLOCK_LOGFILE} && /usr/bin/wwwoffle -config &>>${BLOCK_LOGFILE}
Содержимое lists.json:
[
{
"name": "RUADlist+EasyList",
"url": "https://easylist-downloads.adblockplus.org/ruadlist+easylist.txt",
"format": "adbp",
"moreinformation": "https://easylist.to/",
"description": "EasyList is the primary filter list that removes most adverts from international webpages, including unwanted frames, images and objects. It is the most popular list used by many ad blockers and forms the basis of over a dozen combination and supplementary filter lists.",
"license-identifier": "GPL3 / CC BY-SA 3.0"
},
{
"name": "EasyPrivacy",
"url": "https://easylist.to/easylist/easyprivacy.txt",
"format": "adbp",
"moreinformation": "https://easylist.to/",
"description": "EasyPrivacy is an optional supplementary filter list that completely removes all forms of tracking from the internet, including web bugs, tracking scripts and information collectors, thereby protecting your personal data.",
"license-identifier": "GPL3 / CC BY-SA 3.0"
},
{
"name": "AntiADblock",
"url": "https://easylist-downloads.adblockplus.org/antiadblockfilters.txt",
"format": "adbp",
"moreinformation": "https://easylist.to/",
"description": "EasyPrivacy is an optional supplementary filter list that completely removes all forms of tracking from the internet, including web bugs, tracking scripts and information collectors, thereby protecting your personal data.",
"license-identifier": "GPL3 / CC BY-SA 3.0"
},
{
"name": "ADVblock",
"url": "https://easylist-downloads.adblockplus.org/advblock.txt",
"format": "adbp",
"moreinformation": "https://easylist.to/",
"description": "EasyPrivacy is an optional supplementary filter list that completely removes all forms of tracking from the internet, including web bugs, tracking scripts and information collectors, thereby protecting your personal data.",
"license-identifier": "GPL3 / CC BY-SA 3.0"
},
{
"name": "CNTblock",
"url": "https://easylist-downloads.adblockplus.org/cntblock.txt",
"format": "adbp",
"moreinformation": "https://easylist.to/",
"description": "EasyPrivacy is an optional supplementary filter list that completely removes all forms of tracking from the internet, including web bugs, tracking scripts and information collectors, thereby protecting your personal data.",
"license-identifier": "GPL3 / CC BY-SA 3.0"
},
{
"name": "BITblockext",
"url": "https://easylist-downloads.adblockplus.org/bitblockext.txt",
"format": "adbp",
"moreinformation": "https://easylist.to/",
"description": "EasyPrivacy is an optional supplementary filter list that completely removes all forms of tracking from the internet, including web bugs, tracking scripts and information collectors, thereby protecting your personal data.",
"license-identifier": "GPL3 / CC BY-SA 3.0"
},
{
"name": "FanBoy-Annoyance",
"url": "https://easylist.to/easylist/fanboy-annoyance.txt",
"format": "adbp",
"moreinformation": "https://easylist.to/",
"description": "EasyPrivacy is an optional supplementary filter list that completely removes all forms of tracking from the internet, including web bugs, tracking scripts and information collectors, thereby protecting your personal data.",
"license-identifier": "GPL3 / CC BY-SA 3.0"
},
{
"name": "easylist-china",
"url": "https://easylist-downloads.adblockplus.org/easylistchina.txt",
"format": "adbp",
"moreinformation": "https://adblockplus.org/ru/subscriptions",
"description": "EasyPrivacy is an optional supplementary filter list that completely removes all forms of tracking from the internet, including web bugs, tracking scripts and information collectors, thereby protecting your personal data.",
"license-identifier": "GPL3 / CC BY-SA 3.0"
},
{
"name": "cjx-annoyance",
"url": "https://raw.githubusercontent.com/cjx82630/cjxlist/master/cjx-annoyance.txt",
"format": "adbp",
"moreinformation": "https://adblockplus.org/ru/subscriptions",
"description": "Specialization: removes self-promotion and privacy protection, ÄÏÐÏÌÎÅÎÉÅ Ë EasyList China",
"license-identifier": "GPL3 / CC BY-SA 3.0"
},
{
"name": "Blockzilla",
"url": "https://raw.githubusercontent.com/zpacman/Blockzilla/master/Blockzilla.txt",
"format": "adbp",
"moreinformation": "https://adblockplus.org/ru/subscriptions",
"description": "Specialization: ads and tracking protection, English",
"license-identifier": "GPL3 / CC BY-SA 3.0"
},
{
"name": "adware-filters",
"url": "https://easylist-downloads.adblockplus.org/adwarefilters.txt",
"format": "adbp",
"moreinformation": "https://adblockplus.org/ru/subscriptions",
"description": "Specialization: blocks ads injected by adware",
"license-identifier": "GPL3 / CC BY-SA 3.0"
},
{
"name": "Malware_Domains",
"url": "https://easylist-downloads.adblockplus.org/malwaredomains_full.txt",
"format": "adbp",
"moreinformation": "https://adblockplus.org/ru/subscriptions",
"description": "Specialization: malware protection",
"license-identifier": "GPL3 / CC BY-SA 3.0"
},
{
"name": "spam404",
"url": "https://raw.githubusercontent.com/Dawsey21/Lists/master/adblock-list.txt",
"format": "adbp",
"moreinformation": "https://adblockplus.org/ru/subscriptions",
"description": "Specialization: blocks scam sites",
"license-identifier": "GPL3 / CC BY-SA 3.0"
},
{
"name": "AdGuard Simplified Domain Names Filter",
"url": "https://filters.adtidy.org/extension/chromium/filters/15.txt",
"format": "adbp",
"outputfile": "adguarddns.txt",
"moreinformation": "https://kb.adguard.com/en/general/adguard-ad-filters",
"description": "A filter composed from several other filters (English filter, Social media filter, Spyware filter, Mobile ads filter, EasyList and EasyPrivacy) and simplified specifically to be better compatible with DNS-level ad blocking. This filter is used by AdGuard DNS servers to block ads.",
"license-identifier": "GPL3"
},
{
"name": "NoCoin Filter List",
"url": "https://raw.githubusercontent.com/hoshsadiq/adblock-nocoin-list/master/hosts.txt",
"format": "hosts",
"outputfile": "nocoin.txt",
"moreinformation": "https://github.com/hoshsadiq/adblock-nocoin-list/",
"description": "Blocking Web Browser Bitcoin Mining",
"license-identifier": "MIT",
"license": "https://github.com/hoshsadiq/adblock-nocoin-list/blob/master/LICENSE"
}
]
тоесть по сути подписки управляюца через ists.json, ну и в DontGet не забыть вписать результирующие файлики.
DontCompress
{
mime-type = image/gif
mime-type = image/jpeg
mime-type = image/png
mime-type = image/tiff
mime-type = video/x-msvideo
mime-type = video/quicktime
mime-type = video/mpeg
mime-type = audio/basic
mime-type = audio/x-wav
mime-type = application/x-dvi
mime-type = application/pdf
mime-type = application/zip
mime-type = application/x-ns-proxy-autoconfig
file-ext = .gz
file-ext = .bz
file-ext = .bz2
file-ext = .Z
file-ext = .zip
file-ext = .tgz
file-ext = .rpm
file-ext = .deb
file-ext = .gif
file-ext = .GIF
file-ext = .jpg
file-ext = .JPG
file-ext = .jpeg
file-ext = .JPEG
file-ext = .png
file-ext = .PNG
}
Что ненада сжимать по майм типам или по расширению файла - картинки, архивы, и все такое, помоему вообще тут ничего не правил.
CensorHeader [ censorheader.list ]
Список заголовков которые нада вырезать, или подменить, и еще несколько фич - читайте мануал кароче😊 тут опять инклудица файл censorheader.list.
Содержимое censorheader.list:
referer-self = yes
referer-self-dir = no
referer-from = no
force-user-agent = no
pass-url-unchanged = no
User-Agent = Mozilla/5.0 (X11; Linux x86_64; rv:3.4) Gecko/20100101 Goanna/20180717 PaleMoon/27.9.4
# allow cookies for specific sites
<*://srv.lan> Set-Cookie = no
<*://srv.lan> Cookie = no
<*://srv.lan> session-cookies-only = no
<*://*.lostfilm.tv> Set-Cookie = no
<*://*.lostfilm.tv> Cookie = no
<*://*.lostfilm.tv> session-cookies-only = no
<*://forum.mtbtula.ru> Set-Cookie = no
<*://forum.mtbtula.ru> Cookie = no
<*://forum.mtbtula.ru> session-cookies-only = no
<*://forum.nag.ru> Set-Cookie = no
<*://forum.nag.ru> Cookie = no
<*://forum.nag.ru> session-cookies-only = no
<*://*.chipdip.ru> Set-Cookie = no
<*://*.chipdip.ru> Cookie = no
<*://*.chipdip.ru> session-cookies-only = no
<*://*.google.*/recaptcha/*> Set-Cookie = no
<*://*.google.*/recaptcha/*> Cookie = no
<*://*.google.*/recaptcha/*> session-cookies-only = yes
<*://*.gstatic.com/recaptcha/*> Set-Cookie = no
<*://*.gstatic.com/recaptcha/*> Cookie = no
<*://*.gstatic.com/recaptcha/*> session-cookies-only = yes
<*://*.phoronix.com> Set-Cookie = no
<*://*.phoronix.com> Cookie = no
<*://*.phoronix.com> session-cookies-only = yes
<*://*.ripe.net> Set-Cookie = no
<*://*.ripe.net> Cookie = no
<*://*.ripe.net> session-cookies-only = yes
<*://*.cvedetails.com> Set-Cookie = no
<*://*.cvedetails.com> Cookie = no
<*://*.cvedetails.com> session-cookies-only = yes
# block all cookies
# Set-Cookie = yes
# Cookie = yes
#allow session cookies only
session-cookies-only = yes
# block other annoing headers
# dont block Access-Control-Allow-Origin - used some video hostings
Via = yes
# Strict-Transport-Security = yes
# X-Frontend = yes
# X-Powered-By = yes
# X-Frame-Options = yes
#github
# X-Fastly-Request-ID = yes
# X-Timer = yes
# X-Cache-Hits = yes
# X-Cache = yes
# X-Served-By = yes
# X-GitHub-Request-Id = yes
# X-Geo-Block-List = yes
# X-XSS-Protection = yes
# X-Content-Type-Options = yes
# Content-Security-Policy = yes
# Access-Control-Expose-Headers = yes
тут мы разрешаем куки на нужные мне сайты.
Proxy [ proxy_header blocked_domains_rkn.list blocked_urls_rkn.list proxy_footer ]
А вот и секция парент прокси, именно тут разруливается что через какой вышестоящий прокси запрашивать, а что на прямую - сердце так сказать механизьма обхода блокировок позорного РКН. прокси указываются раздельно для http и https что не совсем удобно.
proxy_header:
# TOR internal resources #<http://*.onion> proxy = localhost:8888 #<https://*.onion> ssl = localhost:8888 # I2P internal resources <http://*.i2p> proxy = localhost:4444 <https://*.i2p> proxy = localhost:4444
Тут мы указываем parent прокси для внутренних ресурсов TOR и I2P сетей. TOR предоставляет только socks прокси в отличии от I2p, поэтому между ним и wwwoffle стоит промежуточный 3proxy, который умеет преобразовывать socks<=>http/s.
proxy_footer:
<*://*/*> proxy = none <*://*/*> ssl = none
Здесь мы запрещаем все прокси для всех, тоесть если адрес не в I2P/TOR сети и не в списках РКН то идем директом, именно поэтому этот файл должен быть последним в секции.
Генерируется это все вот таким нехитрым скриптом лежащим в /etc/wwwoffle/scripts под названием rkn.sh:
#!/bin/bash
PROXY="localhost:8888"
OUT_ENCODING="koi8-r"
LOGFILE="/tmp/rkn.log"
ERDI_XML="/usr/bin/xmlstarlet"
EIPSET="/usr/sbin/ipset"
TMPFILE=`mktemp`
#TMPFILE="/tmp/dump.xml"
wget --retry-connrefused -O $TMPFILE http://api.antizapret.info/all.php?type=xml
create_ipset()
{
"${EIPSET}" flush $2 2>/dev/null || "${EIPSET}" create $2 $1 maxelem 262144
for f in "$3" "$4"
do
[ -f "$f" ] && {
echo Adding to ipset $2 \($1\) : $f
sort -u "$f" | sed -nre "s/^.+$/add $2 &/p" | "${EIPSET}" -! restore
}
done
return 0
}
ACL=/etc/wwwoffle/blocked_domains_rkn.list
echo "Список доменов нормализованный ($ACL)"
mv $ACL $ACL.bak
"${ERDI_XML}" select -E "$OUT_ENCODING" -T -t -v "/reg:register/content/domain" -n "$TMPFILE" \
|sort \
| uniq \
|idn --quiet --no-tld -- \
|awk -v PROXY=$PROXY '/[0-9]|[a-z]/ {print "<http://" $0 "> proxy = "PROXY;print "<https://" $0 "> ssl = "PROXY;}' \
> $ACL
wc -l <$ACL
ACL=/etc/wwwoffle/blocked_urls_rkn.list
echo "Список url адресов ($ACL)"
mv $ACL $ACL.bak
"${ERDI_XML}" select -E "$OUT_ENCODING" -T -t -v "/reg:register/content/url" -n "$TMPFILE" \
|tr -s "\," "\n" \
|grep -e "^http" \
|sort \
|uniq \
|grep -v "<" \
|grep -v ">" \
|awk -v PROXY=$PROXY '$0 ~ /^https:/ {print "<" $0 "> ssl = "PROXY}; $0 ~ /^http:/ {print "<" $0 "> proxy = "PROXY}' \
> $ACL
wc -l <$ACL
ACL=`mktemp`
echo "Список IP адресов ($ACL)"
"${ERDI_XML}" select -E "$OUT_ENCODING" -T -t -v "/reg:register/content/ip" -n "$TMPFILE" \
|tr "\," "\n" \
|sort -V -u \
> $ACL
wc -l <$ACL
create_ipset hash:net blocked_ip_rkn $ACL
rm $ACL
rm $TMPFILE
Слить чтоп не копипастить дохрена:)
Для работы нужен xmlstarlet и ipset, ну wget,awk,grep,sort и остальное как правило есть везде. Список блокировок выкачивается с https://antizapret.info/ через ихний api, но впрочем их куча еще и на гитхабе и где их ща тока нет😊 ipset нужен не для самой wwwofle а для PBR, который нужен потому что по ip и подсетям wwwoffle выбирать выщестоящие прокси не умеет а РКН не вкурсе такой хуйни, и блочит и по ip и подсетями тоже, причем нехилыми такими типа /15, а потом фсе плачут и пиздец, но хуйвам - прорвемся😊 и поэтому чтоп как то обратабывать эти блоки подсетей и ипишников используется ipset + PBR.
Переменную PROXY нада выставить в адрс и порт того самого промежуточного 3proxy.
запускаеца по крону вот так:
RKN_LOGFILE="/tmp/rkn.log"
@reboot /usr/bin/sleep 30 && /etc/wwwoffle/scripts/rkn.sh &>${RKN_LOGFILE} && /usr/bin/wwwoffle -config &>>${RKN_LOGFILE}
@daily /etc/wwwoffle/scripts/rkn.sh &>${RKN_LOGFILE} && /usr/bin/wwwoffle -config &>>${RKN_LOGFILE}
0 10 * * * /etc/wwwoffle/scripts/rkn.sh &>${RKN_LOGFILE} && /usr/bin/wwwoffle -config &>>${RKN_LOGFILE}
0 18 * * * /etc/wwwoffle/scripts/rkn.sh &>${RKN_LOGFILE} && /usr/bin/wwwoffle -config &>>${RKN_LOGFILE}
@reboot - запуск после перезагрузки, нужен чтоп заполнить ipset, который в ядре и перезагрузку соттветственно не перживает и оказывается пустым.
Purge
{
<*://*/*.css> age = 7w
<*://*/*.js> age = 7w
<*://*/*.json> age = 7w
<*://*/*.png> age = 7w
<*://*/*.jpg> age = 7w
<*://*/*.jpeg> age = 7w
<*://*/*.gif> age = 7w
<*://*/*.ico> age = 7w
<*://*/*.pdf> age = 7w
<*://*/*.swf> age = 7w
use-mtime = no
max-size = -1
min-free = -1
use-url = yes
del-dontget = yes
del-dontcache = yes
age = 4w
compress-age = -1
}
Секция Purge управляет очисткой кеша, здесь определяеца че скока хранить и когда удалять. Тут мы храним всякие картинки пдфки css/js и всю такую хорошо кешируемую дроч 7 недель😊
Ох вроде все по конфигу wwwoffle😊 Вот такая вота партянка по маленькому персональному проксику😊 Вот еще мой полный crontab обслуживающий wwwoffle:
RKN_LOGFILE="/tmp/rkn.log"
BLOCK_LOGFILE="/tmp/adblock.log"
@reboot /usr/bin/sleep 30 && /etc/wwwoffle/scripts/rkn.sh &>${RKN_LOGFILE} && /usr/bin/wwwoffle -config &>>${RKN_LOGFILE}
@daily /etc/wwwoffle/scripts/rkn.sh &>${RKN_LOGFILE} && /usr/bin/wwwoffle -config &>>${RKN_LOGFILE}
0 10 * * * /etc/wwwoffle/scripts/rkn.sh &>${RKN_LOGFILE} && /usr/bin/wwwoffle -config &>>${RKN_LOGFILE}
0 18 * * * /etc/wwwoffle/scripts/rkn.sh &>${RKN_LOGFILE} && /usr/bin/wwwoffle -config &>>${RKN_LOGFILE}
@daily cd /etc/wwwoffle/scripts && /etc/wwwoffle/scripts/convertlists.py -v /etc/wwwoffle/scripts/lists.json /etc/wwwoffle &>${BLOCK_LOGFILE} && /usr/bin/wwwoffle -config &>>${BLOCK_LOGFILE}
@daily /usr/bin/wwwoffle -purge|grep -i del &>/var/log/wwwoffle-purge.log
тоесть тут еще и чистка кеша приплюсовалась.
Основные часто используемые команды 2:
больше мне вроде особо ниче не нужно было, но там есть еще😊
По работе впринципе особых нареканий нет, не смотря на весьма обьемныей списки, к примеру только ркновские домены+урлы 198218 записей, блоклисты 91182 записей, итого под 300 тысяч в сумме переваривает кабудта их нет - запуск, перечитывание конфига, да и просто работа - никаких тормозов не ощющаю как и загрузки cpu, единственное очистка кеша тормозит при этом знатно, точно знаю что из за них - без списков тоже летала. Видимо это из за del-dontget и del-dontcache, но на работу самого прокси это всеравно не влияет никак. Вот тебе и домашний проксик😊 А вот сквид на тех же условиях правда плюсом еще список ip а это еще уже почти 100К записей на данный момент при запуске на парсинге всего этого тупил уже ближе к минуте наверное, тоесть перезапускать или переконфигурить его это был ад и израиль😊 Хотя когда запустица - работал и не чхал😊
Еще оно иногда сегфолтица, хз где и почему но не в управляющем процессе видимо а в порождаемых потоках для обработки соединений, нада будет полазить с дебагером и поправить, но на работе это тоже я не вижу чтоп сказывалось, может падает гдето на закрытии соединения или типа того когда уже все сделано.
UPD - пока дошли руки - отдебажил и поправил это дело попутно написав Как собрать пакет для отладки в Gentoo, а проблема была вот тут:
src/wwwoffles.c:
httpsUrl=ParseRequest(client,&request_head,&request_body);
FreeURL(Url);
Url=CreateURL("https",httpsUrl->hostport,httpsUrl->path,httpsUrl->args,httpsUrl->user,httpsUrl->pass);
FreeURL(httpsUrl);
goto checkrequest;
}
ParseRequest возвращает null если по какой то причине не может распарсить запрос, подозреваю что он не мог потому что по какой то причине соединение обламывалось так как этому предшествовали в логе записи вида
Jul 24 20:30:44 srv wwwoffles[25247]: Nothing to read from the wwwoffle proxy socket; timed out or connection lost?
И парсить ему поэтому вообще тупо нечего😊 И судя по коду это сообщение какрас парсер и выводит😊 А потом мы пытаемся создать какой то Url в строке Url=CreateURL из того что нам вернул ParseRequest, а так как он нихрена не вернул, мы обращаемся к нулевым указателям и получаем сегфолт. Ну и на работе не сказывалось видимо потому что рас соединение обломилось то мы тут ниче собсно поделать то и не можем, правда остается вопрос почему они обламываются но это потом как нибудь, на пенсии повыясняю когда делать нехер будет😊
Решение довольно простое:
diff -ruN wwwoffle-2.9j/src/wwwoffles.c wwwoffle-2.9j-new/src/wwwoffles.c
--- wwwoffle-2.9j/src/wwwoffles.c 2018-07-24 02:12:59.233577980 +0300
+++ wwwoffle-2.9j-new/src/wwwoffles.c 2018-07-24 20:26:41.528637086 +0300
@@ -439,11 +439,19 @@
httpsUrl=ParseRequest(client,&request_head,&request_body);
- FreeURL(Url);
- Url=CreateURL("https",httpsUrl->hostport,httpsUrl->path,httpsUrl->args,httpsUrl->user,httpsUrl->pass);
- FreeURL(httpsUrl);
-
- goto checkrequest;
+ if (httpsUrl) {
+ FreeURL(Url);
+ Url=CreateURL("https",httpsUrl->hostport,httpsUrl->path,httpsUrl->args,httpsUrl->user,httpsUrl->pass);
+ FreeURL(httpsUrl);
+ goto checkrequest;
+ }
+ else {
+ PrintMessage(Warning,"https (SSL) connection error - Request parse error for '%s', '%s', '%s'",Url->hostport, request_head?"HTTP request HEAD":"The HTTP request HEAD was empty",request_body?"HTTP request BODY":"The HTTP request BODY was empty");
+ HTMLMessage(client,500,"WWWOFFLE Server Error",NULL,"ServerError",
+ "error","An https (SSL) connection to specified host (and port) is not established - Cannot parse Request.",
+ NULL);
+ mode=InternalPage; goto internalpage;
+ };
}
else
{
я не вдавался в подробности и логику обработки запросов, а просто сделал проверку что парсер чтото вернул и если нет то кажем стандартную ошибку и вякаем в лог - падения убрались, ну покрайней мере по этой причине, и вроде ниче не сломалось
Впринципе вот эта вот система масок у него тоже очень понравилась. На фоне сквидовских регэкспов, да, они универсальней конечно, но сука с ними головняка в 10 рас больше - то экранируй это экранируй тут чето не срослось там нето тут какой то дебил по русски в листе написал или по китайски или спецсимволов наткал и фсе - оно споткнулось и сразмаху наебнулось, сквид не стартанул, бида пичаль фсе плачут и пиздец😊 А в wwwoffle никаких проблем - все просто как для дебилов и эффективно, и покрывает наверное 90 процентов того что можно накрутить регэкспами в сквиде.
А вот система логгирования это у wwwoffle ад израиль и пиздец😊 и я плачу😊 оно там конечно пишет - что из кеша, что в кеш, и pid процесса, но если много запросов то оно пишет в разнобой и бывает сходу хрен поймеш че к чему, request hit rate/byte hit rate оценить по логам в свете этого тоже та еще задача потому что на 1 запрос куча строк получается, встроенной статистики тоже нет никакой, впринципе не критично, но обидно😊 и с листами тоже нада доработать - оно пишет что попало к примеру в DontGet, но не пишет куда именно в нем, а если он большой то задолбаешся искать, может уровень логгинга поднять и начнет писать, я не пробовал, но я его итак уже приподнял чтоп хотябы видеть что закешировалось что нет что заблочилось. Впрочем сквид тоже не пишет в какой именно регэксп запрос попал - догадайся сам😊
Логгинг я отправил в сислог, у меня syslog-ng, им удобно разруливать такие вещи, примерно вот та:
## WWWOFFLE
destination d_wwwoffled { file("/var/log/wwwoffled.log"); };
filter f_wwwoffled { program("wwwoffled") or program ("wwwoffles"); };
log { source(src); filter(f_wwwoffled); destination(d_wwwoffled); flags(final); };
при этом ротейтить его можно логротейтом без дерганья самого wwwoffle, примерно вот так:
/var/log/wwwoffled.log {
missingok
notifempty
copytruncate
}
По части кеширования можно хоть чтото прикрнуть вот так: 
это наверное гдето за полмесяца, тоесть директория https в которой все что по https уже 2.4 гига, a http всего 213 мегабайт, что лиш подтверждает что на данный момент прокси без mitm в https потеряли актуальность чуть менее чем совсем.
Блять, неужели я наконец то дописал это😊 ладна теперь пойдем дальше:
Который нам нужен как средство обойти блокировки так как выходные ноды у него разбросаны по всему миру. Собсно конфиг:
/etc/tor/torrc:
#
# Minimal torrc so tor will work out of the box
#
User tor
PIDFile /var/run/tor/tor.pid
Log notice syslog
SafeLogging 0
DataDirectory /var/lib/tor/data
AvoidDiskWrites 1
#HardwareAccel 1
#AccelName cryptodev
SOCKSPort 127.0.0.1:9050 NoIPv6Traffic NoIsolateClientAddr NoIsolateSOCKSAuth
SocksTimeout 60
TestSocks 1
DNSPort 127.0.0.2:53 NoIsolateClientAddr
TransPort 127.0.0.1:9049 NoIsolateClientAddr NoPreferIPv6Automap
ControlPort 9051
MaxMemInQueues 256 MB
HashedControlPassword 16:5A0131CDE07B048560AD57E0306553CEDB23743F7DB20C74243C5EE58E
ShutdownWaitLength 1
#OutboundBindAddress 10.32.75.177
#dns resolver automap
AutomapHostsSuffixes .onion
VirtualAddrNetworkIPv4 169.254.0.0/16
AutomapHostsOnResolve 1
#DownloadExtraInfo 0
#EnforceDistinctSubnets 0
#OptimisticData auto
#FetchDirInfoEarly 0
#FetchDirInfoExtraEarly 0
#UseEntryGuards 1
#NumEntryGuards 32
TrackHostExits .
TrackHostExitsExpire 600
#LearnCircuitBuildTimeout 1
#NewCircuitPeriod 10
#CircuitBuildTimeout 30
#CircuitStreamTimeout 10
#CircuitIdleTimeout 3600
#MaxCircuitDirtiness 14400
#MaxClientCircuitsPending 512
#KeepalivePeriod 60
KeepBindCapabilities 0
GeoIPExcludeUnknown 0
ExcludeExitNodes {ru},{??}
#ExcludeExitNodes {ru},{ua},{se},{io},{ro}, \
# 46.105.0.0/16, \
# 46.183.216.0/21, \
# 192.42.116.0/22, \
# 77.247.176.0/21, \
# 185.38.12.0/22, \
# 163.172.0.0/16, \
# 46.166.144.0/21, \
# 216.218.128.0/17, \
# 193.90.0.0/16, \
# 104.233.64.0/18, \
# 62.210.0.0/16, \
# 176.10.96.0/19, \
# 85.248.0.0/16, \
# 137.74.167.224, \
# 94.142.240.0/21, \
# 185.11.180.0/22, \
# 89.31.56.0/21, \
# 151.80.0.0/16, \
# 198.50.200.128/27, \
# 199.249.223.0/24, \
# 94.242.192.0/18, \
# 149.56.229.17, \
# 173.208.128.0/17, \
# 66.180.193.192/27, \
# 199.127.224.0/22, \
# 41.206.160.0/19, \
# 93.174.88.0/21, \
# 69.162.128.0/18, \
# 193.70.0.0/17, \
# 207.244.64.0/18, \
# 37.187.0.0/16, \
# 195.228.0.0/16
ClientOnly 1
Стоит он у меня уже давно, поэтому я всех ньюансов уже не помню, только основные:
Следующие 3 строчки делают еще 1 полезную весчь называемую dns resolver automap, суть в том что при запросе внутреннего ресурса в зоне .onion, вот тот внутренний днс сервер выдает ему левый ип из определенного диапазона, и сопоставляет с той белибердой называемой внутренними адресами в сети тор, благодаря чему, любой софт может обратица к данному ресурсу и не обламаца при днс резольвинге пока живо это сопоставление.
У меня этот автомэппинг работает в связке с tun2socks, это по сути обычный tun интерфейс в системе в который отроучена 169.254.0.0/16, другим концом он цепляеца на socks сервер тора, правда умеет он тока TCP но udp через тор не особо то и нада с его то лагами. ну и плюс форвардинг с локального днс сервера. Таким образом в onion может лазить вообще любой софт, ему не нужен никакой прокси, он просто запрашивает у локального днс сервера адрес, тот лезет на днс сервер тора с той же целью, сервер тора отвечат и сразу делает мэппинг, после чего приложение работает как обычно - все адреса из мэппинга то отроучены в tun, не нужно уметь никакой socks прокси вообще. Таким же образом работает и ipset с заблокированными подсетями, только тут уже даже и мэппинг не нужен - главное отправить траффик на этот адрес через tun интерфейс.
Вот вроде бы и все что я смог вспомнить с тором то.
Вобщем дальше настало время связующего звена между тором и wwwoffle в виде 3proxy в позе http/s=>socks прокси. В случае сквида оно было не нужно, там я через ацл мог сразу отправить запрос через тот самый tun2socks интерфейс и не парица - оно просто работало, wwwoffle так не может, и нужно промежуточное звено, тоже долго искал... чучуть поработал с tinyproxy который пришлось пропатчить на предмет поддержки socks, но потом всетаки остановился на [Glossary_3proxy|3proxy]], он маленький, дохера чего может, можно сделать кучу разных проксей для разных задач и все в рамках одной софтины, потому остановился на нем.
Тут так просто сходу 2 кнопками нихера не выйдет - придеца вдумчиво читать документацию😊 порядок команд имеет значение, порядок ACL тоже, и еще куча ньюансов, но тем не менее все работает😊 Неожиданностью оказалось что он тоже умеет mitm aka sslbump для https, правда не понятно нахуя😊 может для фильтрации тока, кешировать к сожалению он не умеет впринципе, зато умеет проксировать http/https,socks4/5/ftp/pop/smtp и даже просто tcp, естественно умеет http/s=>socks и наоборот тоже, иначе бы я его не поставил😊 Расширяеца плагинами, и судя по сайту довольно активно пилица. Эдакий маленький кобайн который может дохрена всего, размером всего в полмегабайта. Умел бы он кешировать думаю надобность в wwwoffle бы отпала, а он бы точно стал паравозиком который смог😊 но, неумеет.
Тут не только то что нам нада для решения задачи, но и кое что еще сбоку - socks->http прокси, я через него же подключаюсь с работы, хоть я и работаю в ISP, и могу обойти эти блокировки по другому так как все железо подконтрольно мне в том числе и то что эти блокировки реализует, да и можно тупо подключица выше этих блокираторов, но это ломает стройность операторского ядра сети и поэтому я не хочу так делать, а юзаю домашний прокси с работы через socks, заодно и банерорезку получаю.
ebuild в gentoo кривоватый, не в плане что не собираеца, а в плане что тупо ставит бинарники и документацию и все - никаких init скриптов и дефолтных конфигов нет, никакого отдельного пользователя для процесса тоже нет, пришлось создавать вручную, все директории тоже вручную, в самом архиве есть init скрипт но пришлось подправить пути и еще там по мелочи. но это все мелочи😊
итак конфиг:
config /etc/3proxy/3proxy.cfg setgid 990 setuid 999 daemon internal 10.32.75.177 external 127.0.0.1 nserver 127.0.0.1 #nscache 1024 fakeresolve timeouts 1 5 30 60 180 1800 15 60 log /var/log/3proxy/3proxy.log D logformat "L%d-%m-%Y %H:%M:%S.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T" archiver gz /bin/gzip %F rotate 30 users $/etc/3proxy/.proxyauth ############### Private HTTP -> SOCKS, used to link wwwoffle to socks servers in tor maxconn 64 auth iponly allow * 127.0.0.0/8 * * * parent 1000 socks5+ 127.0.0.1 9050 allow * 127.0.0.0/8 * * HTTP,HTTPS proxy -a -n -p8888 -i127.0.0.1 -e127.0.0.1 flush ############### Public SOCKS -> HTTP service - personal use on my work to obey rkn blocks for example maxconn 64 #auth iponly strong auth iponly allow * 91.193.236.34 * 80,8080 parent 1000 http 127.0.0.1 3128 allow * 91.193.236.34 * 443 parent 1000 connect+ 127.0.0.1 3128 socks flush ############### Test auth #auth strong #maxconn 64 #allow root #socks -u2 #flush pidfile /run/3proxy.pid
ну тут впринципе все понятно😊
дальше собственно кусок который какрас реализует http->socks между wwwoffle и тором:
Вот впринципе и все, запускаеца он путем 3proxy /path/to/config😊 по сигналу USR1 он толи перезапускаеца толи конфиг перечитывает толи и то и другое - хз. Так же там еще в конфиге откомментированная секция c SOCKS->HTTP прокси который я юзаю с работы, принцип вобщем то тот же только там 2 парента, один для http другой для https и соотвествующие ACL'и к ним выбирающие их по dst port, сделано так потому что для http и https различный тип парентов что впринципе логично, так как использование https несколько отличается от http, если вам данный функционал не нужен то просто удалите эту секцию.
Поправленный init скрипт - положить в /etc/init.d/3proxy:
#!/bin/sh
#
# chkconfig: 2345 20 80
# description: 3proxy tiny proxy server
#
#
#
#
PID="/run/3proxy.pid"
if [ ! -f $PID ]; then
touch $PID && chown proxy3.proxy3 $PID
fi
case "$1" in
start)
echo Starting 3Proxy
/usr/bin/3proxy /etc/3proxy/3proxy.cfg
RETVAL=$?
echo
[ $RETVAL ]
;;
stop)
echo Stopping 3Proxy
if [ $PID ]; then
/bin/kill `cat $PID`
else
/usr/bin/killall 3proxy
fi
RETVAL=$?
echo
[ $RETVAL ]
;;
restart|reload)
echo Reloading 3Proxy
if [ $PID ]; then
/bin/kill -s USR1 `cat $PID`
else
/usr/bin/killall -s USR1 3proxy
fi
;;
*)
echo Usage: $0 "{start|stop|restart}"
exit 1
esac
exit 0
ну и в gentoo сделать rc-update add 3proxy default. По работе могу сказать покашто тока одно - его не видно и не слышно - настроил(поебался) и забыл😊 никаких глюков, падений и проблем небыло.
На данный момент должна работать wwwofle <=> внешний мир, и связка wwwoffle <=http/s=> 3proxy <=socks5=> tor <=> внешний мир для всего что есть в proxy_header и в ркновских блоклистах😊 если нет то проверяем покомпонентно тем же браузером начиная с tor и движемся в сторону wwwofle.
Если вам это не удаеца и вы не можете идентифицировать неработающий компонент, если вы не знаете как использовать tcpdump, как телнетом запросить страничку по http, или не понимаете разницу между socks http и https протоколами хотя бы отдаленно, если не знаете как применить патч и не можете узнать, или не дай бог не отличаете клиента от сервера или не можете читать по английски недайбоже то тушим свет и расходимся, вам на хабр настраивать прокси для телеграмов а не такие связки лепить. Это даже еще не половина😊 Ко мне с вопросами пачемунипашет приставать даже не пытайтесь.
Ладна, поехали дальше, тепень нам нужен способ обойти блокировки по ip, тоесть все то что в том ипсете который формируется скриптом script_wwwoffle_rkn.sh нужно как то отправить через tor, и есть такой способ - tun2socks из пакета badvpn.
tun2socks собсно одним концом представляет из себя обычный сетевой tun интерфейс, с одним ограничением - не умеет udp, там есть какаято примочка для этого но мне не нужна и я не вникал, так что у меня не уммет😊 а другим концом он цепляется на socks сервер, таким образом любое приложение может работать через socks по tcp при условии что траффик идет через данный интерфейс.
Так как у меня генту, готовые конфиги для нее, интерфейс собсно поднимается штатно, ну или почти штатно - через netifrc. ставица emerge net-vpn/badvpn, так как мне нужен только tun2socks я оставил тока tun2socks use flag, ато там еще до кучи поставица какой то ихний сервир, какой то скриптовый интерпретатор для конфигрурации сети и еще всякая хрень - зачем засорять систему???
/etc/conf.d/net
modules="!system !iwconfig !wpa_supplicant !l2tp"
dns_domain_lo="lan"
config_enp2s0f1="10.32.75.177/30"
routes_enp2s0f1="default via 10.32.75.178"
config_tun2sock0="100.64.0.1 netmask 255.255.255.252 brd 100.64.0.3"
rules_tun2sock0="from 100.64.0.0/30 table tun2socks
fwmark 10 lookup tun2socks"
routes_tun2sock0="default via 100.64.0.2 table tun2socks
169.254.0.0/16 via 100.64.0.2 dev tun2sock0"
preup() {
if [ "${IFACE}" == "tun2sock0" ]; then
ip tuntap add dev tun2sock0 mode tun
badvpn-tun2socks --tundev tun2sock0 --netif-ipaddr 100.64.0.2 --netif-netmask 255.255.255.252 --socks-server-addr 127.0.0.1:9050 --loglevel 3 --syslog-facility local &
sysctl net.ipv4.conf.${IFACE}.rp_filter=0
fi
}
postdown() {
if [ "${IFACE}" == "tun2sock0" ]; then
kill `pidof badvpn-tun2socks` && ip tuntap del dev tun2sock0 mode tun
fi
}
Ну тут собсно config_enp2s0f1 это обычный сетевой интерфейс машины, badvpn-tun2socks - так называется бинарник поднимающий tun2socks интефейс, preup()/postdown() - стандартные процедуры вызываемые при поднятии/после опускания интерфейса в gentoo.
так же нада добавить таблицу маршрутизации tun2socks в /etc/iproute2/rt_tables чтоп к ней можно было обращаца по имени, вприсываем туда в конец 1 tun2socks к примеру, чтоп было примерно так:
# # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep 1 tun2socks
Таблица маршрутизации после поднятия интерфейса должна выглядеть примерно так за исключением того что к делу не относица:
#ip rule list 0: from all lookup local 32764: from all fwmark 0xa lookup tun2socks 32765: from 100.64.0.0/30 lookup tun2socks 32766: from all lookup main 32767: from all lookup default #ip route show table tun2socks default via 100.64.0.2 dev tun2sock0 metric 7 #
Теперь у нас есть через чего мы можем тупо отправить tcp траффик через socks, осталось дело за выбором че отправлять че нет, делается это штатным фаерволом, у меня вот так:
#!/bin/bash
IPT="/sbin/iptables"
IPSET="/usr/sbin/ipset"
TABLES=`cat /proc/net/ip_tables_names 2>/dev/null`
for i in $TABLES;
do
$IPT -t $i -F
done
for i in $TABLES;
do
$IPT -t $i -X
done.
if ! $IPSET list blocked_ip_rkn &>/dev/null ; then.
$IPSET flush blocked_ip_rkn 2>/dev/null || $IPSET create blocked_ip_rkn hash:net maxelem 262144
fi
$IPT -t mangle -A OUTPUT -p tcp -m multiport --dports 443,80 -m owner --uid-owner wwwoffle --gid-owner wwwoffle -m set --match-set blocked_ip_rkn dst -j MARK --set-mark 10
# SOCKS ACCESS
$IPT -N 3proxy_access
$IPT -A 3proxy_access -s 91.193.236.34 -j ACCEPT
$IPT -A 3proxy_access -j REJECT.
$IPT -A INPUT ! -i lo -p tcp --dport 1080 -j 3proxy_access
в Gentoo он у меня лежит в /etc/local.d/firewall.start благодаря чему запускается автоматически. В начале идет очистка всех правил, потом проверка что ipset blocked_ip_rkn есть, потому что если его нет то правило iptables не добавица, ну и в конце там еще socks 3proxy зафаерволен который я на работе юзаю. собсно нас тут интересует правило iptables:
$IPT -t mangle -A OUTPUT -p tcp -m multiport --dports 443,80 -m owner --uid-owner wwwoffle --gid-owner wwwoffle -m set --match-set blocked_ip_rkn dst -j MARK --set-mark 10 - именно оно ставит метку 10 благодаря которой потом траффик принудительно маршрутизируется через tun2socks а не через дефолт, разберем подробней:
Впринципе, после всего этого уже любой запрос через wwwoffle на любой адрес из ipset blocked_ip_rkn должен пойти через socks сервер tor, ну к примеру:
┌────[root@srv: 2018-07-26 20:15:55 ~] └─># ipset list blocked_ip_rkn|tail 104.27.176.3 185.106.140.52 95.211.113.169 88.208.50.182 23.253.135.112 78.140.141.120 5.45.70.120 81.94.208.16 94.242.241.63 104.18.44.77 ┌────[root@srv: 2018-07-26 20:15:58 ~] └─># tcpdump -n -i tun2sock0 dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun2sock0, link-type RAW (Raw IP), capture size 262144 bytes 20:16:10.710511 IP 10.32.75.177.34194 > 104.18.44.77.80: Flags [SEW], seq 3424285378, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0 20:16:10.710606 IP 104.18.44.77.80 > 10.32.75.177.34194: Flags [S.], seq 19638, ack 3424285379, win 5840, options [mss 1460], length 0 20:16:10.710697 IP 10.32.75.177.34194 > 104.18.44.77.80: Flags [.], ack 1, win 29200, length 0 20:16:10.710859 IP 10.32.75.177.34194 > 104.18.44.77.80: Flags [P.], seq 1:420, ack 1, win 29200, length 419: HTTP: GET / HTTP/1.1 20:16:10.835219 IP 104.18.44.77.80 > 10.32.75.177.34194: Flags [.], ack 420, win 5421, length 0 20:16:11.176441 IP 104.18.44.77.80 > 10.32.75.177.34194: Flags [.], seq 1:1461, ack 420, win 5421, length 1460: HTTP: HTTP/1.1 403 Forbidden 20:16:11.176489 IP 10.32.75.177.34194 > 104.18.44.77.80: Flags [.], ack 1461, win 32120, length 0 20:16:11.176562 IP 104.18.44.77.80 > 10.32.75.177.34194: Flags [P.], seq 1461:1764, ack 420, win 5421, length 303: HTTP 20:16:11.176579 IP 10.32.75.177.34194 > 104.18.44.77.80: Flags [.], ack 1764, win 35040, length 0 20:16:11.586123 IP 104.18.44.77.80 > 10.32.75.177.34194: Flags [F.], seq 1764, ack 420, win 5421, length 0 20:16:11.586949 IP 10.32.75.177.34194 > 104.18.44.77.80: Flags [F.], seq 420, ack 1765, win 35040, length 0 20:16:11.587020 IP 104.18.44.77.80 > 10.32.75.177.34194: Flags [.], ack 421, win 5420, length 0 20:16:11.643978 IP 10.32.75.177.34204 > 104.18.44.77.80: Flags [SEW], seq 3817387905, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0 20:16:11.644092 IP 104.18.44.77.80 > 10.32.75.177.34204: Flags [S.], seq 25566, ack 3817387906, win 5840, options [mss 1460], length 0 20:16:11.644183 IP 10.32.75.177.34204 > 104.18.44.77.80: Flags [.], ack 1, win 29200, length 0 20:16:11.644315 IP 10.32.75.177.34204 > 104.18.44.77.80: Flags [P.], seq 1:493, ack 1, win 29200, length 492: HTTP: GET /cdn-cgi/styles/cf.errors.css HTTP/1.1 20:16:11.644406 IP 10.32.75.177.34208 > 104.18.44.77.80: Flags [SEW], seq 1368472906, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0 20:16:11.644437 IP 104.18.44.77.80 > 10.32.75.177.34208: Flags [S.], seq 31494, ack 1368472907, win 5840, options [mss 1460], length 0 20:16:11.644458 IP 10.32.75.177.34208 > 104.18.44.77.80: Flags [.], ack 1, win 29200, length 0 20:16:11.644609 IP 10.32.75.177.34208 > 104.18.44.77.80: Flags [P.], seq 1:478, ack 1, win 29200, length 477: HTTP: GET /cdn-cgi/scripts/zepto.min.js HTTP/1.1 20:16:11.659409 IP 10.32.75.177.34212 > 104.18.44.77.80: Flags [SEW], seq 2218674855, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0 20:16:11.659472 IP 104.18.44.77.80 > 10.32.75.177.34212: Flags [S.], seq 37422, ack 2218674856, win 5840, options [mss 1460], length 0 20:16:11.659518 IP 10.32.75.177.34212 > 104.18.44.77.80: Flags [.], ack 1, win 29200, length 0 20:16:11.659744 IP 10.32.75.177.34212 > 104.18.44.77.80: Flags [P.], seq 1:478, ack 1, win 29200, length 477: HTTP: GET /cdn-cgi/scripts/cf.common.js HTTP/1.1 20:16:11.837011 IP 104.18.44.77.80 > 10.32.75.177.34212: Flags [.], ack 478, win 5363, length 0 20:16:11.837054 IP 104.18.44.77.80 > 10.32.75.177.34208: Flags [.], ack 478, win 5363, length 0 20:16:11.837062 IP 104.18.44.77.80 > 10.32.75.177.34204: Flags [.], ack 493, win 5348, length 0 20:16:12.046699 IP 104.18.44.77.80 > 10.32.75.177.34208: Flags [.], seq 1:1461, ack 478, win 5363, length 1460: HTTP: HTTP/1.1 200 OK 20:16:12.046754 IP 10.32.75.177.34208 > 104.18.44.77.80: Flags [.], ack 1461, win 32120, length 0 20:16:12.046763 IP 104.18.44.77.80 > 10.32.75.177.34208: Flags [.], seq 1461:2921, ack 478, win 5363, length 1460: HTTP 20:16:12.046806 IP 10.32.75.177.34208 > 104.18.44.77.80: Flags [.], ack 2921, win 35040, length 0 20:16:12.046904 IP 104.18.44.77.80 > 10.32.75.177.34208: Flags [P.], seq 2921:3487, ack 478, win 5363, length 566: HTTP 20:16:12.046957 IP 10.32.75.177.34208 > 104.18.44.77.80: Flags [.], ack 3487, win 37960, length 0 20:16:12.094814 IP 104.18.44.77.80 > 10.32.75.177.34208: Flags [.], seq 3487:4947, ack 478, win 5363, length 1460: HTTP 20:16:12.094856 IP 10.32.75.177.34208 > 104.18.44.77.80: Flags [.], ack 4947, win 40880, length 0 20:16:12.094880 IP 104.18.44.77.80 > 10.32.75.177.34208: Flags [.], seq 4947:6407, ack 478, win 5363, length 1460: HTTP 20:16:12.094890 IP 10.32.75.177.34208 > 104.18.44.77.80: Flags [.], ack 6407, win 43800, length 0 20:16:12.094919 IP 104.18.44.77.80 > 10.32.75.177.34208: Flags [P.], seq 6407:7471, ack 478, win 5363, length 1064: HTTP 20:16:12.094946 IP 10.32.75.177.34208 > 104.18.44.77.80: Flags [.], ack 7471, win 46720, length 0 20:16:12.107706 IP 104.18.44.77.80 > 10.32.75.177.34208: Flags [.], seq 7471:8931, ack 478, win 5363, length 1460: HTTP 20:16:12.107759 IP 10.32.75.177.34208 > 104.18.44.77.80: Flags [.], ack 8931, win 49640, length 0 20:16:12.107920 IP 104.18.44.77.80 > 10.32.75.177.34208: Flags [P.], seq 8931:9793, ack 478, win 5363, length 862: HTTP 20:16:12.107950 IP 10.32.75.177.34208 > 104.18.44.77.80: Flags [.], ack 9793, win 52560, length 0 20:16:12.178175 IP 104.18.44.77.80 > 10.32.75.177.34204: Flags [.], seq 1:1461, ack 493, win 5348, length 1460: HTTP: HTTP/1.1 200 OK 20:16:12.178214 IP 10.32.75.177.34204 > 104.18.44.77.80: Flags [.], ack 1461, win 32120, length 0 20:16:12.178221 IP 104.18.44.77.80 > 10.32.75.177.34204: Flags [.], seq 1461:2921, ack 493, win 5348, length 1460: HTTP 20:16:12.178231 IP 10.32.75.177.34204 > 104.18.44.77.80: Flags [.], ack 2921, win 35040, length 0 20:16:12.178250 IP 104.18.44.77.80 > 10.32.75.177.34204: Flags [P.], seq 2921:3487, ack 493, win 5348, length 566: HTTP 20:16:12.178261 IP 10.32.75.177.34204 > 104.18.44.77.80: Flags [.], ack 3487, win 37960, length 0 20:16:12.215356 IP 104.18.44.77.80 > 10.32.75.177.34204: Flags [.], seq 3487:4947, ack 493, win 5348, length 1460: HTTP 20:16:12.215385 IP 10.32.75.177.34204 > 104.18.44.77.80: Flags [.], ack 4947, win 40880, length 0 20:16:12.215461 IP 104.18.44.77.80 > 10.32.75.177.34204: Flags [P.], seq 4947:5319, ack 493, win 5348, length 372: HTTP 20:16:12.215478 IP 10.32.75.177.34204 > 104.18.44.77.80: Flags [.], ack 5319, win 43800, length 0 20:16:12.276385 IP 104.18.44.77.80 > 10.32.75.177.34212: Flags [.], seq 1:1461, ack 478, win 5363, length 1460: HTTP: HTTP/1.1 200 OK 20:16:12.276422 IP 10.32.75.177.34212 > 104.18.44.77.80: Flags [.], ack 1461, win 32120, length 0 20:16:12.276474 IP 104.18.44.77.80 > 10.32.75.177.34212: Flags [P.], seq 1461:2441, ack 478, win 5363, length 980: HTTP 20:16:12.276489 IP 10.32.75.177.34212 > 104.18.44.77.80: Flags [.], ack 2441, win 35040, length 0 20:16:12.587898 IP 104.18.44.77.80 > 10.32.75.177.34212: Flags [F.], seq 2441, ack 478, win 5363, length 0 20:16:12.587947 IP 104.18.44.77.80 > 10.32.75.177.34204: Flags [F.], seq 5319, ack 493, win 5348, length 0 20:16:12.587963 IP 104.18.44.77.80 > 10.32.75.177.34208: Flags [F.], seq 9793, ack 478, win 5363, length 0 20:16:12.590500 IP 10.32.75.177.34212 > 104.18.44.77.80: Flags [F.], seq 478, ack 2442, win 35040, length 0 20:16:12.590563 IP 104.18.44.77.80 > 10.32.75.177.34212: Flags [.], ack 479, win 5362, length 0 20:16:12.590690 IP 10.32.75.177.34204 > 104.18.44.77.80: Flags [F.], seq 493, ack 5320, win 43800, length 0 20:16:12.590715 IP 104.18.44.77.80 > 10.32.75.177.34204: Flags [.], ack 494, win 5347, length 0 20:16:12.598426 IP 10.32.75.177.34208 > 104.18.44.77.80: Flags [F.], seq 478, ack 9794, win 52560, length 0 20:16:12.598485 IP 104.18.44.77.80 > 10.32.75.177.34208: Flags [.], ack 479, win 5362, length 0 ^C 66 packets captured 66 packets received by filter 0 packets dropped by kernel ┌────[root@srv: 2018-07-26 20:16:16 ~] └─>#
Это я вбил 104.18.44.77 в адресную строку бравзера - фсе работает😊 Оказалось это адрес одной из нод Cloudflare и получается заблокировали всех кто на нее попадет😊 Впринципе мэппинг зоны .onion в Tor тоже должен работать, если прописать днс сервером 127.0.0.2 в /etc/resolv.conf то можно проверить вот так к примеру:
┌────[root@srv: 2018-07-26 21:00:41 ~] └─># host 3g2upl4pq6kufc4m.onion 3g2upl4pq6kufc4m.onion has address 169.254.211.122 ┌────[root@srv: 2018-07-26 21:01:11 ~] └─>#
Тоесть нам выдали ip для 3g2upl4pq6kufc4m.onion из диапазона для мэппинга в Tor 169.254.0.0/16, вбиваем в браузер https://3g2upl4pq6kufc4m.onion/ и наблюдаем следующее на tun2socks интерфейсе:
┌────[root@srv: 2018-07-26 21:13:34 ~] └─># tcpdump -n -i tun2sock0 dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun2sock0, link-type RAW (Raw IP), capture size 262144 bytes 21:13:38.143806 IP 100.64.0.1.22306 > 169.254.211.122.443: Flags [SEW], seq 3827395173, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0 21:13:38.143860 IP 169.254.211.122.443 > 100.64.0.1.22306: Flags [S.], seq 395346, ack 3827395174, win 5840, options [mss 1460], length 0 21:13:38.143940 IP 100.64.0.1.22306 > 169.254.211.122.443: Flags [.], ack 1, win 29200, length 0 21:13:38.144127 IP 100.64.0.1.22306 > 169.254.211.122.443: Flags [P.], seq 1:270, ack 1, win 29200, length 269 21:13:38.214322 IP 169.254.211.122.443 > 100.64.0.1.22306: Flags [.], ack 270, win 5571, length 0 21:13:41.510642 IP 169.254.211.122.443 > 100.64.0.1.22306: Flags [.], seq 1:1461, ack 270, win 5571, length 1460 21:13:41.510708 IP 100.64.0.1.22306 > 169.254.211.122.443: Flags [.], ack 1461, win 32120, length 0 21:13:41.510719 IP 169.254.211.122.443 > 100.64.0.1.22306: Flags [.], seq 1461:2921, ack 270, win 5571, length 1460 21:13:41.510738 IP 100.64.0.1.22306 > 169.254.211.122.443: Flags [.], ack 2921, win 35040, length 0 21:13:41.510772 IP 169.254.211.122.443 > 100.64.0.1.22306: Flags [P.], seq 2921:3487, ack 270, win 5571, length 566 21:13:41.510787 IP 100.64.0.1.22306 > 169.254.211.122.443: Flags [.], ack 3487, win 37960, length 0 21:13:41.574820 IP 169.254.211.122.443 > 100.64.0.1.22306: Flags [P.], seq 3487:4256, ack 270, win 5571, length 769 21:13:41.574878 IP 100.64.0.1.22306 > 169.254.211.122.443: Flags [.], ack 4256, win 40880, length 0 21:13:41.576256 IP 100.64.0.1.22306 > 169.254.211.122.443: Flags [P.], seq 270:345, ack 4256, win 40880, length 75 21:13:41.717564 IP 169.254.211.122.443 > 100.64.0.1.22306: Flags [.], ack 345, win 5496, length 0 21:13:41.717648 IP 100.64.0.1.22306 > 169.254.211.122.443: Flags [P.], seq 345:396, ack 4256, win 40880, length 51 21:13:41.954137 IP 100.64.0.1.22306 > 169.254.211.122.443: Flags [P.], seq 345:396, ack 4256, win 40880, length 51 21:13:41.954235 IP 169.254.211.122.443 > 100.64.0.1.22306: Flags [.], ack 396, win 5445, length 0 21:13:42.087069 IP 169.254.211.122.443 > 100.64.0.1.22306: Flags [P.], seq 4256:4530, ack 396, win 5445, length 274 21:13:42.088590 IP 100.64.0.1.22306 > 169.254.211.122.443: Flags [P.], seq 396:865, ack 4530, win 43800, length 469 21:13:42.217913 IP 169.254.211.122.443 > 100.64.0.1.22306: Flags [.], ack 865, win 4976, length 0 21:13:42.566856 IP 169.254.211.122.443 > 100.64.0.1.22306: Flags [.], seq 4530:5990, ack 865, win 4976, length 1460 21:13:42.614098 IP 100.64.0.1.22306 > 169.254.211.122.443: Flags [.], ack 5990, win 46720, length 0 21:13:42.614148 IP 169.254.211.122.443 > 100.64.0.1.22306: Flags [P.], seq 5990:7423, ack 865, win 4976, length 1433 21:13:42.614163 IP 100.64.0.1.22306 > 169.254.211.122.443: Flags [.], ack 7423, win 49640, length 0 21:13:42.626013 IP 100.64.0.1.22306 > 169.254.211.122.443: Flags [P.], seq 865:896, ack 7423, win 49640, length 31 21:13:42.626060 IP 169.254.211.122.443 > 100.64.0.1.22306: Flags [R.], seq 7423, ack 896, win 5840, length 0 21:13:43.153681 IP 100.64.0.1.22334 > 169.254.211.122.443: Flags [SEW], seq 1831618165, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0 21:13:43.153773 IP 169.254.211.122.443 > 100.64.0.1.22334: Flags [S.], seq 408169, ack 1831618166, win 5840, options [mss 1460], length 0 21:13:43.153858 IP 100.64.0.1.22334 > 169.254.211.122.443: Flags [.], ack 1, win 29200, length 0 21:13:43.154077 IP 100.64.0.1.22334 > 169.254.211.122.443: Flags [P.], seq 1:270, ack 1, win 29200, length 269 21:13:43.218258 IP 169.254.211.122.443 > 100.64.0.1.22334: Flags [.], ack 270, win 5571, length 0 21:13:43.935375 IP 169.254.211.122.443 > 100.64.0.1.22334: Flags [.], seq 1:1461, ack 270, win 5571, length 1460 21:13:43.935413 IP 100.64.0.1.22334 > 169.254.211.122.443: Flags [.], ack 1461, win 32120, length 0 21:13:43.935420 IP 169.254.211.122.443 > 100.64.0.1.22334: Flags [.], seq 1461:2921, ack 270, win 5571, length 1460 21:13:43.935456 IP 100.64.0.1.22334 > 169.254.211.122.443: Flags [.], ack 2921, win 35040, length 0 21:13:43.935504 IP 169.254.211.122.443 > 100.64.0.1.22334: Flags [P.], seq 2921:3487, ack 270, win 5571, length 566 21:13:43.935525 IP 100.64.0.1.22334 > 169.254.211.122.443: Flags [.], ack 3487, win 37960, length 0 21:13:44.037489 IP 169.254.211.122.443 > 100.64.0.1.22334: Flags [P.], seq 3487:4256, ack 270, win 5571, length 769 21:13:44.037520 IP 100.64.0.1.22334 > 169.254.211.122.443: Flags [.], ack 4256, win 40880, length 0 21:13:44.038769 IP 100.64.0.1.22334 > 169.254.211.122.443: Flags [P.], seq 270:345, ack 4256, win 40880, length 75 21:13:44.219077 IP 169.254.211.122.443 > 100.64.0.1.22334: Flags [.], ack 345, win 5496, length 0 21:13:44.219117 IP 100.64.0.1.22334 > 169.254.211.122.443: Flags [P.], seq 345:396, ack 4256, win 40880, length 51 21:13:44.469480 IP 169.254.211.122.443 > 100.64.0.1.22334: Flags [.], ack 396, win 5445, length 0 21:13:44.652660 IP 169.254.211.122.443 > 100.64.0.1.22334: Flags [P.], seq 4256:4530, ack 396, win 5445, length 274 21:13:44.654222 IP 100.64.0.1.22334 > 169.254.211.122.443: Flags [P.], seq 396:1048, ack 4530, win 43800, length 652 21:13:44.719427 IP 169.254.211.122.443 > 100.64.0.1.22334: Flags [.], ack 1048, win 4793, length 0 21:13:45.056474 IP 169.254.211.122.443 > 100.64.0.1.22334: Flags [P.], seq 4530:5197, ack 1048, win 4793, length 667 21:13:45.056831 IP 100.64.0.1.22334 > 169.254.211.122.443: Flags [P.], seq 1048:1079, ack 5197, win 46720, length 31 21:13:45.056888 IP 169.254.211.122.443 > 100.64.0.1.22334: Flags [R.], seq 5197, ack 1079, win 5840, length 0 21:13:45.056907 IP 100.64.0.1.22334 > 169.254.211.122.443: Flags [F.], seq 1079, ack 5197, win 46720, length 0 21:13:45.056928 IP 169.254.211.122.443 > 100.64.0.1.22334: Flags [.], ack 1079, win 4762, length 0 21:13:45.056964 IP 100.64.0.1.22334 > 169.254.211.122.443: Flags [R], seq 1831619244, win 0, length 0 ^C 53 packets captured 53 packets received by filter 0 packets dropped by kernel ┌────[root@srv: 2018-07-26 21:13:49 ~] └─>#
И поисковик DockDuckGo в браузере - опять фсе работает, кстати через церочку прокси тоже будет работать😊 Если не работает, попробуйте другие адреса, к примеру http://zqktlwi4fecvo6ri.onion/wiki/index.php/Main_Page, Tor штука не совсем стабильная - бывает чтото конкретное не работает, бывает иногда совсем ниче не работает а надо просто подождать😊
Осталось дело за малым - поднять свой днс рекурсор, хотя впринципе это не обязательно, но система блокировки у провайдера может подменять днс ответы, а благодаря dnssec у нас есть шанс узнать об этом, и если он таки так делает то на этом же рекурсоре мы можем сделать форвардинг запросов на dns сервер tor, можно его и на прямую прописать - впринципе работать скорее всего будет, но с рекурсором как то больше возможностей для маневров, и вдобавок получим кеширование что несколько ускорит загрузку страниц в любом случае, а в случае форварда на tor сервер ускорит существенно ибо он нихрена не быстрый и вообще кривой😊 Да и вообще я всю жизнь так делаю😊 В качестве dns сервера на данный момент у меня bind, а по сему:
Bind у меня немного патченный, на предмет оверврайта min-ttl в определении зоны дабы можно было кешировать некешируемое, и можно было самостоятельно определять на какой промежуток времени кешировать, это наруешает rfc но на локальной машине не страшно - в редких ситуациях когда перестарались вегда под рукой есть rndc flushname/flushtree.
Patch_bind-min-ttl-override-9.12.2_p2-r1.patch.bz2 - патч для этого, вводит 2 новые директивы - min-cache-ttl и override-cache-ttl.
Настройки bind собсно находяца в /etc/bind - логично😊
/etc/bind/named.conf:
acl "xfer" {
none;
};
acl "trusted" {
127.0.0.0/8;
192.168.3.0/30;
10.32.18.176/28;
100.64.64.0/30;
10.32.75.176/28;
100.64.65.0/24;
100.64.5.8/30;
};
acl "icf_masters" {
91.193.237.1;
91.193.236.10;
};
masters "icf_masters" {
91.193.237.1;
91.193.236.10;
};
server 127.0.0.2 {
bogus no;
edns no;
request-nsid no;
send-cookie no;
};
#dnssec managed-keys-zone
include "/etc/bind/bind.keys";
options {
directory "/var/bind";
pid-file "/run/named/named.pid";
version "ohuenny servir Made in USSR";
hostname none;
server-id none;
statistics-file "/var/log/named/named_stats.txt";
memstatistics-file "/var/log/named/named_mem_stats.txt";
dump-file "/var/log/named/named_cache_dump.txt";
zone-statistics yes;
empty-zones-enable yes;
interface-interval 0;
recursion yes;
check-names master warn;
check-names slave warn;
check-names response ignore;
minimal-responses no;
message-compression no;
trust-anchor-telemetry no;
transfer-format many-answers;
max-cache-size 512M;
max-ncache-ttl 32400;
max-cache-ttl 3600000;
min-cache-ttl 1036800;
override-cache-ttl 1;
prefetch 10;
lame-ttl 1800;
servfail-ttl 30;
cleaning-interval 120;
min-refresh-time 600;
max-zone-ttl 3600000;
clients-per-query 32;
max-clients-per-query 128;
recursive-clients 512;
tcp-clients 256;
max-recursion-depth 16;
files 65535;
dnssec-enable yes;
dnssec-validation auto;
listen-on { 127.0.0.1; 10.32.75.177; };
listen-on-v6 { none; };
query-source 10.32.75.177;
transfer-source 10.32.75.177;
notify-source 10.32.75.177;
edns-udp-size 1432;
max-udp-size 1432;
allow-new-zones no;
notify no;
allow-query {
trusted;
};
allow-query-cache {
trusted;
};
allow-recursion {
trusted;
};
allow-transfer {
none;
};
allow-update {
none;
};
rate-limit {
ipv4-prefix-length 32;
window 10;
responses-per-second 20;
errors-per-second 5;
nxdomains-per-second 5;
log-only yes;
exempt-clients {
trusted;
};
};
rrset-order {
order fixed;
};
filter-aaaa-on-v4 yes;
filter-aaaa-on-v6 yes;
filter-aaaa {
trusted;
};
};
logging {
channel default_log {
file "/var/log/named/named.log" versions 5 size 5M;
print-time yes;
print-severity yes;
print-category yes;
buffered no;
};
channel security_log {
file "/var/log/named/named_security.log" versions 5 size 64M;
print-time yes;
print-severity yes;
print-category yes;
buffered no;
};
channel dnssec_log {
file "/var/log/named/named_dnssec.log" versions 5 size 64M;
print-time yes;
print-severity yes;
print-category yes;
buffered no;
};
channel lame_log {
file "/var/log/named/named_lame.log" versions 5 size 64M;
print-time yes;
print-severity yes;
print-category yes;
buffered yes;
};
channel xfer_log {
file "/var/log/named/named_xfer.log" versions 5 size 64M;
print-time yes;
print-severity yes;
print-category yes;
buffered no;
};
channel edns-disabled_log {
file "/var/log/named/named_edns-disabled.log" versions 5 size 64M;
print-time yes;
print-severity yes;
print-category yes;
buffered no;
};
channel rate-limit_log {
file "/var/log/named/rate-limit.log" versions 5 size 64M;
print-time yes;
print-severity yes;
print-category yes;
buffered no;
};
category default { default_log; };
category general { default_log; };
category security { security_log; };
category update-security { security_log; };
category dnssec { dnssec_log; };
category lame-servers { lame_log; };
category cname { lame_log; };
category xfer-in { xfer_log; };
category xfer-out { xfer_log; };
category notify { xfer_log; };
category edns-disabled { edns-disabled_log; };
category rate-limit { rate-limit_log; };
};
include "/etc/bind/rndc.key";
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1/32; } keys { "rndc-key"; };
};
zone "lan." IN {
type master;
file "pri/db.lan";
notify yes;
allow-query { trusted; icf_masters; };
also-notify { icf_masters; };
allow-transfer { icf_masters; };
};
include "/etc/bind/loopback.conf";
include "/etc/bind/zones_slave.conf";
include "/etc/bind/zones_forward.conf";
include "/etc/bind/zones_root.conf";
Впринципе тут ничего особенного нет:
дальше наиболее интересное в нашей задаче:
/etc/bind/zones_forward.conf
// tor onion. zone forward to tor internal dns server
zone "onion." {
type static-stub;
server-addresses { 127.0.0.2; };
};
zone "retre.org" {
type forward;
forward only;
forwarders { 127.0.0.2; };
};
zone "tracktor.in" {
type forward;
forward only;
forwarders { 127.0.0.2; };
};
Тут какрас происходит форвардинг запросов для зоны onion. на резольвер tor, который как ранее описано выдает фейковые ip из определенного диапазона для этой зоны и ассоциирует их с нодами внутри tor сети - таким образом это и работает без прямого socks подключения к tor. Так же здесь форврадинг для зон retre.org и tracktor.in - видать при их блокировке накрыли и ихние днс сервера тоже так как на данный момент они напрямую не резольвяца, но при этом резольвяца через tor сеть - пришлось прописать вручную. И тут еще нужен финт ушами - так как onion. типа корневой домен - просто так форвардинг не сработает ибо корневая зона подписана и у нас включен dnssec - будет вякать что подписи нет и резольвить откажеца, workaround - выставить для зоны так называемый nta - negative trust anchor, при этом dnssec для такой зоны будет отключен и все заработает, делаетя это с помощью rndc, и перманентно так сделать нельзя - запись добавляетя на определенное время так как предназначение этой фичи - временно отключить dnssec для зоны в случае если админ зоны сотворил какой либо фейл с dnsec а резольвить ее все же нада пока он не исправил. поэтому добавляем в крон чтото типа такого:
@daily rndc nta -l 1w -f onion. &>>/dev/null
это выставляет nta для зоны рас в день сроком на неделю, таким образом оно будет выставлено всегда, ну если машина не выключается наночь😊
Ну и на последок самое главное:
/etc/bind/zones_root.conf
//zone "." in { type hint; file "/var/bind/named.cache"; }; #The traditional root hints mechanism.
masters "root_xfr_masters" {
199.9.14.201; # b.root-servers.net.
192.33.4.12; # c.root-servers.net.
199.7.91.13; # d.root-servers.net.
192.203.230.10; # e.root-servers.net.
192.5.5.241; # f.root-servers.net.
198.97.190.53; # h.root-servers.net.
192.36.148.17; # i.root-servers.net.
192.58.128.30; # j.root-servers.net.
193.0.14.129; # k.root-servers.net.
};
// http://www.dns.icann.org/services/axfr/
masters "icann_xfr" {
192.0.32.132; // lax.xfr.dns.icann.org
192.0.47.132; // iad.xfr.dns.icann.org
192.0.47.132; // xfr.cjr.dns.icann.org
};
// the slave root zones according rfc7706
zone "." in {
type slave;
file "sec/root-slave.db";
masters { root_xfr_masters; icann_xfr; };
notify no;
};
zone "root-servers.net." in {
type slave;
file "sec/root-slave.root-servers.net.db";
masters { root_xfr_masters; icann_xfr; };
notify no;
};
zone "mcast.net." in {
type slave;
file "sec/root-slave.mcast.net.db";
masters { icann_xfr; };
notify no;
};
zone "arpa." {
type slave;
file "sec/root-slave.arpa.db";
masters { root_xfr_masters; icann_xfr; };
notify no;
};
zone "in-addr.arpa." {
type slave;
file "sec/root-slave.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "224.in-addr.arpa." {
type slave;
file "sec/root-slave.224.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "225.in-addr.arpa." {
type slave;
file "sec/root-slave.225.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "226.in-addr.arpa." {
type slave;
file "sec/root-slave.226.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "227.in-addr.arpa." {
type slave;
file "sec/root-slave.227.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "228.in-addr.arpa." {
type slave;
file "sec/root-slave.228.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "229.in-addr.arpa." {
type slave;
file "sec/root-slave.229.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "230.in-addr.arpa." {
type slave;
file "sec/root-slave.230.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "231.in-addr.arpa." {
type slave;
file "sec/root-slave.231.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "232.in-addr.arpa." {
type slave;
file "sec/root-slave.232.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "233.in-addr.arpa." {
type slave;
file "sec/root-slave.233.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "234.in-addr.arpa." {
type slave;
file "sec/root-slave.234.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "235.in-addr.arpa." {
type slave;
file "sec/root-slave.235.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "236.in-addr.arpa." {
type slave;
file "sec/root-slave.236.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "237.in-addr.arpa." {
type slave;
file "sec/root-slave.237.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "238.in-addr.arpa." {
type slave;
file "sec/root-slave.238.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
zone "239.in-addr.arpa." {
type slave;
file "sec/root-slave.239.in-addr.arpa.db";
masters { icann_xfr; };
notify no;
};
Тут тоже присутствует некоторый финт ушами, хотя для бсдэшников это почти штатно, но тем не менее - кто работал с bind наверное заметил что у меня нет root hints - стандартного механизма получения адресов корневых серверов, его нет потому что я его не использую, вместо этого я делаю transfer корневых зон с корневых серверов к себе, что уменьшает как нагрузку на корневые сервера так и время отклика ибо это убирает необходимость запросов к ним от слова совсем при резольвинге, делается только периодический transfer с них.
Вдобавок я тяну не только корневые зоны, но и обратку и обратки для подсетей, часть из этого доступно как с корневых так и с icann серверов, часть только с icann, поэтому разные значения в masters для зон.
На этом пожалуй наверное все😊 не прошло и полгода как я доваял эту портянку😊 хотя точнее судя по всему прошло - ну да ладно, как могу так и пишу - выж мне за эту хуйню не платите😊
Blog Docs WWW Proxy Caching wwwoffle 3proxy patch Network Linux Unix-Way Bind
Нано это ноу-хау великих мужей С нано жить лучше, жить веселей Нано это круто, поверьте, ребята Нано это десять в минус девятой! Нано мечты, воплощенные реальность. Нано это шанс доказать свою лояльность Без нано что будет? Коллапс и разруха, А с нано улыбка от уха до уха, И с нано, у причастных, сытое брюхо.
Вобщем после создания сего сайта который вы счас читаете, как это водица - одолели спам-боты, коментарии были открыты всем, и вот начали они мне туда "комментировать"😊
Вывод - привернуть регистрацию, а для этого нужна почта, причем на этой же машине где крутица движок сайта.
А ее то тут и нету, вообще, даже локальной, тоесть MTA отсутствует напрочь, а как то мыло для регистрации слать нада. Вобщем то движок при отсылке дергает sendmail как все остальные милионы движков, все стандартно. Поэтому нада чтото что могло бы выступать заменой sendmail'у. Выходы:
И такие варианты нашлись, аж несколько. Начал смотреть и пробовать:
Итак, выбор пал на nullmailer. Далее собсно более подробно о настройке nullmailer ибо она не тривиальна, а очень тривиальна😊 Всего 4 строчки(ну мне просто делать нех и я тут печатаю хрень всякую😊 Рас уж начал - нада дописать до конца😊
Слать почту мы будем через акканут srv@megaprovider.ru на одноименном сервере - megaprovider.ru😊
Конфигурация находица в /etc/nullmailer
megaprovider.ru smtp starttls insecure user=логин pass=пароль
и, все😊 Шлет, эмулирует при этом команду sendmail, так что все что заточено слать через нее будет работать и с nullmailer.
Единственное что я сначала напоролся на insecure - без него вякает на сертификат на сервере, но нифига не ясно на что именно, естественно возникла мысль что так как он там самоподписанный то может на него вякать, и методом тыка (добавлением insecure) это было подтверждено.
После вот этого когда кризис вроде бы отступил, появилось время подумать😊
После осознания того, что с 4 прерываниями на карту удается задействовать только 8 ядре из 12 в голову закралась мысль что нада больше прерываний то😊 Три маршрутизатора справлялись, однако резерва то нет и при выходе из строя хотябы одного будет жопа.
Соответственно нада другие сетевые - купить - хуйвам сказала Танюха, фсе бабло ушло на водку и питарды ибо корпоратив завтра😊
И начались поиски подходящих сетевых путем разгребания всякого хлама ибо чтото гдето такое вроде как было, да и за почти 20 лет работы не могло такого быть чтоп чтото гдето не валялось подходящего, тока где... и вот они - 4 двухпортовых BCM5709 как скуста, часа через пол после начала поисков😊
Чувак там ночью проводил работы и заодно и их воткнул😊 Как итог - стало лучше, но, тоже не без косяков:
#тут у нас какаято блять брадкомовская магия - combined оно говорит что не умеет и при попытке дать шлет нахуй, #при rx 6 tx 6 получается 6 прерываний в сумме, первое из которых не работает вообще - тоесть тупо не прерывается #и не дает никакой нагрузки, при rx 6 tx 1 получется тоже 6 в сумме но при этом вроде бы нормально работающих. #че ето за херня яхз но пока так. # # upd - нихуя не нормально работающих, первое почемуто всегда не догружено причем значительно, возможно это tx, # хотя иногда оно всетаки дает нагрузку как то всплесками. судя по acct2 rx 6 tx 6 combined 6 дает ту же картину. # нада блять будет попробовать 7+1, и опять ебаца как их распределить чтоп задействовать ядра полностью, правда че # будет с теми всплесками зх. #ethtool -L enp1s0f0 rx 6 tx 6 combined 6 ethtool -L enp1s0f0 rx 6 tx 1 #ethtool -L enp1s0f0 combined 6 #ethtool -L enp3s0f0 rx 6 tx 6 combined 6 ethtool -L enp3s0f0 rx 6 tx 1. #ethtool -L enp3s0f0 combined 6 #ethtool -L enp1s0f1 rx 6 tx 6 combined 6 ethtool -L enp1s0f1 rx 6 tx 1. #ethtool -L enp1s0f1 combined 6 #ethtool -L enp3s0f1 rx 6 tx 6 combined 6 ethtool -L enp3s0f1 rx 6 tx 1. #ethtool -L enp3s0f1 combined 6
Это мой коментарий с куском скрипта разруливающего прерывания. тоесть теперь мы можем задействовать 10 ядер из 12 - прогресс как говорица на лицо😊
При этом по названию прерываний в /proc/interrupt tx от rx не отличить, ибо обзываются они просто eth-0/1/2/3 нуитд, примерно так:
acct1 ~ # cat /proc/interrupts |grep enp1s0f0 50: 446973042 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 524288-edge enp1s0f0-0 51: 91 344667423 0 0 0 0 0 0 0 0 0 0 PCI-MSI 524289-edge enp1s0f0-1 52: 85 0 352724036 0 0 0 0 0 0 0 0 0 PCI-MSI 524290-edge enp1s0f0-2 53: 60 0 0 363097349 0 0 0 0 0 0 0 0 PCI-MSI 524291-edge enp1s0f0-3 54: 129 0 0 0 344874594 0 0 0 0 0 0 0 PCI-MSI 524292-edge enp1s0f0-4 74: 86 0 0 0 0 358027569 0 0 0 0 0 0 PCI-MSI 524293-edge enp1s0f0-5 acct1 ~ #
и кто из них кто хз, так же не понятно почему при tx 6 rx 6 их всего 6 когда по логике должно быть 12. Вобщем прерываюца эти бродкомы как то через жопу😊
При этом, BCM5720 вполне себе нормально все рисует и количество прерываний тоже сходица, как указали rx 4 tx 1 так и есть, 5 штук суммарно:
acct0 ~ # cat /proc/interrupts |grep enp1s0f0 50: 206892049 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 524288-edge enp1s0f0-tx-0 51: 3 134202632 0 0 0 0 0 0 0 0 0 0 PCI-MSI 524289-edge enp1s0f0-rx-1 52: 2 0 130895851 0 0 0 0 0 0 0 0 0 PCI-MSI 524290-edge enp1s0f0-rx-2 53: 2 0 0 126258675 0 0 0 0 0 0 0 0 PCI-MSI 524291-edge enp1s0f0-rx-3 54: 2 0 0 0 132045015 0 0 0 0 0 0 0 PCI-MSI 524292-edge enp1s0f0-rx-4 acct0 ~ #
только у BCM5720 драйвер tg3 а у BCM5709 bnx2.
Однако это еще не все.
На Танюхино хуйвам, вечером в ЧНН один из маршрутизаторов сказал свое жесткое хуйвам всем нам, зависнув в час пик, после перезагрузки повторил это снова через пару минут, контрольный так сказать😊 В пятницу вечером, перед корпоративом - знает сцуко когда говорить😊
Оставшиеся 2, практически на пределе, но тянут нагрузку, rtt изредко дергается ms на 10-20, но потерь я пока не фиксирую, так что вроде все нормально с этим. А всего то задействовали 4 дополнительные очереди.
Учитывая что их таких 2 полностью идентичных, и до вчерашней замены сетевых проблем небыло приходит логичный вывод что одна из тех бродкомов полудохлая и проблемы из за нее.
Так что, продолжение следует😊
Вобщем беда четвертая:
Итак, в свете вот этого берем мы "новый сервир" почему в кавычках? да потому что берем мы в срочном порядке что есть, а есть у нас супермикра 1u с двумя Xeon X5670 @ 2.93GHz, образца 2010 года... с двумя планками памяти по 8Гб.
То что памяти 16ГБ нам дофени - нату хватит, а вот то что она одноканальная при таком раскладе, вместо трехканальной нам уже совсем не до фени, ибо это роутер+NAT, этим двум задачам латентность и пропускная способность памяти критична наверное как никаким другим. и это опять полбеды.
Нам Нужно 5 интерфейсов 2 ввех 2 вниз и 1 для слива netflow и out of band управления.
Но это 1u, в котором есть 2 набортных интерфейса, впринципе подходящих под задачу, умеют до 8 очередей, и выставляют 6 без проблем.
В рейзер можно вставить еще 1 сетевую. засунули туда двухпортовый броадком NetXtreme II BCM5709, тоже умеющий до 8 очередей, и тоже походу последний😊
Итого 4 интерфейса...
И, netflow девать некуда😊 Есть рейзер в который можно воткнуть 2 сетевых, но он уже кудато воткнут и выключить это просто так нельзя, тоесть нада ждать темной ночи когда нагрузка минимальна, комуто оставаца, отключать, вытаскивать, включать, а у нас же горит уже😊
Ну хули делать, я его слепила из того что было, зато есть неплохие шансы потом написать как то что я слепила меня полюбило😊
Будем лить инбандом, теряя по дороге кал netflow и управление в случае каких нибудь проблем или перегрузок.
Типовая конфигурация соотвественно тоже попизде пошла, как у нас водица, этоже не интересно, 2 раза одной и той же дорогой ходить, а потом спустя время нам это аукнеца - тоже развлеченье хоть какое, ато не интересно же когда все работает😊
Для восстановления резерва этого оказалось не достаточно, тоесть втроем они эту нагрузку тянут, но при выходе из строя одного из серверов опять будет жопа.
Попутно выяснил еще 1 прикол - наш netflow коллектор по дефолту способен принимать netflow с любой точки сети, не только нашей, а глобальной😊 Тоесть он открыт всему миру😊 ну а что, удобной - я вот начал лить инбандом - даже делать с ним ниче не пришлось😊
Вдобавок в вот этому узрел вдруг всплеск очереди на почтовом сервере, примерно вот такой:
megaprovider ~ # mailq|grep psv@icf.bofh.ru|wc -l 4667 megaprovider ~ #
А там консервный завод в сторону яхи хотмейлов итд.
Все оказалось просто, акаунт дохлый, чувак им не пользуется уже хер знает скока, и ктото решил проявить свою гениальность и влепить на акаунт пароль 12345, ведь никто же не подумает что в интернете могут быть дебилы с таким паролем😊 А наши любимые боты не дремлют, взяли и попробовали, и у них получилось😊
Пришла и третья беда, вечером позвонили и сообщили что на NAT'ах чтото все очень-очень плохо, softirq грузит процы в сотку.
Посмотрел - с части интерфейсов прерывания действительно ушатывают некоторые ядра, траффик вырос гдето в 3 раза с тех пор как их поставили. NAT тоже поменялся - привернули лимит трансляций per IP, и стали натить в пул адресов а не в 1, а это же все тоже не бесплатно в плане ресурсов CPU.
Позвонил Главный инженер, как всегда не вовремя подруку, но это ладно, волнуеца же😊 Поинтересовался как дела, заодно сообщил что оно так уже давно делает периодически в часы пиковой нагрузки. Но все сидят ждут чегото, хз чего, может думают что когда они подключают больше клиентов у них траффик нихуя не растет а только падает.
При таком раскладе ушатали и резерв, так как если запаса по производительности нет то и резерва тоже, нагрузка то при отказе ляжет на оставшиеся сервера, не способные ее обработать. Поэтому деградация сервиса будет такая что можно сказать что резерва нет.
Я это раньше мониторил посредством smokeping, он сразу резво так вякает если растет rtt или не дай боже гдето чтото теряется, тоесть еще за долго до того как ситуация превратица в катастрофу. Но блять с этими переездами сервер где он был вывели из эксплуатации и там ад и израиль и вобщем средств мониторинга у меня не осталось. А нового пока нет. Башка забита перестройкой ядра сети, серверной и инфраструктуры вцелом, и я туда и не смотрел сполгода как совсем. Я строю, другие эксплуатируют, то что я понастрою. До победного конца как оказалось.
Начал смотреть что можно сделать прям сейчас, оказалось что softirq по цене нихрена не одинаков в случае NAT'а, он же в softirq обрабатывается. Входящие на NAT из вне пакеты требуют значительно больше ресурсов для обработки нежели приходящие со стороны серых подсетей.
Прерывания были размазаны поровну исходя из количества сетеух, очередей на них и количества процессоров. Тоесть там впринципе 4 нагруженных интерфейса в бондинге, 2 ввех 2 вниз, и 12 процов, соответственно по 3 irq на интерфейс. Такая схема хорошо работает на чисто маршрутизаторах, там прерывания равноценны. Но не при наличии NAT'а. Некоторые из прерываний с интерфейсов смотрящих вверх грузили свои CPU в полку.
Так же понятно то что как бы чем меньше очередей на интерфейсе тем больший траффик в каждую конкретную очередь влетит, тем больше нада ресурсов чтоп отработать прерывание от этой очереди. Ну и размазываца траффик по ним он будет менее равномерно скорее всего.
Так и получалось - 1 очередь перегружена, 2 других сильно не догружены.
Решил увеличить количество irq и очередей соответственно тоже, но оказалось что BCM5720 больше 4 не умеют, до этого выставлено было 3, но тем не менее полегчало, процентов на 20-30.
Но тоже не без факапа - сервер наебнулся при изменении количества очередей на лету, ну точнее не то чтоп наебнулся совсем, драйвер выдал какой то splat экрана на 4 частично в хексе, после чего линки на интерфейсах начали то падать то поднимаца, видимо под нагрузкой чтото у него там не срослось. Рассматривать мне его было некогда поэтому выход 1 - перезагрузка.
Перегрузил, второй NAT сервир как то пережил нагрузку с дикими тормозами пока первый не загрузица, на втором ситуация повторилась, пришлось тоже перегрузить.
Ну и как итог - сегодня будем готовить третий, иначе говоря как всегда - пока не наебнеца хуй кто зашевелица, несмотря на то что инженер потом позвонил сказал что знал что оно не справляется уже давно.
Все почемуто относяца ко всяким комутаторам и маршрутизаторам как к железке, которая типа целиком вся в железе и софта там нет, и поэтому она не ломаеца иначе как физически, и вообще не поколебима и нерушима😊 Только вот это нихрена не так, везде есть софт, и даже в железе тоже есть ошибки допущенные при проэктировании.
Древнючий Cisco catalyst C3550:
srv-core-gw uptime is 17 weeks, 4 days, 8 hours, 43 minutes System returned to ROM by power-on System restarted at 04:35:49 GMT Fri Aug 18 2017 System image file is "flash:/c3550-ipservicesk9-mz.122-44.SE6/c3550-ipservicesk9-mz.122-44.SE6.bin"
srv-core-gw#who
Line User Host(s) Idle Location
1 vty 0 idle 17w2d 201.172.42.43
2 vty 1 idle 13:03:24 10.32.75.177
3 vty 2 idle 01:16:16 10.32.75.177
4 vty 3 idle 4w1d 184.6.246.208
5 vty 4 idle 13:02:52 10.32.75.177
* 6 vty 5 idle 00:00:00 10.32.75.177
Interface User Mode Idle Peer Address
srv-core-gw#
вобщем все что не 10.32.75.177 это не наши😊
при этом:
ip access-list standard TELNET-ACCESS permit xxx.xxx.xxx.xxx 0.0.0.31 permit 10.32.75.176 0.0.0.15 ! line vty 0 4 password 7 абракадабра login transport input telnet line vty 5 15 access-class TELNET-ACCESS in password 7 издесьабракадабра login transport input telnet !
Тоесть ктото попросту проебал АКЛ на line vty, и так он работает почти с самого старта, аптайм 17 weeks, 4 days, у 201.172.42.43 idle 17 недель 2 дня😊 Чего быть не может с дефолтным таймаутом, Ну или же ios откудато украли сразу со встроенным трояном😊 Или просто какаято уязвимость, и ACL может быть вообще ни причем, этого мы уже наверное никогда не узнаем.
На работе это никак не сказывается, комутирует, маршрутизирует, поэтому всем похуй на это судя по всему, никто бы вообще не заметил никогда не полезь я туда его перенастраивать.
Ну или можно предположить что пароль ушол, но тут возникает ряд других вопросов:
В sh log тоже ниче подозрительного, хотя все комманды логгируюца, что опять таки намекает на какой то бэкдор/троян.
В ручную при таком раскладе никто не будет ебаца с каким то отдельно утекшим паролем и единичным комутатором. При единичном целенаправленном взломе всегда есть мотив, заработать/спиздить/насолить итд, иначе он не возможен, потому что как правило это дорого обходица, поэтому еслип ктото из окружения/сотрудников/бывших преследовал бы одну из подобных целей то навероное он бы ее уже давно достиг и это не осталось бы незамеченным.
При автоматизировнных взломах напротив - цели вывести из строя то что взломали нет, есть цель использовать то что взломали в своих целях в том числе - чаще всего для построения ботнета - взломанная единица присоединяеца к остальному милиону ботов и делает что им скажут, при этом взломанная единица в идеале выполняет свои основные функции как ни в чем не бывало, ведь иначе когда чтото перестанет работать это обязательно заметят, даже если троян будет всячески маскировать свое присутствие (отказ коммутатора коммутировать не замаскируеш😊 и примут меры, а так всем хорошо - и хакерам и лохам которых поимели😊
Поэтому скорее всего это автоматизированный взлом, просто куча роботов автоматом ищет уязвимые железки (и циско не исключение в их длиннющем спике) и хакает дабы потом использовать для рассылки спама или еще чего либо на чем можно заработать. Так же как и с ssh на серверах.
Хотя с другой строны хз на что может быть способен бекдор на комутаторе, анализировать траффик на самом комутаторе не выйдет, этож древняя циска, и там процессор чуть мощьнее чем в калькуляторе ситизен, но зато там есть средства типа PBR которые работают тупо в железе и поэтому на wire speed, и вот ими уже возможно, можно к примеру выделить нужный траффик и развернуть его куда нада и там уже анализировать чем нить мощьным, и к примеру таким образом воровать акаунты/пароли/кредитки и прочую дрочь юзеров и админов, чей траффик через него ходит и на него.
Весь прикол еще и в том что и средств то для какой либо диагностики таких факапов по сути нет, учитывая что он пока в работе, а если предположить что троян то все еще груснее - даже если его вывести из эксплуатации единственный способ что либо сделать это включить его и загрузить, и трояна если он там есть и неизвестно на что способен соответственно тоже, без этого никак - флэш встроенная, перепрошивка опять таки то же самое - гарантий что этот троян не встроит себя автоматом в новую прошивку нет. Можно разьве что с роммона грузануть по сети или прям с терминала и надеяца что его это не затронуло. А так ну если только выпаивать и читать чем либо уже с компа но он не стоит такого гемороя да и денег тоже.
Так что, не проебывайте аклы, и сверяйте crc с кошкодомом когда вливаете краденный иос😊 Следите за обновлениями и секюрити фиксами. И даже это на 100% ничего не гарантирует.