CrowdSec

Инструмент Fail2Ban хорошо известен админам. Программа анализирует логи на сервере и подсчитывает количество попыток доступа с конкретных IP-адресов по указанным протоколам. В случае нарушения правила данный IP-адрес блокируется на заданный отрезок времени. Например, джейл для авторизации по SSH включён с дефолтными настройками 5 попыток авторизации за 10 минут, после чего происходит бан IP-адреса на 10 минут. Отличный способ отфильтровать мусорный трафик от разных сканеров и защита от DDoS.

Fail2Ban и SSHGuard — лучшие инструменты в своей области. Однако новый опенсорсный проект CrowdSec представляется интересной альтернативой. Это локальная замена Fail2Ban, а потенциально нечто большее — глобальная база репутации IP-адресов типа иммунной системы интернета.

Другие материалы по теме:

Eng version
Что значит наезд на Nginx и как это отразится на индустрии — deniskin
Open source — наше всё. Позиция Яндекса по ситуации с Nginx — bobuk
Официальная позиция Программных комитетов Highload++ и других IT-конференций на претензии к Игорю Сысоеву — olegbunin

---

По информации от одного из сотрудников, в московском офисе опенсорс-разработчиков Nginx проводят обыски в рамках уголовного дела, истцом по которому выступает Рамблер (ниже официальный ответ пресс-службы компании по этому вопросу и подтверждение наличия претензий к Nginx). В качестве доказательств приводится фото постановления о производстве обыска в рамках уголовного дела, возбужденного 4 декабря 2019 года по статье 146 УК РФ «Нарушение авторских и смежных прав».


Как предполагается, истцом выступает компания Рамблер, а ответчиком пока «неустановленная группа лиц», а в перспективе — основатель Nginx Игорь Сысоев.

Суть претензии: Игорь начал работу над Nginx, будучи сотрудником Рамблера, а только после того, как инструмент стал популярен, основал отдельную компанию и привлек инвестиции.

Почему Рамблер вспомнил о своей «собственности» только спустя 15 лет — неясно.

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



Я не могу похвастаться тем, что за 7 лет я затронул все темы сетевой сферы или тем, что хотя бы одну из них раскрыл полностью. Но это и не было целью. А целью этой серии статей было ввести юного студента за руку в этот мир и проводить его шаг за шагом по основной галерее, давая общее представление, и уберечь от болезненных скитаний по тёмным уголкам сознания Олифера и Олифера в мучительных попытках найти ответ на вопрос, как всё это применить в жизни.
СДСМ планировался коротким практическим курсом «как научиться в сети за месяц», а вылился в 16 (на самом деле 19) длинных выпусков, которые мы уже даже переименовали в «Сети Для Самых Суровых». Общее количество символов перевалило за 1 000 000.

Эта статья является четвертой в цикле статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти здесь.

В первой части этой главы мы рассмотрели некоторые аспекты сетевой безопасности сегмента «Data Center». Эта часть будет посвящена «Internet Access» сегменту.

Internet access

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

При аудите этого сегмента обратите внимание на следующие аспекты:

• дизайн
• настройки BGP
• DOS/DDOS защита
• фильтрация трафика на фаерволе

Эта статья является третьей в цикле статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти здесь.



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

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

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

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

Эта статья является первой в цикле статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти здесь.

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

Итак, начальные условия.

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

Ваша первая стратегическая цель – научиться противостоять энтропии и удержать уровень предоставляемого сервиса.

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

Рассмотрим на практике использование Windows Active Directory + NPS (2 сервера для обеспечения отказоустойчивости) + стандарт 802.1x для контроля доступа и аутентификации пользователей – доменных компьютеров – устройств. Ознакомиться с теорией по стандарту можно в Wikipedia, по ссылке: IEEE 802.1X

Так как “лаборатория” у меня ограничена по ресурсам, совместим роли NPS и контроллера домена, но вам я рекомендую такие критичные сервисы все же разделять.

Стандартных способов синхронизации конфигураций (политик) Windows NPS я не знаю, поэтому будем использовать скрипты PowerShell, запускаемые планировщиком заданий (автор мой бывший коллега). Для аутентификации компьютеров домена и для устройств, не умеющих в 802.1x (телефоны, принтеры и пр), будет настроена групповая политика и созданы группы безопасности.

В конце статьи расскажу о некоторых тонкостях работы с 802.1x – как можно использовать неуправляемые коммутаторы, dynamic ACL и пр. Поделюсь информацией об отловленных “глюках”…

История реальная, я все видел своими глазами.

Несколько лет один парень, как и многие из вас, работал программистом. На всякий случай напишу так: «программистом». Потому что он был 1Сником, на фиксе, производственной компании.

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

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

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

Операционные системы (ОС) — обширная тема. На протяжении десятилетий здесь доминировал один подход: Unix. Действительно, большинство современных систем, включая большинство дистрибутивов GNU/Linux, *BSD и macOS, придерживаются архитектуры Unix. (Windows нет, но там почти ничего интересного по этой теме).

В 2000 году Роб Пайк выступил с докладом о том, почему исследования системного ПО не релеванты. Из-за пессимизма или пренебрежения к сообществу он, кажется, полностью проигнорировал жалобы, собранные многими Unix-пользователями в книге The Unix-Haters Handbook (1994). Книга умышленно саркастична, однако указывает на некоторые критические проблемы систем Unix — и они не решены до сих пор.

В 2006 году Элко Доситра опубликовал диссертацию «Полностью функциональная модель развёртывания программного обеспечения», где описан функциональный менеджер пакетов Nix. В 2008 году автор опубликовал NixOS: полностью функциональный дистрибутив Linux. В то время как NixOS повторно использует много свободного ПО для Unix-систем, она настолько отходит от дизайна и философии Unix, что вряд ли её можно назвать «системой Unix».

Эта статья является второй в цикле статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти здесь.



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

Сейчас мы не будем говорить об аудите безопасности – этому будет посвящена третья часть.

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

Идеальная ситуация – это когда

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

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

В худшем варианте у вас будет

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

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

Привет.

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

Нередко слышишь мнение, что составление Технического задания по ГОСТ 34 (ТЗ) занятие не только трудоемкое, но и крайне раздражающее, поскольку приходится писать много всякой ерунды, воды. Но подумайте: разработкой этого ГОСТа занимались целые НИИ, это был проект на государственном уровне, обобщен опыт сотен проектов автоматизации, сложных проектов. Неужели они могли написать чушь?

На самом деле, при грамотном подходе ГОСТ очень сильно помогает не только при разработке ТЗ, но и в ходе реализации проекта автоматизации в целом (и не только в госконтрактах, но и для коммерческой разработки). Грамотные люди его писали. Но чтобы воспользоваться плодами их трудов, нужно немного понять замысел не только ТЗ, но и ГОСТ 34 в целом.

В данной статье мы пункт за пунктом разберем все требования ГОСТа и попробуем сделать разработку ТЗ по ГОСТ 34 не обременением, а большой помощью в проекте.

— Сергей, приветствую. Присаживайся.

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

— Что случилось, Евгений Викторович? – осторожно спросил Сергей, присаживаясь напротив собственника.

— Расскажи о ходе проекта по складу.

Евгений Викторович задал этот вопрос, не глядя на Сергея. Дурной знак. У Сергея по спине пробежал неприятный холодок, ладони предательски вспотели – хорошо еще, что успел пожать руку собственнику раньше.

— Все идет по плану. – язык тяжело шевелился в пересохшем рту. – Сейчас занимаюсь автоматизацией контроля.

— С помощью штрихкодов?

— А?

Это единственное, что смог сказать Сергей. Вот дубина, подумал он. Растерялся, как школьник, у которого в кармане мама нашла сигареты. Но откуда он…

— Как штрихкод поможет навести порядок на складе? – Евгений Викторович, наконец, повернулся к Сергею и уставился на него в упор.

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

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

Привет, Хабр!

У нас давно не выходило новых книг по Linux для начинающих — и вот мы беремся за перевод новинки именно такого плана. Книга "Linux in Action" Дэвида Клинтона вышла в издательстве Manning и рассказывает не только о внутреннем устройстве Linux, но и о наиболее распространенных проблемах, и о способах их устранения.


Автор опубликовал на сайте Hackernoon отрывок из 9-й главы, который мы и предлагаем вам оценить.

Данная статья призвана сократить количество времени, необходимое для понимания принципов работы с ExtremeXOS (XOS). Когда я начинал знакомство с XOS, мне очень не хватало такой статьи на Хабре.

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

Стенд коммутаторов Extreme

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

В этой статье я постарался идти от совсем банальных советов до довольно сложно реализуемых. Каждый должен решить самостоятельно, какой уровень безопасности приемлем лично для него. Тут все точно так же, как с сейфами: есть сейф за сто долларов, есть сейф за сто тысяч долларов. Глупо хранить миллионы долларов в первом, и горстку мелочи — во втором.

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

Хочу представить общественности свою разработку – приложение для удаленного управления рабочим столом Aspia. Проект является полностью бесплатным и с открытым исходным кодом (GPL 3.0).

На данный момент реализованы следующие возможности:

• Удаленное управление рабочим столом
• Удаленный просмотр рабочего стола
• Передача файлов
• Адресная книга с поддержкой шифрования и мастер-паролем (XChaCha20+Poly1305, 256-битный ключ)
• Возможность создавать пользователей с индивидуальными правами
• Шифрование всей передаваемой по сети информации (XSalsa20+Poly1305)

Мы живем в интересное время. Я бы даже сказал, в удивительное. По одну сторону мы видим неких лиц, которые очень хотят знать, о чем между собой разговаривают другие люди, и очень хотят указывать им, что можно читать, а что нельзя. С другой стороны граждане, которые хотят отстоять свои права тайны личной переписки и свободного получения информации, и не хотят, чтобы факты этой самой переписки и получения этой самой информации были использованы против них. Бонусом страдает огромное количество сторонних сайтов, сервисов и бизнесов, которых задевает «ковровыми блокировками».

Но нет, эта статья не об обществе, а о технологиях.

Настоящий админ может спать спокойно лишь тогда, когда у него всё бэкапится, мониторится и дублируется. Или когда он работает в хорошей команде, где всегда можно свалить вину на другого.
Так получилось, что я в своей работе использую в основном продукты Microsoft и могу сказать, что компания серьезно подходит к резервированию своих сервисов: Active Directory, Exchange DAG, SQL Always On, DFSR и т.д. Как и везде, здесь есть как весьма изящные и удачные реализации, так и явно неудобные и тяжелые. Для сервиса печати тоже есть решение, но для него необходима кластеризация на базе Hyper-V. А хотелось простого решения “из коробки”, не требующего дополнительных финансов. За основу была взята Windows 2012 R2, но скорее всего та же схема без проблем будет работать на любых серверных версиях, начиная с Windows 2008, и даже клиентских ОС от Vista и выше (привет любителям экономить бюджет!). Кому интересно — прошу под кат.