Remove
Хотел узнать у гугла, умеет ли команда rm в логические операторы, а в итоге узнал, что бтс топ
Хотел узнать у гугла, умеет ли команда rm в логические операторы, а в итоге узнал, что бтс топ
Нихао!
Очередная доработка хелпера "conf_int_ipv4_via_network_scripts" подъехала ( предыдущая публикация - Ansible. Network-scripts. RHEL8. Временное применение сетевой конфигурации ).
Как и обещал, реализовал сбор MAC-адресов (а также сведений о соседствах/neighbours) с удалённых хостов, на основе чего добавлена следующая функциональность:
1) дополнительные проверки на соответствие interface_name+hwaddr из "config" реальным интерфейсам удалённых хостов. Например, если на хосте А используется MAC-адрес "A1:A2:A3:A4:A5:A6", то попытка прописать такой же MAC-адрес на хосте B приведёт к ошибке и остановке сценария. Или, например, если в файле конфигурации для хоста А прописано, что за интерфейсом eth0 закреплён адрес "B1:B2:B3:B4:B5:B6", но в реальности eth0 = "C1:C2:C3:C4:C5:C6", то скрипт предложит исправить "config";
2) функционал проверки конфигурации без её применения ('check_ifcfg_without_apply.sh');
3) анализ сети (в пределах inventory-файла "conf_network_scripts_hosts") на предмет дублирования MAC-адресов. Если после запуска сценариев (бэкап ifcfg, проверка конфигурации, применение конфигурации) в директории ".../playbooks/ifcfg_backup_from_remote/network_data" был создан файл "WARNINGS.txt", то стоит обратить внимание на его содержание.
Также в директории "network_data" присутствует информация (файл "inv_hosts_interfaces_info.txt") об используемых на том или ином хосте MAC-адресах, что полезно при первоначальном заполнении файла "config" (дабы не собирать вручную информацию). В общем, если config на этапе заполнения, то просто запустите, например, скрипт бэкапа "just_run_ifcfg_backup.sh" и загляните в ".../playbooks/ifcfg_backup_from_remote/network_data".
Ссылка на репозиторий: https://github.com/vladimir-chursin000/ansible_helpers
Некоторые ресурсы при копировании текста с сайта вставляют в буфер обмена ссылку на себя. Например, такое поведение будет при копировании первого абзаца со страницы КонсультантПлюс.
Как это технически работает?
В JS можно на событие copy навесить свой обработчик, который что-то модифицирует. Есть более современное Clipboard API.
Этот функционал позволяет осуществить атаку на целостность данных через манипуляцию с содержимым буфера обмена. Результат - страничка, где написано
echo "not evil"
Теперь скопируйте этот фрагмент и вставьте в терминал. Поздравляю, вас хакнули. В терминал вставился другой текст
echo "evil"
Не копируйте команды сразу в терминал. Лучше перепечатать (так ещё и запомнится лучше) или идти по пути сайт — блокнот — анализ глазками. Копировать без переноса строки тоже не поможет — наглый js может вставить в буффер символ переноса строки. В итоге безопасное
pip install -U pytest
Может сделать с вами что-то злобное. Не всегда об этом можно узнать. Команды в терминале, которые начинаются с пробела, в истории команд не сохраняются. Если вывод команды достаточно длинный (установка пакета для python является хорошим примером), то вы даже не увидите настоящую введенную команду.
А ещё так можно модифицировать ваш .bashrc, сделав любой alias.
В телеграм-канале разбираем разные нюансы из жизни разработчика на Python и не только — python, bash, linux, тесты, командную разработку.
Бонжур!
Доработал недавно (как и обещал в предыдущей публикации - Ansible. Network-scripts. RHEL8) функционал ansible-хелпера "conf_int_ipv4_via_network_scripts". Теперь изменения сетевых настроек возможно применить временно (например, на период тестирования). Для этого достаточно:
1) сконфигурировать целевые интерфейсы посредством правки файла "config";
2) задать время отката настроек на предыдущие через конфиг "additional_configs/config_temporary_apply_ifcfg" (по умолчанию = 10 минут);
3) запустить скрипт "apply_temporary_ifcfg.sh". Выполняет действия, аналогичные "apply_immediately_ifcfg.sh" (т.е. реконфигурирует сеть в соответствии с файлом "config"), но перед рестартом сервиса "network" запускает на удалённом хосте bash-скрипт "rollback_ifcfg_changes.sh", который возвращает сетевые настройки к виду до модификации через временной промежуток, определённый в файле "config_temporary_apply_ifcfg";
4) протестировать сетевые связанности целевых хостов (вероятно, когда-нибудь реализую утилиту на основе стека "ansible + bash + perl");
5) если всё в порядке, то запустить скрипт "apply_immediately_ifcfg.sh", который остановит исполнение сценария "rollback_ifcfg_changes.sh".
Итого, два варианта на выбор пользователя - либо применить новые настройки незамедлительно (just run "apply_immediately_ifcfg.sh"), либо применить их временно (run "apply_temporary_ifcfg.sh") до осуществления тестирования и отмены возврата к предыдущей конфигурации сети хоста (run "apply_immediately_ifcfg.sh").
Конечно, неплохо бы добавить централизованный сбор наименований сетевых интерфейсов и соответствующих им MAC-адресов, дабы в автоматическом режиме (при попытке применить конфигурацию) сверять с тем, что пользователь напишет в конфиге (и прекращать выполнение софта, если, например, для интерфейса задан некорректный MAC), но эту фичу, думаю, реализую позже.
P.S. На очереди небольшой сюрприз для любителей разрешать доступ только к тем сетевым портам, которые необходимы для конкретного сервиса.
===
Ссылка на репозиторий: https://github.com/vladimir-chursin000/ansible_helpers
Есть такой вид атаки на отказ в обслуживании (DoS, Denial of Service) — forkbomb. Запускается процесс, который бесконечно порождает сам себя, пожирая все ресурсы системы. Прав суперпользователя не требуется, любой пользователь может создавать процессы.
Cкрипт атаки выглядит так. Функция порождает две версии себя, связанные конвейером. Правая функция уходит в фоновый режим с помощью знака амперсанд &.
forkbomb()
{
forkbomb | forkbomb&
}
Скрипт можно переписать в непонятный однострочник, изменив название на символ двоеточия:
:(){ :|:& }; :
Такой набор символов эквивалентен скрипту выше. При этом он компактен, и его могут запихнуть вам в качестве шуточного ответа на вопрос. Спасибо ещё, что не патч Бармина.
В видео также рассматриваются линуксовые команды команды
1. lscpu
2. nproc
3. uptime
4. top
5. free
6. переменные $$ $PPID
7. настройка числа PID в /proc/sys/kernel/pid_max
8. ctrl-L для очистки терминала
9. разделение экрана в терминале terminator
10. буфер выделения и вставка по нажатию на колёсико мышки
11. pkill
И разбираются флаги такой docker команды
docker run --it --rm --cpus="0.5" --memory=4G --pids-limit=1000 --name=forkbomb ubuntu bash
Плюс применяются команды docker ps / stats / exec.
Хотите почувствовать себя капитаном тонущего корабля? Теперь ресурсы системы принадлежат не вам, а паразитному процессу forkbomb. Приятного просмотра!
Починить атакованную систему можно только перезагрузкой. Ну, если атакующий скрипт вам не дописали в .bashrc. Тогда только recovery mode в grub.
В телеграм-канале разбираем разные нюансы из жизни разработчика на Python и не только — python, bash, linux, тесты, командную разработку.
Приветствую!
Практически завершил работу над ansible-хелпером "conf_int_ipv4_via_network_scripts" (репозиторий "ansible_helpers"), но "практически" означает, что совокупность скриптов и сценариев уже можно использовать в работе.
Краткая инструкция.
1. Клонируем репозиторий - git clone "https://github.com/vladimir-chursin000/ansible_helpers".
2. Переходим в директорию ".../ansible_helpers/conf_int_ipv4_via_network_scripts/rhel8_based".
3. Заполняем inventory-файл "conf_network_scripts_hosts" (не забываем про ssh-ключи на удалённых хостах).
4. Заполняем основной файл конфигурации "config" (такой вот незамысловатый нейминг). Каждая линия - настройка конкретного сетевого интерфейса на конкретном хосте. Присутствует файл со всеми возможными примерами конфигурации - "config_examples".
5. Правим дополнительные файлы конфигурации, расположенные в директории "additional_configs":
а) dns_settings (настройки DNS). По умолчанию содержит только доменные сервера Google (8.8.8.8, 8.8.4.4) в качестве общих NS (nameservers/сервера имён) для всех хостов из inventory-файла. Также присутствует возможность для отдельных хостов выставить уникальные сервера имён;
б) config_del_not_configured_ifcfg. Файл конфигурации, определяющий действия в отношении сетевых интерфейсов, отсутствующих в основном файле конфигурации (который "config"). Для inventory-хостов, вписанных в этот конфиг, действует правило - отключать сетевые интерфейсы (и удалять соответствующие ifcfg-файлы), не сконфигурированные в файле "config".
6. Запускаем скрипт "install_network_scripts_and_configure_network.sh" (если "network-scripts" не установлен) или "apply_immediately_ifcfg.sh".
Что произойдёт после запуска (если опустить часть с установкой "network-scripts"), если кратко:
1. Бэкап ifcfg-файлов с сохранением в директорию (и поддиректории) ".../playbooks/ifcfg_backup_from_remote": "history" - для хранения, "now" - для дальнейшего сравнения с ifcfg-файлами, генерация которых (на основе config-а) произойдёт на следующем этапе.
2. Запуск perl-скрипта "generate_dynamic_ifcfg.pl", которые создаёт:
а) ifcfg-файлы для каждого inventory-хоста (на основе основного конфига). Размещаются в ".../playbooks/dyn_ifcfg_playbooks/dyn_ifcfg";
б) файлы resolv-conf (на основе "dns_settings"). Директория ".../playbooks/dyn_ifcfg_playbooks/dyn_resolv_conf";
в) task-файл для каждого inventory-хоста, содержащий ansible-инструкции для реконфигурации сети (директория ".../playbooks/dyn_ifcfg_playbooks"). Важный момент - если сгенерированные ifcfg-файлы не отличаются от текущих (скопированных на первом этапе исполнения), то task-файл будет содержать только ansible-код для взаимодействия с "resolv.conf".
3. Исполнение сформированных task-файлов.
P.S. №1. Осталась самая малость - реализовать механизм временного применения сетевых настроек (о чём писал ранее).
P.S. №2. Надеюсь, кому-то результат моих изысканий поможет сэкономить время.
Одна вакансия, два кандидата. Сможете выбрать лучшего? И так пять раз.