Forwarded from Записки IT специалиста
Что будет если мы выполним chmod -R 777 / с правами суперпользователя?
Ну казалось бы, чего такого, ну дадим всем полные права, что может пойти не так? Ну про безопасность понятно…
Но с этого момента пойдет не так решительно все. Очень многие службы и системные утилиты требуют определенных прав доступа на файлы, к таким файлам могут относится ключи, сертификаты, конфигурационные файлы, отвечающие за безопасность и т.д. и т.п.
Поэтому такие службы будут работать до рестарта и более не запустятся, сразу откажут такие утилиты как sudo, также вы не сможете войти с использованием ключа по SSH.
А еще вспоминаем, что 777 – это на самом деле 0777, т.е. легким движением руки мы снесем все SUID, SGID и Sticky bit. После чего откажет большая часть системных утилит и наступит неуправляемый хаос в /tmp.
Сама же система будет работать и даже загружаться, но по факту мы ее сделали полностью неработоспособной. Самое лучшее что мы можем сделать – это скопировать данные и переустановить ее.
Ну казалось бы, чего такого, ну дадим всем полные права, что может пойти не так? Ну про безопасность понятно…
Но с этого момента пойдет не так решительно все. Очень многие службы и системные утилиты требуют определенных прав доступа на файлы, к таким файлам могут относится ключи, сертификаты, конфигурационные файлы, отвечающие за безопасность и т.д. и т.п.
Поэтому такие службы будут работать до рестарта и более не запустятся, сразу откажут такие утилиты как sudo, также вы не сможете войти с использованием ключа по SSH.
А еще вспоминаем, что 777 – это на самом деле 0777, т.е. легким движением руки мы снесем все SUID, SGID и Sticky bit. После чего откажет большая часть системных утилит и наступит неуправляемый хаос в /tmp.
Сама же система будет работать и даже загружаться, но по факту мы ее сделали полностью неработоспособной. Самое лучшее что мы можем сделать – это скопировать данные и переустановить ее.
👍54😁3
Копируй, вставляй и молись
Не так давно в классическом труде UNIX® and Linux® System Administration Handbook в очередной раз наткнулся на описание данного метода, который авторы метко назвали «копируй, вставляй и молись».
В переводе данный абзац будет выглядеть так:
Не стесняйтесь адаптировать код существующих скриптов для своих нужд. Но не занимайтесь программированием по принципу «копируй, вставляй и молись», когда вы не понимаете код. Найдите время, чтобы разобраться в этом. Это время никогда не тратится зря.
Но, к сожалению, данный метод использовался, используется и будет продолжать использоваться со всеми вытекающими отсюда последствиями.
И это относится не только к написанию скриптов, но и к файлам конфигурации, когда администраторы копируют чужие примеры даже не задумываясь.
Спрашиваешь: «а зачем тут это?»
В ответ пожимают плечами и путано поясняют что так было написано в одной умной инструкции.
К этой же порочной методике можно отнести и бездумное копирование инструкций, а также любимый многими «вид спорта» - настройка чего-либо с помощью чужих готовых скриптов.
Последний вариант вообще вне конкуренции по возможным деструктивным последствиям, потому как в статье автор хотя бы комментирует свои действия, и вы можете понять надо ли это в вашем случае или не надо, то скрипт может просто сделать все молча и по-своему.
Неоднократно сталкивались с товарищами, которые приходят за помощью с жалобой, мол поставил продукт А, но ничего не работает. А на уточняющие вопросы поясняют, что ничего не знают и дают ссылку на скрипт.
Бездумное следование инструкциям ничуть не лучше, по сути, это выходит тот же самый скрипт, но в более простом варианте, когда команды вбивает оператор. Его роль тут сводится просто к скопировал-вставил и его спокойно можно заменить дрессированной обезьяной. 🐵
Поэтому не стоит уподобляться братьям нашим меньшим. Делаем по инструкции – стараемся понять каждое действие, назначение всех используемых опций, значений настроек и всегда сопоставляем их с нашими текущими реалиями.
Надо нам это? Не надо? А почему здесь такое число? На что оно влияет.
Да, вы потратите больше времени, но это время не будет потрачено даром. Вы начнете хотя бы на базовом уровне разбираться в конфигурации и принципе работы продукта, а также сразу наметите возможные проблемы и места, которые за эти участки отвечают.
Что касается чужих скриптов, то их использовать, конечно можно, но крайне нежелательно до тех пор, пока вы не сможете читать их с листа и понимать, что они делают и зачем. И не важно, насколько популярен этот скрипт, сколько у него звезд на гитхабе и т.д. и т.п.
Почему? Да потому что всегда может что-то пойти не так и если скрипт для вас черный ящик, то вы даже не поймете, где проблема и в чем. После чего все равно придется либо изучать его, либо идти просить помощи.
И это мы еще не говорим о том, что автор может иметь собственные представления «о прекрасном» и использовать нестандартные пути, приемы, допускать ошибки, прибиваться гвоздями к версиям и т.д. и т.п.
При определенных условиях работа скрипта может вообще оказаться деструктивной, но не со злого умысла автора, а просто потому, что он пропустил некоторые проверки или вообще не предусмотрел вашего сценария.
При этом мы понимаем, что, даже прочитав данную заметку многие пожмут плечами и пойдут работать методом «копируй, вставляй и молись» дальше. Потому что он в целом работает, а что касается дальнейшей эксплуатации: упремся – разберемся.
Но только вот профессиональному росту специалиста он никак не содействует и об этом нужно помнить если не хотите чтобы вас потом заменила дрессированная обезьяна в виде столь популярного ныне искусственного интеллекта.
Не так давно в классическом труде UNIX® and Linux® System Administration Handbook в очередной раз наткнулся на описание данного метода, который авторы метко назвали «копируй, вставляй и молись».
В переводе данный абзац будет выглядеть так:
Не стесняйтесь адаптировать код существующих скриптов для своих нужд. Но не занимайтесь программированием по принципу «копируй, вставляй и молись», когда вы не понимаете код. Найдите время, чтобы разобраться в этом. Это время никогда не тратится зря.
Но, к сожалению, данный метод использовался, используется и будет продолжать использоваться со всеми вытекающими отсюда последствиями.
И это относится не только к написанию скриптов, но и к файлам конфигурации, когда администраторы копируют чужие примеры даже не задумываясь.
Спрашиваешь: «а зачем тут это?»
В ответ пожимают плечами и путано поясняют что так было написано в одной умной инструкции.
К этой же порочной методике можно отнести и бездумное копирование инструкций, а также любимый многими «вид спорта» - настройка чего-либо с помощью чужих готовых скриптов.
Последний вариант вообще вне конкуренции по возможным деструктивным последствиям, потому как в статье автор хотя бы комментирует свои действия, и вы можете понять надо ли это в вашем случае или не надо, то скрипт может просто сделать все молча и по-своему.
Неоднократно сталкивались с товарищами, которые приходят за помощью с жалобой, мол поставил продукт А, но ничего не работает. А на уточняющие вопросы поясняют, что ничего не знают и дают ссылку на скрипт.
Бездумное следование инструкциям ничуть не лучше, по сути, это выходит тот же самый скрипт, но в более простом варианте, когда команды вбивает оператор. Его роль тут сводится просто к скопировал-вставил и его спокойно можно заменить дрессированной обезьяной. 🐵
Поэтому не стоит уподобляться братьям нашим меньшим. Делаем по инструкции – стараемся понять каждое действие, назначение всех используемых опций, значений настроек и всегда сопоставляем их с нашими текущими реалиями.
Надо нам это? Не надо? А почему здесь такое число? На что оно влияет.
Да, вы потратите больше времени, но это время не будет потрачено даром. Вы начнете хотя бы на базовом уровне разбираться в конфигурации и принципе работы продукта, а также сразу наметите возможные проблемы и места, которые за эти участки отвечают.
Что касается чужих скриптов, то их использовать, конечно можно, но крайне нежелательно до тех пор, пока вы не сможете читать их с листа и понимать, что они делают и зачем. И не важно, насколько популярен этот скрипт, сколько у него звезд на гитхабе и т.д. и т.п.
Почему? Да потому что всегда может что-то пойти не так и если скрипт для вас черный ящик, то вы даже не поймете, где проблема и в чем. После чего все равно придется либо изучать его, либо идти просить помощи.
И это мы еще не говорим о том, что автор может иметь собственные представления «о прекрасном» и использовать нестандартные пути, приемы, допускать ошибки, прибиваться гвоздями к версиям и т.д. и т.п.
При определенных условиях работа скрипта может вообще оказаться деструктивной, но не со злого умысла автора, а просто потому, что он пропустил некоторые проверки или вообще не предусмотрел вашего сценария.
При этом мы понимаем, что, даже прочитав данную заметку многие пожмут плечами и пойдут работать методом «копируй, вставляй и молись» дальше. Потому что он в целом работает, а что касается дальнейшей эксплуатации: упремся – разберемся.
Но только вот профессиональному росту специалиста он никак не содействует и об этом нужно помнить если не хотите чтобы вас потом заменила дрессированная обезьяна в виде столь популярного ныне искусственного интеллекта.
👍42👏2❤1
Проверяем DNS-записи при помощи PowerShell
Данный метод не является заменой привычным утилитам, например, nslookup, но он показывает возможности PowerShell и будет полезен всем, кто использует данный язык для автоматизации или изучает его.
Для разрешения доменных имен в PowerShell есть командлет Resolve-DnsName, использовать его достаточно просто, полный синтаксис команды выглядит так:
Но его можно упростить:
Ответ зависит от типа записи, для A вы просто получите адрес, а для CNAME результатом будет доменное имя, на которое ссылается запись. Ниже будет приведена информация о полученном доменном имени и разрешение его в IP-адрес.
Это довольно тонкий момент, потому что тот же nslookup всегда выводит второй строкой адрес, здесь же результатом работы может быть как адрес, так и иное доменное имя.
При этом, учитывая объектную структуру PowerShell, такой результат легче поддается разбору и анализу, также сразу будет указан тип записи в отдельном поле.
Для получения записей других типов дополнительно используйте ключ:
Результатом вывода для MX, если записи настроены правильно, вы получите одно или несколько доменных имен. Их разрешение в IP-адреса будет приведено ниже в выводе.
Если вам нужно получить результат от определенного сервера, то добавьте ключ:
А теперь несколько полезных опций, которые могут пригодиться при диагностике и разрешении проблем:
Данный ключ предписывает выполнить DNS-запрос игнорируя файлы hosts, локальный кеш, широковещательные протоколы и т.д.
Наоборот, выдаст запрос из локального кеша, что полезно для диагностики, если есть подозрения на неверную работу кеша.
Указанный ключ проигнорирует локальный файл hosts, его следует использовать если есть подозрение, что указанный домен переназначен локально.
Это далеко не все возможности командлета, а только самые полезные. Больше информации вы можете найти в документации: https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname?view=windowsserver2022-ps
Данный метод не является заменой привычным утилитам, например, nslookup, но он показывает возможности PowerShell и будет полезен всем, кто использует данный язык для автоматизации или изучает его.
Для разрешения доменных имен в PowerShell есть командлет Resolve-DnsName, использовать его достаточно просто, полный синтаксис команды выглядит так:
Resolve-DnsName -Name "example.com"
Но его можно упростить:
Resolve-DnsName example.com
Ответ зависит от типа записи, для A вы просто получите адрес, а для CNAME результатом будет доменное имя, на которое ссылается запись. Ниже будет приведена информация о полученном доменном имени и разрешение его в IP-адрес.
Это довольно тонкий момент, потому что тот же nslookup всегда выводит второй строкой адрес, здесь же результатом работы может быть как адрес, так и иное доменное имя.
При этом, учитывая объектную структуру PowerShell, такой результат легче поддается разбору и анализу, также сразу будет указан тип записи в отдельном поле.
Для получения записей других типов дополнительно используйте ключ:
Resolve-DnsName example.com -Type MX
Результатом вывода для MX, если записи настроены правильно, вы получите одно или несколько доменных имен. Их разрешение в IP-адреса будет приведено ниже в выводе.
Если вам нужно получить результат от определенного сервера, то добавьте ключ:
Resolve-DnsName example.com -Type MX -Server 8.8.8.8
А теперь несколько полезных опций, которые могут пригодиться при диагностике и разрешении проблем:
Resolve-DnsName example.com -DnsOnly
Данный ключ предписывает выполнить DNS-запрос игнорируя файлы hosts, локальный кеш, широковещательные протоколы и т.д.
Resolve-DnsName example.com -CacheOnly
Наоборот, выдаст запрос из локального кеша, что полезно для диагностики, если есть подозрения на неверную работу кеша.
Resolve-DnsName example.com -NoHostsFile
Указанный ключ проигнорирует локальный файл hosts, его следует использовать если есть подозрение, что указанный домен переназначен локально.
Это далеко не все возможности командлета, а только самые полезные. Больше информации вы можете найти в документации: https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname?view=windowsserver2022-ps
1👍53🔥2👏1🤬1
С Днем радио!!!
Сегодня мой профессиональный праздник и не только мой, но и многих коллег, особенно старшего возраста.
Это сейчас путь в IT открыт сразу и напрямую, в наше время путь к вычислительной технике начинался с радиолюбительства и программируемых калькуляторов.
Позже все это плавно перетекало в наиболее близкие профессии, связанные с электроникой. А электроника в свое время была неразлучно связана с связью (вот такой вот каламбур вышел).
И, следует сказать, радиолюбительское прошлое и профильное образование связиста сильно пригодилось впоследствии. Прежде всего инженерным мышлением, умением читать схемы и навыками диагностики и выявления неисправностей.
Появившиеся позднее компьютеры кто-то сделал помощниками в инженерных расчетах, а кто-то связал с ними свою профессию.
Поэтому всех причастных, настоящих и бывших связистов, хотя связисты, а тем более радиолюбители, бывшими не бывают, с праздником!
🥃🥃🥃
Сегодня мой профессиональный праздник и не только мой, но и многих коллег, особенно старшего возраста.
Это сейчас путь в IT открыт сразу и напрямую, в наше время путь к вычислительной технике начинался с радиолюбительства и программируемых калькуляторов.
Позже все это плавно перетекало в наиболее близкие профессии, связанные с электроникой. А электроника в свое время была неразлучно связана с связью (вот такой вот каламбур вышел).
И, следует сказать, радиолюбительское прошлое и профильное образование связиста сильно пригодилось впоследствии. Прежде всего инженерным мышлением, умением читать схемы и навыками диагностики и выявления неисправностей.
Появившиеся позднее компьютеры кто-то сделал помощниками в инженерных расчетах, а кто-то связал с ними свою профессию.
Поэтому всех причастных, настоящих и бывших связистов, хотя связисты, а тем более радиолюбители, бывшими не бывают, с праздником!
🥃🥃🥃
👍89🔥11💯6🌭1
Как полностью удалить PPA и восстановить состояние системы
Одним из нововведений Ubuntu стала система персональных архивов пакетов (Personal Package Arhive - PPA), которые позволяли разработчикам легко создавать собственные репозитории, а пользователям их подключать и использовать.
В те времена это был огромный шаг вперед и сильно продвинул Ubuntu как простую и удобную в эксплуатации Linux систему.
Но в использовании PPA кроме очевидных плюсов есть столь же очевидные минусы. А именно – это репозиторий, а любой сторонний репозиторий это отличный шанс нарушить стабильную работу системы.
Вместе с нужной вам программой из PPA могут обновиться какие-то системные библиотеки или быть заменены какие-то другие компоненты системы, что может привести к самым различным последствиям.
Мы, конечно, можем отключить PPA-репозиторий, но только проблемы это не решает, установленные им пакеты останутся в системе и далеко не факт, что простое их удаление вам поможет.
Для того, чтобы не только полностью удалить PPA-репозиторий, но и полностью восстановить состояние системы предназначена утилита
Применять ее очень просто, достаточно указать наименование PPA в формате:
Это стандартный формат и если вы добавляли PPA командой:
То для полного удаления и восстановления используйте:
Если же вы не знаете точного имени PPA, то получить его можно из адреса репозитория, найти файлы с такими адресами вы можете в
Интересующая нас информация находится сразу за
Несмотря на то, что данная утилита позволяет нам достаточно просто откатить все изменения внесенные PPA следует понимать, что PPA – это достаточно опасный способ установки стороннего ПО и на сегодняшний день существуют современные и безопасные варианты, такие как Snap или Flatpak.
Одним из нововведений Ubuntu стала система персональных архивов пакетов (Personal Package Arhive - PPA), которые позволяли разработчикам легко создавать собственные репозитории, а пользователям их подключать и использовать.
В те времена это был огромный шаг вперед и сильно продвинул Ubuntu как простую и удобную в эксплуатации Linux систему.
Но в использовании PPA кроме очевидных плюсов есть столь же очевидные минусы. А именно – это репозиторий, а любой сторонний репозиторий это отличный шанс нарушить стабильную работу системы.
Вместе с нужной вам программой из PPA могут обновиться какие-то системные библиотеки или быть заменены какие-то другие компоненты системы, что может привести к самым различным последствиям.
Мы, конечно, можем отключить PPA-репозиторий, но только проблемы это не решает, установленные им пакеты останутся в системе и далеко не факт, что простое их удаление вам поможет.
Для того, чтобы не только полностью удалить PPA-репозиторий, но и полностью восстановить состояние системы предназначена утилита
ppa-purge, которая входит в стандартный репозиторий Ubuntu.Применять ее очень просто, достаточно указать наименование PPA в формате:
ppa:user_name/ppa_name
Это стандартный формат и если вы добавляли PPA командой:
add-apt-repository ppa:andrew-crew-kuznetsov/xneur-stable
То для полного удаления и восстановления используйте:
ppa-purge ppa:andrew-crew-kuznetsov/xneur-stable
Если же вы не знаете точного имени PPA, то получить его можно из адреса репозитория, найти файлы с такими адресами вы можете в
/etc/apt/sources.list.d, в нашем случае там будет:https://ppa.launchpadcontent.net/andrew-crew-kuznetsov/xneur-stable/ubuntu/ jammy main
Интересующая нас информация находится сразу за
ppa.launchpadcontent.net, в нашем случае это andrew-crew-kuznetsov/xneur-stable.Несмотря на то, что данная утилита позволяет нам достаточно просто откатить все изменения внесенные PPA следует понимать, что PPA – это достаточно опасный способ установки стороннего ПО и на сегодняшний день существуют современные и безопасные варианты, такие как Snap или Flatpak.
👍25👀3❤1
Алиасы в PowerShell
Многие, кто только начинает изучать PowerShell, особенно перейдя из мира Linux, жалуются на его многословность, что может быть неудобно, если вы используете PS непосредственно для администрирования системы.
Да, это так, но этому есть свои основания.
Классические UNIX-оболочки создавались в те далекие и светлые времена, когда компьютеры были большие, объемы памяти маленькие, а скорости передачи данных – медленные. Все это заставляло биться буквально за каждый байт.
Кроме того, в те времена не было ни интернета с гуглом, ни разных синтаксис-помощников, поэтому команды старались делать попроще, чтобы запоминать было легче, пренебрегая удобством чтения кода и наглядной очевидностью.
Да, bash прост, но прост для того, кто в нем постоянно работает. Если это не так, то возможны разные веселые, или не очень, затруднения.
Например, команда:
Еще вполне читабельна и если мы помним, что такое grep, то без труда догадаемся, что мы ищем строку "
И если вы не помните синтаксис grep вам придется непросто. Особенно если нужно изменить часть команды.
Поэтому PowerShell, который разрабатывался значительно позже, обильно полили синтаксическим сахаром, справедливо предполагая, что люди тоже могут читать программы. И не только могут, но и будут.
Поэтому тот же аналог grep в PowerShell выглядит так:
Да, многословно, но даже далекий от PowerShell человек поймет, что мы выбираем строки, содержащие текст
И если мы занимаемся написанием скриптов, то такая многословность нам только в плюс, так как сильно облегчает читаемость кода человеком.
А скрипты в голом блокноте давно уже никто не пишет, есть удобные среды разработки с автодополнением, подсветкой синтаксиса, синтаксис-помощниками и прочими плюшками.
Но как быть, если мы используем PowerShell для административных нужд, каждый раз набирать полное имя команды и ключи в консоли, даже с автодополнением, может быть утомительно.
А вот как раз для этого придумали алиасы. Полный список алиасов команд PowerShell можно посмотреть, выполнив команду:
Если нас интересует конкретная команда, то следует набрать:
А если, наоборот, расшифровать алиас, то следует выполнить:
Также можно создавать свои алиасы, для этого используйте команду:
Таким образом мы легко можем настроить среду согласно своих привычек или просто писать в привычном стиле:
А для тех, кто свои лучше годы отдал работе с Windows, напоминаем, что PowerShell давно доступен и на платформе Linux.
Многие, кто только начинает изучать PowerShell, особенно перейдя из мира Linux, жалуются на его многословность, что может быть неудобно, если вы используете PS непосредственно для администрирования системы.
Да, это так, но этому есть свои основания.
Классические UNIX-оболочки создавались в те далекие и светлые времена, когда компьютеры были большие, объемы памяти маленькие, а скорости передачи данных – медленные. Все это заставляло биться буквально за каждый байт.
Кроме того, в те времена не было ни интернета с гуглом, ни разных синтаксис-помощников, поэтому команды старались делать попроще, чтобы запоминать было легче, пренебрегая удобством чтения кода и наглядной очевидностью.
Да, bash прост, но прост для того, кто в нем постоянно работает. Если это не так, то возможны разные веселые, или не очень, затруднения.
Например, команда:
grep error error.log Еще вполне читабельна и если мы помним, что такое grep, то без труда догадаемся, что мы ищем строку "
error" в файле error.log. Но расширение не является обязательным атрибутом файла и поэтому мы вполне можем встретить:grep error error
И если вы не помните синтаксис grep вам придется непросто. Особенно если нужно изменить часть команды.
Поэтому PowerShell, который разрабатывался значительно позже, обильно полили синтаксическим сахаром, справедливо предполагая, что люди тоже могут читать программы. И не только могут, но и будут.
Поэтому тот же аналог grep в PowerShell выглядит так:
Select-String -Pattern "error" -Path .\errorДа, многословно, но даже далекий от PowerShell человек поймет, что мы выбираем строки, содержащие текст
“error” из файла .\error. И если мы занимаемся написанием скриптов, то такая многословность нам только в плюс, так как сильно облегчает читаемость кода человеком.
А скрипты в голом блокноте давно уже никто не пишет, есть удобные среды разработки с автодополнением, подсветкой синтаксиса, синтаксис-помощниками и прочими плюшками.
Но как быть, если мы используем PowerShell для административных нужд, каждый раз набирать полное имя команды и ключи в консоли, даже с автодополнением, может быть утомительно.
А вот как раз для этого придумали алиасы. Полный список алиасов команд PowerShell можно посмотреть, выполнив команду:
Get-AliasЕсли нас интересует конкретная команда, то следует набрать:
Get-Alias -Definition Select-StringА если, наоборот, расшифровать алиас, то следует выполнить:
Get-Alias slsТакже можно создавать свои алиасы, для этого используйте команду:
Set-Alias -Name grep -Value Select-StringТаким образом мы легко можем настроить среду согласно своих привычек или просто писать в привычном стиле:
sls error errorА для тех, кто свои лучше годы отдал работе с Windows, напоминаем, что PowerShell давно доступен и на платформе Linux.
👍34🤔9🔥1😱1🤝1
И еще немного про алиасы в PowerShell
PowerShell предлагает большой набор встроенных алиасов, про них мы подробно писали в нашей прошлой заметке.
И предназначены они сугубо для интерактивного использования внутри командной оболочки, т.е. для сокращения руками вводимых команд и упрощения их запоминания, ключи, между прочим, тоже успешно можно пропускать, если располагать опции в надлежащем порядке.
Это как раз решает проблему многословности PowerShell при интерактивном использовании.
Можно ли создавать и применять в проде свои алиасы? Можно и даже нужно, если использовать их по назначению, а именно для интерактивной работы в консоли.
Созданные алиасы без проблем можно выгружать и загружать на другой машине, для этого следует использовать команды
Поэтому у грамотного администратора не будет проблемы с созданными алиасами на новой системе, равно как и не будет их у человека, про данные алиасы не знающего.
А вот чего не стоит делать с алиасами не при каких обстоятельствах – это тащить их в скрипты. Скрипты давно никто на коленке в чистом блокноте не пишет, а любая среда разработки как минимум содержит подсказки и автодополнения, что позволяет быстро и удобно писать код с использованием полного синтаксиса.
Также в скриптах следует обязательно указывать все ключи, даже если их можно пропустить. Это не повлияет на работу, но положительно скажется на читабельности кода вашими коллегами или вами через некоторое время.
И, следует отметить, что многие упреки в неудобности и многословности PowerShell проистекают именно от незнания и попытки напрямую перенести на него предыдущий пользовательский опыт, не изучая возможности языка.
А возможность использовать короткую и немногословную нотацию у него есть, для чего нужно просто ознакомиться со списком встроенных алиасов.
PowerShell предлагает большой набор встроенных алиасов, про них мы подробно писали в нашей прошлой заметке.
И предназначены они сугубо для интерактивного использования внутри командной оболочки, т.е. для сокращения руками вводимых команд и упрощения их запоминания, ключи, между прочим, тоже успешно можно пропускать, если располагать опции в надлежащем порядке.
Это как раз решает проблему многословности PowerShell при интерактивном использовании.
Можно ли создавать и применять в проде свои алиасы? Можно и даже нужно, если использовать их по назначению, а именно для интерактивной работы в консоли.
Созданные алиасы без проблем можно выгружать и загружать на другой машине, для этого следует использовать команды
Export-Alias и Import-Alias.Поэтому у грамотного администратора не будет проблемы с созданными алиасами на новой системе, равно как и не будет их у человека, про данные алиасы не знающего.
А вот чего не стоит делать с алиасами не при каких обстоятельствах – это тащить их в скрипты. Скрипты давно никто на коленке в чистом блокноте не пишет, а любая среда разработки как минимум содержит подсказки и автодополнения, что позволяет быстро и удобно писать код с использованием полного синтаксиса.
Также в скриптах следует обязательно указывать все ключи, даже если их можно пропустить. Это не повлияет на работу, но положительно скажется на читабельности кода вашими коллегами или вами через некоторое время.
И, следует отметить, что многие упреки в неудобности и многословности PowerShell проистекают именно от незнания и попытки напрямую перенести на него предыдущий пользовательский опыт, не изучая возможности языка.
А возможность использовать короткую и немногословную нотацию у него есть, для чего нужно просто ознакомиться со списком встроенных алиасов.
👍27🥱3
Учимся работать со Snap
Почему-то, как только речь заходит про Snap у многих системных администраторов включается режим «не читал – но осуждаю» при котором Snap наделяется массой отрицательных качеств и чуть ли не подлежит немедленному выпиливанию из системы.
В тоже время Snap является универсальным форматом пакетов, созданным компанией Canonical первоначально для Ubuntu, но получившим широкое распространение и в других дистрибутивах.
Главной особенностью snap-пакетов является их самодостаточность, они содержат как нужное приложение, так и все основные зависимости к нему, что ускоряет распространение приложений и снижает возможные конфликты с другим ПО.
Поэтому перед тем как «осуждать» следует все таки ознакомиться с данной технологией подробнее.
https://interface31.ru/tech_it/2022/11/linux-nachinayushhim-uchimsya-rabotat-so-snap.html
Почему-то, как только речь заходит про Snap у многих системных администраторов включается режим «не читал – но осуждаю» при котором Snap наделяется массой отрицательных качеств и чуть ли не подлежит немедленному выпиливанию из системы.
В тоже время Snap является универсальным форматом пакетов, созданным компанией Canonical первоначально для Ubuntu, но получившим широкое распространение и в других дистрибутивах.
Главной особенностью snap-пакетов является их самодостаточность, они содержат как нужное приложение, так и все основные зависимости к нему, что ускоряет распространение приложений и снижает возможные конфликты с другим ПО.
Поэтому перед тем как «осуждать» следует все таки ознакомиться с данной технологией подробнее.
https://interface31.ru/tech_it/2022/11/linux-nachinayushhim-uchimsya-rabotat-so-snap.html
👍28👎5🤔2🥱1
Работа с репозиториями в Debian
Как известно программное обеспечение в Linux устанавливается из централизованных хранилищ – репозиториев. Для работы с ними используется специальное ПО – пакетный менеджер.
В Debian и основанных на нем дистрибутивах это APT. Список репозиториев находится в
Но не всегда набор программ в официальном репозитории является достаточным. Какое-то ПО может отсутствовать, какое-то иметь слишком старые версии. В этом случае обычно подключаются дополнительные репозитории содержащие нужные версии программ.
Добавить их можно по-разному, можно внести записи прямо в
Более подробно можно прочитать в нашей статье:
▫️ Linux - начинающим. Управление пакетами в Debian и Ubuntu
Но следует понимать, что добавление сторонних репозиториев – это потенциально опасная операция и один из самых доступных способов сломать систему.
Поэтому всегда смотрите что на самом деле будет установлено вместе с новым пакетом, проверив его зависимости и посмотрев их источники.
Также можете смоделировать процесс установки использовав ключ
А вообще, если речь идет о небольших программах или пользовательском софте проверить нет ли нужного пакета в формате Snap или Flatpack. В этом случае все нужное пакет принесет с собой и риск сломать систему минимальный.
Про работу Snap читайте:
▫️ Linux - начинающим. Учимся работать со Snap
Еще один распространенный сценарий – это использование репозиториев предыдущего выпуска для получения пакетов, которые требуются некоторому софту, чаще коммерческому, по зависимостям, но отсутствуют в текущей версии.
Чаще всего это безопасно, то есть свои особенности, в частности с возможным обновлением пакета. Можно, конечно, поставить ему HOLD, но это не всегда правильно, особенно если пакет продолжает получать обновления в рамках предыдущего выпуска.
Более правильно в таких случаях использовать технологию APT Pinning, подробнее здесь:
▫️ Используем APT Pinning для закрепления пакетов в Debian и Ubuntu
Ну и наконец, если вы все-таки не вняли первоначальному совету и превратили
Можно спросить у Гугла, можно подсмотреть на другой аналогичной системе, но зачем, если можно восстановить его содержимое одной командой:
Кстати, в той же директории есть оригиналы и других важных файлов из директории
Как известно программное обеспечение в Linux устанавливается из централизованных хранилищ – репозиториев. Для работы с ними используется специальное ПО – пакетный менеджер.
В Debian и основанных на нем дистрибутивах это APT. Список репозиториев находится в
/etc/apt/sources.list. Но не всегда набор программ в официальном репозитории является достаточным. Какое-то ПО может отсутствовать, какое-то иметь слишком старые версии. В этом случае обычно подключаются дополнительные репозитории содержащие нужные версии программ.
Добавить их можно по-разному, можно внести записи прямо в
/etc/apt/sources.list, но в приличном обществе принято создавать отдельные файлы с расширением .list в /etc/apt/sources.list.d. Это позволяет более гибко управлять репозиториями, чтобы отключить не нужные достаточно просто удалить файл или сменить его расширение.Более подробно можно прочитать в нашей статье:
▫️ Linux - начинающим. Управление пакетами в Debian и Ubuntu
Но следует понимать, что добавление сторонних репозиториев – это потенциально опасная операция и один из самых доступных способов сломать систему.
Поэтому всегда смотрите что на самом деле будет установлено вместе с новым пакетом, проверив его зависимости и посмотрев их источники.
Также можете смоделировать процесс установки использовав ключ
-s:apt install имя_пакета -s
А вообще, если речь идет о небольших программах или пользовательском софте проверить нет ли нужного пакета в формате Snap или Flatpack. В этом случае все нужное пакет принесет с собой и риск сломать систему минимальный.
Про работу Snap читайте:
▫️ Linux - начинающим. Учимся работать со Snap
Еще один распространенный сценарий – это использование репозиториев предыдущего выпуска для получения пакетов, которые требуются некоторому софту, чаще коммерческому, по зависимостям, но отсутствуют в текущей версии.
Чаще всего это безопасно, то есть свои особенности, в частности с возможным обновлением пакета. Можно, конечно, поставить ему HOLD, но это не всегда правильно, особенно если пакет продолжает получать обновления в рамках предыдущего выпуска.
Более правильно в таких случаях использовать технологию APT Pinning, подробнее здесь:
▫️ Используем APT Pinning для закрепления пакетов в Debian и Ubuntu
Ну и наконец, если вы все-таки не вняли первоначальному совету и превратили
/etc/apt/sources.list непонятно во что и все сломали, либо наоборот решили навести порядок, то может стать вопрос: а где взять исходное содержимое этого файла.Можно спросить у Гугла, можно подсмотреть на другой аналогичной системе, но зачем, если можно восстановить его содержимое одной командой:
cat /usr/share/doc/apt/examples/sources.list > /etc/apt/sources.list
Кстати, в той же директории есть оригиналы и других важных файлов из директории
/etc/apt, рекомендуем ознакомиться.
👍63👌1
Управление сетевыми настройками в Linux
Последние годы Linux проделал большой путь унификации, во многом благодаря systemd. Теперь вам не нужно вспоминать приемы работы со службами и автозагрузкой в том или ином дистрибутиве. Все везде делается одинаково.
Чего не скажешь о сетевых настройках. Причем, если в графической среде стандартом де-факто давно используется NetworkManager, то в серверном варианте наблюдается полный разброд и шатание.
Debian использует службу networking, которая управляет сетевой конфигурацией через ifupdown, надо сказать – порядком устаревший.
RHEL и производные полагаются на службу network, использующую скрипты ifup и ifdown. В принципе то же самое, что и в Debian, только все по-другому.
Arch и основанное на нем семейство использует netctl собственной разработки, а если вы решите освоить ALT, то познакомитесь с еще одной системой – Etcnet.
Ну и Ubuntu тоже не остался в стороне со своим netplan.
От такого разнообразия разбегаются глаза и становится довольно тоскливо. Если вы редко работаете с тем или иным дистрибутивом, то для управления сетью вам придется заглядывать в справку.
Тем не менее есть инструмент, который позволяет унифицировать работу с сетью, но по какой-то причине до сих пор не пользуется широкой популярностью.
Это systemd-networkd, как и весь systemd он очень прост и также строится на основе юнитов соответствующего типа.
В простейшем случае нам достаточно создать юнит с типом network и внести в него следующее содержимое:
Однако, несмотря на простоту, systemd-networkd достаточно мощный сетевой менеджер и позволяет управлять как проводными, так и беспроводными соединениями, мостами, маршрутизацией и многим другим.
При этом его основной плюс – унификация, он будет работать везде, где есть systemd.
И в целом никто не мешает перейти на systemd-networkd уже сейчас, не дожидаясь пока его завезут из коробки в ваш любимый дистрибутив.
Почему? Потому что это наиболее универсально и перспективно. Вам не нужно учить разные сетевые менеджеры, достаточно просто знать systemd-networkd.
Также отдельно хотелось бы отметить netplan от Ubuntu. Это не самостоятельный сетевой менеджер, а фронтенд, поддерживающий systemd-networkd и NetworkManager.
Netplan позволяет абстрагироваться от конкретного сетевого менеджера и описывать сети декларативно в формате YAML, после чего уже сам netplan сформирует конфигурацию для используемого сетевого менеджера.
Это удобно, прежде всего переносимостью, а также возможностью расширения практически для любого дистрибутива и любого сетевого менеджера.
Кроме того, у netplan есть интересные возможности, например, проверить сетевые настройки перед их применением. Если что-то пошло не так, то вы не потеряете сетевой доступ к узлу, так как все изменения будут автоматически откачены обратно.
Поэтому, глядя на существующий зоопарк технологий мы бы обратили внимание прежде всего на systemd-networkd – он есть везде, где есть systemd, прост, понятен и отлично работает.
В перспективе, конечно, хотелось бы видеть единый унифицированный фронтенд по образу netplan, который бы позволял описывать сети в едином формате и применять их без оглядки на используемый менеджер.
Как и snap, netplan давно уже вышел за рамки мира Ubuntu и доступен практически в любом дистрибутиве, однако широкого распространения не имеет.
Последние годы Linux проделал большой путь унификации, во многом благодаря systemd. Теперь вам не нужно вспоминать приемы работы со службами и автозагрузкой в том или ином дистрибутиве. Все везде делается одинаково.
Чего не скажешь о сетевых настройках. Причем, если в графической среде стандартом де-факто давно используется NetworkManager, то в серверном варианте наблюдается полный разброд и шатание.
Debian использует службу networking, которая управляет сетевой конфигурацией через ifupdown, надо сказать – порядком устаревший.
RHEL и производные полагаются на службу network, использующую скрипты ifup и ifdown. В принципе то же самое, что и в Debian, только все по-другому.
Arch и основанное на нем семейство использует netctl собственной разработки, а если вы решите освоить ALT, то познакомитесь с еще одной системой – Etcnet.
Ну и Ubuntu тоже не остался в стороне со своим netplan.
От такого разнообразия разбегаются глаза и становится довольно тоскливо. Если вы редко работаете с тем или иным дистрибутивом, то для управления сетью вам придется заглядывать в справку.
Тем не менее есть инструмент, который позволяет унифицировать работу с сетью, но по какой-то причине до сих пор не пользуется широкой популярностью.
Это systemd-networkd, как и весь systemd он очень прост и также строится на основе юнитов соответствующего типа.
В простейшем случае нам достаточно создать юнит с типом network и внести в него следующее содержимое:
[Match]
Name=ens33
[Network]
Address=10.8.8.100/24
Gateway=10.8.8.1
DNS=10.8.8.1Однако, несмотря на простоту, systemd-networkd достаточно мощный сетевой менеджер и позволяет управлять как проводными, так и беспроводными соединениями, мостами, маршрутизацией и многим другим.
При этом его основной плюс – унификация, он будет работать везде, где есть systemd.
И в целом никто не мешает перейти на systemd-networkd уже сейчас, не дожидаясь пока его завезут из коробки в ваш любимый дистрибутив.
Почему? Потому что это наиболее универсально и перспективно. Вам не нужно учить разные сетевые менеджеры, достаточно просто знать systemd-networkd.
Также отдельно хотелось бы отметить netplan от Ubuntu. Это не самостоятельный сетевой менеджер, а фронтенд, поддерживающий systemd-networkd и NetworkManager.
Netplan позволяет абстрагироваться от конкретного сетевого менеджера и описывать сети декларативно в формате YAML, после чего уже сам netplan сформирует конфигурацию для используемого сетевого менеджера.
Это удобно, прежде всего переносимостью, а также возможностью расширения практически для любого дистрибутива и любого сетевого менеджера.
Кроме того, у netplan есть интересные возможности, например, проверить сетевые настройки перед их применением. Если что-то пошло не так, то вы не потеряете сетевой доступ к узлу, так как все изменения будут автоматически откачены обратно.
Поэтому, глядя на существующий зоопарк технологий мы бы обратили внимание прежде всего на systemd-networkd – он есть везде, где есть systemd, прост, понятен и отлично работает.
В перспективе, конечно, хотелось бы видеть единый унифицированный фронтенд по образу netplan, который бы позволял описывать сети в едином формате и применять их без оглядки на используемый менеджер.
Как и snap, netplan давно уже вышел за рамки мира Ubuntu и доступен практически в любом дистрибутиве, однако широкого распространения не имеет.
👍42❤1🥱1
Используем адресные листы Mikrotik для сбора данных
Всем известны адресные листы в роутерах Mikrotik, основное назначение которых - упрощение созданий правил брандмауэра, используя в критериях вместо одного значения целый список.
Но адресные листы могут пригодиться не только для брандмауэра, но и для сбора определенных данных.
Сегодня обратился с вопросом коллега, он настроил перехват и перенаправление транзитных DNS-запросов на собственные сервера и заметил, что счетчики правил постоянно растут.
Вопрос был в том, как найти тех, у кого прописаны сторонние DNS.
В Mikrotik это сделать довольно просто: создаем правило, которое отлавливает пакеты к сторонним DNS-серверам и добавляем адрес источник в отдельный список.
Но есть некоторые моменты. Пакеты надо ловить на самом входе в роутер, до всех преобразований или действий с ними.
Для этих целей неплохо подходит
Один из вариантов правила может выглядеть так:
Всем известны адресные листы в роутерах Mikrotik, основное назначение которых - упрощение созданий правил брандмауэра, используя в критериях вместо одного значения целый список.
Но адресные листы могут пригодиться не только для брандмауэра, но и для сбора определенных данных.
Сегодня обратился с вопросом коллега, он настроил перехват и перенаправление транзитных DNS-запросов на собственные сервера и заметил, что счетчики правил постоянно растут.
Вопрос был в том, как найти тех, у кого прописаны сторонние DNS.
В Mikrotik это сделать довольно просто: создаем правило, которое отлавливает пакеты к сторонним DNS-серверам и добавляем адрес источник в отдельный список.
Но есть некоторые моменты. Пакеты надо ловить на самом входе в роутер, до всех преобразований или действий с ними.
Для этих целей неплохо подходит
Mangle prerouting, но помним. что сюда попадают все входящие пакеты, со всех интерфейсов. Поэтому сразу фильтруйте по требуемым условиям.Один из вариантов правила может выглядеть так:
chain=prerouting action=add-src-to-address-list protocol=udp src-address=192.168.3.0/24 dst-address=!192.168.3.1 address-list=BAD_DNS address-list-timeout=none-dynamic dst-port=53 log=no log-prefix=""
Ставим его на самые верх и уже через некоторое время получаем список узлов указанной сети, которые обращались к любым другим DNS, кроме внутреннего.
👍39
Упоминание российских сертификатов вызывает у многих бурную реакцию, вплоть до того, что это мол узаконенный MitM и все мы теперь под колпаком у товарища майора.
Слышать такие вещи довольно странно, тем более от специалистов. При выпуске сертификата закрытый ключ генерируется и остается у клиента, а удостоверяющий центр только подписывает сертификат своей подписью.
Доступ к закрытому ключу CA сразу лишает все сертификаты доверия, но не дает возможности расшифровать клиентский трафик.
Но даже если мы получим доступ к закрытому ключу клиента, то тоже вряд ли сможем расшифровать сеанс. Почему?
Да потому, что чистое шифрование на базе ключевой пары сертификата сейчас не используются. Сеансовый ключ формируется на базе алгоритма Диффи-Хеллмана и не может быть перехвачен, даже если сеанс прослушивает третья сторона.
Подробнее об этом можно почитать в нашей статье: Введение в криптографию. Общие вопросы, проблемы и решения
А пока посмотрим на скриншот ниже, Сбер, сертификат от Минцифры, это видно в самом верху. Теперь смотрим ниже, там есть буквы ECDHE, это означает что для формирования сеансового ключа был использован алгоритм Диффи-Хеллмана на эллиптических кривых. При применении этого алгоритма параметры шифрования не сохраняются, чем достигается совершенная прямая секретность (PFS).
Поэтому не следует пересказывать досужие байки, в устах специалиста они не только звучат глупо, но и подвергают сомнению квалификацию их высказывающего.
Слышать такие вещи довольно странно, тем более от специалистов. При выпуске сертификата закрытый ключ генерируется и остается у клиента, а удостоверяющий центр только подписывает сертификат своей подписью.
Доступ к закрытому ключу CA сразу лишает все сертификаты доверия, но не дает возможности расшифровать клиентский трафик.
Но даже если мы получим доступ к закрытому ключу клиента, то тоже вряд ли сможем расшифровать сеанс. Почему?
Да потому, что чистое шифрование на базе ключевой пары сертификата сейчас не используются. Сеансовый ключ формируется на базе алгоритма Диффи-Хеллмана и не может быть перехвачен, даже если сеанс прослушивает третья сторона.
Подробнее об этом можно почитать в нашей статье: Введение в криптографию. Общие вопросы, проблемы и решения
А пока посмотрим на скриншот ниже, Сбер, сертификат от Минцифры, это видно в самом верху. Теперь смотрим ниже, там есть буквы ECDHE, это означает что для формирования сеансового ключа был использован алгоритм Диффи-Хеллмана на эллиптических кривых. При применении этого алгоритма параметры шифрования не сохраняются, чем достигается совершенная прямая секретность (PFS).
Поэтому не следует пересказывать досужие байки, в устах специалиста они не только звучат глупо, но и подвергают сомнению квалификацию их высказывающего.
🔥38👍23💯5😁2❤1
Родина слышит
Данная заметка написана на злобу дня, в противовес расхожему мнению, что через отечественные сертификаты нас всех расшифруют и… В общем, отправят пилить лобзиком ангарскую сосну на свежем морозном воздухе.
На самом деле никто никогда не скрывал, что отечественный УЦ предназначен в первую очередь для крупных игроков: финтех, госы, электронные сервисы, которые в 2022 чуть было не остались без валидных сертификатов.
Но неокрепшие умы и примкнувшие к ним лица старательно разгоняют тему, что мол отечественный УЦ — это первый шаг к государственному MitM, когда весь трафик расшифруют и никому потом мало не покажется.
Но никто так и не потрудился обосновать – зачем? Какая цель всего этого действа? И кто будет всем этим заниматься?
Ведь расшифровать трафик – это только начало. Его надо проанализировать и выявить… Что выявить? Да пес его знает. Адепты данной теории заговора не склонны к логике, они просто эмоционально нагнетают – могут, значит сделают!
А теперь я предлагаю каждому тупо собрать трафик домашней сети за сутки и вдумчиво его проанализировать. Когда вы скажете – нафиг нужно? Через полчаса? Час? А там еще этого трафика вагон и маленькая тележка. И, самое главное, что это даст?
По факту занятие это чудовищно дорогое и столь же чудовищно неэффективное. Ибо 99,5% трафика – это хлеб и зрелища, крайне далекие от интересов «товарища Майора».
А теперь подумаем, если некто Имярек засветился у т. Майора, то он явно засветился в публичном поле и если его личность неизвестна, то какой смысл в расшифровке трафика? И даже если мы смогли локализовать его до города, то все равно объем информации будет фактически неподъемным для любого регионального отдела хоть МВД, хоть ФСБ, нет там столько людей.
Но если наш Имярек засветился в соцсети, форуме или ином ресурсе, владелец которого гражданин РФ, то органы просто пошлют к нему запрос, в котором попросят выдать всю информацию по Имяреку.
И это не только IP, но и временная активность, социальная активность и т.д. Т.е. когда Имярек заходит на ресурс, кого он лайкает, кто лайкает его, на кого он подписан, кто подписан на него и т.д. и т.п.
А дальше включается привычная любому оперу отработка связей Имярека. И где-то он да проколется, и цепочка выведет от безликих аккаунтов к реальному человеку, а там снова изучение окружения, поиск слабого звена, и кто-то наконец заговорит. После чего клубочек начнет распутываться в обратном направлении.
Эта методика давно отработана оффлайн, проста, дешева и привычна. А слабое звено найдется всегда. Особенно если утром вас выдернут из постели хмурые мужики в штатском.
И к чему тут расшифровка трафика? Совсем ни к чему. Это сложно и дорого. А тут простая и понятная любому оперу отработка социальных связей.
Ладно, наш Имярек весь такой зашифрованный и нигде не прокололся, ходит только через VPN. Так тут тоже все довольно просто. Видим, что наш пассажир заходил в такое-то время через вот этот сервис на этот ресурс.
После чего снимаем с ТСПУ данные, а кто именно в это время обменивался трафиком с этим ресурсом. Выборка будет большая. Но это не страшно. Берем следующий момент времени и накладываем выборки друг на друга.
И уже через несколько итераций мы фактически получит данного пассажира на блюдечке. А если у него свой VPN-сервер, то срисуют его фактически мгновенно.
А дальше что? Перехватим и расшифруем его трафик? Зачем? Проще просто прийти рано утром, вытащить пассажира из теплой постельки, положить лицом в пол, устроить маски-шоу, дать проникнуться и поговорить по душам.
Если пассажир попался непонятливый, то всегда есть рядом слабое звено – родители, супруга, любовница, кореша и собутыльники. Хороший опер умеет работать с этим материалом.
На крайний случай можно использовать терморектальный криптоанализатор или просто зажать бубенцы дверью. В общем, если личность пассажира установлена, то трафик расшифровывать тем более нет никакого смысла. Есть методы гораздо проще.
Поэтому не надо искать черную кошку в темной комнате, особенно если ее там нет.
Данная заметка написана на злобу дня, в противовес расхожему мнению, что через отечественные сертификаты нас всех расшифруют и… В общем, отправят пилить лобзиком ангарскую сосну на свежем морозном воздухе.
На самом деле никто никогда не скрывал, что отечественный УЦ предназначен в первую очередь для крупных игроков: финтех, госы, электронные сервисы, которые в 2022 чуть было не остались без валидных сертификатов.
Но неокрепшие умы и примкнувшие к ним лица старательно разгоняют тему, что мол отечественный УЦ — это первый шаг к государственному MitM, когда весь трафик расшифруют и никому потом мало не покажется.
Но никто так и не потрудился обосновать – зачем? Какая цель всего этого действа? И кто будет всем этим заниматься?
Ведь расшифровать трафик – это только начало. Его надо проанализировать и выявить… Что выявить? Да пес его знает. Адепты данной теории заговора не склонны к логике, они просто эмоционально нагнетают – могут, значит сделают!
А теперь я предлагаю каждому тупо собрать трафик домашней сети за сутки и вдумчиво его проанализировать. Когда вы скажете – нафиг нужно? Через полчаса? Час? А там еще этого трафика вагон и маленькая тележка. И, самое главное, что это даст?
По факту занятие это чудовищно дорогое и столь же чудовищно неэффективное. Ибо 99,5% трафика – это хлеб и зрелища, крайне далекие от интересов «товарища Майора».
А теперь подумаем, если некто Имярек засветился у т. Майора, то он явно засветился в публичном поле и если его личность неизвестна, то какой смысл в расшифровке трафика? И даже если мы смогли локализовать его до города, то все равно объем информации будет фактически неподъемным для любого регионального отдела хоть МВД, хоть ФСБ, нет там столько людей.
Но если наш Имярек засветился в соцсети, форуме или ином ресурсе, владелец которого гражданин РФ, то органы просто пошлют к нему запрос, в котором попросят выдать всю информацию по Имяреку.
И это не только IP, но и временная активность, социальная активность и т.д. Т.е. когда Имярек заходит на ресурс, кого он лайкает, кто лайкает его, на кого он подписан, кто подписан на него и т.д. и т.п.
А дальше включается привычная любому оперу отработка связей Имярека. И где-то он да проколется, и цепочка выведет от безликих аккаунтов к реальному человеку, а там снова изучение окружения, поиск слабого звена, и кто-то наконец заговорит. После чего клубочек начнет распутываться в обратном направлении.
Эта методика давно отработана оффлайн, проста, дешева и привычна. А слабое звено найдется всегда. Особенно если утром вас выдернут из постели хмурые мужики в штатском.
И к чему тут расшифровка трафика? Совсем ни к чему. Это сложно и дорого. А тут простая и понятная любому оперу отработка социальных связей.
Ладно, наш Имярек весь такой зашифрованный и нигде не прокололся, ходит только через VPN. Так тут тоже все довольно просто. Видим, что наш пассажир заходил в такое-то время через вот этот сервис на этот ресурс.
После чего снимаем с ТСПУ данные, а кто именно в это время обменивался трафиком с этим ресурсом. Выборка будет большая. Но это не страшно. Берем следующий момент времени и накладываем выборки друг на друга.
И уже через несколько итераций мы фактически получит данного пассажира на блюдечке. А если у него свой VPN-сервер, то срисуют его фактически мгновенно.
А дальше что? Перехватим и расшифруем его трафик? Зачем? Проще просто прийти рано утром, вытащить пассажира из теплой постельки, положить лицом в пол, устроить маски-шоу, дать проникнуться и поговорить по душам.
Если пассажир попался непонятливый, то всегда есть рядом слабое звено – родители, супруга, любовница, кореша и собутыльники. Хороший опер умеет работать с этим материалом.
На крайний случай можно использовать терморектальный криптоанализатор или просто зажать бубенцы дверью. В общем, если личность пассажира установлена, то трафик расшифровывать тем более нет никакого смысла. Есть методы гораздо проще.
Поэтому не надо искать черную кошку в темной комнате, особенно если ее там нет.
👍62🔥17🤡13👎7👨💻1
Мифы и легенды Active Directory. Миф 1 - PDC.
Читаем официальную документацию:
Роль FSMO эмулятора PDC
Эмулятор PDC необходим для синхронизации времени на предприятии. Windows включает службу времени W32Time (Windows время), требуемую протоколом проверки подлинности Kerberos. Все Windows компьютеры на предприятии используют общее время. Цель службы времени — убедиться, что служба Windows времени использует иерархическую связь, контролируемую полномочиями. Это не позволяет циклам обеспечить надлежащее общее использование времени.
Эмулятор PDC домена является авторитетным для домена. Эмулятор PDC в корне леса становится авторитетным для предприятия и должен быть настроен для сбора времени из внешнего источника. Все держатели ролей PDC FSMO следуют иерархии доменов при выборе своего связанного партнера по времени.
В домене Windows роль эмулятора PDC сохраняет следующие функции:
Изменения пароля, внесенные другими DCs в домене, реплицированы преимущественно в эмулятор PDC.
При сбоях проверки подлинности в том или ином dc из-за неправильного пароля сбои перенаправляются в эмулятор PDC перед сообщением о сбое неправильного пароля пользователю.
Блокировка учетной записи обрабатывается в эмуляторе PDC.
Эмулятор PDC выполняет все функции, которые Windows NT 4.0 Серверный PDC или более ранний PDC выполняет для Windows NT 4.0 или более ранних клиентов.
Эта часть роли эмулятора PDC становится ненужной в следующей ситуации:
Все рабочие станции, серверы членов и контроллеры доменов, работающие Windows NT 4.0 или более ранних, обновлены до 2000 Windows 2000.
Эмулятор PDC по-прежнему выполняет другие функции, описанные в Windows 2000.
В следующих сведениях описываются изменения, которые происходят в процессе обновления:
Windows клиенты (рабочие станции и серверы-члены) и клиенты на уровне ниже уровня, которые установили клиентский пакет распределенных служб, не выполняют каталог записей (например, изменения паролей) в dc, рекламируемом как PDC. Они используют любой DC для домена.
После обновления контроллеров доменов резервного копирования (BDCs) в доменах с Windows 2000 г. эмулятор PDC не получает запросов на реплику на уровне ниже уровня.
Windows (рабочие станции и серверы-члены) и клиенты на уровне, которые установили клиентский пакет распределенных служб, используют Active Directory для поиска сетевых ресурсов. Они не требуют службы Windows NT браузера.
https://docs.microsoft.com/ru-ru/troubleshoot/windows-server/identity/fsmo-roles
Основной вывод: в Active Directory нет никаких первичных контроллеров, все контроллеры равнозначны. Эмулятор PDC нужен для совместимости с NT4 ( у кого-то есть?) и для ряда вспомогательных, но важных функций, например, синхронизации времени.
Читаем официальную документацию:
Роль FSMO эмулятора PDC
Эмулятор PDC необходим для синхронизации времени на предприятии. Windows включает службу времени W32Time (Windows время), требуемую протоколом проверки подлинности Kerberos. Все Windows компьютеры на предприятии используют общее время. Цель службы времени — убедиться, что служба Windows времени использует иерархическую связь, контролируемую полномочиями. Это не позволяет циклам обеспечить надлежащее общее использование времени.
Эмулятор PDC домена является авторитетным для домена. Эмулятор PDC в корне леса становится авторитетным для предприятия и должен быть настроен для сбора времени из внешнего источника. Все держатели ролей PDC FSMO следуют иерархии доменов при выборе своего связанного партнера по времени.
В домене Windows роль эмулятора PDC сохраняет следующие функции:
Изменения пароля, внесенные другими DCs в домене, реплицированы преимущественно в эмулятор PDC.
При сбоях проверки подлинности в том или ином dc из-за неправильного пароля сбои перенаправляются в эмулятор PDC перед сообщением о сбое неправильного пароля пользователю.
Блокировка учетной записи обрабатывается в эмуляторе PDC.
Эмулятор PDC выполняет все функции, которые Windows NT 4.0 Серверный PDC или более ранний PDC выполняет для Windows NT 4.0 или более ранних клиентов.
Эта часть роли эмулятора PDC становится ненужной в следующей ситуации:
Все рабочие станции, серверы членов и контроллеры доменов, работающие Windows NT 4.0 или более ранних, обновлены до 2000 Windows 2000.
Эмулятор PDC по-прежнему выполняет другие функции, описанные в Windows 2000.
В следующих сведениях описываются изменения, которые происходят в процессе обновления:
Windows клиенты (рабочие станции и серверы-члены) и клиенты на уровне ниже уровня, которые установили клиентский пакет распределенных служб, не выполняют каталог записей (например, изменения паролей) в dc, рекламируемом как PDC. Они используют любой DC для домена.
После обновления контроллеров доменов резервного копирования (BDCs) в доменах с Windows 2000 г. эмулятор PDC не получает запросов на реплику на уровне ниже уровня.
Windows (рабочие станции и серверы-члены) и клиенты на уровне, которые установили клиентский пакет распределенных служб, используют Active Directory для поиска сетевых ресурсов. Они не требуют службы Windows NT браузера.
https://docs.microsoft.com/ru-ru/troubleshoot/windows-server/identity/fsmo-roles
Основной вывод: в Active Directory нет никаких первичных контроллеров, все контроллеры равнозначны. Эмулятор PDC нужен для совместимости с NT4 ( у кого-то есть?) и для ряда вспомогательных, но важных функций, например, синхронизации времени.
Docs
Роли Flexible Single Master Operation Active Directory (FSMO) в Windows - Windows Server
В этой статье рассказывается о ролях FSMO Active Directory в Windows.
👍32👎3🥱2
Мифы и легенды Active Directory. Миф 2 - хозяева операций (роли FSMO)
У этого мифа очень много разновидностей, но все они сводятся к тому, что хозяева операций - некая священная корова. Почему? Да потому что так исторически сложилось.
Последствия этого мифа могут быть разные, многие плохо владеющие вопросом администраторы часто сами наживают себе проблем.
На самом деле хозяева выполняют очень важные роли, но в повседневной жизни AD участвуют мало. Отсутствия некоторых вы можете никогда и не заметить.
Всего хозяев пять. Два - уровня леса, по одному в каждом лесу. И три уровня домена, по одном в каждом домене.
Начнем с леса:
1️⃣ Хозяин именования домена. - как часто вы переименовываете домен или заводите новый в текущем лесу? Многие делают это один раз при установке AD.
2️⃣ Хозяин схемы - нужен немного чаще, раз в несколько лет, когда вы захотите ввести в домен контроллер на новой версии ОС или поставить что-то типа Exchange.
Уровень домена:
1️⃣ Хозяин инфраструктуры - самый бесполезный хозяин. Если домен один - он не нужен. Если все контроллеры являются Глобальными каталогами (как рекомендуется ныне) - он не нужен.
2️⃣ Хозяин RID - выдает идентификаторы безопасности для новых объектов, пачками по 500 штук. Если они кончатся, а хозяин будет недоступен - вы не сможете создавать новые объекты.
3️⃣ Эмулятор PDC - его отсутствие вы заметите раньше всего, так как эта роль отвечает за синхронизацию времени в домене. Также перестанут работать некоторые политики при неправильном вводе пароля, но кто на это обращает внимание?
Как видим, ничего сакрального в хозяевах нет и домен может спокойно жить без них некоторое время.
Поэтому не следует носиться с ними, как дурень с писаной торбой. Если нужно вывести контроллер - владельца ролей на некоторое время из эксплуатации, то переносить хозяев нет никакого смысла.
А захват ролей делаем только тогда, когда контроллер окончательно вышел из строя.
Ниже статья как сделать это средствами старого доброго
https://interface31.ru/tech_it/2013/08/upravlenie-rolyami-fsmo-pri-pomoshhi-ntdsutil.html
У этого мифа очень много разновидностей, но все они сводятся к тому, что хозяева операций - некая священная корова. Почему? Да потому что так исторически сложилось.
Последствия этого мифа могут быть разные, многие плохо владеющие вопросом администраторы часто сами наживают себе проблем.
На самом деле хозяева выполняют очень важные роли, но в повседневной жизни AD участвуют мало. Отсутствия некоторых вы можете никогда и не заметить.
Всего хозяев пять. Два - уровня леса, по одному в каждом лесу. И три уровня домена, по одном в каждом домене.
Начнем с леса:
1️⃣ Хозяин именования домена. - как часто вы переименовываете домен или заводите новый в текущем лесу? Многие делают это один раз при установке AD.
2️⃣ Хозяин схемы - нужен немного чаще, раз в несколько лет, когда вы захотите ввести в домен контроллер на новой версии ОС или поставить что-то типа Exchange.
Уровень домена:
1️⃣ Хозяин инфраструктуры - самый бесполезный хозяин. Если домен один - он не нужен. Если все контроллеры являются Глобальными каталогами (как рекомендуется ныне) - он не нужен.
2️⃣ Хозяин RID - выдает идентификаторы безопасности для новых объектов, пачками по 500 штук. Если они кончатся, а хозяин будет недоступен - вы не сможете создавать новые объекты.
3️⃣ Эмулятор PDC - его отсутствие вы заметите раньше всего, так как эта роль отвечает за синхронизацию времени в домене. Также перестанут работать некоторые политики при неправильном вводе пароля, но кто на это обращает внимание?
Как видим, ничего сакрального в хозяевах нет и домен может спокойно жить без них некоторое время.
Поэтому не следует носиться с ними, как дурень с писаной торбой. Если нужно вывести контроллер - владельца ролей на некоторое время из эксплуатации, то переносить хозяев нет никакого смысла.
А захват ролей делаем только тогда, когда контроллер окончательно вышел из строя.
Ниже статья как сделать это средствами старого доброго
ntdsutil.https://interface31.ru/tech_it/2013/08/upravlenie-rolyami-fsmo-pri-pomoshhi-ntdsutil.html
Записки IT специалиста
Управление ролями FSMO при помощи Ntdsutil.
Управление ролями FSMO при помощи стандартных оснасток MMC не совсем удобный процесс, так как для доступа к разным ролям приходится использовать различные оснастки, а к некоторым из них еще и не так просто добраться. Кроме того оснастки MMC не позволяют...
👍24❤1⚡1
▶️ БЕСПЛАТНЫЙ МАСТЕР-КЛАСС «Linux: от основ к профессиональному использованию»
14 мая в 19:00 (МСК) | Онлайн | Бесплатно
✔️Регистрация
Linux уже давно перестал быть инструментом исключительно для системных администраторов. Сегодня это необходимый навык для DevOps-инженеров, специалистов по кибербезопасности и всех, кто работает с IT-инфраструктурой.
На нашем вебинаре мы:
▪️ Развеем мифы о сложности Linux и покажем, как начать работать с ним уверенно
▪️ Продемонстрируем практическое применение в реальных рабочих задачах
▪️ Расскажем о карьерных перспективах для специалистов, владеющих Linux
▪️ Дадим пошаговый алгоритм освоения системы
Особое внимание уделим:
✔ Работе с терминалом (основные команды и их применение)
✔ Решению типовых задач системного администрирования
✔ Возможностям для профессионального роста
Ведущий: Дмитрий Семьянов — действующий специалист по пентесту, куратор курса «Основы Linux».
Не пропустите! Регистрация здесь.
🚀 Трудности с регистрацией? Пишите @Codeby_Academy
14 мая в 19:00 (МСК) | Онлайн | Бесплатно
✔️Регистрация
Linux уже давно перестал быть инструментом исключительно для системных администраторов. Сегодня это необходимый навык для DevOps-инженеров, специалистов по кибербезопасности и всех, кто работает с IT-инфраструктурой.
На нашем вебинаре мы:
▪️ Развеем мифы о сложности Linux и покажем, как начать работать с ним уверенно
▪️ Продемонстрируем практическое применение в реальных рабочих задачах
▪️ Расскажем о карьерных перспективах для специалистов, владеющих Linux
▪️ Дадим пошаговый алгоритм освоения системы
Особое внимание уделим:
✔ Работе с терминалом (основные команды и их применение)
✔ Решению типовых задач системного администрирования
✔ Возможностям для профессионального роста
Ведущий: Дмитрий Семьянов — действующий специалист по пентесту, куратор курса «Основы Linux».
Не пропустите! Регистрация здесь.
🚀 Трудности с регистрацией? Пишите @Codeby_Academy
👍1🤮1
Мифы и легенды Active Directory – откуда ноги растут
Как мы уже неоднократно говорили, администраторы Active Directory очень часто подвержены множественным заблуждениям, из которых уже сформировался устойчивый набор мифов и легенд.
Как водится, происхождение всего этого мифотворчества уходит своими корнями в далекие времена Windows NT, т.е. до 2000 года. Фактически уже выросло второе поколение специалистов, которые эту самую NT в глаза не видели, но тем не менее подвержены распространенным заблуждениям.
Поэтому предлагаем вам немного окунуться в историю и понять, чем являлся домен NT и что изменилось с приходом Active Directory.
Домен NT (NTDS) являлся реализаций службы каталогов от Microsoft доступный в серверной операционной системе Windows NT Server. И состоял из одного первичного контроллера домена – PDC (Primary Domain Controller) и неограниченного количества резервных – BDC (Backup Domain Controllers).
Именно на первичном контроллере хранилась основная база домена и все изменения в нее могли вноситься только на нем. Затем эта база реплицировалась на остальные резервные контроллеры, после чего они тоже могли начать обрабатывать клиентские запросы.
Если первичный контроллер выходил из строя, то домен фактически переходил в режим «только чтение». При его окончательной утере первичным можно было сделать один из резервных контроллеров.
Но это была достаточно непростая задача, учитывая, что выбор роли определялся только на этапе установки и его нельзя было изменить без переустановки системы. Т.е. мы не могли добавить уже существующему серверу роль контроллера или понизить его до рядового. Также сделав резервный контроллер основным, нельзя было снова изменить его роль на резервный.
Чтобы понять все сложности, с которыми сталкивались администраторы тех лет следует вспомнить, что виртуализация в те времена была чем-то из области научной фантастики и сервера были железными. И было их обычно не очень много, поэтому кроме роли контроллера они совмещали в себе еще множество функций и переустановка такого сервера была крайне непростой задачей.
А при появлении нового сервера приходилось крепко думать, будет ли он контроллером домена или нет. Так как изменить его назначение без переустановки было невозможно.
Также схема один PDC – много BDC имела серьезные проблемы с репликацией, особенно для удаленных филиалов с учетом скоростей и качества каналов связи того времени. При том, что удаленный филиал сам не мог внести необходимые данные в домен, так как для этого требовался первичный контроллер.
Поэтому с приходом Windows 2000 и Active Directory от данной схемы отказались, с этого момента все контроллеры домена стали равнозначны и каждый из них мог вносить изменения в базу домена, потом обмениваясь измененными данными. А для контроля целостности и уникальности данных были созданы хозяева операций.
Также теперь любой сервер мог стать контроллером домена или перестать им быть без переустановки, что значительно облегчило администрирование и планирование инфраструктуры.
Но несмотря на то, что Active Directory скоро разменяет четверть века многие коллеги все еще продолжают оперировать устаревшими терминами и понятиями системы, которую никогда в глаза не видели.
Как мы уже неоднократно говорили, администраторы Active Directory очень часто подвержены множественным заблуждениям, из которых уже сформировался устойчивый набор мифов и легенд.
Как водится, происхождение всего этого мифотворчества уходит своими корнями в далекие времена Windows NT, т.е. до 2000 года. Фактически уже выросло второе поколение специалистов, которые эту самую NT в глаза не видели, но тем не менее подвержены распространенным заблуждениям.
Поэтому предлагаем вам немного окунуться в историю и понять, чем являлся домен NT и что изменилось с приходом Active Directory.
Домен NT (NTDS) являлся реализаций службы каталогов от Microsoft доступный в серверной операционной системе Windows NT Server. И состоял из одного первичного контроллера домена – PDC (Primary Domain Controller) и неограниченного количества резервных – BDC (Backup Domain Controllers).
Именно на первичном контроллере хранилась основная база домена и все изменения в нее могли вноситься только на нем. Затем эта база реплицировалась на остальные резервные контроллеры, после чего они тоже могли начать обрабатывать клиентские запросы.
Если первичный контроллер выходил из строя, то домен фактически переходил в режим «только чтение». При его окончательной утере первичным можно было сделать один из резервных контроллеров.
Но это была достаточно непростая задача, учитывая, что выбор роли определялся только на этапе установки и его нельзя было изменить без переустановки системы. Т.е. мы не могли добавить уже существующему серверу роль контроллера или понизить его до рядового. Также сделав резервный контроллер основным, нельзя было снова изменить его роль на резервный.
Чтобы понять все сложности, с которыми сталкивались администраторы тех лет следует вспомнить, что виртуализация в те времена была чем-то из области научной фантастики и сервера были железными. И было их обычно не очень много, поэтому кроме роли контроллера они совмещали в себе еще множество функций и переустановка такого сервера была крайне непростой задачей.
А при появлении нового сервера приходилось крепко думать, будет ли он контроллером домена или нет. Так как изменить его назначение без переустановки было невозможно.
Также схема один PDC – много BDC имела серьезные проблемы с репликацией, особенно для удаленных филиалов с учетом скоростей и качества каналов связи того времени. При том, что удаленный филиал сам не мог внести необходимые данные в домен, так как для этого требовался первичный контроллер.
Поэтому с приходом Windows 2000 и Active Directory от данной схемы отказались, с этого момента все контроллеры домена стали равнозначны и каждый из них мог вносить изменения в базу домена, потом обмениваясь измененными данными. А для контроля целостности и уникальности данных были созданы хозяева операций.
Также теперь любой сервер мог стать контроллером домена или перестать им быть без переустановки, что значительно облегчило администрирование и планирование инфраструктуры.
Но несмотря на то, что Active Directory скоро разменяет четверть века многие коллеги все еще продолжают оперировать устаревшими терминами и понятиями системы, которую никогда в глаза не видели.
👍24❤1
Структура файловой системы Linux
Расположение файлов и директорий в Linux регулируется стандартом Filesystem Hierarchy Standard (FHS). Текущая версия стандарта — 3.0 от 3 июня 2015 года.
При этом следует понимать, что FHS, хоть и является основанным на POSIX, но разрабатывался исключительно для Linux и другие UNIX-системы следовать ему не обязаны.
Также далеко не все дистрибутивы полностью следуют этому стандарту, допуская различные отклонения, но, в общем и целом, основные положения соблюдаются.
Начинается файловая система с корня, который обозначается обратной косой чертой -
В Linux все есть файл, даже устройства. Поэтому мы всегда можем их найти в директории
В ней также содержатся директории
Т.е. изначально предполагалось разделение на файлы самой системы и файлы, которые установил пользователь. Однако в большинстве современных систем директории
Отдельно стоит отметить
А также
Расположение файлов и директорий в Linux регулируется стандартом Filesystem Hierarchy Standard (FHS). Текущая версия стандарта — 3.0 от 3 июня 2015 года.
При этом следует понимать, что FHS, хоть и является основанным на POSIX, но разрабатывался исключительно для Linux и другие UNIX-системы следовать ему не обязаны.
Также далеко не все дистрибутивы полностью следуют этому стандарту, допуская различные отклонения, но, в общем и целом, основные положения соблюдаются.
Начинается файловая система с корня, который обозначается обратной косой чертой -
/
Директория /bin содержит бинарные (исполняемые) файлы пользовательского уровня, для выполнения которых не нужны права суперпользователя, например, cat, find или ls./boot – загрузчик и все что с ним связаноВ Linux все есть файл, даже устройства. Поэтому мы всегда можем их найти в директории
/dev, например, блочные устройства /dev/sda или виртуальное устройство /dev/null./etc – конфигурационные файлы/home – домашние директории пользователей, для каждого пользователя в данном каталоге создается собственная поддиректория: /home/Ivanov или /home/petrov
Для хранения библиотек программ предназначена директория /lib, в современных системах, в зависимости от поддерживаемых архитектур это целый набор директорий, таких как lib32, lib64 и т.п./lost+found, как следует из названия, хранит найденные файлы, которые не относятся ни к одной директории, но их inode не помечены как свободные. Т.е. если во время проверки файловой системы будут найдены такие файлы, то система поместит их сюда. /media используется для автоматического монтирования съемных носителей, таких как флешки, USB или оптические диски./mnt – а вот сюда мы можем монтировать нужные устройства вручную. Например, можем примонтировать дополнительный диск для общего хранилища: /mnt/samba и т.д./opt – дополнительное программное обеспечение, чаще всего проприетарное, или имеющее большой дисковый размер. /proc – сюда смонтирована виртуальная файловая система procfs, через «файлы» этой директории мы можем получить различную информацию от ядра системы. Скажем, cat /proc/meminfo – информация об оперативной памяти./root – домашняя директория суперпользователя, всегда находится в корневом каталоге./run – файлы состояния приложений, такие как сокеты или PID-файлы/sbin – исполняемые файлы, которые для своего запуска требуют права суперпользователя. В первую очередь к ним относятся служебные утилиты. Здесь мы можем найти fdisk, sysctl, useradd и т.д./srv – стандарт предполагает хранение здесь данных сервисов, предоставляемых системой. На практике не используется./sys – место монтирования виртуальной файловой системы sysfs, которая позволяет не только получать различные параметры ядра, но и передавать ему настройки через «запись» нужного параметра в определенный «файл», все измененные параметры действуют до перезагрузки./tmp – временные файлы/usr – достаточно интересная директория, предназначена для хранения всех установленных пользователем программ, документации, исходного кода. Предполагается, что данная директория может быть доступна по сети.В ней также содержатся директории
/usr/bin, /usr/sbin, /usr/lib и т.д.Т.е. изначально предполагалось разделение на файлы самой системы и файлы, которые установил пользователь. Однако в большинстве современных систем директории
/bin, /sbin и все /lib являются симлинками на одноименные директории в /usr.Отдельно стоит отметить
/usr/share, где располагаются различные общие ресурсы, такие как документация, примеры конфигурационных файлов, иконки и т.д.А также
/usr/local, куда по умолчанию устанавливаются файлы программ, которые собраны из исходных кодов или получены иными путями в обход менеджера пакетов./var – файлы, которые изменяются при работе системы, например, логи - /var/log, базы данных - /var/lib, файлы обслуживаемые веб сервером - /var/www.
👍80❤5
Некоторые, неочевидные особенности связки DNS и DHCP в Active Directory
Вчера, в обсуждении возник вопрос, а зачем нужна связка из MS DNS и MS DHCP, ведь можно использовать любой другой DHCP сервер.
Вроде бы очевидный ответ: для того, чтобы DHCP мог динамически изменять DNS-записи в AD.
В ответ можно услышать, мол у меня DHCP на роутере и записи прекрасно добавляются. И на первый взгляд это действительно так.
Но, на самом деле, это называется «вроде бы работает», именно «вроде бы».
Почему? Правильная работа Active Directory серьезно завязана на правильную работу DNS. Поэтому важно, чтобы DHCP-сервер мог своевременно динамически менять записи, но это может делать не абы кто, а только авторизованный сервер.
При отсутствии авторизованного сервера Active Directory может сама внести нужную запись в момент входа в домен. Но только в прямую зону. В обратную зону никаких записей добавлено не будет.
Если устройство не входит в домен, то никаких записей о нем также добавлено не будет. А таких устройств может быть много: принтеры, гипервизоры, промышленные контроллеры и т.д. и т.п.
Первая проистекающая отсюда проблема – это сложности администрирования, так как вам, чтобы подключиться к принтеру в 216 кабинете вместо
Но все это ерунда, когда вопрос коснется обратной зоны. Обратная зона нужна для правильной работы очень многих интеграций сторонних приложений в AD и без нее ситуация превращается в «жизнь – боль» или «какая гадость эта ваша Active Directory».
Как живой пример подобной интеграции можно привести взаимодействие Squid и AD через Kerberos.
И заканчивается это все для администратора довольно плохо. К нам не раз приходили читатели, мол сделал все по статье, ничего не работает. И случайный кусок лога.
Хорошо, если кусок верный и ошибка в нем сразу видна.
В противном случае заниматься дебагом Kerberos по переписке у автора, как и других читателей нет никакого желания, а квалификации вопрошающего явно недостаточно для самостоятельного решения проблемы.
Хотя львиная их часть кроется как раз в неправильной работе DNS и обратная зона только частный случай.
Поэтому нужно сразу настраивать работу ключевых компонентов правильно, а не оставлять в состоянии «вроде работает».
Вчера, в обсуждении возник вопрос, а зачем нужна связка из MS DNS и MS DHCP, ведь можно использовать любой другой DHCP сервер.
Вроде бы очевидный ответ: для того, чтобы DHCP мог динамически изменять DNS-записи в AD.
В ответ можно услышать, мол у меня DHCP на роутере и записи прекрасно добавляются. И на первый взгляд это действительно так.
Но, на самом деле, это называется «вроде бы работает», именно «вроде бы».
Почему? Правильная работа Active Directory серьезно завязана на правильную работу DNS. Поэтому важно, чтобы DHCP-сервер мог своевременно динамически менять записи, но это может делать не абы кто, а только авторизованный сервер.
При отсутствии авторизованного сервера Active Directory может сама внести нужную запись в момент входа в домен. Но только в прямую зону. В обратную зону никаких записей добавлено не будет.
Если устройство не входит в домен, то никаких записей о нем также добавлено не будет. А таких устройств может быть много: принтеры, гипервизоры, промышленные контроллеры и т.д. и т.п.
Первая проистекающая отсюда проблема – это сложности администрирования, так как вам, чтобы подключиться к принтеру в 216 кабинете вместо
printer-216 надо сначала где-то найти его текущий IP-адрес. Но все это ерунда, когда вопрос коснется обратной зоны. Обратная зона нужна для правильной работы очень многих интеграций сторонних приложений в AD и без нее ситуация превращается в «жизнь – боль» или «какая гадость эта ваша Active Directory».
Как живой пример подобной интеграции можно привести взаимодействие Squid и AD через Kerberos.
И заканчивается это все для администратора довольно плохо. К нам не раз приходили читатели, мол сделал все по статье, ничего не работает. И случайный кусок лога.
Хорошо, если кусок верный и ошибка в нем сразу видна.
В противном случае заниматься дебагом Kerberos по переписке у автора, как и других читателей нет никакого желания, а квалификации вопрошающего явно недостаточно для самостоятельного решения проблемы.
Хотя львиная их часть кроется как раз в неправильной работе DNS и обратная зона только частный случай.
Поэтому нужно сразу настраивать работу ключевых компонентов правильно, а не оставлять в состоянии «вроде работает».
👍40🔥6❤1
Самоподписанные сертификаты. Мифы и реальность
Вокруг самоподписанных сертификатов каких только мифов не собрано. Если не вдаваться в подробности, то все они сводятся к тому, что самоподписанный сертификат не безопасен и не предоставляет надежного шифрования. И ставить его в продакшен – ну такое…
Но стоит начать задавать уточняющие вопросы как выясняется, что редко кто может толком пояснить чем же небезопасен самоподписанный сертификат и что в нем такого ненадежного.
Начнем с того, что надежность шифрования не зависит от сертификата, сертификат нужен нам для формирования ключей шифрования, а надежность шифрования зависит от применяемого набора шифров.
Мы вполне можем использовать «настоящий» сертификат и слабые шифры и это будет менее надежно, чем самоподписанный сертификат и сильные шифры.
Так в чем же тогда проблема? В доверии. Вся инфраструктура открытых ключей (PKI) строится на вопросе доверия, ключевым звеном в вопросе доверия является удостоверяющий центр (CA), которому мы однозначно доверяем.
После того, как мы поместим корневой сертификат CA в хранилище доверенных корневых сертификатов мы можем проверить любой выданный этим удостоверяющим центром сертификат и убедиться в том, что он действителен.
Также мы можем проверить сертификат на отзыв, при помощи все того же удостоверяющего центра.
Если нам нужно выпускать собственные сертификаты, то мы можем создать собственный CA и распространив его корневой сертификат внутри своей инфраструктуры обеспечим доверительные отношения к любым выпущенным им сертификатам.
Корневой сертификат удостоверяющего центра не является секретным, но перед его установкой нам следует убедиться, что мы устанавливаем именно тот сертификат, который нам нужен.
Для этого нужно сравнить цифровой отпечаток с предоставленным вам по надежным каналам владельцем сертификата или с опубликованным в официальном источнике.
А теперь перейдем к самоподписанным сертификатам. При его создании не используется никакой удостоверяющий центр и сертификат подписывает себя самостоятельно собственной сигнатурой.
Таким образом мы не можем проверить действительность сертификата и установить с ним доверительные отношения. Нам остается только поверить или проверить его цифровой отпечаток запросив его у владельца сертификата.
Вариант «поверить» на практике выливается в постоянное игнорирование предупреждения о доверии сертификату, что притупляет бдительность и дает прекрасную возможность осуществить атаку MitM, перехватив трафик и предоставив поддельный сертификат. Все равно его никто не проверяет.
Вариант «проверить» также связан с определенными сложностями, вам нужно получить от владельца сертификата по заслуживающему доверию каналу его цифровой отпечаток и сравнить его с тем, который предоставляет удаленный узел.
Хорошо, проверили и убедились, что это действительно реальный сертификат узла, но не будем же мы это делать каждый раз? Не будем, чтобы избежать постоянного предупреждения такой сертификат также нужно добавить в хранилище корневых доверенных сертификатов.
Подводя итог, скажем следующее, самоподписанные сертификаты ничем не отличаются от любых других и их использование не несет никаких технических угроз безопасности.
Основная проблема самоподписанного сертификата – это вопрос доверия, точнее крайняя сложность в установлении доверительных отношений, если только вы сами не являетесь стороной выпустившей такой сертификат.
Кроме того, такой сертификат нельзя отозвать, нет, вы можете выпустить новый самоподписанный сертификат, но старый останется действительным до конца срока действия, что может привести к нежелательным последствиям в случае его компрометации.
Так можно ли использовать такие сертификаты? Можно, если вы представляете все сопутствующие проблемы и риски и готовы их решать. Но лучше все таки создать собственный удостоверяющий центр и выпускать сертификаты с его помощью, что позволит вам более гибко управлять процессом и уменьшит количество потенциально опасных ситуаций связанных с доверием.
Вокруг самоподписанных сертификатов каких только мифов не собрано. Если не вдаваться в подробности, то все они сводятся к тому, что самоподписанный сертификат не безопасен и не предоставляет надежного шифрования. И ставить его в продакшен – ну такое…
Но стоит начать задавать уточняющие вопросы как выясняется, что редко кто может толком пояснить чем же небезопасен самоподписанный сертификат и что в нем такого ненадежного.
Начнем с того, что надежность шифрования не зависит от сертификата, сертификат нужен нам для формирования ключей шифрования, а надежность шифрования зависит от применяемого набора шифров.
Мы вполне можем использовать «настоящий» сертификат и слабые шифры и это будет менее надежно, чем самоподписанный сертификат и сильные шифры.
Так в чем же тогда проблема? В доверии. Вся инфраструктура открытых ключей (PKI) строится на вопросе доверия, ключевым звеном в вопросе доверия является удостоверяющий центр (CA), которому мы однозначно доверяем.
После того, как мы поместим корневой сертификат CA в хранилище доверенных корневых сертификатов мы можем проверить любой выданный этим удостоверяющим центром сертификат и убедиться в том, что он действителен.
Также мы можем проверить сертификат на отзыв, при помощи все того же удостоверяющего центра.
Если нам нужно выпускать собственные сертификаты, то мы можем создать собственный CA и распространив его корневой сертификат внутри своей инфраструктуры обеспечим доверительные отношения к любым выпущенным им сертификатам.
Корневой сертификат удостоверяющего центра не является секретным, но перед его установкой нам следует убедиться, что мы устанавливаем именно тот сертификат, который нам нужен.
Для этого нужно сравнить цифровой отпечаток с предоставленным вам по надежным каналам владельцем сертификата или с опубликованным в официальном источнике.
А теперь перейдем к самоподписанным сертификатам. При его создании не используется никакой удостоверяющий центр и сертификат подписывает себя самостоятельно собственной сигнатурой.
Таким образом мы не можем проверить действительность сертификата и установить с ним доверительные отношения. Нам остается только поверить или проверить его цифровой отпечаток запросив его у владельца сертификата.
Вариант «поверить» на практике выливается в постоянное игнорирование предупреждения о доверии сертификату, что притупляет бдительность и дает прекрасную возможность осуществить атаку MitM, перехватив трафик и предоставив поддельный сертификат. Все равно его никто не проверяет.
Вариант «проверить» также связан с определенными сложностями, вам нужно получить от владельца сертификата по заслуживающему доверию каналу его цифровой отпечаток и сравнить его с тем, который предоставляет удаленный узел.
Хорошо, проверили и убедились, что это действительно реальный сертификат узла, но не будем же мы это делать каждый раз? Не будем, чтобы избежать постоянного предупреждения такой сертификат также нужно добавить в хранилище корневых доверенных сертификатов.
Подводя итог, скажем следующее, самоподписанные сертификаты ничем не отличаются от любых других и их использование не несет никаких технических угроз безопасности.
Основная проблема самоподписанного сертификата – это вопрос доверия, точнее крайняя сложность в установлении доверительных отношений, если только вы сами не являетесь стороной выпустившей такой сертификат.
Кроме того, такой сертификат нельзя отозвать, нет, вы можете выпустить новый самоподписанный сертификат, но старый останется действительным до конца срока действия, что может привести к нежелательным последствиям в случае его компрометации.
Так можно ли использовать такие сертификаты? Можно, если вы представляете все сопутствующие проблемы и риски и готовы их решать. Но лучше все таки создать собственный удостоверяющий центр и выпускать сертификаты с его помощью, что позволит вам более гибко управлять процессом и уменьшит количество потенциально опасных ситуаций связанных с доверием.
👍56❤1