Админская фамилия

Make Sysadmins Great Again

О жизни


11 инструментов безопасности, которые вы не можете пропустить

http://searchsecurity.techtarget.in/photostory/2240149817/11-security-audit-essentials/12/11-IT-security-audit-tools-you-cant-afford-to-skip


Google нельзя

В Кировской области уже запретили пользоваться сервисами Гугла в муниципальных и государственных учреждениях. Скоро это ждёт и все остальные субъекты РФ. Подтверждать или опровергать эту информацию не буду - не в моей компетенции. Хочу лишь обсудить и услышать мнение других.Итак, запрещено пользоваться сервисами иностранных компаний, в частности Google Inc. Сюда входят:Корпоративная почтаСайты и блоги на движке blogspotGoogle diskСобственно поисковая системаОбучающие программы и конкурсыКалендарьДругие сервисыИ, внимание. Google Chrome!Отчасти, я согласен с подобными запретами. Хранить корпоративную почту на сторонних серверах неправильно с точки зрения безопасности и доступности. То же и с гугл диском - кто знает, какие документы пользователи хранят на серверах “потенциального врага”. Но чем не угодил поисковик и браузер для меня остается загадкой. Хорошо, браузер мы можем поменять на Chromium, искать в “нашем” (на самом деле Нидерландском) Яндексе. Но кому от этого станет легче?И как быть бедным админам? Закрывать всю гуглевую AS? Но ведь там есть и другие сервисы - то же YouTube. А его видео почти во всех новостных лентах. Да и те, кому действительно нужен гуголь смогут обойти защиту (Tor, proxy и т.д.). Действовать тут придется только административными мерами.Браузер. Запретить установку и запуск средствами групповой политики. Но есть ведь сервисы, корректно работающие только под Хромом. Можно, конечно, попробовать тот же Хромиум, но бывают настолько корявые веб-кодеры, что он не поможет. Вывод: запрещать выход хрома в инет на шлюзах. Но версий хрома вагон и маленькая тележка. Писать в фаерволе правило под каждый User-Agent и постоянно мониторить появление новых версий. Не радужная перспектива.Хотелось бы услышать мнение читателей моего скромного блога в комментариях.


Защита Wi-Fi

ВОТНадо бы перевести


Выбор средств защиты персональных данных

Статейка старая (2008) , но годная.ОтсюдаПосле выхода в свет постановления Правительства РФ № 781 “Об утверждении Положения об обеспечении безопасности персональных данных при их обработке в информационных системах персональных данных” от 17 ноября 2007 г. и совместного приказа Федеральной службы по техническому и экспортному контролю, ФСБ РФ и Министерства информационных технологий и связи РФ от 13 февраля 2008 г. № 55/86/20 “Об утверждении порядка проведения классификации информационных систем персональных данных” (далее “Порядок…”) перед службами разработки и эксплуатации информационных систем (ИС), обрабатывающих персональные данные, возникло два почти гамлетовских вопроса: как классифицировать ИС, предназначенные для защиты персональных данных; как выбрать средства защиты информации для защиты персональных данных в этих системах. “Порядок…” утверждает, что “классификация информационных систем проводится государственными органами, муниципальными органами, юридическими и физическими лицами, организующими и (или) осуществляющими обработку персональных данных, а также определяющими цели и содержание обработки персональных данных”. Это означает, что персональные данные (ПД) классифицирует их владелец, что является серьезным подспорьем для объективного выбора методов и средств защиты ПД и создает объективную базу для диалога с проверяющими органами о достаточности принятых в организации мер защиты персональных данных. При проведении классификации ИС, предназначенной для обработки персональных данных, учитываются следующие исходные данные: · категория обрабатываемых в информационной системе персональных данных; · объём обрабатываемых ПД (количество субъектов, персональные данные которых обрабатываются в ИС); · заданные владельцем информационной системы характеристики безопасности персональных данных, обрабатываемых в ИС; · структура информационной системы; · наличие подключений ИС к сетям связи общего пользования и (или) сетям международного информационного обмена; · режим обработки ПД; · режим разграничения прав доступа пользователей информационной системы; · местонахождение технических средств ИС. В первую очередь определим, что относится к персональным данным. Это сведения различного характера о конкретных физических лицах. Заметим, что мы говорим только о сведениях в электронной форме, вводимых, хранящихся, обрабатываемых и передаваемых в информационной системе. Данные сведения разделяются на четыре основные категории: · категория 1 — ПД, касающиеся расовой, национальной принадлежности, политических взглядов, религиозных и философских убеждений, состояния здоровья, интимной жизни; · категория 2 — ПД, позволяющие идентифицировать субъекта персональных данных и получить о нём дополнительную информацию, за исключением персональных данных, относящихся к категории 1; · категория 3 — персональные данные, позволяющие идентифицировать субъекта персональных данных; · категория 4 — обезличенные и (или) общедоступные ПД. Например, отдельно фамилия является данными 4-й категории, сочетание фамилии и адреса — третьей, фамилия, адрес, номера страховок и карт — второй, а если к этим данным добавлена электронная медкарта, то получившиеся персональные данные относятся исключительно к первой категории. Исходя из этой классификации можно констатировать, что любые медицинские данные, а также кадровый учет, содержащий графу “национальность” (а таковы почти все действующие анкеты и личные листки по учету кадров, используемые в настоящее время), необходимо относить к первой категории. Понятно также, что фрагменты персональных данных почти всегда имеют меньшую категорию, чем их совокупность. Даже подробные сведения о здоровье физического лица могут быть бессмысленны, если неизвестна его фамилия или другие данные, однозначно привязывающие эти сведения к пациенту. Объем обрабатываемых ПД может принимать следующие значения: · — в ИС одновременно обрабатываются персональные данные более чем 100 000 субъектов или персональные данные субъектов в пределах региона Российской Федерации или Российской Федерации в целом; · — в ИС одновременно обрабатываются персональные данные от 1000 до 100 000 субъектов или персональные данные субъектов, работающих в отрасли экономики Российской Федерации, в органе государственной власти, проживающих в пределах муниципального образования; · — в ИС одновременно обрабатываются данные менее чем 1000 субъектов или персональные данные субъектов конкретной организации. По характеристикам безопасности ПД, обрабатываемых в информационной системе, ИС подразделяются на типовые и специальные. Первые — информационные системы, в которых требуется обеспечение только конфиденциальности персональных данных. Характеристика “конфиденциальность” означает, что обращаться (вводить, хранить, обрабатывать и передавать) с ПД в электронной форме может только тот, для кого они предназначены. Для обеспечения конфиденциальности при передаче персональных данных в сетях, включая Интернет, необходимо использовать шифрование данных. Специальные информационные системы — это такие ИС, в которых вне зависимости от необходимости обеспечения конфиденциальности ПД требуется обеспечить хотя бы одну из характеристик безопасности персональных данных, отличную от конфиденциальности (например, целостность или доступность). Характеристика “целостность” означает, что персональные данные должны меняться только регламентированным образом, например изменения в файл электронной медкарты может вносить только уполномоченный врач, а в любых других случаях информация в медкарте не должна меняться. При передаче по сетям целостность обеспечивается применением электронной цифровой подписи. Характеристика “доступность” означает, что работа с ПД должна обеспечиваться для заданного количества данных и пользователей с соблюдением установленных временных регламентов. Иначе говоря, “доступность” — другая формулировка надежности системы. Заметим также, что говорить о доступности в открытых сетях практически бессмысленно — ни один провайдер не обеспечит гарантированного доступа к данным или их бесперебойной передачи. К специальным информационным системам относятся: · ИС, в которых обрабатываются персональные данные, касающиеся состояния здоровья субъектов; · ИС, в которых предусмотрено принятие на основании исключительно автоматизированной обработки персональных данных решений, порождающих юридические последствия в отношении субъекта или иным образом затрагивающих его права и законные интересы. По структуре информационные системы для обработки ПД подразделяются: · на автономные (не подключенные к иным ИС), предназначенные для обработки персональных данных (автоматизированные рабочие места); · на комплексы автоматизированных рабочих мест, объединенных в единую ИС средствами связи без использования технологии удаленного доступа (локальные информационные системы); · на комплексы автоматизированных рабочих мест и (или) локальных ИС, объединенных в единую информационную систему средствами связи с использованием технологии удаленного доступа (распределённые информационные системы). По наличию подключений к сетям связи общего пользования и (или) международного информационного обмена ИС подразделяются на системы, имеющие подключения не имеющие подключений. Исходя из того, что в обязательном порядке требуется обеспечение конфиденциальности данных, можно выделить необходимые элементы информационной системы для обработки персональных данных. В первую очередь информационная система обязана идентифицировать пользователей и иметь возможность устанавливать индивидуальные полномочия по доступу пользователей к ПД, т. е. обладать системами идентификации и аутентификации и разграничения доступа. Во-вторых, необходимо обеспечивать защиту персональных данных, которые могут отчуждаться из системы. Например, следует контролировать перенос информации на съёмные носители. Весьма вероятно, что в ряде случаев надо учитывать возможность хищения и утраты (потери) компьютерной техники с персональными данными. В этом случае также обязательно шифрование хранимых на носителях компьютера ПД. Если система имеет подключения к открытым сетям или предусматривает обмен данными, обязательно применение шифрования данных и электронной цифровой подписи, а также обеспечение защиты от атак из внешних сетей, включая антивирусную защиту. Для шифрования и электронной подписи используются ключи и сертификаты, которые генерируются самими пользователями и регистрируются в так называемых удостоверяющих центрах. Весьма важный момент — регистрация действий с ПД, которая, с одной стороны, позволяет выявить виновных в их утечке, а с другой — создает психологическую мотивацию для корректной работы с ними. Информационной системе для обработки ПД может быть присвоен один из следующих классов: · класс 1 (К1) — ИС, для которых нарушение заданной характеристики безопасности персональных данных, обрабатываемых в них, может привести к значительным негативным последствиям для субъектов персональных данных; · класс 2 (К2) — ИС, для которых нарушение заданной характеристики безопасности ПД, обрабатываемых в них, может привести к негативным последствиям для субъектов персональных данных; · класс 3 (К3) — ИС, для которых нарушение заданной характеристики безопасности персональных данных, обрабатываемых в них, может привести к незначительным негативным последствиям для субъектов персональных данных; · класс 4 (К4) — ИС, для которых нарушение заданной характеристики безопасности персональных данных, обрабатываемых в них, не приводит к негативным последствиям для субъектов персональных данных. Таблица 1 КатегорияКласс ИС в зависимости от объема обрабатываемых ПД 3 2 1 Категория 4 К4 К4 К4 Категория 3 К3 К3 К2 Категория 2 К3 К2 К1 Категория 1 К1 К1 К1Во-первых, из “Порядка…” следует существование категорий персональных данных. Логично осуществить агрегирование базы данных в ИС, содержащей ПД, на непересекающиеся части, содержащие данные различных категорий. Также ИС для обработки ПД должна быть разделена на контуры, содержащие данные только одной категории. Это вполне возможно сделать, поскольку физические лица однозначно идентифицируются номером паспорта или ИНН либо номером полиса медицинского страхования, который позволяет индексировать базы медицинских данных и другие массивы однозначно. Таким образом, необходимо следовать принципу, что в каждом контуре ИС для обработки персональных данных необходимо использовать сертифицированные средства одного класса, а контуры должны быть изолированы друг от друга. Можно констатировать, что большинство информационных систем для обработки ПД (особенно медицинского назначения) будут специальными, т. е. в них необходимо обеспечивать не только конфиденциальность, но и целостность в обязательном порядкеи другие характеристики безопасности и надежности. В случае распределённой ИС для обработки персональных данных даже при необходимости обеспечения только конфиденциальности в соответствии с “Порядком…” в обязательном порядке потребуется защита передаваемых и хранимых ПД. Это полностью соответствует действующим требованиям ФСБ РФ к автоматизированным ИС, предназначенным для защиты конфиденциальной информации, не составляющей государственной тайны, а именно — положению, что “должна осуществляться защита всей конфиденциальной информации, передаваемой по каналам связи; информация, передаваемая по каналам связи, должна быть зашифрована с использованием средств криптографической защиты информации (СКЗИ), или для ее передачи должны использоваться защищенные каналы связи. Должна осуществляться защита информации, записываемой на отчуждаемые носители”. Последнее требование безусловно применимо для изолированных ИС ПД, не имеющих каналов для передачи ПД, т. е. для отдельных рабочих мест, обрабатывающих персональные данные. Это означает, что для обработки персональных данных ИС должны быть аттестованы по классу не ниже АК2 в классификации ФСБ РФ. Например, такому классу соответствует защищенная Windows XP c пакетом обновления Secure Pack Rus. В состав средств защиты должны входить средства криптографической защиты информации (СКЗИ) класса не ниже КС2. Исходя из этого для любой ИС ПД, обрабатывающей ПД категорий выше 4-й (к которой безусловно будут отнесены все системы обработки медицинских ПД), потребуется выполнение всех требований класса АК2 в классификации ФСБ РФ. Из архитектуры ИС ПД при достаточно большом количестве обрабатываемых ПД (показатель 1 или 2) однозначно будет выделяться серверный компонент, который также потребует защиты. В этом случае должна осуществляться защита всей конфиденциальной информации хранимой на магнитных носителях рабочих станций и серверов, что соответствует требованиям класса АК3. Таким образом, можно предложить вполне обоснованную стратегию защиты ПД, состоящую в том, что табл. 1 заполняется в следующей редакции (см. табл. 2). Таблица 2 Категория ИСКласс ИС в зависимости от объема обрабатываемых ПД 3 2 1 Категория 4 - - - Категория 3 АК2 АК2 АК3 Категория 2 АК3 АК3 АК3 Категория 1 Не ниже АК3 Не ниже АК3 Не ниже АК3 Примечание. “-” — означает, что требования не предъявляются. Таким образом, для защиты ПД первой категории, к которой относятся все медицинские данные, необходимо использовать средства защиты классов не ниже АК3 и средств криптографической защиты классов не ниже КС3. Для практического оснащения ИС средствами защиты можно рекомендовать продукты, специально адаптированные для защиты персональных данных и имеющие необходимые разрешительные документы (сертификаты и заключения). Это в первую очередь Secure Pack Rus и средства криптографической защиты семейства CryptoPro. Попробуем теперь оценить затраты на оснащение одного рабочего места для обработки ПД. Без учета скидок цена пакета Secure Pack Rus составляет приблизительно 2000 руб., при этом средства криптографической защиты семейства CryptoPro уже включены в этот пакет. Далее, для защиты хранимой на компьютере персональной информации целесообразно докупить один из пакетов защиты данных CryptoPro EFS, Secure Pack Explorer либо “Криптопроводник”. Цена каждого из этих продуктов составляет от 600 до 1000 руб. Итого защита одного рабочего места без учета установки и настройки обойдется примерно в 3000 руб., а установка и адаптация программ традиционно добавит 10–15% к стоимости Условно можно выделить “мистические десять шагов на пути” к защищенной системе для обработки ПД. Определите те элементы вашей ИС, которые необходимо защитить в первую очередь. Сначала выясните, какие именно персональные данные нуждаются в защите и где в вашей системе они находятся в настоящее время. Затем проверьте, действительно ли нуждаются в защите данных рабочие места всех без исключения сотрудников. Может быть, проще выделить отдельные компьютеры для работы с персональной информацией, которую необходимо защищать особенно надежно? Помните, что компьютер, подключенный к Интернету, — не самое удачное место для хранения ПД! Оцените текущее состояние информационной безопасности. Насколько оно удовлетворительно? Если есть возможность, проведите внешний аудит защищенности вашей системы. Классифицируйте вашу ИС в соответствии с приведенными выше рекомендациями. Сравните ваши выводы с выводами внешнего аудита. Определите, кто в данное время отвечает за обеспечение защиты ИС. Нельзя ли сузить круг лиц, от которых зависит надежность этой защиты? В то же время помните — безопасность не может зависеть от одного человека! Обязательно назначьте аудиторов, например, главный врач может контролировать работу специалистов по заполнению и перемещению ПД. Критически относитесь к требованиям специалистов, если они настаивают на установке аппаратных средств обеспечения безопасности. Учтите также, что применение криптографических средств — довольно серьезная работа. Важно понять: не помешает ли обслуживание средств шифрования и использование цифровой подписи основной деятельности вашей компании? Учтите также, что далеко не каждый сотрудник может и должен заниматься шифрованием данных. Наведите порядок в сфере безопасности вашей клиники. Установите режим, который позволит обеспечить требуемый уровень информационной безопасности, однако не перегните палку. Например, нельзя лишать людей возможности пользоваться мобильными телефонами. Нецелесообразно также запрещать сотрудникам обращаться к электронной почте и Интернету в личных целях. В то же время вполне целесообразно регламентровать порядок внесения на территорию компании флэш-носителей и собственных ноутбуков, либо использовать имеющуюся в Secure Pack Rus функцию отключения не разрешенных к использованию администратором USB-накопителей Потребуйте от ИТ-специалистов составить чёткий план работы по созданию и настройке системы безопасности. Попросите обосновать необходимость закупок дополнительных средств обеспечения безопасности. Настаивайте на гарантиях того, что настройка системы безопасности не скажется на основной работе системы. Контролируйте выполнение плана по созданию системы безопасности. Выслушайте мнения врачей и сотрудников — не мешают ли меры безопасности их работе и основной деятельности? Поддерживайте и проверяйте состояние защищенности ПД, а также укрепляйте лояльность сотрудников, занимающихся безопасностью. Спокойно относитесь к инновациям в области безопасности — здоровый консерватизм позволить сэкономить ваши деньги.


MiTM атака на RDP с SSL

https://labs.portcullis.co.uk/blog/ssl-man-in-the-middle-attacks-on-rdp/Копипаста:This post seeks to demonstrate why users learning to ignore those certificate warnings for SSL-based RDP connection could leave them open to Man-in-the-middle (MiTM) attacks. The MiTM attack demonstrated displays keystrokes sent during an RDP session. We conclude with some advice on how to avoid being the victim of such an attack. Types of RDP connectionsBefore we start, let’s first clarify which of the various RDP connection types this post is about. There are 3 types of connection: RDP Security LayerSSL (TLS 1.0)CredSSP (SSL with NLA)It’s the middle one we’ll demonstrate an attack on in this post. On the Terminal Server, SSL is configured like this (with any NLA checkboxes unticked): RDP configuration usedSome connections may also be vulnerable if the server is set to “Negotiate” its Security Layer to – as that could result in SSL being used. SSL certificate warningIf users are used to dismissing a warnings like this one each time they connect, then this post is relevant to them: SSL warning that should not be routinely ignoredAttack overviewAt a high level, the attack will proceed in a similar way to any SSL MiTM attack: Have the victim connect to a PoC tool (rdp-ssl-mitm.py) on our system instead of the RDP server they’re trying to reachUsing the RDP protocol, our tool will negotiate the use of SSLAt the point the connection is upgraded to SSL, our tool will negotiate an SSL connection with the RDP client using its own (untrusted) SSL certificate. This will give our tool access to data sent by the RDP client in cleartextOur tool also needs to create an SSL connection with the legitimate RDP server down which it will send data from the RDP clientThe only complication to this attack is that our tool has to talk the RDP protocol briefly before creating the required SSL connections. 1. Having the victim connect to usIn a real attack, we’d need to have the RDP client connect to our system instead of the target server. This could be achieved using ARP spoofing, DNS spoofing or some other method. Rather than cloud the demonstration with such details, we’ll assume this is step is possible and just type the IP address of the attacker system into the victim RDP client. On our attacker system (192.168.190.170), we start our PoC tool. We tell it forward connections to the legitimate RDP server 192.168.2.96: $ ./rdp-ssl-mitm.py -r 192.168.2.96:3389[+] Listening for connections on 0.0.0.0:3389And we simply enter the IP address of the attacker system into the RDP client (the client connects from 192.168.190.1): We enter the attacker IP address to avoid the complexity of ARP spoofing2. Talk RDP to the client to negotiate the use of SSLThe negotiation of SSL is quite short within the RDP protocol: Message #1: Client > MiTM > Server 03 00 00 13 0e e0 00 00 00 00 00 01 00 08 00 0300 00 00This message is fairly static and our tool just passes it through to the server unaltered. The 03 means that the client supports RDP Security Layer, SSL and CredSSP. Message #2: Server > MiTM > Client 03 00 00 13 0e d0 00 00 12 34 00 02 00 08 00 0100 00 00In the next message the server chooses the protocol to use. The 01 in this case means the the server has chosen SSL (not CredSSP which would be 02). Again, we pass this message back to the client unaltered. Note that if the server were to select CredSSP (02), then the demonstration would fail. We’re attacking SSL, not CredSSP. 3. Create SSL connection with RDP clientMessage #3: Client > MiTM The 3rd message is the start of an SSL connection. Here is the SSL Client Hello message beginning 16 03 01… (03 01 being the version of SSL used: SSL 3.1 AKA TLS 1.0). 16 03 01 00 5a 01 00 00 56 03 01 52 21 ac be 6320 ce de 4b a5 90 18 f0 66 97 ee 9d 54 14 e3 1c… snip …Our tool does not forward this data directly to the server. Instead it responds with and SS Server Hello message and proceeds to complete the SSL connection with the client. The SSL certificate we present to the RDP client is issued to fred and this is displayed in the mstsc SSL warning shown to the user: The certificate presented by our PoC tool causes this security warningThe details of the SSL certificate differ to those the user would normally see – if the user were to check. To refine the attack we could make the certificate details match more closely, but we’d never get the signature to be the same as the normal certificate, so there’d always be a difference. 4. Create SSL connection with RDP serverSimultaneously, our tool also sends and SSL Client Hello to the RDP server and creates a second SSL connection. Displaying key strokesOur tool is now in a position to display the cleartext messages about keystrokes (for example) sent by the RDP client. It is relatively easy to determine what sort of message is sent when a key is pressed. The following two 4-byte messages are sent when the ‘p’ key is pressed: 44 04 00 1944 04 01 19The 3rd byte is the direction of key (00 means key-down, 01 means key-up).  The 4th byte is the key scan code.  If we look up 0×19 we find it corresponds to the p key. In the general case, the scan-code to character mapping depends which keyboard you’re using. In the PoC tool I implemented the mapping for for QWERTY keyboards, so if you have a UK/US keyboard, it should translate the majority of scan-codes to the correct characters. Note that we don’t get know whether characters are uppercase or lowercase. We’d have to manually track the status of CAPS Lock and SHIFT keys. Without getting too bogged down in the details, here’s some sample output from the PoC tool that shows keystrokes being logged – in particular an administrator logging in with username Administrator, password Password: $ ./rdp-ssl-mitm.py -r 192.168.2.96:3389 [+] Listening for connections on 0.0.0.0:3389[+] Incoming connection from 192.168.190.1:60370[+] New outgoing request to 192.168.2.96:3389 (SSL: 0)[+] Connected[+] Detected incoming SSL connection. Turning self into SSL socket[+] Incoming connection from 192.168.190.1:60374[+] New outgoing request to 192.168.2.96:3389 (SSL: 0)[+] Connected[+] Detected incoming SSL connection. Turning self into SSL socket<LShift-down>A<LShift-up>DMINISTRATOR<Tab><LShift-down>P<LShift-up>ASSWORD<Enter>ConclusionsLearning to ignore SSL certificate warnings is as bad for RDP connection as it is for HTTPS websites. The results are similar: users quickly become vulnerable to Man-in-the-middle attacks. Such attacks can harvest usernames, passwords, keystrokes and other sensitive data. Using SSL certificates that are signed by a Certificate Authority the RDP client trusts will result in no warning under normal operation, so is highly recommended. This attack doesn’t work if the server mandates NLA, so using NLA is also highly recommended. It’s important to note that this isn’t a vulnerability in the RDP Client or Server software.  Nor is this a  new discovery.  It’s a weakness in way RDP is sometimes used which stems from users ignoring security warnings.  At a technical level, this is a fairly vanilla SSL MiTM attack. It might be interesting to extend this work by recording screen captures; or by injecting images of login boxes to encourage users to part of with other credentials. There would also be an opportunity to attack any drives that the RDP client has mapped for drive redirection – see Attacking the RDP Clients for inspiration. These would be pretty demanding coding challenges, though!


Cacti + Mikrotik = Full Monitoring

Захотелось мне собирать все логи с сетевого оборудования в одном месте. Решил поднять syslog-сервер. Так как с такими сервисами никогда не сталкивался, пришлось спросить у великого гугля. Он подсказал мне, что с этим неплохо справляется система мониторинга Cacti. А о ней то я уже наслышан, и в планах стояло внедрение сего чуда в сеть. Итак, теперь основная цель не сислог, а мониторинг - то, для чего и создан cacti. Настроим мониторинг, а потом примемся за сислог.


Пара слов о проблемах на портах коммутаторов

При выставленной опции autonegotiation на порту свитча и сетевой карте клиента, оба устройства пытаются договориться о параметрах скорости и дуплекса на линке.Если не удаётся согласовать параметры, то используется 10 Мб/с, полудуплекс.Если коммутатор определяет скорость линка без использования автосогласования, то Если скорость 10 Мб/с или 100 Мб/с, используется полудуплекс. Если скорость 1 Гб/с, используется полный дуплекс.Причем, при выставлении дуплекса в фулл, получаем скорость в 2 раза выше (в идеале, конечно) доступной на линке. Т.е. в полудуплексе имеем 10 Мб/с, а в полном дуплексе уже 10*2 Мб/с. За счет того, что данные могут бегать в обоих направлениях.Ошибки на портах:Runts. Количество фреймов, не достигших minimal frame size. 64 байта или 512 бит. 18 байт служебной информации (Source MAC, Destination MAC, CRC) и 46 байт полезной нагрузки (инкапсулированной в протоколы более высокого уровня).Giants. Количество фреймов, превышающих maximum frame size. 1518 байт или 12144 бит. 18 байт служебной информации + 1500 байт полезной нагрузки.CRC. Количество принятых фреймов, не прошедших проверку контрольной суммы. То есть, поврежденные фреймы. Могут быть вызваны коллизиями. Смотреть первую часть поста.Frame. Количество принятых фреймов неверного формата.Collisions. Количество коллизий, произошедших при отправке фреймов.Late Collisions. Количество коллизий, произошедших после передачи первых 64 байт фрейма. Скорее всего, несоответствие дуплексов.По режимам дуплекса гуглить CSMA/CD. Весь пост - вольный перевод Odom Wendell Cisco ICND1 100-101 Official Cert Guide. Инфа применительно к цискам.


Регулирование ИТ и ИБ в РФ


Менеджмент инцидентов иформационной безопасности. ГОСТ

http://bezmaly.files.wordpress.com/2013/10/d0b3d0bed181d182-d0b8d0bdd186d0b8d0b4d0b5d0bdd182d18b-d0b2-d0bed0b1d0bbd0b0d181d182d0b8-d0b8d0b1.pdf