id: Гость   вход   регистрация
текущее время 09:45 09/11/2024
Автор темы: unknown, тема открыта 20/02/2015 11:48 Печать
Категории: инфобезопасность, безопасная разработка, сайт проекта, руководства, разное, офф-топик
https://www.pgpru.com/Форум/Офф-топик/ПродвинутыеПодходыПоддержанияИБDSLMetaprogrammingetc
создать
просмотр
ссылки

Продвинутые подходы поддержания ИБ: DSL, Metaprogramming etc


Тред отделён как сборник неконструктивных, неконкретных и общих коментов от документа Policy-based-фильтрация с помощью iptables.


Предлагается обсуждать избыточность/приемлемость каких-либо концептуально сложных системных подходов для поддержания ИБ. Не только на примере iptables, но и для управления/конфигурирования всего остального.



 
На страницу: 1, 2 След.
Комментарии
— unknown (17/02/2015 10:14, исправлен 17/02/2015 11:40)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

К сожалению, никакой конструктивной критики предложить не могу. Могу только описывать с печальными примерами из своего и окружающего опыта, почему данное ненужно действительно не нужно.


  1. Для тех, кто знает iptables ещё со времён ipchains, никакие надстройки над ним не нужны. Лучше однообразный и примитивный скрипт с кучей повторений, чем этот ужасный самопально-велосипедный синтаксический сахар. Возьмите у любого админа настройки чего-то сложного на сети из тысяч компов. Там обычное перечисление правил с коментами. И всё понятно любому его коллеге. За свой метаязык админа поубивали бы. Т.е. длинными списками iptables вполне можно обойтись.
  2. Самопальный метаязык над iptables не нужен. Лучше мучаться до тех пор, пока в iptables не поменяют синтаксис или не прикрутят к нему штатный метаязык из коробки, но лишь бы не самопал. Например, над TeX есть стандартный штатный метаязык LaTeX. LaTeX — нужен. А над LaTeX некоторые пытались внедрить LyX. LyX — не нужен. Если при первом взгляде на LyX человек этого не понимает, то объяснять бесполезно. Пусть пройдёт через все шишки сам: одним набором через графинтерфейс не отделаться, нужно изучать вставки LyX, под ним лезть вставками в LaTeX, пока не закончится тем, что проще выучить LaTeX и всё.
  3. Метаязыки и метасинтаксис на шелле особенно не нужны. Он не для этого.
  4. Выжимать из шелла что-то слишком сложное не нужно. Это может дойти до того, что в нём пытаются городить хитрые парсеры, сложные функции, эмулированные объекты, подгружаемые библиотеки, а в итоге переходят на питон, перл, руби или что-то подобное, в чём можно поддерживать большой сложный проект. Шелл — для простого, метаязык и велосипедный синтаксис на нём сложно поддерживать, как и любые большие сложные проекты. После очередного обновления системы вам придётся перепроверять все скрипты, параметры и пр., что было проще сделать в «тупом» скрипте без хитрой логики внутри. Любой sed, awk, grep и пр. вас могут подставить, хуже того, если это будет незаметно. Шелл — это простой склеиватель утилит, не надо из него пытаться сделать полноценный скриптовый язык программирования.

Т.е. иногда более высокие абстракции и автоматизация — полезны. Но в случаях, подобных вашему, на поддержание «упрощающего» синтаксиса в перспективе будет потрачено больше усилий, чем на использование стандартного. Это как эмуляция экскаватора с помощью лопаты, колеса, верёвки и прочих подручных средств: и котлован не выроете, и нормальный экскаватор не создадите. Только время потратите впустую.



Смиритесь с этим. Или напишите полную альтернативу iptables на уровне утилиты и ядра. Только не скриптовые костыли.



Сколько пришлось видеть такого пионерства, которое себя не оправдало, даже сам когда-то таким страдал :)



Тоже симптоматично. С какого-то предела, проще выучить чуть более длинные команды, чем поддерживать массу самопальных алиасов.



Жесть какая. Если бы я перешёл на систему с pf, то выучил бы именно его синтаксис, а не писал бы метаязык для работы с ним (да ещё и на шелле!), эмулирующий более привычный мне iptables. Это всё равно, что к офисному пакету придумывать эмулятор LaTeX и наоборот. Выучите оба, если нужно, но не скрещивайте в самопального монстра.


Хотя, возможно, хорошо, что вы со своей упоротостью только скриптоманией страдаете, но не пишите коммиты в утилиты и в ядро, а то вот узнает Леннарт Поттеринг про ваши идеи и запихает iptables в systemd. Тогда всё, приехали. Судя по описанию поставленных целей, начальная стадия синдрома Поттеринга у вас уже заметна. Хотя это не буквально всё про вас. Просто приходилось сталкиваться с такими улучшателями, которые вредные улучшения красочно и якобы убедительно расписывают как полезные и с большим энтузиазмом пропихивают.

— Гость (17/02/2015 13:13)   <#>

Как вы можете догадаться, скрипт я писал самостоятельно. Прежде, чем его писать, мне пришлось ознакомиться с iptables хотя бы на уровне самого базового функционала.


Загрузите правила, выполните iptables-save и получите свои любимые длинные списки, если они действительно нужны. Скрипт ужасен, но я сразу сказал, что он для бедных. У меня нет ни нужной квалификации, ни желания делать полноценный DSL. Но если скрипт упрощает работу хотя бы мне, он полезен.


Такое впечатление, что здесь открылся филиал ЛОРа. Unknown, вы с программированием когда-то были связаны? У вас есть базовые знания хотя бы? Я имею в виду не тяжёлое советкое ассемблерное низкоуровневое наследие с нулевой культурой в IT и CS, а настоящее программирование — то, чему учат в MIT? Вы создавали когда-нибудь свой ЯП? Вы писали на LISPе? Вы понимаете, что такое программирование в самом общем виде, как закладывается синтаксис и семанитика в том или ином языке, зачем? Вы слышали фразу, что любой сложный проект наполовину состоит из своего собственного костыльного и кривого интерпретатора LISPа? Если у нас нет общей базы, о чём мы могли бы с вами поговорить, то можно только покидаться говном. Вы мне напишете, что ненужно, а я вам скажу идти в детский сад, подучить матчасть. Для начала хотя бы осознайте классическую критику принципа worse is better, и почему этот растиражированный всюду в оупенсорсе принцип уё*щен. Это умные люди с именем писали, ознакомьтесь.

Одно из следствий WiB в UNIX выржается в том, что раз мы делаем программы настолько простыми, насколько это можно, вся сложность перекладывается с компьютера на человека. Вместо того, чтобы поручить все низкоуровневые вещи компьтеру, вы сами становитесь компьютером и выполняете за него его работу. Специалисты вообще мыслят в категории DSL. Они не пользуются ЯП в классическом понимании этого слова. Вам нужно решить конкретную задачу? ОК, быстренько набросаем синтаксис, какой нам удобен и уместен под неё, получим свой in sutu ЯП под задачу — domain specific language (DSL), потом на нём красиво и изящно всё напишем. Получается концептуально и просто. Но для того, чтоб так уметь, нужно знать программирование, и знать не в смысле синтаксиса конкретного ЯП, а в самом общем, что реализует собой LISP. Я тоже это всё не знаю, но у меня хотя бы есть общее понимание проблемы, сложившееся от общения с компетентными людьми.


Мне нужно решение сейчас, а не через 20 лет. В самопале нет ничего плохого, если отстутствует достойная альтернатива.


Аналогия вообще не тему. LyX — это не метаязык поверх LaTeX, а визуальный редактор для него. Правильной аналогией было бы «нафиг нам стилевые файлы в LaTeX, пишите для каждой pdf'ки всё in situ, со всеми кишками!». Стилевой файл — это, знаете ли, функции и скриптинг. Считайте, что я тоже написал свой консольный стилевик для iptables.


Ещё раз: у меня нет проблем со знанием iptables. :-) Вот если бы кто-то пытался взять мой скрипт и использовать его без понимания iptables, можно было бы говорить.


С этим согласен, но в моём случае речь шла о том, чтобы либо сделать быстро хоть что-то и на чём-то, либо не сделать вообще ничего. До этого я годами использовал iptables-кишки, как и все остальные.


Я полностью согласен. Но даже если б я знал условный python, всё равно, не было планов писать полноценный серьёзный интерпретатор. Более того, насколько я слышал, были разные попытки написать конвертор правил из iptables в pf и обратно, но я специально их не искал — я не хочу полагаться на чужой и возможно костыльный проект, а в своём я досконально знаю кажду функцию, что она делает.


Их синтаксис, как и синтаксис iptables, не меняется десятилетиями годами ни на йоту, а базовые регекспы, которыми я воспользовался, не меняются со времён 70-ых. У меня есть старая книжка по очень дервнему коммерческому UNIX'у (тогда ещё даже персоналок не было), так вот, там всё точь-в-точь так же.


Нет. Я в какой-то момент, может, с год назад, написал этот скрипт, после этого он практически не менялся. После того я успел много раз порадоваться тому, что не надо каждый раз лазить по сотням строк и искать, что там закомментировать, а что раскомментировать, чтобы включить/отключить нужное. Теперь всё легко и понятно, находится в одном месте. Одну строчку раскомментировал — опция заработала, одну закомментировал — отключил.


С чего это я должен смиряться, если есть способ упростить жизнь?


Соломоново решение «всё или ничего» не всегда мудро.


Я не знаю ситуаций, о которых вы говорите, чтобы комментировать по существу. У меня есть только свой личный опыт.


Дело не в знании команд, а в естественности! Почему я должен писать длинные команды по 100 раз, когда можно сократить? Алиасы за тем и были придуманы. Может быть, вы против вообще всех алиасов на шелле и скриптинга? Ваши аргументы к этому случаю тоже применимы: не пишите функции, не создавайте алиасы, каждый раз вбивайте в командной строке всё, что вам нужно с нуля, т.к. «проще выучить язык, чем городить самопальные функции» — так что ли?


Повторяю ещё раз, жирным: я знаю синтаксис iptables, иначе этот конвертор я не смог бы написать. А писал я конвертор не потому, что у меня с синтаксисом туго, а потому, что мне нужен не какой-нибудь ассмеблерный конечный автомат, а вменяемый policy based файерволл! Это вообще не о синтаксисе (если вы способны понять, о чём я пишу). Синтаксис можно было бы написать другой, просто взял тот, к какому уже привык. «Policy based» означает, что я задаю и мыслю, программируя, в рамках политик, а не правил. Чувствуете отличие? Это разговор с файерволллом на человеческом языке, а не на языке асма. Я ему объясняю, что должно быть разрешено, а что запрещено (как и в pf), а не описываю, как это сделать с помощью конкретных правил. Конкретные правила пусть за меня компьютер додумывает, а я займусь чем-нибудь более полезным.


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

Откуда это всё берётся — понять просто. Когда вы реализуете конкретно свою задачу на iptables, выясняется, что вам нужен 1% от его возможностей. Поэтому разумно этот 1% отразить и в синтаксисе — сделать практичнее, жертвуя универсальностью. Потом, если вы видите, что одно и то же требуется написать 5 раз подряд с чуть другими портами, вам любой программист скажет: пишите функцию.

Чтобы вам было понятнее, убрал все алиасы:
allow_out(){
    # This function allows outgoing traffic and the corresponding replies
    # The network myIP/24 is blocked
    local intf=$1
    local our_proto=$2
    local srcIP=$3    # local IP
    local dstIP=$4    # remote IP
    local dstPORT=$5    # remote port
    local our_user=$6
    if [ $dstIP = all ]; then
        if [ $our_proto = tcp ]; then
            iptables  -A OUTPUT -j ACCEPT -o $intf -p tcp -s $srcIP \
                ! -d $srcIP/24 -m tcp --dport $dstPORT -m owner \
                --uid-owner $our_user
            iptables  -A INPUT  -j ACCEPT -i $intf -p tcp ! -s $srcIP/24 \
                -m tcp --sport $dstPORT -d $srcIP -m state --state ESTABLISHED
        elif [ $our_proto = udp ]; then
            iptables  -A OUTPUT -j ACCEPT -o $intf -p udp -s $srcIP \
                ! -d $srcIP/24 -m udp --dport $dstPORT -m owner \
                --uid-owner $our_user
            iptables  -A INPUT  -j ACCEPT -i $intf -p udp ! -s $srcIP/24 \
                -m udp --sport $dstPORT -d $srcIP -m state --state ESTABLISHED
        fi
    else
        if [ $our_proto = tcp ]; then
            iptables  -A OUTPUT -j ACCEPT -o $intf -p tcp -s $srcIP \
                -d $dstIP -m tcp --dport $dstPORT -m owner \
                --uid-owner $our_user
            iptables  -A INPUT  -j ACCEPT -i $intf -p tcp -s $dstIP \
                -m tcp --sport $dstPORT -d $srcIP -m state --state ESTABLISHED
        elif [ $our_proto = udp ]; then
            iptables  -A OUTPUT -j ACCEPT -o $intf -p udp -s $srcIP \
                -d $dstIP -m udp --dport $dstPORT -m owner \
                --uid-owner $our_user
            iptables  -A INPUT  -j ACCEPT -i $intf -p udp -s $dstIP \
                -m udp --sport $dstPORT -d $srcIP -m state --state ESTABLISHED
        fi
    fi
}
Теперь, чтобы разрешить юзеру user коннектиться к privoxy добавляем политику
allow_out lo tcp 127.0.0.1 127.0.0.1 8118 user
Чтобы разрешить коннектиться к Tor'у:
allow_out lo tcp 127.0.0.1 127.0.0.1 9050 user
Чтобы к mpd:
allow_out lo tcp 127.0.0.1 127.0.0.1 6600 user
Плохо получилось, да? В этих трёх строках ошибку сделать при копипасте, конечно же, проще, чем в вышеприведённых кишках в функции. Почитайте старые обсуждения.

Я пока те правила писал, всю голову себе сломал. Мне это очень напомнило свой первый опыт с ipfw лет 10 назад: на низком уровне надо воспроизвести у себя в голове, как пакет проходит от одного юзера к другому и возвращается обратно, как у него меняются параметры in на out, порты исходящие и назначения, юзер и т.д. Нужно нигде не ошибиться. Даже воспроизведя всю логику правильно и написав эти правила, когда их пишешь другой раз, всё равно ошибаешься, потому что слишком много всего низкоуровневого и нечеловеческого. Мне сейчас предельно понятно, что всё вот это низкоуровневое было запихнуто умными людьми в keep state, а в вашей голове, из-за вашей ограниченности в знаниях файерволлов, вы даже не знаете, что же такое keep state. keep state — это не m state --state ESTABLISHED, понимаете? Это автоматическое приплюсвывание к нужному правилу остальных, которые будут разрешать путь для ответных пакетов. И вам не нужно думать об этом самому. Сейчас keep state вообще в pf по умолчанию. Если вам не нравится, можно его отключить через дописывание к правилу no keep state, вот только много ли оно кому надо? Вам часто нужно посылать что-то демону и никогда не получать ответов обратно? Если вы хотите писать на pf, как на iptables, это можно, я уверяю, но никто так не делает.

Я скажу даже больше: когда я копировал $pass_out-правила я однажды ошибся, написал в одном случае вместо исходящего порта порт назначения, и эта ошибка была выловлена только при дебаге — визуально просматривая файл я так и не смог её найти. В общем, я за то, чтобы способов нечайно выстрелить себе в ногу было как можно меньше, а не за то, что «кто пишет упрощающие инструменты, тот не осилил». В данном случае даже если осилили, рано или поздно ошибки будут. Всю индустрию оупенсорца за это тоже многократно ругали: многие ошибки возникают из-за того, что пишут на сях, а там за всем не уследишь, рано или поздно человек ошибатеся. Не зря же умные люди пишут кодогенераторы C-кода на чём-то высокоуровневом и удобном.

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

— Это надо объяснять?
— Нет.
— Хорошо. ☺
— ?
— Хе-хе. Как говорится, если это надо объяснять то это не надо объяснять.
— А, это да, согласен.

Это глубокая формула, в которую укладывается множество всего. Если выясняется, что собеседник не понимает чего-то совсем концептуального, и ему надо объяснять, то можно извести тонны бумаги и написать сотню простыней, но это всё равно окажется «не в коня корм», потому что это требует некого переосмысления, взятия барьера абстракций и т.д. Короче, процесс сложный, небыстрый и часто очень неблагодарный, поэтому лучше с ним не связываться, и просто ничего не объяснять, оставив своё мнение при себе. Вот и получается, что «если не надо объяснять, то ОК, не обсуждаем, и так друг друга понимаем, а если надо объяснять, то это [всё равно] не надо объяснять, потому что бесполезно».

Дискуссия сильно напомнила этот коммент. Ну вот я выложился, внимательно прочитал всё и всё по полочкам разложил, где, кто, в какой степени и почему заблуждается. И что, это вас убедило? Да ни разу. Вы как считали, что Арно всё делает правильно, так и до сих пор считаете. Все аргументы ушли впустую, время потрачено зря. Интересно, что даже возражений по сути не было, а всё равно, «раз Арно считает, им там видней». Вот поэтому, если на начальных порах чувствуется, что с собеседником мало общего в понимании, дальше обсуждать смысла нет. С одной стороны, это чревато, конечно, тем, что можно оказаться реально неправым и уйти в отрыв, но, с другой стороны, можно не тратить своё время попусту. Вспоминается перепост:

Меньше времени тратить на женщин и людей глупее себя.

Мой вам совет: хотите расширить сознание — изучите что-нибудь полезное. Пусть хотя бы тот же LISP, Haskell или PF. Это позволит взглянуть на одни и те же вещи совсем по другому, даст возможность сравнивать. Пока вы ничего не видели окромя iptables, и вам не с чем его сравнить, вы так и будете до конца жизни убеждённым, что другого пути нет, и быть не может.

P.S. В соответствующих узких кругах вопрос скриптинга iptables обсуждался, никто ничего не сказал против, хотя все люди были неглупыми (во всяком случае, Linux, iptables и программирование они знают намного лучше меня). Так и сказали: да, каждый городит свои костыли в меру испорченности, ничего единого более высокоуровневого нет. Тот, кто умнее, не трахает мозг, а на машины с файерволлами ставит BSD и юзает PF. В общем-то, оно и неудивительно. Когда у меня конфиг PF'а с кучей нетривиальных правил был десятка два строк, а на iptables я понял, что чтобы написать аналогичное, мне нужно не два десятка, а две сотни строк (а потом эту кашу-малу ещё и поддерживать как-то надо!), то сразу стало понятно, что так жить нельзя.
— Гость (17/02/2015 13:30)   <#>
Был бы ещё желательным функционал удаления конкретных правил на лету и их возвращения обратно. Каждый раз комментить и декомментить конкретные строки не только неудобно, но и небезопасно: в один момент (при перезагрузке правил) все правила iptables сбрасываются, поэтому потенциальные зловреды могут прорваться наружу.
— unknown (17/02/2015 13:54, исправлен 17/02/2015 14:24)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Так. Это я говорю, после того как эти функции писал (и даже сам предлагал ровно с той же логикой, что и вы) и частично поддерживал скриптовые проекты на десятки тысяч строк кода.



Я знаю когда их изобрели, знаю, что консоль — это телетайп с перфолентами, знаю, что dd — это диск-дупликатор, tar — это tape archiver и т.д. И сколько лет этому всему, и что оно стабильно и якобы не меняется, что на бумаге и в книгах это так. А на практике — нет. У меня реально разваливались скрипты из-за этого.



Вы меня совсем за непонимающего идиота держите. Естественно, вы его понимаете, иначе не написали бы скрипт, но iptables вам не нравится на уровне подхода. Так вот, я бы выучил на уровне не просто понимания, а принятия подхода (пусть и плюясь от необходимости его использования). Или бы коммитил в проект. Но костыли для самопального перевода одной системы понятий в другую — не нужны. Их поддержка отнимает массу времени.


Ну как ещё вам объяснить. У меня была куча скриптов для GnuPG, с кучей общих функций, псевдобиблиотек, менюшек, проверяльщиков ошибок и пр. — типа пусть машина всё делает за меня, особенно сложные операции. Оказалось проще выучить GnuPG, вместо скриптов и алиасов оставить подсказки для наиболее часто используемых команд (персональный tipsheet, из которого копировать в строку нужные куски). Но обязательно находится кто-то, кто снова хочет начать с такого костылестроения. И красивый подход применить, и свой ЯП запилить и пр.



На десятки и десятки тысяч строк используется. Для тысяч хостов пишут одно и то же правило копированием строчки, даже не циклом (а вам в одно локалхосте не разобраться). Зато напротив каждой строчки стоит свой комент. Всё это элементарно редактируется через vim по ssh. И если для какой-то машины нужно вкорячить нестандартное правило, то не надо в спешке програмить скрипт и отлаживать.


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


Это глубокая формула, в которую укладывается множество всего. Если выясняется, что собеседник не понимает чего-то совсем концептуального, и ему надо объяснять, то можно извести тонны бумаги и написать сотню простыней, но это всё равно окажется «не в коня корм», потому что это требует некого переосмысления, взятия барьера абстракций и т.д. Короче, процесс сложный, небыстрый и часто очень неблагодарный, поэтому лучше с ним не связываться, и просто ничего не объяснять, оставив своё мнение при себе. Вот и получается, что «если не надо объяснять, то ОК, не обсуждаем, и так друг друга понимаем, а если надо объяснять, то это [всё равно] не надо объяснять, потому что бесполезно».

Вот! Я многие темы, поднимаемые на форуме, не обсуждаю или сворачиваю с обсуждения, когда понимаю, что куча времени — впустую. Иногда сразу понятно, что обойти стороной, иногда с какого-то момента. Не в смысле даже, что я прав, а кто-то неправ, просто — не моё, неинтересно, дальше без меня.


У меня тоже есть куча своих программных костылей, которые я бы никому не предложил и не вынес в паблик. Т.к. это изврат, составленный под свои узкие личные предпочтения, не более. А в целом он не нужен. Как в своё время делал проверяльщик подписей для apt, когда подписи пакетов были, а штатной их поддержки в самом apt — не было. Оно даже работало и даже правильно. Так же как и аналог LUKS, до появления собственно LUKS и ещё кучу всякого бреда. Но поддерживать этот изврат самому для себя — сомнительное удовольствие. Хорошо, что сейчас это есть штатно. Даже этот изврат я готов бросить моментально по двум противоположным причинам: сделают штатное решение лучше моего или наоборот — сделают так, что поддерживать это всё будет слишком сложно и проще сидеть вообще без тора.

— Гость (17/02/2015 16:23)   <#>

Т.е. вы вбивали десятки тысяч строк в командной строке каждый раз с нуля, когда вам это было нужно? :) Если нет, то зачем это приводить в пример?


Чем сложнее скрипт, тем выше вероятность. У меня тоже бывало, что что-то отваливалось в скриптах, но не из-за апгрейда, а из-за переноса, например, с BSD на Linux или наоборот, но это неудивительно, т.к. базовые утилиты там разные по опциям, хоть и очень похожи. Если отвалится, буду фиксить. Проблемы надо решать по мере их поступления.


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


Да.


А нет там никакого «подхода» окромя «мы написали так, как было проще программистам, а не юзерам, теперь пусть юзеры выкручиваются, как хотят; раз iptables тьюрингполон в плане возможностей, потенциально на нём всё можно написать». Ну придёт к вам человек сейчас и скажет, что браузер надо писать на ассемблере, типа «подход» у него такой; как писать — он сам не знает, но знает что 1) это возможно 2) асм работает, как заявлено в спеках 3) асм тьюринг-полон, поэтому гипотетически на нём можно написать всё, что угодно. И что вы ему на это ответите?


В вашем случае вы считаете, что оптимальней придерживаться принципа «всё или ничего». Я в моём случае этот принцип за максиму бы не взял.


Я выше уже написал: работает долго, есть не просит, жалоб не было.


Менюшки точно не нужны. Опять же, если требуется делать что-то сложное и много раз, лучше все эти костыли нагородить. Если можно обойтись, то тоже прекрасно, но не все и не во всех задачах могут обойтись. У меня есть некоторые несложные алиасы в шелле для gpg, чтобы вручную не вбивать однотипные команды каждый раз, выцепляя KeyID'ы из листинга gpg и рискуя забыть ту или иную опцию.

Могу ещё скрипт вспомнить. Очень удобный, полезный, вбиваю ./bin/script_name.sh [device] и больше ни о чём не думаю, он всё делает сам. Десятки раз он точно пригождался. А можно было бы сделать по-вашему: написать tipsheet, потом по одной команде дёргать оттуда и на лету редактировать под каждый случай, рискуя ошибиться. Времени уходило бы больше, вероятность ошибки была бы выше, но зато по-вашему.

Более того, ваш подход у меня ещё пока используется для ресайза шифрованных LVM. Там где-то десяток команд, которые нужно по одной копипастить в командную строку и редактировать. Получается долго, муторно, и временами ошибаюсь. Это, наверно, тоже стоило бы автоматизировать, но операция используется редко, поэтому не знаю, стоит ли овчинка выделки.

Ещё один пример — rdiff-backup. Там нужно было добавлять все нужные --exclude'ы, чтобы не засорять ФС вредной информацией. Однажды-таки ошибся, и что потом делать? После прерывания БД теряет консистентность, поэтому приходится сносить весь бэкап, убивать слот cryptsetup'а, потом заново его форматировать, нарезать ФС и снова делать rdiff-backup. Зато по-вашему. После первого фейла написал скрипт с командой запуска, чтобы больше такого не повторялось.

Я не знаю, как можно спорить с очевидным. Вы сейчас точно не троллите?


Редактируется, не вопрос, а как в этом разбираться? Вот копировали вы строчку, исправляли номера портов, а в одном месте забыли исправить, открыли в системе дырку, но всё ОК, работает. Как проанализировать правила на предмет дырок и консистентности? Отдельный интеллектуальный скрипт-парсер писать? Попытайтесь внимательно проанализировать все до одного правила из десятков — у вас крыша поедет. В продакшне всем наплевать на безопасность. Там нет такого, что утечка одного пакета в некоторых случаях приводит к катастрофе.

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


Зачем усложнять себе жизнь? Я не претендую на вселенскую значимость. Здесь раза три уже спрашивали, как закрыть порты в Tor. Вот есть ответ — скрипт. Хотите, отредактируйте под себя и используйте, не хотите — проходите мимо. Зачем мне в обязательном порядке все свои наработки пытаться встроить в какой-то официальный проект? Я как раз поттерингом не страдаю в этом плане. И я не вижу никакой большой важности в нескольких самопальных скриптах-костылях, чтобы их как-то официально распространять для других. Всё это вторично и малозначимо. Если какая-нибудь бессигнатурка и отрицаемое шифрование ещё имеют смысл, то эта малочёвка — уже совсем перебор.


Ну и зря. Бывает, что задача возникает, а фиг нагуглишь, как её решать. Я поэтому придерживаюсь принципа выкладывать всё сколь-нибудь полезное.


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


Кому-то может быть приемлемым сидеть вообще без компьютера. Как всегда, это вопрос личного компромисса между затратами, отдачей и приоритетами.
— unknown (17/02/2015 17:35)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Как можно так переврать очевидное и совершенно неиносказательное? Скрипт на десятки тысяч строк кода, явно же написано. Не для себя, себе я бы такое не делал. И не для себя по доброй воле тоже. Просто знаю, насколько тяжело всё это поддерживать.


Именно. То в tail или head можно было без пробела цифру после опции использовать, то нельзя; то начинают в дистре тасовать между собой awk/mawk/gawk, у которых опции отличаются, причём ошибки не вылетает, а просто не работает.


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


Одно дело — утрировать про браузер. Другое дело — сравнивать iptables с ассемблером. Да им тысячи хостов разруливают и тупо пишут скрипт :



Просто тупо список, даже без конфигов, условий, массивов и циклов, с минимумом переменных. Делается идеально аккуратная разметка, чтобы всё выглядело единообразно. В vim делается поиск и замена того, что нужно, всё управление через текстовый редактор. И так рулят тысячами хостов без ошибок. А вы, чтобы справится с одним, хотите создать свой язык? Для копания ямки под горшок построить экскаватор?


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


У меня тоже долго что работало, пока не пришло время обновить или разобраться в чём-то старом, добавить возможностей и пр. Оказалось, что примитивные скрипты поправить легко, а сложные — проще заново написать. И лучше в примитивном виде.


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


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

Вот я в одной теме сразу заявил, что отрицаемое шифрование в оффлайне — нереально. Но взялся just for fun, но стоило чуть остановиться, как меня подначили тонким троллингом на слабо:

Так можно про любую задачу сказать: раз ещё не решили, значит, бьются и решают. А если приглядеться внимательней, то есть, в лучшем случае, 2-3 научных коллектива, а то и вообще всего несколько человек, которым эта задача интересна. Другие занимаются другими задачами. Лишь очень небольшое число проблем удостаивается официального статуса трудных. Это проблемы, к которым, например, сводится решение множества других важных проблем. В криптографии можно легко придумать тысячу проблем-вопросов, ответа на которых наука не знает. Это не значит, что все они трудные (нахождение и постановка действительно трудной проблемы — само по себе уже открытие, но трудность надо доказать чем-то помимо «я пробовал, и у меня не получилось решить»; например — сведением к другим трудным задачам). Это значит (обычно) только то, что никто из квалифицированной публики серьёзно за них не брался.


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

Вот ещё тема, про аппаратный скремблер. Там показателен не столько протокол, сколько отдельная возможность передачи шифрованного голоса через GSM. Казалось так легко, да ещё проект JackPair якобы это смог (но не отдал наработки в паблик, что подозрительно). А там всплыло столько трудностей, столько исследователей головы ломали, что не стоит это того, чтобы браться. Или будет только ненадёжная имитация, которая при смене условий канала откажется работать. И на бесконечных доработках проект и увязнет. Проще признать, что цифровой голос внутри голоса GSM — забавная задача, но как бы не хотелось её на практике осуществлять, лучше забить.


Это только первая стадия. Хорошо, что вы не в каком-нибудь влиятельном проекте на влиятельной позиции :)


Иногда приходится. Просто буду знать, что никакой анонимности/безопасности там нет и играть в игры с полумерами можно до момента, пока они не сильно напрягают.
— SATtva (18/02/2015 16:02)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Во срач развели только из-за того, что одному ближе экстенсивный подход, а другому — интенсивный. Господа, будьте терпимее к чужим недостаткам.
— ressa (18/02/2015 16:51, исправлен 18/02/2015 16:52)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59

unknown, ты комментом ошибся) Там я Гегелю спасибо говорю)

— unknown (18/02/2015 16:57, исправлен 18/02/2015 17:08)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

промахнулся.



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



OK. Тогда проще согласиться с концом вот этого коментария:


Как всегда, это вопрос личного компромисса между затратами, отдачей и приоритетами.
— Гость (18/02/2015 23:57)   <#>

Хорошо, упростим немного задачу. Китайский код — это, по-вашему, хорошо? Если хорошо, то где хорошо и почему хорошо?
— Гость (19/02/2015 08:00)   <#>
Шелл — это простой склеиватель утилит, не надо из него пытаться сделать полноценный скриптовый язык программирования.

Загляните в каталог /etc, там куча скриптов. Например, для запуска/остановки служб используется скрипт, который использует целую библиотеку функций на bash. Причём эти функции широко заимствуются из одних систем в другие. Даже в такой минималистичной системе как LFS они присутствуют в изменённом виде.

Да им тысячи хостов разруливают и тупо пишут скрипт

Это скорей не скрипт, а база данных, формально похожая на скрипт. Количество хостов вообще не аргумент (пусть их хоть миллион будет), в скриптах главное – сложность логики. Тупой "скрипт" (по сути база) из тысяч строк может быть несравним по сложности с кодом из десяти строк. В вашем примере логика почти отсутствует, а данные относительно редко меняются, поэтому городить надстройки смысла действительно нет.

Настройки сетевого экрана нужно менять например при тестировании чтобы перейти с Tor на прямое соединение, разрешить пинг и traceroute или DNS для подключения к провайдеру когда нет роутера. Если напрямую править "скрипт" iptables, то легко ошибиться. Разумней классифицировать задачи, создать для них нужные правила и возможность лёгкого переключения между ними. Это снизит вероятность ошибки и облегчит работу. Проще разобраться с различием в настройках один раз, чем делать это многократно и в неподходящее время.

Идея со скриптованием iptables нормальная, а насколько хорошо она реализована, это уже другой вопрос.
— unknown (19/02/2015 09:50)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Да не китайский. Вот проверка TBB:

Это скрипт не для тупого конечного пользователя, поэтому сам скрипт имеет право и даже должен быть тупым. Чем примитивнее и тупее, тем лучше. А можно приделать кучу конфигов, проверок, циклов, разные имена файлов (а не только linux64) проверять. Допустим, завтра я сяду за комп уставший, скачаю новый TBB, а там вся структура файлов внезапно поменяется. Поскольку скрипт прост, примитивен, нагляден и туп, его кто-угодно можт поправить за полминуты, даже если до этого в него не заглядывал годами или вообще не разу не видел.

Сложный код оправдан для сложных алгоритмов, но для проекта, который вы собираетесь развивать и поддерживать регулярно всё своё свободное время, чтобы в любой момент можно было делать сложные фичи, масштабировать и пр. Т.е. это перекладывание тупости пользователя в головную боль для разработчика.


Там все скрипты написаны в целом в правильной и уместной идеологии. И именно поэтому так и не надо делать там, где не универсальный скрипт (для дистра) или не в продакшн с полной автоматизацией и универсализацией для конечного пользователя, с тестированием, циклом поддержки и пр. Я уже намекал, что у меня есть опыт поддержки и тупых скриптов, и навороченных. И не для себя, а в продакшн. Это ни разу не повод для гордости, просто вы пытаетесь мне объяснить и показать то, что я уже ковырял более десятка лет. Ну т.е., если я ошибаюсь, то мне это объяснять бесполезно, я уже на этом свою собаку съел и шишек набил :)
— Гость (19/02/2015 10:32)   <#>
Если вариации скрипта тривиальны и не очень часты, то его проще править, чем программировать разные варианты. А если вариации не так очевидны, требуют умственных усилий и существует вероятность ошибиться именно в логике, а не при наборе на клавиатуре? Лучше напрячься один раз, заложить всю сложность в скрипт и отладить, чем регулярно воспроизводить её в голове.
— Гость (19/02/2015 12:33)   <#>

Только потому, что они написаны там и кем-то, а не мной? Ну вот я, например, пытался немного курить стартовые скрипты rc.d, init.d и т.п. Пытался разобраться, как в примитивной NetBSD запускаются консоли при старте. Там какой-то wscons-скрипт есть. Он с функциями, редиректами, case'ами и всем остальным. Понял не сразу и не всё, скажу определённо. Разбирался, потому что чтение системных конфигов почему-то не работало, как надо. Что-то в итоге пофиксил, что-то нет. Но я согласен в целом, что многие стартовые скрипты — это страх и ужас, и по уму это надо делать не на шелле, а на чём-то более умном и удобном. Но тут опять же всё дело в традициях и legacy.

Если быть последовательным, то systemd вроде как пытался решить эту проблему, как и pulseaudio для работы со звуком и др. проекты Поттеринга. В лурке про Поттеринга все эти аргументы приведены. Ну т.е. якобы движение правильное и в верном направлении, а то, что временно всё сломалось, было неизбежным. Если последовательно к этому подходить, то вы, unknown, должны быть всеми руками за в пользу systemd, но почему-то это не так. Вы предпочитаете сложные навороченные заскриптованные ужасы старта системы System V. Как же так?


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

Например, я для себя опредилил 2 простых правила: не втыкать сетевой провод, пока не загружена система, и вытыкать его до ребута (потому что не знаю, как там меняется мак-адрес, и у меня это делается вручную). Как бы ни старался и не параноил, за несколько лет я успевал нарушить это правило не раз, не два и не три, так что мой мак успел утечь к провадйеру n-ое число раз. Кстати, в скрипты я смену мака внёс только после того, когда очередной раз забыл его вручную сменить, а опомнился, уже когда dhcp был запущен с настоящим маком. Да, схватился за голову, а что делать? Всё, поздно уже. Можно много месяцев играть в прятки, а потом одним неосторожным действием разрушить всё.

Другое правило было — выдёргивать провод, когда монтируются оффлайновые разделы. Про него могу сказать ровно то же самое: рано или поздно осечки начали случаться. Если нужно редактировать скрипт, рано или поздно вы ошибётесь, это неизбежно. Не поможет ни vim, ни всё остальное. Не туда нажал, не там отвлёкся, задумался, не исправил что-то, забыл о чём-то — и всё, система оказалсь открытой. Я себя столько ловил на этих нюансах, что теперь стараюсь по-максимуму убрать ручное вмешательство везде, где это можно.

Было дело, забыл, например, отключить логи в privoxy. Когда-то включил для отладки и забыл. Узнал об этом много месяцев спустя, когда случайно чистил домашнюю директорию. А там оказалось, что писались все ссылки, всё в мельчайших подробностях, все веб-логи, за много месяцев. И все эти месяцы я спокойно думал, что хоум у меня чистый и ничего такого там нет. Я после этого очередной раз схватился за голову и сказал сам себе, что я не верю возможность ИБ.


А что сложного в моём коде? Несколько функций + незначимые алисы (можно было и без них). Если очень надо, можно просто написать правило iptables без всяких алиасов, оно тоже будет понятно. В чём проблема?



Я вообще в последнее время подумываю об интеллектуальном дауншифтинге.

Можно впадать в маразм.

[медицинское]
Коллеги, очень жаль, но, похоже, мы теряем его. ☹ SATtva, проверьте пульс ещё раз. Кетамина больше не надо, он не помогает ему. Позвоните родственникам, поговорите о наследстве, кому должен достаться аккаунт на pgpru и пост модератора.
[/медицинское]
— unknown (19/02/2015 14:51)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Я могу (мог когда-то) написать также. Я когда-то также и писал, не для себя, а в проект. Для проекта, который будут использовать много людей и который будет для них оперативно поддерживаться — это нормально: чуть хуже, чуть лучше, но концептуально годится со всеми неизбежными наворотами. Для себя (не в проект) — это часто не оправданно. Если вы будете делать свой Tails, Whonix и пр. Liberte — тогда оправданно. А для себя или для обмена с кем-то — IMHO не оправданно.


Pulseaudio решает часть проблем со звуком, начисто игнорируя другие. Поттеринг открыто сказал, что ему покласть на обработку сигналов и музыкотворчество. Подозреваю, что и на безопасность в плане контроля над системой и анонимность ему также покласть. Он делает универсализацию, расставляя за всех приоритеты. Это вы делаете по Поттерингу: пытаясь нагородить сложные универсальные абстракции там, где не нужно и в ущерб восприятию.


Я понимаю, прятать мак в разовой поездке в далёкой стране, где подключаешься пару раз. Тогда и перешить можно. Или стартовать сеть вручную, как запуск космического корабля с ручной проверкой всех систем. А прятать mac от постоянного провайдера? Проще решить, что это бесполезно.


Необходимость поддержки автоматического вмешательства подводит ещё больше. Ключевое слово и слабое место в автоматике — поддержка. Самые критические системы поэтому и сидят на всяком десятилетиями неменяющемся старье — изменения поддерживать слишком дорого. Дороже примитивного полуручного управления.


Я исхожу из максимы, что не бывает чистого хома, /var, /tmp и пр. Кто залез в расшифрованный комп — тот знает всё. На мелкие подстраховки нет смысла тратить слишком много усилий.


Ничего. Он простой, если вы его сами написали или если потратить время, чтобы его разобрать и помнить. А если спустя месяцы в него заглянуть или первый раз — набор каких-то самопальных абстракций. Стандартный дистровый /etc — там может такой-же ужас и даже хуже, но он и в Африке /etc, один раз выучить и много где пригодится. Он лучше тем, что его пропихнули в негласный стандарт, неважно насколько он убог и кто его написал. Не нравится — меняйте стандарт, пропихивайте своё как Поттеринг.


Меня чья-то якобы непоследовательность почти никогда не удивляет в плане желания требовать объяснений, выводить на чистую воду, искать противоречия. Я обычно могу воспроизвести контекст восприятия другого человека, пусть и с ошибками (в чужую голову не залезешь), но я обычно понимаю, почему кто-то думает именно так и почему оба взаимоисключающих мнения разных людей часто почти равноправны — дальше определённой модели восприятия не вылезешь, надо или строить новую, или выжимать максимум из имеющихся. Абсолютно правых не бывает. Пусть каждый останется прав в своей области. Можно даже оперировать сразу несколькими взаимоисключающими моделями в одной голове, пытаясь посмотреть — какая победит и даст больше профита, можно оперировать разными языками, системами понятий, имитировать чужую логику, но тогда люди понимают такую позицию ещё хуже (они начинают всерьёз думать про кетамин, маразм, множественные личности и пр.).
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3