​​Взломы и их причины

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

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

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

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

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

1️⃣ Слабая политика паролей. По нашей статистике – это одна из основных причин взломов. Слабые пароли, словарные пароли, утекшие пароли. Это просто вопрос времени, боты не знают устали и рано или поздно такой пароль подберут.

Отдельная проблема современности – утекшие пароли, когда пользователь имеет один пароль от рабочей учетной записи и аккаунта в каком-нибудь сервисе, в итоге после очередной утечки или по недосмотру самого пользователя данный пароль утекает в сеть.

Все знают, что пароль должен быть длинным, сложным и периодически меняться, но далеко не у всех хватает сил и воли внедрить и поддерживать такую политику. Как правило все сводится в некоторому компромиссу, по которой надежными начинают считаться пароли типа 1Q2w3E4r$ или Dima2008!, что вкупе с сочетанием других факторов приводит к печальному результату.

Чаще всего нарушителями этой политики становятся топы, которым «не удобно» и которые «не хотят».

В таких случаях не следует выпускать в мир подобные сервисы, закрывайте их при помощи VPN не предусматривающих парольную аутентификацию, например, OpenVPN по сертификатам.

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

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

2️⃣ Уязвимые и снятые с поддержки системы. Что в принципе можно рассматривать как одно и тоже. Пальму первенства тут держат Windows 2003/2008 с RDP сервером на борту, а если такой сервер еще и является членом домена – то это вовсе праздник какой-то, а если еще и контроллером – то прямо фестиваль. Понятно, что не у вас.

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

За старыми версиями Windows следуют ESXi (преимущественно пиратские) и Mikrotik. Софт популярный, уязвимости находятся регулярно, поэтому отсутствие обновлений фактически переводит такие системы в состав уязвимых.

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

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

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

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

erid: 2W5zFHrMtMW

Каждый бизнес — это цепочка процессов: от продаж до производства, от логистики до поддержки клиентов. Но если процессы не оптимизированы, компания теряет время, деньги и конкурентные преимущества.

Зачем анализировать процессы?

✔️ Понять, как работает бизнес — визуализация помогает выявить слабые места.
✔️ Устранить потери — находите и убираете лишние действия, дублирование и задержки.
✔️ Стандартизировать работу — создавайте четкие регламенты для сотрудников.
✔️ Масштабироваться без хаоса — с ростом бизнеса сложно уследить за изменениями PIX Robotics предлагает простое решение — «Облако процессов». Это бесплатная облачная платформа для моделирования, анализа и улучшения бизнес-процессов.Почему стоит попробовать?
✔️ Работа из браузера — не требует установки, доступно из любой точки мира.
✔️ 5 нотаций для моделирования процессов разного уровня (BPMN, VAD, EPC, Workflow, ArchiMate) — подходят для любых задач.
✔️ Регламенты и реестры — вся информация в одном месте.
✔️ Импорт из .bpmn, .vsdx — не нужно рисовать заново.
✔️ Открытая База знаний — поможем разобраться с первых шагов.

👉 Попробуйте бесплатно

​​Я устал, я ухожу или соловья баснями не накормишь

Очередная новость с просторов сети:

▫️ Ник Велнхофер (Nick Wellnhofer), сопровождающий библиотеку libxml2, объявил, что отныне будет трактовать уязвимости как обычные ошибки. Сообщения об уязвимостях не будут рассматриваться в приоритетном порядке, а станут исправляться по мере появления свободного времени.

Информация о сути уязвимости будет размещаться в публичном доступе сразу, не дожидаясь формирования патча и распространения исправления в дистрибутивах и операционных системах.

Ник также снял с себя полномочия сопровождающего библиотеку libxslt и высказал сомнения в том, что найдётся кто-то готовый взять на себя её поддержку.

✅ Источник: https://www.opennet.ru/opennews/art.shtml?num=63437

На первый взгляд новость вызывает недоумение и возмущение: ну как это так? Это же уязвимости! А тут взять и отказаться их исправлять. Но не будем спешить с выводами, благо Ник достаточно подробно пояснил свою позицию.

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

При этом данную библиотеку используют в своих продуктах Apple, Google и Microsoft (а также 1С) и как-то не спешат помочь разработчику. Ну да опенсорс, все свободно, никто никого не держит.

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

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

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

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

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

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

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

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

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

В общем сказка ложь, да в ней намек. А это даже совсем и не сказка. Данная история хороший повод задуматься всем, а прежде всего авторам и разработчикам. Задуматься о том, что мы живем в материальном мире и имеем материальные потребности. И каждый раз взяв что-то бесплатное вспоминать, что за этим бесплатным все-таки стоит чей-то труд.

Смотри на картинку внимательно - знакомых найдешь обязательно!

Всех узнали?

​​Распространяемые компоненты Microsoft Visual C++

Мы думаем, что показанное на картинке окно видел каждый. И хотелось бы думать, что каждый знает как с этим бороться. Но практика порой показывает иное…

Самое худшее, что можно придумать – это начать качать указанные библиотеки из сети интернет. Поэтому не стоит рубить сгоряча, а следует для начала разобраться что это такое.

Итак, если вы увидели данное окно, то это значит, что на вашем компьютере не хватает библиотек распространяемых компонентов Microsoft Visual C++. Эти компоненты являются общими и устанавливаются в систему отдельным пакетом, чтобы потом все нуждающиеся программы могли их использовать.

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

Всего существуют следующие версии:

▫️ Visual Studio 2005 (VC++ 8.0)
▫️ Visual Studio 2008 (VC++ 9.0)
▫️ Visual Studio 2010 (VC++ 10.0)
▫️ Visual Studio 2012 (VC++ 11.0)
▫️ Visual Studio 2013 (VC++ 12.0)
▫️ Visual Studio 2015 (VC++ 14.0)

А вот дальше начинается путаница, вроде бы формально старшие версии называются:

▫️ Visual Studio 2017 (VC++ 15.0)
▫️ Visual Studio 2019 (VC++ 16.0)
▫️ Visual Studio 2022 (VC++ 17.0)

Но по факту Visual Studio 2019 (VC++ 16.7) имеет версии файлов начиная с 14.27, а 2017 с 14.16.

Но выручает то, что сейчас версии 2015-2022 объединили в общий инсталлятор.

Скачать все эти пакеты можно со страницы: https://learn.microsoft.com/ru-ru/cpp/windows/latest-supported-vc-redist?view=msvc-170

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

А вообще, зная любовь Microsoft к постоянному переделыванию собственных порталов и удалению старых версий мы бы советовали выкачать все пакеты и хранить их локально.

Крайне познавательная и интересная статья с Хабра:

Исследую роутеры с «вечным VPN» с российских маркетплейсов: admin:admin, открытые порты и доступ к соседям

Привет, Хабр! Меня зовут Иван Глинкин, я занимаюсь инфраструктурным тестированием и аппаратным хакингом в Бастионе. Недавно наткнулся на интересное предложение на российских маркетплейсах — роутеры с предустановленным «пожизненным» VPN. Звучит заманчиво: купил, включил и сразу получаешь безлимитный доступ к виртуальной частной сети, причем без подписки.

Но, как говорится, бесплатный сыр бывает только в мышеловке. Я решил разобраться, что на самом деле скрывается за красивыми обещаниями продавцов. Приобрел три роутера из разных ценовых категорий — от бюджетного Cudy за 3000 рублей до топового Xiaomi за 7000. Спойлер: если вы ожидали хеппи-энд, то вы зашли не в тот блог.

В процессе исследования обнаружил несегментированные сети, где можно получить доступ к устройствам других покупателей, пароли admin:admin, хранящиеся в открытом виде, и SSH-доступ для продавцов. А еще выяснил, что «пожизненные» серверы работают на дешевом хостинге за 2,5 доллара.

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

✅ https://habr.com/ru/companies/bastion/articles/917522/

​​WinGet (Windows Package Manager) - пакетный менеджер для Windows

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

Пользователи Windows долгое время были лишены подобного инструмента, собственно, как вообще какого-то централизованного подхода к управлению ПО, но затем в Windows появился Магазин, а затем и менеджер пакетов, названный просто - Windows Package Manager или WinGet. В данной статье мы рассмотрим его особенности и примеры работы с ним.

https://interface31.ru/tech_it/2023/09/winget---paketnyy-menedzher-dlya-windows.html

Вчера мы опубликовали заметку о WinGet, достаточно удобном инструменте командной строки для управления пакетами в Windows.

Из плюсов – это родной инструмент и вам не нужно ставить никаких дополнительных приложений.

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

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

В данном случае все уже сделано за нас, приложение Winget-AutoUpdate – это набор PowerShell скриптов, упакованных в удобный установщик и позволяющий выполнять обновление с уведомлением и поддержкой черных и белых листов.

Дополнительный плюс – наличие административных шаблонов для GPO, что дает возможность применять его для обновления приложений пользователей Active Directory.

✅ https://github.com/Romanitho/Winget-AutoUpdate

​​О различных подходах к системному администрированию

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

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

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

Со временем у каждого собирался т.н. «джентельменский набор», который старательно записывался на дискеты, потом нарезался на диски, а затем уже и на флешки перекочевал. Можно ли что-либо из этого сделать просто так, средствами системы, мы не задумывались. А зачем?

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

И сразу же стали всплывать вопросы вроде «а где мне найти аналог утилитки X или программки Y». Только вот интернет не спешил радовать порталами, где были бы сложены разные нужные программки для Linux, разной степени лицензионной чистоты.

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

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

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

Потом мы открыли для себя панели, и многие, включая меня на них подсели. Однако разочарование пришло довольно быстро. Системы время от времени ломались вместе с панелями. И становилось очень неуютно и тоскливо. Особенно если это была система заказчика.

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

Те, кто остался, стали осваивать сложный и непонятный мир терминала. Сколько раз в те годы я ругался, мол да это же MS DOS какой-то, ничего не видно, ничего не понятно, сплошная деградация.

Но потихоньку появлялись знания, нарабатывался опыт и в какой-то момент графика в Linux перестала быть нужна. А потом стало приходить понимание, что все что нужно – всегда у тебя под рукой, вместе с теми самыми «манами, которые нужно курить». Без этих ваших интернетов и СМС.

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

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

И оказалось, что да, что CMD, оказывается, не столь убог, как казалось. А PowerShell так вообще открыл новые, неведомые прежде возможности.

После чего необходимость в разных простых и не очень утилитках и программках стала как-то сходить на нет. Особенно с развитием удаленной работы. Это сегодня ты за своим уютным рабочим местом, а завтра в чужой системе, где ничего этого нет и возможность ставить что-то свое варьируется от нежелательно, до запрещено.

Поэтому, разный полезный софт – это хорошо, уютно, удобно. Но это не должно заменять владение родными инструментами системы.

​​Особенности использования точек восстановления в Windows 10

Точки восстановления Windows появились в Windows XP и сразу завоевали популярность, особенно у простых пользователей, позволяя выполнить откат изменений и вернуть систему в рабочее состояние.

В Windows 7 – 8.1 этот инструмент получил дальнейшее развитие вместе со средой восстановления Windows, которая стала размещаться на отдельном, защищённом разделе, позволяя загрузить компьютер, не прибегая к сторонним инструментам.

В Windows 7, 8 и 8.1 создание точек восстановления включалось автоматически и точки создавались при установке драйверов, ПО, обновлений.

А вот пользователи Windows 10 могут быть неприятно удивлены, если не сказать иначе. Потому что сей неприятный «сюрприз» многие из них обнаружат только в аварийной ситуации.

О чем речь? А о том, что у Windows 10 может вообще не оказаться точек восстановления! Потому что система защиты будет выключена. И, в отличии от многих других ситуаций, Windows не будет спешить уведомить вас об этом прискорбном факте.

👆 Дело в том, что в Windows 10 точки восстановления автоматически включаются только если объем системного раздела превышает 128 ГБ.

Если вы выполнили обновление системы с Windows 7 или 8/8.1 и объем системного диска меньше 128 ГБ, то система защиты будет автоматически выключена, а существующие точки восстановления удалены.

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

Поэтому на системах с размером системного раздела менее 128 ГБ точки восстановления нужно включить самостоятельно и не забыть при этом выделить дисковое пространство. Иначе система защиты хоть и будет включена, но работать не будет.

Рекомендуемый объем выделяемого пространства для разделов менее 64 ГБ – 3%, для более емких – 5%, но не более 10 ГБ.

Небольшая подборка статей по Windows

Прежде всего коснемся темы LTSB/LTSC которая не дает покоя многим:

🔹 Чем является и чем не является Windows 10 LTSB/LTSC

Затем второй актуальный вопрос – встроенное ПО из магазина. Почему-то у многих прямо-таки навязчивая идея по поводу его удаления и при этом часто используются радикальные методы:

🔹 Предустановленное ПО в Windows 10 - мифы и реальность

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

🔹 Tiny 11 - дело ZverCD живет и торжествует

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

🔹 Создание образа Windows 10 с собственным набором предустановленного ПО и настройками меню Пуск

​​Сборки Windows – вчера, сегодня, завтра

Сборки Windows как массовое явление появились во времена Windows XP и занимались ими практически все те, кто по специфике работы сталкивался с частой установкой ОС.

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

По факту требовалось доустановить системные компоненты, такие как пакеты Visual C++, NET Framework, DirectX и набор патчей от самых актуальных сетевых угроз.

Далее нужна была установка прикладного ПО: проигрыватели, кодеки, утилиты для записи дисков, DC++ клиенты и т.д. и т.п.

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

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

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

В результате за этими сборками закрепилось народное название «г-сборки» и их использование стало ярким признаком непрофессионализма. Хотя, справедливости ради, ZverCD был далеко не худшим вариантом. Встречались разного рода «игровые» или «облегченные» сборки, в которых сборщики просто вырезали на свое усмотрение половину системы.

С выходом Windows 7 тенденция делать собственные сборки продолжилась, но акцент сместился с ПО на обновления. Потому что сети плотно вошли в повседневную жизнь, и эксплуатация не обновлённых систем стала небезопасной.

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

При этом интегрируемого в сборку прикладного ПО стало меньше. Причин тому было несколько.

Во-первых, в Windows 7 появилось достаточное количество встроенного ПО, закрывающего базовые потребности: запись CD, просмотр изображений и видео, работа со скриншотами и т.д. и т.д.

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

При этом количество «г-сборок» продолжало расти и множиться. А там кто был во что горазд, тем более что собирать собственные сборки на базе Windows 7 стало легче, а интернет стал доступнее, и теперь каждый суслик мог выступить в роли агронома.

Все поменялось с выходом Windows 10 и ее полугодовым планом выпуска новых версий. Система обновлений перешла на накопительную модель, а встроенное прикладное ПО стало закрывать подавляющее число задач.

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

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

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

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

Поэтому создание сборок современных систем – это или внутренние корпоративные сборки с автоматической установкой всего прикладного ПО. Либо изменить состав предустановленного ПО и предварительно настроить меню Пуск. Либо и то и другое вместе.

В остальных случаях создание собственных сборок современных ОС оправдано сугубо в исследовательских целях, ну либо вам не дают покоя лавры создателя очередной «г-сборки».

​​А давайте кого-нибудь заблокируем!

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

После чего сильно удивляются, когда узнают, что средствами только самого брандмауэра это сделать нельзя.

Почему? Давайте посмотрим, где у нас находится брандмауэр, а где логи. Условно цепочку мы можем построить так:

Сеть => Брандмауэр => Приложение => Лог

Классический брандмауэр работает на сетевом и транспортном уровне (L3 и L4) и все что он видит – это пакеты, которые бегают из сети к приложению и обратно.

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

Любой лог рассчитан прежде всего на чтение его человеком, а не машиной, поэтому работа с логом всегда требует индивидуального подхода.

Следующий момент, лог пишется приложением в некоторое хранилище, которое живет там же, где и приложение и никакого отношения к брандмауэру не имеет.

👆 Сообщения лога через брандмауэр не проходят!

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

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

Все, что мы сейчас можем – это делать какие-либо выводы по косвенным критериям. Но ни один из них не дает 100% гарантии нежелательной активности. Большинство протоколов обмениваются стандартными сообщениями фиксированной длинны и не видя содержимого сообщений нельзя сказать, что именно происходит.

Поэтому в основе любых алгоритмов лежат определенные допущения. Например, при обнаружении брутфорса протокола RDP мы исходили из того, что четко знаем сколько пакетов в состоянии NEW требуется для успешного установления соединения.

Затем выдвинули предположение, что если их количество с одного адреса источника в течении некоторого промежутка времени превышает некоторый лимит – то перед нами попытка подбора пароля.

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

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

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

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

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

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

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

​​Подборка материалов по Linux для начинающих

🔹 Linux - начинающим. Первое знакомство
🔹 Linux - начинающим. Работаем с файловой системой. Теория
🔹 Linux - начинающим. Работаем с файловой системой. Практика
🔹 Linux - начинающим. Управление пакетами в Debian и Ubuntu
🔹 Linux - начинающим. Управление пользователями и группами. Теория
🔹 Linux - начинающим. Управление пользователями и группами. Практика
🔹 Linux - начинающим. Потоки, перенаправление потоков, конвейер

Как установить и настроить?

🔹 Linux - начинающим. Установка и первоначальная настройка Debian 11 для сервера
🔹 Linux - начинающим. Установка и первоначальная настройка Ubuntu 22.04 LTS для сервера
🔹 Настройка языка и региональных стандартов в Ubuntu Server/Debian
🔹 Аpt-key is deprecated или управление ключами в современных выпусках Debian и Ubuntu
🔹 Установка российских корневых сертификатов в Debian и Ubuntu
🔹 Используем APT Pinning для закрепления пакетов в Debian и Ubuntu

Продолжение следует...

​​Hairpin NAT, обратный прокси и двойной горизонт DNS

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

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

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

Второй момент: один сервис – один поддомен, даже если все они ведут на один и тот же внешний адрес. Почему? Да потому что в сети это могут быть различные хосты и тогда у вас возникнут проблемы.

Теперь рассмотрим способы доступа из внешней сети к ресурсам внутренней.

🔹 Самый простой – это проброс портов. Но его нужно сделать правильно, в терминах Mikrotik это называется Hairpin NAT, но данная проблема актуальна и для любых иных систем.

Обычно проброс портов осуществляется правилом с DNAT, которое заменяет адрес назначение и (при необходимости) порт пакета. При этом адрес источника никаких преобразований не испытывает.

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

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

Но клиент не ждет ответа от локального сервера и поэтому такой пакет будет отброшен и ничего работать не будет. Чтобы избежать такой проблемы следует выполнить дополнительно действие SNAT и заменить адрес источника пакета на внутренний адрес роутера.

Подробнее можно прочитать в нашей статье: Проброс портов и Hairpin NAT в роутерах Mikrotik

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

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

Популярным обратным прокси является веб-сервер NGINX и пример такого его использования можно найти в статье: Настраиваем NGINX как обратный прокси для веб-публикации 1С:Предприятие

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

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

Именно это и дает нам двойной горизонт DNS, смысл его заключается в том, что внутренний DNS-сервер отдает для доменных имен сервисов внутренние адреса и клиент будет взаимодействовать напрямую с локальным сервером.

Оказавшись за пределами сети он получит от публичных DNS внешний адрес и будет работать через проброс или обратный прокси.

При использовании проброса вместе с двойным горизонтом DNS следует избегать проброса на другой номер порта. В этом случае лучше поменять порт самого сервиса.

С примером настройки двойного горизонта DNS можно ознакомиться здесь: Настраиваем двойной горизонт DNS (Split DNS) на роутерах Mikrotik

Как устроен IT-бизнес изнутри — без иллюзий и прикрас
Я — CTO и IT-консультант. Веду канал, где пишу о том, как действительно работают команды, технологии и IT-системы.
Разбираю на конкретных кейсах:
— Почему разваливаются проекты?
— Что происходит внутри eCommerce и EdTech?
— Как выстроить сильную команду и не сгореть?
— Какие ошибки ИТ стоят вам денег?

Если хотите разбираться глубже и видеть картину изнутри — подписывайтесь. Только полезное, без воды, продажи курсов и инфоцыганства.
👉 Авторский канал ИТ Директора

Подборка статей по Linux

В прошлой нашей заметке мы дали ссылки на статьи нашего базового цикла для начинающих, и материалы по установке и настройке: https://yangx.top/interface31/4460

Сегодня продолжим, затронув другие темы.

Как получить информацию о системе?

🔹 Как быстро разобраться в Debian/Ubuntu если вы видите систему первый раз
🔹 Как узнать температуру процессора и накопителей
🔹 Как получить информацию об оборудовании ПК
🔹 Как узнать чем занято место на диске?
🔹 Как узнать оставшийся ресурс SSD в Linux

Как именно это работает?

🔹 Что такое Load Average и какую информацию он несет
🔹 Что такое пространства подкачки и как они работают
🔹Что такое OOM Killer и как он работает

Продолжение следует...

​​И снова про отечественные сертификаты

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

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

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

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

За ним последовал Symantec, тоже не последний игрок на рынке, и хотя его прегрешения были куда попроще, но это ему тоже не помогло.

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

И инициаторами вынесения вотума недоверия будет не общественность и не активисты, а крупные игроки этого рынка, пользующиеся его услугами, тот же Сбербанк.

Так что мы не видим никаких разумных предпосылок не доверять сертификатам Минцифры по различным надуманным причинам.

Но это была теория, а теперь перейдем к практике. Основная пугалка адептов секты свидетелей Товарища Майора гласит, что сразу после установки сертификата вы делаете весь свой трафик доступным тому самому Товарищу Майору.

Так ли это? Конечно же не так. Что делает удостоверяющий центр Минцифры выдавая сертификат тому же Сбербанку? Прежде всего он удостоверяется, что за сертификатом пришел именно Сбербанк и подписывает выданный сертификат своим закрытым ключом.

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

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

Но в реальности все еще более интересно, открыв свойства защищенного соединения в браузере, например, для того же Сбербанка, мы увидим строку наподобие:

Key exchange ECDHE_RSA with P-256

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

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

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

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

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

Хотя потенциальному Товарищу Майору гораздо проще пойти договориться с Касперским, чем мутить с нуля свой собственный MitM.

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