Собственно, весь вопрос в подмене адресов. Как я понимаю, если у меня нет возможности знать заранее, что такой-то адрес связан с таким-то маком, то подмену обнаружить е удастся никак? Хотя и разговор про маки полутолков.
Последние комментарии
-
OlegL, 17 декабря 2023 года в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
Посмотри arpwatch. Это программка, которая ведёт свою ARP таблицу и отслеживает любое изменение MAC или IP адреса в соответствии с этой таблицей. Информация об этих изменениях шлётся на e-mail админу и записывается в логи.
в принципе, тут тебе может помочь arpwatch, который будет следить не столько за изменениями MAC-адресов, сколько за ними самими.
а уж изменения тут мониторить тебе придётся самостоятельно. (точнее тебе надо настроить на это дело arpwatch, по умолчанию он этого не делает)
Спасибо. Но насколько я понимаю, это помогло бы сисадмину какой-нибудь локальной сети. Меня же все-таки больше интересует кул хацкер, котрому зачем-то понадобился мой комп. Хочется видеть в журнале не какой-то ip, а настоящий. Не попросишь ведь arpwatch (да какую бы то ни было программу) следить за всем интернетом.
ну, когда расскажешь, как ты получишь MAC удалённого хоста по инету (а не ближайшего к тебе рутера), тогда можно будет и дальше говорить о записи MAC-адреса хацкера.
ну и вопрос на раздумье: какой MAC у пользователя dial-up? :D
Вообще-то, arpwatch может следить только в пределах твоего ethernet-сегмента (а дальше тебе, кстати, и не надо. Какая-то там подмена МАК адреса вне твоего физического сегмента сети тебе как-то побоку). Почему так — тебе на домашнее задание.
Не, ну я ведь и говорил, что у всего инета маки не просветишь. можно ли узнать мак у компа несколько удаленного — даже не задумывался. Все равно за всей сетью следить ни один комп не потянет.
Что до домашнего задания, то я что-то не пойму. если у меня внешний адрес, то меня эта проблема вполне может затронуть!
Только вот я сомневаюсь, что ты понимаешь и представляешь себе почему так…
Это ясно. Если б задумался и попытался разобраться, то таких вопросов просто не задавал бы. Может уже пора разобраться?
Подмена MAC адреса?! Да ну, брось ты..;)
Не, всё-таки выполни домашнее задание — почитай про ethernet и MAC что-нибудь. И я это говорю не с целью как-то унизить тебя или выпендриться. Просто в конечном итоге тебе же будет понятней и полезней.
Щас гвупость скажу.
Единственной целью спуфания IP является организация DOS-атаки (просветите меня, если это не так). Соответственно, изнутри подсетки это делать достаточно бессмысленно. А вот забрасывать удаленную вражескую машину пакетами, которые якобы приходят с других адресов (желательно, притом, разных, дабы админ аккуратненько отрезАл себя от совершенно неповинных адресов и грязно ругался) — самое то. Ко всему прочему, такую атаку лучше осуществлять с большого количества зомбированных писюков, поскольку поток пакетов с одной машины, каким бы интенсивным он не был, хороший сервер не посадит.
В связи с вышеизложенным, ответ на исходный вопрос — положительный. Против IP спуфинга бороться невозможно.
Кстати о причках. Если что-то в моем ответе неверно, скажите. Я действительно хочу знать, прав ли я.
Good Luck,
UT
Я же почему-то считал, что основной целью IP spoofing’а является компрометация настоящего хозяина проспуфленного IP адреса (грубо говоря, выдать себя за чужака с целью завладеть данными/ресурсами этого чужака). Пример до безобразия простой и тривиальный: доступ в интернет в локальной сети осуществляется по IP-адресу. Думаю, тебе не надо объяснять, что может сделать подмена злоумышленником этого самого IP-адреса ;)
Как раз, IP spoofing, как таковой, внутри сети очень даже имеет место быть. Пример см. чуть выше.
Ну такое тоже может быть. Однако чаще делается это с помощью подконтрольных тебе машин-зомби, о чём ты и сам сказал чуть ниже ;). Адреса этих зомби не обязательно-то (да и не зачем) подменять (т.е. спуфить) ;)
Это к IP spoofing’у относится весьма косвенно. Он тут даже и не нужен толком.
Это ты уже плавно перешёл от IP spoofing’а к DDoS атакам ;). Повторюсь, подмена адресов к DDoS атаке имеет весьма посредственное отношение.
Падажжи, падажжи… :-) Что имеется в виду, однако? Классический спуффинг, в моем воспаленном мозгу выглядел так:
Я сижу на машине с адресом 111.111.111.111 и посылаю пакет, в котором source address проставлен как 222.222.222.222. Машина, которая получает этот пакет, пребывает в полной уверенности, что пакет пришел с 222.222.222.222. Следовательно, если она отправит что-то обратно, то ответ уйдет на 222.222.222.222, и я его никогда в глаза не увижу! Какие ресурсы я могу получить таким образом, все выглядит как дорога в один конец…
Good Luck,
UT
Ну увидеть-то можно. введя сетевуху в смешанный что-ли режим. Ну когда она без разбору все пакеты читает. Все, что идет к 222.222.222.222 тут и прочитаем.
Ну а подключаться к провайдеру с подменнным адресом — дубово. здравые люди проверят хотя бы еще мак.
FLY: когда я говорил, что не просветишь маки у всего инета имел в виду то, что уж больно большой поток информации. вовсе не техническую возможность взять мне сейчас, да определить твой мак.
Как я понимаю, вся проблема увидеть мне твой мак лишь в том, что между нами есть роутеры. Если нет (а чисто теоретически это возможно), то узнать могу. правда, ведь!
Про внешний адрес я имел в виду не подмену мака, а подмену адреса. просто тут-то меня мой провайдер не спасет. пакеты ко мне пойдут не от него, а от всех на свете!
Ну, если он тебе не нужен, то не увидишь ;)
Man-in-the-middle
А вообще, тут очень даже хорошо описаны основы IP Spoofing’а.
Интересно, «какой MAC у пользователя dial-up?» (с) Genie прям в этом же треде ;))
Да нету никакого «потока информации». Дальше отдельного физического сегмента сети MAC адреса никуда не выходят!
Можно и так сказать.
Нет, не можешь.
Извини, но этого я что-то не понял вообще =(.
Да, вижу, спасибо.
То есть, как справедливо отмечает propeller, можно загнать свою карту в promiscuous моду и получать все пакеты своей подсетки, или, если все пакеты законной сессии идут через тебя, в эту сессию можно вклиниться. Наконец, если правильно посчитать (что, по утверждению авторов статьи, нынче невозможно) последовательность пакетов, просто вслепую вписать какие-нибудь данные на вражескую машину. Интересно. Первые два способа явно придуманы для локальной сети. Буду знать.
Good Luck,
UT
только к этому есть два но :
1) чтобы ловились все пакеты, необходимо, чтобы в качестве сетевого оборудования были не switch, а hub.
2) при работе в switch-ёванной сети овиться будут только броадкасты, что не сильно будет отличаться от обычного режима…
конечно, можно воспользоваться во втором случае переполнением таблицы arp в switch, но это тоже тонкости.
нууу… в принципе, узнать MAC удалённого компа возможность есть.
временами.
справедливо только для компа с Windows, до которого есть нормальный незарубленный канал к 137-139, 445 портам. (покажите мне такого, кто при знании о дырявости Win выставит открытыми эти порты?).
второй случай этого — установленный и открытый наружу и для публичного пользования snmp. (только каким надо быть идиотом, чтобы не закрыть такое — я не знаю).
да, не увидишь. только «виновато» в этом отнюдь не нераспространение MAC по инету, а?
дополнительно, если провайдер у тебя неглупый, то простое правило на магистральной Cisco быстро отучит тебя пользоваться такой возможностью вне подконтрольной тебе локалки.
кроме того, есть такая возможность — разные маршруты при прохождении пакетов по разным каналам. распространённый случай — настройка dvb и спутникового канала — «туда» пакеты идут одним путём, «по земле», в то время как «обратно» — через спутник.
поэтому «неловимость» обратных пакетов ещё ни о чём не говорит ;)
кстати. а вот интересно, если на выходном шлюзе локалки или на маршрутизаторе за ним поставить SNAT и динамическое обновление маршрутизации (как раз для отдельных, левых, адресов с подконтрольных интерфейсов) — то… ;) пакеты к тебе почти вернутся.
А как же arp poisoning?
Ну, Серёг, это всё равно, что просто прямо спросить: «мужик, а какой у тебя MAC?». К технической реализации вычисления удалённого MAC’а это будет иметь такое же отношение, как и попытка пробиться на NetBIOS’овские порты удалённой машины ;).
Смущает «почти» ;). А на самом деле, просто не понял схемы =(.
По-моему, он имеет в виду такую схему: я, злобный хацкер, отправляю пакеты как будто бы с whitehouse.gov, а шлюз переписывает source address на себя, и недоуменные ответы приходят к шлюзу, на расстояние протянутой руки от меня, шо мене очень греет… :-)
А еще мне понравилось про тарелковый интернет, где пакеты по разным путям ходють. Так вот и вижу идеальный хак: посылаю это я вражине пакет как будто от fbi.org, говорю: «Я имею полное право затребовать у тебя рутовый пароль! Только ты его пошли по вот такому вот IP, там мужик сидит хороший, и он тут совершенно не при чем!» :-)
Шутю я, шутю. Может, в будущем году буду network security преподавать, пора разбираться начинать, или где?
Good Luck,
UT
угу. типа того.
кстати, если это дак действует роутер провайдера, то в недоумении будет уже шлюз клиента ;) или сам клиент (правда, может быть <font size=«-2»>если руки клиента настолько корявые, то</font> произойдёт закольцовка маршрута — это уже другая проблема.. <font size=«-2»>TTL тут поможет, если что</font>)
К сожалению, хака не получится. :)
технология этого типа подключения не особенно-то и позволит :(
тебе какой именно — для switch-а или для компа-жертвы? ;)
вообще же в локалке много проще издеваться над соседом, особенно если у него стоит Win. комп в vmware+выставление у этого компа соседского MAC — и тут только контроль по паре MAC/IP на порту свитча и может спасти ситуацию.
при использовании такого свитча и его грамотной настройке и arp-poison не сработает. не говоря уже про spoofing.
FLY — забей уже на этот диалап. потому и не отвечаю на вопрос.
Короче, в качестве поитога — ответ нет. Так я понял. не увидеть мне подмену адреса.
Кстати, а что есть arp-poisoning? я что-то много искал всяких кул хацреских метод и такого не видал. а врага надо знать в лицо.
А расскажите-ка еще пожалуйста (ну или дайте ссылку) просто 445 и 137-139 порты. на самом деле я долго пытался понять, когда увидел у друга, что есть 445 порт. Я его и на FreeBsd видал…
137/udp, 138/udp, 139/tcp, 445/tcp — это порты протокола NetBIOS (протокол «общения» компьютеров в сети. В основном, Windows-сети). Приложения могут через netbios найти нужные им ресурсы, установить связь и послать или получить информацию. NetBIOS использует для службы имен порт — 137, для службы дейтограмм — порт 138, а для сессий — порты 139, 445. Подробнее об этом протоколе смотри в гугле — он тебе лучше расскажет.
В unix-подобных системах для «общения» по протоколу NetBIOS есть samba. Видимо, именно этот сервис запущен у твоего друга во FreeBSD.
Да вот и я так думал, да самба даже не была установлена!
Тогда попробуй зателнетиться на этот порт, может быть тебе сам сервис расскажет, кто он. Хотя, чем гадать, проще спросить этого друга, что он запустил прослушивать этот порт.
Да у друга master 9.0 после установки сразу дал эту ботву. причем совсем не выходило понять, что за сервис запускался (netstat -nup даже не отображал этот порт). телнет ничего не дал — пробовал. nmap давал просто microsoft-ds (то же написано в /etc/services).
Чего за «master 9.0"? Ты ж говорил, что у него FreeBSD.
А: netstat -atupn тебе ничего не рассказывает? Так же глянь: 'lsof -i’ — если такая команда есть во FreeBSD (или что там у твоего друга).
Да нет, фря и друг — разные вещи. у друга-то все-таки мастер. Так вот netsat просто не показал этого именно порта! не знаю, как такое бывает. Ну а про lsof что-то тогда и забыл.
Да, так и не сказалипро poisoning и чем плохи 137-139.
…Насколько я понял, автору поста просто надо связать ip-адрес с MAC-адресом. Содрал когда-то где-то на opennet-е, комментарии не мои.
# Очищаем ARP /usr/sbin/arp -d -a # Разрешаем работу только с хостов c списанными MAC адресами. /usr/sbin/arp -s 192.168.1.1 0:92:37:91:12:a3 pub # Запрещаем присвоение свободных IP. /usr/sbin/arp -s 192.168.1.2 0:0:0:0:0:0 pub ------- #!/bin/sh mynet="192.168.0."; n=1 while ( [ n -lt 255 ]; ); do arp -S $mynet$n 0:0:0:0:0:0 n=$(expr $n \+ 1); done arp -f /etc/ethers ------- Я сделал так (идею тоже нашел на этом сайте): 1. Создал файл б/д привязки IP к MAC (например /etc/ethers.local) Пример строк из файла: 192.168.0.11 00:0c:6e:3f:cd:e5 #kasa2 192.168.0.12 00:0d:88:82:da:a2 #mobil и т. д. 2. Написал скрипт такого содержания: (например /etc/static.arp): #!/bin/sh # обнуляем всю таблицу arp arp -ad > null # к каждому компу в локальной сети привязываем несуществующий (нулевой) # MAC адрес I=1 while [ $I -le 254 ] do arp -s 192.168.0.${I} 0:0:0:0:0:0 I=`expr $I + 1` done # к реально существующему компу в сети из базы данных в файле # /etc/ethers.local привязываем # правильный MAC адрес arp -f /etc/ethers.local 3. Делаем этот файл исполняемым и прописываем в файл /etc/rc.local такую строчку: /etc/static.arp Еще желательно, чтобы привязки имен юзерских хостов к ip-адресам были прописаны в /etc/hosts (это ускорит их поиск). Теперь сервер не будет рассылать широковещательные запросы о локальных MAC адресах, т. к. все они статически жестко привязаны к ip-адресам. Этим убивается два зайца: не рассылаются широковещательные запросы, что экономит траффик и время на ответ сервера, и не позволяет пользователю менять свой ip-адрес, т. к. сервер все равно пакет будет отправлять на жестко привязанный MAC адрес.