Помогите, пожалуйста, уж нет сил бороться с хулиганами. Прописывают ip сервера у себя на компе, меняют мак и в итоге сервер в дауне. Ну как бороться с такими кроме отключения сегментов и поиска вредителя, ( большой микрорайон) и покупки упраляемых свитчей?? ( очень дорого ). Почему постоянно он отбивает у сервера адрес, хоть и сервер первый включается в сеть? Может есть какая софтина, чтобы сервер был устойчивее, чтобы ip невозможно было отбить и он не реагировал на ip address conflict??
DHCP настроить на отбрасывание неизвестных.
А на сервере МАС адреса статически прописать.
Iptables+Sysctl настроить как положено, чтобы
отбрасывал "левые" пакеты, сканы, и лимит на число
запросов с одного адреса.
В цикле скрипторм парсить логи, и нарушителям посылать "нюк"
за неправомерные действия.
99,9% желающих побаловаться, сразу же расхотят
хулиганить, когда их компы будут перезагружаться
как только начнут бедокурить в сетке.Здесь куча статей была по этому вопросу.
В 2х словах этого не рассказать, обширный вопрос,
а принцип кратко описал.
Читайте "киса" они золотые...
Если при логине выполняется логон скрипт вдуть всем клиентам статический arp
Так стоит статический АРП, а вот как выбивать злоумышленника из сетки???
Может подкините скрипт нюка или хотя бы подскажите как защититься??
Не работал с таким... но может имеет смысл подумать о сборе стареньких компиков под мосты(если управляемые свичи дороги) и тогда рули, руби и бань бардак на контролируемой территории.
Да-да, я тоже обдумывал этот вариант, но что скажем делать, если мы весим коробки в подъездах под потолком примерно 40*90 см, а тут надо целый сейф крепить, которым непременно сразу же заинтересуются Ж)
>Не работал с таким... но может имеет смысл подумать о сборе стареньких
>компиков под мосты(если управляемые свичи дороги) и тогда рули, руби и
>бань бардак на контролируемой территории.google, raqmbler, yandex -> nuke linux и подобные
портянка ссылок, компилятся в секунду.
Эффективность высокая.
Я прописывал еще и на www сервере.
Как только вирусы/трояны типа MyDoom лезут искать уязвимость,
нюка им на перезагрузку. В течении дня их всех лечили,
и больше запросов от них не поступало.Лучшая защита - нападение.
Что-то я ничего подобного не нашел. Может подкинешь ссылку?>google, raqmbler, yandex -> nuke linux и подобные
>портянка ссылок, компилятся в секунду.
>Эффективность высокая.
>Я прописывал еще и на www сервере.
>Как только вирусы/трояны типа MyDoom лезут искать уязвимость,
>нюка им на перезагрузку. В течении дня их всех лечили,
>и больше запросов от них не поступало.
>
>Лучшая защита - нападение.
>Что-то я ничего подобного не нашел. Может подкинешь ссылку?Сорри это уже будет дорого стоить.
А бесплатно на гугле + время на обдумывание + эксперименты +
написание своего скрипта.
Ведь нужен целый арсенал.
под win9x / 2000 / XP / Linux / Free
А также метод выявления оси хацкера.И уже столько всего насоветовали Вам,
Что давно уже надо было решить большую половину проблем.
Если без управляемых свитчей, то проще всего перевести всех на PPPoE. Пусть дебил себе ставит любой адрес, пока не залогинится -- инета (и прочих услуг сети) не будет.Далее, ПОЛУ- (даже четверть-) мера. Уйдите от "общепринятых" адресов вида 10/8, 192.168/16. Аргументы: 192.168.0.1 обожают ставить себе всякие WiFi-примочки, 10.0.0.1 -- ADSL-модемы. Так что, может, это и не хулиганы, а просто криворучки.
Ты че здурел, а какие тогда ип использовать как кроме 10.0.0.0/8 172.16.0.0/16 и 192.168.0.0/24 ?
>Ты че здурел, а какие тогда ип использовать как кроме 10.0.0.0/8 172.16.0.0/16
>и 192.168.0.0/24 ?как у мелкософтовской подсетки %)
>>Ты че здурел, а какие тогда ип использовать как кроме 10.0.0.0/8 172.16.0.0/16
>>и 192.168.0.0/24 ?
>
>как у мелкософтовской подсетки %)это что за подсетка такая? я о такой не слышал... :)
получить PA от провайдера!
на таких адресах инет раздовать незя.>Ты че здурел, а какие тогда ип использовать как кроме 10.0.0.0/8 172.16.0.0/16
>и 192.168.0.0/24 ?
>Ты че здурел,Полегче на поворотах.
>а какие тогда ип использовать как кроме 10.0.0.0/8 172.16.0.0/16
>и 192.168.0.0/24 ?192.168.132.54, к примеру. Имеется в виду, что не надо ставить сервер на "общеприятый" 192.168.0.1. Вероятность того, что кулхацкер на него "сходу" сядет, гораздо меньше.
А вообще, всё это -- детский сад. Как уже было сказано, нормальных решения два:
а) управляемые свичи;
б) различные варианты VPN.
>>Ты че здурел,
>
>Полегче на поворотах.
>
>>а какие тогда ип использовать как кроме 10.0.0.0/8 172.16.0.0/16
>>и 192.168.0.0/24 ?
>
>192.168.132.54, к примеру. Имеется в виду, что не надо ставить сервер на
>"общеприятый" 192.168.0.1. Вероятность того, что кулхацкер на него "сходу" сядет, гораздо
>меньше.
>
>А вообще, всё это -- детский сад. Как уже было сказано, нормальных
>решения два:
>а) управляемые свичи;
>б) различные варианты VPN.
Причём тут ВПН то? Вам же сказали, что злоумышленник создаёт конфликт IP. И нормальных юзеров выбивает с инета. Ему то этот VPN, вероятно, не упёрся.Вообще, конфликт IP решается просто - статический арп у клиентов и всё. А вот конфликт мака - только мостами/управляемыми свичами. Да и то за мостом у юзеров инета не будет. Это, имхо, большой недостаток стандарта.
Либо ставь вместо каждого хаба циску за много денег, либо ликвидируй хулигана физически, что тоже хлопотно.
В своё время я конфликтом мак адресов "опустил" сервер своего врага, и весь персонал сети из 3000компов ничего не смог со мной сделать. =)
Тебя же люди ткнули носом!!!
PPPoE !!!
никакого ip пока не набрал пароль!
>Тебя же люди ткнули носом!!!
>PPPoE !!!
>никакого ip пока не набрал пароль!Ты ёпт внимательно изучи, что я отцитировал и на какое письмо отвечал, а потом разводи визг. Я отвечал на письмо, где предлагался вариант "VPN".
Более того, ты представь ситуацию, когда вся локалка начнёт обмениваться траффиком через сервер. Тут и никаких хулиганов не надо, сам сдохнет.
>>Тебя же люди ткнули носом!!!
>>PPPoE !!!
>>никакого ip пока не набрал пароль!
>
ip то никакого, а вот если он вручную заведомо зная адрес сервера у себя пропишет?? Все равно не будет конфликта?
vpn не поможет...
Ребята! Тут же элементарно, не усложняйте вопрос. Речь идет о том, что ушлый хуцкер, в целях навредить или еще чего, руками ставит себе нужный IP и МАС и вся сеть летит к черту физически! А VPN - средство от логической защиты. Скажем так, есть клиент, подключенный по VPN как положено. И однажды вечером он меняет себе настройки, ставит адрессервака и его МАС (он же их знает, ведь настоящий клиент), и делает сети больно. Я правильно понял ситуацию?
1. про локалку тут не слова! я говрю про инет.
2. локалка пусть ходит по своим адресам, а сервер туда не должен смотреть!.
3. через сервер будет бегать только интернет трафик ысерверу плохо не будет.
4. ответил я туда, куда хотел! практически pppoe лучше VPN так как не требует от сервера слушать ip-сеть! а значит что положить его описаным выше методом НЕ ПОЛУЧИТСЯ!
5. я не хотел тебя обидеть или что-то подобное.
6. и последнее - я советую основываясь не на теории а на практике: 567 хостов в локалке.> Ты ёпт внимательно изучи, что я отцитировал и на какое письмо
>отвечал, а потом разводи визг. Я отвечал на письмо, где предлагался
>вариант "VPN".
>
> Более того, ты представь ситуацию, когда вся локалка начнёт обмениваться траффиком
>через сервер. Тут и никаких хулиганов не надо, сам сдохнет.
что то не понимаю..
сервер pppoe и клиент в одной сети соединены Ethernet, если клиент выставит себе адрес сервера?
>что то не понимаю..
>сервер pppoe и клиент в одной сети соединены Ethernet, если клиент выставит
>себе адрес сервера?
То будет тоже самое что и с IP =) так что не выход
Я так думаю, что единственным выходом в этой ситуации, причем более-менее недорогим, будет поставить хотя бы один грамотный свитч прямо перед рутером/шлюзом, чтобы обезопасить его. А там, в сети, уж как хотят, так пусть и долбят друг друга...По-другому никак..
А как двухуровневый свич поможет от смены ip адреса?
Да в том то и дело, что сервер имеет два интерфейса eth0, eth1. eth0 - 10.1.0.1 смотрит в сеть. Кто-то из сети вручную пишет неизвестный МАК, ип сервера и радости полные штаны. Причем не пойму PPoE , VPN. Ничего ведь ему не помешает и при таком раскладе ручками все прописавать?
Коммутатором от подмены MAC и потом административными методами за такое хулиганство или прости отключать от свича напрочь.
Единственное грамотное и надежное решение - это управляемые свичи, достаточно 2-го уровня, они, кстати, из low-end не настолько дороги сейчас как 3-го уровня. Идеальный вариант - port security на каждого абонента, но можно и на небольшие сегменты:
появились проблемы в каком-то сегменте - ставим временно дежурный управляемй свич в нем уже на порт каждого абонента из этого сегмента и мониторим
дальше разбераемся с нарушителем
>А как двухуровневый свич поможет от смены ip адреса?Static arp на роутере, фильтрация по MAC на свиче.
>Почему постоянно он отбивает у сервера адрес, хоть и сервер первый
>включается в сеть? Может есть какая софтина, чтобы сервер был устойчивее,
>чтобы ip невозможно было отбить и он не реагировал на ip
>address conflict??Сделай на базе какой-нибудь полудохлой машинки transparent bridge, поставь на него файрвол. И гаси все неугодные тебе пакеты извне. Серверу от этого легче станет, да и тебе спокойней. Дешево и сердито.
P.S. Поставь его в разрыв между сервером и локалкой.
>P.S. Поставь его в разрыв между сервером и локалкой.
И чё будет? :) У всей сети сервер будет летать, зато последний будет чувстовать себя замечаетельно =)
> И чё будет? :) У всей сети сервер будет летать, зато
>последний будет чувстовать себя замечаетельно =)А кто сказал что это финальный вариант? Во всяком случае таким макаром можно избежать конфликта на стороне "честного сервера", не меняя его конфигурацию, не устанавливаю дополнительно ПО и пр.(кстати, я так и не понял на чем у него сервак работает). Все "эксперименты" с вычислением злыдней сместятся на данный бриджик.
Ессно в это время в локалке будет "жить" псевдо-сервак, который можно будет отличить от "правильного" если, как говорилось выше, организовать доступ VPN-у. Т.е. админу остается лишь вычислить "шутника", в то время как вся сеть работает как ни в чем не бывало.
>> И чё будет? :) У всей сети сервер будет летать, зато
>>последний будет чувстовать себя замечаетельно =)
>
>А кто сказал что это финальный вариант? Во всяком случае таким макаром
>можно избежать конфликта на стороне "честного сервера", не меняя его конфигурацию,
>не устанавливаю дополнительно ПО и пр.(кстати, я так и не понял
>на чем у него сервак работает). Все "эксперименты" с вычислением злыдней
>сместятся на данный бриджик.
>Ессно в это время в локалке будет "жить" псевдо-сервак, который можно будет
>отличить от "правильного" если, как говорилось выше, организовать доступ VPN-у. Т.е.
>админу остается лишь вычислить "шутника", в то время как вся сеть
>работает как ни в чем не бывало.
Мля слов нет =)) Сервер стоит на линухе(судя по именам интерфейсов) и ему от конфликта по сути не холодно не жарко. Конфликт айпи адресов - это рассылка по сети arp пакетов с таким же ip, но другим маком, что сбивает с толку все машины в сети(на которых мак не пробит статично), и пакеты серверу они отправляют уже на левый мак, и сервер их не воспринимает.
Это так, маленький ликбез. Так вот теперь объясни мне, как вся сеть будет работать "как ни в чем не бывало" ? =). Конфликт всёравно будет, и с сервером люди соединиться не смогут, если не пробьют статически его реальный мак. Так что твои бриджики - это толочь воду в ступе.
>Сервер стоит на линухе(судя по именам
>интерфейсов) и ему от конфликта по сути не холодно не жарко.моя невнимательность. Пришлось всю ветку перечитать заново, и учесть что РУДЗ и Админ - одно лицо.
>Конфликт айпи адресов - это рассылка по сети arp пакетов
>с таким же ip, но другим маком, что сбивает с толку
>все машины в сети(на которых мак не пробит статично), и пакеты
>серверу они отправляют уже на левый мак, и сервер их не
>воспринимает.
>Это так, маленький ликбез.Спасибо, буду знать. (Кто бы мог подумать что arp - это address resolution protocol? ;)
> Так вот теперь объясни мне, как вся сеть
>будет работать "как ни в чем не бывало" ? =). Конфликт
>всёравно будет, и с сервером люди соединиться не смогут, если не
>пробьют статически его реальный мак. Так что твои бриджики - это
>толочь воду в ступе.1. Может я неправильно понял автора ветки, но он просил защитить сервер, а не юзеров(буквально поняв "сервер в дауне"). В этом случае против бриджика возражений нет?
2. В остально согласен - насчет "как ни в чем не бывало" - погорячился,пользователям прийдется несладко, и бороться с этим можно лишь на канальном уровне, т.к. статические ARP таблицы - не спасут от подмены MAC-a на "правильный".
3. А бриджик фильтрующий - все равно разумно поставить, учитывая что локалка практически неподконтрольна админу. И не забывать про логи - они лучший помощник админа.
P.S. О VLAN-ах не упоминал намеренно, т.к. автор сразу оговорился что железо у него бюджетное.
Да нормальное решение.
Фиксириешь на фаеровлле пару MAC-IP и только ее пропускаешь через фильтрующий мост.
Вообще определись что ты хочешь.
Иначе где гарантия что эта задница не начнет менять на клиентские адреса свой адрес, и ты будешь за ней ганяться без устали.
>Да нормальное решение.
>Фиксириешь на фаеровлле пару MAC-IP и только ее пропускаешь через фильтрующий мост.А не понимаю, как тогда все клиенты будут отсылать запросы на сервер через этот бриджик, если, скажем он будет пропускать только одну пару IP-MAC?
Или скажем тогда такой вариант - на бриджике два интерфейса, один смотрит в сеть другой в сервер, и пускает скажем только пакеты от source 172.0.0.1 в сеть, а из сети с source 172.0.0.1 ничего не принимает? Тогда получается, что сервер надо выделять в другую подсеть, а бриджу уже присвоить 172.0.0.2 и 10.1.0.1. В итоге уже Бридж будет конфликтовать с этим кулхацкером, и что это изменит? Система у меня FreeBsd 5.2.1. А Паша, тебя не понял чуть как с помощью ВПН можно его найти и ликвидировать кроме как отключать от сети физически???
>>Да нормальное решение.
>>Фиксириешь на фаеровлле пару MAC-IP и только ее пропускаешь через фильтрующий мост.
>
>А не понимаю, как тогда все клиенты будут отсылать запросы на сервер
>через этот бриджик, если, скажем он будет пропускать только одну пару
>IP-MAC?
>Или скажем тогда такой вариант - на бриджике два интерфейса, один смотрит
>в сеть другой в сервер, и пускает скажем только пакеты от
>source 172.0.0.1 в сеть, а из сети с source 172.0.0.1 ничего
>не принимает? Тогда получается, что сервер надо выделять в другую подсеть,
>а бриджу уже присвоить 172.0.0.2 и 10.1.0.1. В итоге уже Бридж
>будет конфликтовать с этим кулхацкером, и что это изменит? Система у
>меня FreeBsd 5.2.1. А Паша, тебя не понял чуть как с
>помощью ВПН можно его найти и ликвидировать кроме как отключать от
>сети физически???
Ты путаешь бридж с роутером.
>Да нормальное решение.
>Фиксириешь на фаеровлле пару MAC-IP и только ее пропускаешь через фильтрующий мост.
>
>Вообще определись что ты хочешь.
>Иначе где гарантия что эта задница не начнет менять на клиентские адреса
>свой адрес, и ты будешь за ней ганяться без устали.
йопт. вы вообще механизм работы TCP/IP себе хоть в общих чертах представляете? :) Сервер лиш информирует админа о конфликте IP адресов, но на самом деле никакого вреда в формальном смысле серверу это не причиняет. Конфликт IP - это конфликт в arp таблицах клиентов сети, а не какая то ведьма, которая бежит по проводам и кусает сервак, и от которой можно отгородиться бриджем.
не факт что будет только информировать, в результате может быть очень даже нарушена работа.по поводу бриджа.
он будет пропускать только разрешенные пары, сколько хостов за ним столько и пар, если бедет изменен хотя бы один элемен пары, пакет не проходит в сегмент.
>не факт что будет только информировать, в результате может быть очень даже
>нарушена работа.Ага, проц сгорит и пробки в доме повышибает. Я тебе заявляю что ФАКТ -серверу похрену на такой же айпи в сети. Ничего ему не будет, тем более линуксу/юниксу. Они и не от таких атак отбиваются влёгкую =)
>по поводу бриджа.
>он будет пропускать только разрешенные пары, сколько хостов за ним столько и
>пар, если бедет изменен хотя бы один элемен пары, пакет не
>проходит в сегмент.А смысл? :)) Сервер и сам отбросит пакеты идущие на его IP, но не на его мак. И выдаст предупреждение, которое наш герой и видел. Но инет у юзеров от этого не заработает :)
Что то я не догоняю.Никто и не говорит что сервер выйдит из строя, но работа сети может быть нарушена.
Как ты считаешь если хост пошлет запрос "Кто имеет адрес IP" а ему будет выдан ложный мак? Куда уйдет пакет предназначенный серверу?сервер-фильрующий бридж-свич-локальная сеть.
бридж не пропускает к серверу пакеты с парой мак-ip кототорой не разрешено
>Что то я не догоняю.
И я про тоже. Почитай доки по TCP/IP.
>Никто и не говорит что сервер выйдит из строя, но работа сети
>может быть нарушена.Ну почему, объясни мне? :) на него будут сыпаца пакеты с ложным маком, он будет их отбрасывать и всё. Нормальные пакеты будет обрабатывать как обычно.
>Как ты считаешь если хост пошлет запрос "Кто имеет адрес IP" а
>ему будет выдан ложный мак? Куда уйдет пакет предназначенный серверу?На компьютер хулигана. И бриджем ты это не исправишь :)
>
>сервер-фильрующий бридж-свич-локальная сеть.
>бридж не пропускает к серверу пакеты с парой мак-ip кототорой не разрешеноНу и что,что не пропускает то? :))) Ему от этих пакетов не тепло и не холодно. Вот смотри.
Сеть нормально работает. У клиента A пробит реальный мак сервера. Появился хулиган. Клиент A,ловит арп пакет с ложным маком, в арп таблице мак сервера сменяется на ложный. Клиент отправляет пакет серверу, содержащий уже ложный мак. Свичи(обычные, неуправляемые) отправляют этот пакет, в соответствии с маком уже на комп хулигану. До бриджа с сервером он даже не дойдёт. Комп хулигана есессно инет не раздаёт и юзер слетает с инета. Ну и причём тут бридж,объясни мне?
ok
можно хулигана посадить за бридж.
>ok
>можно хулигана посадить за бридж.Так в условии задачи сказано, что неизвестно где хулиган. Еслиб знать - кусачками пару вот и весь бридж =)
А ну тогда управляемый свич.
За каждым портом закрепить мак или группу мак.
При смене MAC задница не получит доступа.
При смене IP в логах смотреть с какого порта это безобразие и далее по обстановке.Еще была версия DHCP закреплять пары.
>А ну тогда управляемый свич.
>За каждым портом закрепить мак или группу мак.
>При смене MAC задница не получит доступа.
>При смене IP в логах смотреть с какого порта это безобразие и
>далее по обстановке.
>
>Еще была версия DHCP закреплять пары.
Дорого. проще пойти по крышам, отрубая сегменты сети, и смотря, пропадает конфликт или нет. Таким образом последовательно вычислить пендоса. Провод кусачками, пендосу в бубен, на форум сети статью про возмездие пендосам, чтоб другим неповадно было.
> Сеть нормально работает. У клиента A пробит реальный мак сервера. Появился
>хулиган. Клиент A,ловит арп пакет с ложным маком, в арп таблице
>мак сервера сменяется на ложный.
Бред. Если у Клиента А в таблице есть правильный мак, то клиент будет работать с правильным сервером. Никакой арп с ложным маком при этом он не может поймать (т.к. ответ на арп запрос не широковещательный, а предназначен только тому кто не знал мак и спросил его). Ситуация с появлением у клиента неправильного мака в таблице арп может возникнуть только если клиент либо не работал до этого с правильным сервером (= не знал), либо мак из таблицы был потерт по таймауту (= забыл). Отсюда следует, что прописание у каждого клиента правильного мака статически (в винде это выглядит типа "arp -s 157.55.85.212 00-aa-00-62-c6-09") лечит ситуацию. И об этом выше уже не раз упоминалось...> Клиент отправляет пакет серверу, содержащий уже
>ложный мак. Свичи(обычные, неуправляемые) отправляют этот пакет, в соответствии с маком
>уже на комп хулигану. До бриджа с сервером он даже не
>дойдёт. Комп хулигана есессно инет не раздаёт и юзер слетает с
>инета. Ну и причём тут бридж,объясни мне?
Далее все верно.
>> Сеть нормально работает. У клиента A пробит реальный мак сервера. Появился
>>хулиган. Клиент A,ловит арп пакет с ложным маком, в арп таблице
>>мак сервера сменяется на ложный.
>Бред. Если у Клиента А в таблице есть правильный мак, то клиент
>будет работать с правильным сервером. Никакой арп с ложным маком при
>этом он не может поймать (т.к. ответ на арп запрос не
>широковещательный, а предназначен только тому кто не знал мак и спросил
>его). Ситуация с появлением у клиента неправильного мака в таблице арп
>может возникнуть только если клиент либо не работал до этого с
>правильным сервером (= не знал), либо мак из таблицы был потерт
>по таймауту (= забыл). Отсюда следует, что прописание у каждого клиента
>правильного мака статически (в винде это выглядит типа "arp -s 157.55.85.212
Может проведём эксперимент? Винда влёгкю менят динамический мак, при получении ложного арп пакета. Проверено занусси епт.
> Может проведём эксперимент? Винда влёгкю менят динамический мак, при получении ложного
>арп пакета. Проверено занусси епт.
Зачем? Я тебе и так верю, только вот откуда этот ложный пакет возьмется, если его только специально не будут рассылать?
>> Может проведём эксперимент? Винда влёгкю менят динамический мак, при получении ложного
>>арп пакета. Проверено занусси епт.
>Зачем? Я тебе и так верю, только вот откуда этот ложный пакет
>возьмется, если его только специально не будут рассылать?В теории так. А на практике винда переспрашивает мак с периодичностью минут в 10-20.а то и чаще. У нас был irc сервак в локалке, на нём висело человек 60, при конфликте IP, через 10-15 минут там оставались только те, у кого мак пробит статически.
> А смысл? :)) Сервер и сам отбросит пакеты идущие на его
>IP, но не на его мак. И выдаст предупреждение, которое наш
>герой и видел.
Ага ... возьмет лопату побольше и как швырнет подальше....
Если сеть на свичах построена, то как этот пакет на его IP и не на его мак вообще к нему попадет? Или свичи уже занимаются коммутацией пакетов по IP? Вроде бы пока речь о втором уровне шла...
Ловите его и отключайте, а если сможете то переломайте пальцы. Охотников менять маки в сети немного. Во первых потому что хулиганов среди людей только каждый 100-й, а во-вторых не все хулиганы умеют менять мак.
Лучше поймать его, конечно сеть подкреплять тоже надо, с этим никто не спорнит, но вы укрепите с одной стороны он пойдет с другой.
Просто иди отрубай его квартиру - никаких компромисов.
Кстати вот недорогой свич lightcom.ru
Позволяет блокировать маки на порту, типа кроме как с тех маков которые прописаны ничего не пропускает.
Свич наверняка глючный так как русский, но я купил. Кроме всего он позволяет блокировать бродкастовые атаки и все прочее.
Большое спасибо все откликнувшимя, не ожидал, что ветка так разрастется =)
А про конфликт адресов - очень и очень не прав автор, пишущий, что от этого сервер не падает. Как только появляется нарушитель - все компы сети начинают метаться кому все же принадлежит 10.1.0.1, пропадает пинг до него, через SSH хрен подключишься и т.д. вобщем инет минуту есть минуту нет и похрен это линукс юникс или солярис, проверено! Главное, что пользователи оскалившиеся в спину дышут =)
>А про конфликт адресов - очень и очень не прав автор, пишущий,
>что от этого сервер не падает. Как только появляется нарушитель -
>все компы сети начинают метаться кому все же принадлежит 10.1.0.1, пропадает
>пинг до него, через SSH хрен подключишься и т.д. вобщем инет
>минуту есть минуту нет и похрен это линукс юникс или солярис,
>проверено! Главное, что пользователи оскалившиеся в спину дышут =)r4 как раз таки прав в этом. SHH - это удаленная консоль, работающая поверх TCP/IP, а потому пакеты летят туда, куда указывает arp-таблица, а так как в ней периодически меняется связка MAC-IP, то и пакеты уходят на разные машины. Поэтому все-таки стоит задуматься об свичах, позволяющих привязывать MAC к порту. Тогда ты однозначно будешь знать КТО нарушает политику безопасности. Во всяком случае - на каком свиче и на каком порту это произошло. А если есть WEB-менеджмент, то вообще не нужно никуда бегать, можно отключить порт на свиче дистанционно.
Единственно, что дороговато получается поставить 50 управляемых свитчей =(
>Единственно, что дороговато получается поставить 50 управляемых свитчей =(
зачем же 50
ставь не 50, а 5 просто распредели чтобы они делили сетку на приблизительно равные участки
потом хотя бы примерна будешь знать откуда ветер дует
>Единственно, что дороговато получается поставить 50 управляемых свитчей =(Если нужно просто побороть ситуацию, то я уже (как и многие другие) написал как это можно сделать с помощью статической привязки мак-адреса сервера к его ip-адресу у каждого клиента на компе. (см. сообщение 54). Хотя конечно вариант с установкой свичей которые умеют "привязывать" мак и ip к конкретному порту вернее будет, да и пользователям так проще.
Если есть желание поймать нарушителя, то здесь нужно обзавестись хотя-бы одним управляемым свичом (можно второго уровня, например D-Link DES-3226S). Далее действовать примерно так: допустим товарищь с телефоном садиться за простой комп подключеный к сети (в тот момент когда нарушитель уже действует) и запускает на нем tcpdump (если на компе *nix) или windump (если это винда) и очищает на компе арп таблицу. Далее пускаем пинг на сервер (это синициирует арп запрос) и смотрим в tcpdump'e кто на него ответит. Да, и предварительно нужно поставить управляемый свич, вместо того свича куда втыкался этот комп в обычной ситуации. Причем, важно запустить tcpdump или windump с ключиком -e, дабы видеть реальные адреса отправителей арп ответов (т.к. нарушитель может отправлять arp-ответ не со своим маком, а с ложным - если его цель просто вывести сервер из строя). Далее, увидев реальный мак нарушителя, смотрим на каком порту он светиться - т.е. какой свич включен в этот порт и который мы будем менять следующим. Дальше берешь мобилу, управляемый свич под мышку и вперед - к следующей точке сети. Меняешь свич, товарищь за компом повторяет описанные выше действия, на сей раз можно без tcpdump, т.к. арп нарушителя уже известен и цель повтороной очистки таблицы мак-адресов и повторный пинг сервера сводиться к тому, чтобы синициировать арп-ответ нарушителя (чтобы он попал в таблицу мак-адресов управляемого свича установленного в новом месте сети). Товарищь
смотрит на свиче с какого порта засветился мак, звонит тебе - и вперед вдоль нового патчкорда до следующего свича... И т.д. пока это не окажется конкретная веревка до конктретного абонента. Далее рекомендую сначала зайти к этому юзеру и отключить патч-корд от сетевого интерфейса компа (спросите зачем - для того чтобы проверить, погас ли этот порт на свиче или, кто-то особо умный разрезал патч-корд на этого, возможно "невинного" абонента, и поставил в разрыв свой маленький свитчик и пакостит потихому (т.е. несанкционированно получил доступ в сеть - такого можно сразу и ногами отпинать)). Если после отключения патч-корда порт погас - то источник проблемы перед вами. Далее решайте сами - бокорезы ли, в бубен ли или еще как... Но учтите, что возможно (я с таким уже сталкивался), это не злодей никакой, а просто ламер ушастый, который запустил на своем свежеустановленном линухе коряво-сконфигуренную-прогу-не-известно-для-чего и сам не понимает что натворил.Удачи.
P.S. Второй вариант не исключает первый (если пользователи это еще смогут вытерпеть, то я бы порекомендовал бы им прописать статически пару мак-ip сервера, чтобы они могли работать, а потом бы занялся отловом нарушителя).
IMHO можно победить и без помощи управляемого свитча - только побегать придется. Итак...
Свитч, получая, пакет на свой порт сохраняет MAC-адрес пакета в специальной таблице для того, чтобы "знать", что пакеты для такого MAC-адреса надо отправлять на этот порт. (Извините за очевидные вещи, но они дальше понадобятся).
Как только нарушитель начал действовать, надо отключить сервер от свитча (чтобы он, посылая пакеты не пытался восстановить справедливость) и вместо него включить "новый" комп с новым MAC-адресом. Первый пакет с "нового" компа заставит свитч переписать свою таблицу. Т.к. нарушитель уже действует, то на всем пути от него свитчи уже изменили свою таблицы (именно поэтому он мешает нам работать, т.к. "неумный" свитч ВСЕГДА реагирует на последние данные/пакеты). С "нового" копма, используя ping, посылаем серии пакетов - две коротких серии, длинную серию, пауза(вариации по вкусу) и так продолжаем до нахождения мерзавца. Серии подбираются таким образом, чтобы их легко было отличить по светоиндикации на свитчах. Дальше начинается беготня: идем и смотрим какие порты светятся "по-нашему" и выходим на нарушителя. Даже если он выключит свой комп мы выйдем на его свитч. Единственное, что спасет его от обнаружения - это смена MAC-адреса на новый пока вы будете его искать...
>IMHO можно победить и без помощи управляемого свитча - только побегать придется.
>Итак...
>Свитч, получая, пакет на свой порт сохраняет MAC-адрес пакета в специальной таблице
>для того, чтобы "знать", что пакеты для такого MAC-адреса надо отправлять
>на этот порт. (Извините за очевидные вещи, но они дальше понадобятся).
>
>Как только нарушитель начал действовать, надо отключить сервер от свитча (чтобы он,
>посылая пакеты не пытался восстановить справедливость) и вместо него включить "новый"
>комп с новым MAC-адресом. Первый пакет с "нового" компа заставит свитч
>переписать свою таблицу. Т.к. нарушитель уже действует, то на всем пути
>от него свитчи уже изменили свою таблицы (именно поэтому он мешает
>нам работать, т.к. "неумный" свитч ВСЕГДА реагирует на последние данные/пакеты). С
>"нового" копма, используя ping, посылаем серии пакетов - две коротких серии,
>длинную серию, пауза(вариации по вкусу) и так продолжаем до нахождения мерзавца.
>Серии подбираются таким образом, чтобы их легко было отличить по светоиндикации
>на свитчах. Дальше начинается беготня: идем и смотрим какие порты светятся
>"по-нашему" и выходим на нарушителя. Даже если он выключит свой комп
>мы выйдем на его свитч. Единственное, что спасет его от обнаружения
>- это смена MAC-адреса на новый пока вы будете его искать...
>
Ну просто ОЧЕНЬ бурная фантазия... Очень смешно... ну протсто обхохочешься :-| Вы сами это пробовали? Расскажите - как в сети из 50 свичей (допустим по 24 порта - это вроде бы около 1000 хостов) будут мигать лампочки на свиче который объединяет два крыла сети по 24 свича в каждом (т.е. около 500 хостов)? Это какой-такой пинг надо придумать чтобы серии "легко было отличить по светоиндикации на свитчах"? И что вы предлагаете делать этим 1000 хостам в тот момент когда вы будете посылать эти "серии"? Вы им в мегафон покричите - чтобы они прекратили общаться с "ложным" сервером - а то они вам мешают за светоиндикацией наблюдать? Если нравится смотреть на мигающие лампочки, то лучше пойти в магазин и купить себе гирлянду.
>Ну просто ОЧЕНЬ бурная фантазия... Очень смешно... ну протсто обхохочешься :-|А то!
>сами это пробовали? Расскажите - как в сети из 50 свичей
>(допустим по 24 порта - это вроде бы около 1000 хостов)
>будут мигать лампочки на свиче который объединяет два крыла сети по
>24 свича в каждом (т.е. около 500 хостов)?Очень просто будут мигать: Вы были бы правы, если бы не одно но
вся эта 1000 хостов очень быстро перестанет общаться с фальшивым сервером, по причине того, что общаются они в основном по TCP...>Это какой-такой пинг
man ping
>надо придумать чтобы серии "легко было отличить по светоиндикации на свитчах"?
Да к тому же, по началу (пока вся эта 1000 хостов не перестанет общаться с фальшивым сервером) этот трафик и так будет видно: порты свитчей, которые ведут к фальшивому серверу будут нагружены прямо пропорционально общей нагрузке на свитче...
>И что вы предлагаете делать этим 1000 хостам в тот момент
>когда вы будете посылать эти "серии"? Вы им в мегафон покричите
>- чтобы они прекратили общаться с "ложным" серверомЧитать на абзац выше.
>лучше пойти в магазин и купить себе гирлянду.
На "Новый Год" так и сделаю - спасибо, что подсказали.
И еще один момент - можно все это попробовать(хуже не станет) - а потом кричать ха-ха-ха...
Уважаемый, а если в сети есть FTP постоянно нагруженный, программы типа QCHAT, да и тому подобные всяческие пакеты-броадкасты ходят, юзеры вечером дружно в CS играют по сети. А каждый свитч из себя представляет примерно 1 вход магистрали один выход магистрали + 10-15 клиентов с этого конкретного дома. Так вот эти порты входа и выхода день и ночь с интервалом 0.00001 мс моргают. Что тогда делать с вашей интересной методикой?
А можно поподробнее как простому пользователю под вин сделать статическую привязку ип к маку сервера. Или может им какой-нить бат-файл раздавать?
>А можно поподробнее как простому пользователю под вин сделать статическую привязку ип
>к маку сервера. Или может им какой-нить бат-файл раздавать?Смотри сообщение номер 54. Куда уж еще подробнее. Можешь эту команду засунуть и в батник - и всем его раздать...
Если неохота искать мессагу в этом разросшемся треде - набери просто в винде arp без параметров - там есть пример.
>Уважаемый, а если в сети есть FTP постоянно нагруженный, программы типа QCHAT,
>да и тому подобные всяческие пакеты-броадкасты ходят, юзеры вечером дружно в
>CS играют по сети. А каждый свитч из себя представляет примерно
>1 вход магистрали один выход магистрали + 10-15 клиентов с этого
>конкретного дома. Так вот эти порты входа и выхода день и
>ночь с интервалом 0.00001 мс моргают. Что тогда делать с вашей
>интересной методикой?1. Это дополнительные данные, которых не было в начальных условиях.
2. Смотреть сообщ. 58 - можно все-таки организовать "существенную нагрузку" пакетами: не устраивает опция flood в ping - используйте возможности ядра "Network testing"...
3. Никто не мешает сделать это в период минимальной нагрузкт на сеть: если отключить сервер от свича когда появляется нарушитель, то некОму будет переписать таблицы в свитчах с MAC-адресом сервера и маршрут между свитчами до "его" свитча сохранится...
Логично. Только вот не понял я как его ловить, если он выключит комп. И потухнет его лампочка. Что тогда будет моргать?
А статический арп извиняюсь, пропустил выше. А можно ли как нибудь привязать им этот статический арп через DHCPD и как тогда бороться с конфликтами адресов - ведь все равно он меня выбивает, как только прописывает ип 10.1.0.1
>Логично. Только вот не понял я как его ловить, если он выключит
>комп. И потухнет его лампочка. Что тогда будет моргать?Все свитчи, кроме "его" будут по прежнему слать пакеты на "его" свитч, только вот там уже ничего мограть не будет. Но круг подозреваемых существенно снизится. В следующий его "сеанс" можно будет выловить с точностью в 99,99%.
А легальный сервер, после отключения от свитча, можно переконфигурировать на новые MAC/IP, подправить запись DNS и спокойно ловить нарушителя.
И еще: если сеть "наводнять" пакетами, то достаточно пройтись по свитчам 3-го уровня, чтобы выловить нарушителя (я так понимаю, что в такой большой сети используется именно 3-х уровневая схема включения свитчей, т.к. ethernet позволяет максимальную схему 3-5: т.е. между любыми двумя точками не более 3 единиц активного оборудования и не более 5 кабельных соединений...)
Еще одна мысль:
если сеть построена как головной свитч и в него все остальные свитчи, то вычислить свитч нарушителя достаточно просто, а уж дальше не более сложно: т.к. на головном свитче его порт будет нагружен сильнее всего, особенно, сразу после его появления. И как бы быстро не мигали остальные индикаторы - индикатор на "его" порт будет активнее всех остальных.
>3. Никто не мешает сделать это в период минимальной нагрузкт на сеть:
Да. И попросить нарушителя чтобы он именно в это время с нами поиграл :)>если отключить сервер от свича когда появляется нарушитель, то некОму будет
>переписать таблицы в свитчах с MAC-адресом сервера и маршрут между свитчами
>до "его" свитча сохранится...
По поводу переписывания маршрута - бред. Какой такой маршрут - если у правильного сервера и у ложного разные маки. То что вы предлагаете звучит примерно так: продолжаем издеваться над пользователями (ведь именно их мы используем как индикатор) и бегаем с бубном по микрорайону пытаясь найти логику в мигании лампочек. Причем бегать от свича до свича нужно со скоростью звука как-мининмум, т.к. если нарушитель всетаки выключил свой комп - то свичи почистят его мак по таймауту и все. Даже если не почистят, а комп всетаки выключен - то найдется только свич куда он подключен, а не конкретный порт на этом свиче.
>>сами это пробовали? Расскажите - как в сети из 50 свичей
>>(допустим по 24 порта - это вроде бы около 1000 хостов)
>>будут мигать лампочки на свиче который объединяет два крыла сети по
>>24 свича в каждом (т.е. около 500 хостов)?
>
>Очень просто будут мигать: Вы были бы правы, если бы не одно
>но
>вся эта 1000 хостов очень быстро перестанет общаться с фальшивым сервером, по
>причине того, что общаются они в основном по TCP...
Ага. Я так понимаю что перед тем как это затевать, нужно рассказать это
>Да к тому же, по началу (пока вся эта 1000 хостов не
>перестанет общаться с фальшивым сервером) этот трафик и так будет видно:
>порты свитчей, которые ведут к фальшивому серверу будут нагружены прямо пропорционально
>общей нагрузке на свитче...
>
>>И что вы предлагаете делать этим 1000 хостам в тот момент
>>когда вы будете посылать эти "серии"? Вы им в мегафон покричите
>>- чтобы они прекратили общаться с "ложным" сервером
>
>Читать на абзац выше.
>
>>лучше пойти в магазин и купить себе гирлянду.
>
>На "Новый Год" так и сделаю - спасибо, что подсказали.
>
>И еще один момент - можно все это попробовать(хуже не станет) -
>а потом кричать ха-ха-ха...
Сорри. Промахнулся с предыдущей мессагой...>>сами это пробовали? Расскажите - как в сети из 50 свичей
>>(допустим по 24 порта - это вроде бы около 1000 хостов)
>>будут мигать лампочки на свиче который объединяет два крыла сети по
>>24 свича в каждом (т.е. около 500 хостов)?
>
>Очень просто будут мигать: Вы были бы правы, если бы не одно
>но
>вся эта 1000 хостов очень быстро перестанет общаться с фальшивым сервером, по
>причине того, что общаются они в основном по TCP...
Ага. Я так понимаю что перед тем как это затевать, нужно рассказать это этой самой 1000-е хостов (где преимущественно винда стоит) что они должны прекратить рассылдать свои виндузячьи броадкасты, перестать слать арп-запроси и еще остановить кучу другой сетевой деятельности.>И еще один момент - можно все это попробовать(хуже не станет) -
>а потом кричать ха-ха-ха...
Жаль убитого на просмотр лампочек и построение необоснованых догадок времени...
мдя.. ну и понаписывали :)1. никакая прописка статичных arp-ip непоможет.
2. В большой сети обнаружить нарушителя методом мигания лампочки -- анриал !в связи с этим лучшее решение будет пожалуй такое
покупается управляемый свитч ! или собирается бридж машина !... выбор непринципиален.
далее ставим "апаратуру" вместо свитча если это управляемый свитч.. и в разрыв от свитча к следующему свитчу если это БРИДЖ
ждемс момента безобразия и снимаем показатели с свитча поставленного или бриджа. и так далее до момента выявления нарушителя...
далее собираются все пострадавшие и направляются к нарушителю :)
>2. В большой сети обнаружить нарушителя методом мигания лампочки -- анриалДа не такой уж и "анриал": какой нормальный клиент/софт в своей бычгой работе генерит 1000-10000 pk/s? А вот ping flood может...
>>2. В большой сети обнаружить нарушителя методом мигания лампочки -- анриал
>
>Да не такой уж и "анриал": какой нормальный клиент/софт в своей бычгой
>работе генерит 1000-10000 pk/s? А вот ping flood может...хотя смотря какие свитчи :) например "планеты" имеют свойство мигать монотонно - методично при любом трафике :) незнаю как где, а у нас до 95% свитчей используются (planet - 803).
>1. никакая прописка статичных arp-ip непоможет.
Можно поподробнее? Почему не поможет?>2. В большой сети обнаружить нарушителя методом мигания лампочки -- анриал
Здесь согласен на 100%...>в связи с этим лучшее решение будет пожалуй такое
>покупается управляемый свитч ! или собирается бридж машина !... выбор непринципиален.
Почему же не принципиален? ИМХО - это вопрос времени. Если сеть разветвленная - использование свича сокращает время поиска нарушителя в разы! Свичем мониторится сразу 24 порта, а бриджом только одна ветка. Т.е. Если предположить что это какой-нибудь головной свич то в одной точке надо поотдельности трахаться с 24-ветками. Да и с собой свич таскать намного легче чем писюк.
>>1. никакая прописка статичных arp-ip непоможет.
>Можно поподробнее? Почему не поможет?потому что если я неошибся по условиям задачи злобный хацкер меняет одновременно свой IP и MAC на сервачный. т.е. никакая прописка не укажут какой из этих 2 кампов с одинаковыми IP и MAC настоящий.
>>в связи с этим лучшее решение будет пожалуй такое
>>покупается управляемый свитч ! или собирается бридж машина !... выбор непринципиален.
>Почему же не принципиален? ИМХО - это вопрос времени. Если сеть разветвленная
>- использование свича сокращает время поиска нарушителя в разы! Свичем мониторится
>сразу 24 порта, а бриджом только одна ветка. Т.е. Если предположить
>что это какой-нибудь головной свич то в одной точке надо поотдельности
>трахаться с 24-ветками. Да и с собой свич таскать намного легче
>чем писюк.ну удобство хорошо :) но я хотел тут сказать, что неповлияет на результат :) хотя с бриджем понятное дело попотеть поболее прийдется :)
>>>1. никакая прописка статичных arp-ip непоможет.
>>Можно поподробнее? Почему не поможет?
>потому что если я неошибся по условиям задачи злобный хацкер меняет одновременно
>свой IP и MAC на сервачный. т.е. никакая прописка не укажут
>какой из этих 2 кампов с одинаковыми IP и MAC настоящий.
Если мак меняется на мак-сервера, тогда сложнее, хотя описанная схема отлова все равно сработает. А статика действительно не спасет. :(
Наверное можно отловить нарушителя и без беготни:
если включить активное оборудование по следующей схеме(на время отлова, т.к. такая схема будет напрягать сеть)
головной ХАБ
все свитчи включены в хабна хабе висит tcpdump. Слушаем трафик идущий на сервер (сервер надо включить в хаб). После появления нарушителя будет такая картина:
со свитчей, на которых НЕТ нарушителя будет по прежнему идти трафик для сервера, а со свитча, на котором висит нарушитель, трафик идти не будет, т.к. свитч нарушителя будет отправлять трафик своих пользователей непосредственно на порт нарушителя, и на хаб такой трафик не попадет.Разобрав вывод tcpdump мы увидим IP адреса только с тех свитчей, где нарушителя нет. Методом исключения получаем свитч нарушителя, а дальше по обстоятельствам...
>головной ХАБ
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Ну просто что не сообщение - так перл! Головной хаб в сети из (1000!!!) хостов. Вы когда-нибудь слышали такое слово: "коллизии"?>все свитчи включены в хаб
>
>на хабе висит tcpdump. Слушаем трафик идущий на сервер (сервер надо включить
>в хаб). После появления нарушителя будет такая картина:
>со свитчей, на которых НЕТ нарушителя будет по прежнему идти трафик для
>сервера, а со свитча, на котором висит нарушитель, трафик идти не
>будет, т.к. свитч нарушителя будет отправлять трафик своих пользователей непосредственно на
>порт нарушителя, и на хаб такой трафик не попадет.
Бред. Рекомендую изучить поподробней работу протоколов TCP/IP, ARP, RARP, стандарт 802.3 и только после этого забивать людям голову подобными идеями...>Разобрав вывод tcpdump мы увидим IP адреса только с тех свитчей, где
>нарушителя нет. Методом исключения получаем свитч нарушителя, а дальше по обстоятельствам...
Продолжение бреда...
>>головной ХАБ
>!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>Ну просто что не сообщение - так перл! Головной хаб в сети
>из (1000!!!) хостов. Вы когда-нибудь слышали такое слово: "коллизии"?1. Кроме Ваших предположений (Вы, наверное, телепат :) о 1000 хостов в сети - об этом нигде не написано.
2. IMHO Вы сами не знаете вопроса(о "коллизиях"):
на сегодняшний день даже самое дешевое оборудование может работать в "полнодуплексном режиме" (может Вы слыхали о таком? :), который(режим) полностью исключает коллизии... Почитать можно что-нибудь, например, введя в гугле: ethernet коллизии "полный дуплекс".
И даже самое дешевое оборудование имеет память для врЕменного хранения пакетов и работает в режиме "перегенерации" пакетов, а не как повторитель.
3. Если бы Вы когда нибудь изучали технику построения СКС, то Вы наверняка бы знали, что при некоторых услових предложенная мной схема работает БЫСТРЕЕ чем схема с головным свитчом.
4. Выловить трафик, идущий с произвольного свитча клиента на произвольный свитч нарушителя при другой схеме не удастся.>Бред. Рекомендую изучить поподробней работу протоколов TCP/IP, ARP, RARP, стандарт 802.3 и
>только после этого забивать людям голову подобными идеями...
Ну и при чем здесь TCP/IP, ARP...(опять умных слов нахватались?) Речь шла о том, что свитчи работают не зависимо от указанных Вами протоколов и будут с тем же успехом пересылать например трафик IPX, т.к. они работают по MAC адресам в кадре ethernet.
А вот tcpdump как раз поможет: как и было описано, трафик с машин, которые подключены на один свитч с нарушителем перестанет достигать центрального хаба, как только свитч получит от нарушителя пакет с MAC-адресом сервера(имеется ввиду адрес отправителя, а то Вы опять не поймете).Вы случаем не тот, кого ищут в этой сети? ;)
>>>головной ХАБ
>>!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>Ну просто что не сообщение - так перл! Головной хаб в сети
>>из (1000!!!) хостов. Вы когда-нибудь слышали такое слово: "коллизии"?
>1. Кроме Ваших предположений (Вы, наверное, телепат :) о 1000 хостов в
>сети - об этом нигде не написано.
У некоторых людей есть способность мыслить логически, у некоторых только фантазировать (отсюда видимо Ваш интерес к телепатии)...>2. IMHO Вы сами не знаете вопроса(о "коллизиях"):
>на сегодняшний день даже самое дешевое оборудование может работать в "полнодуплексном режиме"
>(может Вы слыхали о таком? :), который(режим) полностью исключает коллизии... Почитать
>можно что-нибудь, например, введя в гугле: ethernet коллизии "полный дуплекс".
>И даже самое дешевое оборудование имеет память для врЕменного хранения пакетов и
>работает в режиме "перегенерации" пакетов, а не как повторитель.
Ваша уверенность в себе, радует. Заниматься Вашим образованием не имею никакого желания. Те кто знает что такое семь уровней модели OSI, что такое концентратор (хаб) и что такое коммутатор (свич), на каких уровнях они работают и что такое полный дуплекс, они почему-то скромно молчат и не вступают со мной в полемику. Вам же почему-то захотелось поспорить. Я же вообше отвечаю на Ваши сообщения, что люди менее образованные в сетевых технологиях, а ведь весь этот тред интересен ИМХО только для них, могут подумать что Вы правы и впустую потратить свое время и силы на приобретение отрицательного и бесполезного опыта шамана изгоняющего "ведьму, которая бежит по проводам и кусает сервак".>3. Если бы Вы когда нибудь изучали технику построения СКС, то Вы
>наверняка бы знали, что при некоторых услових предложенная мной схема работает
>БЫСТРЕЕ чем схема с головным свитчом.
И где же Вы ее изучали если не секрет? И вообще вы про что? Умных словечек понахватались? Какой же стандарт СКС нам придет на помощь? Или может Вы не знаете как эта аббревиатура расшифровывается, раз вставляете ее куда ни попадя?>4. Выловить трафик, идущий с произвольного свитча клиента на произвольный свитч нарушителя
>при другой схеме не удастся.
Работающая схема отлова описана мной в сообщении 55 и проверена на практике неоднократно.>>Бред. Рекомендую изучить поподробней работу протоколов TCP/IP, ARP, RARP, стандарт 802.3 и
>>только после этого забивать людям голову подобными идеями...
>Ну и при чем здесь TCP/IP, ARP...(опять умных слов нахватались?) Речь шла
>о том, что свитчи работают не зависимо от указанных Вами протоколов
>и будут с тем же успехом пересылать например трафик IPX, т.к.
>они работают по MAC адресам в кадре ethernet.
Осталось только понять, о том как свичи узнают об этих самых мак-адресах и чем свичи отличаются от хабов. На эту тему есть много литературы - прочтите - узнаете много нового для себя. Поверьте, что сетевые технологии не ограничиваются знанием пары *nix-систем и слабым знакомством с оборудованием Cisco.>А вот tcpdump как раз поможет: как и было описано, трафик с
>машин, которые подключены на один свитч с нарушителем перестанет достигать центрального
>хаба, как только свитч получит от нарушителя пакет с MAC-адресом сервера(имеется
>ввиду адрес отправителя, а то Вы опять не поймете).
Это Вы здесь что-то не понимаете. Трафик перестанет достигать хаба, только тогда, когда машины сидящие на данной ветке потеряют мак-адрес настоящего сервера и получат в результате работы протокола ARP мак-адрес ложного сервера. И свич здесь не причем. Это может случиться с любой машиной в сети, если на ней не прописана статика. И вообще, с чего Вы взяли что топология сети такая? Опять неуемная фантазия разыгралась?
Разберитесь как работает сеть, научитесь выражать свои мысли грамотными техническими терминами, а потом уже что-то кому-то советуйте.>Вы случаем не тот, кого ищут в этой сети? ;)
Судя по тому как рьяно Вы хотите ввести людей в заблуждение (или может просто поиздеваться) то может быть это Вас ищут?
>Ваша уверенность в себе, радует. Заниматься Вашим образованием не имею никакого желания.Я очень рад, что мои учителя отличались от Вас.
>Те кто знает что такое семь уровней модели OSI, что такое
>концентратор (хаб) и что такое коммутатор (свич), на каких уровнях они
>работают и что такое полный дуплекс, они почему-то скромно молчат и
>не вступают со мной в полемику.Да и мне мам говорила: "Не мечи бисер..." - жаль не послушал ее.
>Вам же почему-то захотелось поспорить.
>Я же вообше отвечаю на Ваши сообщения, что люди менее образованные
>в сетевых технологиях, а ведь весь этот тред интересен ИМХО только
>для них, могут подумать что Вы правы и впустую потратить свое
>время и силы на приобретение отрицательного и бесполезного опыта шамана изгоняющего
>"ведьму, которая бежит по проводам и кусает сервак".А это случайно не Ваши слова были?
>на помощь? Или может Вы не знаете как эта аббревиатура расшифровывается,
>раз вставляете ее куда ни попадя?
Не знаю я что это за аббревиатура такая (наверное AESP мне зря сертификат выдала... :))>>Ну и при чем здесь TCP/IP, ARP...(опять умных слов нахватались?) Речь шла
>>о том, что свитчи работают не зависимо от указанных Вами протоколов
>>и будут с тем же успехом пересылать например трафик IPX, т.к.
>>они работают по MAC адресам в кадре ethernet.
>Осталось только понять, о том как свичи узнают об этих самых мак-адресах
>и чем свичи отличаются от хабов. На эту тему есть много
>литературы - прочтите - узнаете много нового для себя. Поверьте, что
>сетевые технологии не ограничиваются знанием пары *nix-систем и слабым знакомством с
>оборудованием Cisco.
Иногда справки виндовс недостаточно...>>А вот tcpdump как раз поможет: как и было описано, трафик с
>>машин, которые подключены на один свитч с нарушителем перестанет достигать центрального
>>хаба, как только свитч получит от нарушителя пакет с MAC-адресом сервера(имеется
>>ввиду адрес отправителя, а то Вы опять не поймете).
>Это Вы здесь что-то не понимаете. Трафик перестанет достигать хаба, только тогда,
>когда машины сидящие на данной ветке потеряют мак-адрес настоящего сервера и
>получат в результате работы протокола ARP мак-адрес ложного сервера. И свич
>здесь не причем. Это может случиться с любой машиной в сети,
>если на ней не прописана статика.
Вот это бред, так уж бред: Вас послушаешь и непонятно становится - как же нарушитель мешает работе сервера?
Как нибудь на досуге, возьмите свитч, подключите к нему 3 машины: "сервер", "клиент" и "нарушитель". Подключитесь с "клиента" к "серверу". Затем с "нарушителя" пошлите ЛЮБОЙ пакет, предварительно сконфигурировав его интерфейс на MAC & IP "сервера". Теперь попробуйте попинговать с "клиента" "сервер" и посмотрите куда будет идти трафик. IMHO таких как Вы ламерами зовут("хромают" у Вас познания...)>И вообще, с чего Вы
>взяли что топология сети такая? Опять неуемная фантазия разыгралась?
А вы сами логически подумайте(может понравится и думать станете чаще) или спросите у "Admin"...>Разберитесь как работает сеть, научитесь выражать свои мысли грамотными техническими терминами, а
>потом уже что-то кому-то советуйте.
>
>>Вы случаем не тот, кого ищут в этой сети? ;)
>Судя по тому как рьяно Вы хотите ввести людей в заблуждение (или
>может просто поиздеваться) то может быть это Вас ищут?
:))) без комментариев...
Надеюсь что мой ответ на вопрос данного треда был исчерпывающим. Если есть желание разобраться в происходящем или потребуется консультация - можно в мыло (я его не скрываю, в отличие от некоторых).Что касается Вас, John, то дальнейший диспут считаю нецелесообразным, т.к. Вам лично он пользы не принесет. Вы безусловно царь и бог, и при Вашем появлении все должны падать ниц и расползаться по углам.
>Если есть
>желание разобраться в происходящемЕсть такое желание: мы просто попросим человека, который обратился с этой проблемой, рассказать как он в итоге ее решил.
>или потребуется консультация
упаси бог...
Да что за идиотизм... Взять у кого нить на время, купить в крайнем случае (всегда пригодится) управляемый свитч второго уровня, и этого достаточно чтоб найти нарушителя. Всё...
В догонку. Ну а уж если в сети из 300-400 хостов нет ни одного управляемого свитча, то админу (или кто там структуру сети такую выдумывал) уже лечиться нужно, что уж говорить о 1000.
Разобрав кучу топиков, все же решил, что наиболее приемлимо по бюджету/возможностям решение для нас ( а в том числе и для большинства ) использовать один управляемый свитч + лаптоп, чтобы не тревожить друзей и не облучать голову радиацией от мобильника ( топик 55 ).
Так же более легкое решение чтобы все это не таскать - отключать по очереди вручную магистрали и смотреть куда идет пинг, если ICMP разрешено у кулхацкера.
Так же хорошее решение использовать бридж, но неосуществимо для многих, кто вешает коробки с оборудованием в подъездах.
Как вариант очень хороший, но дорогостоящий, можно рассматривать деление сети на несколько сегментов управляемых подсетей умными свитчами.
Наименне приемлимым, хоть не спорю, может и осуществимым, считаю смотреть индикацию лампочек, т.к. они у нас моргают постоянно как угорелые.
p.s. а топология у нас именно почти кольцо, а не звезда, т.к. пары идут от дома к дому от звена к звену.
p.p.s после этого треда проблема пока что неожиданно исчезла =)))
p.p.p.s большое спасибо еще раз за поддержку всем откликнувшимся, за ваши интересные идеи.
>Разобрав кучу топиков, все же решил, что наиболее приемлимо по бюджету/возможностям решение
>для нас ( а в том числе и для большинства )
>использовать один управляемый свитч + лаптоп, чтобы не тревожить друзей и
>не облучать голову радиацией от мобильника ( топик 55 ).
Тоже нормальный вариант. Метода та же, только комп с собой (таскать чуть тяжелее, зато экономия на мобильной связи и не нужен второй человек :)>Так же более легкое решение чтобы все это не таскать - отключать
>по очереди вручную магистрали и смотреть куда идет пинг, если ICMP
>разрешено у кулхацкера.
Здесь важно не ICMP. Оно у него может быть и запрещено. Нужно ставить свич, убивать мак-адрес сервера на лаптопе, пытаться запустить пинг на сервер (разрешен он или нет - неважно, важно что перед посылкой первого ICMP пакета будет произведена посылка ARP-запроса, на которую откликнется как правильный, так и ложный сервер и в этот момент свич увидит - на каком порту засветиться пакет с мак-адресом ложного сервера, а это и требуется), смотреть с какой веревки он приходит и двигаться вдоль нее дальше - сужая круг поисков.>p.s. а топология у нас именно почти кольцо, а не звезда, т.к.
>пары идут от дома к дому от звена к звену.
ну полного кольца у вас ведь все равно нет, т.ч. нужно идти по тем веткам вашего "дерева" с которых будет приходить мак нарушителя.
(И еще: если нарушитель подделывает мак-адрес сервера на точно такой же, то вы столкнетесь с ситуацией когда один и тот же мак (мак правильного сервера) будет светиться на 2-х портах свича. В этом случае один порт должен привести вас к правильному серверу (т.к. вы знаете где он стоит, то наверное определить его будет не сложно), а второй порт приведет к нарушителю.)>p.p.s после этого треда проблема пока что неожиданно исчезла =)))
Возможно товарищь тоже почитывает эту конференцию и почуял что жареным запахло :)
>использовать один управляемый свитч + лаптоп, чтобы не тревожить друзей и
>не облучать голову радиацией от мобильника ( топик 55 ).промучавшись с поочередным отключением сегментов, рано или поздно все-равно придешь к выводу, что пора покупать управляемое оборудование хотябы 2-го уровня - просто поверь мне :)
>Так же более легкое решение чтобы все это не таскать - отключать
>по очереди вручную магистрали и смотреть куда идет пинг, если ICMP
>разрешено у кулхацкера.это не проблема, если хост будет в том же езернет сегменте - под *nix есть программа arping (под фри в портах есть), которой по барабану файрволы юзверей - на другом уровне работает, а интерфейс как у ping
>>Если есть
>>желание разобраться в происходящем
>
>Есть такое желание: мы просто попросим человека, который обратился с этой проблемой,
>рассказать как он в итоге ее решил.
>
>>или потребуется консультация
>
>упаси бог...
Это было написано не для Вас. То что касалось Вас - было ниже.
A nelzya li, prosto otklyuchit servak, a potom s kompa soseda pri pomoshi traceroute vichislit put' k etomu merzavtsu, po krayney mere ip izvesten, a tam dalee deystvovat po obstoyatelstvam?????
Сегмент сети то один, общий, traceroute не умеет считать свитчи.
>Сегмент сети то один, общий, traceroute не умеет считать свитчи.Однако, если злоумышленник, определив IP- и MAC-адреса какого-либо компьютера в своей сети, дождется его выключения (или проведет против него атаку «отказ в обслуживании», приводящую к неспособности атакуемого хоста работать в сети), а потом присвоит себе его MAC- и IP-адреса, то обнаружить такого злоумышленника будет невозможно и все его действия будут приписаны атакованному хосту.
http://www.nag.ru/goodies/netbook/ch9.html
>>Сегмент сети то один, общий, traceroute не умеет считать свитчи.
>
>Однако, если злоумышленник, определив IP- и MAC-адреса какого-либо компьютера в своей сети,
>дождется его выключения (или проведет против него атаку «отказ в обслуживании»,
>приводящую к неспособности атакуемого хоста работать в сети), а потом присвоит
>себе его MAC- и IP-адреса, то обнаружить такого злоумышленника будет невозможно
>и все его действия будут приписаны атакованному хосту.
>
>http://www.nag.ru/goodies/netbook/ch9.htmlДля этого логи dhcp посмотреть надо.
И если dhcp говорил клиенту что гатевей по умолчанию
адрес свича. Тогда traceroute все покажет правильно.
Так что не надо "умную" воду лить.
Кстати о проводах.
Вирус надо запустить, который их окислит
до состояния Cu2-O никакой хацкер этого не переживет.
;-))))))))
я конечно до конца не дочитал, но вот такой вариант я видел в одной из московских сеток микрорайонных, у нового клиента выписывался МАС с сетевухи и потом видимо прописывался в файерволе, кто клиент - тот пройдет, кто нет - в отлуп, залезть под несовпадающим МАС/ИП не получится.
>я конечно до конца не дочитал, но вот такой вариант я видел
>в одной из московских сеток микрорайонных, у нового клиента выписывался МАС
>с сетевухи и потом видимо прописывался в файерволе, кто клиент -
>тот пройдет, кто нет - в отлуп, залезть под несовпадающим МАС/ИП
>не получится.
Ты действительно недочитал :)Поидее топ закрыт уже...
>Помогите, пожалуйста, уж нет сил бороться с хулиганами. Прописывают ip сервера у
>себя на компе, меняют мак и в итоге сервер в дауне.
>Ну как бороться с такими кроме отключения сегментов и поиска вредителя,
>( большой микрорайон) и покупки упраляемых свитчей?? ( очень дорого ).
>Почему постоянно он отбивает у сервера адрес, хоть и сервер первый
>включается в сеть? Может есть какая софтина, чтобы сервер был устойчивее,
>чтобы ip невозможно было отбить и он не реагировал на ip
>address conflict??
Хм, почитал я тут половину всего что важные и умные папы написали. Глазки заболели. Я вот посоветую такую фишку - в связи с малобюджетностью (тобто жмемся на бабки) покупаем штуки 4 (скока есть свободных PCI слотов на серваке) сетевухи. По цене аж 6 баков каждая - думаю не разоримся. Делим сеть на количество сегментов равных количеству сетевух в серваке -1.Каждому интерфейсу свой ИП. К внешнему доступ изнутри запретить. Уже добились того, что ложится будет только ЧАСТЬ сети (тобишь один сегмент). Дальше у нас количество подозреваемых уменьшается пропорционально количеству внутренних интерфейсов на серваке.
Далее берем бриджик хотя-бы с тремя сетевухами. Топаем к ближайшему свичу, вытаскиваем оттуда два шнура, тыкаем их в бриджик. Один шнур из бриджика тыкаем в свич. Ждем. Бриджик соответственно настроен так, что-бы не пропускать пакеты с айпишником сервака но левым маком. И пропускать эти пакеты можно только с внутреннего интерфейса на внешний. То-есть разграничиваем два маленьких подсегментика. И записываем жалобы. Если сеть падает в масштабах всего этого свича, то меняем шнуры. Если жалобы будут в нутри одного из подсегментиков ограниченных бриджиком, то по вышеописанному алгоритму сужаем круг поиска.
Времени и усилий уйдет конечно много, но потом находим вредину, кидаем его на землю, и долго и с удовольствием бьем его ногами :))) На это мероприятие можно пригласить друзей.
У меня была похожая проблемма, но юзер менял только IP
пока его ловили в автозагрузку прописывали юзерам следующее
arp -s IP_сервера Mac_сервера, конечно идиотизм, но работало.
Мы перца отключили - предупредив. Он долго вонял что нету такого пункта в договоре - обещал в суд подать, мы ему сказали что он нарушает УК и он заткнулся. Потом еще по мылу разослали адрес конкурентам, чтобы ему затруднительно было пользоваться инетом и в будущем и на сайте опубликовали, конечно без реквизитов, но чтобы другим не повадно было.
То что мы опубликовали было сделано зря так как другим стало как раз повано - все сразу возомнили себя хакерами и тд, поэтому пришлось отключить еще 4-рых.
Не повторяйте моей ошибки делайте все молча и до конца.
Еще кстати прикол был
только слава богу сервак это не затронуло
у сетевых карточек SIS у всех одинаковые MAC адреса.
у нас 6 клиентов с одинаковыми маками, к двум из них сходили обнаружили что у них такая проблемма у обоих карточки сис.
Так что если на сервак поставить оную может сложиться нечто.
В общем это просто фантастика - скорее всего все карты совершенно левые, но они обе эти карточки оказались встроенные в материнку.
Очень интересный тред. А у меня тут родилась идейка. Правда не знаю, насколько работоспособная (я не очень хорошо разбираюсь в данном вопросе), однако рискну представить ее на ваш суд: надо периодически имитировать подключение сервера к сети, чтобы правильные IP-МАС уходил в сеть. Мне кажется, что даже если кто-то изменит свой IP на мой, но с левым МАС, то очередная посылка с моего компа должна вернуть все на место.
Раз пошла такая пьянка вставлю и я пару слов. Чего-то никто не сказал про arpwatch.From: arpwatch@domain.com (Arpwatch)
To: root@domain.com
Subject: changed ethernet address
Status:hostname: <unknown>
ip address: 192.168.1.48
ethernet address: 0:d0:b7:b:d7:7c
ethernet vendor: <unknown>
old ethernet address: 0:80:5f:ac:c9:1c
old ethernet vendor: Compaq Computer Corporation
timestamp: Saturday, November 27, 2004 11:15:11 +0200
previous timestamp: Saturday, November 27, 2004 11:10:58 +0200
delta: 4 minutes