информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Страшный баг в WindowsВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / sysadmin
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Реестр "хакать" не надо. 01.04.06 00:16  Число просмотров: 2980
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
<"чистая" ссылка>
Или через групповые политики запретить смену IP адреса, или ограничить права пользователя (например группой Users).
С товарищами, которые приходят с неконтролируемыми ноутбуками провести разъяснительную беседу и пристально следить в первое время. Но лучше, так же запретить и им.
<sysadmin>
"Запрет назначения определённого IP-адреса на сетевой карте" или "два одинаковых IP в одной сети" 31.03.06 02:25  
Автор: Alexander Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Суть проблемы:

Есть сервак (Linux) с двумя сетевухами: eth0, смотрящим в "мир" и eth1, 192.168.0.1.
Есть локальная сеть, 192.168.0.0/24, (с виндами) подключенная в eth1.
Сервак, он же шлюз, 192.168.0.1 - через него народ ходит в инет.

Если кто-то случайно (или умышленно) в локальной сети назначает себе IP-адрес 192.168.0.1 - все пакеты начинают валить к нему на комп. Т.е. он как бы становится шлюзом.
Соответственно, вся локалка сидит без инета.

Проверял...
Работает.
Ставил на клиентской WinXP IP-адрес на интерфейсе 192.168.0.1. Ругается на то, что "такой IP-адрес в сети уже есть!", но тем ни менее, адрес этот всё-таки ставит.

Получаем два одинаковых IP-адреса в сети.


Каким-нибудь способом можно запретить назначение этого (192.168.0.1) IP адреса компам в локалке?
Варианты на клиентских машинах с жёстким прописыванием МАС-адреса eth1 сервака ч/з "arp -s", "хакинг" реестра во всяких там "Software/Microsoft/Windows/Current Version/Policies" и etc не подходят.

Т.е. нужно что-то организовать на стороне сервака.

Я так понимаю, при появлении этого нового "липового" IP-адреса, 192.168.0.1 в сети, автоматом ARP-кэш обновляется на всех машинах в локалке, и получается, что до сервера уже не "достучаться" - все пакеты валят уже на другой MAC-адрес, "липовый".


Это, разве что... на серваке каким-то образом, с интервалом, допустим в 1 минуту генерировать какой-то широковещательный arp-пакет, заставляющий обновиться arp-кешу на машинах в локалке, чтобы они снова "увидели" истинный шлюз (MAC-адрес), а не "липовый"?... :))

О, как!
Еще могу предложить. 04.04.06 12:01  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
Пишется маленькая программка, проверяющая через ARP соответствие MAC адресов IP адресам локальной сети и к ней маленькие модули, управляемые по сети и осуществляющие какую-нибудь DoS атаку на указанный IP/MAC адрес.

На админский комп ставишь главную прогу, на все остальные компы сети - управляемые модули.

Правда, есть минусы.
Да. 04.04.06 13:42  
Автор: Alexander Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Пишется маленькая программка, проверяющая через ARP
> соответствие MAC адресов IP адресам локальной сети

> Правда, есть минусы.

Да.
Для меня минус уже хотя бы в том, что эту прогу придётся "прикручивать" ко всем компам в сети.
А я не всегда могу отследить появление новых машин в сети.


Хотелось бы организовать что-то именно на стороне сервера...
Не надо отслеживать новые компы и ставить на них управляемые... 05.04.06 20:24  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
> Да.
> Для меня минус уже хотя бы в том, что эту прогу придётся
> "прикручивать" ко всем компам в сети.
> А я не всегда могу отследить появление новых машин в сети.

Не надо отслеживать новые компы и ставить на них управляемые модули.
Достаточно установить эти модули на стационарные компы в сети и при возникновении проблемм будет осуществляться какая-нибудь DoS атака на узел нарушителя.
Реестр "хакать" не надо. 01.04.06 00:16  
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
<"чистая" ссылка>
Или через групповые политики запретить смену IP адреса, или ограничить права пользователя (например группой Users).
С товарищами, которые приходят с неконтролируемыми ноутбуками провести разъяснительную беседу и пристально следить в первое время. Но лучше, так же запретить и им.
Вариант, конечно... Но... 04.04.06 09:30  
Автор: Alexander Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Или через групповые политики запретить смену IP адреса, или
> ограничить права пользователя (например группой Users).
Вариант, конечно... Но...
С ХР в этом плане проще: пораздавал права какие нужно, настроил... и всё.
А вот как быть в 98-ми (и кое-где даже 95-ми ;) ?...


> С товарищами, которые приходят с неконтролируемыми
> ноутбуками провести разъяснительную беседу
Тут намного проще: таких всего пара-тройка ;)
95 и 98 тоже поддерживают ограничение прав пользователей при помощи групповой политики. 04.04.06 17:36  
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
<"чистая" ссылка>
DHCP? 31.03.06 18:04  
Автор: Lurga Статус: Elderman
<"чистая" ссылка>
а при чем тут он? :) если кто взумает руками вбить ДХЦП не спасет =) 31.03.06 21:24  
Автор: DamNet <Denis Amelin> Статус: Elderman
<"чистая" ссылка>
В некоторых случаях помогает! 21.04.06 06:17  
Автор: darin Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Я думал и о таком варианте... 04.04.06 09:45  
Автор: Alexander Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Я думал и о таком варианте...

Могут помочь, разве что, два варианта вместе:
Раздача IP-адресов серваком по DHCP клиентам... и запрет в групповых политиках/правах/реестре этих клиентских машин смены IP-адреса пользователем. ;)
Я, в общем-то, именно это и имел в виду. 04.04.06 10:13  
Автор: Lurga Статус: Elderman
<"чистая" ссылка>
Вычислить вбивающего руками и оные руки ему отбить. =)) 01.04.06 12:53  
Автор: Lurga Статус: Elderman
<"чистая" ссылка>
Хха! 04.04.06 09:21  
Автор: Alexander Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Хха!
Это, пожалуй, оптимальный вариант! ;)

т.к. самый дешёвый :))

Одному - отбить, а остальным уже не захочется.
Угу. 04.04.06 10:35  
Автор: Lurga Статус: Elderman
<"чистая" ссылка>
А если серьёзно -- то переговорить с руководством на тему саботажа. Не все проблемы должны решаться путём системного администрирования.
В принципе это уязвимость локальных сетей. В глобальных... 31.03.06 18:04  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 31.03.06 18:12  Количество правок: 1
<"чистая" ссылка>
В принципе это уязвимость локальных сетей. В глобальных маршрутизаторы помогают, поскольку там у людей деньги есть не только на умные коммутаторы, но и на серваки.
По идее, эта "паршивая овца", прежде чем проинициализировать АиПи сетевой интерфейс, должна была (если дубликат адрес прописан перманентно) посмотреть на наличие в сети машинки с таким же адресом и задавить инициализацию сети с выводом сообщения об ошибке дубликата адреса. Иногда и первая машинка тоже может в логах зарегистрировать событие, что какая-то другая машинка пыталась начать работать с этим же адресом.
Если же эта "паршивая овца" настолько глючная или специально таким безобразием занимается, то аминь. Это все равно, что сеть - общая шина на хабах и какая-нибудь машинка гонит с бешеной частотой без пауз большие пакеты кому-то тем самым забивая всю ширину канала, что сетка встает. Здесь тоже либо коммутаторы решат проблему, либо извините, другие методы пока в голову еще не пришли.

На сколько я понимаю на каком-либо писюке пользователь может выставлять адреса на сетевых интерфейсах или есть возможность приносить персональные буки, на которых у пользователя есть соответствующие права. У меня на компах пользователи работают с обычными правами и не могут изменить настройки сети, такой проблемы возникнуть не может.
Тут все намного проще. :) 04.04.06 09:41  
Автор: Alexander Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> По идее, эта "паршивая овца", прежде чем
> проинициализировать АиПи сетевой интерфейс, должна была
> (если дубликат адрес прописан перманентно) посмотреть на
> наличие в сети машинки с таким же адресом и задавить
> инициализацию сети с выводом сообщения об ошибке дубликата
> адреса.

Тут все намного проще. :)
Умники-то есть... но... тупые :))
Максимум, пытаются методом перебора всех IP-адресов подсети найти тот, для которого открыт доступ в инет.
Но и тут, увы, разочарование ждёт: привязка IP-MAC на серваке ;)

> Если же эта "паршивая овца" настолько глючная или
> специально таким безобразием занимается, то аминь.
Во-во-во! :))

> Здесь тоже либо коммутаторы решат проблему, либо
> извините, другие методы пока в голову еще не пришли.


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

...но, похоже, они свою зарплату зря получают ;)
Управляемым сетевым коммутатором. 31.03.06 13:57  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
Так и знал, что что-то важное забыл сказать! :)) 31.03.06 16:28  
Автор: Alexander Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Так и знал, что что-то важное забыл сказать! :))
Этот вариант тоже можно добавить к числу "неподходящих".
Я бы с радостью именно этот вариант и использовал...
Но, увы - он мне не "светит". Из-за отсутствия денег.


Может ещё какие-нибудь ideas есть у кого?

Или это единственный вариант решения проблемы?
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach