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

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


Wi-Fi. Интересное. 1.

Попала в мои руки приличная сеть с кучей беспроводных устройств. Пришлось грызть гранит беспроводных соединений. Отсюда, репосты нужного и интересного с хабра. Копипаст, чтоб не потерять инфу. Wi-Fi: неочевидные нюансы (на примере домашней сети) Сейчас многие покупают точки доступа 802.11n, но хороших скоростей достичь удается не всем. В этом посте поговорим о не очень очевидных мелких нюансах, которые могут ощутимо улучшить (или ухудшить) работу Wi-Fi. Всё описанное ниже применимо как к домашним Wi-Fi-роутерам со стандартными и продвинутыми (DD-WRT & Co.) прошивками, так и к корпоративным железкам и сетям. Поэтому, в качестве примера возьмем «домашнюю» тему, как более родную и близкую к телу. Ибо даже самые администые из админов и инженеристые из инженеров живут в многоквартирных домах (или поселках с достаточной плотностью соседей), и всем хочется быстрого и надежного Wi-Fi.[!!]: после замечаний касательно публикации первой части привожу текст целиком. Если вы читали первую часть — продолжайте отсюда.Несколько примечаний перед началом:Стиль изложения нарочито упрощен, т.к. некоторые вещи вам, возможно, придется объяснять соседям, совершенно незнакомым с основами радиосетей, стандартом 802.11 и регуляторной политикой государства.Все описанное ниже носит рекомендательный характер. Возможно, они неприменимы к вашей ситуации. Из любого правила есть исключения, которые опущены для краткости. Предельные случаи можно обсудить в комментариях.Пожалуйста, обратите внимание на слово «неочевидные». Подробное доказательство некоторых тезисов требует погружения в стандарты, я этого делать не хочу (хоть и пришлось пару раз).1. Как жить хорошо самому и не мешать соседям.[1.1] Казалось бы – чего уж там? Выкрутил точку на полную мощность, получил максимально возможное покрытие – и радуйся. А теперь давайте подумаем: не только сигнал точки доступа должен достичь клиента, но и сигнал клиента должен достичь точки. Мощность передатчика ТД обычно до 100 мВт (20 dBm). А теперь загляните в datasheet к своему ноутбуку/телефону/планшету и найдите там мощность его Wi-Fi передатчика. Нашли? Вам очень повезло! Часто её вообще не указывают (можно поискать по FCC ID). Тем не менее, можно уверенно заявлять, что мощность типичных мобильных клиентов находится в диапазоне 30-50 мВт. Таким образом, если ТД вещает на 100мВт, а клиент – только на 50мВт, в зоне покрытия найдутся места, где клиент будет слышать точку хорошо, а ТД клиента — плохо (или вообще слышать не будет) – асимметрия. Это справедливо даже с учетом того, что у точки обычно лучше чувствительность приема — смотрите под спойлером. Опять же, речь идет не о дальности, а о симметрии.Сигнал есть – а связи нет. Или downlink быстрый, а uplink медленный. Это актуально, если вы используете Wi-Fi для онлайн-игр или скайпа, для обычного интернет-доступа это не так и важно (только, если вы не на краю покрытия). И будем жаловаться на убогого провайдера, глючную точку, кривые драйвера, но не на неграмотное планирование сети. Обоснование (для тех, кому интересны подробности):Вывод: может оказаться, что для получения более стабильной связи мощность точки придется снизить. Что, согласитесь, не совсем очевидно :) [1.2] Также далеко не самым известным фактом, добавляющим к асимметрии, является то, что у большинства клиентских устройств мощность передатчика снижена на «крайних» каналах (1 и 11/13 для 2.4 ГГц). Вот пример для iPhone из документации FCC (мощность на порту антенны).Как видите, на крайних каналах мощность передатчика в ~2.3 раза ниже, чем на средних. Причина в том, что Wi-Fi – связь широкополосная, удержать сигнал чётко в пределах рамки канала не удастся. Вот и приходится снижать мощность в «пограничных» случаях, чтобы не задевать соседние с ISM диапазоны. Вывод: если ваш планшет плохо работает в туалете – попробуйте переехать на канал 6.2. Раз уж речь зашла о каналах…Всем известны «непересекающиеся» каналы 1/6/11. Так вот, они пересекаются! Потому, что Wi-Fi, как было упомянуто раньше, технология широкополосная и полностью сдержать сигнал в рамках канала невозможно. Приведенные ниже иллюстрации демонстрируют эффект для 802.11n OFDM (HT). На первой иллюстрации изображена спектральная маска 802.11n OFDM (HT) для 20МГц канала в 2.4ГГц (взята прямо из стандарта). По вертикали — мощность, по горизонтали — частота (смещение от центральной частоты канала). На второй иллюстрации я наложил спектральные маски каналов 1,6,11 с учетом соседства. Из этих иллюстраций мы сделаем два важных вывода. [2.1] Все считают, что ширина канала — 22МГц (так и есть). Но, как показывает иллюстрация, сигнал на этом не заканчивается, и даже непересекающиеся каналы таки перекрываются: 1/6 и 6/11 — на ~-20dBr, 1/11 — на ~-36dBr, 1/13 — на -45dBr.Попытка поставить две точки доступа, настроенные на соседние «неперекрывающиеся» каналы, близко друг от друга приведет к тому, что каждая из них будет создавать соседке помеху в 20dBm – 20dB – 50dB [которые добавим на потери распространения сигнала на малое расстояние и небольшую стенку] =-50dBm! Такой уровень шума способен целиком забить любой полезный Wi-Fi сигнал из соседней комнаты, или блокировать ваши коммуникации целиком! ПочемуВывод: если вы поставите точку рядом со стеной, а ваш сосед – с другой стороны стены, его точка на соседнем «неперекрывающемся» канале все равно может доставлять вам серьезные проблемы. Попробуйте посчитать значения помехи для каналов 1/11 и 1/13 и сделать выводы самостоятельно. Аналогично, некоторые стараются «уплотнить» покрытие, устанавливая две точки настроенные на разные каналы друг на друга стопкой — думаю, уже не надо объяснять, что будет (исключением тут будет грамотное экранирование и грамотное разнесение антенн — все возможно, если знать как). [2.2] Второй интересный аспект – это попытки чуть более продвинутых пользователей «убежать» между стандартными каналами 1/6/11. Опять же, логика проста: «Я между каналами словлю меньше помех». По факту, помех, обычно, ловится не меньше, а больше. Раньше вы страдали по полной только от одного соседа (на том же канале, что и вы). Но это были помехи не первого уровня OSI (интерференция), а второго – коллизии — т.к. ваша точка делила с соседом коллизионный домен и цивилизованно соседствовала на MAC-уровне. Теперь вы ловите интерференцию (Layer1) от двух соседей с обеих сторон. В итоге, delay и jitter, может, и попытались немного уменьшиться (т.к. коллизий теперь как бы нет), но зато уменьшилось и соотношение сигнал/шум. А с ним уменьшились и скорости (т.к. каждая скорость требует некоторого минимального SNR — об этом в [3.1]) и процент годных фреймов (т.к. уменьшился запас по SNR, увеличилась чувствительность к случайным всплескам интерференции). Как следствие, обычно, возростает retransmit rate, delay, jitter, уменьшается пропускная способность.Кроме того, при значительном перекрытии каналов таки возможно корректно принять фрейм с соседнего канала (если соотношение сигнал/шум позволяет) и таки получить коллизию. А при помехе выше -62dBm вышеупомянутый механизм CCA просто не даст воспользоваться каналом. Это только усугубляет ситуацию и негативно влияет на пропускную способность.Вывод: не старайтесь использовать нестандартные каналы, не просчитав последствий, и отговаривайте от этого соседей. В общем, то же, что и с мощностью: отговаривайте соседей врубать точки на полную мощность на нестандартных каналах – будет меньше интерференции и коллизий у всех. Как просчитать последствия станет понятно из [3].[2.3] По примерно тем же причинам не стоит ставить точку доступа у окна, если только вы не планируете пользоваться/раздавать Wi-Fi во дворе. Толку от того, что ваша точка будет светить вдаль, вам лично никакого – зато будете собирать коллизии и шум от всех соседей в прямой видимости. И сами к захламленности эфира добавите. Особенно в многоквартирных домах, построенных зигзагами, где окна соседей смотрят друг на друга с расстояния в 20-30м. Соседям с точками на подоконниках принесите свинцовой краски на окна… :)[2.4][UPD] Также, для 802.11n актуален вопрос 40MHz каналов. Моя рекоммендация — включать 40MHz в режим «авто» в 5GHz, и не включать («20MHz only») в 2.4GHz (исключение — полное отсутствие соседей). Причина в том, что в присутствии 20MHz-соседей вы с большой долей вероятности получите помеху на одной из половин 40MHz-канала + включится режим совместимости 40/20MHz. Конечно, можно жестко зафиксировать 40MHz (если все ваши клиенты его поддерживают), но помеха все равно останется. Как по мне, лучше стабильные 75Mbps на поток, чем нестабильные 150. Опять же, возможны исключения — применима логика из [3.4]. Подробности можно почитать в этой ветке комментариев (вначале прочтите [3.4]).3. Раз уж речь зашла о скоростях…[3.1] Уже несколько раз мы упоминали скорости (rate/MCS — не throughput) в связке с SNR. Ниже приведена таблица необходимых SNR для рейтов/MCS, составленная мной по материалам стандарта. Собственно, именно поэтому для более высоких скоростей чувствительность приемника меньше, как мы заметили в [1.1].В сетях 802.11n/MIMO благодаря MRC и другим многоантенным ухищрениям нужный SNR можно получить и при более низком входном сигнале. Обычно, это отражено в значениях чувствительности в datasheet’ах.Отсюда, кстати, можно сделать еще один вывод: эффективный размер (и форма) зоны покрытия зависит от выбранной скорости (rate/MCS). Это важно учитывать в своих ожиданиях и при планировании сети.[3.2] Этот пункт может оказаться неосуществимым для владельцев точек доступа с совсем простыми прошивками, которые не позволяют выставлять Basic и Supported Rates. Как уже было сказано выше, скорость (rate) зависит от соотношения сигнал/шум. Если, скажем, 54Mbps требует SNR в 25dB, а 2Mbps требует 6dB, то понятно, что фреймы, отправленные на скорости 2Mbps «пролетят» дальше, т.е. их можно декодировать с большего расстояния, чем более скоростные фреймы. Тут мы и приходим к Basic Rates: все служебные фреймы, а также броадкасты (если точка не поддерживает BCast/MCast acceleration и его разновидности), отправляются на самой нижней Basic Rate. А это значит, что вашу сеть будет видно за многие кварталы. Вот пример (спасибо Motorola AirDefense).Опять же, это добавляет к рассмотренной в [2.2] картине коллизий: как для ситуации с соседями на том же канале, так и для ситуации с соседями на близких перекрывающихся каналах. Кроме того, фреймы ACK (которые отправляются в ответ на любой unicast пакет) тоже ходят на минимальной Basic Rate (если точка не поддерживает их акселерацию) Еще немного математикиВывод: отключайте низкие скорости – и у вас, и у соседей сеть станет работать быстрее. У вас – за счет того, что весь служебный трафик резко начнет ходить быстрее, у соседей – за счет того, что вы теперь для них не создаете коллизий (правда, вы все еще создаете для них интерференцию — сигнал никуда не делся — но обычно достаточно низкую). Если убедите соседей сделать то же самое – у вас сеть будет работать еще быстрее.[3.3] Понятно, что при отключении низких скоростей подключиться к тоже можно будет только в зоне более сильного сигнала (требования к SNR стали выше), что ведет к уменьшению эффективного покрытия. Равно как и в случае с понижением мощности. Но тут уж вам решать, что вам нужно: максимальное покрытие или быстрая и стабильная связь. Используя табличку и datasheet’ы производителя точки и клиентов почти всегда можно достичь приемлемого баланса.[3.4] Еще одним интересным вопросом являются режимы совместимости (т.н. “Protection Modes”). В настоящее время есть режим совместимости b-g (ERP Protection) и a/g-n (HT Protection). В любом случае скорость падает. На то, насколько она падает, влияет куча факторов (тут еще на две статьи материала хватит), я обычно просто говорю, что скорость падает примерно на треть. При этом, если у вас точка 802.11n и клиент 802.11n, но у соседа за стеной точка g, и его трафик долетает до вас – ваша точка точно так же свалится в режим совместимости, ибо того требует стандарт. Особенно приятно, если ваш сосед – самоделкин и ваяет что-то на основе передатчика 802.11b. :) Что делать? Так же, как и с уходом на нестандартные каналы – оценить, что для вас существеннее: коллизии (L2) или интерференция (L1). Если уровень сигнала от соседа относительно низок, переключайте точки в режим чистого 802.11n (Greenfield): возможно, понизится максимальная пропускная способность (снизится SNR), но трафик будет ходить равномернее из-за избавления от избыточных коллизий, пачек защитных фреймов и переключения модуляций. В противном случае – лучше терпеть и поговорить с соседом на предмет мощности/перемещения ТД. Ну, или отражатель поставить… Да, и не ставьте точку на окно! :)[3.5] Другой вариант – переезжать в 5 ГГц, там воздух чище: каналов больше, шума меньше, сигнал ослабляется быстрее, да и банально точки стоят дороже, а значит – их меньше. Многие покупают dual radio точку, настраивают 802.11n Greenfield в 5 ГГц и 802.11g/n в 2.4 ГГц для гостей и всяких гаджетов, которым скорость все равно не нужна. Да и безопаснее так: у большинства script kiddies нет денег на дорогие игрушки с поддержкой 5 ГГц. Для 5 ГГц следует помнить, что надежно работают только 4 канала: 36/40/44/48 (для Европы, для США есть еще 5). На остальных включен режим сосуществования с радарами (DFS). В итоге, связь может периодически пропадать.4. Раз уж речь зашла о безопасности…Упомянем некоторые интересные аспекты и здесь.[4.1] Какой должна быть длина PSK? Вот выдержка из текста стандарта 802.11-2012, секция M4.1:Keys derived from the pass phrase provide relatively low levels of security, especially with keys generated form short passwords, since they are subject to dictionary attack. Use of the key hash is recommended only where it is impractical to make use of a stronger form of user authentication. A key generated from a passphrase of less than about 20 characters is unlikely to deter attacks.Вывод: ну, у кого пароль к домашней точке состоит из 20+ символов? :)[4.2] Почему моя точка 802.11n не «разгоняется» выше скоростей a/g? И какое отношение это имеет к безопасности? Стандарт 802.11n поддерживает только два режима шифрования: CCMP и None. Сертификация Wi-Fi 802.11n Compatible требует, чтобы при включении TKIP на радио точка переставала поддерживать все новые скоростные режимы 802.11n, оставляя лишь скорости 802.11a/b/g. В некоторых случаях можно видеть ассоциации на более высоких рейтах, но пропускная способность все равно будет низкой. Вывод: забываем про TKIP – он все равно будет запрещен с 2014 года (планы Wi-Fi Alliance).[4.3] Стоит ли прятать (E)SSID? (это уже более известная тема)спрятался5. Всякая всячина.[5.1] Немного о MIMO. Почему-то по сей день я сталкиваюсь с формулировками типа 2x2 MIMO или 3x3 MIMO. К сожалению, для 802.11n эта формулировка малополезна, т.к. важно знать еще количество пространственных потоков (Spatial Streams). Точка 2x2 MIMO может поддерживать только один SS, и не поднимется выше 150Mbps. Точка с 3x3 MIMO может поддерживать 2SS, ограничиваясь лишь 300Mbps. Полная формула MIMO выглядит так: TX x RX: SS. Понятно, что количество SS не может быть больше min (TX, RX). Таким образом, приведенные выше точки будут записаны как 2x2:1 и 3x3:2. Многие беспроводные клиенты реализуют 1x2:1 MIMO (смартфоны, планшеты, дешевые ноутбуки) или 2x3:2 MIMO. Так что бесполезно ожидать скорости 450Mbps от точки доступа 3x3:3 при работе с клиентом 1x2:1. Тем не менее, покупать точку типа 2x3:2 все равно стоит, т.к. большее количество принимающих антенн добавляет точке чувствительности (MRC Gain). Чем больше разница между количеством принимающих антенн точки и количеством передающих антенн клиента — тем больше выигрыш (если на пальцах). Однако, в игру вступает multipath.[5.2] Как известно, multipath для сетей 802.11a/b/g – зло. Точка доступа, поставленная антенной в угол, может работать не самым лучшим образом, а выдвинутая из этого угла на 20-30см может показать значительно лучший результат. Аналогично для клиентов, помещений со сложной планировкой, кучей металлических предметов и т.д. Для сетей MIMO с MRC и в особенности для работы нескольких SS (и следовательно, для получения высоких скоростей) multipath – необходимое условие. Ибо, если его не будет – создать несколько пространственных потоков не получится. Предсказывать что-либо без специальных инструментов планирования здесь сложно, да и с ними непросто. Вот пример рассчетов из Motorola LANPlanner, но однозначный ответ тут может дать только радиоразведка и тестирование. Создать благоприятную multipath-обстановку для работы трех SS сложнее, чем для работы двух SS. Поэтому новомодные точки 3x3:3 работают с максимальной производительностью обычно лишь в небольшом радиусе, да и то не всегда. Вот красноречивый пример от HP (если копнуть глубже в материалы анонса их первой точки 3x3:3 — MSM460)[5.3] Ну, и несколько интересных фактов для коллекции:Человеческое тело ослабляет сигнал на 3-5dB (2.4/5ГГц). Просто развернувшись лицом к точке можно получить более высокую скорость.Некоторые дипольные антенны имеют асммметричную диаграмму направленности в H-плоскости («вид сбоку») и лучше работают перевернутымиВ фрейме 802.11 может использоваться одновременно до четырех MAC-адресов, а в 802.11s (новый стандарт на mesh) — до шести!ИтогоТехнология 802.11 (да и радиосетей в целом) обладает множеством неочевидных особенностей. Лично у меня вызывает громадное уважение и восхищение тот факт, что люди отточили насколько сложную технологию до уровня «воткни-работай». Мы рассмотрели (в разном объеме) разные аспекты физического и канального уровня сетей 802.11:Асиметрию мощностейОграничения на мощность передачи в граничных каналахПересечение «непересекающихся» каналов и последствияРаботу на «нестандартных» каналах (отличных от 1/6/11/13)Работу механизма Clear Channel Assesment и блокировку каналаЗависимость скорости (rate/MCS) от SNR и, как следствие, зависимость чувствительности приемника и зоны покрытия от требуемой скоростиОсобенности пересылки служебного трафикаПоследствия включения поддержки низких скоростейПоследствия включения поддержки режимов совместимостиВыбор каналов в 5ГГцНекоторые забавные аспекты безопасности, MIMO и проч.Не все было рассмотрено в полном объеме и исчерпывающем виде, равно как за бортом остались неочевидные аспекты сосуществования клиентов, балансировки нагрузки, WMM, питания и роуминга, экзотика типа Single-Channel Architecture и индивидуальных BSS — но это уже тема для сетей совсем другого масштаба. Если следовать хотя бы вышеприведенным соображениям, в обычном жилом доме можно получить вполне приличный коммунизм microcell, как в высокопроизводительных корпоративных WLAN. Надеюсь, статья была вам интересна.