FreeBSD или Debian на прокси.

оставайтесь на дебиан и доставьте нужное
на 2Mbit-а хватит Pentium III

iptables на фряхе вы вряд ли поднимете :)

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

Да, и что значит "нет того из-за чего переезжаем"?

>iptables на фряхе вы вряд ли поднимете :)

Да iptables — г... по сравнению с PF.

Але, цирк уехал.

>на 2Mbit-а хватит Pentium III

у меня Pentium II 233Мгц с 64Мб ОЗУ на ура обслуживает 10Мбит/с

Хотя, если сайт предоставляет всем желающим сервис по вычислению факториалов пятизначных чисел, загнётся он при любом канале %)

Какой востребованный сервис получится 8)

>>на 2Mbit-а хватит Pentium III

>у меня Pentium II 233Мгц с 64Мб ОЗУ на ура обслуживает 10Мбит/с

у меня толще!
486DX2 66MHz обслуживает 4Mbit/s ^_^

>Да, и что значит "нет того из-за чего переезжаем"?

Это значит что мне это досталось в наследство и иначе как помойка это дело не назовешь. Поэтому проще поднять всё с нуля.

Во, как раз гадал справиться ли четвёрка или не справится.

Покажи плиз top при нагрузке в 4mbs.

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

А лучше за ~400$ купить нормальный офисный системник с инт.видеокартой заместо хламья.
Купить и прочитать книжку Майкла Лукаса. Почитать и разобраться в PF FAQ.
Затем поставить FreeBSD 7.2-RELEASE.

Это легче и быстрее, даже если за свои деньги — окупится быстро.

>ставь то что лучше админить умеешь

Могу по этому поводу одну презабавную историю рассказать.
Один мой знакомый в свое время, как и все мы, только начинал знакомство с никсами.
Знакомство начиналось с практической задачи задачи: сделать нат на домашнем сервере. Сначала он попытался это сделать на Мандриве. Ниасилил. Точнее, не нашел параметра sysctl net.ipv4.ip_forward.
Снес мандриву со словами "линукс отстой". Поставил фряху. В первый же день пересобрал ядро с поддержкой ipfw и divert, разобрался с правилами ipfw divert natd и т.д.
Cейчас он уже несколько лет на фряхе, админ в крупной хостинговой фирме, и искренне считает линух непригодным серваков.

Это к вопросу о том, какие прикольные люди фанаты BSD :D

>Затем поставить FreeBSD 7.2-RELEASE.

2OSBuster: не слушай школьников. Если ставить фряху, то 7.1, ибо поддержка до конца 2011. У 7.2 - до мая 2010.

Что касается фаерволов: любой упертый фанатик BSD скажет, что iptables сложен для понимания, а pf простой как швабра и мощный как самосвал. Любой упертый фан линуха скажет что все наоборот. Так что не очень-то доверяй таким выкрикам ;)

>Если ставить фряху, то 7.1, ибо поддержка до конца 2011. У 7.2 - до мая 2010.

FreeBSD Security Advisories
2009-06-10 FreeBSD-SA-09:11.ntpd
2009-06-10 FreeBSD-SA-09:10.ipv6
2009-06-10 FreeBSD-SA-09:09.pipe
2009-04-22 FreeBSD-SA-09:08.openssl
2009-04-22 FreeBSD-SA-09:07.libc
2009-03-23 FreeBSD-SA-09:06.ktimer
2009-02-16 FreeBSD-SA-09:05.telnetd
2009-01-13 FreeBSD-SA-09:04.bind
2009-01-13 FreeBSD-SA-09:03.ntpd
2009-01-07 FreeBSD-SA-09:02.openssl
2009-01-07 FreeBSD-SA-09:01.lukemftpd
с момента релиза FreeBSD 7.1.

FreeBSD Security Advisories
2009-06-10 FreeBSD-SA-09:11.ntpd
2009-06-10 FreeBSD-SA-09:10.ipv6
2009-06-10 FreeBSD-SA-09:09.pipe
с момента релиза FreeBSD 7.2.

7.2-RELEASE — это "переходный" релиз к 8.0-RELEASE, ожидаемый следующей осенью.

>Что касается фаерволов: любой упертый фанатик BSD скажет, что iptables сложен для понимания, а pf простой как швабра и мощный как самосвал. Любой упертый фан линуха скажет что все наоборот.

Знаю только обратные случаи: люди переезжали с IPTABLES на PF и облегчённо вздыхали, как всё просто и понятно, из тысяч правил на iptables получалось полторы сотни правил на PF.

iptables можно сравнить с ассемблерными инструкциями (только правила).
PF сравнивается с языком высого уровня типа Pascal (секции, макроопределения, правила).

>FreeBSD Security Advisories...

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

>люди переезжали с IPTABLES на PF и облегчённо вздыхали, как всё просто и понятно, из тысяч правил на iptables получалось полторы сотни правил на PF.

Неудивительно. Фанатики такие фанатики :)
А я вот знаю много историй, когда люди начисто отказывались переходить с iptables на pf, упирая на полное отсутствие в pf всякой логики.

Насчет тысяч правил - это надо быть злостным ламером, чтобы не знать про ipset.

>iptables можно сравнить с ассемблерными инструкциями (только правила).

Не знаешь iptables - так не позорься.

>Не знаешь iptables - так не позорься.

+1 гибче iptables еще ничего не придумали

http://sysadmins.ru/topic134709.html

>http://sysadmins.ru/topic134709.html

но там почти ничего нет про iptables :)

нет , я лично ничего против не имею ipfw и pf. даже сам использовал их,когда сидел на freebsd 5. но когда переполз на линукс ,понял что iptables в связке iproute2 намного гибче и функциональнее.а то что много правил - так для админа это не страшно и можно привыкнуть :) тем более что можно аккуратно расписать правила по цепочками.

единственный недостаток iptables - он больше требует cpu при значительном траффике. но за все надо платить... :)

>http://sysadmins.ru/topic134709.html

Краткий инструктаж на тему "ipfw suxxx, use pf". Все правильно.
Ну и как это относится к теме?

>единственный недостаток iptables - он больше требует cpu при значительном траффике

Да ну? Огласите цифры, если не трудно. И аналогичные для pf.

это ты к чему с advisories?

У 7.2 все те же дыры что и у 7.1

угу, судя по топику на сисадминах не осилили ipfw :]

>У 7.2 все те же дыры что и у 7.1

Разве те дыры, которые были в 7.1 ДО выпуска 7.2, в 7.2 не пофикшены?
Уважаемый iZEN пытался привести это в качестве существенного преимущества 7.2 над 7.1. Правда, это преимущество работает только в том случае, если админ не знает про advisories :)

А вот после окончания срока поддержки система гарантированно превращается в решето. Посему для хоть сколько-нибудь серьезных серваков, а не просто "тестовых машинок", разумно выбирать релиз с максимальным сроком поддержки.

> Разве те дыры, которые были в 7.1 ДО выпуска 7.2, в 7.2 не пофикшены?

А разве те дыры что вообще были в 7.1 не пофикшены? hint: 7_1_RELENG.

> разумно выбирать релиз с максимальным сроком поддержки.

у фряшки очень просто происходит миграция на новые релизы(по крайней мере в пределах одной мажорной ветки). С учётом некоторых хороших фич в 7.2 я бы выбрал именно её а потому обновил бы когда ей придёт eol.

>hint: 7_1_RELENG.
Как много нам открытий чудных... :)

>С учётом некоторых хороших фич в 7.2 я бы выбрал именно её а потому обновил бы когда ей придёт eol.

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

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

>Ну это зависит от назначения машины. Если на ней эти фичи нафиг не нужны - так лучше идти по пути наименьшего траха.

Так и так придётся обновлять ядро/мир, закрывая уязвимости.
В 7.2 включены функции мультироутинга. Так что эта фича несовсем второстепенна для шлюза.

>Так и так придётся обновлять ядро/мир, закрывая уязвимости.

О! Это так сложно сделать?
Кроме того, тут мелькало волшебное слово RELENG

>В 7.2 включены функции мультироутинга.

А до этого ipnat значит мультироутинга не умел?

Изобразите вот это правило PF:
pass in quick on $wan_if_u reply-to ($wan_if_u ($wan_if_u:0)) \
    inet proto tcp from any to ($wan_if_u:0) port ssh \
    (max-src-conn 15, max-src-conn-rate 5/3, \
    overload <bruteforce> flush global, floating) label "SSH"

на IPTABLES?

"Данное правило разрешает входящие SSH-соединения и создаёт обратное правило.
При этом ответ будет отправлен на тот интерфейс с которого он пришёл, независимо от маршрута по умолчанию. Если кто-то попытается установить соединения превышающее max-src-conn-rate, адрес будет добавлен в таблицу bruteforce и что важно, ВСЕ установленные соединения с данным адресом (по любым портам) будут незамедлительно закрыты.
Да, и ещё важная деталь, это правило динамическое. Т.е. если у интерфейса $wan_if_u сменился адрес, всё будет работать без перезагрузки правил."

Тут есть один нюанс. Нельзя ограничить кол-во соединений за определённый период в pf. Дробь 5/3 будет преобразована к 1.6 соединений в секунду без всяких burst. Так что тут линух работает сильно лучше.

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

А вот чтобы ходило через тот же интерфейс пока не знаю. Опиши в какой ситуации это может произойти, тогда может что-нить придумаю. У меня стоит net.ipv4.conf.all.rp_filter = 1 на всякий случай.

>Тут есть один нюанс. Нельзя ограничить кол-во соединений за определённый период в pf.

Можно.
Это решается опциями. Пример:
# укороченный таймаут "1 час" для состояния установленного tcp соединения
set timeout { frag 10, tcp.established 3600 }

Из man'a:
pf(4) may be tuned for various situations using the set command.

     set timeout

           interval   Interval between purging expired states and fragments.
           frag       Seconds before an unassembled fragment is expired.
           src.track  Length of time to retain a source tracking entry after
                      the last state expires.

           When a packet matches a stateful connection, the seconds to live
           for the connection will be updated to that of the proto.modifier
           which corresponds to the connection state.  Each packet which
           matches this state will reset the TTL.  Tuning these values may
           improve the performance of the firewall at the risk of dropping
           valid idle connections.

For example:
set timeout tcp.first 120
set timeout tcp.established 86400
set timeout { adaptive.start 6000, adaptive.end 12000 }
set limit states 10000

With 9000 state table entries, the timeout values are scaled to 50% (tcp.first 60, tcp.established 43200).

>Дропнуть соединения явно и без костылей, увы, нельзя, но можно заблокировать пакеты для этого хоста и соединения сами скоро отвалятся. 

Опять же, в секции опций:
set block-policy drop

>А вот чтобы ходило через тот же интерфейс пока не знаю. Опиши в какой ситуации это может произойти, тогда может что-нить придумаю. У меня стоит net.ipv4.conf.all.rp_filter = 1 на всякий случай.

Чего?

> Это решается опциями. Пример:

Как задать что можно с одного хоста не более 10 соединений в минуту?

> Чего?

В какой ситуации пакет придёт не на тот интерфейс?

>Дропнуть соединения явно и без костылей, увы, нельзя,

А разве REJECT этого не делает? В случае, скажем, с tcp, после отправки RST логично соединение закрыть.

>>net.ipv4.conf.all.rp_filter = 1
>Чего?

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

>Можно.
>Это решается опциями. Пример:

Да-да-да. Блестящий пример, не имеющий никакого отношения к теме. А в линухе эти таймауты рулятся через sysctl.

Блокировкой же брутфорсеров, а равно и портсканнеров, должны заниматься специально обученные юзерспейсовские демоны. Фаервол должен быть _быстрым_, а не задумчивым.

> А разве REJECT этого не делает?

нет. Вот у меня установлено соединение. Как его дропнуть? reject только удалённой стороне ошибку отправит, а локально соединение будет висеть пока по таймауту не отвалится.

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

не согласен. Как раз фаервол создан для защиты. Если в его функции защита не входит то зачем он тогда нужен?

По поводу скорости. На гигабитных линках с миллионами записей в conntrack работает нормально. Правил в фаерволе не сотни, но десятки, в том числе тысячи хостов в ipset.

>локально соединение будет висеть пока по таймауту не отвалится.

Насколько это опасно? Задосить так можно?

>не согласен. Как раз фаервол создан для защиты.

Так PAM тоже создан для защиты :) Только он почему-то сетевой трафик не фильтрует... И музыку не играет.

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

Конечно, можно блокировать брутфорс средствами банальной пакетной фильтрации - в pf для этого есть max-src-conn, max-src-con-rate, overload, в iptables - recent. Но это будет "хирургия топором". Имхо с такими атаками нужно бороться, _анализируя_ трафик и принимая решения, как это делают IDS, а не тупой фильтрацией.

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

# Антиспуффинг
antispoof for { $wan_if, $lan_if1, $lan_if2 }

>Блокировкой же брутфорсеров, а равно и портсканнеров, должны заниматься специально обученные юзерспейсовские демоны. Фаервол должен быть _быстрым_, а не задумчивым.

Вот в линухе потому так всё сложно, что любую более-менее сложную задачу решают сообща куча демонов и скриптов и никто ни за что не отвечает. :))

>Вот в линухе потому так всё сложно, что любую более-менее сложную задачу решают сообща куча демонов и скриптов и никто ни за что не отвечает.

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

Демонов и скриптов нет только в винде - наверное, поэтому ее так любят упертые фанаты фряхи.

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

> Насколько это опасно? Задосить так можно?

ну, ни у кого ещё ни разу не получалось.

Ты когда-нить защитой серверов занимался? Можно узнать названия волшебных программ который бы защитили сервер? Неужели дырявый snort? Или циски? :)

И почему recent это хирургия топором? Не тот ли это анализ трафика о котором ты говорил?

И ты так и не ответил зачем нужен фаервол.

>Неужели дырявый snort?

В каком месте он дырявый?
Если есть конструктивная альтернатива этой свинье - валяй, буду рад. Задолбался пакеты со snortsam-патчем пересобирать.

>И почему recent это хирургия топором? Не тот ли это анализ трафика о котором ты говорил?

Потому что более корректным подходом к борьбе с ssh-брутфорсом будет анализ логов sshd на предмет _неудачных_ попыток логина, как это делает, скажем sshguard, а не подсчет количества соединений. Может, я просто по жопорезу к своему серваку коннекчусь, а жопорез падает часто.

Это - наиболее корректный в данном случае подход, то, что я назвал "блокированием на уровне программы". Анализ трафика больше подходит для ряда других задач, например, детект портскана.

>И ты так и не ответил зачем нужен фаервол.

Фаервол - фильтровать и классифицировать трафик. Шейпер - приоретизировать и ограничивать его. Снифферы и иже с ними IDS - исследовать его на предмет опасности. Таблицы рогутинга - роутить его. Аудиоплеер - играть музыку. Так пусть каждая прога^Wподсистема будет делать свою работу, и делать ее хорошо!

> Может, я просто по жопорезу к своему серваку коннекчусь, а жопорез падает часто.

Настолько часто что защита срабатывает? не верю.

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

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

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

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

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

Пакетный фильтр PF не занимается просмотром и анализом содержимого пакетов. Он анализирует и обрабатывает только заголовки IP-пакетов.

>Настолько часто что защита срабатывает? не верю.

Запросто.

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

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

>Так вот хватило лёгкого пинг-флуда чтобы это перловое поделие выжрало все ресурсы.

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

>При том что портов всего чуть больше 65тыщ распределённой системой можно быстро все порты просканить так что никто ничего не заметит.

Ключевое слово "распределенной". Развернуть распределенную систему или купить услуги тех, кто ее предоставляет - это не nmap запустить.
Вероятность применения против рядового сервака такой системы очень мала. А nmap-а - высока.

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

В свое время в patch-o-matic тусил проект psd - детект портскана на уровне фаервола. Загнулся проект. Ныне в xtables-addons пребывает критерий lscan - однако хреновенько он работает... Во фряхе, насколько я знаю, вообще ничего похожего нет. Фаервол - это фаервол. Вот когда (если) в ядро встроят нормальную IDS - тогда будет разговор.

>В отличие от от userland-средств которые...

Альтернатива pcap - решения типа psad, которые требуют добавления в iptables правила логгировать ВСЕ пакеты и потом читают логи. Думаете это лучше? А других альтернатив пока нет.

pf может быть, зато модуль string может :). Полезно, например, для отлова некоторых червей и заражённых тачек в локалке.

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

iZEN, ты так и не привёл ситуации когда пакет приходит не на тот интерфейс. И, на сколько я понимаю, бридж успешно решает эту проблему, я прав?

> Вероятность применения против рядового сервака такой системы очень мала. А nmap-а - высока.

это тоже не проблема. Надо просто интервал увеличить и подождать. Большинство защит это обойдёт. Потом вероятность мала если это тупо боты шаряться по сети провайдера. А если твой сервак облюбовали хацкеры то они быстро поймут что к чему.

> Думаете это лучше?

Я думаю это просто не нужно. От брутфорса меня, например, защищает авторизация по ключам, отключённая парольная аутентификация у ssh и большие таймауты при неуспешной попытке. Ну и knockd когда-нить поставлю если надоест мусор в логах. Хотя, вроде, эта задача успешно может решаться и средствами iptables в связке с ipset.

Я убедил что snort не нужен? Если нет то скажи в каком случае он может помочь. Ты случайно не в гос-структуре серваки защищаешь? Слышал, в армии его используют.

>pf может быть, зато модуль string может

Угу. Некоторый функции снорта он с успехом заменяет.

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

Согласен :) Но я и не говорил, что всякие снорты, scanlogd и psad нужны на каждом шагу.

Только брутфорс - это не дос и не использование дыры. Впрочем, лучшая защита от ssh-брутфорса - всего лишь повесить sshd на нестандартный высокий порт :)

а, погоди, самопальный скрипт который парсит логи и банит тех кто борзеет входит в понятие userspace-программ? Ну тогда я отчасти с тобой соглашусь, некоторые атаки фаерволом не уберёшь. Однако я считаю что если фаервол умеет что-то хорошо делать то это надо делать фаерволом. И не руководствоваться предубеждениями что дескать некошерно функционал ids переносить в фаервол.

>Надо просто интервал увеличить

Прежде чем поймут - засветятся. С паршивой овцы хоть шерсти клок.

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

>Хотя, вроде, эта задача успешно может решаться и средствами iptables в связке с ipset.

Какая задача? Открывать порт после стука? Так это опять же старый добрый recent, насколько я помню. Щас в patch-o-matic есть модуль portknocko, но, кажется, ему кабздец.

>Если нет то скажи в каком случае он может помочь.
It features rules based logging and can perform content searching/matching in addition to being used to detect a variety of other attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, and much more
:)
Если серьезно - находить и банить зараженные всякой дрянью виндовые машины, а также наших любимых школьников-кульхацкеров и иже с ними. Вообще для сервера они обычно не опасны, но всяко бывает. Иногда лучше переоценить опасность, чем недооценить ее.

>Однако я считаю что если фаервол умеет что-то хорошо делать то это надо делать фаерволом.

Я бы с радостью. Только вот когда фаервол научится хорошо "делать" IDS...