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

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.
Вопрос доверия имеющимся "корням" остается на совести администратора системы (то есть вас), при этом по сети могут прилетать обновления списка корневых сертификатов, после которых опять нужно проверять хранилище на случай появления нежелательных для вас корневых сертификатов.

Zabbix до сих пор не умеет менять интервал опроса агентов по триггеру https://support.zabbix.com/browse/ZBXNEXT-1414 . Технически, если позволить скрипту реакции на триггер менять значения в заббиксе, можно пробовать посылать ему API-запросы на изменение настроек конкретного итема, но в таком случае нужно очень сильно подумать о безопасности - заббикс не дает назначить права только на один итем, минимум на хост (хост-группу или тег-фильтр, вторым можно отфильтровать один хост, первой тоже можно, но менее удобно), как следствие, утекшие креды позволят как минимум просто отрубить мониторинг на этом хосте, как максимум захватить его через скажем remote commands. Поэтому я бы не рекомендовал такой подход.

Начнем с того, что триггер может и немудреный, у вас сложность с его погашением. Вам нужно как минимум повесить этот самый all.log на элемент данных, а потом экспериментировать с выражением отключения триггера с использованием метаданных события, которые вам придется ещё выколупывать из строчки в error.log, которая вызывает ошибку. Но если вам хватит по любой строчке в all.log гасить ошибку, в настройке триггера выбираете "OK event generation = Recovery expression" и в самом выражении Recovery expression пишете, скажем, nodata(/test/log[/logs/program/all.log],30)=0.

Однако тут есть подводный камень - recovery expression проверяется только если trigger expression становися false, т.е. пока вы НЕ УДАЛИТЕ ВСЕ ЛОГИ (при такой формулировке триггера) из error.log (или не запишете туда 0, как его понимает заббикс), ваш триггер не опустится. Поэтому при триггерах по логам (любым) нужно в качестве trigger expression на фильтрованные логи использовать nodata()=1, и если отсутствие данных в логах не означает прекращение проблемы, писать какой-то вменяемый recovery expression.