Проект HardenedBSD, занимающийся улучшением механизмов защиты FreeBSD и выпускающий защищённые сборки FreeBSD, сообщил (http://hardenedbsd.org/article/shawn-webb/2018-04-30/hardene...) о возвращении к использованию OpenSSL, спустя более года после миграции на LibreSSL. Как следствие возвращения на OpenSSL, в качестве NTP-сервера по умолчанию будет возвращён ISC NTP вместо OpenNTPd.
В качестве причины называется сложность сопровождения решения на базе LibreSSL и существенные трудозотраты при переходе на новые выпуски LibreSSL. В частности, при обновлении LibreSSL с версии 2.6.4 до 2.7.2 всплыло большое число несовместимостей в портах, которые требуют индивидуальных внесений исправлений в порты. При расширении команды разработчиков HardenedBSD проект намерен вернуться на LibreSSL, но в данный момент продолжение использования LibreSSL невозможно из-за отсутствия необходимых ресурсов для сопровождения.
C 1 июля в ветках HardenedBSD 12-CURRENT и 11-STABLE по умолчанию будет включена сборка с OpenSSL, но поддержка LibreSSL в базовой системе будет сохранена в форме опции (для сборки слдует установить переменную MK_LIBRESSL=yes). Копия репозитория пакетов, связанных с LibreSSL, будет доступна до 1 января 2019 года, т.е. пользователям будет предоставлено 8 месяцев на обновление до OpenSSL.URL: http://hardenedbsd.org/article/shawn-webb/2018-04-30/hardene...
Новость: https://www.opennet.ru/opennews/art.shtml?num=48519
Тоже мне безопасники. Вернулись на дырявый openssl, потому что не осилили написать патчи для портов.
если безопасность не подкреплена математикой - это шутка
openssl - это шутка
> Тоже мне безопасники. Вернулись на дырявый openssl, потому что не осилили написать
> патчи для портов.Ну блин написано - на безопасность нет ресурсов. Видимо, корпоративщики как всегда показали фигу и с коммитами/рабочей силой и с деньгами. Лицензия позволяет, ниипер.
> Ну блин написано - на безопасность нет ресурсов.Харденед разрабы вообще-то всегда больше ограничивались ядром, внося в базу только мнинимальные дополнения. А мейнейнить в два-три рыла еще и не сильно маленькую репу в 30к портов немного перебор.
Но, конечно же глупо ждать от анонима хоть какого-то знания предмета - ему лишь бы вcпyкнуть при виде знакомых слов )> Видимо, корпоративщики как всегда показали фигу и с коммитами/рабочей силой и с деньгами. Лицензия позволяет, ниипер.
А не хочет ли дорогой наш эксперт всего и вся поведать нам, какая лицензия заставляет спонсировать деньгами или рабочей силой любой форк какого-то проекта? И что там со спонсированием майками QoS, например, репы арчика?
И самое главное: какие именно проприетарщики показали фигу дебиану с коммитами/рабочей силой и с деньгами, так что там даже не пытались перейти на либру?
В отличие от этой поделки дебианом пользуется сильно больше людей, а ломать все значит превратится в такую же поделку - никому не нужную. Этим ребятам явно пофиг, либраводам пофиг, почему кому-то должно быть не пофиг на агонию престарелого бомжа.
>>> Вернулись на дырявый openssl, потому что не осилили написать патчи для портов.
>> Ну блин написано - на безопасность нет ресурсов
> В отличие от этой поделки дебианом пользуется сильно больше людей, а ломать все значит превратится в такую же поделку - никому не нужную.
> этой поделки
> в такую же поделкуПолучается, дебиану можно использовать "дырявый openssl", потому что им пользуются больше людей и дебиан "не поделка". Наоборот - если перейдут на либру, то сломают все и станут поделкой.
А вот сабжу неможно переходить обратно, потому что они поделка, а невозможность втроем мейнтенить здоровенную репу просто отговорка неосиляторов?
В общем, внятно аргуменировать и логично обосновать свою точку зрения ты не осилил. Так бы сразу и писал "Дибиан лудьший и рулит! Так воть!".
> Получается, дебиану можно использовать "дырявый openssl"Думаю ребятам из дебиана виднее, и риски они оценивают правильно, имено потому их продуктом пользуются.
и эта фраза неоспорима
> А вот сабжу неможно переходить обратно, потому что они поделка, а невозможность
> втроем мейнтенить здоровенную репу просто отговорка неосиляторов?их трое, потому что никто не видит смысла в их шатаниях -> их шатания следствие...
за них этот круг никто не разорвет.> В общем, внятно аргуменировать и логично обосновать свою точку зрения ты не осилил.
Да что ты говоришь, редко приходится констатировать чтото более логичное.
> Так бы сразу и писал "Дибиан лудьший и рулит!
честно тебе скажу, дебиан 3-й с конца в моем личном рейтинге.
еще один повод для меня пересобрать libressl с git pull после обновления 16.04.4 ЛТС до 18.04 :)
Ещё раз собери. И ещё раз. На всякий случай.
> после обновления 16.04.4 ЛТС до 18.04А ты уже обновился? Не страшно?
нет...не страшно ;) а че боятся то? вся обнова прошла как по маслу.
выкидывание кода усложняет систему, ай да выкидыватели
Не смогли в миграцию, и только.
Поторопился.
Во фре тоже перешли на эту версию, щас порты допилят за неделю/месяц.А ISC NTP просто какое то днище.
Мне вот не нужно предоставлять сервис времени другим, поэтому я нашёл в хз какой документации параметры и сделал чтобы он биндился только на lo.
Проверил, работает.
Прошло немного времени и после апдейта ОС вместе с этим демоном работа сломалась.
Притом сломалась настолько, что ntpd должен обязательно слушать и обязательно обрабатывать пакеты на том интерфейсе на котором он общается с апстримами.
Те смотреть голой жопой в инет обязательно. Про фаер я слышал, но это костыльное решение ля купирования проблемы, а на рабочих станциях я фаер не держу.Поставил OpenNTPd.
Конфиг простейший и понятный.
Не хочешь предоставлять точно время другим - не биндишься к интерфейсам и оно спокойно себе работает.Ещё раз убедился что в ISC сплошные плохие кодеры, всегда обходил ихний дхцп и днс (бинд) стороной, знал бы про ntp - избежал бы траты кучи времени.
Просто к сведению: на линуксе isc-шный умеет пользоваться "подкруткой времени" в ядре и плавно его выводить на точное, ну а openntpd лупит кувалдой, как умеет, не заморачиваясь ерундой вроде монотонности системных часов.
Я в курсе, но мне оно не критично.
Монотонность обеспечивается в таймерах, там аптайм считается.
> Просто к сведению: на линуксе isc-шный умеет пользоваться "подкруткой времени" в ядре
> и плавно его выводить на точное, ну а openntpd лупит кувалдой,
> как умеет, не заморачиваясь ерундой вроде монотонности системных часов.Откуда дровишки? Плавная подстройка (при поддержке ядра) в OpenNTPd есть давно, может, это где-то сборка криво происходит?
Зато весь ISCшный софт являет собой пример монструозного энтерпрайзного оверинжиниринга. Наиболее эпично они конечно в BIND 10 оттянулись, но и остальной софт - очень в духе. И поэтому "радует" огромным attack surface и багодромом, кучей зависимостей, уроном для приваси и прочими характерными "прелестями".А openntpd - выгодно отличается мелким кодом и "security in mind". Мелкая прожка, которая делает только то что обещала. И как максимум - ну может через нее систему накрайняк левым временам накормят. Что наверное лучше чем remote code execution, которым по жизни отличается софт от ISC из-за смеси монструозности и увлечения наворачиванием фич с пофигом на безопасность. Что для сетевого софта все-таки критично.
Вот еще прекрасная NTP-реализация:
DragonFly has its own from-scratch time daemon. After pulling our hair out over the many issues with open source time daemons we decided to write one by ourselves and add new system calls to support it. dntpd(8) uses a double staggered linear regression and correlation to make time corrections. It will also properly deal with network failures (including lack of connectivity on boot), duplicate IPs resolved by DNS, and time source failures (typically 1 second off) when multiple time sources are available. The linear regression and correlation allows dntpd(8) to make rough adjustments and frequency corrections within 5 minutes of boot and to make more fine-grained adjustments at any time following when the linear regression indicates accuracy beyond the noise floor.
> Вот еще прекрасная NTP-реализация:Она работает в Linux?
И описание - довольно странное, чтоли. Какие-то "5 minutes after boot". А почему не минуту? Или не полчаса? И почему именно "after boot"? Это их "properly deal" включает в себя например сетку в ауте первые два часа после загрузки? Или wakeup из suspend to RAM вместо "boot"? Ну там лаптоп какой-нибудь с intermittent connectivity и спячкой - как на него такая логика ложится? Ну вот вообще совсем нихрена не очевидно из такого описания.
Openntpd не пытается сильно умничать, поэтому и сильных сюрпризов вроде не подкидывает. У NTPD именно алгоритмы синхронизации и коррекции часов довольно крутые. Но он в результате перерос в огромного монстра. С какими там еще керберосами, всякой полудекоративной "типа-секурити" и чем там еще. Явно лишним для выполнения задачи подкорректировать часы.
а когда isc-шный научится НЕ переводить время в давнее прошлое (делая невалидные взломанные сертификаты снова валидными)?это ведь простейшее действие -- спросить у гугл-сервера текущее время
В наших краях время положено спрашивать у серверов ВНИИФТРИ.
> В наших краях время положено спрашивать у серверов ВНИИФТРИ.Да что уж там, у ВНИИ Химических Удобрений и Ядохимикатов.
> В наших краях время положено спрашивать у серверов ВНИИФТРИ.Кем положено?
Короче, ещё один не осилил конфиг NTP и понаписал кучу ерунды, которую даже разбирать желания нет.
Осилил и пользовался много лет.
Но встал вопрос что на рабочих станциях я не желаю предоставлять сервис точного времени и использовать фаер.
В конфиге кое как нашлись опции для этого, но вскоре сломались.В общем я не хочу и не будут тратить больше своё время на поделия ISC, оно того не стоит.
Ты так хорошо его осилил, что даже не заметил в документации раздел ACL и пошел сразу рубить бинды?
За ACL в приложениях нужно сажать
Если ставить игнорировать запросы - синхронизация тоже отваливается.
ACL подразумевает обработку запросов, это как возможность для DoS так и потенциальная дырка, если там в очередной раз уязвимость найдут.Уязвимости в ntpd за последние 10 лет находили более 10 раз, притом там часто за раз была не одна узявимость а несколько.
Это одна из лидирующих по дыркам служб во фре.
Десятки инсталляций годами работают с NTP и без файерволов для чего надо было всего лишь поправить ntp.conf в разделе security. А последние несколько лет так и вообще его трогать нет необходимости. По-крайней мере во FreeBSD.
Миллионы мух не могут ошибатся ага.
Нету никакого секурити в софте от ISC, все эти надписи имеют много меньше ценности чем любая надпись на заборе.https://www.freebsd.org/security/advisories.html
Я вот смотрю сюда и просто выкидываю всё что часто встречается: openssl, ntpd.
Обновляться своевременно не пробовали?
Софт ISC 25 лет поддерживает инфраструктуру сети, в том числе и ключевую, как бы кто к нему не относился. Количество дыр соразмерно истории и наследию.
На стабле сижу.
А если ставить свежее с портов то я вот альтернативу и выбрал.Ничего он уже давно не поддерживает, так, всякие маргиналы ещё юзают бинд, дхцп и апач в придачу (знаю что не их), потому что с молодости привыкли и всё никак не переучатся.
По пачке дыр каждый год последние 10 лет в простом демоне синхронизации времени это как то чересчур.
> Софт ISC 25 лет поддерживает инфраструктуру сети, в том числе и ключевую,
> как бы кто к нему не относился. Количество дыр соразмерно истории и наследию.Количество дыр соразмеримо блоатварности и оверинжинирингу их софта, внезапно. Потому что чем больше программа - тем больше в ней багов. Включая и проблемы безопасности.
И поэтому хакер не сможет часы мне сбить, зато код выполнит, дааа? Это конечно прикольное понимание безопасности, но нет.
О, а подскажи замену isc dhcpd, а то как то сам задумался свалить с него.
dnsmasq или мой скрипт на перле: http://netlab.dhis.org/wiki/ru:software:perl:dhcp_server
> Не хочешь предоставлять точно время другим - не биндишься к интерфейсам и оно спокойно себе работает.Не хочу вас огорчать, но NTP - это UDP, а там нельзя отправлять пакеты, не забиндив сокет (ну, если не говорить про AF_RAW, которые тут явно не используются).
Так что биндится он как миленький.
А ещё на UDP сокете можно вызвать connect() и тогда он будет принимать пакеты только от одного ip:port.
Даже без этого фильтрация на одном сокете левых пакетов заметно проще.
ISC я не доверяю принципиально, они писать программы не умеют.
>> Не хочешь предоставлять точно время другим - не биндишься к интерфейсам и оно спокойно себе работает.
> Не хочу вас огорчать, но NTP - это UDP, а там нельзя
> отправлять пакеты, не забиндив сокет (ну, если не говорить про AF_RAW,
> которые тут явно не используются).
> Так что биндится он как миленький.Отправлять можно. Вот с получением будут проблемы.
> Как следствие возвращения на OpenSSL, в качестве
> NTP-сервера по умолчанию будет возвращён ISC NTP
> вместо OpenNTPd.Гм, а в чём связь? В альте, скажем, сейчас штатно поставляются именно openssl и openntpd (но есть и LibreSSL, и ntp).
> сложность сопровождения решения на базе LibreSSL ... большое число несовместимостей в портахВ этом вся суть модно-молодёжных форков, спонсируемых корпорастами для атаки на базовые библиотеки и поломку инфраструктуры OpenSource.
(1) >спустя более года после миграции на LibreSSL(2)> при обновлении LibreSSL с версии 2.6.4 до 2.7.2
Раз в год обновляют?
> (1) >спустя более года после миграции на LibreSSL
> (2)> при обновлении LibreSSL с версии 2.6.4 до 2.7.2
> Раз в год обновляют?Написано же 12-CURRENT втащили. ??
> (2)> при обновлении LibreSSL с версии 2.6.4 до 2.7.2
> Раз в год обновляют?
/usr/src]$ git log crypto/libressl
Date: Sun Dec 31 16:41:10 2017 +0100crypto/libressl: Update to 2.6.4
Date: Sat Nov 11 19:23:27 2017 +0100HBSD: crypto/libressl: Update to 2.6.3
Date: Tue Jul 18 19:03:55 2017 +0200hBSD: Complete merge of LibreSSL 2.5 changes
Date: Wed Feb 1 09:48:58 2017 +0100HBSD: Import LibreSSL 2.4.5 from upstream