А автор и не пользуется ifconfig-ом на мой взгляд. Автор использует штатную конфигурацию интерфейсов из дистрибутива.
Автор использует функциональные возможности скриптов автоконфигурирования рассмотренных ОС, не прибегая к каким-либо уловкам наподобие if-up и if-down. Команды «ifconfig» и «ip» применяются только для диагностики.
Разумеется, Debian поддерживает iproute2 и назначение нескольких IP-адресов на одном интерфейсе
Такой подход нарушает функционирование механизма виртуальных хостов в серверах HTTP Apache и nginx, работающих под управлением панели ISPmanager 4. В чем именно заключается проблема, я уже, честно говоря, не помню. И смысла разбираться не вижу. Четвертая версия официально более не поддерживается. Как обстоят дела в пятой, еще не проверял.
gotch, для чего необходимы виртуальные сетевые интерфейсы «eth0:X» тут уже разъяснили достаточно развернуто, с VLAN они никак не связаны. Сетевая маска 255.255.255.255 служит для того, что бы один из дополнительных адресов IPv4 не использовался системой по умолчанию для исходящих подключений. Данная тема несколько выходит за рамки заметки, подробнее об этом написано, например, вот здесь: http://serverfault.com/a/422230
Для предоставления этой конфигурации за заявленные цены у товарищей из озвученной компании, вероятно, есть свои резоны. Однако (совершенно без намерения кого-то очернять или выгораживать) поинтересуйтесь отзывами в Сети на тему тамошней поддержки. Да, вам молниеносно ответят несколько раз в течение 1-2 дней, но потом начнут оставлять без внимания запросы по неделям. Если этот уровень сервиса Вы готовы проглатывать за смешные деньги…
Хетцнер оставимте вне комментариев, пожалуй, чтобы не провоцировать срач :)
Немецкому хостеру/регистратору нерентабельно вести бизнес в США по многим причинам (даже если — это делается через соответствующую дочернюю компанию).
Преимущества немецкого регистратора / хостера в том, что за Вашими данными (сиречь, Вашим бизнесом) не придут суровые мужики в масках, не получив перед этим соответствующего постановления немецкого суда. Который, будем смотреть правде в глаза, не совсем то же самое, что, скажем, российский.
intelligence CSF в зависимости от настроек может использовать ipset или создавать по отдельному правилу iptables на каждый заблокированный адрес IP. Но это неважно. Если на вас натравят сеть ботов в ~100000 уникальных адресов, то iptables никак не справится с такой атакой, что с ipset, что без оного. Тут потребуется уже профессиональная защита от DDoS. Описанное решение способно противостоять только атакам слабой и средней мощности.
С удовольствие ознакомлюсь со статьей на тему написания собственных «regex.custom.pm» :-) Конкретно в моем случае необходимо было спешно развернуть защиту от DDoS на базе имевшихся наработок под Fail2ban. Интегрировать последний с CSF оказалось быстрее, нежели переделывать все под RegExp.
Не совсем правда, т.к. гораздо чаще это бот-сети с абсолютно разных IP адресов. Просто это не так очевидно (IP же разные).
lfd выявляет и блокирует подобного рода атаки, однако, только для поддерживаемых им сервисов. Это одна из причин, по которой я предпочел использовать Fail2ban как дополнение к CSF.
используя jail «recidive» (не очень гибкое решение, подобное вашему cron, хотя и не для подсети);
Эта методика описана в статье.
используя эту версию ban-time-incr, к сожалению уже довольно долго валяющуюся pull-реквестом (более гибкое решение, позволяющее увеличивать время бана нелинейно, хотя тоже пока не для подсети); Я как-то писал об этом на хабре.
Описанное в статье решение базируется на Fail2ban v0.8.6 из стандартного репозитория Debian Wheezy.
IPv6 уже в окончательной стадии разработки — там появится возможность определять ширину полосы (маску) подсетей (и возможно веса к ним). Подробнее можно почитать тут и тут.
Т.е. в итоге полноценной поддержки подсетей в Fail2ban пока нет. А вести полемику на тему того, чей костыль красивее :-) и насколько целесообразно его применение, я смысла не вижу.
Ну а пока, изменив параметры «actionban» и «actionunban» например для «recidive» можно уже сейчас блокировать подсети.
Такая методика может привести к тому, что заблокированной окажется вся подсеть буквально из-за одного адреса IP, проявляющего чрезмерную активность.
Хотя для IPv4 это имхо не нужно, т.к. действительно редкость.
В статье приведена выдержка из журнала, которая наглядно показывает, что идет целенаправленный подбор с разных IP одной подсети. Это не синтетический тест. Далее по тексту приведен результат работы скрипта из cron со статистикой попыток для трех заблокированных подсетей: 332-641. Идея написания скрипта родилась у меня, когда статья уже была по большей части готова. Я взглянул на журнал работы Fail2ban и обнаружил, что идет массовый перебор с разных IP одних и тех подсетей. Насколько такие случаи являются массовыми, судить не берусь.
Тем более из-за одного двух нехороших адресов класть всю подсеть в бан на неделю — как-то через чур уж жестко.
Для того, что бы снизить вероятность этого используется двухступенчатая фильтрация. jail «recidive» блокирует отдельные IP на неделю, если они проявляли чрезмерную активность в течение суток: 10 или более блокировок. А срипт из cron в связке с соответствующими настройками logrotate блокирует также на неделю те подсети, чьи адреса набрали за туже неделю 30 или более блокировок. Таким образом, для блокировки всей подсети необходимо как минимум три активных адреса :-)
Sky4eg Мы искали рабочее решение под сервер с большим количеством клиентов на Debian. Ради поддержки нескольких версий PHP мигрировать на CloudLinux не было желания. А в остальных плюшках CloudLinux мы не нуждаемся.
Не обижайтесь, но про динозавра вы правы :) Задача заключалась не просто в том, чтобы убрать данные из ЛВС предприятия, а в обеспечении безопасного доступа к данным через публичный Internet со всех современных ОС: Windows, Linux, Mac OS, Android, iOS.
Точнее так, эта проблема возникает из-за настроек по умолчанию и архитектурных ограничений PHP, ПО серверов HTTP. Как это можно устранить, Вы можете посмотреть по ссылке, которую я указал выше.
На момент проработки ТЗ для клиента, этот продукт мне на глаза не попадался. Ничего про него сказать не могу. Выбор пал на ownCloud как наиболее развитой в своем классе среди бесплатных.
Хетцнер оставимте вне комментариев, пожалуй, чтобы не провоцировать срач :)
Преимущества немецкого регистратора / хостера в том, что за Вашими данными (сиречь, Вашим бизнесом) не придут суровые мужики в масках, не получив перед этим соответствующего постановления немецкого суда. Который, будем смотреть правде в глаза, не совсем то же самое, что, скажем, российский.
А индивидуальную конфигурацию серверов там предложат? А в ДЦ заведут?
И Вы постучитесь сейчас к ним в чат, например. Или среди ночи. :)
Эта методика описана в статье.
Описанное в статье решение базируется на Fail2ban v0.8.6 из стандартного репозитория Debian Wheezy.
Т.е. в итоге полноценной поддержки подсетей в Fail2ban пока нет. А вести полемику на тему того, чей костыль красивее :-) и насколько целесообразно его применение, я смысла не вижу.
Такая методика может привести к тому, что заблокированной окажется вся подсеть буквально из-за одного адреса IP, проявляющего чрезмерную активность.
В статье приведена выдержка из журнала, которая наглядно показывает, что идет целенаправленный подбор с разных IP одной подсети. Это не синтетический тест. Далее по тексту приведен результат работы скрипта из cron со статистикой попыток для трех заблокированных подсетей: 332-641. Идея написания скрипта родилась у меня, когда статья уже была по большей части готова. Я взглянул на журнал работы Fail2ban и обнаружил, что идет массовый перебор с разных IP одних и тех подсетей. Насколько такие случаи являются массовыми, судить не берусь.
Для того, что бы снизить вероятность этого используется двухступенчатая фильтрация. jail «recidive» блокирует отдельные IP на неделю, если они проявляли чрезмерную активность в течение суток: 10 или более блокировок. А срипт из cron в связке с соответствующими настройками logrotate блокирует также на неделю те подсети, чьи адреса набрали за туже неделю 30 или более блокировок. Таким образом, для блокировки всей подсети необходимо как минимум три активных адреса :-)