<фото робо-кошко-жены> Но вообще - это про освоение новых пределов. Так пусть же ветер раздует солнечные паруса! Как Магеллан и Кук, как Кортез и Бартоломеу Диаш, заправлены в планшеты космические карты... До женщин ли им, великим космоплавателям...
Проблема в том, что к тому времени, как женщины прибудут, цисгендерные мрази должны будут обеспечить им приемлемые условия пребывания. Это не Земля, где можно под кустом рожать. И детей вырастить, особенно в младенчестве, тоже целая история. Там шаг влево-вправо, и получился страшный уродец. Иммунитет, кости, микрофлора, аллергии... Так что до рождения детей в космосе нам еще очень и очень далеко. А там уже придумают искусственную матку, и можно будет этот вопрос вообще закрыть...
Между прочим, это неплохой выход. Я не про клавиатуру, конечно. Свозить одного такого под транквилизаторами, и пару профи. Все будут говорить, вот какой он молодец. А псих вполне себе нафантазирует полёт.
Про расу, заметьте, тут особо никто не говорил. Но вот женщина, при одинаковых вложениях в подготовку, физически устроена более хрупко, чем мужчина, и менее физически сильна. Кроме того, с точки зрения популяции, женщины более ценны, чем мужчины. Поэтому с точки зрения целесообразности имеет смысл посылать в космос именно здоровых цисгендерных расистов-шовинистов, желательно уже имеющих детей, чтобы генофонд человечества не потерял удачные комбинации. Такие дела. Вселенная устроена логично, и переносить туда человеческие заморочки - слегка не имеет смысла.
Спасибо за пометку. Там значим весь блок кода. Мы сперва запрещаем от <block_web>, затем разрешаем остальные. Подумаю, может надо более развернуто описать блок конфига.
Можно, что ж нет. Но это вводная статья, где всё максимально упрощено. Кроме того, такие правила гораздо сложнее редактировать во время работы файрволла. Например, удалить 80 порт.
Ну в основном для того, чтобы продемонстрировать само правило. Но используется в основном для того, чтобы отсеять все ACK, которым не предшествовал SYN с одной из сторон. Просто защита от мусора. Сейчас добавлю в статью разъяснения.
С PF всё не так просто, есть возможность заполнить таблицу доменными именами и она будет разрешаться в IP при загрузке. Инфа есть в предыдущем цикле статей. С IPFW - так и есть, в ИКС имеется отдельная внутренняя служба, отвечающая за разрешение доменных имён в IP адреса.
Приветствую! Эта статья - вводная, посмотрите на цикл по PF, там такая же структура. Дальше будем постепенно погружаться, усложнять конфигурации и до skipto дойдём :) Конфигурация тоже демонстрационная. Основная цель - показать, как вообще сторится конфигурация, что именно нужно в какой последовательности писать.
Приветствую!
Там в первой статье про макросы и списки было. Макрос $ExtIf2 будет при применении конфига превращен в re1 или что там в нем. Макрос — это просто замена строки.
Взятое в скобки, имя интерфейса превращается в ip адрес этого интерфейса. К примеру, если провайдер выдаёт ip динамически из пула, и мы не знаем его заранее, в правиле вместо адреса можно указать интерфейс в скобках. То же самое с сетью (re1:network), если мы получаем настройки по dhcp.
В правилах с reply-to и route-to в скобках указывается интерфейс и шлюз за этим интерфейсом, не относится к интерфейсу в скобках. Путано, но уж как есть.
В случае фигурных скобок это список { ($ExtIf2), 192.168.1.0/24}, например, при чтении конфига будет создыны правила для всех элементов списка. Если в фигурных скобках только одно значение, то и дополнительных правил не будет. Удобно сразу брать в фигурные скобки то место, где в будущем возможны несколько значений, и удобно таскать такой конфиг с хоста на хост с минимальными изменениями.
В статьях я постарался использовать максимально возможное количество комбинаций, знаков и элементов синтаксиса, чтобы показать, как вообще можно.
Извините, если запутал.
Поправил. По поводу статей — вряд ли я смогу писать более одной в неделю, скорее уж менее… И уже есть планы на 3 статьи. Следующая, уже начатая, про условную маршрутизацию. Там будет 2 провайдера, маршруты через 2 ВПН-туннеля в одну сеть. Маршрутизация средствами PF и множественные таблицы маршрутизации во FreeBSD. Потом — более глубокий разбор сетевого стэка Фри на 2 статьи. Если получится стэк в одну, то разберу простой балансировщик с 2 провайдеров на pf.
После этого можно будет попробовать что-то по поводу примеров различных настроек.
Да, конечно. Однако в этих статьях я стараюсь акцентировать внимание на PF и его настройке. Если есть интерес, то можем выпустить цикл статеек с примерами первоначальной настройки. Думаю, смысла особого нет. Не на стролько FreeBSD отличается от того-же Debian в этом плане. А остальное легко гуглится.
Спасибо, это хорошая оценка. Цель цикла статей — показать, как настроить типовые конфигурации файрвола в Freebsd. Самое главное — показать логику построения, ведь она сильно отличается от того, к чему привыкли администраторы Linux, использующие IPTables.
Да, именно так. В том числе ограничение количества подключений и защита от спуфинга — в следующей статье. Не забудем и устаревание адресов в таблице bruteforce. Однако table rfc6890 у Вас, на мой взгляд, довольно неоднозначна. У провайдера может быть серая сеть за внешним интерфейсом сервера. Например сервер бэкапов. Или внутренняя нетарифицируемая меж-серверная сеть, годная для обмена данными внутренних ресурсов.
В следующей статье будет подробный разбор фильтрации. Собственно возьмем тот недоконфиг, что я привёл в статье, и будем развивать. Статья банальная именно потому, что вводная.
Обычному юзеру на десктоп — понятное дело, фрю не надо. А вот на сервер — уже не так очевидно. Если железо поддерживается, или вообще виртуалка, то особой разницы нет. А с точки зрения целостности системы и единообразия подхода ко всему на свете FreeBSD даст 100 очков форы любому дистрибутиву Linux.
Проблема dos атак в том, что, зачастую, с точки зрения файрволла, это вполне легитимный трафик. Для защиты от такого необходимо ставить что-то 7 уровня, либо реверс-прокси, либо suricata… Собственно мы в ИКС используем suricata. Если же у вас DDOS, то вообще всё скверно, потому что входящим трафиком, который прилетает из шнурка провайдера, мы не управляем.
<фото робо-кошко-жены>
Но вообще - это про освоение новых пределов. Так пусть же ветер раздует солнечные паруса! Как Магеллан и Кук, как Кортез и Бартоломеу Диаш, заправлены в планшеты космические карты...
До женщин ли им, великим космоплавателям...
Проблема в том, что к тому времени, как женщины прибудут, цисгендерные мрази должны будут обеспечить им приемлемые условия пребывания. Это не Земля, где можно под кустом рожать. И детей вырастить, особенно в младенчестве, тоже целая история. Там шаг влево-вправо, и получился страшный уродец. Иммунитет, кости, микрофлора, аллергии... Так что до рождения детей в космосе нам еще очень и очень далеко. А там уже придумают искусственную матку, и можно будет этот вопрос вообще закрыть...
Между прочим, это неплохой выход. Я не про клавиатуру, конечно. Свозить одного такого под транквилизаторами, и пару профи. Все будут говорить, вот какой он молодец. А псих вполне себе нафантазирует полёт.
Про расу, заметьте, тут особо никто не говорил. Но вот женщина, при одинаковых вложениях в подготовку, физически устроена более хрупко, чем мужчина, и менее физически сильна. Кроме того, с точки зрения популяции, женщины более ценны, чем мужчины. Поэтому с точки зрения целесообразности имеет смысл посылать в космос именно здоровых цисгендерных расистов-шовинистов, желательно уже имеющих детей, чтобы генофонд человечества не потерял удачные комбинации. Такие дела.
Вселенная устроена логично, и переносить туда человеческие заморочки - слегка не имеет смысла.
Спасибо за пометку. Там значим весь блок кода. Мы сперва запрещаем от <block_web>, затем разрешаем остальные. Подумаю, может надо более развернуто описать блок конфига.
Забыли Internet Control Server, тоже наш, скрепный. https://xserver.a-real.ru/
Непонятно почему )
Скорее retroshare
https://retroshare.cc/
Только в ретрошаре можно задейстововать tor или i2p как транспорт.
Можно, что ж нет. Но это вводная статья, где всё максимально упрощено. Кроме того, такие правила гораздо сложнее редактировать во время работы файрволла. Например, удалить 80 порт.
Ну в основном для того, чтобы продемонстрировать само правило. Но используется в основном для того, чтобы отсеять все ACK, которым не предшествовал SYN с одной из сторон. Просто защита от мусора. Сейчас добавлю в статью разъяснения.
С PF всё не так просто, есть возможность заполнить таблицу доменными именами и она будет разрешаться в IP при загрузке. Инфа есть в предыдущем цикле статей.
С IPFW - так и есть, в ИКС имеется отдельная внутренняя служба, отвечающая за разрешение доменных имён в IP адреса.
Приветствую! Эта статья - вводная, посмотрите на цикл по PF, там такая же структура. Дальше будем постепенно погружаться, усложнять конфигурации и до skipto дойдём :) Конфигурация тоже демонстрационная. Основная цель - показать, как вообще сторится конфигурация, что именно нужно в какой последовательности писать.
Спасибо, поправил. Обычные опечатки.
Там в первой статье про макросы и списки было. Макрос $ExtIf2 будет при применении конфига превращен в re1 или что там в нем. Макрос — это просто замена строки.
Взятое в скобки, имя интерфейса превращается в ip адрес этого интерфейса. К примеру, если провайдер выдаёт ip динамически из пула, и мы не знаем его заранее, в правиле вместо адреса можно указать интерфейс в скобках. То же самое с сетью (re1:network), если мы получаем настройки по dhcp.
В правилах с reply-to и route-to в скобках указывается интерфейс и шлюз за этим интерфейсом, не относится к интерфейсу в скобках. Путано, но уж как есть.
В случае фигурных скобок это список { ($ExtIf2), 192.168.1.0/24}, например, при чтении конфига будет создыны правила для всех элементов списка. Если в фигурных скобках только одно значение, то и дополнительных правил не будет. Удобно сразу брать в фигурные скобки то место, где в будущем возможны несколько значений, и удобно таскать такой конфиг с хоста на хост с минимальными изменениями.
В статьях я постарался использовать максимально возможное количество комбинаций, знаков и элементов синтаксиса, чтобы показать, как вообще можно.
Извините, если запутал.
После этого можно будет попробовать что-то по поводу примеров различных настроек.
Мы обновляем ОС и собираем свежий софт из портов от релиза к релизу.
Обычному юзеру на десктоп — понятное дело, фрю не надо. А вот на сервер — уже не так очевидно. Если железо поддерживается, или вообще виртуалка, то особой разницы нет. А с точки зрения целостности системы и единообразия подхода ко всему на свете FreeBSD даст 100 очков форы любому дистрибутиву Linux.
Проблема dos атак в том, что, зачастую, с точки зрения файрволла, это вполне легитимный трафик. Для защиты от такого необходимо ставить что-то 7 уровня, либо реверс-прокси, либо suricata… Собственно мы в ИКС используем suricata. Если же у вас DDOS, то вообще всё скверно, потому что входящим трафиком, который прилетает из шнурка провайдера, мы не управляем.