Вопросы Теги

pfsense: блокировка второго DHCP-сервера

Вывод smbclient -L remote-server содержит домен; на связанной странице показан пример: 

smbclient -L zimmerman

Результат этой команды должен выглядеть примерно так: 

 Server time is Sat Aug 10 15:58:27 1996
Timezone is UTC+10.0
Password: 
Domain=[WORKGROUP] OS=[Windows NT 3.51] Server=[NT LAN Manager 3.51]

Server=[ZIMMERMAN] User=[] Workgroup=[WORKGROUP] Domain=[]

    Sharename      Type      Comment
    ---------      ----      -------
    ADMIN$         Disk      Remote Admin
    public         Disk      Public 
    C$             Disk      Default share
    IPC$           IPC       Remote IPC
    OReilly        Printer   OReilly
    print$         Disk      Printer Drivers


This machine has a browse list:

    Server               Comment
    ---------            -------
    HOPPER               Samba 1.9.15p8
    KERNIGAN             Samba 1.9.15p8
    LOVELACE             Samba 1.9.15p8
    RITCHIE              Samba 1.9.15p8
    ZIMMERMAN

Ссылка: http://www.tldp.org/HOWTO/SMB-HOWTO-8.html

2
15.05.2017, 21:48
2 ответа

К сожалению, вы не можете заблокировать второй DHCP в той же локальной сети (конечно, не на уровне брандмауэра, и смягчение его последствий с помощью высокопроизводительного корпоративного коммутационного оборудования - непростая тема); IP-запрос - это служба широкополосной рассылки, которая обычно работает на уровне локальной сети, и поэтому нет служб маршрутизации для блокировки служб на уровне межсетевого экрана.

например. Брандмауэры не блокируют разговоры между машинами, принадлежащими к одному сетевому блоку / локальной сети, однако они контролируют / выполняют маршрутизацию с его помощью для взаимодействия с другими сетями.

Протокол DHCP определяет, что какой бы ответ ни пришел первым на станцию, запрашивающую IP, это будет принятый ответ. Таким образом, в зависимости от того, кто победит, рабочие станции случайным образом получат IP-адрес от официального или мошеннического IP-адреса.

Что можно сделать, так это смягчить последствия, то есть найти MAC-адрес неисправного оборудования и найти его в коммутаторах или заблокировать этот MAC-адрес в коммутаторах / беспроводной точке доступа.

Чтобы узнать это, у вас есть два возможных пути:

Вы заходите на зараженный компьютер и пытаетесь узнать IP-адрес DHCP-сервера, который обслужил этот запрос. Или, если на то пошло, освободите IP-адрес и попросите его несколько раз.

Получив ответ для внешнего маршрутизатора, получите этот IP-адрес (например, с помощью ipconfig / all в клиенте Windows), затем получите этот MAC-адрес, а затем предположите, что IP-адрес мошеннический DHCP-сервер - 1.1.3.200: 

$ping -c1 1.1.3.200 
PING 1.1.3.200 (1.1.3.200) 56(84) bytes of data.
64 bytes from 1.1.3.200: icmp_seq=1 ttl=255 time=0.273 ms

--- 1.1.3.200 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.273/0.273/0.273/0.000 ms
$arp -a 1.1.3.200
xxxx.local (1.1.3.200) at 00:0b:fc:07:04:01 [ether] on eth0

Или, как я предпочитаю, в окне Linux вы используете tcpdump для прослушивания пары запросов DHCP (в поле есть горизонтальный ползунок, чтобы увидеть весь текст ) 

sudo tcpdump -n -c 10 -e port 68
09:23:57.298176 00:21:97:c6:76:fc > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 1.1.3.2.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:21:97:c6:76:fc, length 300
09:23:59.034798 00:19:21:3c:2c:22 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 1.1.3.116.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:19:21:3c:2c:22, length 300
09:24:00.191144 64:00:6a:09:58:16 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 1.1.3.142.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 64:00:6a:09:58:16, length 300
09:24:07.325291 6c:62:6d:d0:20:f4 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 1.1.3.2.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 6c:62:6d:d0:20:f4, length 300
09:24:31.500826 00:23:24:06:e8:0b > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 363: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:23:24:06:e8:0b, length 321
09:24:31.502554 00:0b:fc:07:04:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 1.1.3.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
09:24:31.502812 00:0b:fc:07:04:01 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 1.1.3.200.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
09:24:32.098505 00:0f:fe:fd:6c:27 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 1.1.3.10.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0f:fe:fd:6c:27, length 300
09:24:49.340908 64:00:6a:09:05:6d > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 1.1.3.174.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 64:00:6a:09:05:6d, length 300
09:24:53.444891 ac:16:2d:08:44:1b > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 1.1.3.170.68 > 255.255.255.255.67: BOOTP/DHCP, Request from ac:16:2d:08:44:1b, length 300

Обратите внимание на строки, в которых написано "Ответ DHCP":
в этом примере сервер DHCP - 1.1.3.254 и MAC 00: 0b: fc: 07: 04: 00; второй имеет IP-адрес 1.1.3.200 и MAC-адрес 00: 0b: fc: 07: 04: 01 (6-я и 7-я строки вывода).

3
27.01.2020, 21:59

Я использовал голодание DHCP (в частности, на мошенническом DHCP-сервере) в течение более длительных периодов времени. Попробуйте dhcdrop или dhcpstarv или сценарий scapy. В конце концов я выбрал последний, потому что он был более гибким. Как в scapy, так и в dhcpstarv можно нацелиться на атакующий DHCP-сервер, не прерывая законную службу.

Некоторые маршрутизаторы и коммутаторы могут сбрасывать ссылки на хосты, которые нарушают набор правил. Например, см. эту ветку поддержки Cisco.

3
27.01.2020, 21:59

Теги

Похожие вопросы