Максим Гришин

Скорее всего слишком старый процессор у вашего ПК. Попробуйте взять VMware Workstation более старой версии и из неё запустить утилиту. И не повредит посмотреть логи системы после запуска вашей утилиты, там может, например, появиться сообщение о падении с причиной illegal instruction. Ну и вариант, может у вас десятка x86, а не x64, тогда проблемы возникнут при запуске не только этой программы.

Выставь мускул слушать на 10.0.0.1, должно хватить.

systemctl list-units|grep ssdp
Судя по тому, что отправляется NOTIFY, ваша система сообщает всем кто слышит о том, что у неё есть что-то из функционала. Нужно найти в системе SSDP-демон и отключить.

Вам надо на своем узле раздавать два сайта: старый_домен.ru и новый_домен.ru, у каждого сайта свой сертификат. На старом отдаете 301, на новом отдаете контент.

GPO относится к поведению компьютеров и пользователей на стороне клиента, а членство в группах - управление доступом на стороне сервера. Вы пытаетесь решить задачу неправильным инструментом. Выше правильно подсказали - запустите на сервере/DC скрипт по изменению групп. А вообще правильнее всего настроить требуемое поведение (скажем, подключение сетевых дисков) как GPO на OU, а права на диск раздавать уже группами, причем лучше вручную, либо корректно делегировать права и ответственность за группы начальникам тех людей, которым нужен доступ к тому, что защищено членством в группе AD.

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

1. Остановить веб-сервер и перезагрузить хост
2. Изолировать хост от доступа извне, перенастроить файрволл для ограничения выхода сервера в интернет (обратный шелл - гадость, которую надо ловить отдельно)
3. Обновить wordpress на свежую версию, сохранив старый каталог в месте, недоступном для веб-сервера
4. Создать новую базу для wordpress, сменить пароль админа и пароль доступа к БД
5. Просмотреть changelog wordpress'a в поисках багфиксов, через которые возможен взлом сайта
6. Просмотреть старый каталог wordpress в поисках залитого шелла, при обнаружении проанализировать, включая путь, которым он туда попал
7. Ограничить доступ к админке wordpress средствами веб-сервера (IP, авторизация логин-пароль внутри сервера (не вордпрессная!), ещё что-нибудь, что умеете)
8. Настроить аудит доступа к админке и fail2ban на его основе, чтобы отсечь ломающего ваш сервер
9. Создать бэкап системы для обеспечения отката на состояние "купированная атака"
10. Включить новый wordpress, проверить ваш доступ к нему, проверить (ожиданием и анализом логов) наличие попыток взлома
11. В случае, если взломать новый wordpress у атакующего не получилось (по логам, по косвенным признакам, ещё как), запустить перенос данных со старого инстанса (из БД в БД), пользователей пересоздать.

Как-то так имхо.

Best practice - валидировать входящие данные. И да, если что-то хотя бы теоретически возвращает null или ещё какую-то чушь, всегда проверяете, вернулась ли чушь, иначе рано или поздно огребете серьезный баг, и хорошо ещё, если последствия будут всего лишь падением пхп. Серебряной пули, естественно, нет, но есть статические анализаторы, которые могут помочь найти места в коде, где валидации на чушь не хватает.

Как-то так
По ссылке: нужно создать сетевой namespace, в него пихнуть vpn-адаптер и браузер, который надо, чтобы ходил в впн, а остальных оставить в default.

Задача понята так: Есть два подключения к Интернету через два независимых роутера, нужно настроить сеть так, чтобы ПК, который подключен в свитч, имел оба выхода как доступные и был доступен из Интернета через оба роутера, где второй нужен для резервной связи. На ПК запущена некая служба (сайт, ssh, неважно), использующая известный порт.

Делаете так:
- На свитче создаете два VLAN, скажем с номерами 10 и 20, в один включаете порт с ПК (tagged, порт соответственно в trunk), и порт с роутером (untagged), во второй порт с ПК (tagged) и порт второго роутера (untagged);
- На ПК настраиваете два виртуальных сетевых адаптера (eth0.1, eth0.2) под оба VLAN, на обоих настраиваете DHCP;
- На роутерах выдаете известному мак-адресу ПК конкретный статический IP-адрес (лучше из разных подсетей, чтобы при работе с ПК не путаться) и настраиваете проброс требуемого порта на этот IP;
- На ПК проверяете доступность Интернета через каждую из сетевых карт путем отключения их поочередно (ifdown eth0.2 например, и пингуете 8.8.8.8, потом ifup eth0.2; ifdown eth0.1 и опять пингуете);
- Настраиваете службу так, чтобы она слушала на 0.0.0.0 или на обоих IP-адресах, выданных роутерами;
- Настраиваете DynDNS на оба IP-адреса, с которыми ПК выходит в Интернет, для обеспечения доступа снаружи;
- Проверяете доступ снаружи путем отключения каждого из каналов по очереди и ожидания обновления DynDNS.

Странно, что у вас не открывается. Запускаете cmd, если надо запустить от админа, а UAC не вылезает, делаете shift+RMB - Run as different user, вводите креды админа, получаете админский cmd. в нем запускаете mmc compmgmt.msc и вперед. А вот если надо панель управления запустить, тут сложнее, запуск control из-под админа лезет в существующий explorer-процесс.

Если в той сети Windows, то у неё есть (ЕМНИП не выпиливали) способ послать сообщение через net send, встроенный в винду и поддерживаемый отдельной службой. А вообще выше правильно писали - поднимите локальный XMPP-мессенджер и работайте в нем.

Если твой трафик с ВМ НАТится, IP не утечет, разве что на ВМ появится некое ПО, передающее фактическую конфигурацию вовне. И от такого вам защищаться уже нужен NGFW (L7-фильтрация), сильно сомневаюсь, что вообще потребуется защита подобного уровня. Проще говоря, если в Интернет выходите через NAT, и не используете протоколов, которые в данных передают локальные IP-адреса (ЕМНИП SIP/RTP их передают, и для нормального проксирования SIP нужен модуль на прокси для подмены этих адресов), то ваш IP не утечет.

Похоже, в Zabbix 5.4 появился новый синтаксис для агрегированных вычислений https://www.zabbix.com/documentation/current/en/ma... и для вычисления вашего "среднего CPU на SNMP" нужно написать обычный item, типа calculated, с формулой из примера №2 по ссылке, только вместо sum поставить avg. Т.е. формула должна быть вроде вот такой:

avg(last_foreach(/host/hrProcessorLoad[*]))

Ну начнем с того, что корневых сертификатов приличное множество. Не один, и не один десяток даже. Пример:

64 штуки. И сертификат, подписанный любым из них, система считает доверенным. Это, собственно, и причина, почему боятся получить дополнительный корневой сертификат - заранее не знаешь, у кого есть возможность подписи с его помощью, и отличить сертификат, подписанный новым добавленным корневым (транзитивно или нет), можно только после того, как ты его получишь, при этом большинство программ не позволяют пользователю заблокировать соединение, установленное с использованием доверенного сертификата. То есть, вначале тебя с ним поимеют, потом тебе вычищать последствия.
Fiddler точно так же устанавливает свежесозданный (это важно, новая пара ключей, которых ни у кого нет) корневой сертификат тебе в доверенные корни, и использует его, чтобы на лету генерировать сертификаты для каждого сайта, куда ты ломишься, подсовывая их браузеру, чтобы тот не вякал, а сам выполняя роль man-in-the-middle.
Вопрос доверия имеющимся "корням" остается на совести администратора системы (то есть вас), при этом по сети могут прилетать обновления списка корневых сертификатов, после которых опять нужно проверять хранилище на случай появления нежелательных для вас корневых сертификатов.