VirtualBox 7.6.2 on Windows issue after update

I’ve now run into the same VirtualBox issue twice, so it’s clearly worth documenting.

The pattern is always the same:

1. VirtualBox receives an update.

2. I install it on Windows.

3. During installation, a couple of minor issues appear (driver warnings, permission prompts, etc.), but those are usually resolved by re-running the installer or starting VirtualBox as Administrator.

4. VirtualBox and the Extension Pack install successfully.

5. Existing Linux guest VMs refuse to start.

The last time, the error looked like this:

“VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MachineWrap, interface IMachine”

Googling (and LLM-ing) this error is mostly useless. The advice is vague, repetitive, and usually boils down to “reinstall VirtualBox” or “check permissions”. Rolling back VirtualBox to the previous version didn’t help either.

The actual root cause

What finally cracked the case was noticing the state of the VM before the update.

Before installing the update, my guest VM was in an Aborted state. It had frozen at some point, and I killed it instead of shutting it down cleanly. Without restarting the VM, I went ahead and updated VirtualBox.

In that situation, VirtualBox creates and keeps a file here:

C:\Users\<USER>\.VirtualBox\VirtualBox.xml-prev

After the update, this file prevents the new VirtualBox version from starting the VM at all.

Deleting that file immediately fixed the issue. The VM started normally again.

One more file to watch out for

In addition, I also found a file with a .pre extension in the VM directory:

C:\Users\<USER>\VirtualBox VMs\<VM NAME>\<VM NAME>\

I deleted this file as well. I’m not 100% certain whether it must be removed to fix the problem, because I deleted it first and it didn’t help on its own. Only after removing VirtualBox.xml-prev did everything start working.

Still, it’s worth checking and cleaning up both.

Takeaway

If you update VirtualBox on Windows and suddenly your existing VM refuses to start:

• Check whether the VM was in Aborted state before the update

• Delete:

  • C:\Users\<USER>\.VirtualBox\VirtualBox.xml-prev

  • Any suspicious .pre files in the VM directory

• Then start VirtualBox again

This is one of those issues where everything looks broken, error messages are meaningless, and the fix turns out to be deleting a single leftover state file.

I have a lot of respect for the guys behind VirtualBox.
But honestly… God damn.

Wordpress: 500 internal Server error на заглавной странице

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

Столкнулся с тем ошибкой "500 internal server error" при открытии одного из сайтов под управлением Wordpress. Открытие других страниц по прямым ссылкам происходит нормально, а home page дает эту ошибку.
/var/log/apache2/error.log содержит записи "PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted". Все посты на эту тему указывают на то, что нужно увеличить объем доступной PHP памяти. Но у меня ему и так выделено 128MB. На других сайтах на том же хосте все нормально в этом плане.
Полез посмотреть базу сайта. Оказалось, что активная тема в одном из своих PHP-скриптов содержит строку:
add_custom_field('Bannerimage', 1)
, которая выполняется при каждом обращении к базе постов. Это привело к созданию более 44 тысяч записей в таблице wp_postmeta и, соответственно, заполнению всей выделенной памяти.
Судя по всему это какой-то дебажный код, попавший в релизную сборку темы. Строчку удалил, все такие записи из этой таблицы вычистил, сайт проверил. Домашняя страница стала открываться нормально.

---

Just faced "500 internal server error" error while opening front page of one of Wordpress powered sites. Other pages including admin dashboard are opened successfully by direct links. File /var/log/apache2/error.log contains lines like "PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted". All internet posts point that the reason is low memory accessible to PHP. Although it is already configured 128MB for PHP. Furthermore, other sites on same host work well.
Decided to discover site' database. And figured out that wp_postmeta table contains more than 44K records which contain Bannerimage value. Short search through sources revealed that active theme contains in one of PHP files line like:
add_custom_field('Bannerimage', 1)
, which executed every referencing to posts table. Sequentially all memory was grabbed while reading the table.
Seems it some debug code was left in release build. I've removed the code line, deleted all such records from the table, checked site. Home page now is opened well.

Пакетный whois для проверки нескольких зон

Пульнул свой скриптик для проверки скопом доступности вебдомена в нескольких зонах на гитхаб: https://github.com/RettPop/wwhois. You are welcome.

MacOS: установка pkg-файлов из командной строки

Установка pkg-файла из клиандной строки:

 sudo installer -pkg filename.pkg -target /

Пуск/остановка Jenkins под Mac OS X

Две команды для старта и остановки демона Jenkins (continuous integration tool) под Mac OS X. Запуск Jenkins:

sudo launchctl load /Library/LaunchDaemons/org.jenkins-ci.plist

Остановка Jenkins:

sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist

Однострочники: Быстрое криптование файлов в *x-системах

Напоминалка. Быстрое (рас)криптование файла из командной строки в системах, с установленным пакетом OpenSSL (практически все *x-системы).

#криптование
openssl enc -in <input_file_name> -out <output_file_name> -blowfish

#раскриптование
openssl enc -d -in <input_file_name> -out <output_file_name> -blowfish 

Для Mac OS, в частности Yosemite:

#криптование
openssl <cyphername, i.e. bf> -in <input_file_name> -out <output_file_name>

#раскриптование
openssl <cyphername, i.e. bf> -d -in <input_file_name> -out <output_file_name>

Чистка ноута Compaq nx6125

Мой старый ноут Compaq nx6125 служит мне уже лет 5. А вообще отроду ему уж 7-й год. Служит долго, исправно. Очередное подтверждение того, что технику Хьюллеты делать умеют. Описывать его смысла нет. Во-первых, он уже староват, и навряд ли кто-то будет себе такой покупать. Во-вторых, это ноут бизнес-класса (по состоянию на 2005 год), поэтому обзоров и описаний - до утра. Хотя бы на том же IXBT. Мой ноут сейчас стоит на кухне. Подруга пользует его. Сериалы, веб и т.д. С недавних пор он начал очень сильно тормозить. Борьба с софтварными настройками к заметным улучшениям не привела. Решил его разобрать и пропылесосить. Ибо шуметь он с самого включения стал аки паровоз, и греться, аки Везувий. Вдохновился этим роликом, вооружился отверткой-шестигранником, простым мелким крестом (для крышки отсека жесткого диска) и плоской (чтобы поддеть кожухи шарниров экрана). Отвинтил, открыл, пропылесосил, собрал, включил. Сначала даже ушам не поверил - так тихо стал работать :). И скорость работы сразу вернулась к эталонной. На операцию ушло около 20 минут. Еще один спасенный друг (сколько на нем работы сделано - страшно вспомнить!). Сентиментален я как-то к полезной технике.

SVN + Apache + Nginx. Ошибка коммита изображений

После переезда на новый хостинг столкнулся с тем, что SVN не хочет коммитить файлы изображений (jpg, png, etc). Выдает примерно такие ошибки:

Adding  (bin)  icon57x57.jpg
svn: Commit failed (details follow):
svn: Server sent unexpected return value (405 Not Allowed) in response to PROPFIND request for '/svn/!svn/wrk/6ec81701-d224-4232-851b-23f6d87b9e06/Bzzzer2/icon57x57.jpg'
svn: Server sent unexpected return value (405 Not Allowed) in response to PROPFIND request for '/svn/Bzzzer2/icon57x57.jpg'

Оказалось, что на сервере установлен Nginx, который и мешает загрузке картинок на сервер. Остальные файлы он игнорирует, ибо они не относятся к вебу - проекты Objective-C и C++. Для исправления этого положения нужно внести директорию репозитория в список игнорируемых Nginx-ом путей. Делается это в разделе

location ~* ^/(awstats/|webmail/|phpmyadmin/|server-status/|backups/|svn/) {^M
                        proxy_pass http://80.91.191.246:8080;^M
                        proxy_redirect http://sapisoft.com:8080/ /;^M
                        proxy_set_header Host $host;^M
                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;^M
                        proxy_set_header X-Real-IP $remote_addr;^M
                }^M

соответствующего файла конфигурации соответствующего хоста, например /etc/nginx/vhosts/yourhost.com.cfg

*x. svn + vimdiff = тру!

Небольшое описание настройки SVN с тем, чтобы дефолтным менеджером сравнения использовался трушный vimdiff (специальный режим работы vim). У SVN есть команда diff, которая сравнивает указанный файл с его предыдущими ревизиями - по умолчанию с предыдущей. И, опять-таки по умолчанию, она выводит список различий в довольно таки неудобочитаемом формате. Для использования внешнего менеджера различий нужно указать в командной строке модификатор --diff-cmd <команда запуска менеджера>, либо прописать <команда запуска менеджера> в файле ~/.subversion/config в параметре diff-cmd. Но не все так просто. SVN в дополнение к именам файлов передает менеджеру еще 5 параметров. При брутальном указании vimdiff он начинает ругаться на несуществующие файлы и отсутствующие команды. Для обхода этого используем unix-way - скрипты. Итаг:

1. создаем следующий файл bash-скрипта:

#!/bin/sh

# Configure your favorite diff program here.
VIMDIFFCMD="/usr/bin/vimdiff"

# Subversion provides the paths we need as the sixth and seventh
# parameters.
LEFT=${6}
RIGHT=${7}

# Call the diff command (change the following line to make sense for your merge program).
$VIMDIFFCMD "$LEFT" "$RIGHT"

называем его как-то типа svndiff.sh, устанавливаем права доступа для выполнения

chmod +x svndiff.sh

и кладем где-то в $PATH - можно в домашней директории, можно в /usr/local/bin - куда руки дотянутся.

2.  Далее в файле ~/.subversion/config добавляем/заменяем строку:

diff-cmd = svndiff.sh

Ну и в принципе все. Делаем

svn diff <filename>

и пользуемся правильными инструментами.

Mac OS. Смена IP-адреса и других свойств принтера

В Mac OS интуитивно сделано только добавление принтера. Как ни странно. Замена IP-адреса и других свойств принтеров делается только через их удаление. Но можно обойтись и Unix-way :). Достаточно отредактировать любимым vim файлик /etc/cups/printers.conf.

Linux. Однострочники

Сделать что-то с файлами в текущей директории:

for f in *; do {do_any_command_with_} $f; {do_one_more_command_with_} $f; {do_one_extra_command_with_} $f; done

И вариант с циклом по конечной последовательности индексов:

for ((i=1;i<=10;++i)); do echo $i; done

Тормоза Windows по причине Hardware Interrupts

Намедни начались у меня на домашнем ноуте в винде дикие тормоза. Основные симптомы - дергание мыши, звука, загрузка системы в течение минут 10. Process Explorer показал, что виртуальный процесс Interrupts отжирает до 90% процессорного времени. Началась борьба с драйверами, устройствами, ошибками на диске, антивирусами... Ничего не помогло.
Причина оказалась проста. Контроллер жесткого диска с какой-то радости переключился в режим PIO вместо DMA. Вылечилось удалением устройства Primary IDE Channel и последующей перезагрузкой системы для обновления драйвера.
Хто бы знал?!

PS: На скриншоте - уже исправленный режим работы драйвера.

Copypast: Плюс 100 к защите: Круговая оборона Linux десктопа

Копипаст статьи "Плюс 100 к защите: Круговая оборона Linux десктопа" с сайта Xakep.ru.Fdnjh - Евгений Зобнин. Ничего супернового, но как напоминалка - хорошая статейка. Имхо.

Плюс 100 к защите: Круговая оборона Linux десктопа Открытые UNIX-системы всегда славились своей безопасностью. Постоянный аудит кода, молниеносные выходы багфиксов, хорошо продуманная политика разграничения прав доступа – все это сделало их очень привлекательным продуктом, которому можно доверить хранение даже самой конфиденциальной информации. Но значит ли это, что мы можем полностью положиться на разработчиков и не должны «допиливать» свою систему самостоятельно? Нет, каждый случай установки ОС уникален и требует подкручивания винтиков. Безопасность машины – понятие весьма многогранное, для разных людей оно может иметь совершенно разные значения. В рамках одной статьи мы не сможем охватить их все, поэтому давай сразу определимся с тем, что и от кого будем защищать: Человек – существо общественно-зависимое. В любой сфере жизни нас окружают люди. Дом, место учебы, работа – везде и всегда мы находимся в обществе других людей, не все из них чисты на руку, бескорыстны и холодны к чужим секретам. Поэтому первая линия обороны – это, конечно же, обеспечение защиты от физического доступа к машине во время нашего отсутствия. Интернет полон придурков, кул-хацкеров и просто любопытных людей. Никто из нас не хочет подвергнуться взлому со стороны одного из них (или всех сразу). Поэтому вторая линия обороны – это защита сетевых рубежей от вторжения. Взломав машину, те самые придурки, кул-хацкеры и просто любопытные люди захотят получить доступ к нашим важным данным, включая пароли, сертификаты, кукисы и архивы баз данных, которые мы стащили, взломав чужую машину. Поэтому третья линия обороны – защита конфиденциальных данных от посторонних глаз с помощью сокрытия информации или шифрования. Получив желаемое, ПКЛ (придурки, кул-хацкеры, любопытные) захотят оставить на твоей машине черный ход, который в будущем будут использовать для регулярного обновления своего архива твоими данными, а также для рассылки спама или проведения DDoS. Четвертая линия обороны – проверка системы на наличие руткитов и прочей дряни. Даже если ПКЛ не засунут в недра машины свой бэкдор или DOS-бота, они все равно захотят уйти в чисто английской манере, не оставив после себя не только нежного «Тебя поимели, пупсик» (хотя первые два представителя тройки это, скорее всего, сделают), но и логов и другого доказательства своей вины и контактных данных. Во избежание их безнаказанности следует использовать пятую (и окончательную) линию обороны под названием аудитинг. Это и есть пять основных рубежей, грамотно организовав защиту каждого из которых, ты сведешь вероятность быть поломанным к цифре, маячащей где-то далеко позади 0,1%. От машины руки прочь! Методы защиты от физического проникновения на твою машину весьма просты. Достаточно представить себя на месте подлеца, и все становится предельно ясно. Во-первых, мы можем просто продолжить работу с системой, потому как многие даже не удосуживаются заблокировать экран во время своего ухода. Правило первое: всегда блокируй экран (в большинстве сред ). Во-вторых, мы можем попробовать подобрать пароль, который нередко бывает равен комбинациям вроде «qwerty» или «123». Правило второе: используй сложные и надежные пароли (о том, как их придумать, читай в боковом выносе INFO). Мы можем перезагрузить компьютер и с помощью GRUB загрузить ОС в однопользовательском режиме, получив полный контроль над системой. Правило третье: установи пароль на GRUB (об этом во врезке). Увидев, что GRUB запаролен, мы можем войти в меню BIOS, установить в качестве первого загрузочного устройства CD-ROM и загрузиться с LiveCD, получив полный доступ к содержимому жесткого диска. Правило четвертое: настрой загрузку только с жесткого диска и поставь пароль на BIOS. Но это нас не остановит: мы снимем крышку с корпуса и сбросим настройки CMOS вместе с паролем, просто вынув батарейку на несколько секунд. Правило пятое: покупай корпус с замком. Увидев замок на корпусе, мы забираем весь системник с собой и разбираем его на ближайшей свалке. Правило шестое: всегда пристегивай системник к батарее с помощью цепи. Последнее правило, конечно же, шутка, но и в ней есть доля правды: эффективность защиты от физического доступа падает прямо пропорционально росту наглости взломщика. Кстати, есть еще одна рекомендация, связанная с запираемыми на замок системниками. Большинство из них имеют переднюю крышку, которая также обеспечивает некоторую защиту CD-привода, USB-разъемов и кнопок включения/сброса. Однако мы всегда можем зажать на клавиатуре для перезагрузки машины. Но комбинация не сработает, если открыть файл /etc/inittab, закомментировать строку «ca::ctrlaltdel:/sbin/shutdown -t3 -r now» и выполнить команду «/sbin/init q». Угроза извне Те, кто пролезает на машину жертвы из Сети, обычно используют несколько простых и проверенных приемов. Самое простое, что может сделать злоумышленник – просканировать твою машину на открытые порты и попытаться найти уязвимый сетевой сервис. В борьбе с такими экземплярами фауны кул-хацкеров поможет отключение ненужных демонов, своевременные обновления дистрибутива и чтение моей статьи «Огненная дуга», посвященной правильной настройке брандмауэра (см. ][ от 06.2010). Обломавшись на этом пути, хацкер может попытаться подсунуть тебе троян под видом легальной программы или использовать дыру в браузере. В этом случае все просто: ставь софт из официальных репозиториев дистрибутива, используй правильные браузеры свежей версии. Поняв безуспешность своих попыток проникновения, взломщик может попробовать провести DoS/DDoS. От хорошей распределенной атаки ты, скорее всего, не спасешься, а вот небольшую волну вполне сможешь выдержать, если будешь следовать рекомендациям, описанным в статье «Устоять любой ценой» (][ от 09.2009). Хорошей практикой в борьбе с дырами является настройка автоматического обновления ОС, благодаря которому система всегда будет оставаться в свежайшем состоянии. Такие дистрибутивы, как Ubuntu, Fedora, OpenSuSE, уже имеют в своем составе графические напоминалки, которые время от времени выскакивают из трея и сообщают об очередном обновлении. Это удобно, но быстро надоедает, гораздо эффективнее сделать так, чтобы система сама производила обновления в фоне, не отвлекая пользователя от работы. В Ubuntu это делается через графический интерфейс (System -> Administration -> Software Sources -> Updates -> Automatic updates, Install security updates without confirmation) или с помощью модификации файла /etc/apt/apt.conf.d/10periodic: $ sudo vi /etc/apt/apt.conf.d/10periodic APT::Periodic::Enable "1"; APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Download-Upgradeable-Packages "1"; APT::Periodic::AutocleanInterval "5"; APT::Periodic::Unattended-Upgrade "1"; Замечу, что это относится только к обновлениям безопасности, простой апдейт софта придется производить руками. От возможных дыр в софте также очень эффективны такие системы, как SELinux или AppArmor (уже интегрированные в Ubuntu, OpenSuSE и Fedora), которые просто не позволят уязвимому сервису выполнить код, подсунутый взломщиком (мы не раз писали о настройке популярных расширений безопасности для ОС Linux, подними архив ][). Свой личный бастион После проникновения в машину через уязвимый сервис взломщик скорее всего будет иметь очень ограниченные права и возможности (почти все сетевые сервисы в UNIX работают от какого-либо специального пользователя, не имеющего серьезных полномочий в системе), поэтому первое, что он попытается сделать – повысить свои права до root. Наша задача – приложить все силы для того, чтобы помешать ему это сделать, иначе машина окажется полностью в чужих руках. Ниже мы рассмотрим типичные приемы злоумышленников, направленные на получение root, и методы защиты от них. 1. Первым делом хацкер попытается выполнить команду su в надежде на то, что пароль root окажется пустым или настолько простым, что он сможет его подобрать. Мы обезопасим систему, просто добавив в файл /etc/pam.d/su строку «auth required pam_wheel.so» сразу после строки «auth sufficient pam_rootok.so». Теперь право использовать su будет только у пользователей, состоящих в группе wheel (естественно, ты должен себя в нее добавить). 2. Потерпев неудачу в получении прав root обычными методами, взломщик попытается залить на твою машину эксплойт, чтобы добыть права root'а через локальные дыры в безопасности. Но так как его права сильно ограничены, он сможет использовать всего несколько мест для заливки вредоносного кода: общедоступный каталог /tmp и приватный каталог взломанного сервиса (например, корневой каталог веб-сервера или FTP-сервера). Защититься довольно просто, достаточно вынести эти каталоги на отдельные разделы и подключить с опциями noexec (а для верности и nosuid,nodev). Например: /dev/sda5 /tmp ext2 nosuid,noexec,nodev 0 0 Так взломщик не сможет выполнить свой эксплойт в указанном каталоге. Но не все так просто – знающий человек запустит программу с помощью динамического линковщика и легко обойдет данное ограничение: $ /lib/ld-linux.so.2 /tmp/exploit К сожалению, в стандартном ядре Linux защиты от данного вида атак нет, но она есть в патче RSBAC (www.rsbac.org), который в любом случае рекомендуется к установке. 3. Если каким-либо образом взломщику удастся обойти проблему запуска эксплойта, он сможет направить его действие всего в две стороны: ядро ОС или программы, имеющие SUID-бит. Только эти два компонента ОС могут дать ему заветный root-доступ. Но если с ядром все ясно (уязвимость либо есть, либо ее нет), то с SUID-софтом все немного сложнее. Даже если в одной из них будет найдена уязвимость, взлома можно легко избежать, просто сняв SUID-бит с программы. Для этого получи список SUID-софта с помощью find: $ sudo find / -type f \( -perm -04000 -o \ -perm -02000 \) \-exec ls {} \; А затем лиши некоторые из программ привилегий исполнения с правами root: $ sudo chmod a-s /путь/к/бинарнику Будь осторожным – оставив без прав важные системные программы, ты можешь обрушить всю систему. Как всегда, man в помощь. 4. Один из способов проползти в систему находится в области человеческой безалаберности. Чтобы заставить прочитать свои данные какие-либо важные системные утилиты и таким образом привести их в желаемое состояние, взломщик может найти открытые для всеобщей записи файлы и вставить в них какой-либо код (например, добавить в опции сетевого сервиса возможность входа без пароля или записать в файл код, который сорвет стек утилите, прочитавшей ее). Чтобы избежать такой ситуации, достаточно найти все общедоступные файлы и снять бит записи для всех: # find /dir -xdev -type d \( -perm -0002 -a \ ! -perm -1000 \) -print 5. Потерпев фиаско в борьбе за права суперпользователя, взломщик попытается разнюхать побольше информации о системе и утащить важные данные. В первую очередь это касается данных взломанного сервиса, например, файлов, выложенных на FTP-сервер, или страниц веб-сайта. Фактически защититься от этого можно только вовремя распознав атаку и запретив все подключения с помощью файера (либо просто вытащив кабель из сетевой карты). Второе – это данные о самом сервере, маршрутизация, ближайшие машины и т.д. Обычно их тоже невозможно скрыть без нарушения работоспособности системы. Третье – личные данные пользователей. В большинстве дистрибутивов файлы, создаваемые в домашнем каталоге пользователя, остаются видимыми всем подряд (маска 022), поэтому даже не имея каких-либо серьезных прав в системе, взломщик сможет их прочитать (кроме архиважных файлов с паролями различных программ, которые при создании защищают файл от посторонних). В борьбе с этим поможет одна коротенькая строчка, записанная в файл ~/.profile: umask 077 Теперь все вновь создаваемые файлы пользователя будут защищены от посторонних глаз. Вообще, по-настоящему безопасная домашняя машина не должна иметь на своем борту никаких сетевых сервисов, кроме совсем важных и необходимых (OpenSSH, например), а если уж припрет выложить в локальную сеть свой файловый архив или сайт, воспользуйся системой виртуализации уровня ОС, такой как FreeBSD Jail или Linux VServer (обе они уже были подробно описаны на страницах журнала). Кроме сетевых сервисов не исключена возможность подцепить заразу прямо через дыру в веб-браузере или каком-нибудь pidgin. Если такое произойдет – пиши пропало. Взломщик унесет все, включая пароли, сохраненные браузером, личную переписку и всю прочую конфиденциальщину (о методах получения root в этом случае я вообще молчу, их сотни). Даже если твои пароли будут зашифрованы, никто не помешает хацкеру унести все настройки того же Firefox, положить их на свою машину и броузить интернет от твоего имени. Единственное, что можно порекомендовать для защиты от такой ситуации – хранить все конфиденциальные данные на виртуальном разделе и подключать его к системе только по мере необходимости (полное шифрование /home не спасет, потому что взломщик окажется на уже расшифрованном разделе). Хорошей идеей будет установка модуля Linux-ядра Yama (http://lkml.org/lkml/2010/6/23/25), созданного разработчиками из Canonical. Yama по умолчанию включен в дистрибутив Ubuntu и позволяет защитить систему от некоторых видов локальных атак: Атака через подстановку символьной ссылки в общедоступном каталоге. Некоторые приложения создают во время своей работы символьные ссылки, создаваемые в каталоге /tmp или /var/tmp. В некоторых ситуациях взломщик может подменить эту ссылку, заставив программу обратиться к поддельному файлу. После установки Yama следовать по ссылкам, созданным в таких каталогах, можно будет только в том случае, если UID процесса, открывающего ссылку, и UID владельца ссылки совпадают. Атака с использованием жестких ссылок. Само по себе создание жестких ссылок пользователем, не имеющим доступ к оригинальному файлу, не является проблемой, так как ссылка будет иметь те же права доступа. Однако через создание жесткой ссылки взломщик может подсунуть исходный файл другому привилегированному приложению и раскрыть содержащиеся в нем данные. Yama запрещает создание жестких ссылок пользователям, не имеющим доступа к оригинальному файлу. Атака с использованием системного вызова ptrace. По умолчанию любой процесс может выполнить отладку другого процесса с помощью ptrace, если UID отлаживаемого процесса равен UID, вызвавшего ptrace. Это может привести к тому, что при взломе одного из пользовательских приложений взломщик сможет раскрыть состояние и конфиденциальную информацию другого приложения этого пользователя. Yama разрешает использовать системный вызов ptrace только для отладки процессов-потомков. Истребляем нечисть Что ж, мы защитили систему снаружи и внутри, но как обезопасить себя в том случае, если все это не поможет, и взломщик таки проникнет в систему? Попробуем разобраться. Даже мало-мальски образованный хацкер прекрасно понимает, что через уже использованную дыру в безопасности он не сможет ходить вечно (если это уже опубликованная уязвимость, ее исправят буквально через час-два, и ты получишь заплатку в виде баг-фикс обновления, если же это неизвестная сообществу дыра, информация о ней рано или поздно всплывет), поэтому, скорее всего, он попытается установить в систему бэкдор, который позволит без всяких проблем ходить на твою машину, или бота, рассылающего спам. Бэкдоры, трояны, боты и все остальные «нелегалы» могут быть как совсем простыми, так и весьма изощренными, выполненными в виде отдельной программы/скрипта, внедренными в легальные программы или же подключенными к ядру с помощью модуля. Однако это не имеет никакого значения, потому как любой нелегал может быть отловлен через анализ системы на модификации (никакой код не может быть внедрен в ОС на любом уровне без модификации окружения исполнения). А главное, что такой анализ легко провести через заблаговременную установку специальных систем, называемых HIDS (Локальные системы обнаружения вторжений). Одна из самых популярных HIDS, доступных в UNIX-системах, носит имя Tripwire, однако в последнее время она потеряла свои позиции в пользу более открытого аналога под названием AIDE (Advanced Intrusion Detection Environment – продвинутая система обнаружения вторжений). Как и Tripwire, AIDE основана на простом предположении: если какие-то файлы в системе изменились без предупреждения – значит, произошло вторжение. На деле это выглядит еще проще: при первом запуске AIDE создает базу с контрольными суммами всех сколько-нибудь значимых для взломщика системных файлов и периодически сверяет ее состояние с актуальным состоянием системы. Если что-то изменилось, на предварительно указанный e-mail отправляется письмо с предупреждением и деталями изменения. AIDE доступна в виде прекомпилированных пакетов для любого дистрибутива и может быть установлена с помощью стандартного пакетного менеджера: $ sudo apt-get install aide Конфигурация AIDE располагается в двух конфигурационных файлах: /etc/default/aide – главный конфигурационный файл /etc/aide/aide.conf – правила Первый хранит основную конфигурацию AIDE и обычно даже не требует правки. Единственная опция, которую имеет смысл изменять, носит имя MAILTO и содержит адрес электронной почты, на который будут отправлены все отчеты об изменениях в файлах (по умолчанию – root). Второй хранит список правил, на основании которых ведется анализ состояния системы (права доступа, контрольные суммы и т.д.) В нем же задано место хранения базы данных, хранящей предыдущее согласованное состояние системы (/var/lib/aide/aide.db). Популярные дистрибутивы уже содержат список необходимых правил (которые могут быть вынесены в отдельные файлы каталога /etc/aide/aide.conf.d), поэтому мы не будем что-либо в них менять. Чтобы инициализировать новую базу AIDE, воспользуемся командой aideinit: $ sudo aideinit После окончания ее работы в каталоге /var/lib/aide будет создана новая база с именем aide.db.new. Чтобы сделать ее базой согласованного состояния системы, произведем переименование: $ sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db После этого можно произвести первую проверку системы: $ sudo aide -c /etc/aide/aide.conf --check При установке AIDE помещает себя в список заданий cron, поэтому проверки будут происходить каждый день. Однако не следует полностью полагаться на систему. Если взломщик сможет модифицировать системные файлы для установки бэкдора, он также сможет модифицировать и сам AIDE, включая базы данные и бинарные файлы, поэтому лучший способ использования AIDE заключается в помещении ее на USB-флешку и ручной запуск в случае необходимости (не забыв исправить путь поиска баз данных в файле aide.conf): # cp /var/lib/aide/aide.db* /usr/bin/aide \ /etc/aide/aide.conf /etc/aide/aide.conf.d/* /media/флешка Конечно же, после каждого намеренного изменения состояния системы (установка пакетов, изменение конфигов и т.д.) базу придется пересоздавать. Такова уж расплата за гарантию безопасности. Кроме HIDS общего назначения для UNIX-систем разработано несколько утилит, специализирующихся исключительно на руткитах. Программы chkrootkit и rkhunter используют базу сигнатур для поиска и обнаружения вредоносного ПО (rkhunter также проверяет целостность исполняемых файлов, загрузочных скриптов и анализирует сетевые интерфейсы на предмет прослушиваемых портов). Обычно их используют совместно с AIDE для создания дополнительного слоя безопасности. Доступны в любом дистрибутиве. Использовать предельно просто: $ sudo chkrootkit $ sudo rkhunter --check На экране появится информация о проверяемых бинарниках, файлах доступа, проверки на известные типы руткитов и т.д. Обе программы написаны на языке shell, поэтому используют стандартные утилиты командной строки (awk, cat, grep, …) для выполнения проверок. Если ты не уверен в целостности этих утилит, помести их заведомо «чистые» версии на флешку и вызывай программы следующим образом: $ sudo chkrootkit -p /media/флешка $ sudo rkhunter --check --bindir /media/флешка Выводы При должном терпении организовать действительно прочную защиту домашней машины не так сложно. И я надеюсь, что смог это доказать, даже несмотря на то, что далеко не все из задуманного удалось поместить в статью. В частности, пришлось опустить целый раздел, посвященный аудиту происходящих в системе действий, но это настолько обширная тема, что ей лучше посвятить отдельную статью, и я надеюсь, что в одном из ближайших номеров она будет опубликована. Пароль на GRUB Для установки пароля на GRUB необходимо сделать две вещи: Запустить команду /sbin/grub и набрать в ее интерактивной оболочке команду md5crypt. После этого программа запросит пароль и выведет на экран его md5-хеш. Открыть файл /boot/grub/grub.conf и добавить в него опцию «password --md5 хеш-пароля». Tiger – анализатор локальной безопасности Tiger – это пакет, состоящий из коллекции shell-скриптов, бинарных файлов и файлов данных, используемый для поиска проблем безопасности UNIX-систем. Он производит сканирование конфигурационных файлов, файловых систем, конфигурационных файлов пользователя и генерирует отчеты. В своей работе использует chkrootkit и John the ripper. Zeppoo – поиск руткитов на уровне ядра Zeppoo позволяет найти Linux руткиты, скрытые процессы и сетевые соединения, новые системные вызовы и многое другое, используя прямой доступ к памяти ядра с помощью файлов /dev/kmem и /dev/mem. Исходный код доступен на сайте проекта: http://sourceforge.net/projects/zeppoo. INFO Если с придумыванием сложных паролей туго, воспользуйся утилитой APG, которая поможет сгенерировать весьма сложный, но притом вполне читаемый пароль. Поиск suid/sgid-файлов с несколькими ссылками: $ find / -type f \( -perm -004000 -o -perm -002000 \) -links +1 -ls

Файл hosts в Windows x64

Опять наткнулся на "отсутствие" файла hosts в Windows XP x64. Полез искать этот файл через файл-менеджер. А в c:\WINDOWS\system32\Drivers\ даже директории etc нету. Начал паниковать, рыскать по директориям, под столом... Нету! Потом нажал в строке команд Unreal Commander-а
cd etc
находясь в c:\WINDOWS\system32\Drivers\ и попал в нужную директорию.
Кейс связан с 32-битностью файл-мнеджера.

Как вариант, открыть директорию etc можно через Windows Explorer.

Очередной троянец-вымогатель

"Уж сколько раз твердили миру..."

Знакомые поставили некую софтинку, которая обещала отображать кто заходил на их страницу во ВКонтакте. Софтина, естественно, ничего не отобразила. Но при заходе на популярные социалки (ВКонтакте, Мой Мир, Мой круг, etc), на странице логина стало отображаться сообщении о блокировке учетки в связи с рассылкой с нее спама. За активацию учетки спрашивали переслать 20 грн на какой-то WebMoney-кошелек.
Подозрение сразу вызвал счетчик зарегистрированных аккаунтов во ВКонтакте. На этой странице он был около 98 000 000, в то время как он уже где-то недели две перевалил за 100 000 000.

В телефонном режиме проверили с ними nslookup на vkontakte.ru, проверили файл
c:\windows\system32\drivers\etc\hosts
Вроде нормально. Потом выяснили, что рядом с этим hosts-файлом лежал еще один скрытый. Explorer его, естественно, не отображал. В нем-то и был прописан список фишинговых страниц. Как был переименован штатный файл не знаю - по телефону не видно было.

Выводов напрашивается несколько. Основные:

• Работай с правами пользователя. Никакая хрень не сможет подменить системные файлы. Ну, почти никакая. Я, по крайней мере, таких еще не встречал.


• Работаешь под админом, пользуй админские примочки. В частности, файловый менеджер, который показывает и скрытые, и системные файлы.


• Не ставь всякую хрень, которая должна делать то, чего не может быть.

Обновление Sysinternals Suite

Обновился набор от Sysinternals Sysinternals Suite. Набор архиполезных администраторских утилит от Марка Руссиновича. Рекламировать его смысла нет.
Одна из главных фич новой версии Process Explorer - индикация сетевой активности процесса.
И, не уверен, что новая фича, но я ее раньше не замечал, - отображение сервиса, исполняемого svchost.exe. При наведении мыши на этот процесс можно посмотреть что именно он выполняет. Имхо - фича полезная, ибо какая-то кака может спрятаться за svchost, а админ ее и не заметит.

Еще одна фича, которую я всегда пользую - проверка подписанности образа процесса (Options/Verify Image Signatures). В отдельном столце отображается результат сверки цифровой подписи образа процесса и записи на сайте производителя. Оч удобно вычислять произведения кустарных мастеров. Тем паче с названиями типа svshost.exe...

Таблица преобразования CIDR. Маска сети.

Таблица преобразования CIDR. Маска сети.

Наша support и опасна, и трудна...

Де-то таг :)

С заботой о гиках

Очень, знаете ли, замечательные подарки для компьютерщиков :)

MKEF (Make Empty File). Простая ReadOnly защита для флешек

Написал на досуге простую консольную утилитку MKEF, которая по заданному пути создает пустой файл заданной длины. По умолчанию файл создается в директории запуска программы и размер файла берется равным размеру свободного места на текущем диске. Основная идея работы - забить на флешке всё свободное место, чтобы при втыкании ее в зараженную машину записаться на нее у вируса не было бы возможности. При запуске без параметров программа проверяет, является ли текущий диск сменным (removable). Если нет, то запрашивается допольнительное подтверждение, чтобы избежать неприятностей с работой системы.

Usage:
mkef [-n <file name>] [-p <file path>] [-s <file size>] [-u <units>] [-a <attr>] [-h|/h|-?]
-n <file name> Имя нового файла. По умолчанию - уникальное имя вида mkfXXXXX для целевой директории.
-p <file path> Путь, по которому будет создаваться файл. По умолчанию - текущая директория.
-s <file size> Размер нового файла. По умолчанию - всё свободное пространство на целевом диске.
-u <units> Единицы задаваемого размера. Понимаются: B, K, M, G. По умолчанию - M(egabytes).
-a <attr> Атрибуты создаваемого файла. Понимаются: A, S, H, R. По умолчанию -H(idden).
-h|/? Показать справку по использованию.

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

Скорость работы утилиты сильно зависит от скорости носителя. У меня на одной флешке файл размером 2,5ГБ создавался 19 минут. На другой - 5 минут. При таких скоростях интерес в этой утилите чисто академический получается. Но, может кому-то и пригодится :). Время покажет. Возможно, со временем удастся ускорить этот процесс.

UPD 2010-05-23 14-36-46:

Удалось значительно увеличить скорость создания файла. Около 2 крат. Академичности стало меньше :).