Ну почему же "не осинт") Просто если написать "купите подписку на Кронос" будет неинтересно. Интереснее было подсветить что под капотом подобных ПО. А еще бы потом тапками за рекламу софта закидали бы)))
Это вообще очень весело. Когда руководитель СБ бывший полицейский или военный связанный с ЗГТ, то берут просто форму по допуску к ГТ и бахают ее кандидату. Маразм конечно неадекватных размеров...
Все верно. С точки зрения правильности Ваш вариант подойдет лучше, но полагаю проблема была в том, что решения нужно было сделать быстро, а проверку отклонения транзакции нужно было допиливать раз ее не было раньше. Как итог во впопыхах начали просто блочить продавцов.
Если сначала человек сопоставил Вашу доп фразу по утечкам баз, а потом пошел и вскрыл Ваш менеджер паролей, то скорее всего это таргетированная атака лично на Вас и тут как бы вообще мало что спасет, потому что хакает не Вася Script Kiddie и не случайный китайский хакер получивший случайно доступ к Вашему ПК...
Опять же ничего не мешает сделать первую часть пароля длинной в 20-30 символов, а вместо Пушистик или чего-то осознанного использовать 12-20 значный рандомный пароль. В этом случае ок доп фразу узнали это - 12-20 символов, остаются остальные 20-30+ символов которые мы сгенерили рандомно. Прибавляем к этому двуфакторку.
Метод №2 в целом предназначен для попытки защиты именно от факта компрометации менеджера паролей. Опять же повторюсь: от таргетированной атаки на конкретного человека вообще мало какие методы помогут.
По поводу публичных сервисов я в целом согласен. Но полагаю в корп сегменте все еще валидный метод для защиты паролей от серверов и учеток. Мы же не храним в 1й базе и личные и рабочие пароли. На работе свой KeePass со своей базой. И в корп сегменте утечка парольной базы в открытом виде не частое явление.
Чаще вектором атаки становится компрометация компа админа и вскрытие базы KeePass или поиск текстовика с паролями, либо Brute Force по спискам утечек и патернам генерации УЗ в домене (например - Фамилия.Первая буква имени).
Так вот в том-то и дело, что не в бобине и не в дефолтных паролях. Дефолтные пароли — это самый простой сценарий атаки. И даже он дает результат. Собственно вопрос не про компетентность людей с кредами kali:kali, а про то, что таким же методом можно пульнуть вообще любой эксплойт…
Но не будем забывать, что OffensiveSecurity более закрытый и профессиональный лабораторный практикум, а TryHackMe ориентируется на новичков, которые могут еще не до конца разбираться в вопросе. И единоразовых пользователей у них несоизмеримо больше в единицу времени, нежели у тех же Offensive.
Одновременно с этим, если я правильно помню, то даже у Офенсивов при подключении к VPN Вы не можете от себя взаимодействовать с другими пользаками. Если блочить подобно поведение пользователей смысла нет, то тогда зачем делать это ограничение? Пункт Лицухи, что ВЫ ПРЕДУПРЕЖДЕНЫ и все дела. Всех в одну сеть с правилами ANY ANY. Однако на практике мы имеем всё-таки наличие запрета на прямое взаимодействие машин пользователей между собой. Зачем?
Опять же подчеркну. На мой взгляд сравнение с Offensive не корректно, так как в этом Лабораторном практикуме нет новичков. Только люди, которые знают и понимают что к чему и зачем пришли.
На TryHackMe дела обстоят иначе. Тут люди даже с нулевым уровнем в инфобезе могут быть, соответственно такой же аргумент к ним не применим. Иначе мы скатываемся в оправдание уровня "Пенсионеров можно обманывать, так как они ни чего не понимают в технологиях/финансах/*вставить нужную отрасль современной жизни*".
Если у тебя платформа для новичков, то обеспечь максимальный уровень защиты, потому что люди могут еще не знать что и к чему. ИМХО. Если платформа для профессионалов, то могут быть некоторые послабления.
Полностью согласен с Вами. Что попало в интернет — то осталось там навсегда и стало общим. Я тоже считаю, что если не уверен, что твоя личная информация не повернется против тебя — не публикуй ее.
Люди в целом ленивые) Особенно всего что касается интернета. Даже не представляешь сколько людей используют одинаковые или похожие ники. Вот например сервис для проверки совпадения для открытых соц сетей. namechk.com
Даркнет, в данном случае, не исключение. Человек мог сделать это машинально (зарегаться под привычным ником) и даже не подумать о подобном.
В интернете в целом нет уверенности, что человек на фото и есть тот, кто в реальности. Ну а по поводу генетического разнообразия — на 7 миллиардов всего 2 двойника — по моему очень отличное разнообразие) Даже у «однояйцовых» близнецов есть отличия во внешности. Вопрос лишь в том, сколько факторов биометрии лица мы рассматриваем. В Китае сейчас вообще полным ходом идет тюнинг системы под распознавание лиц под факт ношения хирургических масок…
Думаю ценник там не дороже чем само maltego. А вот по поводу графа аффилированности на российском рынке можете посмотреть сервис List.org. Он сам такие графики строит на основе ЕГРЮЛ. Правда интерактивность там так себе)
Ага) В нашем мире «посадки» за репост теперь только так( Эх, был же интернет в 2007 году… Мамку любого можно было оттаскать и все ок. А теперь даже IP не нужен чтобы вычислять) Может оно конечно и к лучшему, но лично я скучаю по тому старому доброму интернету. И дело даже не в «мамках», а в том, что тебе в целом не нужно было тогда особо париться как твои слова будут истолкованы спустя время… Блин! Надо книжку «Чиполино» выкинуть! А то не ровен час экстремистской литературой признают. Блин! «Незнайка на луне» же еще!))))
P.S. В пятой статье будет тест функционала распознавания лиц на фото через Social Links.
Тут я имел ввиду работу по количеству опознающих признаков. Например: нам нужно построить связи между 2мя группами людей по признаку общего места работы и района проживания. Постепенное продвижение, в данном случае, выглядит как работа сначала по признаку «общего места работы», а потом по признаку «общий район проживания» или наоборот. Если Вы попытаетесь работать сразу по 2-3 признакам одновременно, то Вы рискуете либо что-то пропустить, либо получить мешанину связей, которую потом будет очень трудно разгребать. Количественный состав групп людей в данном случае особой роли не играет)
С опытом работы я для себя вывел, что именно это оптимальный метод работы даже при ресерче по одному человеку. Сначала базовые биографические данные, потом соц. сети, потом каждая соц. сеть по отдельности с делением на этапы проработки по контактам, постам, фото, видео и т.д.
P.S. Maltego как раз и служит для некой автоматизации процесса построения связей между большими группами объектов) Для еще более пущей автоматизации можно создать «Machinеs». Их я вскользь упоминал при разборе интерфейса во второй статье.
Относительно API от SL. Тут я полагаю они имеют ввиду, что можно использовать их API для интеграции их решений в свое ПО. Наша компания пока что не занимается разработкой OSINT ПО по этому не интересовался как у них он работает)
По порядку цен. Тут конкретно к сожалению не могу сказать, так как ПО на всю нашу дружную команду закупало руководство и какие у них договоренности с Social Links я, к сожалению, не в курсе. По общему ценообразованию: вам потребуется либо Maltego Classic, либо Maltego XL, а уже поверх него накатывается SL. Опять же Social Links позиционирует свой продукт, как корпоративное решение и по этому нет смысла вываливать ценник на сайт. Как по мне, так это стандартная корп практика. Даже у тех же PATERVA на сайте отдельный раздел, если покупает организация. Так что тут скорее как у всех)))
Заходите на сайт www.mtg-bi.com Там оставляете запрос на тест. С Вами свяжется менеджер и далее уже все вопросы по порядку тестирования продукта и методах покупки обговариваете с ним. Стандартная схема покупки подобных систем.
Ну почему же "не осинт") Просто если написать "купите подписку на Кронос" будет неинтересно. Интереснее было подсветить что под капотом подобных ПО. А еще бы потом тапками за рекламу софта закидали бы)))
Это вообще очень весело. Когда руководитель СБ бывший полицейский или военный связанный с ЗГТ, то берут просто форму по допуску к ГТ и бахают ее кандидату. Маразм конечно неадекватных размеров...
В примере про Wildberries как раз рассказывается как под удар попала именно компания
Все верно. С точки зрения правильности Ваш вариант подойдет лучше, но полагаю проблема была в том, что решения нужно было сделать быстро, а проверку отклонения транзакции нужно было допиливать раз ее не было раньше. Как итог во впопыхах начали просто блочить продавцов.
Если сначала человек сопоставил Вашу доп фразу по утечкам баз, а потом пошел и вскрыл Ваш менеджер паролей, то скорее всего это таргетированная атака лично на Вас и тут как бы вообще мало что спасет, потому что хакает не Вася Script Kiddie и не случайный китайский хакер получивший случайно доступ к Вашему ПК...
Опять же ничего не мешает сделать первую часть пароля длинной в 20-30 символов, а вместо Пушистик или чего-то осознанного использовать 12-20 значный рандомный пароль. В этом случае ок доп фразу узнали это - 12-20 символов, остаются остальные 20-30+ символов которые мы сгенерили рандомно. Прибавляем к этому двуфакторку.
Метод №2 в целом предназначен для попытки защиты именно от факта компрометации менеджера паролей. Опять же повторюсь: от таргетированной атаки на конкретного человека вообще мало какие методы помогут.
По поводу публичных сервисов я в целом согласен. Но полагаю в корп сегменте все еще валидный метод для защиты паролей от серверов и учеток. Мы же не храним в 1й базе и личные и рабочие пароли. На работе свой KeePass со своей базой. И в корп сегменте утечка парольной базы в открытом виде не частое явление.
Чаще вектором атаки становится компрометация компа админа и вскрытие базы KeePass или поиск текстовика с паролями, либо Brute Force по спискам утечек и патернам генерации УЗ в домене (например - Фамилия.Первая буква имени).
Но не будем забывать, что OffensiveSecurity более закрытый и профессиональный лабораторный практикум, а TryHackMe ориентируется на новичков, которые могут еще не до конца разбираться в вопросе. И единоразовых пользователей у них несоизмеримо больше в единицу времени, нежели у тех же Offensive.
Одновременно с этим, если я правильно помню, то даже у Офенсивов при подключении к VPN Вы не можете от себя взаимодействовать с другими пользаками. Если блочить подобно поведение пользователей смысла нет, то тогда зачем делать это ограничение? Пункт Лицухи, что ВЫ ПРЕДУПРЕЖДЕНЫ и все дела. Всех в одну сеть с правилами ANY ANY. Однако на практике мы имеем всё-таки наличие запрета на прямое взаимодействие машин пользователей между собой. Зачем?
Опять же подчеркну. На мой взгляд сравнение с Offensive не корректно, так как в этом Лабораторном практикуме нет новичков. Только люди, которые знают и понимают что к чему и зачем пришли.
На TryHackMe дела обстоят иначе. Тут люди даже с нулевым уровнем в инфобезе могут быть, соответственно такой же аргумент к ним не применим. Иначе мы скатываемся в оправдание уровня "Пенсионеров можно обманывать, так как они ни чего не понимают в технологиях/финансах/*вставить нужную отрасль современной жизни*".
Если у тебя платформа для новичков, то обеспечь максимальный уровень защиты, потому что люди могут еще не знать что и к чему. ИМХО. Если платформа для профессионалов, то могут быть некоторые послабления.
Даркнет, в данном случае, не исключение. Человек мог сделать это машинально (зарегаться под привычным ником) и даже не подумать о подобном.
Часть 2:Facebook плачет, Social Links смеется, Maltego курит
P.S. В пятой статье будет тест функционала распознавания лиц на фото через Social Links.
Тут я имел ввиду работу по количеству опознающих признаков. Например: нам нужно построить связи между 2мя группами людей по признаку общего места работы и района проживания. Постепенное продвижение, в данном случае, выглядит как работа сначала по признаку «общего места работы», а потом по признаку «общий район проживания» или наоборот. Если Вы попытаетесь работать сразу по 2-3 признакам одновременно, то Вы рискуете либо что-то пропустить, либо получить мешанину связей, которую потом будет очень трудно разгребать. Количественный состав групп людей в данном случае особой роли не играет)
С опытом работы я для себя вывел, что именно это оптимальный метод работы даже при ресерче по одному человеку. Сначала базовые биографические данные, потом соц. сети, потом каждая соц. сеть по отдельности с делением на этапы проработки по контактам, постам, фото, видео и т.д.
P.S. Maltego как раз и служит для некой автоматизации процесса построения связей между большими группами объектов) Для еще более пущей автоматизации можно создать «Machinеs». Их я вскользь упоминал при разборе интерфейса во второй статье.
Относительно API от SL. Тут я полагаю они имеют ввиду, что можно использовать их API для интеграции их решений в свое ПО. Наша компания пока что не занимается разработкой OSINT ПО по этому не интересовался как у них он работает)
По порядку цен. Тут конкретно к сожалению не могу сказать, так как ПО на всю нашу дружную команду закупало руководство и какие у них договоренности с Social Links я, к сожалению, не в курсе. По общему ценообразованию: вам потребуется либо Maltego Classic, либо Maltego XL, а уже поверх него накатывается SL. Опять же Social Links позиционирует свой продукт, как корпоративное решение и по этому нет смысла вываливать ценник на сайт. Как по мне, так это стандартная корп практика. Даже у тех же PATERVA на сайте отдельный раздел, если покупает организация. Так что тут скорее как у всех)))