Ferm — это низкоуровневая надстройка над iptables, позволяющая организовывать своего рода циклы по спискам параметров iptables. Это оказывается особенно полезно при настройке сложных правил файрвола, для написания которых с использованием одного только iptables приходится повторять до умопомрачения -t filter -A INPUT -p tcp --state NEW ..., потом делать аналогичное для -p udp, в общем кто плавал — знает.

Ferm прекрасен тем, что, сохраняя всю гибкость iptables, позволяет добиваться тех же эффектов меньшими усилиями. Так, например, разрешить новые соединения на порты ftp, ssh и http и запретить все остальное (кроме связанных), можно написать вот такой конфиг:
chain INPUT {
policy DROP;
mod state state (RELATED ESTABLISHED) ACCEPT;
proto tcp dport (http ftp ssh) ACCEPT;
}

Удивительно дело, поиск дает по запросу ferm только одну статью, которая к собственно ferm никакого отношения не имеет. То ли все уже все знают и всем очевидно, то ли наоборот. Исходя из последнего, я решил написать этот топик.

По каким-то причинам может получиться так, что нужно установить Ubuntu на компьютер, на котором установлен Windows (в данном случае это был Windows Server 2003). Почему речь именно о Windows? Под Линуксом есть и другие способы решения, есть debootstrap и chroot, а на Windows возможных вариантов для такого манёвра остаётся меньше.

Но обычный метод установки (загрузиться с LiveCD/LiveUSB, произвести установку, настроить всё, перезагрузиться снова) не всегда подходит. Почему не всегда? Потому что может быть так, что доступ к компьютеру только удалённый (в данном случае это был RDP-сервер в Windows), а физический доступ только через другого человека, и редкий (раз в сутки). Да и потом сколько бы от него потребовалось действий, если делать обычным способом — вставить флэшку/диск, загрузиться, подождать, пока предложат попробовать использовать дистрибутив, выбрать этот вариант, потом настроить удалённый доступ (в Убунте даже SSH-сервер по умолчанию не установлен — никогда, кстати, не понимал почему, но факт), и только после этого идти по своим делам. А так единственное, что потребовалось от человека — это поменять порядок загрузки с жёстких дисков в BIOS.

Кстати, теоретически, можно попробовать обойтись даже без этого, если распаковать на диск C:\ в Windows grldr из пакета grub4dos, создать там же menu.lst (где с помощью chainloader загрузиться с другого жёсткого диска), и добавить в C:\Boot.ini пункт «C:\grldr=«GRUB»», после чего выбрать этот пункт по умолчанию. Тогда достаточно просто перезагрузить компьютер, и он перезагрузится в Ubuntu, где на тот момент уже будет SSH. Только нужно не забыть добавить параметр timeout в конфигурационный файл menu.lst — иначе загрузка не будет совершена автоматически (GRUB будет ждать, пока кто-нибудь нажмёт Enter).

Помимо удалённой установки есть ещё одно важное применение этого метода — представьте, что вам нужно сократить время, которое сервер не будет функционировать с точки зрения пользователя, к минимуму. И вы можете это сделать. От того, что вы ставите Ubuntu в виртуальной машине, работа сервера не нарушится, и вы сможете, перезагрузив виртуальную машину после установки, произвести все необходимые изменения, включая создание пользователей, установку и настройку SSH, возможно веб-сервера, почтового сервера, FTP и всего остального, что может понадобиться. А потом вы просто перезагружаете компьютер. И всё то, что работало на Windows, теперь работает на Ubuntu: полторы минуты, которые компьютер будет перезагружаться, совсем не так заметны, как несколько часов, в течение которых вы бы это всё постепенно настраивали и включали.

О чём это я?

Задачи бывают разные… Бывают простые, бывают сложные, а бывают такие, на решение которых может уйти не одна неделя и достаточное количество нервных клеток. Одной из подобных задач как можно считать разворачивание чего-то серьёзного на большом количестве слабого железа. А именно…

(Здесь и далее будет говориться о немного специфичной и оптимизированной настройке LTSP и поднятии на его основе кластера серверов).

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

Дамп создан в форме doc-файла с одним вопросом на страницу. На каждый вопрос есть скриншот с вопросом на английском и переводом вопроса на русский под скриншотом. Для того, чтоб у каждого была возможность решить вопросы самому, ответы были вынесены в отдельные файлы (второй архив). Номера страниц совпадают с номерами файлов скриншотов.

Так же прилагаю набор симуляций. Все симуляции сделаны в Packet Tracer'е.

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

Итак:

Doc-файл, или отсюда

Архив скриншотов с ответами, или отсюда

Архив симуляций, или отсюда или отсюда

Список ошибок, или отсюда

А вот здесь лежит торрент со всеми 4 файлами и дополнительными материалами.

А теперь к новостям погрустней:

Введение.

Про SNORT было сказано много, но в большинстве статей речь идёт о SNORT, как о средстве тотального наблюдения за сетью, которое собирает все данные с сетевого интерфейса. В этой статье я расскажу как собрать конструкцию, в которой SNORT будет в режиме IPS следить не за всем трафиком на интерфейсе, а только за трафиком, который можно описать с помощью правил для iptables. Я не буду касаться настройки правил, речь будет исключительно о том, как на голой системе собрать SNORT для работы в режиме IPS и как подойти к защите им абстрактного сервиса. Так же будет описана сборка и запуск SNORT.

Как и у многих коллег по цеху, дома у меня построена небольшая сеть. И, конечно же, есть домашний сервер, этакий плацдарм для испытания новых технологий. С регулярной периодичностью тихими вечерами под монотонное бубнение какого-нибудь подкаста, меня посещают мысли поковырять что-то новое и интересное. Объявление провайдера об открытии услуги sip-телефонии натолкнуло меня на мысль пойти в сторону voip. Интересное и перспективное направление. Казалось бы, что тут такого – поставил софтфон, а еще лучше железный sip-шлюз и радуйся жизни. Но разве это тот путь, который мы выбрали, пойдя по пути инженера, сисадмина, программиста (нужное подчеркнуть). Гораздо интереснее будет поставить свой собственный VoIP-сервер, повесить на нем голосовую почту и пускай красивым женским голосом отвечает на звонки, когда никто не может снять трубку. Конечно выбор пал на Asterisk.

Доброго времени суток, %username%!

Рано или поздно ко всем администраторам сети приходит руководство, и просит сделать доступ к внутренним ресурсам сети компании через Интернет. Руководству, чрезвычайно приятно попивая сок, на Мальдивских берегах, мониторить прогресс решения поставленных задач в корпоративной системе управления проектами. Вот и становиться задача организации доступа.

Уважаемые скучные люди из интернета коллеги! Рад предложить вам для бета-тестирования виртуальные серверы (VDS) на базе KVM!

Как и обещал, начинаю серию статей о том, как мы делали услугу аренды выделенных серверов на базе KVM.

В этой вступительной статье я расскажу вкратце обо всех программных средствах, использованных в процессе разработки услуги. Более подробно о них будет рассказано в следующих статьях.

Продолжаем серию статей о виртуализации на базе KVM. В предыдущих статьях было рассказано об инструментарии, о настройке хост-машины и создании виртуальной машины. Сегодня мы поговорим о создании образа виртуальной машины и его клонировании.

В предыдущих сериях публикациях мы рассмотрели с вами вопросы подготовки хост-машины, создания и клонирования виртуальных машин. Сегодня я поведаю о не менее важном вопросе — об ограничении использования ресурсов виртуальными машинами.

Предыдущая статья про связку rtorrent+rutorrent+nginx+php-fpm была написана сразу после успешной установки и начальной настройки этой связки. В процессе эксплуатации выявились некоторые подводные камни, о которых я и хочу рассказать.

Работая у крупнейшего провайдера РФ столкнулся с ситуацией, что происходит обращение абонента о проблемах в недалеком прошлом, т.е. вчера все было плохо, а сейчас заработало. Что делать в этом случае? Есть варианты использовать системы мониторинга, которые будут собирать ключевые параметры всех абонентских линий и хранить их некоторое время, и оператор ТП легко сможет получить доступ к этим данным для решения подобных ситуаций. Также, имея эти данные, можно давать автоматическую экспертную оценку по каждой абонентской линии, и при желании, на xDSL, автоматически подбирать наиболее подходящий профиль. Используя эти же данные, можно выявлять дефектные линии или линии с неудовлетворительными параметрами и устранять возможные проблемы абонентов еще до их обращения в ТП.
С первого взгляда задача не сложная, но когда количество оборудование легко перешагивает тысячи узлов доступа, а количество абонентских портов может исчисляться десятками тысяч появляются некоторые особенности настройки и запуска подобной системы, с максимальной автоматизацией всего.
Если интересно, добро пожаловать под кат

Вступление

Как и было обещано в предыдущей статье, сегодня мы поговорим о базовой настройке хост-машины для работы KVM.

После того, как у нас вышли в релиз еще несколько проектов, а количество тикетов в трекере на тему «создать пользователя, развернуть виртуалку, дать доступ» превысило все мыслимые пределы, назрела необходимость что-то менять.
Задача: организовать рабочее окружение linux для нескольких команд разработчиков и тестировщиков. Общее количество виртуальных машин — три-четыре десятка.

PHP-FPM — патч к PHP, предоставляющие альтернативный интерфейс FastCGI. Обычно используется с nginx в проектах с высокими нагрузками или дефицитом ресурсов. Для удобной и упрощенной инсталляции мы собрали PHP-FPM в пакет для Debian 5 Lenny. Последнюю пару недель тестировали и тюнили, сейчас выложили в публичный доступ. Над пакетами в поте лица трудился viliar, которому дружно направляем за это благодарности и карму. Багрепорты и замечания приветствуются, лучше комментами к посту.

Инструкция по установке

Дело было вечером, делать было нечего. Написал скрипт для поиска файлов phpinfo.php. Было исследовано 36,804 сайтов Рунета, на 1,725 нашёлся файл phpinfo.php с функцией phpinfo (~4.69%).

Как видно, не все вебмастера знают простую истину – взлом сайта начинается со сбора информации о сервере.

Аналогичная проверка зарубежных сайтов показала, что наши иностранные коллеги более благоразумны: исследовано 166,652 сайтов, phpinfo.php обнаружен на 3,923 (~2,35%).

%username%, а ты удалил файл phpinfo.php (temp.php, test.php) со своего сайта?

Побочный результат исследования, статистика версий PHP

У практически любого сетевого инженера, рано или поздно наступает момент в жизни когда в его сети появляются домены маршрутизации отличные от любимого OSPF, EIGRP или IS-IS. Чаще всего это связано со слиянием двух сетей, но иногда может быть связано с модернизацией или редизайном. Одним словом, необходимость делать редистрибуцию маршрутов из одного протокола маршрутизации в другой возникает не так уж и редко. В случае с OSPF, эти маршруты появляются в таблице маршрутизации под меткой E1 (External Type 1) и E2 (Externel Type 2) маршрутов. Обычно учебные материалы Cisco говорят о том, что основное отличие этих двух маршрутов заключается в том, что при расчете метрики для Е1 маршрута используется общая метрика для всего пути, а для Е2 маршрута только стоимость редистрибуции. Попытаемся разобраться, что это значит и как это работает.

Редистрибуция маршрутов (route redistribution) – особая и горячо любимая экзаменационная тема Cisco. Свойства технологий таковы, что помимо хорошо известных нам петель маршрутизации (routing loops) в пределах одного домена/зоны существуют также петли между несколькими зонами в случае использования OSPF, а также петли между доменами в случае редистрибуции маршрутов из домена с одним протоколом маршрутизации в домен с другим.



Я не нашел определения им ни в одном стандарте, потому буду называть их inter-domain routing loops. До недавнего времени эта особенность была обязательным элементом CCIE Lab Exam, но после обновления CCNP стала частью курса Route.