Собрано, в том числе под 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
Исправлены некоторые ошибки, в том числе та самая досадная со сменой паролей:
https://bugzilla.novell.com/show_bug.cgi?id=392057
Ограничение количества соединений с ssh
Используя ssh сервер, легко можно заметить, что существуют злоумышленники которые пытаются подбирать пароли к вашим аккаунтам, или просто использовать часто встречающиеся комбинации. Это создаёт проблему в виде большого количества бесполезных и более того нежелательных соединений к вашему серверу. Модуль hashlimit из пакетного фильтра iptables позволяет интеллектуально ограничить доступ, он устанавливает индивидуальные ограничения для каждой пары srcip,dstport ( как в моем примере ).
Рассмотрим подробнее... Последняя команда отправляет все запросы на соединение с портом 22 (ssh) в цепочку ssh_input, которая действует по следующим правилам - либо запрос подтверждается и отправляется дальше, либо обработка прерывается и отправляется ответ tcp-reset. Во втором случае подсоединение к ssh будет выглядеть так, как-будто сервер не запущен.
Таким образом, в то время как ваш ssh сервер будет подвергнут flood-атаке, вы сможете беспрепятственно зайти с любой своей машины на него. В случае использования модуля limit вместо hashlimit в приведённом примере, вам бы пришлось подключаться со злоумышленником на равных условиях, т.е. из-за сработавших ограничений вы бы скорее всего не попали на сервер до окончания атаки.
Надо сказать, что --hashlimit и --hashlimit-burst в моем примере достаточно либеральны, и по накопленной статистике запросы на подключение распределяются так: треть - пропущено ( включая полезные ), две трети - отказано.
Как действуют --hashlimit и --hashlimit-burst. Легко понять на примере. Пусть у нас есть счётчик, причём каждый раз когда срабатывает правило с limit его значение увеличивается на единицу. Пусть теперь, его первоначальное значение - ноль. Далее вы пять раз соединились с ssh ( как в этом примере ) за достаточно короткое время, после этого счётчик стал равен 5. Больше значения --hashlimit-burst этот счётчик стать не может и далее правила не будут срабатывать ( в этом примере это означает что ваши запросы будут отклонены ). --hashlimit - это скорость с которой счётчик откручивается назад, например: 5/m - это значит пять раз в одну минуту значение счётчика будет уменьшено на единицу, пока не достигнет ноля. Значит, подождав 12 секунд, у вас будет ещё ровно один шанс соединиться с ssh.
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, либо командой
которая изменит main.cf и перезапустит демон.
Теперь можно создать списки рассылки как указано в README. А вот дальше начинаются проблемы с правами доступа. mlmmj хранит свое имущество в /var/spool/mlmmj, соответственно mlmmj-recieve должен иметь право туда писать.
Один из возможных вариантов -- добавить нового системного пользователя и сменить права на /var/spool/mlmmj:
Теперь нужно объяснить Postfix что делать с письмами; для этого создаем в /etc/aliases.d/mlmmj файл с нужным содержимым:
и делаем на него
Это означает, что mlmmj-recieve будет запущен Postfix от имени пользователя mlmmj ( по умолчанию он запускает от nobody, или смотри man ).
Дальше делаем
Это маленький кусочек черной магии. SuSEconfig просматривая aliases.d сам сообразит, что нужно переделать базы привязок, но для создания mlmmj.db потребуются права для пользователя mlmmj на создание файлов в aliases.d, поскольку перестройка базы привязок произойдёт от имени того пользователя, которому принадлежит файл. В конце концов, в aliases.d должны оказаться два файла mlmmj и mlmmj.db, владелец которых mlmmj, а в
скажет что-то подобное
В /etc/cron.d/mlmmj добавляем, в соответствии с инструкцией
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, да дело то вовсе не в том
upd: ну как нечего... нарисовал сам в inkscape, названия из wikipedia, да дело то вовсе не в том
Принтсервера D-Link
Тут товарищ вчера собственноручно подавил последнее сопротивление точки доступа D-Link'овской, которая как принт-сервер умеет работать. Модель конкретную не знаю, да и не важно. Кто-бы мог подумать что название очереди LPD будет lpUSB0. Меня больше другое удивило - под альтернативной ОС требовалась установка специальных программ для того чтобы заставить печатать по сети, однако альтернативная ОС умеет печатать через LPD из коробки практически, надо только установить драйвера нужные с диска, в интернете есть инструкций море с картинками.
Полезная ссылка прилагается: Gentoo HOWTO
Полезная ссылка прилагается: Gentoo HOWTO
eBOX-4300
Дали поиграть что-то типа такого компьютера.
Сделано на платформе VIA: VIA Eden 500Mhz и встроенная DDR2 512 Мб, из устройств хранения данных - разъём CompactFlash, который обнаруживается как Primary Slave IDE. Все в среднем работает, незначительный конфуз вышел только когда via82cxxx из ядра 2.6.18.2 (которое на загрузочном диске openSUSE 10.2) отказался признавать устройство IDE-контроллер 1106:5324 (оно-же VIA CX700M2). Однако, что интересно, такой-же модуль из 2.6.18.8 (которое в том же дистрибутиве, но в обновлениях) об этом устройстве знает. Смущают две вещи - температурный диапазон от 0°С, и торчащая из корпуса карта памяти, которая играет роль диска. С такими же размерами (12x12 см.) в этой же линейке есть и мощнее модели. Резюме такое: маленький, дешёвый и достаточно мощный, а самое главное тихий и потребляет не так много электричества.
Сделано на платформе VIA: VIA Eden 500Mhz и встроенная DDR2 512 Мб, из устройств хранения данных - разъём CompactFlash, который обнаруживается как Primary Slave IDE. Все в среднем работает, незначительный конфуз вышел только когда via82cxxx из ядра 2.6.18.2 (которое на загрузочном диске openSUSE 10.2) отказался признавать устройство IDE-контроллер 1106:5324 (оно-же VIA CX700M2). Однако, что интересно, такой-же модуль из 2.6.18.8 (которое в том же дистрибутиве, но в обновлениях) об этом устройстве знает. Смущают две вещи - температурный диапазон от 0°С, и торчащая из корпуса карта памяти, которая играет роль диска. С такими же размерами (12x12 см.) в этой же линейке есть и мощнее модели. Резюме такое: маленький, дешёвый и достаточно мощный, а самое главное тихий и потребляет не так много электричества.
00:00.0 Host bridge: VIA Technologies, Inc. CX700 Host Bridge (rev 03)
00:00.1 Host bridge: VIA Technologies, Inc. CX700 Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. CX700 Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. CX700 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. CX700 Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. CX700 Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:0f.0 IDE interface: VIA Technologies, Inc. Unknown device 5324
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 90)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 90)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 90)
00:11.0 ISA bridge: VIA Technologies, Inc. CX700 PCI to ISA Bridge
00:11.7 Host bridge: VIA Technologies, Inc. CX700 Internal Module Bus
00:13.0 PCI bridge: VIA Technologies, Inc. CX700 Host Bridge
01:00.0 VGA compatible controller: VIA Technologies, Inc. Unknown device 3157 (rev 03)
02:01.0 Audio device: VIA Technologies, Inc. VIA High Definition Audio Controller (rev 10)
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 13
model name : VIA Eden Processor 500MHz
stepping : 0
cpu MHz : 498.748
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx up pni est tm2 xtpr rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en
bogomips : 998.55
Подписаться на:
Сообщения (Atom)