Обновление до версии Debian 6.0

One rather old laptop and one server were the test objects for this howto. Both systems do not have any RAID devices and use a simple partition scheme from a default basic Lenny install. If your setup deviates much from this, it’s highly recommended to read all details of the Debian Release Notes before you continue. Be warned. All commands are run as root and Debian recommends to use apt-get for the Squeeze upgrade process.

As with all upgrades, begin with a backup of your critical data, and that will be the users data in /home/your-users but I would also back up the content of all configurations files. The latter can quickly be archived:

tar -czvf host.etc.tar.gz /etc

Move your files for safe storage on a backup drive.

Edit your Apt source list file

To prepare for the installer, we need to get to a point where the package system is in a clean state. Move the preferences file from the directory if used. If you have a very complicated Debian source file, I would recommend that this is simplified to near the original install.

Open up a command line editor and reduce /etc/apt/source.list to something similar to only:

deb http://ftp.se.debian.org/debian/ lenny main contrib non-free
deb-src http://ftp.se.debian.org/debian/ lenny main contrib non-free
deb http://security.debian.org/ lenny/updates main
deb-src http://security.debian.org/ lenny/updates main
deb http://volatile.debian.org/debian-volatile lenny/volatile main
deb-src http://volatile.debian.org/debian-volatile lenny/volatile main

Naturally your country code is likely to be different from mine se.

Update the packages for Lenny
With a few commands we will make sure that the existing package system is in good shape before the system is upgraded to Squeeze.

apt-get update

Ready for first upgrade:

apt-get upgrade

Follow this with:

apt-get dist-upgrade

Check that no packages are on hold or in any half installed state

The system usually contains many many packages, and before the real upgrade stage we must fix such problem packages.

Ensure that we do not have any packages on hold with:

dpkg --audit
dpkg --get-selections | grep hold

No packages can be on hold.

For the final go ahead test use:

aptitude

Press g and the list shows which packages need your attention. Fix any packages in the action list, until the message says:

No packages are scheduled to be installed, removed or upgraded

Only then you are done and ready to pass this point.

Update the source list for Squeeze
Update once more the /etc/apt/sources.list:

deb http://ftp.se.debian.org/debian/ squeeze main contrib non-free
deb-src http://ftp.se.debian.org/debian/ squeeze main contrib non-free
deb http://security.debian.org/ squeeze/updates main
deb-src http://security.debian.org/ squeeze/updates main

and at the command line type:

apt-get update

Squeeze upgrade in two careful steps

It’s recommenced to use a two stage upgrade approach with kernel, udev and the preparation for grub2. After the first completed the full distribution upgrade is performed. Start with the upgrade like so:

apt-get upgrade

Now to the kernel; we need to find your flavor, i.e. the exact version numbers and architecture and install it with:

uname -r
apt-get install linux-image-2.6.26-2-amd64

If the system is old like my laptop it would install with:

apt-get install linux-image-2.6.26-2-686

Prepare grub2 and udev for the new system:

update-grub
apt-get install udev

Если есть проблемы с установкой драйверов сетевой карты, смотреть здесь:

http://linux.koolsolutions.com/2009/05/11/tip-debian-linux-kernel-firmware-issues-ethernet-drivers-missing/

Once previous steps have completed, it’s time to restart the system:

reboot

Almost there

When the system has restarted, continue with the full upgrade phase:

apt-get dist-upgrade

Starting the system with the first menu item shows if grub2 works properly, if so run:

upgrade-from-grub-legacy

which will install grub2 in the Master Boot Record (MBR) on the disk.

Further information are found on Debian main site.

О порядке ввоза в Россию шифровальных (криптографических) средств

Положение к п.2.19 о порядке ввоза на таможенную территорию таможенного союза и вывоза с таможенной территории таможенного союза шифровальных (криптографических) средств

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

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

3. К шифровальным средствам относятся:

а) средства шифрования – аппаратные, программные и аппаратно-программные средства, системы и комплексы, реализующие алгоритмы криптографического преобразования информации и предназначенные для защиты информации от несанкционированного доступа при ее передаче по каналам связи и (или) при ее обработке и хранении;

б) средства имитозащиты – аппаратные, программные и аппаратно-программные средства, системы и комплексы, реализующие алгоритмы криптографического преобразования информации и предназначенные для защиты от навязывания ложной информации;

в) средства электронной цифровой подписи – аппаратные, программные и аппаратно-программные средства, обеспечивающие на основе криптографических преобразований реализацию хотя бы одной из следующих функций: создание электронной цифровой подписи с использованием закрытого ключа электронной цифровой подписи, подтверждение с использованием открытого ключа электронной цифровой подписи подлинности электронной цифровой подписи, создание закрытых и открытых ключей электронной цифровой подписи;

г) средства кодирования – средства, реализующие алгоритмы криптографического преобразования информации с выполнением части преобразования путем ручных операций или с использованием автоматизированных средств на основе таких операций;

д) средства изготовления ключевых документов (независимо от вида носителя ключевой информации);

е) ключевые документы (независимо от вида носителя ключевой информации);

ж) системы, оборудование и компоненты, разработанные или модифицированные для выполнения криптоаналитических функций;

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

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

Примечание. Нормативно-техническая, конструкторская и эксплуатационная документация к шифровальным средствам, указанным в подпунктах “а” – “и” настоящего пункта, считается составной частью этих средств.

4. Положение распространяется на лиц, осуществляющих ввоз и вывоз шифровальных средств (далее – заявители).

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

6. Для получения лицензии заявитель представляет в уполномоченный орган документы, предусмотренные пунктом 3 статьи 3 Соглашения, а также:

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

приложение к заявлению о получении лицензии с указанием полного наименования всех шифровальных средств в случае ввоза или вывоза нескольких видов шифровальных средств, соответствующих одному 10-значному классификационному коду в соответствии с ЕТН ВЭД.

7. Для получения заключения в соответствии с пунктом 6 настоящего Положения заявитель представляет в согласующий орган:

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

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

8. Не требуется получения лицензий:

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

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

9. Для получения заключения (разрешительного документа) заявитель представляет в согласующий орган:

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

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

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

10. В выдаче лицензии (заключения согласующего органа) помимо оснований, указанных в пункте 6 статьи 3 Соглашения, может быть отказано в случаях:

  • непредоставления документов в объеме, предусмотренном пунктами 6, 7 и 9 настоящего Положения;
  • наличия ограничений в третьих странах на ввоз шифровальных средств на их таможенную территорию;
  • возможности нанесения ущерба безопасности государствам — участникам таможенного союза, которая определяется по результатам научно-технической экспертизы шифровальных средств и (или) документации на них.

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

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

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

Форма нотификации приведена в приложении 2 настоящего Положения.

Срок регистрации нотификации и опубликования информации о ней в единой базе таможенного союза сети “Интернет” не должен превышать 10 дней со дня поступления нотификации на регистрацию.

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

13. Уполномоченный орган вправе выдавать разъяснения (заключения) по вопросам выдачи лицензий. Информация о выданных разъяснениях (заключениях) направляется в Комиссию таможенного союза.
Приложение 1

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

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

  • симметричный криптографический алгоритм, использующий криптографический ключ длиной, не превышающей 56 бит; или
  • асимметричный криптографический алгоритм, основанный на любом из следующих методов:

а) на разложении на множители целых чисел, размер которых не превышает 512 бит;

б) на вычислении дискретных логарифмов в мультипликативной группе конечного поля размера, не превышающего 512 бит; или

в) на дискретном логарифме в группе, отличного от поименованного в вышеприведенном подпункте “б” размера, не превышающего 112 бит.

Примечание.

1. Биты четности не включаются в длину ключа.

2. Термин “криптография” не относится к фиксированным методам сжатия или кодирования данных.

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

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

б) электронной цифровой подписи.

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

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

4. Персональные смарт-карты (интеллектуальные карты):

а) криптографические возможности которых ограничены использованием в оборудовании или системах, указанных в пунктах 5 – 8 настоящего перечня; или

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

Примечание.        Если интеллектуальная карта может выполнять несколько функций, то контрольный статус каждой из функций определяется отдельно.

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

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

а) программное обеспечение исполнено в защищенном от копирования виде;

б) доступом к любому из следующего:

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

в) контролем копирования аудио- и видеоинформации, защищенной авторскими правами.

7. Шифровальное (криптографическое) оборудование, специально разработанное и ограниченное применением для банковских или финансовых операций.

Примечание.        Финансовые операции включают сборы и оплату за
транспортные услуги и кредитование.

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

9. Беспроводное радиоэлектронное оборудование, осуществляющее шифрование информации только в радиоканале с максимальной дальностью беспроводного действия без усиления и ретрансляции менее 400 м в соответствии с техническими условиями производителя.

10. Шифровальные (криптографические) средства, используемые для защиты технологических каналов информационно-телекоммуникационных систем и сетей связи.

11. Товары, у которых криптографическая функция заблокирована производителем.

____________
Приложение 2

Форма нотификации

Зарегистрирована в реестре “____” _____________ 20___г.            № 

М.П.           

(подпись лица  уполномоченного органа)                                                                                                          (Ф.И.О.)

—————————————————————————————————————-

НОТИФИКАЦИЯ

о характеристиках товара (продукции),
содержащей шифровальные (криптографические) средства

1. Наименование товара (продукции)  

2. Назначение товара (продукции)  

3. Реквизиты производителя товара (продукции)  

4. Используемые криптографические алгоритмы:                                                                   № категории товара

из приложения 1

а) 

б) 

в) _

5. Наличие у товара (продукции) функциональных возможностей, не описанных в предоставляемой пользователю эксплуатационной документации

6. Срок действия нотификации  до “___” _______________ 20___г.

7. Реквизиты заявителя  

8. Реквизиты документа производителя (изготовителя), предоставившего уполномоченному лицу полномочия

по оформлению нотификации (при необходимости)  

9. Дата принятия нотификации  “___” _______________ 20___г.

М.П.           

(подпись заявителя)                                                                                                                           (Ф.И.О.)

Примечание: допускается использования оборота бланка.

____________

Asterisk + iLBC

Since Asterisk 1.4.19 (and also 1.6), the iLbc codec was removed due to licensing problems (It is not licensed for distribution). To enable it again, it is necessary to download its source code and tell to Asterisk to compile with it.

To do it manually, the instructions says:

run the contrib/scripts/get_ilbc_source.sh
run ‘make menuselect‘ and check the codec_iLBC option under Codec Translators.
compile/install Asterisk as usual
When using PADS you will need to modify the package/asterisk/asterisk.mk file to add the get_ilbc_souce.sh script in a way that it will be executed before the configure script. In addition, it is necessary to modify the get_ilbc_souce.sh to use the right path to download the iLbc source code.

You can look for the following code in asterisk.mk file:

$(ASTERISK_DIR)/.configured: $(ASTERISK_DIR)/.asterisk_unpacked $(ASTERISK_DIR)/.sounds_unpacked
cd $(ASTERISK_DIR); ./configure $(ASTERISK_CONFIGURE_OPTS)
touch $(ASTERISK_DIR)/.configured

Then you can add the following commands just before the configure call:

$(ASTERISK_DIR)/.configured: $(ASTERISK_DIR)/.asterisk_unpacked $(ASTERISK_DIR)/.sounds_unpacked
sed -i “s|codecs/ilbc|build_warp/asterisk/codecs/ilbc|” $(ASTERISK_DIR)/contrib/scripts/get_ilbc_source.sh
$(ASTERISK_DIR)/contrib/scripts/get_ilbc_source.sh
cd $(ASTERISK_DIR); ./configure $(ASTERISK_CONFIGURE_OPTS)
touch $(ASTERISK_DIR)/.configured

Note: The italic code above is all in a single line

Before compiling Asterisk again using PADS, you’ll need to enable the Asterisk menuconfig. To do this, you need to run the PADS ‘make menuconfig’ and check the Asterisk Custom Settings. This will open the Asterisk menu allowing you to set the iLBC codec as explained above.

When everything is done, a simple way to check if the codec was properly installed is to use the asterisk console command core “show translation”. It will show you a table like that with the iLbc code in:

g723 gsm ulaw alaw g726aal2 adpcm slin lpc10 g729 speex ilbc g726 g722
g723 — — — — — — — — — — — — —
gsm — — 6 6 12 6 5 28 — — 132 11 —
ulaw — 13 — 1 8 2 1 24 — — 128 7 —
alaw — 13 1 — 8 2 1 24 — — 128 7 —
g726aal2 — 17 6 6 — 6 5 28 — — 132 1 —
adpcm — 13 2 2 8 — 1 24 — — 128 7 —
slin — 12 1 1 7 1 — 23 — — 127 6 —
lpc10 — 27 16 16 22 16 15 — — — 142 21 —
g729 — — — — — — — — — — — — —
speex — — — — — — — — — — — — —
ilbc — 37 26 26 32 26 25 48 — — — 31 —
g722 — — — — — — — — — — — — —

marek comment:

As you can see from the large numbers in ‘core show translation’ for iLBC, iLBC can be quite CPU-intensive. This ultimately means that only a handful of ports using iLBC will run on appliance.

iptables and kernel :) (for beginners)

To quote the iptables homepage

iptables is the userspace command line program used to configure the Linux 2.4.x and 2.6.x IPv4 packet filtering ruleset. It is targeted towards system administrators.

In order to run iptables on the WARP, there are two things required. It must be enabled in the kernel and you need the user space libraries from www.netfilter.org. Both of these things must be completed to get it to run.

iptables – kernel portion

IP Tables is available in our kernel. You can enable it through the ‘Target Architecture Configuration (Custom Kernel Options)’ option in the main page of menuconfig. To invoke the ‘custom kernel’ selection menu when you run ‘make’ here is a little trick.

1) go to the /build_warp/linux
2) do a ‘ls- al’ —> you should see a ‘.configured’ file – please remove this file
3) run ‘make menuconfig’ from your main PADS checkout directory > select the second item ‘Target Arch Configuration (Custom Kernel Options)’ from the menu. Select ‘Custom Kernel Options’ from the next menu. Save this configuration.
4) Upon your next ‘make’ you should be presented with a new menu (’custom kernel’) where you can select which kernel modules you would like to add.
Of interest to you will be:
> Linux Kernel Configuration
-> Networking
–> Networking Options
—> Network packet filtering framework (Netfilter)
—-> IP: Netfilter Configuration

You will also see there is many other available kernel options available however I would recommend being selective as each of this options has the potential to have undesirable consequences.

iptables – user mode

The package for the user mode libraries is available from the PIKA extra_packages SVN repository here. In order to compile this, just check it out into your packages directory in PADS and do a make iptables in the root of your PADS directory. There are sometimes issues with this cross compiled version not accepting all commands. If you run into this issue, you can try the precompiled version below.

iptables – binary – user mode

The package for the pre-compiled version of the user mode libraries is available from the PIKA extra_packages SVN repository here. In order to install this, just check it out into your packages directory in PADS and do a make iptables-binary in the root of your PADS directory.

If you need assistance with configuring iptables, I suggest you read the man pages that come with it.

——

Here is the kernel configuration suggested to me by a colleague of mine as a starting point (thanks Sean). It provides routing and firewall capabilities. Instead of selecting options through ‘menuconfig > Linux Kernel Configuration’ you can also simply modify the ‘/package/linux/linux-config’ file in PADS and rebuild.
CONFIG_NETFILTER=y
CONFIG_NETFILTER_ADVANCED=y
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_NF_DEFRAG_IPV4=m
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_NF_NAT_FTP=m
CONFIG_IP_NF_MANGLE=m

Защищаем сервер Asterisk с помощью fail2ban

Итак, пришло время поговорить о защите. На написание поста меня сподвигла атака из США жестким брутом. Дело было так, я зашел на сервер оптимизировать конфиг users.conf(Об этом в следующей статье). После правки файла, я благополучно зашел в консоль Asterisk и увидел кучу сообщений (примерно 5 раз в секунду) о том, что с такого-то IP попытка зайти под пользователем 104. Меня это сначала смутило. А потом я решил поставить fail2ban, чтобы обезопасить себя. Итак, статья в моем стиле — поэтому никакой лишней инфы не будет, только то что нужно чтобы закрыть доступ для атакующего IP. Защищать будем Asterisk, ну и бонусом SSH.

Шаг 1. Установка fail2ban.

apt-get install fail2ban

Шаг 2. Установка python и iptables. Возможно вам понадобиться установить эти пакеты, поэтому

apt-get install iptables python

Шаг 3. Конфигурация fail2ban. Итак, займемся конфигурацией. Для этого перейдем в каталог /etc/fail2ban/filter.d.

cd /etc/fail2ban/filter.d

Создаем новый фильтр:

touch asterisk.conf

Содержимое файла /etc/fail2ban/filter.d/asterisk.conf должно быть примерно таким:

# Fail2Ban configuration file
# $Revision: 250 $
[INCLUDES]
# Read common prefixes. If any customizations available -- read them from
# common.local
#before = common.conf
[Definition]
#_daemon = asterisk
# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P\S+)
# Values:  TEXT
failregex = NOTICE.* .*: Registration from '.*' failed for '' - Wrong password
NOTICE.* .*: Registration from '.*' failed for '' - No matching peer found
NOTICE.* .*: Registration from '.*' failed for '' - Username/auth name mismatch
NOTICE.* .*: Registration from '.*' failed for '' - Device does not match ACL
NOTICE.* failed to authenticate as '.*'$
NOTICE.* .*: No registration for peer '.*' \(from \)
NOTICE.* .*: Host failed MD5 authentication for '.*' (.*)
NOTICE.* .*: Failed to authenticate user .*@.*
# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
ignoreregex =

Шаг 4. Редактируем /etc/fail2ban/jail.conf. В конец файла добавляем следующее содержимое:

[asterisk-iptables]
enabled  = true
filter   = asterisk
action   = iptables-allports[name=ASTERISK, protocol=all]
sendmail-whois[name=ASTERISK, dest=root, sender=fail2ban@example.org]
logpath  = /var/log/asterisk/messages #(Тут внимательно! Посмотрите где у вас логи храняться!)
maxretry = 5
bantime = 259200

Шаг 5. Логирование Asterisk. Открываем /etc/asterisk/logger.conf и раскомментируем:

[general]
dateformat=%F %T

В консоли перегружаем сервис логирования:

asterisk -rx "logger reload"

Шаг 6. Запуск.

/etc/init.d/iptables start

Проверим:

iptables -L -v

Должно появиться что то типа этого:

 iptables -L -v

Chain INPUT (policy ACCEPT 20100 packets, 3866K bytes)
pkts bytes target     prot opt in     out     source               destination
62  5692 fail2ban-ssh  tcp  --  any    any     anywhere             anywhere            multiport dports ssh
2049  471K fail2ban-ASTERISK  all  --  any    any     anywhere             anywhere

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 18948 packets, 5246K bytes)
pkts bytes target     prot opt in     out     source               destination

Chain fail2ban-ASTERISK (1 references)
pkts bytes target     prot opt in     out     source               destination
2049  471K RETURN     all  --  any    any     anywhere             anywhere

Chain fail2ban-ssh (1 references)
pkts bytes target     prot opt in     out     source               destination
62  5692 RETURN     all  --  any    any     anywhere             anywhere

Шаг 7. Автозапуск fail2ban и iptables:

update-rc.d iptables defaults
update-rc.d fail2ban defaults

http://www.fail2ban.org/wiki/index.php/Asterisk

http://www.voip-info.org/wiki/view/Fail2Ban+%28with+iptables%29+And+Asterisk

Force iptables to log messages to a different log file

According to man page:
Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. Several different tables may be defined. Each table contains a number of built-in chains and may also contain user defined chains.

By default, Iptables log message to a /var/log/messages file. However you can change this location. I will show you how to create a new logfile called /var/log/iptables.log. Changing or using a new file allows you to create better statistics and/or allows you to analyze the attacks.

Iptables default log file

For example, if you type the following command, it will display current iptables log from /var/log/messages file:
# tail -f /var/log/messages
Output:

Oct  4 00:44:28 debian gconfd (vivek-4435): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2
Oct  4 01:14:19 debian kernel: IN=ra0 OUT= MAC=00:17:9a:0a:f6:44:00:08:5c:00:00:01:08:00 SRC=200.142.84.36 DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=18374 DF PROTO=TCP SPT=46040 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Oct  4 00:13:55 debian kernel: IN=ra0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:18:de:55:0a:56:08:00 SRC=192.168.1.30 DST=192.168.1.255LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=13461 PROTO=UDP SPT=137 DPT=137 LEN=58

Procedure to log the iptables messages to a different log file

Open your /etc/syslog.conf file:
# vi /etc/syslog.conf
Append following line
kern.warning /var/log/iptables.log
Save and close the file.

Restart the syslogd (Debian / Ubuntu Linux):# /etc/init.d/sysklogd restartOn the other hand, use following command to restart syslogd under Red Hat/Cent OS/Fedora Core Linux:# /etc/init.d/syslog restart

Now make sure you pass the log-level 4 option with log-prefix to iptables. For example:
# DROP everything and Log it
iptables -A INPUT -j LOG --log-level 4
iptables -A INPUT -j DROP

For example, drop and log all connections from IP address 64.55.11.2 to your /var/log/iptables.log file:
iptables -A INPUT -s 64.55.11.2 -m limit --limit 5/m --limit-burst 7 -j LOG --log-prefix '** HACKERS **'--log-level 4
iptables -A INPUT -s 64.55.11.2 -j DROP

Where,

  • —log-level 4: Level of logging. The level # 4 is for warning.
  • —log-prefix ‘*** TEXT ***’: Prefix log messages with the specified prefix (TEXT); up to 29 letters long, and useful for distinguishing messages in the logs.

You can now see all iptables message logged to /var/log/iptables.log file:
# tail -f /var/log/iptables.log

Updated for accuracy.

Запуск нескольких сайтов с различными SLA

От переводчика (А.К.): SLA (от англ. Service Level Agreement) означает «Соглашение об Уровне Обслуживания» — основной документ, регламентирующий взаимоотношения между ИТ-компанией и заказчиком.

Сделать это можно несколькими способами. Прежде всего следует упомянуть, что Apache поддерживает подобную функциональность в виде модулей, но мы продемонстрируем как добиться этого средствами операционной системы. Эти строки взяты из примера, представленного Джамалом Хади (Jamal Hadi).

Допустим, что у нас есть два клиента, которые арендуют некоторую долю нашего канала под http, ftp и потоковое audio. Первый клиент арендует полосу в 2 Мбита, второй — 5 Мбит. Для начала назначим нашим клиентам виртуальные IP-адреса на нашем сервере:

# ip address add 188.177.166.1 dev eth0
# ip address add 188.177.166.2 dev eth0

Решение проблемы о том, как назначить правильные IP-адреса различным службам, оставляем за вами. Практически все популярные демоны поддерживают такую возможность.
Присоединяем CBQ qdisc к eth0:

# tc qdisc add dev eth0 root handle 1: cbq bandwidth 10Mbit cell 8 avpkt 1000 \
mpu 64

Создаем классы клиентов:

# tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 10Mbit rate \
2MBit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21
# tc class add dev eth0 parent 1:0 classid 1:2 cbq bandwidth 10Mbit rate \
5Mbit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21

И добавляем фильтры к классам:

##FIXME: Для чего нужна первая строка, что она делает? Каково назначение "делителя" (divisor)?:
##FIXME: Делитель имеет отношение к хеш-таблице и номеру пула
## (bucket) - ahu
# tc filter add dev eth0 parent 1:0 protocol ip prio 5 handle 1: u32 divisor 1
# tc filter add dev eth0 parent 1:0 prio 5 u32 match ip src 188.177.166.1
flowid 1:1
# tc filter add dev eth0 parent 1:0 prio 5 u32 match ip src 188.177.166.2
flowid 1:2

FIXME: Почему нет token bucket filter?

Прозрачное проксирование с помощью netfilter, iproute2, ipchains и squid

Этот раздел написал Рэм Нарул (Ram Narula), из «Internet for Education» (Таиланд).

Прозрачное проксирование — это обычное перенаправление серверу squid трафика, отправляемого на порт 80 (web).

Существует 3 общеизвестных способа такого перенаправления:

Шлюз.
Вы можете настроить шлюз таким образом, что он будет перенапрвлять все пакеты, адресованные на порт 80, сереверу squid

НО

Это увеличит нагрузку на шлюз. Кроме того, некоторые коммерческие роутеры не поддерживают такую возможность.

Layer 4 switch
Свичи выполняют такое перенаправление без особых проблем.

НО

Стоимость этого оборудования очень высока и может быть сопоставима с ценой связки «обычный роутер» + «Linux-сервер»

Использовать кэш-сервер в качестве шлюза.
Вы можете отправить ВЕСЬ трафик через кэш-сервер.

НО

Это довольно рисковано, поскольку squid довольно значительно нагружает CPU, что может привести к снижению производительности сети. Кроме того, squid может «рухнуть» и тогда никто из сети не сможет выйти в Интернет.

Мы предлагаем 4-й вариант:
Linux+NetFilter.
Эта методика предполагает установку меток на пакеты, с портом назначения равным числу 80, и дальнейшая маршрутизация помеченных пакетов, с помощью iproute2, на squid.

|—————-|
| Реализация |
|—————-|

Используемые адреса
10.0.0.1 naret (NetFilter)
10.0.0.2 silom (Squid)
10.0.0.3 donmuang (Router, соединенный с Интернет)
10.0.0.4 kaosarn (некий сервер в сети)
10.0.0.5 RAS
10.0.0.0/24 main network
10.0.0.0/19 total network

|—————|
|Структура сети |
|—————|

Internet
|
donmuang
|
————hub/switch———-
| | | |
naret silom kaosarn RAS etc.

Прежде всего — весь трафик должен идти через naret, для этого на всех компьютерах пропишем его в качестве шлюза по-умолчанию. Исключение составляет silom, для которого шлюз по-умолчанию — donmuang (в противном случае web-трафик зациклится).
(на всех компьютерах в моей сети был прописан шлюз по-умолчанию — 10.0.0.1, который ранее принадлежал donmuang, поэтому я изменил IP-адрес у donmuang на 10.0.0.3, а серверу naret присвоил адрес 10.0.0.1)

Silom
——
-настройка squid и ipchains

Настройте прокси-сервер squid на silom. Убедитесь, что он поддерживает прозрачное проксирование. Обычно прокси-серверу, для приема запросов от пользователей, назначают порт 3128, поэтому весь трафик, отправляемый на порт 80 будет перенаправлен на порт 3128. С помощью ipchains это делают следующие правила:
silom# ipchains -N allow1
silom# ipchains -A allow1 -p TCP -s 10.0.0.0/19 -d 0/0 80 -j REDIRECT 3128
silom# ipchains -I input -j allow1

iptables:
silom# iptables -t nat -A PREROUTING -i eth0 -p tcp —dport 80 -j REDIRECT —to-port 3128

За информацией по настройке сервера squid, обращайтесь на http://squid.nlanr.net/.
Убедитесь, что на этом сервере разрешен форвардинг, и заданный по умолчанию шлюз для него — donmuang (НЕ naret!).

Naret
——
-настройка iptables и iproute2
-запрет ICMP-сообщений о перенаправлении (если необходимо)

Пометить пакеты, с портом назначения 80, числовой меткой 2.

naret# iptables -A PREROUTING -i eth0 -t mangle -p tcp —dport 80 \
-j MARK —set-mark 2

Настроить маршрутизацию так, чтобы помеченные пакеты отправлялись на silom

naret# echo 202 www.out >> /etc/iproute2/rt_tables
naret# ip rule add fwmark 2 table www.out
naret# ip route add default via 10.0.0.2 dev eth0 table www.out
naret# ip route flush cache

Если donmuang и naret находятся в одной подсети, то naret не должен выдавать ICMP-сообщения о перенаправлении. Запрет можно наложить так:
naret# echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects

На этом настройку можно считать завершенной. Проверим конфигурацию

Для naret:

naret# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK tcp — anywhere anywhere tcp dpt:www MARK set 0x2

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

naret# ip rule ls
0: from all lookup local
32765: from all fwmark 2 lookup www.out
32766: from all lookup main
32767: from all lookup default

naret# ip route list table www.out
default via 203.114.224.8 dev eth0

naret# ip route
10.0.0.1 dev eth0 scope link
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1
127.0.0.0/8 dev lo scope link
default via 10.0.0.3 dev eth0

|——-|
|-КОНЕЦ-|
|——-|

15.5.1. Схема движения пакетов после настройки.

|——————————————|
| Схема движения пакетов |
|——————————————|

ИНТЕРНЕТ
/\
||
\/
———————donmuang————————
/\ /\ ||
|| || ||
|| \/ ||
naret silom ||
*destination port 80 ================>(cache) ||
/\ || ||
|| \/ \/
\\===================================kaosarn, RAS, и пр.

Обратите внимание, в данном случае сеть получилась асимметричной, т.е. добавился один лишний переход для исходящих пакетов.
Ниже приводится путь, проделываемый пакетами в/из Интернет для компьютера kaosarn.

Для web/http трафика:

kaosarn http request->naret->silom->donmuang->internet
http replies from Internet->donmuang->silom->kaosarn

Для прочего трафика:
kaosarn outgoing data->naret->donmuang->internet
incoming data from Internet->donmuang->kaosarn

http://docstore.mik.ua/manuals/ru/LARTC/x2540.html

Решение проблемы с Path MTU Discovery путем настройки MTU/MSS

Общеизвестно, что скорость передачи данных возрастает с увеличением размера пакета. Это вполне естественно, ведь для каждого пакета в потоке принимается решение о выборе маршрута. К примеру, файл, размером в 1 мегабайт, будет передан быстрее, если он будет разбит на 700 пакетов (при максимальном размере пакета), а не на 4000.

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

Процесс поиска такого размера называется ‘Path MTU Discovery’ (Поиск Максимального Размера Пакета для выбранного Пути), где MTU означает ‘Maximum Transfer Unit’ (Максимальный Размер Блока передачи данных).

Когда на маршрутизатор поступает пакет, который не может быть передан по выбранному маршруту целиком (без фрагментации) И у него установлен флаг «Don’t Fragment» (Не фрагментировать), то в ответ отправляется ICMP-сообщение о том, что пакет был сброшен из-за невозможности «протолкнуть» его по выбранному маршруту. Компьютер, выполнивший посылку, начинает последовательно уменьшать размер пакетов до тех пор, пока они не смогут быть переданы по выбранному маршруту.

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

В результате таких действий процесс поиска оптимального размера пакета работает все хуже и хуже, а на некоторых маршрутизаторах вообще не работает, что в свою очередь порождает сеансы TCP/IP с весьма странным поведением, которые «умирают» спустя некоторое время.

Хотя у меня нет никаких доказательств, но я знаю по крайней мере два сайта, с которыми наблюдается подобная проблема и перед обоими стоит Alteon Acedirectors — возможно кто-то имеет более богатый опыт и сможет подсказать как и почему это происходит.

15.6.1. Решение

Если вы столкнетесь с подобной проблемой, то можно посоветовать отключить ‘Path MTU Discovery’ и установить MTU вручную. Koos van den Hout пишет:

У меня возникла следующая проблема: для арендованного мною канала, работающего через ppp, на скорости 33.6К, я установил величину MTU/MRU, равную 296. Это дает мне достаточно приемлемое время отклика.

Со моей стороны установлен роутер (с маскарадингом), работающий под управлением Linux.

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

После этого возникла масса проблем с авторизацией в irc. В процессе длительных поисков я установил, что само соединение проходит и даже показывается системой как ‘connected’, но я не получал motd от irc (motd — от англ. Message of The Day, которое демонстрируется после успешной авторизации, прим. перев.). Кроме того, помятуя о проблеме, связанной с MTU, я определил, что проблема исчезала только в том случае, когда MTU устанавливался равным 296. А так как серверы irc блокируют весь трафик, который напрямую не связан с их работой, то в числе блокируемых оказался и ICMP.

Мне удалось убедить администратора WEB-сервера в истинных причинах возникновения проблем, но администратор IRC-сервера отказался устранять их.

Таким образом, передо мной встала необходимость уменьшить MTU для внешнего трафика и оставить нормальное значение для локального.

Решение:

ip route add default via 10.0.0.1 mtu 296

(10.0.0.1 — шлюз по-умолчанию, внутренний адрес маршрутизатора с маскарадингом)
Вообще, можно запретить ‘PMTU Discovery’ путем настройки специфических маршрутов. Например, если проблемы наблюдаются только с определенной подсетью, то это должно помочь:

ip route add 195.96.96.0/24 via 10.0.0.1 mtu 1000

Как уже говорилось выше, Path MTU Discovery не работает в Интернет должным образом. Если вам известны факты существования сегментов в вашей сети, где размер MTU ограничен, то вы уже не можете полагаться на безотказную работу Path MTU Discovery.

Однако, помимо MTU, есть еще один способ ограничения размера пакета — это, так называемый MSS (Maximum Segment Size — Максимальный Размер Сегмента). MSS — это поле в заголовке TCP-пакета SYN.

С недавних пор, ядра Linux и некоторые драйверы PPPoE, стали поддерживать такую особенность, как ‘clamp the MSS’ (ограничение размера MSS).

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

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

Чтобы иметь возможность манипулировать размером сегмента, у вас должны быть установлены iptables, не ниже 1.2.1a и ядро Linux, не ниже 2.4.3. Основная команда iptables:

# iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Она рассчитает правильный MSS для вашего соединения. Если вы достаточно уверены в себе и в своих знаниях, можете попробовать нечто подобное:

# iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 128

Это правило устанавливает MSS равным 128. Очень полезно, если вы наблюдаете разрывы при передаче голосовых данных, когда поток небольших пакетов VoIP прерывается «огромными» http-пакетами.

Ограничение скорости для отдельного хоста или подсети

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

Эти три строки сделают все что вам нужно:

tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit

tc class add dev $DEV parent 1: classid 1:1 cbq rate 512kbit \
allot 1500 prio 5 bounded isolated

tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
match ip dst 195.96.96.97 flowid 1:1

Первая строка — назначает базовую дисциплину на заданный интерфейс и сообщает ядру, что пропускная способность интерфейса составляет 10 Мбит/сек. Если вы установите неверное значение, то особого вреда не будет, однако, всегда стремитесь устанавливать верные значения, это повысит точность вычислений.

Вторая строка создает класс с полосой пропускания 512 Кбит/сек. Подробное описание CBQ содержит раздел Дисциплины обработки очередей для управления пропускной способностью.

Последняя строка говорит о том, какой трафик должен формироваться классом, определенным выше. Трафик, не подпадающий под заданное в фильтре условие, НЕ ОГРАНИЧИВАЕТСЯ! Более сложные примеры назначения условий (подсети, порт отправителя, порт адресата), вы найдете в разделе Наиболее употребимые способы фильтрации.

Если вы внесли какие-либо изменения в сценарий и желаете перезапустить его — предварительно запустите команду tc qdisc del dev $DEV root, чтобы очистить существующую конфигурацию.

Сценарий может быть немного улучшен, за счет добавления в конец дополнительной строки tc qdisc add dev $DEV parent 1:1 sfq perturb 10. За подробным описанием обращайтесь к разделу Stochastic Fairness Queueing.