Записки IT специалиста

​​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

​​Подборка материалов по 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

​​Особенности использования точек восстановления в 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 2003 еще не имел сервис-паков. Эпоха DOS стремительно уходила в прошлое, а новые версии Windows радовали новыми и удобными графическими интерфейсами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Новое в настройках OpenVPN в Mikrotik

Начиная с выпуска RouterOS 7.18 многие пользователи задались вопросом: а куда исчезла кнопка OVPN Server на закладке PPP – Interface.

А ее теперь там нет, вместо этого появилась отдельная вкладка OVPN Servers, которая позволяет теперь настроить более одного экземпляра OpenVPN сервера.

Данное нововведение можно оценить сугубо положительно, так как OpenVPN был и остается наиболее распространенным корпоративным VPN, а взаимоотношения его и Mikrotik были сложными.

Что это дает? Прежде всего позволяет разнести экземпляры по разным протоколам. Скажем, перевести пользователей на UDP, а остающиеся на RouterOS 6 роутеры оставить на единственно доступном им TCP.

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

👍 В общем – инструмент есть, а применение ему найдем. А тенденция развития и улучшения возможностей OpenVPN в RouterOS только радует.

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

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

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

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

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

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

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

​​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

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

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

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

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

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

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

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

​​Распространяемые компоненты 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 к постоянному переделыванию собственных порталов и удалению старых версий мы бы советовали выкачать все пакеты и хранить их локально.

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

Всех узнали?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как временно отключить пользователя OpenVPN

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

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

👉 Как это сделать рассказано в нашей статье: Отзыв сертификатов пользователей в OpenVPN

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

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

Понятно, что отзыв сертификата с последующим перевыпуском тут не подходит. В этом случае мы будем использовать файлы client-config-dir (ccd), которые позволяют передавать клиентам настройки в индивидуальном порядке.

Расположение таких файлов определяется одноименной опцией конфигурационного файла client-config-dir, а для отключения нам достаточно выполнить команду:

echo “disable” >> /etc/openvpn/ccd/certname

Где certname – имя сертификата конечного пользователя, а /etc/openvpn/ccd – типовое расположение client-config-dir.

Для того, чтобы снова включить клиента достаточно закомментировать строку disable в указанном файле.

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

Сегодня выходной, поэтому еще немного вопросов не технических, но близких к этому.

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

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

1️⃣ Бригада крепких, физически здоровых мужиков, которые адекватно пояснили чего они могут, чего не могут и показали результаты своих других работ.

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

3️⃣ Некое светило из очень важного и секретного НИИ (или не НИИ, секретно ведь), который десятки лет строил секретные бани в секретных местах и хорошо знает, как их надо строить, какие стандарты соблюдать, какие есть правила и регламенты, кого нужно назначить крайним, и кто будет виноват если баню построить почему-то не получится.

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

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

🤫 Кому из них вы доверите заняться постройкой бани?

👇👇👇 Ответы в опросе ниже, там же оставляем комментарии.

​​Сеанс черной магии с разоблачением

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

Начнем с просто примера: 192.168.1.100 с маской 255.255.255.0 или /24

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

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

128 | 64 | 32 | 16 | 8 | 4 | 2 | 1

Теперь берем первый октет, проверяем, помещается ли первое число 128 в 192? Помещается, ставим 1. Затем вычитаем из 192 число 128, получаем 64. Проверяем со вторым числом, помещается, снова ставим 1 и вычитаем из остатка 64.

У нас остался ноль, в который не помещаются остальные числа, там проставляем ноли.

В итоге адрес 192.168.1.100 мы запишем как

11000000 10101000 00000001 01100100

Теперь маска, также переводим ее в двоичный вид. Но если с 255.255.255.0 все понятно, то как понимать /24? А просто, 24 обозначает что маска содержит 24 единицы, т.е. вам даже не нужно ничего переводить:

/24  = 255.255.255.0 = 11111111 11111111 11111111 00000000

А теперь начинается настоящая двоичная магия, записываем адрес и маску друг под другом:

11000000 10101000 00000001 01100100
11111111 11111111 11111111 00000000

Те части адреса, которые покрываются маской являются адресом сети, а те, которые не попадают в маску – адресом узла.

Таким образом у нас адрес сети (все что не попадает под маску меняем нолями):

11000000 10101000 00000001 00000000

Что соответствует 192.168.1.0

Минимальным адресом сети будет:

11000000 10101000 00000001 00000001 = 192.168.1.1

Максимальным:

11000000 10101000 00000001 11111110 = 192.168.1.254

А последний доступный адрес в сети является широковещательным:

11000000 10101000 00000001 11111111 = 192.168.1.255

Теперь поменяем маску на /23 или 255.255.254.0 и посмотрим, что изменится:

11000000 10101000 00000001 01100100
11111111 11111111 11111110 00000000

Адрес сети у нас та часть, которая покрывается маской, остальное заменяем нулями:

11000000 10101000 00000000 00000000 = 192.168.0.0

Минимальный адрес:

11000000 10101000 00000000 00000001 = 192.168.0.1

Максимальный адрес:

11000000 10101000 00000001 11111110 = 192.168.1.254

Широковещательный адрес:

11000000 10101000 00000001 11111111 = 192.168.1.255

А теперь вернемся к примеру из пятничного вопроса:

5.6.7.0/23

00000101 00000110 00000111 00000000
11111111 11111111 11111110 00000000

Адрес сети:

00000101 00000110 00000110 00000000 = 5.6.6.0

Минимальный адрес:

00000101 00000110 00000110 00000001 = 5.6.6.1

Максимальный адрес:

00000101 00000110 00000111 11111110  = 5.6.7.254

Широковещательный адрес:

00000101 00000110 00000111 11111111  = 5.6.7.255

Таким образом в результате таких вот магических манипуляций мы выяснили, что 5.6.7.0/23 является адресом узла сети.

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

Почему? Расписываем в двоичном виде адрес и маску и понимаем, что сети с адресами 5.6.6.0/23 и 5.6.8.0/23 существовать могут, а вот сеть с адресом 5.6.7.0/23 – нет.