Виктор Судаков

CloudFlare поддерживает Certificate Transparency Monitoring для тех доменов, которые в нем зарегистрированы, и присылает очень информативное письмо при выпуске нового сертификата. А как быть с остальными?

Возможно у других регистраторов есть свои инструменты, но я искал универсальный инструмент для мониторинга любого домена. Пока не нашел ничего лучше, чем Atom feed на https://crt.sh/. И вроде денег не спрашивают.

Я бы возможно предпочел в виде утилиты командной строки, читающей одну из CT баз, но работающей не нашёл.

Полезное расширение, если есть несколько учетных записей на Github и т.п.

Firefox Multi-Account Containers

Есть у меня плеер Mi Box S. В последнее время всё чаще и чаще при включении стал выдавать сообщение "Подключен к сети WiFi без доступа в Интернет". Youtube не работает, просит переподключиться. При этом VLC прекрасно играет с локального SMB сервера. Телефоны, планшет и ноутбук также через этот WiFi прекрасно ходят в Интернет. Т.е. дело явно не в ошибках беспроводной сети как таковой, и не с отсутствием выхода в Сеть на роутере. Чайниковские методы вроде "перегрузить плеер по питанию" и "пересоздать WiFi подключение" не помогают.

ОК, берем в руки Wireshark и пытаемся понять, как же плеер определяет наличие подключения к Интернету.

Сперва он успешно резолвит несколько имен, в их числе 2.android.pool.ntp.org, data.mistat.intl.xiaomi.com, connectivitycheck.gstatic.com. Потом пытается соединиться по HTTPS с сервером connectivitycheck.gstatic.com. Похоже на искомое, думаю я. Сервер предлагает вполне валидный X.509 сертификат с временем годности до 3 ноября 2020 года. А плеер ему в ответ (в TLS handshake): Alert, Certificate Expired. И всё по новой. Весь tcpdump забит этими неудачными хендшейками.

Ах ты ж, думаю, часы у плеера что ли сбились? А на экране телевизора часы плеера вполне правильное время показывают, и не заподозришь.

Иду в настройки плеера, убираю галочку "автоматически получать время из сети", подвожу локальное время буквально на минутку, сохраняю. И вуаля, моя сеть WiFi с точки зрения плеера теперь уже с доступом в Интернет.

А от 2.android.pool.ntp.org к плееру ни одного NTP-ответа не пришло. Не знаю, может раньше приходили, сейчас нет.

Ох как я зол.

Собираю варианты на случай отказа от NIS (пора закопать эту стюардессу) и нежелания управлять пользователями и группами через ansible. Рецепты:

https://www.freebsd.org/doc/en_US.ISO8859-1/articles/ldap-auth/article.html

https://arthurdejong.org/nss-pam-ldapd/ (есть в портах), о нём же https://lists.freebsd.org/pipermail/freebsd-questions/2020-March/288234.html

Схема от инженеров Facebook: https://engineering.fb.com/security/scalable-and-secure-access-with-ssh/ - работающий пример использования сертификатов с SSH c авторизацией, давно искал.

FreeIPA sux, но есть статья https://blog.hostileadmin.com/2016/03/24/integrating-freebsd-w-freeipasssd/

Samba AD DC (or Microsoft AD) + pam_winbind + security/pam_mkhomedir (вариант без LDAP).

Ссылка на тред: https://lists.freebsd.org/pipermail/freebsd-questions/2020-March/288211.html

Во FreeBSD есть удобная фича для организации IPSec туннелей: интерфейс ipsec. Включен в GENERIC ядро, т.е. доступен "из коробки".

Интерфейс ipsec автоматически создает все необходимые политики (SPD) в ядре. Пример конфигурации интерфейса (где x.x.x.x и y.y.y.y - публичные адреса нашего и удалённого роутера соответственно):

cloned_interfaces="ipsec0"
create_args_ipsec0="reqid 100"
ifconfig_ipsec0="inet 192.168.1.1 192.168.1.2 netmask 255.255.255.252 tunnel x.x.x.x y.y.y.y"

Вышеприведенная настройка создаст вот такие записи в SPD:

0.0.0.0/0[any] 0.0.0.0/0[any] any
        in ipsec
        esp/tunnel/2.2.2.2-1.1.1.1/unique:100
        spid=3051 seq=9 pid=12530 scope=ifnet ifname=ipsec0
        refcnt=1
::/0[any] ::/0[any] any
        in ipsec
        esp/tunnel/2.2.2.2-1.1.1.1/unique:100
        spid=3053 seq=8 pid=12530 scope=ifnet ifname=ipsec0
        refcnt=1
        refcnt=1
0.0.0.0/0[any] 0.0.0.0/0[any] any
        out ipsec
        esp/tunnel/1.1.1.1-2.2.2.2/unique:100
        spid=3052 seq=1 pid=12530 scope=ifnet ifname=ipsec0
        refcnt=1
::/0[any] ::/0[any] any
        out ipsec
        esp/tunnel/1.1.1.1-2.2.2.2/unique:100
        spid=3054 seq=0 pid=12530 scope=ifnet ifname=ipsec0
        refcnt=1

После конфигурации интерфейса останется только обменяться ключами (создать записи в базе SAD). Это можно сделать на статических ключах, как описано в man, или привлечь racoon или strongswan. Чтобы strongswan а) не пытался создавать свои записи в SPD и б) привязывал записи в SAD к нашим ipsec-интерфейсам и созданным ими политикам, мы напишем в ipsec.conf отдельную секцию на каждый ipsec-интерфейс, запретим в ней создание записей в SPD (они у нас уже есть) и дадим ссылку на reqid соответствующего ipsec-интерфейса:

conn ipsec0
   left=x.x.x.x
   right=y.y.y.y
   reqid=100
   authby = psk
   auto=route
   installpolicy = no

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

Сабж: https://hg.sr.ht/~vas/

С Bitbucket со временем уберу, либо они сами исчезнут в связи с прекращением поддержки Mercurial. Обновлять на Bitbucket с этого момента уже ничего не буду.

PGP ключ, которым подписываются сообщения от sr.ht, лежит тут: https://meta.sr.ht/privacy/pubkey , отпечаток вроде как "447B 69E4 B34B E90B C829 A0E9 6597 04D1 A38A 93AE".

В /usr/sbin/service в конце присутствует "env -i":

for dir in /etc/rc.d $local_startup; do
        if [ -x "$dir/$script" ]; then
                [ -n "$VERBOSE" ] && echo "$script is located in $dir"
                exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin $dir/$script $*
        fi
done

поэтому если запускать сервис вручную через "service mydaemon start", то все переменные среды будут очищены, а если запускать через /usr/local/etc/rc.d/mydaemon start", то все переменные среды рута попадут в окружение mydaemon, т.к. в самих rc-скриптах никакая очистка не производится.

По-моему это в некотором роде уязвимость. Сейчас активно обсуждается в https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235185

В RFC4217 предусмотрен механизм защиты FTP control connection: команда 'AUTH TLS' зашифровывает данные (конечно, если клиент и сервер ее поддерживают).

Но как быть с межсетевыми экранами прикладного уровня, которым нужно заглядывать в control connection для открытия дополнительных портов для пропуска data connection?

Оказывается, при помощи команды 'CCC' ftp-клиент может сообщить, что шифрование больше не нужно (например после того, как логин/пароль уже передали). Это несколько снижает безопасность, зато облегчает прохождение FTP через межсетевые экраны.

В lftp (лучший клиент!) это поведение включается строчкой "set ftp:ssl-use-ccc on" в .lftprc
Интересно, как в других клиентах, например в Far?

"openssl passwd" не работает с современными алгоритмами хэширования, поэтому приходится использовать Питон:

python3.6 -c 'import crypt; print(crypt.crypt("MySecretPass",crypt.mksalt(crypt.METHOD_SHA512)))'

Более изящные варианты welcome.

Много ли внутрироссийского трафика проходит транзитом через зарубежных операторов? По данным исследования http://www.rans.ru/images/news/Traffic_30112017.pdf совсем немного:

1) Российский сегмент сети Интернет характеризуется высокой внутренней связанностью и замкнутостью внутрироссийского трафика.

2) По оценке петлевых маршрутов: максимальное количество петлевых маршрутов от общего числа маршрутов составляет 3,5%, среднее значение – 3,05 %.

3) По оценке петлевого трафика: максимальный объем петлевого трафика (по превалирующим направлениям) от общего объема трафика, получаемого из за рубежа, составляет 2,37%, среднее значение – 1,61%.

Полученные результаты указывают на практическое отсутствие неоптимальных маршрутов и трафика через них. Таким образом, можно сделать вывод об отсутствии критичных проблем в маршрутизации внутрироссийского трафика. [...]

С учетом приведенного анализа можно констатировать, что сегодня в России сформирована одна из наиболее автономных замкнутых (самоподдерживающихся и самодостаточных) интернет - экосистем в Европе