По DMZ — нет, я к моменту перехода на атаки через перехват/модификацию трафика забросил атаки на сервисы — долго изучал все, там не было перспективных, уходящих внутрь сети.
Про встроенный NTLM граббер не знал, спасибо.
Cain там появился первым, так вышло. Когда его резко перестало хватать по функциям — появился Intercepter.
Так то да. Раскрою еще деталей — обработку 1С пытались делать для запуска на сервере, но прав не хватило, и она работала только на клиенте. Но не пропадать же такому добру)
Добрый день! Отвечу по порядку:
1. Делался доступ L3, L2 тоже возможен — надо поднять на TAP-адаптерах туннель OpenVPN, и сделать bridge TAP-интерфейса с Ethernet-интерфейсом на скомпрометированной машине. Но делать так не советую, доступ к серверу потеряется. Если не изменяет память, на вновь созданном bridge-интерфейсе не будет IP-адреса, то есть упадет все сразу. Да и в целом это не нужно — если есть права администратора, все бонусы L2 можно получить непосредственно на удаленном сервере.
2. Да, Windows не форвардит пакеты по умолчанию. До меня на сервере стояла ISA, я ее заменил на RRAS, специально форвардинг пакетов не включал — либо эти службы сами его включали, либо его включили до меня. Сервер пережил ни одну перезагрузку в процессе настроек.
3. Инструментов для ARP spoofing много. Если интересует только перехват трафика без модификации, советую отдельно писать трафик сниффером типа tcpdump/tshark, отдельно — делать перехват. Потом уже парсить пойманный трафик разными инструментами. Чем будет сделан перехват в таком случае – вопрос не сильно принципиальный.
4. Кто где локальный админ BloodHound узнает двумя путями:
— С самих машин через вызов WinAPI NetLocalGroupEnum (netapi32.dll) см. тут docs.microsoft.com/en-us/windows/win32/api/lmaccess/nf-lmaccess-netlocalgroupenum, либо через ADSI.
— через просмотр файлов объектов групповых политик на шаре Sysvol контроллера домена через SMB.
В обоих случаях доступ может быть получен с обычной непривилегированной доменной учетной записью. Почему такая не очень безопасная возможность есть, я про первый вариант – вопрос к Microsoft)
Еще больше деталей от первоисточника: www.harmj0y.net/blog/redteaming/local-group-enumeration
Т.к. важен «разбор полетов» после инцидентов. Если у всех персональные учетки, при включенном аудите найти источник значительно проще, чем в случае, если толпа будет пользоваться одним общим root. Кто-то поменял пароль root из sudo — пожалуйста, только это инцидент. Знать root — на аварийные случаи, когда все владельцы персональных учеток внезапно кончились.
Пароли у ключей ssh это само собой, иначе это будет как пароль на бумажке под клавиатурой.
Атака через WPAD в общем случае возможна, когда он не настроен. Т.е. клиенты ищут прокси, а инфраструктура не предлагает сервер конфигурации. В этом случае возможно навязывание злоумышленником своего сервера. Чтобы ее предотвратить, можно либо отключить WPAD (там где прокси не было и не будет), либо настроить WPAD, для случаев, когда используется прокси.
Кстати, путешествующий за пределы офиса ноутбук из домена не самое лучшее решение для безопасности сети.
— Плох тем, что:
1. Видно внутренние сервисы через инет. Их можно исследовать, вынимая скрытую информацию, вплоть до критическо значимой для потенциальной атаки. Их можно ломать, и, если нет изоляции типа DMZ, то привет вся внутренняя сеть, и дальнейшие атаки.
2. Без VPN с шифрованием — еще добавляется вероятность атаки типа Mitm на подключающегося во внутреннюю сеть через интернет. Тут и кражи прав доступа, и прослушка трафка, и другие прелести.
3. Если пробрасывать порт, и таким образом давать удаленный доступ, например, по RDP без VPN, вы не сможете устроить хороший разбор полетов в случае проблем. VPN же добавит в логи конкретное имя пользователя на сетевую железку, а они обычно более устойчивы к взломам, чем серверы.
— Ресурсы — google: nmap online. Можно делать самостоятельно от другого подключения к инету, но со сканом даже своего адреса надо аккуратнее, это не то, что можно легко советовать.
Это все-таки мое личное мнение, не пытаюсь его возвести в абсолютную истину. Я рассуждал так. Предположим наличие двух наиболее частых вариантов авторизации через ssh — по сертификату, и по паролю. Во втором случае, зная только один пароль пользователя, можно получить root. С сертификатом авторизация, конечно, спасет от такого сценария. Но. Есть вариант авторизации на консоли сервера (физ. доступ, IP KVM). Тогда даже с сертификатом на ssh sudo опять даст прямой root при авторизации через консоль. Конечно я привел много условностей, пароль root можно точно так же похитить, а консоль защитить, но все-же, отдельный root это дополнительный полуфактор авторизации.
Вопрос применения sudo/чистого root для одного админа, кмк, остается на совести конкретного администратора, его привычек, опыта и оценки других факторов защиты сервера. У sudo однозначно есть свои большие плюсы, которые лучше всего себя проявят в многопользовательском сервере.
Спасибо за интересную информацию.
Что же поделать, если SMTP и другие почтовые протоколы разрабатывали очень давно, когда все было белое и пушистое, авторизаций не было, спуфингом никто не занимался. Остается только добавлять костыли, которые будут все усложнять.
Добавлю небольшую историю про фейлы SPF. Мои коллеги нашли у одного очень крупного почтового сервиса, который предоставляет услуги типа «почта для вашего домена» интересный баг (передаю привет автору находки randomib). Есть домен с spf, где в конце стоит ~all, остальные настройки говорят сомнительным письмам строго валиться в спам. Так оно и происходит, за исключением одной ситуации. При отправке внутридоменного фишинга на групповой ящик рассылки происходит форвардинг письма сервисом самому себе, SPF приобретает статус pass вместо softfail. Письмо радостно попадает в инбокс как правильное. Производитель сервиса это багом не считает, говорит, сами смотрите заголовки, проверяйте DKIM. А строгий DKIM мало кто может сделать, так как назло найдется что-то, что его не умеет применять.
Но несмотря на это, рядовым компаниям все-таки стоит задуматься насчет SPF, у них наверняка нет пожизненных ящиков и прочих экзотических атрибутов.
>?all — просто утверждает что ваши пользователи могут быть за пределами вашей сети
SPF не предназначен для пользователей. Пользователи абсолютно легитимно авторизуются на Mail submission agent через SMTP с авторизацией, либо через веб-клиент из любой локации. SPF предназначен для получателя, чтобы тот смог оценить достоверность писем от вас.
>он-же обеспечивает нормальную пересылку почты(forward)
Тут сложнее. SPF по механизму действия ломает «классический» форвард, но с другой стороны, это в первую очередь проблема кривой настройки сервера-форвардера, а не владельца SPF.
Насчет примеров — намного лучше по некторым вопросам ни на кого не смотреть. Я не говорю, что в Вэльсе или Принстоне кривой SPF. Я имею в виду, что если они так сделали, это их решение, и почему они его приняли, мы не узнаем. Для другой системы подобная настройка может привести к легкому засылу фишинга.
?all — это еще хуже, чем ~all. Последнее хоть намекает, что письмо поддельное, а первое «разводит руками». Частичное спасение — проверка подписью DKIM. Частичное потому, что при общей неправильной политике DMARC ваши письма не будут доходить по получателей.
Нужно пересмотреть ваши маршруты почты, и четко определить, кто доверенный, исходя их этого писать DMARC.
Не согласен. Я делал упор на то, что делается своими руками, и без дозакупок. Не уверен, что тетя Глаша у вас создает кривые групповые политики, и конфигурит ssh.
Задача безопасника/админа — организовать правильную настройку того, на что можно повлиять, а про остальное — вовремя и правильно донести риски тому, кто «выше». Если вы все сделали правильно — риски уже не ваши, вы сделали все, что от вас зависело.
Cain там появился первым, так вышло. Когда его резко перестало хватать по функциям — появился Intercepter.
1. Делался доступ L3, L2 тоже возможен — надо поднять на TAP-адаптерах туннель OpenVPN, и сделать bridge TAP-интерфейса с Ethernet-интерфейсом на скомпрометированной машине. Но делать так не советую, доступ к серверу потеряется. Если не изменяет память, на вновь созданном bridge-интерфейсе не будет IP-адреса, то есть упадет все сразу. Да и в целом это не нужно — если есть права администратора, все бонусы L2 можно получить непосредственно на удаленном сервере.
2. Да, Windows не форвардит пакеты по умолчанию. До меня на сервере стояла ISA, я ее заменил на RRAS, специально форвардинг пакетов не включал — либо эти службы сами его включали, либо его включили до меня. Сервер пережил ни одну перезагрузку в процессе настроек.
3. Инструментов для ARP spoofing много. Если интересует только перехват трафика без модификации, советую отдельно писать трафик сниффером типа tcpdump/tshark, отдельно — делать перехват. Потом уже парсить пойманный трафик разными инструментами. Чем будет сделан перехват в таком случае – вопрос не сильно принципиальный.
4. Кто где локальный админ BloodHound узнает двумя путями:
— С самих машин через вызов WinAPI NetLocalGroupEnum (netapi32.dll) см. тут docs.microsoft.com/en-us/windows/win32/api/lmaccess/nf-lmaccess-netlocalgroupenum, либо через ADSI.
— через просмотр файлов объектов групповых политик на шаре Sysvol контроллера домена через SMB.
В обоих случаях доступ может быть получен с обычной непривилегированной доменной учетной записью. Почему такая не очень безопасная возможность есть, я про первый вариант – вопрос к Microsoft)
Еще больше деталей от первоисточника: www.harmj0y.net/blog/redteaming/local-group-enumeration
Пароли у ключей ssh это само собой, иначе это будет как пароль на бумажке под клавиатурой.
Кстати, путешествующий за пределы офиса ноутбук из домена не самое лучшее решение для безопасности сети.
1. Видно внутренние сервисы через инет. Их можно исследовать, вынимая скрытую информацию, вплоть до критическо значимой для потенциальной атаки. Их можно ломать, и, если нет изоляции типа DMZ, то привет вся внутренняя сеть, и дальнейшие атаки.
2. Без VPN с шифрованием — еще добавляется вероятность атаки типа Mitm на подключающегося во внутреннюю сеть через интернет. Тут и кражи прав доступа, и прослушка трафка, и другие прелести.
3. Если пробрасывать порт, и таким образом давать удаленный доступ, например, по RDP без VPN, вы не сможете устроить хороший разбор полетов в случае проблем. VPN же добавит в логи конкретное имя пользователя на сетевую железку, а они обычно более устойчивы к взломам, чем серверы.
— Ресурсы — google: nmap online. Можно делать самостоятельно от другого подключения к инету, но со сканом даже своего адреса надо аккуратнее, это не то, что можно легко советовать.
Вопрос применения sudo/чистого root для одного админа, кмк, остается на совести конкретного администратора, его привычек, опыта и оценки других факторов защиты сервера. У sudo однозначно есть свои большие плюсы, которые лучше всего себя проявят в многопользовательском сервере.
Что же поделать, если SMTP и другие почтовые протоколы разрабатывали очень давно, когда все было белое и пушистое, авторизаций не было, спуфингом никто не занимался. Остается только добавлять костыли, которые будут все усложнять.
Добавлю небольшую историю про фейлы SPF. Мои коллеги нашли у одного очень крупного почтового сервиса, который предоставляет услуги типа «почта для вашего домена» интересный баг (передаю привет автору находки randomib). Есть домен с spf, где в конце стоит ~all, остальные настройки говорят сомнительным письмам строго валиться в спам. Так оно и происходит, за исключением одной ситуации. При отправке внутридоменного фишинга на групповой ящик рассылки происходит форвардинг письма сервисом самому себе, SPF приобретает статус pass вместо softfail. Письмо радостно попадает в инбокс как правильное. Производитель сервиса это багом не считает, говорит, сами смотрите заголовки, проверяйте DKIM. А строгий DKIM мало кто может сделать, так как назло найдется что-то, что его не умеет применять.
Но несмотря на это, рядовым компаниям все-таки стоит задуматься насчет SPF, у них наверняка нет пожизненных ящиков и прочих экзотических атрибутов.
SPF не предназначен для пользователей. Пользователи абсолютно легитимно авторизуются на Mail submission agent через SMTP с авторизацией, либо через веб-клиент из любой локации. SPF предназначен для получателя, чтобы тот смог оценить достоверность писем от вас.
>он-же обеспечивает нормальную пересылку почты(forward)
Тут сложнее. SPF по механизму действия ломает «классический» форвард, но с другой стороны, это в первую очередь проблема кривой настройки сервера-форвардера, а не владельца SPF.
Насчет примеров — намного лучше по некторым вопросам ни на кого не смотреть. Я не говорю, что в Вэльсе или Принстоне кривой SPF. Я имею в виду, что если они так сделали, это их решение, и почему они его приняли, мы не узнаем. Для другой системы подобная настройка может привести к легкому засылу фишинга.
Нужно пересмотреть ваши маршруты почты, и четко определить, кто доверенный, исходя их этого писать DMARC.
Задача безопасника/админа — организовать правильную настройку того, на что можно повлиять, а про остальное — вовремя и правильно донести риски тому, кто «выше». Если вы все сделали правильно — риски уже не ваши, вы сделали все, что от вас зависело.