Инструменты для поиска ip за cdn/waf

[monsoon]

Может кто-то знает более эффективные чем httpx инструменты для http probing'а ?
При работе с не очень сильной впской и достаточно крупным AS httpx может требоваться до нескольких дней.

Сам я пытался написать че то свое на расте, но вышло тяп-ляп и не очень стабильно, хоть и выдавало постоянные 500+ rps на очень слабой впске и в целом мне удалось просканить AS396982 (google cloud platform, us) за часов 6.

 

[creeper44]

Попробуй сделать на go с либой fasthttp, писать и дебажить на нем куда проще и быстрее чем на расте, мне удавалось получить rps в пару раз больше так же на дешевом vps, Еще проблема может быть в самом vps, возможно смена хостера поможет.

 

[zdestuta]

Может кто-то знает более эффективные чем httpx инструменты для http probing'а ?
При работе с не очень сильной впской и достаточно крупным AS httpx может требоваться до нескольких дней.

Сам я пытался написать че то свое на расте, но вышло тяп-ляп и не очень стабильно, хоть и выдавало постоянные 500+ rps на очень слабой впске и в целом мне удалось просканить AS396982 (google cloud platform, us) за часов 6.

httpx он упирается обычно не в сетку, а в ядра CPU, так как TLS столь массовый он "недешёвый" оказывается (сюрприз), а если ещё и DSL правила заюзал, то на проце можно чаёк себе вскипятить ещё заодно :-D
опять же httpx у него куча флагов и настроек, поэтому прога "заточеная" под конкретику конечно же уделает httpx (особенно если там ещё и DSL правила заюзаны) по производительности, но не по гибкости.
то есть по сути если у тебя задача именно вот такая и часто требуется и не меняется - смело пиши своё конечно же, но если сегодня ищеш одно, а завтра другое, а послезавтра третье, то переписывать куски кода (+риск ошибки) - это зайопывает и именно поэтому более общие тулзы типа httpx или даже nuclei имеют место быть - из-за их гибкости больше, а не из-за их скорости.

 

[zdestuta]

Может кто-то знает более эффективные чем httpx инструменты для http probing'а ?
При работе с не очень сильной впской и достаточно крупным AS httpx может требоваться до нескольких дней.

Сам я пытался написать че то свое на расте, но вышло тяп-ляп и не очень стабильно, хоть и выдавало постоянные 500+ rps на очень слабой впске и в целом мне удалось просканить AS396982 (google cloud platform, us) за часов 6.

Наверное очень глупый вопрос у меня, но всё же: а ты часом не забыл ну там всякие ulimit -n поднять и прочие вот такие штуки (см. далее) сделать?

touch /etc/sysctl.d/99-custom.conf

echo "net.core.rmem_max = 16777216" >> /etc/sysctl.d/99-custom.conf
echo "net.core.wmem_max = 16777216" >> /etc/sysctl.d/99-custom.conf
echo "net.core.netdev_max_backlog = 250000" >> /etc/sysctl.d/99-custom.conf
echo "net.core.somaxconn = 65535" >> /etc/sysctl.d/99-custom.conf
echo "net.ipv4.tcp_max_syn_backlog = 65536" >> /etc/sysctl.d/99-custom.conf
echo "net.ipv4.ip_local_port_range = 1024 65535" >> /etc/sysctl.d/99-custom.conf

sysctl -p /etc/sysctl.d/99-custom.conf

ulimit -n unlimited

вот такой типовой "разгончик сетки" сделал не забыл?

оно обычно при масскане помогает (особенно syn backlog), но для httpx и прочих тулов тоже полезно не менее.

 

[monsoon]

Наверное очень глупый вопрос у меня, но всё же: а ты часом не забыл ну там всякие ulimit -n поднять и прочие вот такие штуки (см. далее) сделать?

touch /etc/sysctl.d/99-custom.conf

echo "net.core.rmem_max = 16777216" >> /etc/sysctl.d/99-custom.conf
echo "net.core.wmem_max = 16777216" >> /etc/sysctl.d/99-custom.conf
echo "net.core.netdev_max_backlog = 250000" >> /etc/sysctl.d/99-custom.conf
echo "net.core.somaxconn = 65535" >> /etc/sysctl.d/99-custom.conf
echo "net.ipv4.tcp_max_syn_backlog = 65536" >> /etc/sysctl.d/99-custom.conf
echo "net.ipv4.ip_local_port_range = 1024 65535" >> /etc/sysctl.d/99-custom.conf

sysctl -p /etc/sysctl.d/99-custom.conf

ulimit -n unlimited

вот такой типовой "разгончик сетки" сделал не забыл?

оно обычно при масскане помогает (особенно syn backlog), но для httpx и прочих тулов тоже полезно не менее.

Не забыл, упор в cpu именно