Лучшие DNS практики для телекома

В настоящее время, во многих российских провайдерах уделяется очень мало внимания DNS серверам. Тем не менее это очень важная составляющая услуг доступа в интернет.
Инженерам по телематике и инфраструктурным сервисам, а так-же их боссам посвящается.

Выполнение перечисленных правил может помочь вам минимизировать жалобы ваших пользователей на DNS:

• Никогда не используйте межсетевые экраны с контролем состояния сессий на DNS серверах. Iptables и пр. сетевые экраны существенным образом уменьшают производительность нагруженных DNS серверов. Если по организационным причинам необходимо проводить фильтрацию трафика — то лучше это делать на обычных не statefull межсетевых экранах на сетевом оборудовании. Например с помощью обычных ACL на аппаратных маршрутизаторах Cisco, начиная с 7600 (6500) серии, построенных на ASIC и FPGA.

• Размер кеша должен быть меньше или равен 512Мб. БОльшие значения не приводят к хоть сколько либо значимому увеличению эффективности кеширования, но увеличивают требования к пропускной способности оперативной памяти и эффективности кешей центрального процессора. При использовании кеша размером 512Мб желательно иметь общий объем оперативной памяти не менее 2048Мб.
• Средняя нагрузка на центральный процессор DNS сервера не должна превышать 30%. Выполнение этого правила позволит легче пережить DDOS и вирусные атаки.
• Всегда используйте настройки, ограничивающие доступ к кеширующим DNS серверам только для своих клиентов. Не стоит позволять их использовать всем пользователям Интернет. Это может привести к использованию ваших DNS серверов для DNS Amplification Attacks, к неконтролируемой нагрузке и увеличивает шансы злоумышленников отравить ваш кеш.
• Всегда разделяйте авторитативные и кеширующие DNS сервера. Это справедливо для организаций любых размеров.
• DNS сервера желательно эксплуатировать на выделенном для них оборудовании. Для кеширующих DNS серверов самым важным параметром является мощность центрального процессора. Для авторитативных DNS серверов несколько важнее пропускная способность оперативной памяти. При малых нагрузках на DNS сервера допускается их использование на системах виртуализации. При этом им обязательно необходимо гарантировать ресурсы по процессору, памяти и сети.
• Для DNS серверов лучше использовать процессоры максимальной частоты. Лучше один мощный двух-ядерный или четырех-ядерный процессор, чем два процессора меньшей частоты. Дело в том, что современное программное обеспечение плохо масштабируется на множество ядер-нитей процессоров. Более того лучше использовать «single-threaded» реализации (или сборки) программного обеспечения DNS.
• Используйте 64-битные операционные системы на современном оборудовании. Для новых систем следует использовать сервера, построенные x86-64. Системы построенные на SPARC процессорах значительно меньше подходят для задач DNS сервера.
• Для DNS серверов желательно использовать гигабитные сетевые интерфейсы, для того чтобы сеть не стала узким местом.
• При необходимости распределять нагрузку на несколько DNS серверов рекомендуется делать это через IP ANYCAST или с помощью баласировщиков нагрузки c выключением состояния сессий.
• Используйте проверенные решения. Тестируйте новые версии перед использованием их в продуктивной среде. Старайтесь делать одно изменение за раз, не больше. Например обновляя версию ПО, обновите ее сначала только на одном из серверов.
• Не увлекайтесь слишком тюнингом сетевого стэка операционной системы. Как правило все современные UNIX и UNIX-like системы имеют оптимальные настройки. Если появились какие то проблемы эксплуатации, то надо провести как можно более глубокую диагностику, перед тем как кошмарить операционную систему громадными буферами и пр.
• До начала использования DNSSEC необходимо тщательно протестировать как и ПО, так и нагрузку на оборудование. Дополнительно к этому стоит внимательно отнестись к процедурам, связанным с DNSEC, так как любая ошибка может быть незаметной и в то же время носить фатальный характер, когда DNSSEC кеширующие DNS сервера будут отвергать записи с ваших зон как неправильно подписанные.
• Не ленитесь настроить мониторинг ваших DNS серверов. Это позволить избежать проблем до того как их заметят пользователи. Ведь проблемы DNS воспринимаются пользователями как проблемы сети. Им неважно что у вас супер-современная скоростная низколатентная сеть, защищенная от сбоев, если у них медленно открыватся страничка в Интернет из за плохо работающего DNS сервера.
• Сохраняйте общий дизайн вашего DNS решения максимально простым. Это облегчит вам диагностику проблем.

Как установить telnet-сессию с коммутатором EdgeCore из скрипта

Есть известная "проблема": из скрипта (php, perl, python и т.п.) средствами
самого языка установить telnet-соединение с коммутаторами EdgeCore не
получается. Сразу после соединения свитч присылает бинарный "мусор", потом
коннект просто висит и отваливается по таймауту. Т.е. даже строки приглашения
от коммутатора получить не удается. В то же время тот же самый скрипт может
прекрасно работать по телнету с D-Link'ами.

Происходит это потому что edgecorе'ам надо согласовывать параметры терминала
при поднятии телнет-сессии. Т.е. сначала (сразу после коннекта на 23-й порт)
передать свитчу желаемые параметры сессии - и только после этого он передаст
окно приглашения и с ним можно будет работать.

Пример рабочей последовательности параметров:

   0xFF 0xFD 0x03 0xFF 0xFB 0x18 0xFF 0xFB 0x1F 0xFF 0xFB 0x20 0xFF 0xFB 0x21 0xFF 0xFB 0x22 0xFF 0xFB 0x27 0xFF 0xFD 0x05 

   0xFF 0xFA 0x18 0x00 0x58 0x54 0x45 0x52 0x4D 0xFF 0xF0 

   0xFF 0xFD 0x01 0xFF 0xFC 0x01

Что интересно - в таком виде отлично работается и с edgecore'ами, и с
d-link'ами. Хотя для d-link'ов такая "инициализация" и необязательна.

Рейтинг самых опасных ошибок при создании программ

Институт SANS (SysAdmin, Audit, Network, Security), совместно с организацией MITRE и ведущими экспертами по компьютерной безопасности, подготовил новую редакцию рейтинга 25 самых опасных ошибок, приводящих к возникновению серьезных уязвимостей. Рейтинг построен на основе анализа уязвимостей, обнаруженных в течение 2010 года. Ошибки были отобраны с учетом их распространенности, трудоемкости обнаружения и простоты эксплуатации уязвимости. В опубликованном документе подробно разбирается каждый из 25 видов ошибок, приводятся примеры уязявимостей и рекомендации для разработчиков по предотвращению появления подобных ошибок.

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

Проблемы в рейтинге разделены на три категории:

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

Общий рейтинг:

1. SQL Injection: Неспособность сохранения целостной структуры SQL запроса, что может привести к подстановке злоумышленником SQL запроса;
2. OS Command Injection: Неспособность корректного формирования структуры запускаемого приложения, может привести к подставке кода злоумышленника при выполнении внешней команды, через определение некорректных значений, используемых в качестве параметров запускаемой программы;
3. Buffer Overflow: Копирование содержимого буфера без предварительной проверки размера входных данных. Неспособность удержать действия в определенных жестких рамках или в пределах заданного буфера памяти, приводит к классическим уязвимостям вида выхода за допустимые границы и переполнению буфера;
4. XSS, Cross-site Scripting: Неспособность сохранения структуры web-страницы, что позволяет злоумышленнику внедрить на страницу свой скрипт или html-блок;
5. Missing Authentication: Отсутствие аутентификации при выполнении критических действий (например, при смене пароля, отсутствует проверка старого пароля);
6. Missing Authorization: Отсутствие должной проверки авторизации, что может привести к получению доступа к ресурсам или выполнения операций, не имея на это полномочий;
7. Hard-coded Credentials: Задание базового пароля или параметров аутентификации прямо в коде скрипта или в общедоступных файлах конфигурации;
8. Отсутствие шифрования конфиденциальных данных, например, хранение номера кредитной карты в БД в открытом виде;
9. Неограниченная возможность загрузки файлов опасного типа, например, когда через форму загрузки картинки на сайт можно загрузить (и затем выполнить) ".php" скрипт;
10. Доверие к непроверенному вводу при принятии решений, связанных с безопасностью. Например, излишнее доверие к содержимому cookie (кодирование прав доступа или уровня пользователя через cookie);
11. Выполнение приложений с предоставлением излишних привилегий и без надлежащего сброса привилегий;
12. C ross-Site Request Forgery (CSRF): Отсутствие проверки источника запроса, что может быть использовано злоумышленником для незаметного перенаправления авторизированного пользователя для выполнения определенных скрытых действий;
13. Path Traversal: Возможность внешнего переопределения путей или имен файлов, например, когда в качестве имени файла используется какой-то передаваемый параметр, используя "../" в котором можно выйти за пределы текущей директории;
14. Загрузка исполняемого кода без проверки его целостности через сверку с цифровой подписью, например, в результате взлома сайта или подстановки неверной информации в DNS, злоумышленник может изменить содержимое пакета с программой;
15. Некорректная авторизация. При доступе к требующему определенных привилегий ресурсу проверка доступа осуществляется некорректно, давая возможность атакующему преодолеть ограничения, свойственные его уровню доступа;
16. Включение внешней функциональности из недоверительной области. Например, включение на страницу виджета со внешнего ресурса, который теоретически может быть подменен злоумышленником через взлом сторонней системы или некорректное использование директивы include в PHP, позволяющей атакующему совершить включение кода с внешнего сайта;
17. Небезопасное назначение прав доступа к критически важным ресурсам, например, возможность чтения или изменения другим пользователем конфигурационных или служебных файлов;
18. Использование потенциально опасных функций, которые при неосторожном использовании могут привести к появлению уязвимостей. Классический пример подобных функций - strcpy и sprintf;
19. Использование ненадежных или рискованных криптографических алгоритмов. Например, использование XOR или DES;
20. Некорректный расчет размера буфера;
21. Отсутствие ограничения излишних попыток авторизации. Например,отсутствие лимита на число неудачных попыток авторизации в единицу времени может привести к осуществлению атак, направленных на подбор паролей (brute force);
22. Перенаправление на вызывающий доверие сайт через некорректное использование средств переброса на другой URL в веб-приложениях (например, когда когда в скрипт локального переброса вместо "/redirect?url=form.php" передают "/redirect?url=http://example.com");
23. Неконтролируемое форматирование строк (ошибка форматирования строк в функциях подобных printf);
24. Проблемы, связанные с целочисленным переполнением;
25. Создание хэшей на основе входных данных (например, пароля) без задействования случайного salt, что позволяет атакующим при проведении словарной атаки использовать списки предгенерированных хэшей, например, rainbow-таблицы.

Ассоциативные коллекции в Оракле

Вот таким способом можно пройтись по ассоциативной коллекции в Оракле:

key VARCHAR2(30);

key := assoc_collection.FIRST;

WHILE key IS NOT NULL LOOP

  DBMS_OUTPUT.PUT_LINE(

    key || ' = ' || assoc_collection(key) );

  key := assoc_collection.NEXT(key);

END LOOP;

Собственно ничего сложного :)