Пакет осуществляет сниффинг для паролей в полностью коммутируемой сети действительно беспокойства?

И DeployStudio и NetRestore сделали, чтобы NetBoot отобразил, который создается для запуска фактического приложения DeployStudio или NetRestore для копирования изображения. В разделе NetBoot Администратора Сервера Вы хотите отключить изображение NetBoot, которому установили NetRestore на нем (и после того как Ваша миграция сделана, можно удалить его, так как он не будет необходим), и заставьте DeployStudio NetBoot отобразить значение по умолчанию.

При необходимости можно воссоздать изображение DeployStudio NetBoot путем выполнения помощника DeployStudio снова. Можно также использовать netbootch.sh от Парня Mac, который также продолжает работать, даже если NetBoot прекращает работать, пока Вы не можете перезапустить сервер.

27
задан 10 August 2009 в 21:28
9 ответов

Это - разумное беспокойство, поскольку существуют инструменты, которые выполняют arp, отравляющий (спуфинг), которые позволяют Вам, убеждают компьютеры, что Вы - шлюз. Примером и относительно простым в использовании инструментом был бы ettercap, который автоматизирует целый процесс. Это убедит их компьютер, что Вы - шлюз и осуществляете сниффинг трафика, это также передаст пакеты поэтому, если не будет IDS, выполняющий целый процесс, могло бы быть прозрачно и не обнаружен.

Так как эти инструменты доступны деточкам, это - довольно большая угроза. Даже если сами системы не настолько важны, люди пароли повторного использования и могли бы выставить пароли более важным вещам.

Коммутируемые сети только делают сниффинг более неудобным, не твердый или трудный.

42
ответ дан 28 November 2019 в 20:03
  • 1
    Я ответил на Ваш конкретный вопрос, но я рекомендую читать Ernie' s отвечают также о более широком подходе к размышлению о безопасности. –  Kyle Brandt 10 August 2009 в 19:40
  • 2
    s/posing/poisoning/ –  grawity 10 August 2009 в 21:03
  • 3
    сила тяжести: Я провожу почти столько времени, исправляя мое отвратительное написание с Firefox, проверяют правописание, сколько я делаю записи каждый post:-), –  Kyle Brandt 10 August 2009 в 21:35
  • 4
    +1 можно все заполнить switch' s таблицы Mac и превращают его в концентратор. Очевидно, более крупные переключатели имеют большие таблицы и поэтому тяжелее заполниться. –  David Pashley 10 August 2009 в 22:00
  • 5
    Заполнение switch' s таблицы Mac приводит к одноадресным пакетам, предназначенным для неизвестного (из-за нападения лавинной рассылки) широковещательно передаваемые адреса. VLAN все еще ограничивают широковещательный домен, таким образом, it' s больше как концентратор на VLAN. –  sh-beta 12 August 2009 в 00:49

Да, но это не только из-за Вашего использования Telnet и Ваших слабых паролей, это из-за Вашего отношения к безопасности.

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

И затем, также необходимо не упустить сотрудников. Удостоверьтесь общий не использование того же счета на любую заданную функцию. Это делает это болью для всех остальных, когда кто-то уволен, и необходимо изменить все пароли. Также необходимо удостовериться, что они не пали жертвой фишинговых атак через образование (скажите им, что, если бы Вы когда-нибудь просили у них их пароль, это было бы, потому что Вы только что стали уволенными, и у Вас больше нет доступа! У кого-либо еще есть еще меньше причины спросить.), а также сегментирующийся доступ на основе на учетную запись.

Так как это, кажется, новое понятие Вам, это - вероятно, хорошая идея для Вас забрать книгу по безопасности сети/систем. Глава 7 "Практики Системного администрирования и Администрирования сети" затрагивает эту тему немного, как делает "Существенную Системную администрацию", оба из которых я рекомендую читать так или иначе. Существуют также все книги, выделенные предмету.

21
ответ дан 28 November 2019 в 20:03
  • 1
    " Хорошая безопасность существует слоев " Очень хорошо сказал, что я думаю, мысль о редактировании моего сообщения, чтобы иметь что-то вроде этого, но это wouldn' t выразили так хорошо. –  Kyle Brandt 10 August 2009 в 19:33

Да это - большое беспокойство, поскольку с некоторым простым ARP, отравляющим Вас, может обычно осуществлять сниффинг LAN, не будучи физически в правильном порту коммутатора, так же, как в старые добрые дни концентратора - и очень легко сделать также.

12
ответ дан 28 November 2019 в 20:03
  • 1
    Кроме того, думайте о сколько сетевых портов, там находятся в небезопасном или сомнительно охраняют территории. Один из моих прошлых работодателей имел полдюжины в неконтролируемом, небезопасном лобби лифта. Даже если port' s безопасный, думайте о том, кто еще находится в здании - швейцарах, сервис techs, и т.д. - и помните, что социальная инженерия является одним из самых легких векторов для обхода физической безопасности. –  Karl Katzke 10 August 2009 в 18:20
  • 2
    " Привет регистратор! I' m здесь для наблюдения John, но I' m немного рано, я мог занять свободный конференц-зал для обработки некоторой электронной почты на моем ноутбуке?В самом деле?Отлично! " –  Oskar Duveborn 10 February 2010 в 16:11

Вы, более вероятно, будете взломаны с внутренней части, чем внешняя сторона.

Спуфинг ARP тривиален с различными предварительно созданными сценариями/инструментами, широко доступными в Интернете (ettercap, был упомянут в другом ответе), и требует только, чтобы Вы были на том же широковещательном домене. Если каждый из Ваших пользователей не находится на их собственном VLAN, Вы уязвимы для этого.

Учитывая то, как широко распространенный SSH нет действительно никакой причины использовать telnet. OpenSSH свободен и доступен для фактически каждого *отклонять-стиль ОС там. Это встроено на всех дистрибутивах, которые я когда-либо использовал, и администрирование достигло состояния под ключ.

4
ответ дан 28 November 2019 в 20:03
  • 1
    +1 Для упоминания VLAN и широковещательных доменов. –  Maxwell 10 August 2009 в 18:23
  • 2
    Вытаскивание немного из моей глубины сетевой безопасности здесь... Но I' m не верные VLAN защитят Вас любой как правило: cisco.com/en/US/products/hw/switches/ps708/… –  Kyle Brandt 10 August 2009 в 18:31
  • 3
    +1 для упоминания OpenSSH, когда никто еще не имел. –  Ernie 10 August 2009 в 19:00
  • 4
    Kyle - уязвимости там главным образом не важны. Нападение лавинной рассылки MAC все еще ограничивается широковещательным доменом, таким образом, никакое скачкообразное движение VLAN. То же с нападениями ARP. Нападение скачкообразного движения VLAN двойной инкапсуляции, которое все заключают в кавычки как, почему VLAN небезопасны, требует, чтобы взломщик был привязан к магистральному порту с собственным VLAN. Соединительные линии должны никогда , имеют собственный VLAN во-первых... –  sh-beta 10 August 2009 в 20:21

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

Может AD перемещение на данный момент и проводить Ваше время, настраивая ssh. Затем пересмотрите AD и используйте ldaps, когда Вы делаете.

1
ответ дан 28 November 2019 в 20:03

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

Тем не менее часто хорошо смочь найти arp отравителя, даже если просто, потому что они ухудшают производительность Вашей сети. Инструменты как Arpwatch могут помочь Вам с этим.

1
ответ дан 28 November 2019 в 20:03

Несомненно, у Вас есть коммутируемая сеть теперь... Но вещи изменение. И скоро кто-то захочет WiFi. Затем, что Вы собираетесь сделать?

И что происходит, если один из Ваших доверяемых сотрудников хочет шпионить на другом сотруднике? Или их босс?

1
ответ дан 28 November 2019 в 20:03

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

Например, возьмите поддерживающий telnet сервер оболочки Linux. Так или иначе это поставлено под угрозу, и у плохих людей есть корень. Тот сервер теперь 0wn3d, но если они захотят загрузиться к другим серверам в Вашей сети, то они должны будут сделать немного больше работы. Вместо глубокой трещины passwd файл, они включают tcpdump в течение пятнадцати минут и захватывают пароли для любого, инициировал сессию telnet в течение того времени. Из-за повторного использования пароля, это, вероятно, позволит взломщикам эмулировать законных пользователей в других системах. Или если сервер Linux использует внешний аутентификатор как LDAP, NIS ++, или WinBind/AD, даже глубоко взламывая passwd файл не получил бы их очень, таким образом, это - намного лучший способ получить пароли дешево.

Измените 'telnet' на 'ftp', и у Вас есть та же проблема. Даже в коммутируемых сетях, которые эффективно защищают от спуфинга/отравления ARP, вышеупомянутый сценарий все еще возможен с незашифрованными паролями.

0
ответ дан 28 November 2019 в 20:03

Даже вне темы Отравления ARP, Которое любой довольно хороший IDS может и обнаружит и надо надеяться предотвратит. (А также множество инструментов намеревалось предотвратить его). Корневой ролевой угон STP, Вторжение в маршрутизатор, спуфинг информации о Маршрутизации от источника, панорамирование VTP/ISL, список продолжается, В любом случае - существуют МНОГОЧИСЛЕННЫЕ методы к MITM сеть, физически не прерывая трафик.

0
ответ дан 28 November 2019 в 20:03

Теги

Похожие вопросы