Назад | Перейти на главную страницу

Обнаружение вредоносного использования сети в локальной сети

Я управляю небольшой локальной сетью (30 компьютеров, смесь Linux, Windows и Mac). Раньше передача файла размером 100 МБ на локальный сервер (то есть в офис, а не в Интернет) занимала у меня около пары минут, но в последнее время на это уходит почти 30 минут. Я проверил свой локальный хост и сервер, и каждая машина в порядке, поэтому я предполагаю, что есть какие-то проблемы с сетью.

Как мне определить, что замедляет работу сети, и / или найти в сети компьютеры, использующие необычно высокую пропускную способность?

Какие хорошие инструменты мониторинга сети для Linux (в частности, Ubuntu) помогут мне в решении этой задачи? Большинство, которые я обнаружил, похоже, предназначено для мониторинга сетевого доступа локального хоста, а не доступа других машин в той же сети.

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

Это потому, что они были бы бесполезны в коммутируемой сети. Коммутатор разделяет трафик данных, поэтому в идеале хост получает только те данные, которые он предназначен для получения. Если вам нужна общесетевая статистика, вам нужно будет отслеживать статистические счетчики RMON ваших коммутаторов (доступно только при использовании управляемых коммутаторов).

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

Помимо проверки оборудования, рассмотрите возможность расследования того, что происходит в OSI Layer 8 -это пользователи.

Бывают случаи, когда сотрудники используют приложения для обмена файлами или потоковое видео / аудио на своих рабочих станциях - что-то, что может серьезно повлиять на производительность сети.

Рассматривали ли вы возможность тестирования вашей сети после «нормального» рабочего времени?

Чтобы решить различные сетевые проблемы, я настроил центральный маршрутизатор GNU / Linux, где использую такие инструменты, как iptraf для отслеживания текущего использования сети и получения подробной информации о трафике, исходящем от каждого хоста в сети и предназначенном для него.

tcpdump или Wireshark - отличные инструменты для устранения загадочных сетевых проблем и замедлений.

  • Используйте Wireshark или Tcpdump, чтобы увидеть, что происходит во время медленной передачи файлов. Проблема может быть вообще не связана с использованием сети (скорее всего, это уровень 7).
  • Изолируйте, а затем воспроизведите проблему:
    • Это всего лишь один клиент или все клиенты?
    • Это только один сервер или все серверы?
    • Это происходит постоянно или время от времени?
    • Можете ли вы использовать определенные шаги, чтобы воспроизвести проблему, или это происходит «случайно»?
  • Для сбора полезной информации вам нужна управляемая коммутационная инфраструктура. Чрезвычайно полезными будут либо RMON, либо SFlow, либо даже счетчики портов или статистика, доставляемые по протоколу SNMP.

По моему опыту, сеть часто обвиняют в «медлительности», когда коренная причина проблемы находится совсем в другом месте. Несколько примеров:

  • Приложение толстого клиента, работающее на рабочей станции с минимальным объемом памяти
  • Поставщик неправильно настроил маршрутизацию на своих устройствах
  • Поставщик настроил свои устройства так, чтобы они имели статические адреса в пределах нашего диапазона DHCP, рабочие станции, которым позже были назначены эти адреса, имели "проблемы"
  • Youtube работает медленно, поэтому сеть медленная. (Да, Youtube работает медленно ... потому что мы его ограничиваем).
  • Рабочая станция была неправильно настроена для индексации сетевых ресурсов пользователя
  • Обновление для Internet Explorer нарушило обратную совместимость со старым (примерно 2006 г.) веб-сервером, который использовался для управления на нескольких встроенных устройствах COTS. IE больше не выполнял «правильный» запрос GET, что приводило к сбросу каждого сеанса. Обновление прошивки улучшило ситуацию.

Еще один совет (обычно один из трех):

  1. Сначала проверьте физический уровень и уровень канала данных. В девяти случаях из десяти это патч-кабель, который кто-то многократно пробегал со своим офисным креслом (кстати, ошибки порта будут отображаться в статистике коммутатора, сообщаемой SNMP ... полезно посмотреть?). Или транспортная компания припарковала свой грузовик перед одним из наших беспроводных мостов. Ищите плохие согласования (используйте кабельный тестер), трассы кабелей, не соответствующие спецификации, несоответствия дуплексного режима или широковещательные петли, особенно если у вас нет физического контроля над всей коммутационной инфраструктурой.
  2. Уровень 7: ищите неправильные конфигурации или конфигурации клиента или сервера, которые больше не актуальны (Wireshark здесь ваш друг). Проблемы с DNS. Выполняется ли сетевое резервное копирование в течение дня? Или применяются обновления WSUS? И т.п.
  3. Уровень 8: И, наконец, всегда есть кто-то, кто смотрит видео через NetFlix (RMON или SFlow это обнаружат).

Как мне определить, что замедляет работу сети, и / или найти в сети компьютеры, использующие необычно высокую пропускную способность?

Начнем с проверки оборудования, а именно - реальной пропускной способности LAN, настроек NIC, качества кабелей и контактов, LA сервера при передаче файлов, скорости HDD и (возможных) ошибок. Даже "пара минут ..." для файлов размером 100+ Мбайт - очень медленная передача (для LAN 100Мб)

Я бы посоветовал вам использовать управляемые переключатели, как предлагал syneticon-dj, и настроить локальный сервер для мониторинга его жизненно важных функций и трафика, вы можете использовать cacti для построения графика его трафика, использования процессора / памяти и т. Д. Вы также можете настроить его для отправки предупреждений, когда пороговые значения пересекают некоторый уровень, который вы настраиваете в, nagios будет более полезен в таких задачах предупреждения.