Дмитрий Дурновцев, без дискавери можно обойтись, если сеть подконтрольная, скажем, локальная на гипервизоре и вы админите этот гипер. Можете создать новый discovery для корректного диапазона IP-адресов и подождать, пока он пройдет (discoverer'ы заббикса занимаются активным ожиданием пингов, о чем и рапортуют, отчего вылезает алерт), и пусть работает, а алерт, если что, можно и отключить.
Евгений у вашего объекта время жизни - до конца рендера страницы, так как пхп-скрипты дольше не пребывают запущенными. И вот когда ваш пользователь какой-то кусок опроса пытается дальше отправить, вам надо достоверно знать, во-первых, что это за пользователь, во-вторых, на каком этапе опроса он сейчас находится, в-третьих, какой номер/ID записи соответствует его сессии, и не начал ли он внезапно новую, и со звездочкой - не ломает ли он вам сохраненные данные, отправляя запрос с фейковыми элементами. И вот это всё вам надо в вашем скрипте уметь вытаскивать на КАЖДЫЙ запуск, и всех данных у вас - то, что передано в $_REQUEST. Вот, планируйте логику работы и архитектуру хранения данных на клиенте в предположении, что а) клиент ВРЕТ, и валидность передаваемых данных нужно вначале проверить; и б) клиент МОЖЕТ сфальсифицировать свой идентификатор, чтобы создать больше одного ответа (актуально для голосований).
iBird Rose, не понял, зачем мне ещё один. Проблема в том, что мне показалось, что при попытке вставить пароль в диалог создания нового пользователя вместо случайного вставляется мой.
И такое задают... я бы ещё понял, если бы это был питон или скажем bash с возможностью задать параметр с именем, а-ля func(param=value,param2=value2), а тут javascript, который ничего кроме списка параметров не умеет. Народ что, программировать учится методом фаззинга исходных кодов?
Объект новый создается при следующем запуске скрипта, и откуда ему знать, что за запись вы недавно вставили, если в $_REQUEST[] вы ничего в скрипт не передаете, а если и передаете, то не используете?
Константин Формально - да, так как мы не знаем, все ли баги в обработке изображений исправлены в конкретной ОС и конкретном ПО на ПК "жертвы". Фактически - скорее всего на выполнение такой атаки потратится больше времени, сил и денег, чем с той жертвы можно выбить, в большинстве случаев. То есть априори любой файл, прилезший каким-либо образом на систему (скачанный, присланный, залитый на шару, принесенный на болванке или флоппи-диске), должно третировать как потенциально опасный.
Константин, иной раз и просто через баги в ОС можно пролезть, вне зависимости от того, какое и насколько проприетарное ПО на ней стоит. Между прочим, opensource совсем не гарантия отсутствия дырок (но больше шансов, что конкретно бэкдоров в нем нет). А безбаговое ПО вымерло в третичном досовом периоде (с) Травник. Да вообще жить вредно, от этого умирают (с)
Название файлов видеть тоже не будет - на это нужно иметь list folder/read file, который для прохождения по пути не нужен от слова совсем. Мы так выдавали права в далеком 2004м, концепция с тех пор не менялась.
Фокс Йовович да и без админских прав "хакнуть" могут, хотя и куда с меньшей вероятностью - например, воткнутая в него уязвимость, приводящая к RCE под правами текущего пользователя. Этого уже хватит, чтобы запустить шифровальщик.
CityCat4, чтобы пакет долетел через два туннеля, маршрутизация тоже должна быть настроена, особенно если на локальной тачке внезапный докер или ещё какая-то нетривиальная конфигурация. И IPsec в самом деле не учитывает маршрутизацию - потому что ему не надо, его задача определить, шифровать ли пакет и чем, после того, как routing engine определил следующий хоп. А то, что демон, реализующий IPsec, ещё и заботится о заполнении таблицы маршрутизации - приятное следствие, он не обязан это делать. В любом случае, я тут вижу обычную непонятку с терминами с учетом необходимости объяснить "для чайников", куда смотреть, необязательно ТС окажется единственным, кто что-то будет делать по этой инструкции. И если ему понятно - ОК.
ettaluni, дык, прописывать их надо все как целое, и на каждом узле, куда попадает пакет, проверить, что следующий узел, куда он полетит по таблице маршрутизации, находится в правильной стороне и сам сможет направить пакет дальше. В обратную сторону, кстати, то же самое.
По туннелю как раз всё и должно пускаться - когда ты пишешь, что маршрут через второй конец туннеля, пакет будет пытаться быть запихнутым в туннель. Кстати, параметры IPSec встанут препятствием, если на left/right subnet отсутствует целевая сеть... 10.1.1.1 должен знать, что за второй стороной (10.0.1.1) могут быть адреса 192.168.20.0/24, а 10.1.1.2 должен знать про 192.168.10.0 на стороне 10.0.1.1. Тогда параметры IPsec в туннелях придется тоже поменять - на стороне 10.0.1.1 помимо имеющихся пар сетей должны объявляться 192.168.20.0/24 для туннеля с 10.1.1.1, и 192.168.10.0/24 для туннеля с 10.1.1.2, оба клиента могут ожидать того же или шире (192.168.0.0/16, например, минус своя подсеть) на второй стороне.
Так или иначе, сети связаны через центральный сервер. Скорее всего, маршруты до остальных сетей должны быть прописаны и на 10.1.1.1, 10.1.1.2, чтобы их искали за дальней стороной VPN"a - если я правильно понимаю, то 10.1.1.1 имеет прямой выход в интернет и его шлюз по умолчанию не находится внутри VPN. Возможно, удастся обойти конфигурацию клиентов, заставив сервер пушить таблицу маршрутизации вида 192.168.0.0/16 via 10.0.1.1
Вообще, такие проблемы надо отлаживать изнутри сетей 192.168, чтобы в случае недостатка конфигурации на VPN endpoint'ах они всплывали на traceroute.
Ошибка в коде, реализующем перезапуск (основная) - где-то снаружи класса освобождается "allCubes" который потом пытается разыменоваться в update(). Проверяй внимательно.
А зачем вам одна локальная сеть, но два разных выхода в интернет? Если затеете хотя бы какое-то физическое объединение, обязательно получите проблем. А строить VPN - можно, если использовать VPN-сервер где-то в интернете, но тогда трафик из одного кабинета в другой будет жрать оба интернета.
