March 8

Kali Ashes. Закаляем хакерский дистр и учимся не шуметь в сети

  1. Above
  2. Обращение к репозиториям
  3. Операции с хостнеймом системы
  4. TTL
  5. Отключение NTP
  6. Работа с netfilter
  7. Отключение ICMP Redirect
  8. Рандомизация MAC-адреса
  9. Минимизация шума
  10. F31
  11. Выводы

Дис­три­бутив Kali Linux неверо­ятно популя­рен сре­ди пен­тесте­ров. Одна­ко при про­ник­новении в сеть с нас­трой­ками по умол­чанию он может соз­дать мно­го шума в эфи­ре, который не оста­нет­ся незаме­чен­ным. В этой статье я рас­ска­жу о хар­денин­ге Kali и о том, как научить Linux работать в наибо­лее тихом режиме.

Что­бы мож­но было авто­мати­зиро­вать нас­трой­ку, я недав­но зарели­зил инс­тру­мент F31, написан­ный на Bash. Даль­ше мы под­робно раз­берем, что имен­но он дела­ет.

Эта статья и F31 не гаран­тиру­ют тебе стоп­роцен­тный обход сис­тем, за которы­ми приг­лядыва­ет SOC, но ты зна­читель­но сни­зишь веро­ятность спа­лить­ся. Каж­дый пен­тест сети уни­кален, и написать уни­вер­саль­ное решение вряд ли воз­можно. Уве­рен, что есть и дру­гие спо­собы умень­шить шум в эфи­ре. Но мы сос­редото­чим­ся на глав­ных момен­тах.

ABOVE

Above — еще один мой инс­тру­мент, это сетевой сниф­фер про­токо­лов для поис­ка уяз­вимос­тей в сетевом обо­рудо­вании. Его работа осно­вана толь­ко на ана­лизе тра­фика, что не соз­дает никако­го шума в эфи­ре.

Он охва­тыва­ет сле­дующие про­токо­лы:

  • L2: CDP, LLDP, DTP, 802.1Q Frames;
  • L3: OSPF, EIGRP, VRRP, HSRP;
  • L7: LLMNR, NBT-NS, MDNS, SSDP, MNDP.

Кста­ти говоря, Above недав­но вклю­чили в Kali Linux! Ты можешь уста­новить его пря­мо из репози­тори­ев Kali:

sudo apt update && sudo apt install above above --help

Что­бы начать ана­лизи­ровать тра­фик:

sudo above --interface eth0 --timer 250 --output-pcap vettel.pcap

Здесь

  • --interface eth0 — интерфейс сис­темы;
  • --timer 250 — вре­мя, в течение которо­го будет про­водить­ся ана­лиз;
  • --output-pcap — файл дам­па тра­фика, куда Above запишет все, что смо­жет най­ти.
При­мер работы Above

С помощью Above мож­но искать век­торы атак на сеть и при этом не соз­давать никако­го шума в эфи­ре.

ОБРАЩЕНИЕ К РЕПОЗИТОРИЯМ

Ес­ли во вре­мя работы в сети в рам­ках пен­теста ты обра­тишь­ся к репози­тори­ям Kali, имей в виду, что SOC может сра­зу обна­ружить это дей­ствие. Даже если вклю­чить обра­щение к репози­тори­ям через HTTPS, ты все рав­но можешь спа­лить­ся по DNS-зап­росу.

ОПЕРАЦИИ С ХОСТНЕЙМОМ СИСТЕМЫ

Да‑да‑да, совет менять хос­тнейм Kali — это страш­ный баян. Тем не менее дефол­тный хос­тнейм Kali так и оста­ется глав­ным инди­като­ром обна­руже­ния это­го дис­тра в сети.

Ре­шение прос­тое до безоб­разия. Мы не толь­ко поменя­ем имя сис­темы, но и заод­но зап­ретим переда­чу хос­тней­ма в пакетах DHCP, которые ухо­дят, ког­да ата­кующий пыта­ется получить адрес в сети.

sudo hostnamectl set-hostname DESKTOP-HNA2AEVS sudo sed -i "s/127.0.1.1.*/127.0.1.1\tDESKTOP-HNA2AEVS/" /etc/hosts

От­клю­чить переда­чу име­ни сис­темы по DHCP мож­но в connection-фай­лах NetworkManager, добавив параметр dhcp-send-hostname=false:

sudo sed -i '/\[ipv4\]/a dhcp-send-hostname=false' /etc/NetworkManager/system-connections/Wired\ connection\ 1

TTL

Для дис­три­бути­вов Linux зна­чение TTL рав­но 64. Мож­но изме­нить стан­дар­тное зна­чение TTL в сис­теме. Если хочешь при­кинуть­ся Windows, выбирай TTL 128.

sudo sysctl -w net.ipv4.ip_default_ttl=80

Ес­ли у тебя пла­ны про­водить MITM в сети, то можешь скрыть свой адрес в трас­сиров­ке со сто­роны легитим­ных хос­тов. Очень прос­той трюк в виде сме­щения TTL с инкре­мен­том +1:

sudo iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-inc 1

ОТКЛЮЧЕНИЕ NTP

Твоя сис­тема может пери­оди­чес­ки обра­щать­ся к NTP-сер­веру для син­хро­низа­ции акту­аль­ного вре­мени. В Kali пери­оди­чес­ки про­исхо­дит обра­щение к NTP по име­ни DNS.

За­то отклю­чить син­хро­низа­цию вре­мени в Kali очень прос­то:

sudo systemctl stop systemd-timesync

РАБОТА С NETFILTER

Нам нуж­но раз­решить уста­нов­ленные и свя­зан­ные меж­ду собой соеди­нения, бло­киро­вать некор­рек­тные и бло­киро­вать TCP-сег­менты с неожи­дан­ными зна­чени­ями TCP MSS. А так­же филь­тро­вать ICMP-тра­фик и вык­лючить пин­ги. Одна­ко будь осто­рожен: не заб­локируй слу­чай­но ICMP Type 3, который поз­воля­ет сис­теме PMTUD избе­гать избы­точ­ной фраг­мента­ции.

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT sudo iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP sudo iptables -A INPUT -p icmp --icmp-type 0 -m conntrack --ctstate NEW -j ACCEPT sudo iptables -A INPUT -p icmp --icmp-type 3 -m conntrack --ctstate NEW -j ACCEPT sudo iptables -A INPUT -p icmp --icmp-type 11 -m conntrack --ctstate NEW -j ACCEPT sudo iptables -A INPUT -p icmp -j DROP sudo iptables -t mangle -A PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP

ОТКЛЮЧЕНИЕ ICMP REDIRECT

Ре­дирек­ты ICMP слу­чают­ся при MITM-ата­ках. На сооб­щения ICMP redirect могут стриг­герить­ся сис­темы IDS/IPS, что ском­про­мети­рует дей­ствия ата­кующе­го. Давай вык­лючим эти сооб­щения.

sudo sysctl -w net.ipv4.conf.all.accept_redirects=0 sudo sysctl -w net.ipv6.conf.all.accept_redirects=0

РАНДОМИЗАЦИЯ MAC-АДРЕСА

Клас­сика жан­ра: сме­на MAC-адре­са на сво­ем интерфей­се. Думаю, пояс­нять этот пункт нет необ­ходимос­ти.

sudo ifconfig eth0 down sudo macchanger -r eth0 sudo ifconfig eth0 up

Так­же мож­но нас­тро­ить NetworkManager так, что­бы при каж­дом под­клю­чении к сети MAC-адрес менял­ся на слу­чай­ный.

echo -e "\n[connection]\nwifi.cloned-mac-address=random\n\n[connection]\nethernet.cloned-mac-address=random" | sudo tee -a /etc/NetworkManager/NetworkManager.conf

МИНИМИЗАЦИЯ ШУМА

Пен­тесте­ры вынуж­дены в сво­ей работе исполь­зовать ска­неры (Netdiscover, Nmap и про­чие), одна­ко при запус­ке с уста­нов­ками по умол­чанию эти ска­неры соз­дают очень боль­шой шум в эфи­ре. Мало того что повыша­ется риск ком­про­мета­ции дей­ствий ата­кующе­го, так еще есть веро­ятность перег­рузить сетевой ком­мутатор (осо­бен­но если мы говорим о быс­тром ARP-ска­ниро­вании). Тре­вогу может забить и сис­тема Storm Control, которая управля­ет огра­ниче­ниями лимитов UCAST/MCAST/BCAST-тра­фика.

Я нашел воз­можность миними­зиро­вать шум в эфи­ре с помощью огра­ниче­ния ско­рос­ти на интерфей­се сис­темы. Мож­но резать ско­рость на интерфей­се до 30 Кбит/с, выс­тавив задер­жку 800 мс, что­бы тот же Netdiscover не вызывал перег­рузку в эфи­ре. Разуме­ется, такой фикс пов­лияет на ско­рость работы ска­нера и ско­рость переда­чи дан­ных, но все это толь­ко ради избе­жания перег­рузки. Зна­чения я опре­делил в сво­их наб­людени­ях, одна­ко не стес­няй­ся регули­ровать их при необ­ходимос­ти.

Для шей­пин­га я исполь­зовал ути­литу tc (traffic control):

sudo tc qdisc add dev eth0 root tbf rate 30kbit burst 30kbit latency 800ms

Ни­же скрин­шоты с работой ска­неров Netdiscover и Nmap. Коман­ды запус­ка были сле­дующие:

sudo netdiscover -i eth0 sudo nmap -n 10.10.100.0/24

Об­ращай вни­мание на Outgoing — ути­лита nload показы­вает этот исхо­дящий тра­фик (ког­да ты что‑то ска­ниру­ешь — это исхо­дящий тра­фик).

Ра­бота Netdiscover без шей­пин­га тра­фика
Ра­бота Netdiscover с шей­пин­гом
Ра­бота Nmap без шей­пин­га тра­фика
Ра­бота Nmap с шей­пин­гом

Ес­ли нуж­но уда­лить парамет­ры огра­ниче­ния тра­фика, то для это­го есть вот такая коман­да:

sudo tc qdisc del dev eth0 root

F31

Итак, я написал скрипт F31 для авто­мати­зации все­го про­цес­са нас­трой­ки. Скрипт пол­ностью нас­тра­ивает­ся, и запус­кать его нуж­но со спе­циаль­ными аргу­мен­тами.

Здесь

  • --interface — ука­зыва­ешь сетевой интерфейс сво­его Kali Linux;
  • --new-hostname — новый хос­тнейм для сво­его Kali Linux;
  • --noise-reduction — акти­вация того самого шей­пин­га тра­фика для миними­зации шума в эфи­ре. Параметр опци­ональ­ный, вклю­чай его при необ­ходимос­ти.

sudo bash F31.sh --interface eth0 --new-hostname DESKTOP-HNA2AEVS --noise-reduction

На слу­чай, если понадо­бит­ся отка­тить все изме­нения, я написал скрипт reset.sh, ты смо­жешь его най­ти в этом репози­тории:

sudo bash reset.sh --interface eth0 --old-hostname kali

ВЫВОДЫ

Я рас­ска­зал об основных иде­ях по поводу миними­зации шума в эфи­ре и хар­денин­га Kali Linux. Акцент всех эта­пов нас­трой­ки Kali Linux сде­лан имен­но на сетевом уров­не. Написать пол­ноцен­ный ману­ал по обхо­ду SOC вряд ли воз­можно, тем более всё не умес­тить в одну статью. Думаю, в будущем ты можешь ждать новые час­ти Kali Ashes.