, но я все таки сторонник пристального наблюдения во время испытательного срока,
Испытательный срок в ИТ актуален наверное только для джуниоров, за все время работы ни разу не видел, чтобы кого-то из айтишников увольняли после него.
Да и дорого это — три месяца платить зарплату, вводить в курс дел, давать доступ ко внутренним системам, чтобы потом уволить?
возвращаемся к вопросу что ваше приложение не должно само стучать в интернет, только если вы не краулер делаете
Это идет в разрез с текущими тенденциями: проверка и скачивание обновлений, централизованная конфигурация, централизованная аутентификация, облачные хранилища данных и так далее.
Сейчас все сетевое.
О чем можно говорить, когда половина логики в современной системе — вызовы REST‑методов по сети.
Да, ДМЗ это хорошо и нужно на серьезных проектах.
Но дорого и непросто, поскольку все что делает автоматика вам придется делать вручную.
опять-таки это не ваш случай когда ваш класс уже в системе и его надо как-то запустить
Вы ошибочно считаете, что код это обязательно класс и что вызов может быть только локальным. Хотя RCE на практике нужен в первую очередь для скачивания основной логики, но вполне может использоваться и напрямую.
Код реверс-шелла в одну строку в статье есть, как это работает (вывод управляющих команд) видно на заглавной картинке.
акамай на сколько знаю sql injection замечает.
SQL Injection ныне довольно редок а попытки его резать запросто могут мешать логике работы системы. Это помимо очевидного замедления работы из-за подобного фонового сканирования, так что решение откровенно нишевое.
Описанное в статье это очень редкий сценарий, который требует уж очень много всего: тут и триггер изнутри корпоративной сети и специфический набор протоколов взаимодействия и нетривиальная настройка.
Если уж дошло до запуска чего-то изнутри корпоративной сети, то сильно проще запустить банальный реверс-шелл типа описанного выше и дальше просто работать.
в принципе я не вижу проблем настроить томкат так, чтобы он запускал приложение из отдельной папки и сам мог писать только в папку log и temp которые тоже находятся в отдельном месте
Не видите проблем или не пробовали? А я например вижу (потому что пробовал). И кто прав?
, но возможно в этом случаи вы в принципе не сможете модифицировать и подложить что-то в classpath.
Все‑таки стоит более внимательно читать технические статьи прежде чем комментировать — про автоматическую загрузку и выполнение кода из переменной окружения было написано. И не один раз.
Я за лет 15 не помню такого случая.
Надо почаще читать профильные новости, хотя вопрос конечно спорный - вдруг начитаетесь и сон потеряете?
При такой настройке, зная белый ip торчащий в интернет, угадав внутренн. подсеть (ничего сложного), найдя активный ip перебором и активный порт на нем, гипотетически действительно можно отправить на него пакет и получить ответ.
Вы своим постом шатаете устои маршрутизации.
Такого никогда не было, нет и не будет.
Но с радостью почитаю про источник столь удивительной ереси (чтобы отправить по адресу зондер-команду цисководов).
приговаривал автор имея полный админский доступ, меняя jarки и подкладывая свои
В Java-мире принято, что у пользователя, от которого работает Java-приложение есть доступ на запись минимум в собственный каталог. Поэтому при наличии RCE (линк в статье) всегда можно записать что-то на уязвимый сервер.
у меня на большом проекте есть запрет на соединения с произвольными адресами, только по белому листу
Вроде даже РКН перестал пытаться блокировать по IP еще 10 лет назад.
Даже интересно как выглядит ваш "whitelist": полный список ip-адресов Amazon S3, CloudFlare, зеркал Яндекса и так далее - рука не устала вбивать? А поддерживать потом как?
Ну а чтобы кто-то шел залил так это надо еще найти такую
Вбейте в поисковик: "github java rce" - удивитесь.
Если сразу не успокоитесь, то вот еще одна моя статья, пока не перенесенная на Хабр, как раз про ваш корпоративный мир.
Я как-то проходил собеседование с таким СТО самодуром
А я если честно надеялся, что умные и образованные айтишники все же задумаются о том что тупизна бывает показательной а не только врожденной и применяется с определенной целью.
С таким бы я точно не хотел бы работать!
Рад что у вас есть выбор, да еще настолько большой, что вы даже посреди кризиса и спада экономики готовы предъявлять претензии работодателю.
Вот он золотой ключик успешности "технического специалиста".
Знаете как получилось, что из всего выпуска 2005 года на Хабре пишу только я один?
Выпускалось с дипломом «инженер‑программист» в тот год что‑то около сотни человек, если память не изменяет. Прошло 20 лет и все, никого нет.
Как думаете, куда делись одногруппники, коллеги по многочисленным работам?
Они сошли с дистанции — большинство одногруппников ушло из ИТ в течение первых пяти лет, часть вообще никогда не работала по специальности. Кого‑то уже нет в живых.
Тоже самое с коллегами, в самом лучшем случае часть из них еще как-то присутствует в ИТ-отрасли в виде менеджмента, но сопоставимых технических компетенций больше нет.
Так что увы, но основной критерий успешности (статистически) это самое банальное выживание — даже после 10 лет практики о конкуренции можно не задумываться, после 20 ее просто нет.
Испытательный срок в ИТ актуален наверное только для джуниоров, за все время работы ни разу не видел, чтобы кого-то из айтишников увольняли после него.
Да и дорого это — три месяца платить зарплату, вводить в курс дел, давать доступ ко внутренним системам, чтобы потом уволить?
Volkov Commander так и остался закрытым, исходников нет а сам он на ассемблере, так что врядли.
Это идет в разрез с текущими тенденциями: проверка и скачивание обновлений, централизованная конфигурация, централизованная аутентификация, облачные хранилища данных и так далее.
Сейчас все сетевое.
О чем можно говорить, когда половина логики в современной системе — вызовы REST‑методов по сети.
Да, ДМЗ это хорошо и нужно на серьезных проектах.
Но дорого и непросто, поскольку все что делает автоматика вам придется делать вручную.
Вы ошибочно считаете, что код это обязательно класс и что вызов может быть только локальным. Хотя RCE на практике нужен в первую очередь для скачивания основной логики, но вполне может использоваться и напрямую.
Код реверс-шелла в одну строку в статье есть, как это работает (вывод управляющих команд) видно на заглавной картинке.
SQL Injection ныне довольно редок а попытки его резать запросто могут мешать логике работы системы. Это помимо очевидного замедления работы из-за подобного фонового сканирования, так что решение откровенно нишевое.
Тут я хотел выдать очередную гусарскую шутку, но внезапно реальность меня обогнала:
Надо будет обязательно попробовать собрать, хотя-бы ради ностальгии )
Еще как были )
Я как раз занимался домовыми сетями в те годы, RIP/OSPRF - с тех времен и VLANы тогда только начинались.
Которые в самом хреновом случае были в одной подсети да.
Ага и первым делом запускает перебор клиентских IP-адресов и сканер открытых портов. Как в фильме "Хакеры" )
Вообщем это безумие, но даже в этом безумном случае, даже самый отбитый сисадмин не станет пускать протоколы маршрутизации на клиентский порт.
Это у них на уровне генетики прошито.
Ээм не читайте таких статей на ночь )
Описанное в статье это очень редкий сценарий, который требует уж очень много всего: тут и триггер изнутри корпоративной сети и специфический набор протоколов взаимодействия и нетривиальная настройка.
Если уж дошло до запуска чего-то изнутри корпоративной сети, то сильно проще запустить банальный реверс-шелл типа описанного выше и дальше просто работать.
Не видите проблем или не пробовали? А я например вижу (потому что пробовал). И кто прав?
Все‑таки стоит более внимательно читать технические статьи прежде чем комментировать — про автоматическую загрузку и выполнение кода из переменной окружения было написано. И не один раз.
Надо почаще читать профильные новости, хотя вопрос конечно спорный - вдруг начитаетесь и сон потеряете?
Помимо упомянутого в статье эпичного фейла с log4j:
https://github.com/BobTheShoplifter/Spring4Shell-POC
https://github.com/absholi7ly/POC-CVE-2025-24813
https://github.com/akamai/CVE-2025-27636-Apache-Camel-PoC
https://gist.github.com/win3zz/308c6567e38e096c7071d3564ef164ad
https://securitylab.github.com/advisories/GHSL-2022-085_pac4j/
https://github.com/abdoghazy2015/ofbiz-CVE-2023-49070-RCE-POC/
И все это уже PoC (Proof of Concept) те готовый запускаемый эксплоит -
наливай да пейзапускай да используй.Все кто занимается ИБ поседели за последние три года, смотреть страшно.
Прежде чем заморачиваться со стендом - почитайте про протоколы маршрутизации, хотя бы про классику вроде RIP.
Это самое простое.
"Форвард" пакетов между подсетями, в которые подключен ваш локальный сервер к маршрутизации отношение имеет очень слабое.
Вы своим постом шатаете устои маршрутизации.
Такого никогда не было, нет и не будет.
Но с радостью почитаю про источник столь удивительной ереси (чтобы отправить по адресу зондер-команду цисководов).
Что-то новое в мире маршрутизации. Детали будут? Хотя-бы подскажите где вы о таком узнали.
В Java-мире принято, что у пользователя, от которого работает Java-приложение есть доступ на запись минимум в собственный каталог. Поэтому при наличии RCE (линк в статье) всегда можно записать что-то на уязвимый сервер.
Вроде даже РКН перестал пытаться блокировать по IP еще 10 лет назад.
Даже интересно как выглядит ваш "whitelist": полный список ip-адресов Amazon S3, CloudFlare, зеркал Яндекса и так далее - рука не устала вбивать? А поддерживать потом как?
Вбейте в поисковик: "github java rce" - удивитесь.
Если сразу не успокоитесь, то вот еще одна моя статья, пока не перенесенная на Хабр, как раз про ваш корпоративный мир.
И перебивать вручную номера пакетов, полагаю?
Какая-то фантастика, если только между роутером и аплинком не бегает какой-нибудь OSPRF/RIP. Или речь про какую-то подделку пакетов?
На 2025й год входящие подключения на обычный компьютер практически все.
держите в курсе )
Полагаю речь об участии в качестве рядового разработчика а не руководителя такого проекта, верно?
Я конечно замечал на Хабре представителей совсем старшего поколения, но в реальной жизни это уж совсем редкость )
А я если честно надеялся, что умные и образованные айтишники все же задумаются о том что тупизна бывает показательной а не только врожденной и применяется с определенной целью.
Рад что у вас есть выбор, да еще настолько большой, что вы даже посреди кризиса и спада экономики готовы предъявлять претензии работодателю.
Знаете как получилось, что из всего выпуска 2005 года на Хабре пишу только я один?
Выпускалось с дипломом «инженер‑программист» в тот год что‑то около сотни человек, если память не изменяет. Прошло 20 лет и все, никого нет.
Как думаете, куда делись одногруппники, коллеги по многочисленным работам?
Они сошли с дистанции — большинство одногруппников ушло из ИТ в течение первых пяти лет, часть вообще никогда не работала по специальности. Кого‑то уже нет в живых.
Тоже самое с коллегами, в самом лучшем случае часть из них еще как-то присутствует в ИТ-отрасли в виде менеджмента, но сопоставимых технических компетенций больше нет.
Так что увы, но основной критерий успешности (статистически) это самое банальное выживание — даже после 10 лет практики о конкуренции можно не задумываться, после 20 ее просто нет.