Что-то мне подсказывает, что сеть там на неуправляемых коммутаторах. И, возможно, эта атака - попытка переполнить очередь пакетов коммутаторов и перевести их в режим повторителя

SOLDIER

Честно говоря, по приведённым логам консоли о состоянии винтов ничё не понял. Ибо не сисадмин )) Можно прояснить ситцацию?Что было, что стало и какой вывод о дисках да и вообще на будущее можно из всего этого сделать?

Сервак беру для выхода в нет через него. Будет как шлюз работать. А виртуалки там для всяких тестов отделу нужны. В т.ч. и Win7 и Mac OS X.

В итоге остановился на MBD-X8DAi. Ну а видяха может потредоваться для всяких там CUDA - тоже поэксперементируем )

Думаю, для моих задач это не потребуется

RU_LIDS
Насчёт KVM. Пытались юзать его. Сначала сконвертить vmware-вскую виртуалку готовую. Но процесс конвертации завис. Посему с KVM общаться перестали

Планируется создание сервака, на котором будет крутиться в одно и то же время около 8-10 виртуальных машин с разными ОС. На самом сервере планируется поставить Ubuntu server

Железо вот такое:

Kingston KVR1333D3D8R9S/4G 4096Mb 4 шт //память
APC Power Saving Back-UPS Pro 1500 1 шт //бесперебойник
CPU Intel Xeon E5620 2400/5.8GT/12M S1366 (oem) SLBV4   2 шт //
проц
Supermicro Server MBD-X8DTL-IF-O                     1 шт ///// мат.плата
Supermicro Server CSE-743TQ-865B 1 шт // корпус
hdd Hitachi HUS156060VLS600 1 шт //диск для системы (и виртуалок)
Western Digital Caviar Green 2Tb 1 шт //диск для данных
Supermicro Server SNK-P0040AP4 2 шт ///// вентилятор 2U
Supermicro Server CSE-PT26L-B 1 шт // монтажный комплект
DVD-/+R/RW EXT USB SLIM RTL BLACK DRX-S77U/B OPTIARC 1 шт


Обратил внимание, что в материнку внешнюю видяху не всунуть. Но у неё есть встроенная. В связи с этим вопрос: смогу ли я гонять 8-10 виртуалок с такой матерью? Или видеопамяти будет нехватать уже для 3-4 виртуалок?

На самом деле, быстрый поиск в гугле сразу не помогает. Посему здесь поинтересовался дабы много времени не утекало на это

Я правильно понял, что можно настроить нечто подобное установив VNC-сервер и настроив его для привязки каждой сессии к своему виртуальному рабочему столу? Это получается альтернатива терминальному серверу? Или часть работ в дополнение оному?

Хочу настроить аналог Windows Server терминального сервера, но под Ubuntu. Чтобы через удалённый рабочий стол по 1 учётке могли подключаться много юзеров одновременно. Как это сделать? Где почитать?

Пока надумали вот что:

1. кол-во компьютеров для доступа в сеть уменьшить
2. эти компы используются только для доступа в инет, для работы с документами - отвязанные от сети компьютеры
3. Возможно присоединение компьютеров (которые в инет выходят) к доменам

Именно в этом и проблема. Использование же виртуального рабочего стола сведёт на НЕТ такие вещи. А следить за безопасностью и обновлением ПО на 1 (или нескольких) серверах намного проще, чем за более 200 пользователями. Так что я пока что целюсь именно на это решение.

Задолбаюсь ходить и устанавливать обновление на такое кол-во компьютеров. Это не вариант. Тем более, если кто решит переставить систему - я даже не узнаю об этом.

Мало эффективно. У нас стоит такой корпоративный Касперский. У него даже проактивки нет никакой - не предупреждает о загрузке драйвера.

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

Посмотреть наличие пакетов с бродкастом, а также поддельных arp-пакетов

Каким образом можно организовать эффективную защиту локальной сети фирмы от атак из интернета? Слышал, что можно сделать выход в интернет всех сотрудников через удалённый рабочий стол сервера, который будет иметь доступ в интернет. А компьютеры самой локальной сети выходить в инет не могут. Где можно почитать об этом подробнеее? Или, может, есть более эффективное решение?

Общая картина такова: около 200 компов выходит в интернет через прокси-сервер. В сети установлен также DHCP-сервер

Есть файл .xls Он создан и запаролен стандартыми срествами  MS Excel 97/XP. С помощью программы Advanced Office Password Breaker удалось его расшифровать. При этом я теперь имею:
1. Исходный зашифрованный файл
2. Расшифрованный файл
3. Ключ шифрования, который был определён ПО Advanced Office Password Breaker

Каким образом я могу получить пароль, которым был зашифрован файл средствами MS Excel 97/XP?

Мы сейчас обсуждаем не инженерные методы решения проблемы, а совсем другой вопрос

Именно так. Это и будет при атаке "человек посередине", когда все компьютеры вынуждены будут общаться через 1 единственный атакующий компьютер

Я был не прав? оказывается, это не коммутатор не справляется, а компьютер-получатель. Это хорошо заметно по возрастающему значению overruns в ifconfig получателя

jungle_vnd,
Вы до сих пор не понимаете отличия инженерной задачи от научной, как я вижу. Это очень печально. Получается, что я вместо того, чтобы найти помощь сам трачу время на обучение других.

В двух словах. Инженерная задача будет: подключить несколько компов к коммутатору, настроить "нормальное общение" - передачу инфы в сети, провести arp-спуфинг, убедиться что при большом трафике сеть загнётся. С точки зрения научной этот результат - полный ноль.

Научная задача: найти математическую модель, более или менее точно описывающую процессы, происходящие в инженерной задаче. В нашем примере может подойти теория массового обслуживания и формулы характеризующие вероятностно-временные характеристики модели. Проанализировать модель и процессы в ней, сравнить с практикой, обосновать соответствие/несоотвтествие полученных результатов. Посчитать дисперсию, выявить доверительный интервал. Посчитать о общем виде пределы некоторых переменных в формулах. Например, выявить минимальную пропускную способность n-ого количества компьютеров, необходимых для наступления "тормознутости в сети" (а по научному: достижения в очереди не меннее k-ого кол-ва пакетов при которых происходит потеря). Все эти результаты можно будет потом использовать для обобщения формул или как основание для создания более точных мат. моделей сети.

Гляньте ссылки что я тут кидал. Сразу будет понятно, как разительно отличается инженерная задача от научной


Вот это и плохо, что люди совершенно не чувствуют границ применения своих же знаний

jungle_vnd,
Спасибо за интерес к проблеме, но, увы, ваши посты нас никуда не продвинули

Будьте столь любезны: почитайте ВНИМАТЕЛЬНО  название темы и первый пост. Вопрос поставлен корректно. А то, как я вижу, ещё не разобрались что к чему, а уже носом тыкать других принялись. Некрасиво как-то, со стороны взрослого воспитанного человека... Али я погорячился и человек не воспитанный? Или не взрослый?

Пишу магистерский диплом, который теперь уже называется магистерской диссертацией. Направление: телекоммуникации. Диплом звучит так: "Оценка влияния сетевых атак на производительность ЛВС Ethernet". По поводу брошенного - отчасти правы: руководитель формальный, практически всё приходится делать самому
А уточнять ничего не нужно, я выше писал, что сформулировал вопрос корректно

Вот уж спасибо. У вас у самого какое образование? И из какой научной сферы? Максимум чему бы эти ссылки помогли - это инженерному проектированию, а никак не научной работе. Хорошо хоть в этих ссылках нет детских картинок, объясняющих дошкольникам как пакеты из одного компьютера через извилистые дороги проводов пробираются сквозь все невзгоды на другой комп.

К слову, я о своём образовании сказал. Надеюсь, после этого у вас поубавится желания общаться со мной как с маленьким

Судя по всему - да. Но, как выяснилось, потеря пакетов идёт не в коммутаторе, а в принимающем компьютере: в ifconfig параметр overruns: становится больше 0

Евгений Палитов,
Спасибо, как раз то, что нужно

В винде - да. А в Линухе я создал скрипт который выгружает и заново загружает драйвер. 2 клика и всё сделано

Провёл небольшой эксперимент и получил интересный результат...

к коммутатору подключены 2 компа. Один посылает пакеты другому в цикле, без пауз. Другой только принимает, но не обрабатывает. Если Payload < 65 байт - наблюдаем потери пакетов. Судя по всему, коммутатор не успевает их обрабатывать. В случае когда Payload > 65 байт - потерь не возникает. Во всяком случае, такой результат достигнут при генерации от 1 000 000 до 10 000 000 пакетов

Необходимо в линуксе очистить статистику сетевого интерфейса, которую видно через ifconfig.

Пробовал вот так:
/etc/init.d/networking restart eth0
не покатило. Статистика видна в файле /proc/net/dev Попытка его затирания даже через sudo оборачивается отказом доступа