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

Вторая часть статьи об управлении трафиком в Linux. В статье приведены примеры приоретизации трафика (QoS) и рассказано об использовании hash таблиц при фильтрации трафика (fast hash tables), использование которых позволяет существенно увеличить производительность.

В этом топике расскажу как можно в пару скриптов наладить простой сбор статистики по аномальной активности в сети.

Аномальным для нас будет на момент снятия статистики:

1. Более 20 исходящих коннектов по 25 порту с 1 IP.
2. Более 100 исходящих коннектов по 80 порту с 1 IP.
3. Более 100 исходящих коннектов по 53 порту с 1 IP.
4. Придумывайте сами, всё гибко.

Статистику будем вынимать из кэша netflow маршрутизаторов. Будет ли это Cisco или FreeBSD — не важно. О настройке netflow на FreeBSD я рассказывал в предыдущих своих статьях.

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

Удивлённо поднимем брови, умиляясь тому, как гибка наша любимая операционка, засучим рукава и приступим к делу.

В данной статье рассмотрен один из вариантов шифрования данных в Linux.

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

Итак, первое:

Интернет пришел и в наш город!

Интернет провайдеры в Воронеже последние 2 года развиваются и плодятся с огромной скоростью, в связи с чем приходится менять и апгрейдить и своё клиентское интернет-оборудование. Долгое время у меня в качестве доступа к сети использовался ADSL2+ модем и недорогой Wi-Fi роутер, но мой провайдер решил начать параллельно с доступом по телефонной линии предоставлять возможность подключения и по Ethernet или как его называет Домолинк — Fttx. Вместе с этим также стала доступна бесплатная услуга Открытое ТВ, представляющая из себя ничто иное как IPTV по протоколу UDP. Всё это и подтолкнуло меня на замену простенького Level ONE WBR-3408 на что-то более функциональное. К моему удивлению оказалось, что функциональность не всегда идёт рука об руку с высокой ценой. О том, как и почему я выбрал именно Dlink dir-615 можно узнать под катом.

В этой заметке я опишу методы увеличения производительности линуксового маршрутизатора. Для меня эта тема стала актуальна, когда проходящий сетевой трафик через один линуксовый маршрутизатор стал достаточно высоким (>150 Мбит/с, > 50 Kpps). Маршрутизатор помимо роутинга еще занимается шейпированием и выступает в качестве файрволла.

OpenDPI — библиотека для классификации трафика на основе технологии глубокого анализа пакетов (DPI — Deep Packet Inspection). Проект IPP2P более не поддерживается, и, в качестве замены, предлагает использовать именно OpenDPI. В отличие от IPP2P, основной целью которого является определение именно p2p трафика, OpenDPI поддерживает широкий набор различных протоколов. OpenDPI изначально спроектирован для очень низкого уровня ложных положительных срабатываний. В отличие от L7-filter не требует наложения патчей на iptables и ядро; работает в виде модуля ядра и библиотеки xtables. Также определения протоколов представляют собой не список регэкспов, а модули на C, что повышает быстродействие. Недавно для этой библиотеки была реализована поддержка iptables.
А теперь давайте попробуем использовать OpenDPI на практике.

Написано по следам публикации Большие потоки трафика и управление прерываниями в Linux

В нашей городской сети более 30 тысяч абонентов. Суммарный объем внешних каналов — более 3 гигабит. А советы, данные в упомянутой статье, мы проходили еще несколько лет назад. Таким образом, я хочу шире раскрыть тему и поделиться с читателями своими наработками в рамках затрагиваемого вопроса.

В заметке описываются нюансы настройки/тюнинга маршрутизатора и NAT-сервера под управлением Linux, а также приведены некоторые уточнения по поводу распределения прерываний.

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

Есть программа iperf, которая позволяет проверять скорость интерфейсов (у меня на тестах из 10G интерфейса она выжимала 9.37 Гбит/с).

Пакет (в дебиане и убунте) так и называется — iperf.

Применение очень простое: на одном сервере запускаете iperf -s X.X.X.X (свой собственный адрес сервера, на котором слушать). Можно запустить просто iperf -s, тогда слушать будет на всех интерфейсах.

На клиентской части пишем iperf -c X.X.X.X (адрес сервера из предыдущего этапа). Клиент подключается, работает 10 с и показывает скорость работы канала.

Пример: сервер имеет адрес 192.0.2.1, клиент 192.0.2.200. На сервере запускаем iperf -s 192.0.2.1 на клиенте iperf -c 192.0.2.1.

Для того, чтобы сделать много байтов (привет хостерам с соотношениями) нужно просто указать опцию -t (время в секундах). Многие гигабайты трафика в нужном направлении вам обеспечены. С учётом текущих тарифов для дома — можно даже с домашней машины, за 3-4 часика можно выправить любое соотношение с минимальной нагрузкой как на сервер, так и на клиента.

Стояла задача: в цикле, из скрипта на php5 зайти по ssh на Mikrotik, сгенерировать скрипт с текущим конфигом, забрать скрипт на некое локальное хранилище. И так для ~500 роутеров. Так как в провайдерских кругах микротик весьма нередкий зверь — думаю кому-то ещё может пригодиться.

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

В процессе обнаружилось следущее:

В прошлой заметке мы рассматривали некоторые аспекты тюнинга роутера под Linux, предназначенного для работы в условиях высоких нагрузок: Linux под нагрузкой. Маршрутизатор, NAT-сервер Теперь же речь пойдет о шейперах.

Mikrotik Router OS, Ищем свой сервер в чужой сети. Или как не платить большие деньги

Все мы не раз слышали о грандиозной поддержке малого бизнеса и частного предпринимательства в нашей стране. Пока ты физическое лицо, у тебя нет никаких проблем. Но как только ты собрался с мыслями и решил открыть свое дело, ты моментально попадаешь на деньги (конские проценты в банках, налоги, отчисления в ПФР, поборы, штрафы, инфляция, и прочая вата). Особенно отличились в этом плане провайдеры, если к простому домашнему пользователю требования минимальны, то к частным предпринимателям и организациям подход особенный. А именно: если ты арендовал нежилое помещение для работы, это означает что ты дойная корова и должен платить кучу денег провайдеру. Да, конечно очень хорошо, если вам удалось договорится с провайдером и составить договор на физическое лицо, ну или скажем недалеко живет ваш знакомый который согласен поставить wifi в форточку. Но если данные варианты не прокатывают, есть еще один способ не платить провайдеру кучу денег. :)

Идея заключается в том, что в наше время не сложно найти провайдера с внутренней локальной сетью 10.0.0.0/255.0.0.0 или 192.168.0.0/255.255.0.0 и в ней организовать две точки (Физическое лицо с дешевым, безлимитным интернетом будет Сервером) (Организация с дорогим помегабайтным интернетом будет Клиентом) между ними поднимаем VPN.

Mikrotik Router OS, скрипт для динамического деления скорости (Версия 2)

Это вторая версия, первая лежит тут: тут.

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

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

В новой версии стало все значительно проще в плане расположения пользователей, теперь не имеет значения, как подключился пользователь, главное, что у него есть ip адрес и этого нам достаточно.

Mikrotik Router OS, скрипт для динамического деления скорости.

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

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

Примерно два года назад я арендовал у одного немецкого хостера не очень мощный сервер на базе Centos 5.2. На нём живут несколько вебпроектов, приносящих некоторую прибыль, и поэтому, я стараюсь присматривать за ним по мере возможности.
На Centos есть стандартный анализатор логов Logwatch, который запускается ежедневно по крону, анализирует содержимое /var/log, делает сводный отчет и присылает его по электропочте. В один прекрасный день я обнаружил в этом отчете запись:

--------------------- yum Begin ------------------------ 
 
 Packages Installed:
    lzo2 - 2.02-3.el5.rf.i386
    dnstracer - 1.8-1.2.el5.rf.i386
    openvpn - 2.0.9-1.el5.rf.i386

---------------------- yum End -------------------------

В тот момент меня она очень смутила, так как в предыдущий день на сервер я не логинился и тем более ничего не устанавливал. Первое, что пришло в голову — сервер был скомпроментирован. Себя я считал уверенным пользователем Linux, однако я растерялся. Благо в тот момент в icq был мой бывший коллега, лучший системный администратор, которого я знаю, и просто очень хороший человек.
Он помог быстро проверить систему. В результате у меня сформировалось краткое HowTo о том, как быстро проверить свой сервер на предмет взлома. Уверен, что многим Храброчитателям оно будет полезно. Предполагается, что пользователь знаком с консолью Linux/Unix.

Началось все с того, что я откопал в полке с железками USB модем huaweiE1550, купленный мной прошлым летом для организации резервного канала Интернет. Проработал он тогда недолго и за ненадобностью был убран в «закрома» до лучших времен. Первое что сделал, разлочил его для работы с МТС (так уж сложилось исторически, что я предпочитаю именно этого оператора). Изначально в голову пришла идея отправки смс с предупреждениями от Nagios, вместо почты. Бегло пробежавшись по Интернетам, наткнулся на smsd демона для отправки/приемки смс-ок из пакета smstools. После прочтения документации по этому зверю, в голову пришла идея о том, что можно принимать сообщения с нужных телефонов, с командами для сервера. Так и родилась идея «Управлять сервером посредством СМС», которая может применяться для чего угодно: перезагрузить сервер, выключить его, перезапустить демона, сбросить кеш, открыть порт на фаерволе для удаленного подключения по ssh.