Прослушивание портов
- Автор темы KolDun123
- Дата начала
Ос: Fedora помойму 4,0
1-ый комп (прослушиваемый)
2-ой комп (тот что прослушивает)
Оба в локальной сети в одном допустим помещение где ещё таких 20 и более
1-ый доступ в инет имеет (кабель)
2-ой доступа не имеет в инет, IP отсутствует, стоит блок на АРП атаки.
Прослушивает допустим всё.
Оборудование незнаю.
1-ый комп (прослушиваемый)
2-ой комп (тот что прослушивает)
Оба в локальной сети в одном допустим помещение где ещё таких 20 и более
1-ый доступ в инет имеет (кабель)
2-ой доступа не имеет в инет, IP отсутствует, стоит блок на АРП атаки.
Прослушивает допустим всё.
Оборудование незнаю.
В данной ситуации некого вычислять - все компы в локалке видят все пакеты с других компов и "прослушивают" все открытые порты друг друга в пределах общего домена конфликтов, общая шина передачи данных - это основа работы стека TCP\IP.
Отдельный разговор как от этого защититься
Да и ещё... Что значит IP отсутсвует?
Отдельный разговор как от этого защититься
Да и ещё... Что значит IP отсутсвует?
Последнее редактирование модератором:
Вот препод сказал нету ИП я так понял что ifconfig несконфигурирован.
Задание таково определить тот комп, какие порты прослушивает и защититься от него.
Ну раз вопрос заходит тупик, может у компа который прослушивает все порты закрыты?
А разве все всегда прослушивают? Дапустим он один прослушивает, и пакеты он не пасылает он толька слушает.
Задание таково определить тот комп, какие порты прослушивает и защититься от него.
Ну раз вопрос заходит тупик, может у компа который прослушивает все порты закрыты?
А разве все всегда прослушивают? Дапустим он один прослушивает, и пакеты он не пасылает он толька слушает.
Привет!
1. Может быть дубликат мак-адреса. Тогда весь трафик твоей машины будет приниматься и машиной-шпионом. С такой ситуацией лучше определиться на управлямом коммутаторе сети. Коммутатору должно быть очень плохо.
2. ifconfig - день вчерашний. Сейчас все пользуют утилиту ip
3. Поставь блокирование всего ip трафика на машине 1 с записю в лог, посмотри чего пишут в него.
4. А еще можно утилитой tcpdump писать весь трафик в файл. При этом у тебя прослушиваемый интерфейс будет в promiscious моде. Смотреть утилитой ifconfig.
Veda
Нужно подчеркнуть, что утверждение, что все компы видят ip-трафик других... справедливо только в всучае использования НЕ коммутатора в сети.
1. Может быть дубликат мак-адреса. Тогда весь трафик твоей машины будет приниматься и машиной-шпионом. С такой ситуацией лучше определиться на управлямом коммутаторе сети. Коммутатору должно быть очень плохо.
2. ifconfig - день вчерашний. Сейчас все пользуют утилиту ip
3. Поставь блокирование всего ip трафика на машине 1 с записю в лог, посмотри чего пишут в него.
4. А еще можно утилитой tcpdump писать весь трафик в файл. При этом у тебя прослушиваемый интерфейс будет в promiscious моде. Смотреть утилитой ifconfig.
Veda
Нужно подчеркнуть, что утверждение, что все компы видят ip-трафик других... справедливо только в всучае использования НЕ коммутатора в сети.
enyuri внимательно читайте моё сообщение:
все компы в локалке видят все пакеты с других компов и "прослушивают" все открытые порты друг друга в пределах общего домена конфликтов, общая шина передачи данных - это основа работы стека TCP\IP
Для справки: разделение на домены конфликтов обеспечивает только интелектуальное, активное коммутационное оборудование, тобишь всё начиная со второго поколения коммутаторов. Более того существует класс трафика - multicast, при рассылки на адреса зарезервированные за этим классом любое оборудование кроме роутера обязано разослать трафик не только в пределах данного домена конфликтов, но и в пределах всех доступных ему доменов, но это я уже немного в сторону отошёл от разговора!
И ещё... Ваше формулировка не точна:
KolDun123
нету IP и он не сконфигурирован - это разные вещи, впредь объясняйтесь пожалуйста точнее! Это же относиться к формулировке проблемы!
Теперь ещё уточняющий вопрос - какими средствами защититься и определить? Тобишь любыми или список ограничен только встроенными средствами оси?
все компы в локалке видят все пакеты с других компов и "прослушивают" все открытые порты друг друга в пределах общего домена конфликтов, общая шина передачи данных - это основа работы стека TCP\IP
Для справки: разделение на домены конфликтов обеспечивает только интелектуальное, активное коммутационное оборудование, тобишь всё начиная со второго поколения коммутаторов. Более того существует класс трафика - multicast, при рассылки на адреса зарезервированные за этим классом любое оборудование кроме роутера обязано разослать трафик не только в пределах данного домена конфликтов, но и в пределах всех доступных ему доменов, но это я уже немного в сторону отошёл от разговора!
И ещё... Ваше формулировка не точна:
под понятие НЕ коммутатора попадают и хабы\мосты (которые Вы, видимо, имели ввиду) и роутеры, которые по факту настроек по умолчанию действительно делят домент конфликтов (и не только), однако так же спокойно могут и объединять несколько доменов конфликтов (и не только)!
KolDun123
нету IP и он не сконфигурирован - это разные вещи, впредь объясняйтесь пожалуйста точнее! Это же относиться к формулировке проблемы!
Теперь ещё уточняющий вопрос - какими средствами защититься и определить? Тобишь любыми или список ограничен только встроенными средствами оси?
Последнее редактирование модератором:
Veda
Я так и не пойму, при чем тут multicast. В нашем применении он такой-же, как и unicast.
Под понятие НЕ коммутатор попадают устройства, которые не знают про mac-адреса или не смотрят на них. Раньше это были концентраторы. День вчерашний. Сейчас даже самое тупое устройство уже считает себя коммутатором, и отправляет пакеты только на нужные порты. Именно поэтому для перехвата трафика стали писать программы, которы отправляют ARP-запросы, в которых пишут свой mac на чужой IP.
Более умные коммутаторы умеют слать чужой трафик на указанный порт, так называемая функция port monitor. Если она включена, то на этот прот будет попадать трафик с указанных портов.
И еще. Перехваченный трафик легко прослушать, но тяжело в него вмешаться. В установленную сессию TCP очень трудно подсунуть свои пакеты.
Я так и не пойму, при чем тут multicast. В нашем применении он такой-же, как и unicast.
Под понятие НЕ коммутатор попадают устройства, которые не знают про mac-адреса или не смотрят на них. Раньше это были концентраторы. День вчерашний. Сейчас даже самое тупое устройство уже считает себя коммутатором, и отправляет пакеты только на нужные порты. Именно поэтому для перехвата трафика стали писать программы, которы отправляют ARP-запросы, в которых пишут свой mac на чужой IP.
Более умные коммутаторы умеют слать чужой трафик на указанный порт, так называемая функция port monitor. Если она включена, то на этот прот будет попадать трафик с указанных портов.
И еще. Перехваченный трафик легко прослушать, но тяжело в него вмешаться. В установленную сессию TCP очень трудно подсунуть свои пакеты.
IP нету.
Защита от АРП атак, так что как я понимаю про МАК можна забыть.
Я проверю на наличия конфликта завтра, но это маловероятно т.к. задания по словам не такое и лёгкое.
Свитч или Роутер тоже узнаю завтра.
Средства для определения подслушивающего устройства любые.
Защита от АРП атак, так что как я понимаю про МАК можна забыть.
Я проверю на наличия конфликта завтра, но это маловероятно т.к. задания по словам не такое и лёгкое.
Свитч или Роутер тоже узнаю завтра.
Средства для определения подслушивающего устройства любые.
KolDun123, посмотри вот Как увидеть ссылки? | How to see hidden links? статью...
Нелохая статейка, жаль только не упоминается множество тонких моментов связанных с активным сетевым оборудованием в данном вопросе, ну да видимо это уже другая статейка будет, а то и не одна
А почитав её повнимательней (чего я не сделал к сожалению с самого начала) можно понять что автор либо непонимает, либо специально не делает разницы между прослушкой трафика (что является нормой например для винды) и перехватом (с последующим анализом пакетов) - статья то называется "Обнаружение пакетных снифферов"...
Ну да как говориться критиковать каждый может, а вот написать самому... В любом случае любопытно почитать
А почитав её повнимательней (чего я не сделал к сожалению с самого начала) можно понять что автор либо непонимает, либо специально не делает разницы между прослушкой трафика (что является нормой например для винды) и перехватом (с последующим анализом пакетов) - статья то называется "Обнаружение пакетных снифферов"...
Ну да как говориться критиковать каждый может, а вот написать самому... В любом случае любопытно почитать
Последнее редактирование модератором: