Main About Documentation Help Blog New Login Register

Main

2020-04-19 Cycling-Blog

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

Learn more...

2019-03-28 Networking-Blog

--- Уязвимости в Cisco RV32x были устранены через блокировку запросов от утилиты curl.

Исследователи из компании RedTeam Pentesting обнаружили, что компания Cisco лишь создала видимость устранения уязвимостей в выпущенном в январе обновлении прошивки к маршрутизаторам Cisco RV320 и RV325. Вместо реального устранения проблем в скриптах web-интерфейса, в обновлении прошивки были внесены изменения в настройки http-сервера nginx, блокирующие обращение при помощи утилиты curl, которая использовалась в прототипе эксплоита и примерах для проверки наличия уязвимости.

cisco_ebanyistyd.jpg

После установки обновления прошивки с "устранением" проблем, устройства 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:

"The initial fix for this vulnerability was found to be incomplete. Cisco is currently working on a complete fix."

Предполагаю, что под "complete fix" они понимают блокировку User-Agent "kurl", используемый в новом примере атаки😊

И заметье, на подготовку такого патча им потребовалось полгода:

  • 2018-09-19 Original vulnerability identified
  • 2019-01-22 Firmware 1.4.2.20 released by vendor

Ещё доставляет реклама этих рутеров на сайте Cisco:

"Keep your employees, your business, and yourself productive and effective. The Cisco RV320 Dual Gigabit WAN VPN Router is an ideal choice for any small office or small business looking for performance, security, and reliability in its network."

(c) opennet

Хоть это и мыльница и скорее всего ваще не их но тем не менее Ебаныйстыд!!!

2019-03-17 Networking-Blog

Лазал я тут по ебею, и неожиданно попался моему взору 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 можно засунуть в такой виртуальный роутер дабы он не анонсировал что ни попадя, и че бы он там ни принял эти анонсы в этом виртуальном роутере так и остануца и не попадут в глобальную таблицу маршрутизации.

Вроде бы на этом все мои страдания по скрещиванию законьчилис, теперь собственно

Learn more...

2018-07-09 Networking-Blog

Networking-Blog

Итак пока я сыграв в русскую рулетку с каким то долбаебом на шоссере вывихнул себе правое плече и получил трещину в ребре благодаря чему появилось время продолжить написание данной писанинки продолжим😊

Cвязка squid + c-icap с моими любимыми шлюхами и блэкджеками (ака контент фильтрация) для себя любимого у меня стояла уже лет 10 как в качестве банерорезки и кеша, После начала позора роскомнадзора со своими блокировками я добавил в эту схему tor для обхода блокировок, и i2pd до кучи - хз зачем но пускай будет. Но я все время искал чем бы заменить сквид с его sslbump ибо для одного юзверя это даже не из пушки по воробьям а чето ближе к ядерной боеголовке. И не особо то находил, а без sslbump все это не имеет смысла, большая часть траффика идет по https, и его необходимо расковыривать для фильтрации баннеров и кеширования тоже. Плюс сквид это тот еще монстр и часто заточить его на чтото что вызывает standart violation без рашпиля (ковыряния в исходниках) бывает невозможно. Не для персонального использования он создан, он может не чхая переварить полгига траффика и тысячи юзверей - я правда проверял - может😊 но при этом иногда заставить его к примеру закешировать чтото что по стандарту кешироваца не должно весьма проблематично.

И тут, недавно, не помню уже с чего вдруг гдето выплыл выплыл у меня в поиске [[Glossary_wwwoffle?|wwwoffle]], который заточен какрас для персонального использования в противовес сквиду, и почемуто я решил на него глянуть, не помню уже почему - мошт просто делать нехер было. И полной неожиданностью оказалось что оно умеет mitm ака sslbump в сквиде типа из коропки, причем уже много лет, и кешировать https тоже умеет, ну и еще кучу всяких standart violation для которых squid нада затачивать что не всегда тривиально, а тут типа все есть. ну и сразу же я решил сие дело посмотреть и опробовать.

Вообще так как все это нужно для 1-2-3 добашних клиентов, требования ко всему этому очень просты:

  • Оно должно быть маленькое и простое, пофиг на производительность и масштабируемость. Хотя кстати тот же сквид кстати тормозил при старте на парсинге ACL'ей сгенерированных из списка РКН
  • Оно обязательно должно уметь mitm aka sslbump в сквиде для https.
  • Оно должно уметь роутить траффик по url спискам, ну тоесть к примеру http://www.gedanken.org.uk/software/wwwoffle/ - идем директом, https://rutracker.org/forum/viewforum.php?f=1958 - идем через некий parent прокси дабы обойти блокировку, и это должно работать и для https тоже, а url желательно с масками.
  • Так же оно должно бы уметь роутить и по dst ip адресам и подсетям, ну тоесть 1.1.1.0/22 идем директом, а 2.2.2.0/24 опять таки идем через некий parent proxy, хотя это опционально так как в случае socks прокси тора это решается на уровне системы связкой [[Glossary_tun2socks?|tun2socks]] + ipset + iproute.
  • Хорошо бы еслип оно умело делать преобразование socks<->http proxy, но тоже опционально - решаеца промежуточными прокси, к примеру 3proxy
  • Оно должно уметь блочить url по маскам дабы фильтровать рекламку и прочую дроч, желательно с возможностью подмены заблоченных ссылок на свои.
  • Неплохо было бы так же иметь контент-фильтрацию, хотя опять таки решается промежуточными прокси к примеру privoxy/bfilter.

Learn more...

Linux Gentoo system wide epatch user

В Gentoo есть очень полезная возможность наложить свои патчи на стандартный ebuild при сборке. Делается это так - патчи нужно сложить к примеру в /etc/portage/patches/net-proxy/wwwoffle для пакета net-proxy/wwwoffle и они применяца автоматом при сборке, ЕСЛИ! в ебилде вызов epatch_user в src_prepare(), а есть он блять не везде.. поэтому гдето это работает а гдето нет.

Но есть способ это исправить:

В /etc/portage/bashrc помещаем следующее: 

pre_src_prepare() {
    [[ ${EAPI:-0} == [012345] ]] || return
    if ! type estack_push > /dev/null 2>&1; then
        local estack_names="eshopts_push eshopts_pop evar_push evar_push_set evar_pop estack_push estack_pop"
        source <(awk "/^# @(FUNCTION|VARIABLE): / { p = 0 } /^# @(FUNCTION|VARIABLE): (${estack_names// /|})\$/ { p = 1 } p { print }" ${PORTDIR}/eclass/estack.eclass)
    fi
    if ! type epatch_user > /dev/null 2>&1; then
        local epatch_names="EPATCH_SOURCE EPATCH_USER_SOURCE epatch_user_death_notice epatch_user epatch"
        source <(awk "/^# @(FUNCTION|VARIABLE): / { p = 0 } /^# @(FUNCTION|VARIABLE): (${epatch_names// /|})\$/ { p = 1 } p { print }" ${PORTDIR}/eclass/epatch.eclass)
    fi

    epatch_user

    for name in $epatch_names; do
        unset $name
    done
    for name in $estack_names; do
        unset $name
    done

}

Улыбимся/радуемся - гентуж блять!! рулит жеж нах!!😊

Learn more...

Linux Gentoo build package for debugging

Создаем /etc/portage/env/debugsyms и пишем туда следующее: 

USE="debug"
CFLAGS="${CFLAGS} -g -ggdb"
CXXFLAGS="${CXXFLAGS} -g -ggdb"
FEATURES="${FEATURES} nostrip"

#debuging FEATURES: keepwork nostrip splitdebug compressdebug nostrip

Этого достаточно чтоп собрать пакет с отладочной информацией.

До кучи создаем /etc/portage/env/installsources с вот таким содержимым: 

FEATURES="${FEATURES} installsources"

Это позволит установить результирующие исходники из которых был собран пакет со всеми патчами дабы не ипаца вручную, ставяца они в /usr/src/debug/

Это по сути мы сделали вариацию окружения для сборки пакетов с отладкой, на систему это не влияет - нада принудительнр сказать что нам нада собрать с отладкой, делается это вот так к примеру для пакета net-proxy/wwwoffle:

/etc/portage/package.env: 

net-proxy/wwwoffle debugsyms installsources

Тоесть собрать с отладкой и поставить исходники.

Learn more...

Linux Conntrack automatic helper assignment Docs

nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. вот что выдало мне ядро 4.14 на нате, вобщем то предупреждали уже давно, на 4.4 как минимум точно. Ну, я подгрузил модули хелперов принудительно, и думал что этого достаточно, но не тут то было.

Позвонили из саппорта, говорят pptp не хочет у когото соединяца, правда ошиблись и назвали не тот роутер на котором у меня тестируется 4.14, я забил сказав что со мной сие никак не связано😊 Тем не менее мне прислали дамп:

root@nwmsk-46-gw:~# tcpdump -ni eth1.189 host 37.29.74.109
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1.189, link-type EN10MB (Ethernet), capture size 262144 bytes
13:15:18.411162 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [S], seq 3051623381, win 8192, options [mss 1460,nop,wscale
8,nop,nop,sackOK], length 0
13:15:18.454187 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [S.], seq 1229404315, ack 3051623382, win 5600, options [mss
1400,nop,nop,sackOK,nop,wscale 5], length 0
13:15:18.455865 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [.], ack 1, win 257, length 0
13:15:18.455873 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [P.], seq 1:157, ack 1, win 257, length 156: pptp CTRL_MSGTYPE=SCCRQ
PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(0) HOSTNAME() VENDOR(Microsoft)
13:15:18.498863 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [.], ack 157, win 209, length 0
13:15:18.511886 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [P.], seq 1:157, ack 157, win 209, length 156: pptp CTRL_MSGTYPE=SCCRP
PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP() BEARER_CAP() MAX_CHAN(1) FIRM_REV(1) HOSTNAME(local) VENDOR(linux)
13:15:18.512947 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [P.], seq 157:325, ack 157, win 256, length 168: pptp CTRL_MSGTYPE=OCRQ
CALL_ID(49223) CALL_SER_NUM(23) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0)
PHONE_NO_LEN(0) PHONE_NO() SUB_ADDR()
13:15:18.567638 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [P.], seq 157:189, ack 325, win 242, length 32: pptp CTRL_MSGTYPE=OCRP
CALL_ID(63232) PEER_CALL_ID(49223) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(100000000) RECV_WIN(64) PROC_DELAY(0)
PHY_CHAN_ID(0)
13:15:18.575569 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [P.], seq 325:349, ack 189, win 256, length 24: pptp CTRL_MSGTYPE=SLI
PEER_CALL_ID(63232) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
13:15:18.577786 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 0, length 64: LCP, Conf-Request (0x01), id 0, length 50
13:15:18.657114 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [.], ack 349, win 242, length 0
13:15:20.577458 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 1, length 64: LCP, Conf-Request (0x01), id 1, length 50
13:15:23.577748 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 2, length 64: LCP, Conf-Request (0x01), id 2, length 50
13:15:27.578069 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 3, length 64: LCP, Conf-Request (0x01), id 3, length 50
13:15:31.578450 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 4, length 64: LCP, Conf-Request (0x01), id 4, length 50
13:15:35.578286 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 5, length 64: LCP, Conf-Request (0x01), id 5, length 50
13:15:39.579232 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 6, length 64: LCP, Conf-Request (0x01), id 6, length 50
13:15:43.580117 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 7, length 64: LCP, Conf-Request (0x01), id 7, length 50
13:15:47.580822 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 8, length 64: LCP, Conf-Request (0x01), id 8, length 50
13:15:48.632986 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [F.], seq 189, ack 349, win 242, length 0
13:15:48.633575 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [.], ack 190, win 256, length 0
13:15:48.641130 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [F.], seq 349, ack 190, win 256, length 0
13:15:48.684009 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [.], ack 350, win 242, length 0

GRE в одну сторону - типичный случай для pptp без хелпера потому что оно не натица без него а идет с серого адреса а дальше его тупо дропнет и до сервера оно вообще не дойдет, потому и LCP без ответа - закралось подозрение что сапорт обьебался с роутером.

Уточнил - точно ли оно идет не через тестовый роутер, оказалось таки через него - вопиющий пример херовой диагностики😊

Ну и тут сразу стало понятно что хелперы не работают, и начались разборки:

Learn more...

2017-12-09

Learn more...

2018-05-15 Blog

Нано это ноу-хау великих мужей
С нано жить лучше, жить веселей
Нано это круто, поверьте, ребята
Нано это десять в минус девятой!
Нано мечты, воплощенные реальность.
Нано это шанс доказать свою лояльность
Без нано что будет? Коллапс и разруха,
А с нано улыбка от уха до уха,

И с нано, у причастных, сытое брюхо.

Learn more...

Linux Filesystems IO Amplification Docs

Попалась тут интересная статейка, есть над чем задумаца...

Вот она, расплата за журналирование, COW, LOG-Структуры и прочие плюшки современных FS.

Learn more...

Nginx frontend backend Docs

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

Многие скажут - купи хостинг за 1$/VPS/etc и ниипи мозга итд - нихачуя😊 У меня это все на работе есть, но всеравно не хочу. Как говорица своя фуфайка ближе к телу😊 Какрас хостинг и впс помоему ни что иное как мозгоебство, на хостинге шаг влево-вправо - наткнешся на стену, а у меня тут perl и шагов там может быть овердохрена, виртуализацию и облачка не признаю впринципе для таких задач, и вам предлагаю тоже спустица с облачков на землю, тут все лучше😊 Да и вообще, кагдато давно-давно, мой самый первый сайт работал у меня дома ваще на диалапе😊

И тут возникли некоторые сложности со всякими натами и PBR. Схемка сети примерно такая - оператор<->мойроутерснатом<->локалкивсякие. В локалкивсякие находица и сервер, но помимо этого у роутера еще неожиданно есть тоннель ко мне на работу, с bgp прямо в ядро сети и прочими шлюхами дабы мне было удобно работать😊

И, получается что ну даже если я прокину порт с роутера, навешу домен на его внешний адрес ну да - будет работать, со всея интернету, НО, тока не из дома и не с работы😊 И вот почему:

Learn more...

2017-12-23 Web-Blog

Web-Blog

Вобщем после создания сего сайта который вы счас читаете, как это водица - одолели спам-боты, коментарии были открыты всем, и вот начали они мне туда "комментировать"😊

Вывод - привернуть регистрацию, а для этого нужна почта, причем на этой же машине где крутица движок сайта.

А ее то тут и нету, вообще, даже локальной, тоесть MTA отсутствует напрочь, а как то мыло для регистрации слать нада. Вобщем то движок при отсылке дергает sendmail как все остальные милионы движков, все стандартно. Поэтому нада чтото что могло бы выступать заменой sendmail'у. Выходы:

  1. поставить MTA и настроить форвардинг всей почты на почтовый сервер. как правило в составе любого MTA есть затычка аля sendmail.
  2. поискать чтото аля fetchmail наоборот, ну или какойнить совсем легкий MTA чтоп всю локальную почту форвардило через акаунт на почтовом сервере, тоесть по сути 1 хрен вариант 1 но только это будет уже не из пушки по воробьям как в случае полноценного MTA

И такие варианты нашлись, аж несколько. Начал смотреть и пробовать:

  1. esmtp отложил как last resort сразу - на страничке проэкта надпись THIS PROJECT IS NO LONGER BEING MAINTAINED.
  2. ssmtp завел, настроил, и exim на почтовом сервере мне сказал SMTP protocol synchronization error, это значит что ssmtp пытается слать команды до того как почтовый сервер выдаст ему приглашение, что в свою очередь значит что ssmtp херова следует стандартам и по сему я его забраковал после этого как поделие какованить очередного криворукого далбаеба, вдобавок он работает в синхронном режиме - тоесть ктото дернул там mail/sendmail, он тут же начинает слать в том же процессе, если не удачно ну чтож - обидно, досадно, но ладно - тоесть никакой очереди и ретраев у него нет. пока не отослал или не получил отлуп процесс блокируется, что опять таки намекает на криворуких далбаебов.
  3. nullmailer завелся не сразу, почемуто localhost в /etc/nullmailer/me ему не понравилось - выплевывал какуюто непонятную ошибку при попытке отправить что либо даже не доходя до smtp, тоесть выплевывал сам еще до того как поместить письмо в свою локальную очередь, хз почему, но после того как туда вписал домен от которого собираюсь слать все наладилось и заработало. Так же он имеет очередь, тоесть доставка асинхронна в отличии от варианта 2, и если сразу доставить не удалось будет пытаца потом сделать это снова.
  4. masqmail последняя версия от 2015 года, в генте вообще отсутствует - отмел так как вариант 3 задачу решает и присутствует в генте штатно, а именно она стоит на этом сервере.

Итак, выбор пал на nullmailer. Далее собсно более подробно о настройке nullmailer ибо она не тривиальна, а очень тривиальна😊 Всего 4 строчки(ну мне просто делать нех и я тут печатаю хрень всякую😊 Рас уж начал - нада дописать до конца😊

Learn more...

2017-12-22 Networking-Blog

Blog

Learn more...

2017-12-21 Networking-Blog

Blog

Learn more...

2017-12-20 Networking-Blog

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

megaprovider ~ # mailq|grep psv@icf.bofh.ru|wc -l
4667
megaprovider ~ #

А там консервный завод в сторону яхи хотмейлов итд.

Все оказалось просто, акаунт дохлый, чувак им не пользуется уже хер знает скока, и ктото решил проявить свою гениальность и влепить на акаунт пароль 12345, ведь никто же не подумает что в интернете могут быть дебилы с таким паролем😊 А наши любимые боты не дремлют, взяли и попробовали, и у них получилось😊

Learn more...

2017-12-19 Networking-Blog

Все почемуто относяца ко всяким комутаторам и маршрутизаторам как к железке, которая типа целиком вся в железе и софта там нет, и поэтому она не ломаеца иначе как физически, и вообще не поколебима и нерушима😊 Только вот это нихрена не так, везде есть софт, и даже в железе тоже есть ошибки допущенные при проэктировании.

Learn more...

Blog

2020-04-19 Cycling-Blog

Тестирование велосипедных цепей на разрыв

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

Comments on this page

2019-03-28 Networking-Blog

--- Уязвимости в Cisco RV32x были устранены через блокировку запросов от утилиты curl.

Исследователи из компании RedTeam Pentesting обнаружили, что компания Cisco лишь создала видимость устранения уязвимостей в выпущенном в январе обновлении прошивки к маршрутизаторам Cisco RV320 и RV325. Вместо реального устранения проблем в скриптах web-интерфейса, в обновлении прошивки были внесены изменения в настройки http-сервера nginx, блокирующие обращение при помощи утилиты curl, которая использовалась в прототипе эксплоита и примерах для проверки наличия уязвимости.

cisco_ebanyistyd.jpg

После установки обновления прошивки с "устранением" проблем, устройства 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:

"The initial fix for this vulnerability was found to be incomplete. Cisco is currently working on a complete fix."

Предполагаю, что под "complete fix" они понимают блокировку User-Agent "kurl", используемый в новом примере атаки😊

И заметье, на подготовку такого патча им потребовалось полгода:

  • 2018-09-19 Original vulnerability identified
  • 2019-01-22 Firmware 1.4.2.20 released by vendor

Ещё доставляет реклама этих рутеров на сайте Cisco:

"Keep your employees, your business, and yourself productive and effective. The Cisco RV320 Dual Gigabit WAN VPN Router is an ideal choice for any small office or small business looking for performance, security, and reliability in its network."

(c) opennet

Хоть это и мыльница и скорее всего ваще не их но тем не менее Ебаныйстыд!!!

Comments on this page

2019-03-17 Networking-Blog

IPSEC between cisco and juniper behind nat with dynamic IP and cisco DVTI aka Cisco Dynamic Virtual Interface / IPSEC между cisco и juniper за натом на динамическом IP с использованием DVTI на 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 можно засунуть в такой виртуальный роутер дабы он не анонсировал что ни попадя, и че бы он там ни принял эти анонсы в этом виртуальном роутере так и остануца и не попадут в глобальную таблицу маршрутизации.

Вроде бы на этом все мои страдания по скрещиванию законьчилис, теперь собственно

Конфигурация Cisco side:

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 и маршруты до нас на них итак есть.

  • maximum-paths ibgp 2 - для балансировки.
  • maximum-prefix 32 50 restart 1 - на всякий случай, ато вдруг где косяк на бордерах случица, и FV польеца, боюсь 3725 такого счастья не переживет😊

А под address-family ipv4 vrf backbone собственно конфигурация сессии с juniper.

  • transport connection-mode passive - не пытаца поднять bgp сессию со своей стороны - зачем нам😊 На самом деле смысла просто нет в этом - удаленная сторона после поднятия туннеля всеравно постучица, а мы по сути не знаем когда она жива когда мертва - вот пусть сама и поднимает.
  • update-source Loopback0 - потому что на туннелях ip unnembered Loopback0.
  • maximum-prefix 32 16 restart 10 - еще одно средство защиты - из дома Full View в бэкбон никак вливаца не должно, он тоже может этого не заценить, покрайней мере частично😊
  • route-map vpn_bgp_out out - тут подправляем origin отдаваемых маршрутов на IGP, не люблю я ?😊
  • prefix-list no-default-route in/out - опять предосторожность - срезаем дефолт по входу и выходу.
  • redistribute ospf 1 vrf backbone match internal external 1 external 2 nssa-external 1 nssa-external 2 редистрибьюция OSPF.
  • bgp redistribute-internal - опять редистрибьюция, только немного другая - прикол в том что когда мы в ospf роутере говорим redistribute bgp 42916 subnets - это будет действовать только на eBGP, который типа External Border Gateway, на IGP же к которому относится и iBGP, тоесть как у нас когда с обоих сторон номер AS один и тот же это не действует так как по мнению циски iBGP это тоже IGP как и ospf/eigrp/итд и редистрибьюции в ospf не будет, пока не дать эту команду в bgp роутере что немного неожиданно на первый взгляд😊
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 кусками, ибо у меня там накручено помимо этого еще дохрена чего и все целиком портянка та еще и слишком будет лишним перегружено.

Конфигурация juniper side:

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;
  • route 91.193.236.27/32 - очень важный вещь, покрайней мере для меня, так как кошка с которой мы соединяемся по сути находица в адресном пространстве той же AS с которой соединяемся, адреса на которых она висит нам так же прилетят по bgp, в том числе и 91.193.236.27, и все погаснет так как отвалица транспорт, тоннель же не может работать через самого себя😊
  • instance-import import-from-inst-AS42916-VPN; политика импорта маршрутов из виртуального роутера - как я уже говорил - ospf пришлось засунуть в виртуальный роутер, но адреса туннельного интерфейса нам всетаки нужны в общей таблице маршрутизации - тут и описана политика их импорта.
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 вообще, ибо на тех же бордерах где куча пиров конфигурация превращаеца в длиннющую портянку, что:

  • 1 - затрудняет чтение и понимание и в итоге дает
  • 2 - тебя же и тормозит и
  • 1+2 = 3 - увеличивает шанс твои шансы на ошибку😊

Вот только на циске можно != обязан, поэтому нужна некоторая дисциплина чтоп не допускать такого, а тут хош не хош а придется.

  • default-route-reject - срезает дефолт по in/out.
  • reject-uplink - срезает адреса с pppoe интерфейса к провайдеру - зачем они нам.
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;
    }
}

Отладка всего этого на кошке:

  • debug crypto isakmp - phase 1
  • debug crypto ipsec - phase 2

позырить ассоциации: 

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.

  • clear crypto isakmp - снесет phase 1 ключи и ассоциацию вобщем то целиком.
  • clear crypto session - снесет phase 2 ключи и ассоциации тоже.

Отладка на juniper:

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.

  • clear security ike security-associations - снесет phase 1 сессии и ключи.
  • clear security ipsec security-associations - снесет phase 2 сессии и ключи.

Comments on this page

2018-07-09 Networking-Blog

Networking-Blog

Итак пока я сыграв в русскую рулетку с каким то долбаебом на шоссере вывихнул себе правое плече и получил трещину в ребре благодаря чему появилось время продолжить написание данной писанинки продолжим😊

Cвязка squid + c-icap с моими любимыми шлюхами и блэкджеками (ака контент фильтрация) для себя любимого у меня стояла уже лет 10 как в качестве банерорезки и кеша, После начала позора роскомнадзора со своими блокировками я добавил в эту схему tor для обхода блокировок, и i2pd до кучи - хз зачем но пускай будет. Но я все время искал чем бы заменить сквид с его sslbump ибо для одного юзверя это даже не из пушки по воробьям а чето ближе к ядерной боеголовке. И не особо то находил, а без sslbump все это не имеет смысла, большая часть траффика идет по https, и его необходимо расковыривать для фильтрации баннеров и кеширования тоже. Плюс сквид это тот еще монстр и часто заточить его на чтото что вызывает standart violation без рашпиля (ковыряния в исходниках) бывает невозможно. Не для персонального использования он создан, он может не чхая переварить полгига траффика и тысячи юзверей - я правда проверял - может😊 но при этом иногда заставить его к примеру закешировать чтото что по стандарту кешироваца не должно весьма проблематично.

И тут, недавно, не помню уже с чего вдруг гдето выплыл выплыл у меня в поиске [[Glossary_wwwoffle?|wwwoffle]], который заточен какрас для персонального использования в противовес сквиду, и почемуто я решил на него глянуть, не помню уже почему - мошт просто делать нехер было. И полной неожиданностью оказалось что оно умеет mitm ака sslbump в сквиде типа из коропки, причем уже много лет, и кешировать https тоже умеет, ну и еще кучу всяких standart violation для которых squid нада затачивать что не всегда тривиально, а тут типа все есть. ну и сразу же я решил сие дело посмотреть и опробовать.

Вообще так как все это нужно для 1-2-3 добашних клиентов, требования ко всему этому очень просты:

  • Оно должно быть маленькое и простое, пофиг на производительность и масштабируемость. Хотя кстати тот же сквид кстати тормозил при старте на парсинге ACL'ей сгенерированных из списка РКН
  • Оно обязательно должно уметь mitm aka sslbump в сквиде для https.
  • Оно должно уметь роутить траффик по url спискам, ну тоесть к примеру http://www.gedanken.org.uk/software/wwwoffle/ - идем директом, https://rutracker.org/forum/viewforum.php?f=1958 - идем через некий parent прокси дабы обойти блокировку, и это должно работать и для https тоже, а url желательно с масками.
  • Так же оно должно бы уметь роутить и по dst ip адресам и подсетям, ну тоесть 1.1.1.0/22 идем директом, а 2.2.2.0/24 опять таки идем через некий parent proxy, хотя это опционально так как в случае socks прокси тора это решается на уровне системы связкой [[Glossary_tun2socks?|tun2socks]] + ipset + iproute.
  • Хорошо бы еслип оно умело делать преобразование socks<->http proxy, но тоже опционально - решаеца промежуточными прокси, к примеру 3proxy
  • Оно должно уметь блочить url по маскам дабы фильтровать рекламку и прочую дроч, желательно с возможностью подмены заблоченных ссылок на свои.
  • Неплохо было бы так же иметь контент-фильтрацию, хотя опять таки решается промежуточными прокси к примеру privoxy/bfilter.

Обход наших любимых роском/позо/надзо/ровских блокировок в linux и в gentoo в частности

Итак смотрим wwwoffle

Оно умеет далеко не все что нужно и списка выше. пойдем с конца:

  • контент фильтрации считай что нет = есть возможность прирезать какието конкретные hardcoded вещи в теле страниц но на этом все - никаких вам регэкспов итд.
  • преобразование socks<->http proxy нет, как и вообще нет поддержки socks ни сервера ни parent прокси, но есть ветка -par в которой есть socks parent - есть шанс портировать оттуда, но руки у меня до этого не дошли, выкрнутился через 3proxy
  • роутить parent proxy по dst ip тоже не умеет

Остальное все умеет, и кое чего сверху по мелочи. И да - оно маленькое и простое, и кривое😊

В 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, так родился третий патч, ну а четвертый мелкий фикс ворнинга - до кучи😊 Нну и пошло-поехало😊

Собсно сами патчи:

  • Patch_000-wwwoffle-2.9j-to-trunk.diff.bz2 - update до trunk версии из svn. правильнее было бы сделать отдельный ebuild но мне влом😊
  • Patch_100-certs-trunk-v3.patch - фикс рейса в генерации сертификатов.
  • Patch_110-SessionCookiesOnly.diff - опция позволяющая парсить set-cookie удаляя из них expire что делает их сессионными.
  • Patch_zzz100_reduce_RSA_BITS.patch - уменьшаем длинну RSA ключа - у меня на локалхосте нет хакеров которые будут снифать мой траффик и пытаца сломать ssl😊 зато генерит/шифрует/дешфрует быстрее и меньше нагружает entropy pool.
  • Patch_zzz100-fix_implicit_declaration_of_isspace_in_parce.c.diff - почемуто именно этот ворнинг меня задрал при сборке когда я чтото там патчил и я его поправил😊
  • Patch_zzz900_crash_fix_test_3.patch - Фикс сегфолтов, описано там ниже в конце секции о wwwoffle.
  • wwwoffle-ebuild.bz2 - ebuild если кому нужен, мой локальный оверлей из сети не доступен покашто.

На генте все эти патчи можно сложить в 

/etc/portage/patches/net-proxy/wwwoffle

и они применяца автоматом при сборке, ЕСЛИ! в ебилде вызов epatch_user в src_prepare(), а есть он блять не везде.. поэтому гдето это работает а гдето нет. Но есть способ сделать чтоп работало всегда и везде.

Вобщем наигравшись с исходниками и добившись какой-никакой но приемлемой работы я принялся играца с конфигурацией😊 Итак:

Настройка wwwoffle

Собственно конфигурация 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 и фтыкаеца галка юзать его для всех протоколов и на этом все.

  • https-port мне не понадобился, хз для чего он ваще.
  • wwwoffle-port который 8081 используется для упрвления, через него можно отдватать команды, ну там конфигурацию перечитать, кеш почистить итд.
  • max-servers=16 - ахули!!! у меня 4 процессорный 64головый аптерон блять!!! пусть работает😊 На самом деле wwwoffle мультипоточная, на каждое соединение порождает отдельный поток, и не умеет pipeline, так что сколько запросов от вашего бравзера прилетит столько потоков и нужно чтоп их обработать без блокировки, а 64/4=16 что является одной numa нодой, в пределах нее и будем работать посредством numa aware memory placement shceduler'а в ядре😊
  • max-fetch-servers задает количество потоков которые будут выгребать страницы запрошенные в offline mode как тока наступит online mode, но блять, щас 2018 год, какие еще вжопу оффлайны, но тем не менее у нее есть такой функционал, а так же wwwoffle можно просто сказать - выкачай мне вот эти страницы, в том числе можно даже рекурсивно, количество потоков которые выкачивать будут опять таки равно этому параметру, но так как все это мне нах не нада ставим 1.
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
}
  • log-level = info дабы лучше видеть что происходит, что закешировалось что нет ну итд.
  • reply-compressed-data поставил в no - заким хреном чтото жать при передаче через локалхост?
  • lock-files = yes - иначе есть засада если 2 разных потока получат запрос одной и той же страницы и начнуть допустим оба писать ее в спул кеша, поэтому используем локи.
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
}
  • Тут все url специфичные настройки типа <*:*/*.css> request-changed = 6w мои. Значат они что всякие картинки/иконки/пдфки/CSS/JS и прочий шит мы кешируем до усрачки на 6 недель, даже если нам будут говорить что так низзя, нинада, ну пажалуста... А перегрузить их можно только через CTRL-F5 ито если север на запрос if-modified-since скажет что они изменились.
  • Всякие css/js с параметрами, тоесть somesheet.js?track-user-id=xxx кешируем на 10 минут, если не говорят что низзя, но обычно говорят😊 оставил на всякий случай, пока же в другом месте запретил вообще кешировать динамику.
  • validate-with-etag = no - заебали все этим етагом, пихают куда ни попадя из за чего нихера не кешируеца - соотвественно тут мы на него забиваем полностью.
  • request-compressed-data/request-chunked-data = yes - запраивать компрессию у сервера - актуально при транзите через TOR.
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 в сквиде😊

  • enable-caching = yes - собсно включает расковыривание https, тоесть wwwoffle на стороне сервера выступает как обычный клиент - самостоятельно поднимает ssl/tls, шифртует/дешифрует, а со стороны клиента выглядит как сервер - тоесть генерирует фейковый сертификат для нужного домена и подсовывает его клиенту, чтоп это работало клиенту нада установить корневой сертификат сгенерированный wwwoffle при первом запуске, иначе мата не оберешся от бравзера по поводу самоподписанного сертификата и отсутствия цепочек для проверки, делается это просто через web интерфейс wwwoffle - тыркаем http://localhost:3128/certificates/root и там [Download Certificate]. Так же в бравзере нужно вырубить вот эти костыли - [[Glossary_HSTS?|HSTS - Strict transport Security]], [[Glossary_HPKP?|HPKP - Certifikate Key Pinning]] и [[Glossary_OCSP-Stapling?|OCSP Stapling]] иначе будет орать на некоторые сайты что сертификат нихуя не тот какой должен бы быть, еще может понадобица повключать weak chyphers, если применили Patch_zzz100_reduce_RSA_BITS.patch чем мы уменьшили длинну герерируемых фейковых сертификатов. Как это фсе сделать в ващем бравзере разбирайтесь сами, у меня на данный момент palemoon и там все это делается штатно в настройках безовсяких about:config + с помощью аддона pale moon commander можно тыркать криптоалгоритмы и много чего еще.
  • quick-key-gen = yes чтото там насчет источника энтропии в gnutls - насколько помню юзать какой то другой но менее надежный - но нам лучше быстро чем надежно ибо хакеров на локалхосте нет😊
  • allow-cache = *:443 - какрас включает расковыривание и кеширование https, маска хоста и порт.
  • disallow-cache = *.googlevideo.com:443 и allow-tunnel = *.googlevideo.com:443 - не расковыривать https - в данном случае это видео сервера ютуба зачем тратить ресурсы на дешифровку а потом шифровку видеопотоков когда можно просто туннелировать как обычные прокси. порядок директив имеет значение - срабатывает первая подходящая, поэтому они должны идти до allow-cache = *:443 в этой секции.
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
}

Эта секция позволяет делать некоторые манипуляции непосредственно с контентом страницы.

  • enable-modify-html = yes - включить/выключить секцию целиком.
  • site specific fixes разрешаем куки для определенных сайтов, для всех остальных толи совсем зарезаны толи только сессионные, не помню уже, дальше по ходу дела выясним😊
  • disable-meta-refresh = yes - вырезает мета тэги с рефрешем и редиректом на другую страницу, нах так делать то?
  • disable-meta-refresh-self = yes - вырезает мета теги с просто рефрешем страницы, в том числе периодическим - нах оно мне встряло, я сам обновлю когда мне понадобица, ато с моими 100500 вкладками всякой дрочи получается постоянно чтото дергаеца и обновляеца.
  • disable-meta-set-cookie = yes - не дает устанавливать куки через мета тэг.
  • disable-dontget-links = yes - убирает все ссылки попадающие в список в секции DontGet, секция DontGet предназначена какрас для фильтрации запросов по url.
  • replace-dontget-images = yes и replacement-dontget-image = /local/dontget/replacement.gif - если вырезаемая ссылка на картинку то вместо этого подставит картинку из /local/dontget/replacement.gif в спул директории.
  • replace-webbug-images = yes и replacement-webbug-image = /local/dontget/replacement.gif - детектирует какието бажные картинки и вырезает их, с заменой на локальную /local/dontget/replacement.gif, локальная - прозрачная гифка размером 1 пиксель.
  • disable-dontget-iframes = yes - вырезает iframe если он попадает под список в секции DontGet.
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

тут мы разрешаем куки на нужные мне сайты.

  • User-Agent = Mozilla/5.0 (X11; Linux x86_64; rv:3.4) Gecko/20100101 Goanna/20180717 PaleMoon/27.9.4 - жестко прописываем user-agent.
  • referer-self = yes выставляет referer в запрашиваемый url.
  • session-cookies-only = yes разрешаем только сессионные куки всем кроме нужных мне сайтов, такие куки удаляюца после закрытия вкладки или браузера.
  • пытаемся фильтровать какието левые хедеры с гихаба итд но чето не взлетело - гитхаб сломался, а четаки руки не дошли разобраца потому закоментировал просто.
Proxy
[
proxy_header
blocked_domains_rkn.list
blocked_urls_rkn.list
proxy_footer
]

А вот и секция парент прокси, именно тут разруливается что через какой вышестоящий прокси запрашивать, а что на прямую - сердце так сказать механизьма обхода блокировок позорного РКН. прокси указываются раздельно для http и https что не совсем удобно.

  • proxy_header и proxy_footer для ручного вмешательства так сказать, но первый должен быть всегда первым в секции, второй последним, иначе логика работы сломаеца.
  • blocked_domains_rkn.list - генерируется автоматом из списка РКН и представляет из себя список заблокированных доменов.
  • blocked_urls_rkn.list - генерируется автоматом из списка РКН и представляет из себя список заблокированных url.

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 недель😊

  • use-mtime = no - не использовать mtime - время последней модификации файла, вместо этого смотреть на atime - время последнего доступа к файлу, файл тут равен обьекту в кеше, это автоматом значит что ФС с кешем нельзя монтировать с noatime - будет не совсем правильно работать, тоесть будет удалять что угодно спустя 7 недель так как atime будет равен дате создания файла что равно времени когда обьект закешировали. но впринципе можно юзать relatime или lazytime если есть и если машина работает круглосуточно.
  • use-url = yes - оперировать урлами при очистке кеша, иначе будет смотреть только на протокол и хост.
  • del-dontget = yes - удалять сразу же все из кеша что попадает в DontGet список, удобно когда закешировал чтото не то или просто поправил DontGet - можно перечитать конфигурацию и запустить очистку.
  • del-dontcache = yes - тоже самое только для секции DontCache
  • age = 4w - максимальное время жизни обьекта. Если к нему небыло доступа в течении заданного промежутка времени то он удаляеца, это общее правило для всех у кого не указано индивидуально в начале секции.

Ох вроде все по конфигу 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:

  • wwwoffle -config - перечитать конфигурацию.
  • wwwoffle -purge - почистить кеш.

больше мне вроде особо ниче не нужно было, но там есть еще😊

По работе впринципе особых нареканий нет, не смотря на весьма обьемныей списки, к примеру только ркновские домены+урлы 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
}

По части кеширования можно хоть чтото прикрнуть вот так: ncdu

это наверное гдето за полмесяца, тоесть директория https в которой все что по https уже 2.4 гига, a http всего 213 мегабайт, что лиш подтверждает что на данный момент прокси без mitm в https потеряли актуальность чуть менее чем совсем.

Блять, неужели я наконец то дописал это😊 ладна теперь пойдем дальше:

Настройка TOR

Который нам нужен как средство обойти блокировки так как выходные ноды у него разбросаны по всему миру. Собсно конфиг:

/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

Стоит он у меня уже давно, поэтому я всех ньюансов уже не помню, только основные:

  • SOCKSPort 127.0.0.1:9050 NoIPv6Traffic NoIsolateClientAddr NoIsolateSOCKSAuth собсно адрес:порт на котором принимать socks соединения, NoIPv6Traffic - запретить ipv6, у меня он в системе отсутствует как класс, NoIsolateClientAddr - не изолировать клиентов на основе их адреса путем выделения отдельного circuit каждому клиенту, ну клиент то один - изолировать нехер по определению😊 NoIsolateSOCKSAuth - тоже самое только различает клиентов по авторизации на socks прокси, но авторизации тоже нет, клиент все еще 1 я поэтому опять таки изолировать нехер и потому нехер😊
  • DNSPort 127.0.0.2:53 NoIsolateClientAddr - очень полезный весчь - поднимает корявый и кривой dns сервир который резольвит через тор имена, но только A и AAAA помоему, ни MX ни че еще покруче не умеет впринципе, но зато туда можно потом форвардить запросы с бинда и пресечь dns-leaks или выкрутица если провайдер вкорень охуеет и начнет подменять/резать днс запросы/ответы. NoIsolateClientAddr то же самое что и до этого.

Следующие 3 строчки делают еще 1 полезную весчь называемую dns resolver automap, суть в том что при запросе внутреннего ресурса в зоне .onion, вот тот внутренний днс сервер выдает ему левый ип из определенного диапазона, и сопоставляет с той белибердой называемой внутренними адресами в сети тор, благодаря чему, любой софт может обратица к данному ресурсу и не обламаца при днс резольвинге пока живо это сопоставление.

  • AutomapHostsSuffixes .onion - для какой зоны вкдючать этот автомаппинг, пока вроде есть только .onion
  • VirtualAddrNetworkIPv4 169.254.0.0/16 - подсеть из которой пэпить адреса, это вроде link-local которая мне нахер не нужна нигде и никогда.
  • AutomapHostsOnResolve 1 - собсно включить этот автомэппинг.

У меня этот автомэппинг работает в связке с tun2socks, это по сути обычный tun интерфейс в системе в который отроучена 169.254.0.0/16, другим концом он цепляеца на socks сервер тора, правда умеет он тока TCP но udp через тор не особо то и нада с его то лагами. ну и плюс форвардинг с локального днс сервера. Таким образом в onion может лазить вообще любой софт, ему не нужен никакой прокси, он просто запрашивает у локального днс сервера адрес, тот лезет на днс сервер тора с той же целью, сервер тора отвечат и сразу делает мэппинг, после чего приложение работает как обычно - все адреса из мэппинга то отроучены в tun, не нужно уметь никакой socks прокси вообще. Таким же образом работает и ipset с заблокированными подсетями, только тут уже даже и мэппинг не нужен - главное отправить траффик на этот адрес через tun интерфейс.

  • TrackHostExits . - да да - там точка😊 нужно для того чтоп при запросах к одному и тому же dst ip использовалась одна и та же exit node что означает один и тот же ip адрес, нужно потому что некоторые форумы очень не любят когда авторизованный пользователь скачет по разным ip в рамках форумной сессии и получается ой, а тор без этой хрени может вообще для каждого запроса выбрать разные exit node к примеру, плюс это получается быстрее, правда документация утверждает что галактекапасносте и при этом вас могут отследить но мне насрать на это - я ниче такого не делаю каму я нах нужен меня отслеживать😊
  • TrackHostExitsExpire 600 - таймаут сопоставления dst ip-exit node, после него выбирается новая exit node, правда с этим есть косяк - если нода уйдет в даун - фсе сломаеца, почемуто он не вабирает новую пока таймаут не коньчица. какой далбаеб так придумал яхз, хотя может уже поправили, много времени уже прошло с тех пор как я это ковырял.
  • GeoIPExcludeUnknown 0 - не удалять неизвестные по мнению geoip базы а так же из A1(че за а1???) из exit node и транзитных нод.
  • ExcludeExitNodes {ru},{??} - удалить по мнению geoip российские -{ru} и неизвестногде {??} ноды из выходных нод - иначе будем нарываца на те же блокировки если нода находица в россси. Правда блокировки есть не только в россси, поэтому можно нарваца на другие блокировки, в других странах и местах, но это не так страшно - всегда можно сменить exit node в ручную или заэксклудить всю страну/подсеть.
  • ClientOnly 1 - использовать только клиентскую часть - у меня нет никаких сервисов в сети тор, покашто😊 в ip2 есть этот сайтик зато, до тора руки не дошли еще да и не хочеца прикладывать то особо потому что когда то давно некоторое время я был транзитной нодой, когда был у меня белый ip, потом я переехал и его не стало, а серверная часть тора через нат работает мягко говоря через жопу - ему почемуто нада задать и внутренний серый локальный ip машины и внешний ip ната, пробросить порты, подождать сполчаса пока он это проверит, если заебись то тогда работает, а у меня и серый и натовский белый адреса динамические, и как блять быть???? I2PD тут же шпарит из коробки - похуйна нат, даже на двойной ибо я за роутером еще. а тут присягаблязатрах, ип сменился - и че? мне конфиги править каждый день? да нахер нада...

Вот вроде бы и все что я смог вспомнить с тором то.

Вобщем дальше настало время связующего звена между тором и wwwoffle в виде 3proxy в позе http/s=>socks прокси. В случае сквида оно было не нужно, там я через ацл мог сразу отправить запрос через тот самый tun2socks интерфейс и не парица - оно просто работало, wwwoffle так не может, и нужно промежуточное звено, тоже долго искал... чучуть поработал с tinyproxy который пришлось пропатчить на предмет поддержки socks, но потом всетаки остановился на [Glossary_3proxy|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

ну тут впринципе все понятно😊

  • config /etc/3proxy/3proxy.cfg - путь к конфигу, насколько я понял используется в случае если сервер рестартует сам себя, так то при старте ему с командной строки конфиг указывается.
  • setgid 990 и setuid 999 - вытсавляют uid/gid процесса, тоесть он сбрасывает права, я создал специально системного юзера под него, не помню как - не спрашивайте, в конце концов если вы этого не можете то вам тут ваще читать нехер - всеравно нихера не сделаете😊 их нада ближе к началу, и до pidfile, иначе будет ой, 2 штуки, но мне лень расписывать каких и почему😊
  • daemon - стать демоном😊 тоже лучше ближе к началу и до pidfile, ато он сделает форк и в pidfile будет старый pid, из за чего не получица потом сделать ни стоп ни релоад через init скрипт, вообще тут идеология такова что он тупо читает этот файл и тут же выполняет все по очереди, как интерпретатор, в отличии от других у которых просто набор опций, которые сначала все читаются и формируется конечная конфигурация а потом уже включается логика на ее основе, тут не так.
  • internal 10.32.75.177 - задает внутренний ip по умолчанию, внутренний тут значит тот на котором он ожидает клиентские запросы, какие бы то нибыло, можно задать другой для конкретного сервиса, а если в сервисе не указан явно то будет этот.
  • external 127.0.0.1 задает внешний ip по умолчанию, внешний тут значит тот с которого он будет делать запросы в мир, можно задать другой для конкретного сервиса, а если в сервисе не указан явно то будет этот. 127.0.0.1 тут потому что нам мир ваще не нужен - мы локальный прокси между двумя другими локальными прокси.
  • nserver 127.0.0.1 - адрес днс сервера, автор рекомендует указывать тут, хотя если не указать он юзает системный, но гдето у него были какието грабли с libc при этом поэтому он рекомендует указать тут😊 ну нам не жалко - укажем на свой локальный бинд.
  • fakeresolve резольвить все в 127.0.0.2, не совсем понятна эта хрень, используется когда резольвинг вообще не нужен, к примеру при socks5 и http parent'ах - резольвит parent прокси, нам это не нужно, но если нам это не нужно нахрена чтото резольвить в 127.0.0.2? не понятно нихуя ну да ладно - автор рекомендует это юзать в нашей ситуации - не будем спорить😊
  • log /var/log/3proxy/3proxy.log D - куда писать лог, и как часто ротейтить - D каждый день, логи он ротейтит сам, совсем сам - сам ротейтит сам пакует, сам удаляет старые... впервый рас такое вижу😊
  • logformat "L%d-%m-%Y %H:%M:%S.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T" формат лога - я там формат времени поменял, но уже точно не помню че да как, в документации смотрите но сдаеца мне что это L%d-%m-%Y %H:%M:%S.%.
  • archiver gz /bin/gzip %F - команда архивирования логов.
  • rotate 30 - ротация логов, будет хранить за последние 30 дней.
  • users $/etc/3proxy/.proxyauth таким вот макаром он инклудит кусок конфига из другого файла, в данном случае там логины с паролями которые я пытался заюзать на socks->http с работы, но как оказалось у браузеров неожиданно socks авторизация мягко говоря бывает прихрамывает, и пока у меня с этим нихуя не вышло - зарезал доступ по ip фаером.

дальше собственно кусок который какрас реализует http->socks между wwwoffle и тором:

  • maxconn 64 - максимальное число соединений - действует на все сервисы после данной команды.
  • auth iponly - авторизация по ip, есть и другие, нам тут авторизация не нужна, нам нужен тупо транзит, всеравно оно все на lo крутица - никто туда не достанет, и есть такая - none, но при none не работают ACL'и с ip, так что придеца юзать iponly
  • allow * 127.0.0.0/8 * * * - разрешить все всем со всех адресов локальной петли.
  • parent 1000 socks5+ 127.0.0.1 9050 - а вот этот финт ушами обязательно должен идти только после предыдущего allow, почему так читайте в официальной документации. и делает он какрас то что нам нада - отправляет все на socks сервер тора, 1000 это типа вес данного парента, их может быть несколько и выбираца они могут на основе веса, socks5+ - протокол, + означает резольвить имена через вышестоящий прокси, 127.0.0.1 9050 соответственно адрес и порт вышестоящего прокси.
  • allow * 127.0.0.0/8 * * HTTP,HTTPS разрешить HTTP и HTTPS запросы с петлевой подсети на локальный http прокси, который должен идти именно за этим allow, почему так читайте выше😊
  • proxy -a -n -p8888 -i127.0.0.1 -e127.0.0.1 - запускает http прокси сервер, -a значит анонимный, тока хз что это значит в точности - не написано😊 -n откючает NTLM авторизацию, -p8888 - на каком порту слушать, -i127.0.0.1 -e127.0.0.1 это тоже самое что internal/external выше но только для даного конкретного сервиса, тоесть по сути это оверврайтинг того что в internal/external.
  • flush - сбрасывает все предыдущие ACL'и, как точно это работает я не разобрался, но как я понял начиная с auth он их запоминает и применяет ко всем сервисам какие описаны пока не наткнеца на flush, после чего можно опять написать auth и другие ACL'и для других сервисов, и они не будут никак пересекаца с предыдущими.
  • pidfile /run/3proxy.pid - куда писать pid, лучще чтоп оно было в конце, ато он там в некоторых случаях форкаеца в процессе а пид не перезаписывает.

Вот впринципе и все, запускаеца он путем 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 и сопуствующая хрень

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.

  • tun2sock0 - имя интерфейса.
  • preup() - функция запускаемая перед попыткой сконфигурировать интерфейс, тут собственно стартует tun2socks, --netif-ipaddr 100.64.0.2 - адрес типа виртуального роутера - по сути аналог маршрута по умолчанию, --netif-netmask 255.255.255.252 - маска интерфейса, они же потом используется в конфигурации интерфейса, тоесть они не от балды😊 --socks-server-addr 127.0.0.1:9050 - ip адрес:порт socks сервера tor, ну оставшееся понятно наверное итак - логгинг через syslog с facility local, sysctl net.ipv4.conf.${IFACE}.rp_filter=0 - отключает reverce path filtering для данного интерфейса, иначе система отбросит все пакеты которые исходят не с подсетей на этом интерфейсе и ниче соответственно работать не будет.
  • postdown() - функция запускаемая ппосле деактивации и деконфигурирования интерфейса - тут нам просто нужно прибить процесс и удалить интерфейс.
  • config_tun2sock0="100.64.0.1 netmask 255.255.255.252 brd 100.64.0.3" стандартное обьявление адресов на интерфейсе, я взял из этого диапазона так как он редко используется в локалках и вероятность пересечься с чем то крайне мала.
  • rules_tun2sock0 - PBR - все с подсети 100.64.0.0/30 роутим через отдельную таблицу маршрутизации tun2socks, так же через нее же роутим все что имеет fw метку 10.
  • routes_tun2sock0 - маршрут по умолчанию в таблице tun2socks, и туда же роутим все что идет на подсеть для мэппинга имен в tor - 169.254.0.0/16. эти параметры писать как есть - в 2 строки или скока там, иначе не сработает.

так же нада добавить таблицу маршрутизации 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 а не через дефолт, разберем подробней:

  • -p tcp - только tcp
  • -m multiport --dports 443,80 - расширение multiport - позволяет задавать список портов за рас, тут у нас порты назначения 80 и 443.
  • -m owner --uid-owner wwwoffle --gid-owner wwwoffle - основное колдунство😊 - классифицирует гокальный траффик на основе идентификаторов пользователя/группы процесса, тут мы выделяем траффик wwwoffle - только от нее он будет идти через tun2socks.
  • -m set --match-set blocked_ip_rkn dst - расширение set - для проверок в ipset, тут собсно проверяем что ip адрес назначения попадает в ipset blocked_ip_rkn.
  • -j MARK --set-mark 10 собсно таргет всего данного правила - выставить метку 10, по которой потом правилом from all fwmark 0xa lookup tun2socks и маршрутизируется траффик по таблице tun2socks, в которой 1 маршрут - через интерфейс 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

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";

Впринципе тут ничего особенного нет:

  • acl "trusted" - перечисляем сети которые обслуживаем, и соотвественно с которых принимаем рекурсивные запросы - исправляйте на свои.
  • acl "icf_masters" - это авторитативные сервера на работе, нужны потому что делаем оттуда трансфер нужных по работе зон на локальный сервер, в основном это локальные зоны в которых торчат managment интерфейсы всяких железок, дабы были всегда под рукой, помогает в случае каких либо факапов или аварий когда днс сервера не доступны. вам такое врятли нужно так что можете удалить, и все на что будет материца после удаления тоже😊
  • masters "icf_masters" - то же самое только не ацл, до кучи я отдаю локальную домашнюю зону на сервера на работе дабы домашняя сеть тоже резольвилась, ну тоесть у меня вообще все прозрачно по сути😊 так же можете удалить как и предыдущую опцию.
  • server 127.0.0.2 - описание кривого резольвера в tor - так как он кривой - прилось повырубать на нем все что тока можно чтоп хоть как то работал форвард на него.
  • listen-on { 127.0.0.1; 10.32.75.177; }; - биндимся на lo и 10.32.75.177 - локальный адрес машины собсно.
  • zone "lan." IN { и далее - моя локальная зона - вам тоже врятли нужна так что тоже лучше грохнуть.
  • include "/bla/bla/bla" как следует из описания втыкает в конфигурацию внешний файл, там какрас описанные выше мои локальные и рабочие зоны которые вам не нужна так что тоже удаляем, все кроме 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 с них.

  • masters "root_xfr_masters" - список корневых серверов допускахющих transfer - не на всех серверах разрешено, но на многих как видите по списку.
  • masters "icann_xfr" - у icann так же есть сервера специально для этого дабы не дергать корневые - тут собственно перечислены они.

Вдобавок я тяну не только корневые зоны, но и обратку и обратки для подсетей, часть из этого доступно как с корневых так и с icann серверов, часть только с icann, поэтому разные значения в masters для зон.

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

Comments on this page

2018-05-15 Blog

Нанотехнологии😊

Нано это ноу-хау великих мужей
С нано жить лучше, жить веселей
Нано это круто, поверьте, ребята
Нано это десять в минус девятой!
Нано мечты, воплощенные реальность.
Нано это шанс доказать свою лояльность
Без нано что будет? Коллапс и разруха,
А с нано улыбка от уха до уха,

И с нано, у причастных, сытое брюхо.

Comments on this page

2017-12-23 Web-Blog

Web-Blog

Вобщем после создания сего сайта который вы счас читаете, как это водица - одолели спам-боты, коментарии были открыты всем, и вот начали они мне туда "комментировать"😊

Вывод - привернуть регистрацию, а для этого нужна почта, причем на этой же машине где крутица движок сайта.

А ее то тут и нету, вообще, даже локальной, тоесть MTA отсутствует напрочь, а как то мыло для регистрации слать нада. Вобщем то движок при отсылке дергает sendmail как все остальные милионы движков, все стандартно. Поэтому нада чтото что могло бы выступать заменой sendmail'у. Выходы:

  1. поставить MTA и настроить форвардинг всей почты на почтовый сервер. как правило в составе любого MTA есть затычка аля sendmail.
  2. поискать чтото аля fetchmail наоборот, ну или какойнить совсем легкий MTA чтоп всю локальную почту форвардило через акаунт на почтовом сервере, тоесть по сути 1 хрен вариант 1 но только это будет уже не из пушки по воробьям как в случае полноценного MTA

И такие варианты нашлись, аж несколько. Начал смотреть и пробовать:

  1. esmtp отложил как last resort сразу - на страничке проэкта надпись THIS PROJECT IS NO LONGER BEING MAINTAINED.
  2. ssmtp завел, настроил, и exim на почтовом сервере мне сказал SMTP protocol synchronization error, это значит что ssmtp пытается слать команды до того как почтовый сервер выдаст ему приглашение, что в свою очередь значит что ssmtp херова следует стандартам и по сему я его забраковал после этого как поделие какованить очередного криворукого далбаеба, вдобавок он работает в синхронном режиме - тоесть ктото дернул там mail/sendmail, он тут же начинает слать в том же процессе, если не удачно ну чтож - обидно, досадно, но ладно - тоесть никакой очереди и ретраев у него нет. пока не отослал или не получил отлуп процесс блокируется, что опять таки намекает на криворуких далбаебов.
  3. nullmailer завелся не сразу, почемуто localhost в /etc/nullmailer/me ему не понравилось - выплевывал какуюто непонятную ошибку при попытке отправить что либо даже не доходя до smtp, тоесть выплевывал сам еще до того как поместить письмо в свою локальную очередь, хз почему, но после того как туда вписал домен от которого собираюсь слать все наладилось и заработало. Так же он имеет очередь, тоесть доставка асинхронна в отличии от варианта 2, и если сразу доставить не удалось будет пытаца потом сделать это снова.
  4. masqmail последняя версия от 2015 года, в генте вообще отсутствует - отмел так как вариант 3 задачу решает и присутствует в генте штатно, а именно она стоит на этом сервере.

Итак, выбор пал на nullmailer. Далее собсно более подробно о настройке nullmailer ибо она не тривиальна, а очень тривиальна😊 Всего 4 строчки(ну мне просто делать нех и я тут печатаю хрень всякую😊 Рас уж начал - нада дописать до конца😊

Итак, Nullmailer или fetchmail наоборот😊

Слать почту мы будем через акканут srv@megaprovider.ru на одноименном сервере - megaprovider.ru😊

Конфигурация находица в /etc/nullmailer

  • /etc/nullmailer/adminaddr - email адрес администратора, туда будет идти вся почта для рута итд, у меня тут - bottleman@megaprovider.ru
  • /etc/nullmailer/defaultdomain - домен по умолчанию - megaprovider.ru.
  • /etc/nullmailer/me - ? кто я? тут FQDN машины на которой работает nullmailer, или ip на худой конец если , им он будет представляца в EHLO и MAIL FROM в сессии к почтовому серверу, так что localhost с большой вероятностью не прокатит.
  • /etc/nullmailer/remotes - наверное единственное что в нем хоть какой то настройкой назвать можно😊 вообще не знаю зачем для него аж 4 файла конфигурации, все уместилось бы в 1😊 но есть как есть, итак, в remotes собсно описывается сервер на который отсылать почту.
megaprovider.ru smtp starttls insecure user=логин pass=пароль

и, все😊 Шлет, эмулирует при этом команду sendmail, так что все что заточено слать через нее будет работать и с nullmailer.

Единственное что я сначала напоролся на insecure - без него вякает на сертификат на сервере, но нифига не ясно на что именно, естественно возникла мысль что так как он там самоподписанный то может на него вякать, и методом тыка (добавлением insecure) это было подтверждено.

Comments on this page

2017-12-22 Networking-Blog

Blog

Беда не приходит одна - эпопея продолжается😊 Скоро переплюнем сантабарбару

После вот этого когда кризис вроде бы отступил, появилось время подумать😊

После осознания того, что с 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 полностью идентичных, и до вчерашней замены сетевых проблем небыло приходит логичный вывод что одна из тех бродкомов полудохлая и проблемы из за нее.

Так что, продолжение следует😊

Comments on this page

2017-12-21 Networking-Blog

Blog

Продолжаем мультилогию про беды, которые судя по всему не то что по одной не приходят, а и по 2-3 тоже, валят пачками😊

Вобщем беда четвертая:

Итак, в свете вот этого берем мы "новый сервир" почему в кавычках? да потому что берем мы в срочном порядке что есть, а есть у нас супермикра 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 с любой точки сети, не только нашей, а глобальной😊 Тоесть он открыт всему миру😊 ну а что, удобной - я вот начал лить инбандом - даже делать с ним ниче не пришлось😊

Comments on this page

2017-12-20 Networking-Blog

Беда как говорица не приходит одна

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

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 сервир как то пережил нагрузку с дикими тормозами пока первый не загрузица, на втором ситуация повторилась, пришлось тоже перегрузить.

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

Comments on this page

2017-12-19 Networking-Blog

Хакнули комутатор cisco

Все почемуто относяца ко всяким комутаторам и маршрутизаторам как к железке, которая типа целиком вся в железе и софта там нет, и поэтому она не ломаеца иначе как физически, и вообще не поколебима и нерушима😊 Только вот это нихрена не так, везде есть софт, и даже в железе тоже есть ошибки допущенные при проэктировании.

Ну чтож, вот и нас петя клюнул в одно место, пока правда не сильно больно😊 Так - фигня - на полшишечки😊

Древнючий 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 может быть вообще ни причем, этого мы уже наверное никогда не узнаем.

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

Ну или можно предположить что пароль ушол, но тут возникает ряд других вопросов:

  1. каму мы нах нужны?
  2. почему ничего не сделали?

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

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

При автоматизировнных взломах напротив - цели вывести из строя то что взломали нет, есть цель использовать то что взломали в своих целях в том числе - чаще всего для построения ботнета - взломанная единица присоединяеца к остальному милиону ботов и делает что им скажут, при этом взломанная единица в идеале выполняет свои основные функции как ни в чем не бывало, ведь иначе когда чтото перестанет работать это обязательно заметят, даже если троян будет всячески маскировать свое присутствие (отказ коммутатора коммутировать не замаскируеш😊 и примут меры, а так всем хорошо - и хакерам и лохам которых поимели😊

Поэтому скорее всего это автоматизированный взлом, просто куча роботов автоматом ищет уязвимые железки (и циско не исключение в их длиннющем спике) и хакает дабы потом использовать для рассылки спама или еще чего либо на чем можно заработать. Так же как и с ssh на серверах.

Хотя с другой строны хз на что может быть способен бекдор на комутаторе, анализировать траффик на самом комутаторе не выйдет, этож древняя циска, и там процессор чуть мощьнее чем в калькуляторе ситизен, но зато там есть средства типа PBR которые работают тупо в железе и поэтому на wire speed, и вот ими уже возможно, можно к примеру выделить нужный траффик и развернуть его куда нада и там уже анализировать чем нить мощьным, и к примеру таким образом воровать акаунты/пароли/кредитки и прочую дрочь юзеров и админов, чей траффик через него ходит и на него.

Весь прикол еще и в том что и средств то для какой либо диагностики таких факапов по сути нет, учитывая что он пока в работе, а если предположить что троян то все еще груснее - даже если его вывести из эксплуатации единственный способ что либо сделать это включить его и загрузить, и трояна если он там есть и неизвестно на что способен соответственно тоже, без этого никак - флэш встроенная, перепрошивка опять таки то же самое - гарантий что этот троян не встроит себя автоматом в новую прошивку нет. Можно разьве что с роммона грузануть по сети или прям с терминала и надеяца что его это не затронуло. А так ну если только выпаивать и читать чем либо уже с компа но он не стоит такого гемороя да и денег тоже.

Так что, не проебывайте аклы, и сверяйте crc с кошкодомом когда вливаете краденный иос😊 Следите за обновлениями и секюрити фиксами. И даже это на 100% ничего не гарантирует.

Comments on this page

More...

Learn more...

2017-12-13 Web-Blog

Blog

Learn more...


Comments on Mainbottleman@megaprovider.ru