Эм… разве мы не можем просто бежать по списку и проходя каждый элемент менять ссылку на «следующий элемент» ссылкой на предыдущий пройденный элемент?...
Можем… но это не так весело… ну и тут автор как бы и "тонко" потроллил, опять же блеснул знаниями функциональщины, да и в математику "сбегал"...
А так то да (если in-place, т.е. не нужна копия/оригинал списка) — как ответ достаточно что-нибудь типа — "поменяем" три значения в цикле (ну и какой-нибудь простейший тест):
Скрытый текст
class Node:
@staticmethod
def reverse(head):
prev = None;
while head:
head.next, prev, head = prev, head, head.next
return prev
##
def __init__(self, d=None, next=None):
if hasattr(d, '__iter__'):
n = self; prev = None
for d in d:
n.d = d
if prev: prev.next = n
prev = n
n = Node()
prev.next = None
return
self.d = d; self.next = next;
def __repr__(self, aslist=False):
n = self;
s = []
while (n):
s.append(n.d);
n = n.next;
return s if aslist else str(s)
def __eq__(self, lst):
if isinstance(lst, Node): lst = lst.__repr__(True)
return self.__repr__(True) == lst
def test_reverse():
assert(Node.reverse(Node([1])) == [1])
assert(Node.reverse(Node([1,2,3])) == [3,2,1])
# in-place change:
n = Node([1, 2, 3, 4])
assert(n == [1, 2, 3, 4])
m = Node.reverse(n)
assert(m == [4, 3, 2, 1]) # m is inversed list now
assert(n == [1]) # n is single (last) element now
Node.reverse(m) # n will be restored to original
assert(n == [1, 2, 3, 4])
Т.е. вы правда не догадываетесь как это можно изменить? Да хоть для ста меток?
Если же вы хотите намного лучше работающий TDoA...
TDoA на коротких дистанциях (расстояниях между якорями), для кучи бирок, да с помехами в виде отраженных сигналов, еще и без внешнего RTC/CSU… и т.д.
Хмм… месье знает толк…
Ну пробуйте… Получется что-нибудь как тут у ребят на дуинках.
А чего TWR то вдруг не устраивает? Да для машин-то (т. е. не леталок, т. е. 2D не 3D)…
Я так понимаю до сантиметра точно не нужно, еще и раз в пол- или четверть секунды (а я думаю чаще оно на карте и не нужно)…
Если что, то до 20 метров там сильно секретный режим реально very high tag densities...
Люди ну мы же на хабре, я вам там даже даташит приложил.
Т.е. чтобы организовать RTLS (или TWR между двумя "кусками текстолита") вам правда такой-вот kit за "стопитсот" денег нужен?
Эх повывелись нонче инженеры...
Вот вам готовое — ScenSor DWM1000 Module, позиционируется до 300м с аккуратностью до 10cm, при скорости юнита до 5м/сек.
В теории такое можно и самому на коленке собрать, но муторно да и зачем при ценнике то в районе $20-$30 за штуку. Конечно, если там не 1000 штук вдруг нужно будет...
Собственно ссылка на то, что меня возмутило, есть в первой же строке
Ну да "хайли лайкли" русские снова всё поломали тестируют "системы способные повредить западноевропейскую инфраструктуру".
Персонально товарищ майор Петров и Башаров отметились.
А чего вы собственно хотели от "Contributor Driven News Platform"? Ну написала какая-то Китова какую-то чушь в никому неизвестном онлайн "журнальчике".
И что?
Статье плюс и вашей теории зачет… а вот истерить прекращайте уже все-таки.
А как иначе? Вы либо верите в зависимости, либо нет. Какие ещё есть варианты?
Т.е. вы из тех которые никогда никогда rm -fr ... не используют? (потому что опасно!) Тогда я сливаюсь с ветки… Нам правда нечего больше обсуждать.
И вы сами рассказали — почему. Потому что разработчики пользуются внутренними интерфейсами и «забивают на совместимость».
WTF? Конечно разработчики пользуются внутренними интерфейсами. А для чего они по вашему есть вообще?
И где вы увидели про «забивают на совместимость»?
Потому что сейчас у вас проблемы ровно оттого, что мистические «другие разработчики» делают то же, что и вы. А почему вам можно, а им нельзя?
У меня/нас нет проблем. От слова совсем. Вы во первых повидимому просто не в теме как разработка больших проектов ведется в принципе.
А во вторых тут конкретно вообще мимо — ибо Tcl (по сравнению с многими другими) это проъект с великолепной обратной совместимостью.
Нет, я рассказываю человеку, плюющему в колодец, что вода в нём плохая не потому что колодец не чистят, а потому, что другие делают то же самое, что и вы.
Чаво?
Т.е. если вы к примеру увидели что кто-то, где-то использует шуруповерт в качестве молотка (один раз, потому что просто под рукой и удобно тут) — вы на этом основании делаете вывод что во первых он всегда и везде так делает, а во вторых "что и другие делают то же самое, что и он".
Если хотите поставить два пакета — возьмите dpkg и поставьте.
Ага — отвелосипедить то есть… создать список того что надо (в нужной последовательности, скачать ручками, и т.д. и т.п.
APT — это тулза, нужная для управления зависимостями.
Вообще-то нет (ну, или не только)… оно себя заявляет как пакетный манагер… например оно еще и скачать может, и в правильной последовательности накатить то что надо и т.д.
С какого перепугу вам вообще потребовался TCL 8.6.9 и почему TCL 8.6.5 вас не устраивает?
Ну я же писал о CI (т.е. надо оттестировать что-то)… С того перепугу, что мы (ну как мы, вообще-то Натан и Дон) в версиях 8.6.8 и особливо 8.6.9 кое-чего "поломали" (в частности NRE trampoline в связке с резолверами ассемблей), и если тестировать какое-либо расширение для Тикля, использующее внутренние API (а бинарная совместимость гарантируется только для public-API), то нужно это делать для всех версий, для которых их потом выльют.
Мэйнтейнеры тоже знаете ли не всё могут знать/проверять...
С таким подходом идея пакетов вообще становится нереализуемой
Т.е. вы разрабу Tcl сейчас пытаетесь рассказать про зависимости оного… Ну, ну.
Если что, как и с чем его и его модули собирать и откуда чего брать я прекрасно осведомлен…
А в виртуальном снэпшоте CI что-то поломать из зависимостей… да мне как-то до одного места оно.
Просто для скорости иногда хочется (или тупо нужно) и "тяп-ляп" и поломать чего можно, главное что бы быстро и не муторно.
Вы вообще видели когда-нибудь как оно тестируется… И сколько иногда надо ждать, чтобы узнать что с включенной опцией O для платформы X, в 32-битном варианте что-то безвозвратно "поломалось".
А если нужно дальше код писать на той базе (чтобы не переписывать по десять раз потом), и/или тебя еще трое разрабов ждут…
И не забывайте, что это нередко вовсе неосновная работа (и нужно еще и той заниматься за которую платят), да еще и не единственный проект как правило...
Так что ваше "Это несложно", извините, но как минимум режет слух (повторюсь — особливо для дебианов)… и очень многие мэйнтейнеры с вами тут не согласятся.
Ну если вам это не нужно — то почему это кому-то ещё должно быть нужно?
Я так-то в большей степени разраб, и на активно что-нибудь еще мэйнтэйнить просто времени нет совсем (ибо будет вероятно в ущерб остальному). Так что тут — вы мимо...
И нет, то было скорее ответом на "Это не сложно"… ибо я как раз таки согласен со Штапельбергом.
Возможно "сложно" здесь не совсем верно — есть такое слово "муторно" — так вот оно — то самое скорее. (А еще утомительно, раздражает и многое многое другое).
Тот же apt иногда выбешивает не по-детски… Вот для примера из недавнего:
Намедни нужен был мне в трависе (CI) на xenial tcl8.6 (>= 8.6.9, а родной там 8.6.5)… ну т.е. ставим из репа для старшей версии… и вот откуда-то там взялась зависимость к locales 2.29 (через libc и ко), который тупо ставится скриптом генерируя каждый locale на месте, а затем еще тащит обновления для всех postgresql (на минутку для каждого снапшота, тестируемого компилятора, и т.д.) и выключить эти обновление не представляется возможным… т.е. совсем выпилить те пакеты можно (например apt-get install -t disco -y tcl8.6 tcl8.6-dev locales- 'postgresql*-'), а вот тупо обновить всё нужное, проигнорировав обновление locales и т.д. — выкуси (хоть пиннинг, хоть apt-mark hold, и т.д.)…
Опять же есть такая опция "--no-upgrade", вот кто-нибудь может внятно объяснить что если написано:
apt-get install --no-install-recommends --no-upgrade -t disco -y tcl8.6 tcl8.6-dev
т.е. явно указано что хочу установить 2 пакета из disco (и не апгрэйтить остальное), какого оно говорит "Skipping tcl8.6, it is already installed and upgrade is not set."?
Т.е. нужна видимо новая (двухсотая уже) опция типа --no-upgrade-but-install.
Вот и получается, что или ждать пока CI полчаса всё то установит, проверит, и т.д. (когда сама компиляция и тесты собственно менее 20-ти секунд занимают) или "велосипедить" что-то типа:
Не знаю про "большинство", но очень часто "заржавел(и)" как раз maintainer(ы).
Т.е. разрабы нередко уже даленько-даленько, а в пакетах воз и ныне там…
И особливо оно касается как раз дебианов, к сожалению, по целому ряду причин, см. например...
берите на себя техподдержку, пакет оживят. Это несложно.
Так итог их сценария для "дефолного конфига" на самом деле подводится всего одной фразой:
but simpler and faster solutions may exist
И оно таки существует… У вас verify ACL что действительно отключен был? Кто-нибудь смог оценить сколько им на самом деле понадобилось (с дефолтными ACL)?
Т.е. qualys нашли один возможный вектор атаки (с помощью bounce) и развили его в возможный сценарий как оно при этом позволяет обойти дефолтные ACL).
Еще раз — проработали один возможный сценарий, при этом явно указав что вероятны и другие (проще и быстрее).
А в интернете как всегда притянули то что хотели за уши и теперь талдычат про «по байту целую неделю»… Ну-ну.
Кстати, кроме всё-таки несколько сложных вещей (типа упомянутого уже BO), я на вскидку вижу еще как минимум один возможный сценарий… тоже с bounce, но с глобальным .forward (определенного вида) или локальным .forward пользователя с привязкой к анти-спаммерам типа spamassassin. (Нужно в исходниках кое-чего глянуть).
Как минимум если "режектинг" спама реализован через deliver директиву (у exim фильтра директива fail через одно место реализована, поэтому такое сплошь и рядом).
Можно таки увидеть определение безопасности, на которое вы ссылаетесь?
Подойдет вам в качестве так требуемого вами "определения" живой пример успешного предотвращения IDS-ом одного вектора атаки последнего epic fail от exim.
Я естественно понимаю, что то есть случай и даже некоторая удача… Но таки всё же.
Я к сожалению не могу, ибо в "моем" случае (например на серверах клиентов, там где stretch) везде стоял мой IDS (на базе кастомного fail2ban), так что они все посваливались в долгосрочный бан не успев ничего натворить до обновления.
Вытяжка из summary для одного адреса выглядит примерно так (я обрезал немного дабы скрипт-киддис не вводить в искушение):
Start of ban | End of ban | Jail | Ban-time | Ban-count | Info
---------------------|---------------------|------|--------------------|-----------| -----------
2019-06-11 13:27:34 | 2019-06-13 05:30:52 | exim | 144198 (1.7 days) | 2
failures > 2, ip4: 89.248.171.57, country: NL (prev: SC)
matches:
2019-06-11 13:27:34 no IP address found for host scanner20.openportstats.com (during SMTP connection from [89.248.171.57])
2019-06-11 13:27:34 no IP address found for host scanner20.openportstats.com (during SMTP connection from [89.248.171.57])
---------------------|---------------------|------|--------------------|-----------| -----------
Start of ban | End of ban | Jail | Ban-time | Ban-count | Info
---------------------|---------------------|------|--------------------|-----------| -----------
2019-06-10 04:31:31 | 2019-06-11 00:56:56 | exim | 73525 (20.4 hours) | 1
failures > 10, ip4: 89.248.171.57, country: NL (prev: SC)
matches:
2019-06-10 04:31:31 no IP address found for host scanner20.openportstats.com (during SMTP connection from [89.248.171.57])
2019-06-10 04:31:31 no IP address found for host scanner20.openportstats.com (during SMTP connection from [89.248.171.57])
2019-06-10 04:31:31 no IP address found for host scanner20.openportstats.com (during SMTP connection from [89.248.171.57])
2019-06-10 04:31:31 no IP address found for host scanner20.openportstats.com (during SMTP connection from [89.248.171.57])
2019-06-10 04:31:31 H=(target.example.com) [89.248.171.57] F=<> rejected RCPT <${run{...}@target.example.com>: Unrouteable address
2019-06-10 04:31:31 H=(target.example.com) [89.248.171.57] F=<> rejected RCPT <root+${run{...}@target.example.com>: Unrouteable address
2019-06-10 04:31:31 H=(target.example.com) [89.248.171.57] F=<> rejected RCPT <bin+${run{...}@target.example.com>: Unrouteable address
2019-06-10 04:31:31 H=(target.example.com) [89.248.171.57] F=<> rejected RCPT <${run{...}@target.example.com>: Unrouteable address
2019-06-10 04:31:31 H=(target.example.com) [89.248.171.57] F=<> rejected RCPT <root+${run{...}@target.example.com>: Unrouteable address
2019-06-10 04:31:31 H=(target.example.com) [89.248.171.57] F=<> rejected RCPT <bin+${run{...}@target.example.com>: Unrouteable address
Кстати, глядя на тот код я право не знаю откуда такое вот берется:
an attacker must keep a connection to the vulnerable server open for 7 days (by transmitting one byte every few minutes).
Обычное переполнение… Я утрирую, но… тут на коленке за час можно инжект состряпать… Десяток емайлов (ну сотня в худшем случае) определенного содержания и "сервер наш".
Им кстати неоднократно об этом и намекалось и прямо говорилось чуть не с 2004-го года, например или здесь…
По видимому на грабли нужно наступить раз 20-ть пока дойдет.
А не надо тут разбираться. Ну люди, мы на каком ресурсе здесь вообще?
Я понимаю клонить лень т.д., но есть жеж онлайн инструменты
Находим фикс d740d2111f189760593a303124ff6b9b1f83453d для CVE-2019-10149, а потом блеймим до изменения где тот код впервые экспериментально появился (и смотрим в каких ветках оно есть) ну или просто тупо сравниваем еще непофикшеный файл src/src/deliver.c из какого-либо предыдущего коммита (или из 0cbf2b821bb13da0268556d0e30ea627d5592c60 где оно появилось уже в том виде как до фикса) с веткой 4.84 (или с версией jessie). У кого не прыгает на код, щелкнуть на таб "Files changed".
И видим что этот кусок кода там (в jessie версии) вовсе отсутствовал:
Jessie во первых вовсе затронут не был, а во вторых — типа как бы "устарел".
Для текущей же стабильной ветки (stretch) — обновление 4.89-2+deb9u4 прилетело только 5 июня.
(Да и для buster 4.92-7 вылили после 07 мая судя по changelog).
Аргументировано.
На собственном опыте могу сказать, что "по опыту" как правило значит чуть более чем ничего. Кхе… кхе :)
На самом деле главный аргумент приспешников blacklistd ("не нужно парсить лог") "разбивается" единственным примером:
Демон sshd (при включенном UseBlacklist) отправит инфу (authentication success/failure) на blacklistd сокет, и… запишет это в лог. Ну а blacklistd прочитает её из сокета и распарсит.
Чем оно в принципе отличается от "распарсивания" fail2ban тех же строчек прочитанных из лога, никто так и не смог мне внятно объяснить.
Кроме того, fail2ban тоже это давно умеет, а в новых версиях уже официальным протоколом и для сообщения об отдельных неудачных попытках, т.е. достаточно отправить ему на сокет:
# отовсюду (симулируем простейший "маринад"):
f2b_attempt_msg="(lp0\nS'set'\np1\naS'%s'\np2\naS'attempt'\np3\naS'%s'\np4\na.<F2B_END_COMMAND><F2B_CLOSE_COMMAND>"
printf "$f2b_attempt_msg" sshd 192.0.2.1 | nc -q 0 -U '/run/fail2ban/fail2ban.sock'
# из питона:
s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM);
s.connect('/run/fail2ban/fail2ban.sock');
s.send(pickle.dumps(['set', 'sshd', 'attempt', '192.0.2.2', 'unknown user'], 0) + b"<F2B_END_COMMAND>"); s.close()
# ну и из шела:
fail2ban-client set <jail> attempt <IP> [<failure-message1> ... <failure-messageN>]
Можем… но это не так весело… ну и тут автор как бы и "тонко" потроллил, опять же блеснул знаниями функциональщины, да и в математику "сбегал"...
А так то да (если in-place, т.е. не нужна копия/оригинал списка) — как ответ достаточно что-нибудь типа — "поменяем" три значения в цикле (ну и какой-нибудь простейший тест):
0xd34df00d а кстати чому idris? (и да я знаю про https://deque.blog/2017/06/14/10-things-idris-improved-over-haskell/ и т.п., но все же оно де-факто никак не стандарт, тем паче если собеседование не про pure functional lang, или я таки отстал от жизни)?
Или то из оперы — если уж троллить, то с музыкой? :)
П р а в д а?!
img src="You Don't Say ©Nicolas Cage"Т.е. вы правда не догадываетесь как это можно изменить? Да хоть для ста меток?
TDoA на коротких дистанциях (расстояниях между якорями), для кучи бирок, да с помехами в виде отраженных сигналов, еще и без внешнего RTC/CSU… и т.д.
Хмм… месье знает толк…
Ну пробуйте… Получется что-нибудь как тут у ребят на дуинках.
А чего TWR то вдруг не устраивает? Да для машин-то (т. е. не леталок, т. е. 2D не 3D)…
Я так понимаю до сантиметра точно не нужно, еще и раз в пол- или четверть секунды (а я думаю чаще оно на карте и не нужно)…
Если что, то до 20 метров там
сильно секретный режимреально very high tag densities...Люди ну мы же на хабре, я вам там даже даташит приложил.
Т.е. чтобы организовать RTLS (или TWR между двумя "кусками текстолита") вам правда такой-вот kit за "стопитсот" денег нужен?
Эх повывелись нонче инженеры...
Вот вам готовое — ScenSor DWM1000 Module, позиционируется до 300м с аккуратностью до 10cm, при скорости юнита до 5м/сек.
В теории такое можно и самому на коленке собрать, но муторно да и зачем при ценнике то в районе $20-$30 за штуку. Конечно, если там не 1000 штук вдруг нужно будет...
А кто-то говорит обратное?
Коммент был как бы про "что меня возмутило" в какой-то статье из никому неизвестного онлайн портала, который читают чуть более чем 0 человек.
Ну да "хайли лайкли" русские снова
всё поломалитестируют "системы способные повредить западноевропейскую инфраструктуру".Персонально
товарищ майорПетров и Башаров отметились.А чего вы собственно хотели от "Contributor Driven News Platform"? Ну написала какая-то Китова какую-то чушь в никому неизвестном онлайн "журнальчике".
И что?
Статье плюс и вашей теории зачет… а вот истерить прекращайте уже все-таки.
Т.е. вы из тех которые никогда никогда
rm -fr ...не используют? (потому что опасно!) Тогда я сливаюсь с ветки… Нам правда нечего больше обсуждать.WTF? Конечно разработчики пользуются внутренними интерфейсами. А для чего они по вашему есть вообще?
И где вы увидели про «забивают на совместимость»?
У меня/нас нет проблем. От слова совсем. Вы во первых повидимому просто не в теме как разработка больших проектов ведется в принципе.
А во вторых тут конкретно вообще мимо — ибо Tcl (по сравнению с многими другими) это проъект с великолепной обратной совместимостью.
Чаво?
Т.е. если вы к примеру увидели что кто-то, где-то использует шуруповерт в качестве молотка (один раз, потому что просто под рукой и удобно тут) — вы на этом основании делаете вывод что во первых он всегда и везде так делает, а во вторых "что и другие делают то же самое, что и он".
Серьезно? У вас правда с логикой всё нормально?
Ага — отвелосипедить то есть… создать список того что надо (в нужной последовательности, скачать ручками, и т.д. и т.п.
Вообще-то нет (ну, или не только)… оно себя заявляет как пакетный манагер… например оно еще и скачать может, и в правильной последовательности накатить то что надо и т.д.
Ну я же писал о CI (т.е. надо оттестировать что-то)… С того перепугу, что мы (ну как мы, вообще-то Натан и Дон) в версиях 8.6.8 и особливо 8.6.9 кое-чего "поломали" (в частности NRE trampoline в связке с резолверами ассемблей), и если тестировать какое-либо расширение для Тикля, использующее внутренние API (а бинарная совместимость гарантируется только для public-API), то нужно это делать для всех версий, для которых их потом выльют.
Мэйнтейнеры тоже знаете ли не всё могут знать/проверять...
Т.е. вы разрабу Tcl сейчас пытаетесь рассказать про зависимости оного… Ну, ну.
Если что, как и с чем его и его модули собирать и откуда чего брать я прекрасно осведомлен…
А в виртуальном снэпшоте CI что-то поломать из зависимостей… да мне как-то до одного места оно.
Просто для скорости иногда хочется (или тупо нужно) и "тяп-ляп" и поломать чего можно, главное что бы быстро и не муторно.
Вы вообще видели когда-нибудь как оно тестируется… И сколько иногда надо ждать, чтобы узнать что с включенной опцией O для платформы X, в 32-битном варианте что-то безвозвратно "поломалось".
А если нужно дальше код писать на той базе (чтобы не переписывать по десять раз потом), и/или тебя еще трое разрабов ждут…
И не забывайте, что это нередко вовсе неосновная работа (и нужно еще и той заниматься за которую платят), да еще и не единственный проект как правило...
Так что ваше "Это несложно", извините, но как минимум режет слух (повторюсь — особливо для дебианов)… и очень многие мэйнтейнеры с вами тут не согласятся.
Я так-то в большей степени разраб, и на активно что-нибудь еще мэйнтэйнить просто времени нет совсем (ибо будет вероятно в ущерб остальному). Так что тут — вы мимо...
И нет, то было скорее ответом на "Это не сложно"… ибо я как раз таки согласен со Штапельбергом.
Возможно "сложно" здесь не совсем верно — есть такое слово "муторно" — так вот оно — то самое скорее. (А еще утомительно, раздражает и многое многое другое).
Тот же apt иногда выбешивает не по-детски… Вот для примера из недавнего:
Намедни нужен был мне в трависе (CI) на xenial tcl8.6 (>= 8.6.9, а родной там 8.6.5)… ну т.е. ставим из репа для старшей версии… и вот откуда-то там взялась зависимость к locales 2.29 (через libc и ко), который тупо ставится скриптом генерируя каждый locale на месте, а затем еще тащит обновления для всех postgresql (на минутку для каждого снапшота, тестируемого компилятора, и т.д.) и выключить эти обновление не представляется возможным… т.е. совсем выпилить те пакеты можно (например
apt-get install -t disco -y tcl8.6 tcl8.6-dev locales- 'postgresql*-'), а вот тупо обновить всё нужное, проигнорировав обновление locales и т.д. — выкуси (хоть пиннинг, хоть apt-mark hold, и т.д.)…Опять же есть такая опция "--no-upgrade", вот кто-нибудь может внятно объяснить что если написано:
т.е. явно указано что хочу установить 2 пакета из disco (и не апгрэйтить остальное), какого оно говорит "Skipping tcl8.6, it is already installed and upgrade is not set."?
Т.е. нужна видимо новая (двухсотая уже) опция типа
--no-upgrade-but-install.Вот и получается, что или ждать пока CI полчаса всё то установит, проверит, и т.д. (когда сама компиляция и тесты собственно менее 20-ти секунд занимают) или "велосипедить" что-то типа:
т.е. ставить нужные пакеты dpkg ручками.
И это всё вообще-то элементарщина, а maintainer(ы) такого порассказывают иногда...
Не знаю про "большинство", но очень часто "заржавел(и)" как раз maintainer(ы).
Т.е. разрабы нередко уже даленько-даленько, а в пакетах воз и ныне там…
И особливо оно касается как раз дебианов, к сожалению, по целому ряду причин, см. например...
Ну, ну…
флаг, как говорится, барабан… все дела...Так итог их сценария для "дефолного конфига" на самом деле подводится всего одной фразой:
И оно таки существует… У вас verify ACL что действительно отключен был? Кто-нибудь смог оценить сколько им на самом деле понадобилось (с дефолтными ACL)?
Т.е. qualys нашли один возможный вектор атаки (с помощью bounce) и развили его в возможный сценарий как оно при этом позволяет обойти дефолтные ACL).
Еще раз — проработали один возможный сценарий, при этом явно указав что вероятны и другие (проще и быстрее).
А в интернете как всегда притянули то что хотели за уши и теперь талдычат про «по байту целую неделю»… Ну-ну.
Кстати, кроме всё-таки несколько сложных вещей (типа упомянутого уже
BO), я на вскидку вижу еще как минимум один возможный сценарий… тоже с bounce, но с глобальным.forward(определенного вида) или локальным.forwardпользователя с привязкой к анти-спаммерам типа spamassassin. (Нужно в исходниках кое-чего глянуть).Как минимум если "режектинг" спама реализован через
deliverдирективу (у exim фильтра директиваfailчерез одно место реализована, поэтому такое сплошь и рядом).Подойдет вам в качестве так требуемого вами "определения" живой пример успешного предотвращения IDS-ом одного вектора атаки последнего epic fail от exim.
Я естественно понимаю, что то есть случай и даже некоторая удача… Но таки всё же.
Так разве непонятно как заражалось?
Не надо там 7-ми дней, от слова совсем...
Ну вот вам комманда как искать (здесь в ротированых логах):
Оцените сколько им нужно было времени.
Я к сожалению не могу, ибо в "моем" случае (например на серверах клиентов, там где stretch) везде стоял мой IDS (на базе кастомного fail2ban), так что они все посваливались в долгосрочный бан не успев ничего натворить до обновления.
Вытяжка из summary для одного адреса выглядит примерно так (я обрезал немного дабы скрипт-киддис не вводить в искушение):
Да какие-то труды… Не за что.
Кстати, глядя на тот код я право не знаю откуда такое вот берется:
Обычное переполнение… Я утрирую, но… тут на коленке за час можно инжект состряпать… Десяток емайлов (ну сотня в худшем случае) определенного содержания и "сервер наш".
Им кстати неоднократно об этом и намекалось и прямо говорилось чуть не с 2004-го года, например или здесь…
По видимому на грабли нужно наступить раз 20-ть пока дойдет.
А не надо тут разбираться.
Ну люди, мы на каком ресурсе здесь вообще?
Я понимаю клонить лень т.д., но есть жеж онлайн инструменты
Находим фикс d740d2111f189760593a303124ff6b9b1f83453d для CVE-2019-10149, а потом блеймим до изменения где тот код впервые экспериментально появился (и смотрим в каких ветках оно есть) ну или просто тупо сравниваем еще непофикшеный файл src/src/deliver.c из какого-либо предыдущего коммита (или из 0cbf2b821bb13da0268556d0e30ea627d5592c60 где оно появилось уже в том виде как до фикса) с веткой 4.84 (или с версией jessie).
У кого не прыгает на код, щелкнуть на таб "Files changed".
И видим что этот кусок кода там (в jessie версии) вовсе отсутствовал:
Есть основания кроме "ломанули сервер на jessie"?
Векторов атаки на самом деле пруд пруди и очень редко попытки идут через одну единственную дыру в одной софтине...
Факт в том, что согласно истории exim, исправленный в фиксе код впервые появился в 4.87. На jessie же 4.84.
На этом собственно всё.
Jessie во первых вовсе затронут не был, а во вторых — типа как бы "устарел".
Для текущей же стабильной ветки (stretch) — обновление 4.89-2+deb9u4 прилетело только 5 июня.
(Да и для buster 4.92-7 вылили после 07 мая судя по changelog).
А в чем проблема?
LineageOS и сейчас прекрасно ставится и работает совсем без GApps/microG...
Подпробнее например тут.
"искаропки" оно было бы, если бы sshd умел всё то сам (это однако противоречило бы философии *nix).
Аргументировано.
На собственном опыте могу сказать, что "по опыту" как правило значит чуть более чем ничего. Кхе… кхе :)
На самом деле главный аргумент приспешников blacklistd ("не нужно парсить лог") "разбивается" единственным примером:
Демон sshd (при включенном UseBlacklist) отправит инфу (authentication success/failure) на blacklistd сокет, и… запишет это в лог. Ну а blacklistd прочитает её из сокета и распарсит.
Чем оно в принципе отличается от "распарсивания" fail2ban тех же строчек прочитанных из лога, никто так и не смог мне внятно объяснить.
Кроме того, fail2ban тоже это давно умеет, а в новых версиях уже официальным протоколом и для сообщения об отдельных неудачных попытках, т.е. достаточно отправить ему на сокет: