⌨ Labor omnia vincit ☮

QuckLisp: how to use my own local changes?

Posted in Lisp by anaumov on 04.12.2018

One of the first beginner’s questions regarding using QuickLisp is – how to build some Common Lisp project and to see the effect of the local changes if this project is already in the QL-repository? The problem is – each time, when you try to build such project, QL will try to download sources from its repository and that means that local changes will be ignored. First you will maybe try to change the build configuration asd-file, right? This is the wrong way.
In QuickLisp blog I found one post about The Quicklisp local-projects mechanism. One of the goals of this mechanism is to override libraries Quicklisp does provide. Namely, the solution is just a PATH of such projects, i.e. you just should to clone your git-repo into ~/quicklisp/local-projects directory. That location tells QuickLisp to use local source tree and doesn’t use some remote QL-repositories during the build process. You don’t need to change some asd-file or something like that. Good luck and don’t forget to have a lot of fun with Common Lisp 😉


Configuring SNMP v3 on OpenBSD 6.4

Posted in OpenBSD by anaumov on 27.11.2018

Today everyone who cares about its network infrastructure security choice commercial solutions and buys hardware appliances. Usually it’s an easy-to-use “boxes” with some number of network services. Vendors of this appliances provides support. This is one of the reason why many managers like it and choose it. But most important here – usually on those boxes runs OpenBSD. And it is the reason why we, engineers and developers, who are responsible for infrastructure security, love it too 😉
I think, it’s not needed to explain how it’s important to monitor your infrastructure. But it’s also very important to do it in secure way, right? Unfortunately, in its book Absolute OpenBSD Michael Lucas explains about second version of the Simple Network Management Protocol – SNMP v2c – but this is not what we want and should to use today! SNMPv3 – the latest version of SNMP – doesn’t solve all kind of problems, but its usage is more and more desirable today.

Wikipedia says:

As of 2004 the IETF recognizes Simple Network Management Protocol version 3 as defined by RFC 3411–RFC 3418[18] (also known as STD0062) as the current standard version of SNMP. The IETF has designated SNMPv3 a full Internet standard,[19] the highest maturity level for an RFC. It considers earlier versions to be obsolete (designating them variously “Historic” or “Obsolete”).

keep reading…

I’m going to LinuxDay in Dornbirn, Austria

Posted in Events, openSUSE by anaumov on 10.10.2018

1200px-textil_htl_dorbirn1This weekend I am going to LinuxDay, the German-specking Free Software one-day event. It takes place in the higher technical school in Dornbirn, Austria.
Organized by Linux User Group Vorarlberg, it scheduled two timelines of presentations/talks and stands of the many Free Software projects including openSUSE, Debian, Devuan, etc. It looks a bit like a LinuxTag or FOSDEM. Here you can find photos from the last years.

This time it celebrates 20 years, so I think it is a good reason to visit this event now. And not just this. It is very beauty there in this time of the year. For sure I will take my family there and continue to enjoy the traveling on Sunday 🙂

Libre Linux (GNU Kernel) on openSUSE

Posted in Linux Kernel, openSUSE by anaumov on 09.10.2018

As we known, openSUSE project doesn’t provide official packages for Linux Libre kernel. There is a simple reason for that: default openSUSE kernel doesn’t include some proprietary modules; it’s free. All proprietary parts of the kernel could be found in a separate package kernel-firmware. But anyway there are users who want to use exactly GNU version. So, why not? This short tutorial describes how to build and install Libre Linux on openSUSE Leap 15.1 (openSUSE TW needs the same instructions).

Right now in the Leap 15.1 repository the kernel version is 4.12.14.

> uname -r

Let’s check the latest available 4.x kernel on the FSF server. Right now the latest avaliable kernel there is version 4.18. Its size is less then 100 Mb. Download it:

> wget -c \

Before we continue, I will recommend to verify file integrity. The .sign files can be used to verify that the downloaded files were not corrupted or tampered with. The steps shown here are adapted from the Linux Kernel Archive, see the linked page for more details about the process.

wget -c \

Having downloaded the keys, you can now verify the sources. You can use gpg2 to verify the .tar archives. Here is an example of a correct output:

> gpg2 --verify linux-libre-4.18-gnu.tar.xz.sign
gpg: assuming signed data in 'linux-libre-4.18-gnu.tar.xz'
gpg: Signature made Mon 13 Aug 2018 01:25:14 AM CEST
gpg:                using DSA key 474402C8C582DAFBE389C427BCB7CF877E7D47A7
gpg: Can't check signature: No public key

> gpg2  --keyserver hkp://keys.gnupg.net --recv-keys \
key BCB7CF877E7D47A7:
12 signatures not checked due to missing keys
gpg: key BCB7CF877E7D47A7: \
public key "linux-libre (Alexandre Oliva) " imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1

> gpg2 --verify linux-libre-4.18-gnu.tar.xz.sign 
gpg: assuming signed data in 'linux-libre-4.18-gnu.tar.xz'
gpg: Signature made Mon 13 Aug 2018 01:25:14 AM CEST
gpg:                using DSA key 474402C8C582DAFBE389C427BCB7CF877E7D47A7
gpg: Good signature from "linux-libre (Alexandre Oliva) " [unknown]
gpg:                 aka "[jpeg image of size 5511]" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 4744 02C8 C582 DAFB E389  C427 BCB7 CF87 7E7D 47A7

The primary key fingerprint looks good.

If everything goes well, untar downloaded kernel:

> tar xfv linux-libre-4.18-gnu.tar.xz
> cd linux-4.18

Well… now comes the personal part of the installation process, i.e. you know better what’s you should to care about during creating the config file, what’s hardware do you have and your kernel should support, what kind of optimization do you want to have, etc. That’s the most important step of this entire tutorial. For example, good configured kernel could save few seconds of boot time, bad configured kernel will doesn’t boot at all 🙂
To prepare the configuration file, you will need a base kernel configuration, it’s a plain text file calling .config. The are many ways to create .config file. It’s the same like for official Linux Kernel.
Before we can configure our new kernel we will need to install all needed dependencies.

# zypper in gcc make ncurses-devel bison flex libelf-devel libopenssl-devel bc
# make menuconfig
# make -j4
# make modules_install
# make install

If you newer built a linux kernel before and it makes you scary, you can just make make menuconfig and just close it without to change anything. It will scan your hardware and generate a default config. This configuration will include much more then you will really need, but it guarantees that the new kernel will boot.

After installing we can still find the native openSUSE default-kernel in the GRUB menu. I think, this is the default behavior today in the most GNU/Linux systems. Thus, if something goes wrong and, for example, your new self-configured kernel will not boot, don’t worry.

> uname -r

I think, if it’s your first experience with the kernel compilation process and you will get new kernel that will boot and it will be smaller then default openSUSE kernel, you can be proud of yourself.
Whatever you will get, don’t forget to have a lot of fun 🙂
More info about Linux kernel for beginners could be found on the https://kernelnewbies.org/. More info about GNU Libre Linux could be found on the https://www.fsfla.org/ikiwiki/selibre/linux-libre/index.en.html. And, finally, if you interested in the openSUSE Linux kernel development process, you are always welcome to visit openSUSE wiki portal 😉

virsh, tell me VM’s IP

Posted in Network by anaumov on 08.10.2018

Сколько же я в пусую потерял времени, не зная, что virsh, оказывается, может без всяких лишних телодвижений просто сказать IP VM. До этого приходилсь постоянно опрашивать arp-кеш. Теперь жизнь станет существенно легче. Если вы, как и я, разработчик, и вам не приходится ежедневно заниматься работой с инфраструктурой, то возможно вы об этом не знаете. В этом случае, думаю, эта инфомация вам пригодится.

К примеру, мне нужно посмотреть какой IP в процессе установки получила VM leap151. При помощи list -all как обычно virsh покажет список всех виртуальных машин, а при помощи domifaddr покажет и айпишник.
Когда-то давным-давно нашел команду domiflist и почему-то решил (не спрашивайте почему (может тогда этой фишки действительно еще не добаили, не знаю…)), что это все, что получится вытянуть через консоль. По этой причине приходилось переводить MAC в IP при помощи заглядывания в arp, для которого нужно, кстати сказать, доустанавливать клиент.

# virsh list --all
 Id    Name                           State
 2     debian9                        running
 3     centos                         running
 5     leap151                        running
 -     fedora28                       shut off
 -     kubuntu                        shut off
 -     SunOS                          shut off
 -     tumbleweed                     shut off

# virsh domiflist leap151
Interface  Type       Source     Model       MAC
vnet2      network    default    virtio      52:54:00:d7:a6:ab

# virsh domifaddr leap151
 Name       MAC address          Protocol     Address
 vnet2      52:54:00:d7:a6:ab    ipv4


Решил записать, дабы снова не тратить время на поисковик.

How to detect SSH or SCP is using?

Posted in Network, security by anaumov on 27.09.2018

That was interesting to spend some time and to try to detect what kind of service is use SSH. As you know, OpenSSH provides ssh(1) and scp(1) programs. Both use the same protocol and the same port number. In fact, both programs has been developed exactly with purpose to be secure enough to protect its users to network packet analysis. But there is nothing more interesting that to try to figure out how exactly all these things works together and try to find a way to detect what service is used on the server.

My first idea was to get this information from OpenSSH server itself, because I was pretty sure that packet analysis will not help me. There is an option in the config file calling LogLevel. The default value (tested on openSUSE) is set to INFO. Let’s change it to DEBUG3 and restart OpenSSH server. After that try to copy something to the server and check the syslog:

As you can see, server provide this information very easily. The problem is – I need to be root and I need to reconfigure and restart OpenSSH server… that is not intelligent and that’s why it’s a bit boring. How we can get the same information without root-right on the server? There is the second way to get it. You will not need root-right, you will not need to be on the server at all.

Welcome to the network packets analysis 🙂

Yeah, I was wrong to thinking that sniffer will not help. But please don’t misunderstand me, SSH connections is pretty secure! There is no way no recognize or find some differences in secure shell or secure copy connections. What kind of authentication is used – password or publickey authentication – is also terra incognita. Packets generated by OpenSSH looks same in all cases. At least by authentication phase… 🙂

As you know, SSH is a cryptographic network protocol and it operates on the Application layer. It’s great and amazing, but it does nothing with bottom layers. And this is exactly where our story begins.
As I said, authentication phase is secure, but after the new connection is established (open_session phase is done) the picture changes drastically and I would even say – dramatically. The culprit here becomes a DSCP/ToS or Differentiated services.

Differentiated services, as the name says, differentiates the ToS-bit depend on used service. In case of SSH, for secure shell ToS-bit will be sets to 0x10 and for secure copy it has value 0x08. Yes, it seems that the IP header (where ToS-bit is) “includes information” about upper layers content… Unbelievable. I know, it sounds like a craziness. I’m still think that I get something wrong, but let’s repeat it together.

The tcpdump’s expression for filtering content of IP header looks like this:

sudo tcpdump -n -i any -v 'ip[1] & 0xfc == 0x10' and port 22

This filter will parse IP packets, where ToS sets to 0x10 (for normal secure shell).
Change it to 0x08 to get a filter for SCP-connections.

You don’t need to be root on the machine where OpenSSH server is running, you don’t need to login on this machine at all. As we all know, to sniff the traffic (encrypted or not) can be easily happen by using the MITM-attack.

You can add port 22 at the end of tcpdum command to get “SSH packets”, but don’t trust it too much, because… to reconfigure OpenSSH server to use other port, say 2222, is not a big deal. Unfortunately, it seems like tcpdump doesn’t support filters for application protocols like SSH and we can just sets the port number (in the hope of the using of standard port). But there could be used a small trick – at the beginning of the connection establishing (exactly after TCP three-way-handshake), OpenSSH client and server exchange its application version and version of used SSH protocol. It’s not encrypted. This wireshark screenshot shows that system has no idea to what service/protocol belongs this data and it says just “Data”, but you can see in TCP header that port of server is 2222:
Should I say, that theoretically every server (implemented by bad guys) can send the similar “fake SSH-data” to deceive or just to confuse you? 🙂 So, be careful with filter for something like *OpenSSH_; check it carefully.

Russian KDE community

Posted in KDE, SuSE [ru] by anaumov on 20.09.2018

KDEНаконец-то увидел свет новый движок портала https://kde.ru, посвященного русскоязычным пользователям KDE и проету KDE в частности. И хотя сам я уже давно KDE не пользуюсь, до сих пор многое связывает меня с этим проектом. Именно с разработки KDE начался мой путь в мир свободного ПО. Еще будучи студентом я познкомился с проетом GNU, Linux и Qt3, а уже после, в Германии – когда я начал работу в SUSE – занимался разработкой и портированием стека KDE4 на openSUSE (больше всего постов в этом блоге именно о KDE и openSUSE). Мы тогда еще сидели на svn, помните что это такое? 🙂
После SUSE я забросил проект KDE, опробовал и пересел на различные window managers. До тех пор, пока не устроился разработчиком LiMux (Kubuntu на основе собственной management-системы на основе LDAP) тут, в Мюнхене. И хотя занимался я в основном security-проектами,  было приятно вспомнить и почти весь KDE стек, который мы создавался более чем 10 лет назад.

Это очень интересный проект. Да, он большой, очень большой, и не всегда это хорошо, тем не менее он обладает самой на мой взгляд продуманной архитектурой. Программировать KDE всегда было здорово не только из-за мощи Qt и самым новейшим инструментам, используемым в проекте, но и благодаря идеям, заложенным в основу структуры стека его компонентов. Очень важным в проекте KDE всегда было сообщество людей, его разрабатывающих. Его окружило много молодых инженеров, открытых для новых, а порой даже и для откровенно сумасшедших идей. Это так освежало. Это так вписывалось в природу свободного ПО. Я никогда не забуду эти хиппи-тусовок по всей Европе, куда мы добирались по ночам и самыми сумасшедшими способами, доклады, подготавливаемые и читаемые друг другу просто ради удовольствия.

Я рад, что и в России есть люди, продолжающие разработку и продвигающие этот проект. Хочу пожелать вам, ребята, удачи. Постарайтесь сохранить эту атмосферу, сводящую с ума и увлекающую за собой. Я думаю, это самый большой стимул для разработки ПО. Увлечение процессом, удовольствие от наконец-то найденного решения, восхищение его элегантностью и простотой. Все это KDE, все это – сообщество людей, его продвигающих.


Posted in Hacker culture by anaumov on 31.07.2018

Давно хотел написать пару строк об этом журнале, но все руки не доходили довести пост до состояния, когда его наконец уже можно опубликовать. В прошлом месяце вышел очередной его выпуск, но из-за смены работы у меня снова не дошли руки. Среди security-инженеров так же бытует мнение, что это не то издание, о котором стоит рассказывать “широким массам”. Спорный момент. Так или иначе No Starch Press выпустила печатное издание всех номеров журнала.

Итак, для тех, кто слышыт об этом журнале впервые, International Journal of Proof-of-Concept or Get The Fuck Out или просто PoC || GTFO представляет из себя интернет-журнал для технарей, любителей поиграться с ЭВМ, чья осведомленность принципами работы последнего не должна вызывать никаких сомнений, ребят, в конец отбившихся от рук и, как правило, стоящих на учете в соответствующих огранах… одним словом – сетевых, тьфууу, хулиганов.
А теперь серьезно – этот материал будет немного покрепче 2600 или Phrack. Материал, публикуемый там, называют “научными публикациями” той же тематики. Там не учат ни С, ни ассемблеру, ни основам микроэлектронники, ни скользким моментам различных поведений программ на разных платформах, где работа типов процессоров отличается – все это надо иметь при себе.

Спектр тем включает в себя computer science, intellectual challenge, hacker culture, reverse engineering, микропроцессоры и микроэлектронику вообще (доходит до химии (да, надо сказать методы, к которым прибегают авторы для достижения описываемых целей, очень и очень креативны)), эксплойды… кстати, в отличие от многих других изданий, там не просто публикуются все новые и новые эксплойды с коротким описанием, словно в новостной ленте, но подробное описание принципов, нарушение которых и привели к ошибке и легли в основу эксплойда. Подробно описывается сам процесс анализа, да и вообще причин, из-за которых этот анализ проводили. Издание учит учиться. И мыслить шире. Порой складывается впечатление, что авторы специально выбирают нетипичные методы взлома, если процесс от этого станет интереснее. Объективности ради надо сказать, что не все темы связаны с security, но безусловно все – с красотой процесса и творческим подходом к решению задачи, оценить которые, как оно обычно и бывает в разных областях искусства, смогут далеко не все.

Leap 15.0 Beta testing: Fujitsu U757 Laptop

Posted in Linux Kernel, SuSE [ru] by anaumov on 25.05.2018

2 месяца назад нашел незначительный, но все же баг в ядре openSUSE Leap 15.0 (тогда еще это была Beta, build 174). Баг связан с лептопом Fujitsu U757 и воспроизводиться должен во всех дистрибутивах, т.к. проблема в upstream коде ядра.
Суть проблемы связана с поддержкой мультифункциональных клавиш, отвечающих за включение/выключение wifi.

Чтобы удостовериться, что kernel не обрабатывает нажатие клавиш, можно воспользоваться libinput. Это так называемый input device driver для X.org window system. С его помощью можно легко (в userland) отлавливать события, которые должны быть обработаны ядром. Так вот он показывал, что комбинация клавиш Fn+F5 при нажатии не давала никакого эффекта (F5 – это wifi-клавиша).
Тем не менее, при помощи rfkill wireless можно легко включить/отключить:

# rfkill list
0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
# rfkill block 0
# rfkill list
0: phy0: Wireless LAN
        Soft blocked: yes
        Hard blocked: no

Как оно обычно и бывавает, много времени уходит на то, чтобы собрать достаточно материала. Долгое время я не был уверен, что делаю все верно. С толку сбивало и то, что в других дистрибутивах проблема воспроизводилась один в один. Я отключил Bluetooth в BIOS, чтобы только одно устройство влияло на работу LED на корпусе лептопа. Таким образом, LED должен был загораться при включении wireless и наоборот – тухнуть при выключении. Этого не происходило…

Я решил опробовать другие ядра. Я ставил ядро из репозиториев Kernel:stable (на тот момент это было ядро 4.15.13) и Kernel:HEAD (4.16 rc7-1). Это не решило проблему.

Спустя какое-то время я нашел в сети описание этой проблемы и патч. Я отправил bugreport. Такаши, один из разработчиков в Kernel Team, сказал мне, что патч будет принят в upstream в 4.17-rc1. В стандартное Leap-ядро этот фикс сразу же не попал, т.к. баг не слишком критичен, НО Такаши пересобрал ядро с этим исправлением для SLE15 и Leap15. Leap пользователи могут установить его отсюда. Это исправление будет в Leap совсем скоро официально, в виде maintenance update.

После установки этого ядра libinput отлавливает events:

# libinput debug-events

 -event7  KEYBOARD_KEY   +3.51s  KEY_RFKILL (247) pressed
  event7  KEYBOARD_KEY   +3.51s  KEY_RFKILL (247) released

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

Удачи! Have a lot of fun =)

The Linux Programming Interface: Russian edition

Posted in books, GNU/Linux by anaumov on 23.03.2018

LPIbookСлучайно заметил в одном из российских интернет-магазинов перевод The Linux Programming Interface Майкла Керриска. Не удержался и сразу же заказал его 🙂
Русское издание по качеству практически не отличается от оригинала. Я уверен, что многие это оценят.
Про английскую версию я писал ранее.
Книга очень классная; пожалуй одна из лучших в моей библиотеке по системному программированию в GNU/Linux (подробно описывается работа с библиотечными функциями/вызовами, нюансы работы с памятью, shared libraries, несколько последних глав посвящены в том числе и сетевому программированию… и многое и многое другое). Книга содержит множество продуманных полнофункциональных программ, доступно иллюстрирующих все теретические концепции и будет очень полезна тем, кто уже хорошо знает язык С и хочет плотнее поработать с операционной системой.
Англоязычное издание этой книги вышло почти 7 лет назад. С тех пор kernel да и glibc претерпели немало изменений. Тем не менее, актуальность материал не утратил. Потому что во-первых, интерфейс API остается практически неизменным, т.е. разработчики его меняют очень осторожно. Причина тому – совместимость программ в userland с новыми версиями glibs и kernel. Во-вторых, изменения вносятся лишь в виде дополнений, но не как не изменений поведения и модификаций уже существующих интерфейсов. Кстати, для тех, кому интересно – вот тут можно посмотреть как менялись API от версии к версии. Занятное чтиво для ботанов %)

Leap 15.0 Beta testing: configuring 802.1x (auth with RADIUS)

Posted in Network, security, SuSE [ru] by anaumov on 15.03.2018

В этом посте я попытаюсь рассказать как настроить IEEE 802.1x в openSUSE. Сейчас Leap 15.0 в активной стадии бета-тестирования, поэтому возьмем её и для клиента и для сервера, чтобы убедиться, что все работает как надо, и никаких неприятных сюрпризов в финально-официальном релизе нам ждать не придется.

Если в двух словах, 802.1x это стандарт сетевой аутентификации. Работает на втором OSI уровне и определяет механизм контроля доступа к сети на основе принадлежности к порту и проверки x509-сертификатов. Доступ к сети получают только клиенты прошедшие аутентификацию. В качестве “системы, проверяющей подлинность” или просто аутентификатора я буду использовать CISCO SG300-28 28-Port Gigabit Managed Switch. Для проверки он будет обмениваться сертификатами с authentication server, который мы попытаемся развернуть на отдельной машине и который будет колдовать для нас x509 TLS-сертификаты.

Authentication server

Когда я только задумывал этот пост, я представлял это себе как “пустяковое дело на 20 минут”. Сразу же после установки я понял, что “приключение начинается”. Инсталлер разучился отключать firewall и включать OpenSSH. Фича? Аха щас… BUG! Первый баг. Попался 🙂 Пытался сначала достучаться до людей в IRC, все бестолку. Три дня думал, что я что-то пропустил и искал информацию. Так ничего и не найдя, я заглянул в ML, где меня ждал успех.

Очень не приятно после установки заходить в систему и отключать firewalld и включать sshd… но на сейчашний момент это именно то, что мы имеем:

# systemctl stop firewalld
# systemctl disable firewalld
# systemctl start sshd
# systemctl enable sshd

Напомню, что мы тут просто тестируем 802.1x. На практике отключать firewall конечно же не обязательно, достаточно открыть UDP/1812 и UDP/1813 порты.

Приступаем к установке authentication server. Мы будем использовать freeradius. Последняя стабильная версия – 3.0.16 – вышла два месяца назад. В openSUSE пакет называется freeradius-server. Устанавливаем его:

> sudo zypper in freeradius-server
> rpm -qa freeradius-server

После установки переходим в /etc/raddb/certs. Тут все будем делать от root.

# ll /etc/raddb/certs
total 48
-rw-r----- 1 root radiusd 6155 Feb 20 06:18 Makefile
-rw-r----- 1 root radiusd 8714 Feb 20 06:18 README
-rwxr-x--- 1 root radiusd 2706 Feb 20 06:18 bootstrap
-rw-r----- 1 root radiusd 1432 Feb 20 06:18 ca.cnf
-rw-r----- 1 root radiusd 1103 Feb 20 06:18 client.cnf
-rw-r----- 1 root radiusd 1131 Feb 20 06:18 inner-server.cnf
-rw-r--r-- 1 root radiusd  166 Feb 20 06:18 passwords.mk
-rw-r----- 1 root radiusd 1125 Feb 20 06:18 server.cnf
-rw-r----- 1 root radiusd  708 Feb 20 06:18 xpextensions

Документация о том, как сгенерировать сертификаты (самый минимум) находится в файле README. 3 шага: генерация root-сертификата (ca.pem), генерация сертификата сервера (server.pem) и клиента (client.pem). Необходимые параметры нужно указать в конфиг файлах: ca.cnf, server.cnf и client.cnf соответственно.

Несмотря на то, что все кажется простым и логичным, генерация TLS/SSL сертификатов может быть оказаться достаточно запарным процессом. Особенно если вы нечасто этим занимаетесь. Дело в том, что сообщения об ошибках не всегда понятны. Давайте рассмотрим пару примеров.

Во-первых, нигде не сказано, что пароль в /etc/raddb/certs/server.cnf и /etc/raddb/mods-enabled/eap должен быть один и тот же. Вот в этом месте файла /etc/raddb/mods-enabled/eap надо быть осторожней:

        tls-config tls-common {
                private_key_password = myTEST1eap
                private_key_file = ${certdir}/server.pem

Вот так выглядит часть /etc/raddb/certs/server.cnf файла, где нужно быть чуточку внимательней:

[ req ]
prompt                  = no
distinguished_name      = certificate_authority
default_bits            = 2048
input_password          = myTEST1eap
output_password         = myTEST1eap
x509_extensions         = v3_ca

Если пароли окажутся разными, то при запуске cервера мы получим в логах вот это:

Wed Mar  7 17:08:15 2018 : Info: Debugger not attached
Wed Mar  7 17:08:15 2018 : Error: tls: Failed reading private key file "/etc/raddb/certs/server.pem"
Wed Mar  7 17:08:15 2018 : Error: tls: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
Wed Mar  7 17:08:15 2018 : Error: tls: error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal error
Wed Mar  7 17:08:15 2018 : Error: tls: error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe crypt
Wed Mar  7 17:08:15 2018 : Error: tls: error:0907B00D:PEM routines:PEM_read_bio_PrivateKey:ASN1 lib
Wed Mar  7 17:08:15 2018 : Error: tls: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib
Wed Mar  7 17:08:15 2018 : Error: rlm_eap_tls: Failed initializing SSL context
Wed Mar  7 17:08:15 2018 : Error: rlm_eap (EAP): Failed to initialise rlm_eap_tls
Wed Mar  7 17:08:15 2018 : Error: /etc/raddb/mods-enabled/eap[14]: Instantiation failed for module "eap"

Согласитесь, с ходу не ясно в чем тут может быть проблема.
Остальные пароли могут быть (должны быть) разными.

Во-вторых, можно забыть про команду:

# openssl dhparam -out dh 2048

В bootstrap скрипте она есть, но если вы решите сгенерировать сертификаты дважды и отчистите все командой

# make destroycerts

то make удалит и файл /etc/raddb/certs/dh, а при make ca.pem или make server.pem файл dh снова создан не будет. При запуске сервера это приведет к следующему сообщению в логах:

Wed Mar  7 16:18:44 2018 : Info: Debugger not attached
Wed Mar  7 16:18:44 2018 : Error: Unable to check file "/etc/raddb/certs/dh": No such file or directory
Wed Mar  7 16:18:44 2018 : Error: rlm_eap_tls: Failed initializing SSL context
Wed Mar  7 16:18:44 2018 : Error: rlm_eap (EAP): Failed to initialise rlm_eap_tls
Wed Mar  7 16:18:44 2018 : Error: /etc/raddb/mods-enabled/eap[14]: Instantiation failed for module "eap"

Обратите внимание, что в README файле написано, что удалять старые сертификаты нужно вот так:

# rm -f *.pem *.der *.csr *.crt *.key *.p12 serial* index.txt*

т.е. без dh файла. Это, пожалуй, единственная проблема, суть которой ясна из сообщения об ошибке.

И вот еще одина проблема, с которой, я надеюсь, никому не придется столкнуться:

failed to update database
TXT_DB error number 2

Она возникает по причине того, что CN (Common Name) для генерируемого сертификата такое же как и для CA-сертификата.

Последний шаг настройки RADIUS – прописываем имя, ip и secret клиента (остальное можно оставить как есть) в /etc/raddb/clients.conf. Клиент в данном случае – наш cisco-коммутатор. Шаг простой, но очень важный. Без него RADIUS не будет отвечать коммутатору. Secret тут должен быть как можно сложнее.

После того как все сертификаты созданы, для уверености их можно сверить:

# openssl verify -CAfile ca.pem client.crt client.pem
client.crt: OK
client.pem: OK

Если все в порядке, запускаем сервер, проверяем созданные им сокеты:

# systemctl start radiusd

# lsof -i :1812
radiusd 4811 root    7u  IPv4 179990      0t0  UDP *:radius 
radiusd 4811 root    9u  IPv6 179994      0t0  UDP *:radius 

# lsof -i :1813
radiusd 4811 root    8u  IPv4 179993      0t0  UDP *:radius-acct 
radiusd 4811 root   10u  IPv6 179995      0t0  UDP *:radius-acct

# tcpdump -vv -n -i eth0 -S port 1812 -l -A -X

Последняя команда может помочь при отладке. Вы видете, что именно ушло в сеть. Даже если вы подробно не знакомы с EAP, можно заметить отличие удачных попыток авторизации и не очень удачных 🙂 Если по той или иной причине возникли проблемы, log radius-сервера находится в /var/log/radius/radius.log.
Если все же возникнет какая-то новая проблема, которая тут не описана, и вы начнете искать информацию в инете и найдете примеры программы radtest(1) и попытаетесь ее запусить… в openSUSE она лежит в отдельном пакете:

> rpm -qf $(which radtest) 

Я не стал описывать ВСЕ, что мне пришлось пережить за эти пару дней… и так этот пост разбух и стал походить на статью. Возможно я напишу еще что-то о самой openssl в отдельной статье. Тема PKI очень интересная и нужная. Ее понимание требуют многие работадатели.

Но вернемся к нашему тестированию. Переходим к настройке нашего коммутатора. Пока новых жуков не обнаружено 🙂


Настройка аутентификатора (или “системы, проверяющей подлинность”) сводится к простому добавлению в список RADIUS-серверов только что настроенной машины. Security => RADIUS => Add:

В появившемся окне просто добавляем IP-адрес и secret, который мы указывали /etc/raddb/clients.conf на RADIUS-сервере. Secret – это фактически единственный механизм аутентификации между cisco-коммутатором и сервером проверки подлинности (RADIUS). Эта часть сети в 802.1x-схеме подразумевает достаточно доверительные отношения между хостами, т.е. остается практически не защищенной. Поэтому повторюсь – secret должен быть как можно сложнее.


Переходим к последнему шагу – настройке клиента.
Да, друзья мои, в качестве клиента openSUSE сейчас использовать увы, не получится. Для тестирования 802.1x мне пришлось взять какой-то другой GNU-дистрибутив. Но обо всем по порядку.

Сначала я поставил Leap 15.0 Beta с Plasma 5.12 LTS. networkmanagement отказался создавать соединение, и я сначала подумал, что проблема в созданных мной сертификатах. Я потратил несколько дней на проверку и перегенерацию сертификатов. Я устанавливал Leap с GNOME… с Xfce… и вообще без X. Паралельно я проверял все в Tumbleweed, и это меня и сбило с толку. Там соединение тоже не работало и я подумал, что проблема на 8 OSI уровне 🙂
Через несколько дней я попробовал другие GNU-дистрибутивы и оказалось, что, используя те же самые сертификаты и конфиги, там соеднинение удается создать одной командой…

BUUUUG! Да, черт побери, и сидит он так глубоко, что ни одним NM-апплетом его не достать. Он воспроизводится и через nmcli(1):

# cat /etc/NetworkManager/system-connections/LEAP_8021x





# nmcli con reload

# nmcli con up LEAP_8021x
Secrets are required to access the wired network 'LEAP_8021x'
Warning: password for '802-1x.identity' not given in 'passwd-file' and nmcli
cannot ask without '--ask' option.
Error: Connection activation failed: Secrets were required, but not provided

Secret я использую и в конфиге и прописывал его и в апплетах GNOME и KDE. Не принимает ни в какую.
Пробовал испльзовать ‘–ask’, результат тот же: спашивает, вводишь пароль… снова спрашивает, снова вводишь… снова спрашивает…

# nmcli con up LEAP_8021x --ask
Secrets are required to access the wired network 'LEAP_8021x'
Identity (802-1x.identity): GNOME
Secrets are required to access the wired network 'LEAP_8021x'
Private key password (802-1x.private-key-password): *****
Secrets are required to access the wired network 'LEAP_8021x'
Identity (802-1x.identity): GNOME
Secrets are required to access the wired network 'LEAP_8021x'
Private key password (802-1x.private-key-password): *****

Я использовал и wpa_supplicant(1). Результат такой же. Он просто повисает.

Чтобы довести дело до конца я взял Kubuntu 17.10. Выбор был не случайным, т.е. это не был “первый дистрибутив, который попался под руку”. Пока я искал инфу по поводу проблем с 802.1x, я нашел этот BUG. Я не уверен, что это именно то, но повеселил меня не тот факт, что проблема в upstream’е, а то, КАК это решили в Ubuntu 🙂 Ребятами из RedHat (хотя там ссылка на GNOME, а оттуда на Debian…) было предложено и другое решение. Следить за изменениями я уже не стал. Хотя разобраться до конца все же стоило бы.

В Kubuntu 17.10 просто кидаешь конфиг в /etc/NetworkManager/system-connections/802.1x и перезапускаешь сеть (без ‘–ask’), как я показал выше. Понадобятся 3 сертификата: клиентские сертификаты client.pem и client.crt (к ним надо знать secret) и root-сертификат CA.pem. При генерировании новых клиентских сертификатов нужно лишь обновить client.cnf (имя и secret) и сделать

# make client.pem

Помните, что в случае повторной генерации root-сертификата придется перенастраивать уже настроенные клиенты.

Итак, ситуация Leap 15.0 пока очень и очень не классная. BUG’ов в beta хватает. О них знают, и можете быть уверенными, друзья мои, их исправят.
Оставайтесь на светлой стороне. И да прибудет с вами удовольствие от работы с openSUSE 🙂

openSUSE Leap 15.0: call for testers

Posted in SuSE [ru] by anaumov on 23.02.2018

Самый разгар тестирования следующей major-версии openSUSE – Leap 15.0. Beta доступна уже без малого месяц. Как и обычно, качество системы зависит от нас с вами, друзья. Для тех, кто никогда не принимал участия в разработке openSUSE, но хотел бы наконец-то помочь, самое время скачать Leap 15.0, установить и погонять его по самые не балуй 🙂 на своей машине (хотя бы виртуальной) или машине своего коллеги 😀 Помните, что beta-версия нестабильна и может сломаться в самом непредсказуемом месте.
О всех найденных ошибках надо сообщить нам в bugzilla.

Важно понимать, что система разрабатывается силами сообщества, и ее качество в большей мере зависит он нас с вами. Ошибается тот, кто думает, что в Нюрнберге все и так сделают как надо и даже лучше. Там ребята работают главным образом над SLE – тем, что приносит SUSE деньги. Дистрибутив openSUSE отдан сообществу: энтузиастам, дизайнерам, программистам… и простым пользователям. У нас есть права менять его как мы захотим. Более того – от нас этого ожидают. Не будем же делать вид, что это не так.

Итак, что мы имеем на сейчашний момент? На момент написания этого поста актуальным является build139. Второй и третьей официальной beta, как это было когда-то, не будет. Теперь beta меняется по принципу rolling release. Уже где-то через месяц, в апреле/мае, мы перейдем на фазу release candidate. Было бы здорово найти как можно больше и начать работать над исправлениями ДО начала этой фазы.
Так как следующий Leap получится мажором, поддерживаться он будет не 12 (в отличии от минорных релизов, привязанных к SUSE Linux Enterprise Service Packs), а 36 месяцев.

Так что же собственно тестировать? Для каждого из нас есть свои use cases. Кто-то админит самый обычный web- и mail-сервер, кто-то не может представить свою жизнь без какой-то хитроумной конфигурации Kerberos, кто-то в Leap видит исключительно desktop-систему и захочет посмотреть на сколько стабильна в ней работает Plasma 5.12 LTS. Я, к примеру, планирую протестировать sddm c PAM, а так же freeradius сервер со своим 802.1x L3-свитчем. Также будет интересно посмотреть, получится ли обновить свой Leap до нового Leap 15.0.
Кстати, в Leap 15.0 используется новый rpm из Tumbleweed – версии 4.14.1 (с целым вагоном и маленькой тялежкой SUSE-патчей). Возможно там получится что-то найти.

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

Актуальное состояние пакетной базы Leap 15.0 можно посмотреть вот тут.
Там же есть ссылка на изменения, которые ожидают Leap 15.0.

Если у вас возникли вопросы, я всегда буду рад помочь вам. Оставляйте комментарии или просто пишите на alexander_naumov @openSUSE.org. Меня так же можно найти на freenode IRC-сервере. Мой ник там – anaumov. Удачи!


Posted in Events, GNU/Linux, openSUSE by anaumov on 08.02.2018

The Free Open Source Developers European Meeting (FOSDEM) 2018 happened over the weekend. FOSDEM is a fantastic conference where Free Software enthusiasts from all over Europe can meet together at once a year (more than 17000 MAC addresses were registered this time). I really like its clearly unique atmosphere. As usual, 2 amazing days in Brussels, Belgium…

The reason why I visit it again and again. It charges you. When you see all these developers, visit these talks/presentations, have so many conversation with contributors, get innovation ideas that are shared there. It motivates you to get a copy of The Linux Programming Interface & TCP/IP Guide and hack away your amazing Linux software 🙂
Most of the talks were recorded. That’s nice, but by watching it online you just get information, by visiting these talks in person and taking part in discussions, you get much much more.

This time I was there together with my LiMux colleagues from Landeshauptstadt München. By the way, as you maybe know, we’re going to share as much as we can until Munich migrates to Windows (unfortunately, because of bureaucratic reasons making software freely (share it) sometimes is not so easy as we want).

Like in last year FOSDEM was held in so-called “developer rooms”. First I planned to visit devrooms such as debugging tools, DNS/DNSSEC and security + encryption. That was my target when I planned my program. But as I noticed later I was not the only one who had the same plans to visit the same talks, hacking sessions and open discussions 🙂 That led to the free-places-problem in the devrooms and it made my program a bit more dynamic than I planned first 🙂 But get it right – that was absolutely no problem for me. Outside we also had very interesting conversations. I met ex-colleges, friends whom I knew from mailing lists and IRC only and of course a lot of openSUSE contributers.

I would like to thank FOSDEM’s staff, everyone who made it happen, who helped to organize it (I’m definitely going to send a feedback to you guys). Thanks GitHub for free coffee. Keep it going 🙂 I also have to say thanks for openSUSE’s Travel Support Program. It supports me to visit this amazing event (and not for the first time!). I’m going to visit FOSDEM again next year. My photos can be found here. See you next time 😉

Good idea %)

Posted in security by anaumov on 26.01.2018

pam-accesscontrol: PAM-based access control system written in python

Posted in python, Qt, security by anaumov on 27.12.2017

In traditional UNIX/Linux authentication there is not much granularity available in limiting a user’s ability to login. For example, how would you limit the number of users from a specific group? What if you want to allow some users to log in from a specific host, but disallow all others from a same host? Firewall can not help at this point. What if you want to allow SSH for someone, but not X- or login sessions on tty? And… what if you want to be able to decide about allowing SSH-session for someone at the same moment when connection will be established?

PAM, or pluggable authentication modules, allows for you just this sort of functionality (and more) without the need to patch all your services. PAM is flexible enough to provide solution for all of the above listed issues. All what you need at this point is just implement a new PAM-plugin for your needs.

Some times ago I came across pam_python — a PAM module that lets you write PAM modules in python. During paying with pam-python I implemented my own plugin as a hobby. At the beginning that was just notification window about every new incoming SSH connection. After that I added possibility to allow or denied every new established SSH connection by asking the owner of the X session (that was implemented just for desktop users in mind, of course). Next – define the list of users who may to login any time, who should wait for confirmation and who should never get the shell on my machine. I came on idea to put these lists to the config file. Project grew quickly. Now I would like to introduce it, show the sources and invite everyone (who love coding) to take a part of the development 😉


I called it pam-accesscontrol. Before we start I would like to remind you, that it was implemented as a hobby project just for fun and it’s still unstable, i.e. can broke something on your system. “Someting” is, for example, possibility to login via tty/login(1), SSH or display manager . So, you can just look at the source code or, if you really know what you’re doing, install the package.

To be able to understand how PAM and pam-accesscontrol communicate with other, take a look at doc-page where you can find the list of pam-python methods which are nothing other then a interface for Linux PAM APIs. Every PAM event like open_session, close_session, authenticate, etc. will call appropriate pam-python method. This method will call appropriate pam-accesscontrol function.
For example, OpenSSH: by using password authentication procedure PAM calls pam_authenticate function, which call pam-python’s pam_sm_authenticate function. You just need to implement pam_sm_authenticate-method in your plugin to intercept further steps in the authentication process. Pam-python is just a “bridge” between PAM and pam-accesscontrol:

As you can see, we also should tell PAM (add configuration to files in /etc/pam.d/ directory) to call plugin in some necessary cases. Necessary cases are services like, for example, sshd or login (depend on our wishes) and events like auth, session, etc.

List of all available PAM modules can be found in /lib/$(arch)-linux-gnu/security/ directory. After installiing pam-python package pam-python.so file should be there and after installing pam-accesscontrol package — accesscontrol.py script.


PAM-accesscontrol’s behavior depend on its config file. You add rules for /etc/pam.d/* services like sddm or login. It’s similar to iptables rules: by an authenticate new user or creating new session, pam-accesscontrol will read config file, parse it and try to make a decision. Actually, pam-accessconfig is nothing else then just a parser. It’s possible to close access for everybody and specify in what case and for whem it will be open, or vice versa — just define who should have no access. At the end, decision has made by pam-accesscontrol will be returned to PAM.

Right after package installing it has just one rule in its config file: DEFAULT:OPEN, i.e. access open for everyone. If this DEFAULT variable will be not set in config file, pam-accesscontrol initialize it with CLOSE value.

Let me show some configuration examples.

> cat /etc/pam-accesscontrol/pam-accesscontrol.conf

sshd OPEN GROUP lp,users
sddm OPEN USER bob,alice
login OPEN USER bob,alice

First line of this configuration closes access for all users. After that we open SSH (password authentication) for all users from lp and users groups (it supports LDAP groups, POSIX groups and primary user groups); open access via sddm for users bob and alice; open access via login for users bob and alice. Pretty easy. Every rule should have exactly 4 fields. If rule is broken, it will be just ignored.

It’s possible to set limit for number of users from specific group.

sshd NUMBER GROUP users:2,lp:3

For example, this line sets limit to 2 for group users and to 3 for group lp. In other words, new SSH connection will be possible for users from group lp, if only 2 or less users will be logged on this system at the same time.

It’s also possible to configure it so that it will ask you for every new incoming connection. With this line in config file everyone from group lp will wait for your confirmation:

sshd-key ask group operation

It means, access will be granted via SSH by using public-key authentication only for someone from group operation… only if X-session owner allow it.

It calls QMessageBox from PyQt5 that returns 0 or 1 to pam-accesscontrol depend on your choice. This value will be interpreted as allow or not allow. By the way, if there is no active Xorg session, pam-accesscontrol will not be able to ask you… so in this case this will be interpreted as an OPEN rule. Also keep in mind that pam-accesscontrol ask owner of the Xorg session only for the first SSH incoming connection. Remote user would like, for example, to copy 100 files on its host; in that case also just one confirmation at the begging will be needed.


X-session owner also will be informed when remote user (whose SSH session was confirmed through QMessageBox) ends its SSH session.


Pam-accesscontrol uses syslog. It creates logs after every successful authentication. As usual, on systemd-based systems you can use journalctl(1). Also some logs can be found in /var/log/auth.log (authentication phase) and /var/log/syslog files. By default, there is not so much information. For debugging and during development it’s a good idea to enable debug/verbose mode. Add debug:true to the config file and it will put much more info about why it made this or that decision.
It also creates its own logfile /var/log/pam-accesscontrol-YEAR-MON.log where is stored short statistic about when, who, via which interface tried to login and also — was it successful or not.

Use ldd(1) to check PAM compatibility for supported interfaces:

# ldd $(which sshd) | grep pam
        libpam.so.0 => /lib64/libpam.so.0 (0x00007f82cdfff000)
# ldd $(which login) | grep pam
        libpam.so.0 => /lib64/libpam.so.0 (0x00007fee7f3c9000)
        libpam_misc.so.0 => /lib64/libpam_misc.so.0 (0x00007fee7f1c5000)