DHCP leased time можно ли узнать (Можно ли спросить у клиента сколько ему жить осталось?)

[Nab]

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

[Angel_13th]

Nab
Задача не трудная, но обходится такая связка на раз. Соответсвенно либо VPN, либо еще дополнительная авторизация по паролю.

[Nab]

А конкретно?
Как узнать у клиента время, до которого ему выдан адрес?
Если можно то код в студию
Ну или хотя-бы толковую ссылку....
Про все остальное я знаю и пароль будет обязательно, но вот меня этот конкретный вопрос мучает....

[Zhic]

можно.
смотри /var/state/dhcpd.leases
вроде так

[Nab]

Читаем внимательно....

Как узнать у клиента время, до которого ему выдан адрес?

Я не нахожусь на самом клиенте, и не имею доступа к его dhcp.leases

время до которого ему выдоли адрес на сервере я знаю, меня интересует возможность средствами самого DHCP протокола, или еще как узнать у самого клиента, сколько времени он иожет пользоваться выданным адресом.

[Slimy]

Читаем внимательно....

Как узнать у клиента время, до которого ему выдан адрес?

Я не нахожусь на самом клиенте, и не имею доступа к его dhcp.leases

время до которого ему выдоли адрес на сервере я знаю, меня интересует возможность средствами самого DHCP протокола, или еще как узнать у самого клиента, сколько времени он иожет пользоваться выданным адресом.

А зачем ? Это все ведь должен знать DHCP сервер. Он ведь выдает информацию до какого времени адресс действителен. Да и все эти временные ухищрения врятли помогут. по себе знаю полгода юзал интернет на халяву (давно было) причем без ограничения по скорости(т.е. столько сколкьо канал сети давал столько и было ,е если другие не занимали конечно), дырка была в старых линукс-рутерах вернее в их фаирволах. Теперь ее благополучно заделали.

[Nab]

Блин, да какая разница зачем?

Я не могу более толково вам объяснить, да и незачем считаю.
Те кто меня понял, думают что наверно нельзя такое замутить хотя я все еще питаю надежду....

А без толку ребята не пишите....

[7biohazard7]

Согласно работы протокола третьей стороне это узнать нельзя.
Вернее можно попытаться прослушать, но только в момент запроса IP адреса.
Или в момент продления и то вряд ли, это будет зависеть от конкретной реализации.
А так в любой момент времени взять и узнать, нет.
вы RFC почитайте....

[Nab]

Согласно работы протокола третьей стороне это узнать нельзя.
Вернее можно попытаться прослушать, но только в момент запроса IP адреса.
Или в момент продления и то вряд ли, это будет зависеть от конкретной реализации.
А так в любой момент времени взять и узнать, нет.
вы RFC почитайте....

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

Но также существует протокол UAP согласно которого можно аутентифицировать на уровне получения ликвидных адресов. Не знаю только, все ли клиенты поддерживают его... Еще предстоит разобраться и изучить....
Вот такую выдержку дам.... возможно кому интересно станет

Опция DHCP для протокола аутентификации пользователей открытых групп
(RFC-2485, S. Drach, DHCP Option for The Open Group's User Authentication Protocol)

Технический стандарт для клиента вычислительной сети разработан рабочей группой по сетевым вычислениям NCWG (Network Computing Working Group), он определяет схему аутентификации клиента-пользователя в вычислительной сети, которая носит название протокола аутентификации пользователя (UAP).

UAP предлагает два уровня аутентификации, базовый и безопасный. Базовая аутентификация использует механизм, определенный в спецификации HTTP 1.1 [3]. Безопасная аутентификация является просто аутентификацией реализованной в рамках сессии SSLv3 [4].

В обоих случаях клиент UAP должен получить IP-адрес и номер порта службы UAP. В зависимости от реализации системы может потребоваться дополнительная информация о проходе. URL [5] представляет прекрасный механизм инкапсуляции этой информации, так как многие серверы UAP реализуются как часть HTTP/SSL-серверов.

Большинство клиентов UAP конфигурируются при загрузке через DHCP. Ни одна из существующих опций DHCP [6] не имеет информационных полей, содержащих URL. Опция 72 содержит список IP-адресов WWW-серверов, но она не адекватна задаче, так как нельзя специфицировать номер порта и/или проход. Следовательно, нужна опция, которая содержит список URL.

[sash-kan]

сделать защиту от одновременной подмены IP и MAC

↑

а на это не смотрел?

Код: Выделить всё

$ apt-cache show arpwatch
Package: arpwatch
Priority: optional
Section: admin
Installed-Size: 380
Maintainer: KELEMEN Péter <fuji@debian.org>
Architecture: i386
Version: 2.1a13-2
Depends: libc6 (>= 2.3.2.ds1-4), libpcap0.8, debianutils, adduser
Recommends: mail-transport-agent
Suggests: snmp
Filename: pool/main/a/arpwatch/arpwatch_2.1a13-2_i386.deb
Size: 124446
MD5sum: 27d2071359a915c9f1ddb69f8ce0f806
Description: Ethernet/FDDI station activity monitor
 Arpwatch maintains a database of Ethernet MAC addresses seen on the
 network, with their associated IP pairs.  Alerts the system administrator
 via e-mail if any change happens, such as new station/activity,
 flip-flops, changed and re-used old addresses.

[Nab]

Смотрел, спасибо...
и на arpalert, и на arping (кстати мне больше всего понравилось), и на ipsintel....
все же они не решаеют задачу в полном объеме, вот именно в дополнение к ним и нужна какая-либо еще идентификация хоста... думал по точному времени dhcp, ведь у всех оно разное будет... но вижу не получиться.

[sash-kan]

nmap -O host ?