openSUSE Build Service 1.5

Вышел новый релиз:

http://news.opensuse.org/2009/03/19/opensuse-build-service-15-announced

Проблем пока не обнаружено, в пакете obs-signd бинарик /usr/bin/sign едет без SUID-бита.

Верные права:

-rwsr-x--- 1 root obsrun 48003 Июн 25 17:25 /usr/bin/sign

Отображения jabber-статуса в web.

Еще один молодой, но перспективный бот, отображающий статус пользователя, обнаружен по адресу http://web-apps.ru/jabber-presence/. Картинку можно вставить в подпись форума, в блог, на домашнюю страницу, да много куда еще, и посетители всегда узнают о том, online ли ваш jabber аккаунт.

Работает примерно так: .

За подробностями, прошу пройти по ссылке.

ESO Midas 09FEBpl1.0

Собрано, в том числе под openSUSE 11.1 и openSUSE Factory.

http://download.opensuse.org/repositories/science/

openSUSE Build Service 1.0.0

Вышел долгожданный релиз, главное его достоинство в том, что он просто работает и просто настраивается.
Исправлены некоторые ошибки, в том числе та самая досадная со сменой паролей:
https://bugzilla.novell.com/show_bug.cgi?id=392057

Ограничение количества соединений с ssh

Используя ssh сервер, легко можно заметить, что существуют злоумышленники которые пытаются подбирать пароли к вашим аккаунтам, или просто использовать часто встречающиеся комбинации. Это создаёт проблему в виде большого количества бесполезных и более того нежелательных соединений к вашему серверу. Модуль hashlimit из пакетного фильтра iptables позволяет интеллектуально ограничить доступ, он устанавливает индивидуальные ограничения для каждой пары srcip,dstport ( как в моем примере ).

iptables -N ssh_input
iptables -A ssh_input \
    -m hashlimit \
    --hashlimit 5/m \
    --hashlimit-burst 5 \
    --hashlimit-mode srcip,dstport \
    --hashlimit-name ssh \
    --hashlimit-htable-expire 3600000 \
    -j ACCEPT
iptables -A ssh_input \
    -p tcp \
    -j REJECT --reject-with tcp-reset
iptables -A INPUT \
    -m state -m tcp \
    -p tcp --dport 22 --state NEW -j ssh_input

Рассмотрим подробнее... Последняя команда отправляет все запросы на соединение с портом 22 (ssh) в цепочку ssh_input, которая действует по следующим правилам - либо запрос подтверждается и отправляется дальше, либо обработка прерывается и отправляется ответ tcp-reset. Во втором случае подсоединение к ssh будет выглядеть так, как-будто сервер не запущен.

• --hashlimit 5/m -- подобно модулю limit, это скорость срабатываний


• --hashlimit-burst 5 -- подобно модулю limit, это максимальное количество срабатываний


• --hashlimit-mode srcip,dstport -- возможные ключевые слова srcip, dstip, srcport, dstport и любые их комбинации через запятую; hashlimit может составлять свою хэш таблицу на основе любой комбинации указанных параметров. например, при указании srcip - каждая запись будет характеризоваться адресом источника, т.е. для каждого источника будет индивидуальный лимит, независимо от других параметров. При задании например srcip,dstport - индивидуальный лимит будет для каждой пары источника и запрашиваемого им порта, т.е. с одного и того-же адреса при запросе двух разных портов на вашей машине будут разные эффекты


• --hashlimit-name ssh -- в файле /proc/net/ipt_hashlimit/ssh можно посмотреть непосредственно саму таблицу ограничений


• --hashlimit-htable-expire 3600000 -- время, которое запись будет храниться в таблице, по истечению этого времени она будет удалена, в данном примере - 1 час ( в миллисекундах )

Таким образом, в то время как ваш ssh сервер будет подвергнут flood-атаке, вы сможете беспрепятственно зайти с любой своей машины на него. В случае использования модуля limit вместо hashlimit в приведённом примере, вам бы пришлось подключаться со злоумышленником на равных условиях, т.е. из-за сработавших ограничений вы бы скорее всего не попали на сервер до окончания атаки.

Надо сказать, что --hashlimit и --hashlimit-burst в моем примере достаточно либеральны, и по накопленной статистике запросы на подключение распределяются так: треть - пропущено ( включая полезные ), две трети - отказано.

Как действуют --hashlimit и --hashlimit-burst. Легко понять на примере. Пусть у нас есть счётчик, причём каждый раз когда срабатывает правило с limit его значение увеличивается на единицу. Пусть теперь, его первоначальное значение - ноль. Далее вы пять раз соединились с ssh ( как в этом примере ) за достаточно короткое время, после этого счётчик стал равен 5. Больше значения --hashlimit-burst этот счётчик стать не может и далее правила не будут срабатывать ( в этом примере это означает что ваши запросы будут отклонены ). --hashlimit - это скорость с которой счётчик откручивается назад, например: 5/m - это значит пять раз в одну минуту значение счётчика будет уменьшено на единицу, пока не достигнет ноля. Значит, подождав 12 секунд, у вас будет ещё ровно один шанс соединиться с ssh.

Настройка списка рассылки с помощью mlmmj и postfix

http://mlmmj.mmj.dk

mlmmj -- очень простой и тривиальный менеджер списков рассылки, наверное не может сравниться с монстрами типа GNU Mailman. Но, будучи простым и тривиальным, обладает преимуществом в простоте настройки, собственно никакой настройки там и нет, открываете файл README, он помогает создать новый список, открываете TUNABLES, там написано как его сконфигурировать.

Будем считать, что Postfix уже настроен, и посылает и получает письма из внешнего мира.

Для начала, нужно изменить настройки Postfix, установив recipient_delimiter в положение '+', можно сделать либо руками в main.cf, либо командой

postconf -e 'recipient_delimiter=+'

которая изменит main.cf и перезапустит демон.

Теперь можно создать списки рассылки как указано в README. А вот дальше начинаются проблемы с правами доступа. mlmmj хранит свое имущество в /var/spool/mlmmj, соответственно mlmmj-recieve должен иметь право туда писать.

Один из возможных вариантов -- добавить нового системного пользователя и сменить права на /var/spool/mlmmj:

groupadd -r mlmmj
useradd -c "User for mlmmj" -d /var/spool/mlmmj -g mlmmj -r -s mlmmj
chown mlmmj:mlmmj /var/spool/mlmmj

Теперь нужно объяснить Postfix что делать с письмами; для этого создаем в /etc/aliases.d/mlmmj файл с нужным содержимым:

mlmmj-test: "|/usr/bin/mlmmj-recieve -L /var/spool/mlmmj/mlmmj-test/"

и делаем на него

chown mlmmj:mlmmj /etc/aliases.d/mlmmj

Это означает, что mlmmj-recieve будет запущен Postfix от имени пользователя mlmmj ( по умолчанию он запускает от nobody, или смотри man ).

Дальше делаем

setfacl -m user:mlmmj:rwx /etc/aliases.d
SuSEconfig --module postfix

Это маленький кусочек черной магии. SuSEconfig просматривая aliases.d сам сообразит, что нужно переделать базы привязок, но для создания mlmmj.db потребуются права для пользователя mlmmj на создание файлов в aliases.d, поскольку перестройка базы привязок произойдёт от имени того пользователя, которому принадлежит файл. В конце концов, в aliases.d должны оказаться два файла mlmmj и mlmmj.db, владелец которых mlmmj, а в

postconf alias_maps

скажет что-то подобное

alias_maps = hash:/etc/aliases, hash:/etc/aliases.d/mlmmj

В /etc/cron.d/mlmmj добавляем, в соответствии с инструкцией

0 */2 * * *  mlmmj /usr/bin/mlmmj-maintd -F -L /var/spool/mlmmj/mlmmj-test

IDE

Собственно, нечего добавить.



upd: ну как нечего... нарисовал сам в inkscape, названия из wikipedia, да дело то вовсе не в том