2

Чем отличается настройка iptables в Debian от других операционных систем? Тем, что достаточно давно сложилось так, что способ загрузки правил iptables оставался на усмотрение администратора, который администрирует сервер. И хотя позже появились такие решения, как ufw, пришедший из Ubuntu, или iptables-persistent, все равно может потребоваться реализовать автоматическую загрузку таблиц самостоятельно. И есть несколько способов это сделать…

Прежде, чем рассматривать способы загрузки и сохранения таблиц, давайте разберемся, что мы можем использовать. Это три команды:

Команда iptables – это основная команда для изменения текущих таблиц, по ней можно найти много информации на просторах Интернета, поэтому пока не будем подробно рассматривать все ее возможности.

Команда iptables-save выдает на стандартный вывод действующие в данный момент правила iptables, поэтому для сохранения их в файл надо использовать перенаправление потоков:

Команда iptables-restore делает, как вы уже догадались, обратное. То есть восстанавливает правила iptables. Работает она тоже со стандартными потоками, поэтому загрузка правил будет выглядеть так:

А теперь давайте более подробно посмотрим, как же, собственно, организовать загрузку правил автоматически.

Способ 1. Простой способ.

Самый простой способ загрузки таблиц – это вызывать загрузку после поднятия основного сетевого интерфейса при помощи параметра post-up, размещенного в файле /etc/network/interfaces

Что для этого потребуется? В первую очередь нам потребуется директория, в которой будут храниться файлы с таблицами. В соответствии со стандартом FHS, это будет /etc/iptables/, в ней мы будем хранить файлы с правилами, полученными при помощи iptables-save. Перед настройкой правил сначала сбросим содержимое правил по умолчанию:

Теперь посмотрим, что у нас получилось:

У вас должны быть чистые списки правил. Это состояние желательно сохранить на случай необходимости сброса правил.

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

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

Теперь делаем еще одно действие, которое нам позволит не переписывать название файла с правилами для загрузки. Создаем символическую ссылку на файл, в который мы только что сохранили правила. Пусть это будет файл iptables-20130904-223007, тогда делаем так:

И последнее, что надо сделать – изменить файл /etc/network/interfaces, дописав одну строчку. Должно получиться примерно следующее:

И после этого сохраняем.

В общем, вот и всё. Теперь после поднятия интерфейса правила iptables будут загружены автоматически. Какие у этого способа есть минусы? Если кто-нибудь изменит файл /etc/network/interfaces, например, какая-нибудь программа-менеджер сети, то строчка с загрузкой правил может потеряться. Не факт, конечно, но вероятность есть. Второе – если у вас несколько сетевых интерфейсов, то вам надо либо вешать на событие post-up каждого интерфейса, либо точно знать, что выбранный вами интерфейс точно поднимается. Вариация этого способа – размещение скрипта загрузки правил в директории /etc/network/{if-pre-up.d|if-up.d}. В таком случае По соответствующему событию правила будут загружаться автоматически.

Способ 2. Совсем простой способ.

Еще более простой способ, которым многие пользуются – это написать шелл-скрипт загрузки правил и вызывать его из, например, /etc/rc.local или еще из какого-нибудь места при загрузке системы. Минус тут очевиден – для сохранения текущего состояния надо будет править этот самый скрипт, что не есть хорошо и удобно. Предыдущий способ в этом смысле выигрывает.

Способ 3. Самый сложный, но и самый интересный с моей точки зрения.

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

Начнем с того, что создадим наш скрипт и поместим его в директорию /etc/init.d, где у нас хранятся скрипты для других сервисов.

Далее в любом удобном вам редакторе редактируем этот файл, вписываем в него следующее:

 

Это наш шаблон скрипта сервиса, который мы с вами сейчас будем доводить до ума.

У нас уже есть обработка параметров и тела всех функций, осталось только написать внутренности этих функций. Начнем со старта, напишем содержимое функции do_start:

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

После этих действий цепочки iptables будут, но никаких запретов не будет. Следующая функция, которую мы напишем – do_list (). Ее задача – вывести список файлов с правилами. И можно сразу указать, какой из них считается файлом по умолчанию.

Теперь мы можем просмотреть список файлов с правилами и сказать, какой из этих файлов является файлом по умолчанию. Это нам необходимо для того, чтобы в дальнейшем можно было указывать, какой файл с правилами должен быть по умолчанию. Следующая функция – do_makedefault (). Ее задача – сделать некоторый файл с правилами файлом по умолчанию, чтобы он загружался автоматически при старте нашего скрипта. Поскольку файл, который у нас загружается, всегда будет иметь одно и то же название, он всегда будет просто символической ссылкой, а указывать эта ссылка будет на разные файлы. В этой функции у нас будет использоваться еще один параметр скрипта, поэтому добавим значение $2 в вызов функции в структуре case. Должно получиться так:

Итак

В самой функции этот параметр превратится в $1, потому что для скрипта он второй, а для функции – первый. Как вы видите ,мы просто удаляем символическую ссылку с названием iptables.default и делаем новую на тот файл, название которого указано. Указывать надо только имя файла, путь указывать не нужно. А флаг -f мы используем для подавления сообщения об ошибке, если такого файла не существует.

И осталась последняя функция – do_savecurrent (). Она будет тоже выполнять всего одно несложное действие – сохранять текущие правила iptables в файл с включенным в название временем сохранения этих самых правил.

Вот, собственно, сам скрипт почти закончен. Осталось сделать еще одну малость – автоматическое создание директорий, в которых будут храниться правила, если их не существует, и, если файл /etc/iptables/iptables.default не существует, то сбросим правила и политики и создадим файл iptables.clean, после чего создадим символическую ссылку на него с названием iptables.default. Для этого напишем отдельную функцию do_init ():

Эту функцию будем вызывать в самом начале скрипта, еще до выбора выполняемой команды. В итоге у нас получится следующий скрипт:

Осталось теперь включить получившийся скрипт в автозапуск:

Всё. Теперь правила будут загружаться каждый раз после загрузки, после выполнения скрипта networking. Если сеть стартовать при использовании LSBInit не будет, то правила фаервола загружаться тоже не будут. Надеюсь, этот скрипт будет вам полезен. Любые замечания в комментариях приветствуются.

Для настройки правил iptables существуют различные виды таблиц:
Mangle –для изменения заголовков пакетов
Nat – необходима для настройки трансляции сетевых адресов.
Filter – в данной таблице указываются правила для фильтрации трафика. Данная таблица задействована по умолчанию.
Continue Reading

Ситуация проста: на новый и очаровательный сервер с Ubuntu 10.04+ и современным (когда-то) PHP 5.3, пригодным для всех актуальных версий CMS, вдруг требуется подселить старый-старый сайт, начинающий сыпать ошибками при попытке запуска на PHP 5.3 (подавай ему чего-нибудь постарше, например, PHP 5.2). Кто виноват — понятно. Но что делать?

Continue Reading

В общем, понадобилась мне версия php 5.3 на новом debian 7. В репозиториях только версия 5.4. Немного гугления и решение найдено.

Для начала нужно подключить репозитории squeeze. Открываем файл /etc/apt/sources.list редактором nano или другим и добавляем туда вот это:

deb http://ftp.de.debian.org/debian/ squeeze main
deb-src http://ftp.debian.org/debian/ squeeze main

deb http://packages.dotdeb.org squeeze all
Для dotdeb.org  добавляем ключ
wget -O - http://www.dotdeb.org/dotdeb.gpg |  apt-key add -

После чего выполняем команду apt-get update.

Перед установкой необходимо удалить всё, что связано с php 5.4.

apt-get remove --purge `dpkg -l | grep php | grep -w 5.4 | awk '{print $2}' | xargs`

Далее смотрим, какая версия php 5.3.* доступна для установки:

apt-cache showpkg php5

Будет что-то вроде этого:

Provides:
5.4.35-0+deb7u2 -
5.4.4-14+deb7u14 -
5.3.29-1~dotdeb.0 -
5.3.3-7+squeeze19 -

Последняя — то, что нам нужно. Для удобства присвоим ей переменную:

VERSION="5.3.3-7+squeeze19"

Устанавливаем основные пакеты:

apt-get install php5=$VERSION php5-cli=$VERSION php5-common=$VERSION

или

apt-get install php5=5.3.3-7+squeeze19 php5-cli=5.3.3-7+squeeze19 php5-common=5.3.3-7+squeeze19

или
apt-get install -t squeeze php5

Также и с другими пакетами. Допустим, нужен модуль mysql.

apt-get install php5-mysql=$VERSION

Если php как модуль apache:

apt-get install libapache2-mod-php5=$VERSION

После установки, все пакеты нужно будет заморозить, чтобы при установке обновлений ОС php не был обновлён до последней версии 5.4. Делается это при помощи aptitude. Напечатайте aptitude hold и названия установленных пакетов:

aptitude hold php5 php5-cli php5-common

Если вдруг понадобилось разморозить эти пакеты, то hold следует заменить на unhold. Пример:

aptitude unhold php5 php5-cli php5-common

Как говориться «лень — двигатель прогресса» поэтому я покажу как можно еще работать с командной строкой bash, стандартно с помощью клавиш перемещения курсора можно перемещаться по списку ранее введенных команд. Если мне была нужна определенная команда из ранее введенных — „стрелка вверх“ и до тех пор пока нужная команда не появиться в терминале далее корректировка по надобности и выполнения ее.
Оказываеться есть еще один хороший способ — для просмотра списка ранее введенных команд в bash — имеется команда history. По умолчанию она выводит список команд хранящийся в истории.
$ history
1 sudo route del -net
2 cat /etc/resolv.conf
3 htop
......
50 nslookup
51 ping mail.ru
52 ifconfig
......
200 sudo aptitude full-upgrade
......
300 mc


По умолчанию все пишиться в файл ~/.bash_history, а его размер — 500 команд.
Если хотим хранить историю в другом файле, то нужно в .bashrc, задать команду HISTFILE=~/.my_history.
HISTSIZE — определяет число строк, хранящихся в списке истории (в памяти интерпретатора).
HISTFILESIZE — максимальное количество команд хранящихся в файле истории.
Если интересует больше записей, по можно поменять под себя:

$ export HISTSIZE=1000
$ export HISTFILESIZE=1000

При запуске команды history без параметров, выдаеться весь список сохранненных команд, что довольно громоздко, поэтому есть возможность указать
количество выводимых строк (команд):
$ history 20
280 sudo aptitude full-upgrade
281 ps ax | grep conky
282 dig @217.23.122.130 ya.ru mx
......
300 mc

Выдаст 20 последних команд, все команды имеею свой номер, с помощью которого к ней можно обратится.
Если нам надо повторить 282 команду, то просто набираем в терминале:
$ !282
dig @217.23.122.130 ya.ru mx
; <<>> DiG 9.5.0-P2 <<>> @217.23.122.130 ya.ru mx
; (1 server found)
... ......

Сначало показываеться команда соответствующая этому номеру, потом ее выполнения.
Cписок наиболее распространенных команд:

 

  • !! — ссылается на предыдущую команду;
  • !n — ссылается на команду под номером n;
  • !-n — ссылается на команду по номером „текущая минус n“;
  • history -c — очистить историю команд, удалив все записи
  • history -d n — удалить из истории запись под номером n
  • history -a — дописать команды, введенные в текущей сессии bash, в конец файла $HISTFILE

 

Дополнения:
Так же можно сохранить дату и время для каждой команды в истории, для этого в конец .bashrc дописываем:
$ nano .bashrc

export HISTTIMEFORMAT="%h/%d-%H:%M:%S"

и применяем изменений в .bashrc без перезапуска сеанса/системы делаем командой
$ bash
Получаем :
$ history 3

147 Aug/11 — 11:05:28 sudo aptitude install gspca-source
148 Aug/11 — 11:07:23 cd /lib/modules/2.6.32-22-generic/
149 Aug/11 — 11:11:08 modprobe gspca

 

Контролируйте Bash History

HISTCONTROL — представляет из себя список опций, разделенных двоеточиями.

Они контролируют каким образом список команд сохраняется в истории.

Опция Описание
ignorespace не сохранять строки начинающиеся с символа <пробел>
ignoredups не сохранять строки, совпадающие с последней выполненной командой
ignoreboth использовать обе опции 'ignorespace' и 'ignoredups'
erasedups удалять ВСЕ дубликаты команд с истории

Пример :

export HISTCONTROL=ignorespace:erasedups

Добавьте в .bashrc:

export HISTCONTROL="ignoredups"

Или даже так:

export HISTIGNORE="&:ls:[bf]g:exit"

Это заставит bash игнорировать дупликаты, так же как ls, bg, fg и exit, делая историю чище.

Забытая история bash.

Если вы открыли терминал и печатаете там команды, потом открыли еще один, немного его поиспользовали, то новый терминал не «вспомнит» ни одной команды, напечатанной в первом. Вдобавок, при закрытии первого терминала второй перезапишет все команды в истории, введённые в первом. Вдвойне досадно!

Это происходит потому, что история bash сохраняется только когда вы закрываете терминал, а не после каждой команды. Чтобы исправить такое поведение, добавьте в ~/.bashrc строки:

shopt -s histappend
PROMPT_COMMAND=`history -a`

Добавьте следующую строку, если переменная $PROMPT_COMMAND уже была задана :

PROMPT_COMMAND='$PROMPT_COMMAND; history -a'

Это заставит bash дополнять историю вместо того, чтобы перезаписывать её: каждый раз, когда показывается приглашение командной строки, последняя команда добавляется в историю.

 

Увеличиваем Размер Хранимой Истории

Увеличьте HISTSIZE — количество команд, которые необходимо запоминать в списке истории (стандартное значение — 500).

export HISTSIZE=10000

Увеличьте HISTFILESIZE — максимальное количество строк, содержащееся в файле истории (стандартное значение — 500).

export HISTFILESIZE=10000

Одна Команда — Одна Запись в Истории

Сохранять все строки многострочной команды в одной записи списка истории :

shopt -s cmdhist

Изменить Имя Файла с Историй Команд

Используйте HISTFILE для изменения имени файла, в котором сохраняется история команд. Стандартное значение ~/.bash_history.

export HISTFILE=~/.custom_file
 

Много раз наблюдал, когда системный администратор для того, чтобы узнать, сколько запросов приходит ему на nginx за секунду, сидит и выгрепывает определенную секунду из лога, после чего делает | wc -l. Не знаю, зачем так извращаться, если есть pv.
Вообще pv позволяет посчитать, сколько строчек в секунду появляется в файле (если быть занудой — то сколько строчек в секунду подается ему на STDIN). Легко предположить, что при правильном access.log’e у nginx’a количество новых строчек == количеству отправленных ответов на запросы. А при ещё более правильном — количество запрошенных страниц.
Вообще эту штуку можно натравить на любой лог, фантазируйте сами.

Для начала поставим pv:
<strong>root@debian:~# aptitude install pv</strong>
Самый простой пример:
<strong>root@debian:~# tail -f /var/log/nginx/access.log | pv -lr</strong>
Где-то там внизу у нас замелькают какие-то цифры. При желании их можно разглядеть. Плюс этой команды в том, что мы можем одновременно видеть, что происходит в логе.

Представим, что нам не нужно смотреть, что происходит в самом логе. Сделаем так:
<strong>root@debian:~# tail -f /var/log/nginx/access.log | pv -lr >/dev/null</strong>
[3.94/s ]

Всё хорошо, но такая статистика — цифры в вакууме. Значение будет скакать от нуля до пикового.
Нам нужна усредненная статистика, по количеству строк в секунду, за последние 30 секунд:
<strong>root@debian:~# tail -f /var/log/nginx/access.log | pv -lr -i 30 >/dev/null</strong>
[0.933/s ]

Первое значение появится через 30 секунд, потом каждые 30 секунд будет обновляться. Такое значение колеблется намного меньше и ему уже можно верить при озвучивании цифр.
Запустив такую штуку в скрине с -i 86400 мы получим усредненное значение за сутки.

Ну и напоследок. Вам никто не запрещает использовать grep. Например, чтобы отследить количество обращений к одной странице или количество хитов с определенного адреса.
Делать это просто:
<strong>root@debian:~# tail -f /var/log/nginx/access.log | grep 192.168.0.10 | pv -lr -i 30 >/dev/null</strong>
[0.125/s ]
Здесь мы видим, что хост 192.168.0.10 последние 30 секунд обращался к нам с частотой 0.125 запроса в секунду.

Или так:
<strong>root@debian:~# tail -f /var/log/nginx/access.log | grep ""-"" | pv -lr -i 30 >/dev/null</strong>
[137.124/s ]
137.124 запроса в секунду с пустым реферером. Имеет смысл запретить на время коннекты с пустым реферером, не правда ли?

И grep -v тоже никто не запрещает использовать:
<strong>root@debian:~# tail -f /var/log/nginx/access.log | grep -v "/index.php" | pv -lr -i 30 >/dev/null</strong>
[15.541/s ]
Здесь мы видим 15.541 запроса в секунду к страницам, кроме index.php (в т.ч. и без index.php?чтототам).

Пользуйтесь на здоровье и поменьше вам ddos’ов, по которым нужно писать отчеты.