Save Me. Защищаем сети от спуфинг-атак

Спу­финг‑ата­ки прос­ты в исполне­нии, но при этом несут огромный импакт. В этой статье мы погово­рим о них с точ­ки зре­ния защит­ников. Слож­ность в том, что­бы с умом интегри­ровать решения сетевой безопас­ности в про­дак­шен и при этом не сло­мать биз­нес‑про­цес­сы. При такой интегра­ции нуж­но хорошо понимать работу сети и осо­бен­ности обо­рудо­вания. Толь­ко тог­да тебя ждет успех.

Эта статья — ни в коем слу­чае не инс­трук­ция для защиты любой сети, потому что у каж­дой из них свои осо­бен­ности и всег­да пот­ребу­ется какой‑то тюнинг. Я буду демонс­три­ровать работу на обо­рудо­вании Cisco, но с железом дру­гого вен­дора прин­ципи­аль­ной раз­ницы нет. Кон­цепция механиз­мов безопас­ности вез­де оди­нако­вая, и отли­чия будут лишь в син­такси­се нас­тро­ек и некото­рых нюан­сах реали­зации.

Нем­ного особ­няком сто­ит толь­ко сис­тема RouterOS, на которой работа­ет обо­рудо­вание MikroTik. Там отсутс­тву­ет один из глав­ных, на мой взгляд, механиз­мов безопас­ности — Dynamic ARP Inspection. Вмес­то него про­изво­дитель фак­тичес­ки пред­лага­ет вес­ти толь­ко ста­тичес­кую ARP-таб­лицу, а, учи­тывая раз­меры сов­ремен­ных кор­поратив­ных сетей, это в прин­ципе нерен­табель­но. Так­же в RouterOS отсутс­тву­ет RA Guard, пре­дот­вра­щающий ата­ки на сер­вер DHCPv6.

Еще ого­ворюсь, что этот матери­ал — не все­объ­емлю­щий ману­ал по защите от спу­фин­га. Атак может быть бес­конеч­но мно­го, и мы рас­смот­рим лишь основные из них.

DHCP SNOOPING

DHCP Snooping — это фун­кция сетевой безопас­ности на уров­не ком­мутации. Она поз­воля­ет защитить сетевые сег­менты от атак на DHCP-сер­вер. К ним отно­сят­ся сле­дующие виды:

• DHCP Exhaustion — вызыва­ет исто­щение адресно­го прос­транс­тва на легитим­ном DHCP-сер­вере, рас­сылая лож­ные DHCPDISCOVER-сооб­щения от раз­ных MAC-адре­сов источни­ка. DHCP-сер­вер будет реаги­ровать на сооб­щения и выдавать адре­са. Пос­ле ата­ки DHCP-сер­вер не смо­жет обслу­жить новые хос­ты. Обыч­но эту ата­ку исполь­зуют либо для дес­трук­тивно­го воз­дей­ствия, либо для ата­ки DHCP Spoofing;
• DHCP Spoofing — соз­дание лож­ного DHCP-сер­вера, который будет обслу­живать кли­ентов сети. Опас­ность ата­ки зак­люча­ется в том, что ата­кующий в информа­ции о шлю­зе по умол­чанию прос­то уста­новит свой адрес и тем самым про­ведет MITM-ата­ку, так как тра­фик хос­тов будет идти в его сто­рону.

Нас­трой­ка Snooping — это, по сути, наз­начение доверен­ных и недове­рен­ных пор­тов. На недове­рен­ных пор­тах будут отсле­живать­ся все DHCP-сооб­щения. Цель в том, что­бы про­верить, сге­нери­рова­ны ли они DHCP-сер­вером. Ведь ежу понят­но: если в поль­зователь­ском сег­менте мы будем видеть сооб­щения вро­де DHCPLEASEQUERY, DHCPOFFER и DHCPACK, то это однознач­но ано­малия и в поль­зователь­ской сети находит­ся DHCP-сер­вер.

На доверен­ных же пор­тах все DHCP-сооб­щения будут счи­тать­ся легитим­ными. Обыч­но доверен­ные пор­ты нас­тра­ивают­ся на соеди­нени­ях меж­ду ком­мутато­рами и мар­шру­тиза­тора­ми, а недове­рен­ные кон­фигури­руют­ся на пор­тах, куда под­клю­чают­ся конеч­ные стан­ции (нап­ример, компь­ютер, прин­тер, точ­ки дос­тупа, VoIP).

Те­перь к кон­фигура­ции. Пред­положим, перед нами ком­мутатор Cisco. Его порт g0/2 смот­рит в сто­рону мар­шру­тиза­тора, а зна­чит, этот порт нуж­но обя­затель­но сде­лать доверен­ным для DHCP Snooping, так как это про­межу­точ­ное устрой­ство, от которо­го могут лететь легитим­ные DHCP-сооб­щения. Может быть, DHCP-сер­вер находит­ся на самом роуте­ре или даже за роуте­ром (в таком слу­чае при­меня­ют DHCP Relay). А пор­ты f0/1-24 — это пор­ты, к которым под­клю­чают­ся конеч­ные стан­ции, их нуж­но сде­лать недове­рен­ными, пос­коль­ку имен­но от поль­зователь­ских под­клю­чений есть риск ата­ки на DHCP. Заметь, DHCP Snooping вклю­чает­ся имен­но на сег­ментах VLAN. Еще нуж­но ука­зывать адрес авто­ризо­ван­ного DHCP-сер­вера, который дос­тупен через доверен­ный порт ком­мутато­ра.

Все пор­ты по умол­чанию недове­рен­ные, поэто­му нам нуж­но явно ука­зать, какие пор­ты будут доверен­ными. Затем гло­баль­но вклю­чить DHCP Snooping и Snooping-про­цесс для сег­мента VLAN.

NightmareSwitch(config)# interface g0/2

NightmareSwitch(config-if)# ip dhcp snooping trust

NightmareSwitch(config)# ip dhcp-server <IP ADDRESS>

NightmareSwitch(config)# ip dhcp snooping

NightmareSwitch(config)# ip dhcp snooping vlan <VLAN ID>

Те­перь ком­мутатор будет насыщать таб­лицу DHCP Snooping, занося в нее MAC, IP, VLAN ID кли­ентов, получив­ших адрес по DHCP.

При необ­ходимос­ти мож­но соз­дать ста­тичес­кую запись в базе дан­ных DHCP Snooping:

NightmareSwitch(config)# ip dhcp snooping binding <MAC> vlan <VLAN ID> <IP ADDRESS> interface <INTERFACE ID> expiry <SECONDS>

Ко­ман­ды для отладки и про­вер­ки сос­тояния DHCP:

NightmareSwitch(config)# show ip dhcp snooping

NightmareSwitch(config)# show ip dhcp snooping statistics

NightmareSwitch(config)# show ip dhcp snooping binding

Для надеж­ности необ­ходимо записы­вать содер­жимое таб­лицы DHCP Snooping в память ком­мутато­ра: вдруг свитч вне­зап­но уйдет в перезаг­рузку, а таб­лица DHCP Snooping потеря­ется. Если это будет вмес­те с Dynamic ARP Inspection, то мы получим сетевой паралич.

NightmareSwitch(config)# ip dhcp snooping database flash:/snooping.db

Кста­ти, базу дан­ных Snooping мож­но не толь­ко хра­нить в памяти ком­мутато­ра, но и передать по служ­бам FTP, HTTP, RCP, SCP, TFTP.

NightmareSwitch(config)# ip dhcp snooping database ?

flash:

ftp:

https:

rcp:

scp:

tftp:

timeout:

write-delay

DAI & IPSG

Обыч­но Dynamic ARP Inspection (DAI) нас­тра­ивает­ся вмес­те с DHCP Snooping, так что это, по сути, про­дол­жение пре­дыду­щей час­ти.

DAI поз­воля­ет пре­дот­вра­щать ARP-спу­финг внут­ри сети бла­года­ря отсле­жива­нию все­го ARP-тра­фика. И здесь есть очень важ­ный момент. Что­бы инспек­ция работа­ла, ей нуж­но на чем‑то осно­вывать­ся, и вся ее работа нап­рямую зависит от DHCP Snooping. DAI на осно­ве таб­лицы DHCP Snooping будет про­верять валид­ность ARP-отве­тов, то есть про­верять, дей­стви­тель­но ли такая при­вяз­ка MAC-адре­са и IP-адре­са есть внут­ри сети. Если нет, то DAI мгно­вен­но заб­локиру­ет такой тра­фик.

Од­нако при интегра­ции DAI в про­дак­шене нуж­но позабо­тить­ся о том, что­бы таб­лица DHCP Snooping была пол­ностью насыще­на. То есть в нее дол­жны попасть абсо­лют­но все хос­ты внут­ри сети. В про­тив­ном слу­чае тра­фик не попав­ших туда легитим­ных хос­тов будет заб­локиро­ван, что нарушит биз­нес‑про­цес­сы.

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

Нас­трой­ка DAI опи­рает­ся на ту же кон­цепцию доверен­ных и недове­рен­ных пор­тов. Как и в слу­чае с DHCP Snooping, все пор­ты ком­мутато­ра по умол­чанию недове­рен­ные. И в осталь­ном то же самое: доверен­ные пор­ты — это пор­ты меж­ду ком­мутато­рами и роуте­рами, недове­рен­ные — поль­зователь­ские пор­ты. На недове­рен­ных пор­тах сто­ит вклю­чить IP Source Guard (IPSG), который будет про­верять источник зап­росов.

NightmareSwitch(config)# int g0/2

NightmareSwitch(config-if)# ip arp inspection trust

NightmareSwitch(config)# interface range f0/1-24

NightmareSwitch(config-if-range)# ip verify source

При необ­ходимос­ти мож­но соз­дать ARP ACL, что­бы не про­верять устрой­ства со ста­тичес­ким IP. Вдруг в тво­ей сети есть хос­ты со ста­тичес­ким адре­сом.

NightmareSwitch(config-if)# arp access-list DAI

NightmareSwitch(config-arp-nacl)# permit ip host <IP> mac host <MAC>

Кста­ти, для IPSG мож­но тоже соз­давать ста­тичес­кие записи внут­ри ком­мутато­ра, но это дела­ется без ACL.

NightmareSwitch(config)# ip source binding <MAC> vlan <VLAN ID> <IP ADDRESS> interface <INTERFACE ID>

За­кон­чив нас­трой­ку и убе­див­шись, что нуж­ные ста­тичес­кие адре­са забин­дились, а таб­лица DHCP Snooping пол­ностью насыще­на, вклю­чаем сам DAI. DAI, как и DHCP Snooping, вклю­чает­ся имен­но на сег­ментах VLAN.

NightmareSwitch(config)# ip arp inspection vlan <VLAN ID>

ОБНАРУЖЕНИЕ И БЛОКИРОВКА ИНСТРУМЕНТА RESPONDER

Responder — это инс­тру­мент пен­тесте­ров, поз­воля­ющий перех­ватывать учет­ные дан­ные внут­ри сетевой инфраструк­туры, в основном он при­менят­ся в сре­дах с Windows-машина­ми. Одна­ко пре­вен­тивные меры про­тив Responder обыч­но закан­чива­ются лишь вык­лючени­ем MCAST-про­токо­лов, таких как LLMNR, NBNS и MDNS.

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

Источник