Home › Archive for linux › Page 2

linux

Установка IPSET, TARPIT и т.д. на Squeeze

Posted on by — 1 Comment ↓

Честно скопи-пастил отсюда 🙂

# aptitude update && aptitude install module-assistant xtables-addons-source
# m-a prepare
# m-a auto-install xtables-addons-source
# depmod -a

Новые таржеты для iptables:

  • CHAOS: randomly use REJECT, DELUDE or TARPIT targets.
    This will fool network scanners by returning random results
  • DELUDE: always reply to a SYN by a SYN-ACK. This will fool TCP half-open discovery
  • DHCPADDR: replace a MAC address from and to a VMware host
  • IPMARK: mark a packet, based on its IP address
  • LOGMARK: log packet and mark to syslog
  • SYSRQ: trigger a sysreq over the network (sending a saK over the network looks like a real funny ida
  • TARPIT: try to slow down (or DoS) remote host by capturing the session and holding it for a long time, using a 0-bytes TCP window. Run that on port 25 if you have no mail server to slow down spammers 😉

Новые совпадения (matches) для iptables:
condition: match on boolean value stored in /proc/net/nf_condition/name
dhcpaddr: match the DHCP Client Host address in a DHCP message
fuzzy: match a rate limit based on a fuzzy logic controller
geoip: match a packet by its source or destination country
ipp2p: match (certain) p2p protocols
quota2: named counters
pknock: port knock
…. и другие.

У себя собрал, но запустить в работу еще руки не дошли.

mod_ruid2 и php mail() = sender verify failed

Posted on by — 2 коментарі ↓

При использовании apache + mod_ruid2 в некоторых случаях может не доставляться почта, отправленная с помощью php-шной функции mail(), не смотря на все корректно заполненные заголовки.

При попытке отправить письмо приходит “отлуп”:

Subject: Mail delivery failed: returning message to sender

This message was created automatically by mail delivery software. A message that you sent could
not be delivered to one or more of its recipients. This is a permanent error.

The following address(es) failed: remoteuser@domain.com 
SMTP error from remote mail server after 
RCPT TO:: host mx.domain.com.ua [89.1xx.xx.xx]: 550 Can't verify sender

Кто-то уже сталкивался с таким ?

Update:
Вылечилось легкой правкой конфига Exim-а

Причина проявления данного эффекта связана с тем, что вот эта директива, указанная в юзеровском httpd.conf:

    php_admin_value sendmail_path '/usr/sbin/sendmail -t -i -f user@domain.net'

полностью игнорировалась.

Фикс такой – добавляем в конфиг ексима следующее:

local_from_check = false
local_sender_retain = true
untrusted_set_sender = *

Перезапускаем и наслаждаемся отсутствием описанной выше проблемы.

Для справки.
до установки мода mod_ruid2 php скрипты работали под именем apache. В свою очередь, пользователь apache входит в trusted_users в конфигурации ексима.
Поэтому заголовок ‘Sender:’ изменялся с помощью “sendmail -t -i -f user@domain.net” вполне нормально.

После установки mod_ruid, скрипты выполняются уже от имени владельца, который не входит в trusted_users и естественно не мог сделать подмену ‘Sender:’ и ‘From:’

vsftpd: No /usr/sbin/vsftpd found running; none killed.

Posted on by — 1 Comment ↓

Итак, сервер: Debian Squeeze + ISPmanager + vsftpd.
При попытке перезапуска фтп демона пишет:

# /etc/init.d/vsftpd restart
Stopping FTP server: No /usr/sbin/vsftpd found running; none killed.

При этом init-скрипт пишет номер процесса:

# cat /var/run/vsftpd/vsftpd.pid  
4634

Но пишет неправильный PID.
По всей видимости, при установке ftp из панели ISPmanager, в конфиг /etc/vsftpd.conf была добавлена строка:

background=YES

Соответственно, в pid файл записывался некорректный пид процесса. Это древний баг, оказывается
Собственно, про это же написано и в /usr/share/doc/vsftpd/README.Debian:

The included init script uses start-stop-daemon's --background option to run
vsftpd in the background.  If you have "background=yes" in your configuration,
the wrong PID will be recorded in /var/run/vsftpd/vsftpd.pid, and the init
script may fail to restart or stop vsftpd later.  Just remove "background=yes"
from vsftpd.conf.

Т.е. комментируем или убираем вообще строку “background=yes”, после чего init-скрипт начинает нормально запускать/останавливать vsftpd

PS. Как все таки, иногда, полезно почитывать документацию 🙂

/lib/libc.so.6: version ‘GLIBC_2.11’ not found

Posted on by — 2 коментарі ↓

Попал в руки сервер Debian Lenny 5.0.7 со следующими симптомами:
не добавляются юзеры,  часть сервисов отвалилась (exim и dovecot, в частности, остальное не проверял), а при попытке что-ли установить получаем:

dpkg: /lib/libc.so.6: version `GLIBC_2.8' not found (required by dpkg)
dpkg: /lib/libc.so.6: version `GLIBC_2.11' not found (required by dpkg)
E: Sub-process /usr/bin/dpkg returned an error code (1)

Смотрим почему:

# ldd -v /usr/bin/dpkg
/usr/bin/dpkg: /lib/libc.so.6: version `GLIBC_2.8' not found (required by /usr/bin/dpkg)
/usr/bin/dpkg: /lib/libc.so.6: version `GLIBC_2.11' not found (required by /usr/bin/dpkg)
linux-vdso.so.1 => (0x00007fffeccfd000)
libc.so.6 => /lib/libc.so.6 (0x00007f4a09e8d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4a0a1e0000)

Version information:
/usr/bin/dpkg:
libc.so.6 (GLIBC_2.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.8) => not found
libc.so.6 (GLIBC_2.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.11) => not found
libc.so.6 (GLIBC_2.2.5) => /lib/libc.so.6
/lib/libc.so.6:
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

Примечательный факт: /lib/libc.so.6 был не симлинком на libc-2.7.so, а был самостоятельным файлом.
Мдааа.. ))
На всякий случай попросил клиента заказать ipkvm и liveCD, а также показать /etc/apt/source.list (Откуда в lenny libc-2.11 ??).
После увиденного я вообще удивился как оно еще жило. Были подключены репы stable и sid (жуть !), да в придачу еще и от убунты репа. Apt-Pinning , естественно не использовался.

Пришлось хаком приводить систему в чувства.
Убрал лишние репы, скачал нормальный штатный deb пакет dpkg.
Так как установить его все равно не получится, подменил файл /usr/bin/dpkg на тот который из deb-пакета.
dpkg заработал, уже лучше.

Ну а дальше пошли уже мытарства по вычистке системы от всего лишнего и чуждого для этой версии. Вот тут как раз и пригодился ipkvm.
Загрузился в rescue режиме, поднял сеть, потом chroot /dev/sda1 (диск был разбит на root и swap)
Перелинковал libc.so.6 на libc-2.7.so ну и на всякий случай переустановил libc6, а то мало ли откуда там файл вместо симлинка взялся.
После чего попытка взлететь с родного винта.

Скажу, что на этот раз повезло и система поднялась удачно.
Правда, после этого было потрачено пару часов на вычистку и переустановку пакетов.
Но в итоге, все заработало как и должно работать, клиент доволен.
Ну и я доволен, что смог помочь )

[warn] [client x.x.x.x] mod_fcgid: HTTP request length 138329 (so far) exceeds MaxRequestLen (131072)

Posted on by — 5 коментарів ↓

Установлен apache + mod_fcgi. При аплоаде файлов свыше 128к получаем 500-ю ошибку, а в логе пишется сабж.
Фикс простой. Открываем конфиг mod_fcgi и увеличиваем максимальный размер, например в 10 мб:

# nano /etc/apache2/mods-enabled/fcgid.conf

<IfModule mod_fcgid.c>
  AddHandler    fcgid-script .fcgi
  FcgidConnectTimeout 20
  MaxRequestLen 10485760
</IfModule>

после релоада апачи – все работает.

/dev/null: Permission denied

Posted on by

Попался тазик, где происходит сабж.
Клиент чудным образом выставил на /dev/null левые права:

# ls -la /dev/null
-rw-r--r-- 1 root munin 38 2010-12-23 21:01 /dev/null

Фикс простой – получаем root-овые права и чиним:

# rm /dev/null && mknod -m 0666 /dev/null c 1 3
# ls -la /dev/null
crw-rw-rw- 1 root root 1, 3 2010-12-24 01:53 /dev/null

Вот теперь правильно и все работает.

На всякий случай нужно убедиться, что udev при старте системы выставляет нужные права. В его правилах должна быть строка:

# grep null /etc/udev/rules.d/*permissions.rules 
KERNEL=="null",         MODE="0666"

Очередная лажа с ядром.

Posted on by

Итак, вот что я сегодня выкопал.
Локальная уязвимость в ядре позволяет устроить ДоС.

Проверил на ядрах центоса, дебиана. Результат везде один – отказ в обслуживани. Запущенный процесс не убивается, никак.
Помогает физический ребут 🙂

В оригинале:

Simple kernel attack using socketpair. easy, 100% reproductiblle, works under guest. no way to protect 🙁
Process become in state ‘Running’ but not killalble via kill -KILL.
eat 100% CPU, eat all available internal file descriptors in kernel

Вот так.
Найдено здесь.
фикс: использовать grsecurity или патчить ядро.

Как закрыть sshd без iptables

Posted on by — 6 коментарів ↓

Если лень возиться с iptables, то ограничить доступ к ssh (и не только) можно и без iptables.

Для этого достаточно дописать несколько строк в файлы
/etc/hosts.allow
/etc/hosts.deny

Например, открываем доступ к sshd с ip 192.168.1.12 и 192.168.250.250, а для остальных доступ к sshd будет закрыт.
Добавляем в файл /etc/hosts.allow строку, где указаны разрешенные ip:

sshd: 192.168.1.12, 192.168.250.250

А в файле /etc/hosts.deny закрываем доступ всем, кроме разрешенных:

sshd: ALL

При попытке подключения с неразрешенного хоста получим ответ:

# ssh 192.168.0.1
ssh_exchange_identification: Connection closed by remote host

А если подключаться с разрешенного, то увидим приглашение ssh.

# ssh 192.168.0.1
user@host’s password:

Вот такой простой способ 🙂
Таким же способом, например, можно разрешить/запретить коннекты с mysqld, nfs или другим сервисам.