vesselin.org/tech

Конструкция на AS112 в мрежата на Софийския Университет "Св. Климент Охридски"

Vesselin Kolev — 2008-06-19T08:46:08Z

Документът описва подробно техническата реализация на AS112 в мрежата на Софийския Университет "Св. Климент Охридски".

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/as112-in-su.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Напълно автономно делегиране на in-addr.arpa и ip6.arpa поддомейни

Vesselin Kolev — 2008-05-28T08:46:08Z

Напълно автономното делегиране на in-addr.arpa и ip6.arpa поддомейни има за цел да снижи броят запитвания към DNS, извървшвани в хода на изпълнението на рекурсивните заявки, за извличането на записи от in-addr.arpa и ip6.arpa поддомейни. В изложението по-долу нарочно е употребяван термина "поддомейн", а не домейн. Разделението на домейн и поддомейни почти винаги е условно и зависи от това къде в дървото на делегирания в DNS и от кого е обособена дадена автономна структура от имена. Негласно е прието всяка йерархична структура от имена, която се обслужва технически и административно от един субект, да се нарича домейн. Всяко дефиниране на подструктура в йерархичното дърво на домейна, което се извършва от организацията, която управлява последния, се нарича поддомейн. От тази гледна точка, RIPE и останалите RIR (регионални интернет регистри), делегират in-addr.arpa и ip6.arpa домейни. След като един субект получи управлението на съответния in-addr.arpa или ip6.arpa домейн, той може да дефинира в него поддомейни, съгласно своите нужди. Поддомейните обаче, нямат делегиращи записи в сървърите за имена на RIR. Те се делегират от субекта, който управлява домейна.

Най-честата практика е делегирането на in-addr.arpa и ip6.arpa домейните и поддомейните, да става чрез домейни различни от in-addr.arpa и ip6.arpa. Например, домейнът 0.0.193.in-addr.arpa (служеш за решаване на обратната задача в DNS за IPv4 мрежата 193.0.0.0/24), е делегиран по следния начин в RIR зоната 193.in-addr.arpa:

0.0.193.in-addr.arpa.  172800  IN   NS   sec1.apnic.net.
0.0.193.in-addr.arpa.  172800  IN   NS   sec3.apnic.net.
0.0.193.in-addr.arpa.  172800  IN   NS   ns-pri.ripe.net.

Това делегиране е направено така, че за да стане извличане на записи от зоната на домейна 0.0.193.in-addr.arpa, следва да се извличат записи от зоните на домейните apnic.net и/или ripe.net.

Подобен пример може да се даде и ip6.arpa чрез зоната на домейна 6.0.1.0.0.2.ip6.arpa, която е делегирана по следния начин:

6.0.1.0.0.2.ip6.arpa.  84600   IN   NS   sec1.apnic.net.
6.0.1.0.0.2.ip6.arpa.  84600   IN   NS   sec3.apnic.net.
6.0.1.0.0.2.ip6.arpa.  84600   IN   NS   sunic.sunet.se.
6.0.1.0.0.2.ip6.arpa.  84600   IN   NS   ns-pri.ripe.net.
6.0.1.0.0.2.ip6.arpa.  84600   IN   NS   tinnie.arin.net.
6.0.1.0.0.2.ip6.arpa.  84600   IN   NS   ns3.nic.fr.

Тук отново имаме делегиране чрез използване на други домейни, различни дори от майчиния ip6.arpa.

Целта на настоящата статия е да покаже, че има и друг, по-икономичен откъм брой заявки към DNS и трафик начин, чрез който могат да се делегират in-addr.arpa и ip6.arpa домейни и поддомейни.

Синтаксисът на прмерните декларации и дефиниции е съобразен с BIND9.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/autonomous_arpa_delegation.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

DNSSEC и BIND9 - кратко ръководство

Vesselin Kolev — 2008-06-19T08:46:08Z

DNSSEC е протокол, чието актуално описание е направено в следните документи: RFC4033, RFC4034 и RFC4035.

Основната идея на DNSSEC е начин за удостоверяване на автентичността на ресурсните записите в зоната на даден домейн, на база проверка на електроннния подпис извършен върху тях. Така се гарантира, че записите наистина принадлежат на съответната зона на домейн и не са генерирани с цел измама по пътя на DNS заявката. Извършването и проверката на електронния подпис в рамките на DNSSSEC става чрез използването на криптографска система с публичен ключ. За момента използваните в DNSSEC криптографски алгоритми с публичен ключ са DSA и RSA. Генерира се двойка ключове по един от споменатите два криптографски алгоритъма и с помощта на частния ключ от двойката, администратора на домейна подписва ресурсните записи в зоната. Електронните подписи върху ресурсните записи се влагат в зоната също като ресурсни записи. Проверката на електронния подпис върху даден ресурсен запис става чрез публичния ключ от същата двойка ключове. Самият публичен ключ се публикува като ресурсен запис в зоната на домейна. Когато даден клиент иска да провери автентичността на даден запис в зоната на домейна, извлича записа, който иска да провери, след това извлича записа, който съдържа публичния ключ и ако подписът е проверяем с публичния ключ, има автентичност. Разбира се този, който проверява електронния подпис трябва да знае дали публичния ключ, който извлича като запис е автентичен или не. Това става с методи извън DNSSEC, които са дискутирани в статията.

Документът акцентира върху DNSSEC интеграцията в BIND9.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/bind9-dnssec.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Използване на TSIG при комуникацията "клиент-сървър" в DNS

Vesselin Kolev — 2008-06-19T08:46:08Z

TSIG е метод за извършване и проверка на електронен подпис върху DNS заявки и отговорите им с помощта на криптосистема със секретен ключ. Методът е обект на описание в RFC2845.

Статията описва настройката и работата с TSIG между DNS клиентския софтуер и BIND9.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/bind9-tsig-roadwarriors.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Динамично управляеми зони на домейни в ISC BIND9

Vesselin Kolev — 2008-06-19T08:46:08Z

Описана е добра практика по реализиране на динамична актуализация на съдържанието на зони на домейни в BIND9, като е наблегнато на сигурността на удостоверяване на източника на актуализацията чрез TSIG.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/ddns-bind9.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Динамично управляеми зони на домейни в ISC BIND9

Vesselin Kolev — 2008-06-12T08:46:08Z

Инструментът nsupdate е част от пакета bind. Той служи за дистанционно управление на съдържание на зонални файлове, разположени (в общия случай) върху отделечени сървъри за имена. За да може да бъде извършено това управление, описанието на зоната в конфигурационния файл на отдалечения сървър named.conf, трябва да е такова, че да позволява динамичното й управление.

Предимството на nsupdate е, че не се налага собственика на зоната да има права за достъп до отдалечената система (напрмер потребителско име и/или достъп до локалната файлова система и т.н). Още повече, не се налага той да има достъп до ръчна редакция на файла на зоната на домейна чрез някакви локални за отдалечената система инструменти като скриптове и др.

Статията описва подробно работата с nsupdate и особеностите на синтаксиса в команден ред.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/nsupdate.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Управление на обекти в RIPE DB чрез OpenPGP идентификация

Vesselin Kolev — 2008-06-18T08:46:08Z

Документът описва добра практика по използването на OpenPGP подписани заявки за управление на обектите в RIPE DB. Особено внимание е отделено на начина на предаване на заявките по криптиран канал, с цел изключване на злонамерени повторения на заявки (каквато опасност има, ако се използват некриптирани канали).

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/ripedb-updates-openpgp-howto.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Управление на обекти в RIPE DB чрез X.509 идентификация

Vesselin Kolev — 2008-06-18T08:46:08Z

Документът описва добра практика по използването на X.509 подписани заявки за управление на обектите в RIPE DB. Особено внимание е отделено на начина на предаване на заявките по криптиран канал, с цел изключване на злонамерени повторения на заявки (каквато опасност има, ако се използват некриптирани канали).

Към момента този метод за удостоверяване не е използваем за RIPE DB (спрян е временно).

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/ripedb-updates-x509-howto.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Колизии на електронно подписани заявки "без билет" (с примери за RIPE DB)

Vesselin Kolev — 2008-06-18T08:46:08Z

Ще бъде разгледана система, която се състои от получател и изпращач. Изпращачът изпраща на получателя инструкции за изпълнение, оформени в съобщение, което се нарича заявка. Получателят изпълнява инструкциите на изпращача само тогава, когато заявките с инструкции са електронно подписани (без значение от сертификатния модел) и подписът върху тях бъде проверен. Проверката на електронния подпис става с помощта на сертификат, копие от който получателя има на разположение в някакво хранилище и са с установена идентичност. Изпращачът изпраща електронно подписаните заявки през среда, която може да бъде разгледана като "черна кутия" - т.е. знае се, че съобщението преминава през "кутията", но всички процеси, които водят до преминаването не са напълно известни и не могат да бъдат моделирани. Подобна среда, за която до известна степен може да бъде прието, че може да се моделира като "черна кутия", относно дадени процеси, е Интернет. При комуникация през тази среда на практика се идентифицира само съставителя на заявката, но не и нейния изпращач. Това значи, че всеки, който има достъп до средата, може да изпрати подписана от друг заявка. Интернет не може да идентифицира (само чрез механизмите за адресация) изпращача на заявки.

Примерите за реализация на колизии са за RIPE DB.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/no-ticket-signing.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

OpenPGP интеграция в Mozilla Thunderbird

Vesselin Kolev — 2006-12-05T08:46:08Z

Документацията разглежда използването на OpenPGP в Mozilla Thunderbird чрез приставката Enigmail.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/documentation/thunderbird-openpgp/index.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

OpenPGP интеграция в RPM

Vesselin Kolev — 2008-06-19T08:46:08Z

RPM е пакетна система, в която всеки пакет подлежи на интеграция в рамките на сертификатен модел за удостоверяване. За удостоверителен модел е избран OpenPGP. Когато един RPM пакетен файл бъде създаден, съдържанието му се подписва така, че електронния подпис се поставя вътре в създадения RPM файл (това отличава пакетната система RPM от пакетни системи, при които електронния подпис се съхранява във файл извън пакета). Така електронният подпис следва пакетния файл навсякъде и служи за идентификация на лицето или организацията, която е произвела пакета. Възможно е електронният подпис да бъде извършен и от този, който предоставя/дистрибутира пакета (благодарение на възможността за реподписване на пакета), а не от създателя му (при реподписването, електронния подпис на създателя на пакета може да бъде заменен с електронния подпис на дистрибутора).

Когато един RPM пакет трябва да бъде инсталиран, е наложително да бъде проверен електронния подпис интегриран в него. Създаването на таква практика силно намалява възможността за подмяна ("пробутване" на опасен пакет, който примерно може да отвори дупка в сигурността на системата, да унищожи файлове, да използва несанкционирано ресурси и т.н). Разбира се, инсталиращият пакета трябва да притежава копие от OpenPGP сертификата на лицето и организацията, които са подписали пакета. От гледна точка на сертификатния модел OpenPGP, не е достатъчно проверяващия електронния подпис просто да притежава копие от сертификата. Той трябва да е убеден в неговата автентичност. Следователно трябва да съществува канал за проверка на автентичността - примерно представител на дистрибутура гарантира за сертификата или пък да се ползва схемата на онаследено доверие в рамките на Web Of Trust (тази схема няма да бъде коментирана тук).

Сертификатното хранилище на базата на RPM няма нищо общо със сертификатното харанилище на други приложения, по-специално GNUPG. Проверката в рамките на Web Of Trust се прави в рамките на GNUPG и неговото сертификатно хранилище и чак след това удостоверения сертификат се прехвърля в RPM базата с OpenPGP сертификати.

Настоящата статия има за цел да покаже възможностите за интеграцията на сертификатния модел OpenPGP в пакетната система RPM. По-задълбочени познания за пакетната система RPM могат да се получат от различните документации на тази тема, като повечето от тях са свободно достъпни в Интернет. Към настоящият момент най-пълното ръководствто за потребители по използване на пакетната система RPM е създадено в рамките на проекта по документация на дистрибуцията Fedora [2].

Статията е фокусирана върху работата с пакетната система RPM в рамките на дистрибуциите Fedora Core и Red Hat Enterprise Linux.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/RPM-OpenPGP-FC_RHEL.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Подписване на RPM пакети

Vesselin Kolev — 2008-06-19T08:46:08Z

Статията представялва ръководство за електронно подписване на RPM пакети с OpenPGP, а така също описва начините за проверка на електронното подписване и целостта на инсталираните пакети.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/RPM-signing.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

OpenPGP подписано съдържание в XHTML

Vesselin Kolev — 2008-06-19T08:46:08Z

Електронното подписване на XHTML документи решава проблема за автентичността на съдържанието, който не може да бъде решен чрез протокола SSL (използван в HTTPS). При една HTTPS сесия се удостоверяват само страните, обменящи си документи, но не и самите документи. Казано по друг начин, SSL удостоверява и защитава сесията за пренос на данни, но не удостоверява самите данни, а само указва, че техния поток идва от определен, удостоверен, източник.

Този документ има за цел да опише един възможен начин за OpenPGP подписване на съдържанието на XHTML документи с цел удостоверяване на съдържанието им. Начинът на извършване на подписването, описан по-долу, засяга само съдържанието, което се намира в елемента BODY и не обхваща това в елементите XML, HTML, HEAD и др. Реално погледнато, съдържанието в BODY е визуалното съдържание, което потребителя вижда и обработва (например отпечатва). Следователно неговото подписване решава задачата за проверка на източника на информацията в BODY. Документът няма претенциите за първичност, нито описва добра практика. Той само описва едно възможно решение, което трябва да се прилага само в случаите, в които има ясно разбиране за приложимостта му. В Интернет има документи, които описват подписването на HTML документи, но те или не отчитат XHTML синтаксиса, или с тяхна помощ не е възможно да се получи валидируем изходен код на подписаната страница със съдържание.

Описанието в документа съблюдава правилността на XHTML синтаксиса и метода на подписване на съдържанието е такъв, че да позволява изработването на валиден XHTML 1.0 Strict и XHTML 1.1 код на подписаните страници.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/openpgp-signed-html.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Изпълнение на процесите на Sendmail с права на непривилигерован потребител

Vesselin Kolev — 2008-06-19T08:46:08Z

Има различни описани техники, чрез които да се заставят процесите на Sendmail в локалната система, да използват правата на непривилигерован потребител. Повечето от тях са сложни за реализиране от страна дори на системни администратори с опит, а най-лошото е, че често влизат в противоречие с актуализациите на пакета sendmail, който идват от дистрибутивното хранилище. Целта на тази статия е да покаже начин на стартиране на процесите на Sendmail с права на непривилигерован потребител, който да е максимално съвместим с логиката на актуализация на пакетите в една Linux дистрибуция. Основният фокус е върху Red Hat Enterprise Linux и производните му (CentOS, Scientific Linux и др).

Най-често се препоръчва схема на стартирането на sendmail демона в chroot. След това в конфигурационния файл sendmail.cf (който също е в chroot средата), се указва потребител и група, с чиито права ще се изпълняват процесите на Sendmail. Тази схема е напълно ненужна при наличието на SELinux. Нещо повече, тази схема е дори опасна, защото при нея се налага в chroot средата да се копират библиотеки от пакета glibc. В даден момент от живота на системата може да се получи ситуация, при която в chroot средата има файлове от старата версия на пакета glibc, който са потенциално опасни, а в системната среда има по-нова, актуализирана версия на glibc (същото касае и файловете от пакета sendmail). Това може да открие пътя за злонамерено използване на тази разлика във версиите. От друга страна няма еднозначно решение как при пакетно обновяване да се "изравни" chroot средата със системната, от гледна точка на библиотеки, изпълними файлове, конфигурационни и директорийни промени и др.

Вторият тип схема, при която процесите на Sendmail се изпълняват с права на непривилигерован потребител, включва промяна на правата върху директорията /var/spool/mqueue (писане и четене за непривилигерования потребител) и промяна на правата върху конфигуационните файлове (писане и четене за непривилигерования потребител). Обикновено конфигурационните файлове на Sendmail в Red Hat Enterprise Linux се намират в директория /etc/mail. След това в конфигурационния файла sendmail.cf се указва потребителя и групата, с чиито права ще се изпълняват процесите на Sendmail. Това е достатъчно за използване на схемата.

Втората схема обаче, влиза в тотално противоречие с пакетната система. RPM пакетите за Sendmail са направени така, че задават права върху служебните файлове и директории на демона sendmail. Дори администраторът да смени тези права в полза на непривилигерования потребител върху локалната система, след пакетна актуализация на Sendmail, ще се възстановят оригиналните права върху служебните файлове и директории (разбира се, няма да се промени sendmail.cf), което означава, че процесите на демона, които се изпълняват с права на непривилигерован потребител няма повече да могат да пишат и четат на и от съответното място на файловата система, което пък ще провали услугата.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/sendmail_non_root.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

LDAP базирано управление на пощенските концентратори на мрежата на СУ "Св. Климент Охридски"

Vesselin Kolev — 2008-06-19T08:46:08Z

Управлението на Sendmail в ролята му на MTA (Mail Transport Agent) се извършва централизирано с помощта на свързването на демона sendmail към LDAP директорийна услуга.

Целта на този документ е да опише интеграцията на пощенските концентратори на Софийския Университет "Св. Климент Охридски" с LDAP директорията, в която са въведени параметрите на мрежовите услуги. Дадени са подробни описания на LDIF шаблоните, с които се извършва създаване, промяна и премахване на записи от LDAP директорията.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/mailhubs-sunet-ldap.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Принцип на действие на пощенските концентратори на мрежата на СУ "Св. Климент Охридски"

Vesselin Kolev — 2008-06-19T08:46:08Z

Пощенските концентратори на мрежата на Софийския Университет "Св. Климент Охридски" са SMTP сървъри, които са обект на стриктна поддръжка и наблюдение от страна на квалифициран за целта персонал. Замисълът на изграждането им е цялата входяща електронна поща за пощенски домейни, чиито сървъри за крайна обработка на електронна поща (доставката по кутиите на потребителите), са в мрежата на СУ, да преминава през концентраторите. По този начин се избягва риск от пробив в сървъри за електронна поща, които не са обект на квалифицирана техническа поддръжка и постоянно наблюдение (повечето факултетски сървъри за електронна поща). Евентуален пробив би могъл да бъде използван злонамерено за разпращане на нежелана електронна поща (SPAM), което от своя страна би довело до регистриране на хостове от мрежата на СУ (AS5421) в различни "черни" списъци на SPAM излъчватели и това да препятства нормалния процес на изпращане на електронна поща от тези сървъри (или от всички университетски сървъри, ако в "черния" списък попадне цялото мрежово адресно пространство на AS5421).

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/mailhubs-sunet.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Настройки на пощенските концентратори на мрежата на СУ "Св. Климент Охридски" за работа с IPv6

Vesselin Kolev — 2008-06-19T08:46:08Z

Пощенските концентратори на мрежата на СУ (AS5421) са IPv6 базирани. Целта е те да осигуряват двупротоколна адреса SMTP услуга, в духа на пълна IPv6 интеграция на мрежата на СУ. По-долу е описано какви опции са използвани за IPv6 интеграцията.

Linux дистрибуцията, която пощенските концентратори на мрежата на СУ използват, е Red Hat Enterprise Linux 5. В състава на тази дистрибуция пакетът sendmail е компилиран с поддръжка на IPv6, което свежда IPv6 интеграцията на SMTP услугата, базирана на схемата с използване на концентраторите, само до въвеждане на съответните конфигурационни опции.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/sendmail-ipv6.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Ръководство за подписване на съдържанието на зоната на домейна uni-sofia.bg

Vesselin Kolev — 2008-06-19T08:46:08Z

Целта на този документ е да бъде кратко ръководство за подписването на зоната на домейна uni-sofia.bg, която се редактира върху сървъра за имена ns.uni-sofia.bg. С малки промени това ръководство може да се използва за подписване и на други зони на домейни.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/dnssec-zone-signing.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Заявяване на авторство върху свободно съдържание чрез удостоверение за време

Vesselin Kolev — 2008-06-06T08:46:08Z

Удостоверяването на време е услуга, която се предоставя в частна или обществена полза от съответния за това доставчик. Същността й се състои в издаване на електронен подпис от страна на доставчика върху изпратен му от заявителя хеш, при което в електронно подписания блок информация, който се връща на заявителя, освен хеша се указва и точното време на извършване на подписването. Върнатият към заявителя електронно подписан блок, съдържащ служебна информация, хеша на заявителя и точното време на електронното подписване, се нарича удостоверение за време. Доставчикът на услугата още се нарича "удостоверител на време" или "издател на удостоверение за време". За да може да предоставя услугата, той следва да разполага с универсален източник на време, репериран и отчитащ UTC.

В детайли услугата функционира по следния начин. Заявителят изчислява хеш на някакво съдържание, с използването на стандартизирана хеш функция (към момента това е SHA-1). След това влага изчисления хеш в специално форматиран блок информация и го изпраща към системата на издателя на удостоверения за време. Изпратеният блок се нарича заявка за издаване на удостоверение за време. Издателят проверява заявката за коректност (най-вече синтактична), прибавя към нея точното време в момента на подписването и допълнителни полета с информация, извършва електронен подпис върху така форматирания блок и го връща на заявителя. Полученото от заявителя е удостоверението за време.

За какво служи издаденото удостоверение за време и каква документна стойност има то? Удостоверението за време служи само и единствено като свидетелство, че към момента от време, отбелязан в него, на заявителя е бил известен хеш с някаква стойност, описана в удостоверението. Самият удостоверител на време по право не е виждал съдържанието, от което е изчислен хеша. Предполага се, че той е изчислен от заявителя, но ако следва да бъдем детайлни, би следвало да споменем, че това не е задължително, защото е възможно друго лице да е съобщило хеша на заявителя и последния да го е вложил в заявката изпратена до удостоверителя. Възможно е дори заявителя да е измислил някакво N-битово число, което да съответства като разред на резултата от използването на някоя от стандартните хеш функции и да го е заявил, кото значи, че дори не е нужно на числото, представляващо хеша, да съответства някакво съдържание. Последното обаче не носи никаква практическа стойност.

Казаното по-горе все още не обяснява в детайли точно и ясно документната стойност на удостоверението за време, затова е нужно да бъде обяснена чисто практическата полза от него. Да си представим, че някой трябва да докаже пред съд или друго физическо или юридическо лице, че някакъв блок информация е съществувал преди някаква дата, час, минути и секунди. За целта той следва да е изчислил хеша на това съдържание и да е издал удостоверение за време, преди датата, часа, минутите и секундите, за които ще се доказва давността. Ролята на удостоверителят на време в цялата схема е като независима страна да даде гаранции, че наистина на заявителя е бил известен въпросния хеш преди някаква дата, час, минути и секунди. Тези гаранции той дава чрез електронния си подпис, извършен върху заявката, в която се добавя и точното време на подписване. За доказване на давността се изисква проверка на валидността на удостоверението за време, която е на два етапа. В първия етап се проверява валидността на електронния подпис на удостоверителя (издателя) върху съдържанието на удостоверението, като за целта се изисква копие от съответния удостоверителски (издателски) сертификат и лиспа на данни, че частния ключ към него е бил разкрит (проверява се чрез публикуван CRL списък). Ако при първия етап е потвърдена валидността на удостоверението, се пристъпва към втория етап. Вторият етап изисква да е достъпно копие на съдържанието, за което хеша е изчислен и което е обект на доказване като давност. След това заинтересованото от уставяване на давността лице или организация, изчислява хеша и го сравнява с този публикуван в удостоверението. Ако изчисления и публикувания хешове са равни по стойност, то се приема, че преди някаква дата, час, минути и секунди, съдържанието е съществувало. Това приемане е ключа към документната стойност на удостоверението за време.

Това, че някой е заявил хеш на съдържание за влагане в удостоверение за време, все още не доказва неговото авторство върху съдържанието. На практика удостоверението за време не е документ за авторство или собственост върху съдържанието, а и няма целта да направи това. Когато удостоверенията за време се използват за установяване на авторство, те удостоверяват не самото съдържание, а стойността на електронния подпис върху него. Идеята е следната. Заявителят извършва електронен подпис върху съдържанието (все едно дали електронният подпис ще е вложен или отделен от съдържанието). След това изчислява хеша на съдържанието с електронния подпис и именно него подлага на удостоверяване по време. В този случай удостоверяването за време указва, че преди някаква дата, час, минути, секунди е съществувал електронен подпис върху съдържанието. Ако никой не успее да представи електронен подпис върху съдържанието с по-задна дата и няма други документи за авторство, то заявителя следва да се счита за автор на съдържанието.

Подобен механизъм на определяне на авторство ползва изключително много творците на свободно съдържание, чиито творби са обект на некоректно използване от страна на различни търговски организации, в разрез с лиценза за разпространение и използване на съдържанието. Чрез удостоверение за време те могат да доказват авторството си върху свободно разпространяемо съдържание (например "Снимка: Интернет"). Авторите следва възможно най-бързо след създаването на произведението си, да го подпишат електронно и след това да издадат удостоверение за време за извършения електронен подпис. Всеки автор следва да пази оригиналното съдържание, електронния подпис, обект на удостоверението за време, и издаденото удостоверение. Само чрез тези три елемента на процеса по удостоверяване на съдържанието, може да бъде заявявано авторство на база на давност.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/protect_free_content_distribution.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Възможности за сертификатната измама в X.509

Vesselin Kolev — 2008-06-22T08:46:08Z

В рамките на сертификатния модел X.509 се следва йерархична структура, която представлява пирамида на доверитето. На върха на пирамидата стои един единствен (въховен) удостоверител. Възможно е в йерархията да има още удостоверители, но всички те са подчинени на върховния удостоверител.

Всеки, който е удостоверяван в рамките на пирамидата на доверие е директно или индиректно удостоверяван от върховния удостоверител. Индиректното удостоверяване става чрез подудостоверител, но на практика той е удостоверяем от върховния удостоверител и така пак схемата на доверие започва от върха.

Всеки публичен ключ има свой хеш за проверка, който може да бъде изчислен чрез някой от най-често използваните за целта алгоритми (например MD5 и SHA1). Основата на всеки X.509 сертификат е публичния ключ заложен в него. Следователно, ако се знае сумата за проверка на публичния ключ, който е основа на сертификата, по някакъв независим път, то може да се провери дали копието от дадено копие на сертификата е оригинално или е фалшифицирано.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/x509_fraud.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Изграждане на IPv6 свързаност за Софийския Университет "Св. Климент Охридски"

Vesselin Kolev — 2008-07-27T08:46:08Z

Заявяването на IPv6 адресно пространство за краен потребител към настоящия момент не е тривиална задача, поне в региона на действие на RIR RIPE. Причината е, че към момента регионалния интернет регистър (RIR) RIPE приема заявки за алокиране на IPv6 мрежови адресни пространства само и единствено от LIR (локални интернет регистри). Тази политика на алокиране е описана в RIR документа "RIPE-421", който е публично достъпен на адрес:

http://www.ripe.net/ripe/docs/ripe-421.html

От съдържанието на документа става ясно, че за да получи IPv6 алокация директно от RIR RIPE, субектът Софийски Университет следва да бъде LIR и да се наеме с раздаването на IPv6 адресно пространство с дължина на мрежовата маса от 32 бита. Придобиването на LIR статус от страна на Университета е финансово неоправдано, а освен това не са налице функции на LIR, който биха били поети, ако бъде получен такъв статус. От друга страна адресно пространство с дължина на мрежовата маска от 32 бита е прекалено огромно и не си заслужава да бъде "погребвано" в организация, която никога няма да може да го използва и на 1%. Да не говорим за изискването, според което в ролята си на LIR Университета би следвало да се ангажира да раздаде поне 200 IPv6 адресни субалокации с дължина на мрежовата маска 48 бита за свои клиенти (!).

Причината, поради която RIR RIPE не извършва директна алокация на IPv6 пространства за крайни потребители (както това е в IPv4), е че няма все още общоприета регионална политика за извършване на "PI" алокации в IPv6. Към момента обаче има предложение за документ, съгласно който в бъдеще подобно PI алокиране би било реално:

http://ripe.net/ripe/policies/proposals/2006-02.html

Към момента на написването на тази документация предложението все още не е получило статус на официален документ на RIR RIPE.

От написаното по-горе следва, че за момента няма адекватна и обслужваща нуждите на Университета процедура, чрез която да се алокира IPv6 адресно пространство. В документа е описан един възможен и работещ компромис за non-LIR IPv6 алокация.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/depl_ipv6_in_su.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Сигурна електронна поща с Mozilla Thunderbird и X.509 сертификати

Vesselin Kolev — 2008-10-26T08:46:08Z

Статията представлява подробно ръководство за работа с X.509 сертификати в Mozilla Thunderbird.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/mozilla_ssl_x509.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Създаване и употреба на криптирани CD и DVD носители

Vesselin Kolev — 2009-01-04T08:46:08Z

Твърде често в новинарските емисии се появяват съобщения за изгубени лични данни на клиенти на банки, застрахователни агенции и други. Ако изгубените носители на информация, съдържащи лични данни попаднат в престъпни ръце, това създава огромен риск за гражданите, фирмите и дръжавните институции. С откраднати лични данни могат да бъдат извършени редица престъпни дейности като пране на пари, незаконно прехвърляне на движимо или недвижимо имущество, застрахователни и данъчни измами и др. Всичко това може лесно да се предотврати, ако лични или изобщо важни данни, се пренасят в криптиран вид не само през Интернет, но и чрез информационен носител (най-често CD или DVD диск).

В съвремените условия на лесен и евтин достъп до клъстери с голяма изчислителна мощност, няма място за използване на "слаби" криптографски алгоритми. Именно затова винаги следва да се използват най-сигурните и неразбиваеми към момента криптографски алгоритми и хеш функции. В изложението по-долу са дадени примери с използването само на сигурни и надеждни криптографски алгоритми и хеш функции.

Предимството на криптирания CD или DVD носител е, че дава директен достъп до криптираната информация, което спестява време. За да се направи съпоставка, нека опишем стандартния случай, при който не се създава ISO изображение, а цялото криптирано съдържание е в някакъв файл. Ако например по този стандартен начин се криптира директория, това трябва да стане на две стъпки: (i) създава се архив, например tar или zip и (ii) полученият архив се криптира. Следователно за да може след това да се достъпи даден файл от криптираната директория, трябва да се декриптира целия архив. За архив с големина от няколко гигабайта, дори при съвременната процесорна мощ, това е дълъг и енергоемък процес. В противовес на това е криптираното ISO 9660 изображение. При него криптирането и декриптирането са поточни процеси и след като дадено криптирано ISO 9660 изображение се монтира като файлова система, достъпа до файловете и директориите в него е изключително лесен и сравнително бърз.

Документът е предназначен за всички организации боравещи с лични данни и съхраняващи ги или пренасящи ги върху CD или DVD носители. Примерите са реализирани върху операционна система Linux (ядро 2.6.18), дистрибуция Red Hat Enterprise Linux 5, съотв. CentOS 5, но почти без никаква промяна са приложими и върху други Linux базирани дистрибуции, които имат поддръжка на dm-crypt. Представените рецептури са обобщение на добрите практики за работа с dm-crypt при създаването и употребата на крипитани ISO 9660 изображения, публикувани в Интернет.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/encrypted_cd_dvd.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

VLAN_PLUS_VID/VLAN_PLUS_VID_NO_PAD указвания за 802.1q интерфейси в RHEL5 и дериватите му

Vesselin Kolev — 2009-01-06T08:46:08Z

Съгласно официалната документация на Red Hat Enterprise Linux 5 и дериватите му (CentOS 5, ScientificLinux 5), 802.1q (VLAN) базиран интерфейс следва да се именова с т.нар. "DEV_PLUS_VID" конвенция на инструмента vconfig, която може да се илюстрира с примера:

				eth0.100

в който eth0 е името на физическия интерфейс, членуващ в съответния VLAN, а 100 е номера на виртуалния LAN (VLAN ID идентификатор). Конкретно, тази конвенция за именоване е посочена като единствено възможна в документацията към пакета initscripts. Във файла

				/usr/share/doc/initscripts-<version>/sysconfig.txt

е записано следното:

					Ethernet 802.1q VLAN items:
    						 DEVICE=eth0.42
       						Initscripts use DEV_PLUS_VID_NO_PAD naming mode for VLAN
       						devices. 
               					Example: eth0.42 for vlan 42 on device eth0.
       					Valid VLAN ID range is 0-4095. Most ethernet switches reserve
       					VLAN ID 1 to be used as management VLAN; starting from VLAN
       					ID 2 is recommended.

Ако се разгледа обаче по-внимателно съдържанието на самите инициращи скриптове, става ясно, че няма никакви проблеми да се използва и конвенция за наименоване на 802.1q интерфейси, а именно VLAN_PLUS_VID или VLAN_PLUS_VID_NO_PAD. По-долу в статията е описано как да стане това без да се излиза от добрата практика на администриране на системи базирани на Red Hat Enterprise Linux 5 и дериватите му.

Статията е достъпна в пълен обем на адрес:

http://www.vesselin.org/papers/xhtml/vlan_interfaces_rhel.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Изграждане на блог агрегатор, предотвратяващ събиране на социограми

Vesselin Kolev — 2009-01-25T13:41:31Z

Прочита на съдържанието на блогове или други подобни ресурси (напр. форуми), се улеснява изключително много от наличието в тях на RSS емисии или Atom. Това са стандартни методи за синтезирано извличане на съдържание и уведомяване на читателите за прибавянето на ново. Всеки блог има тематика, а контролът над съдържанието му е твърде труден, а понякога и невъзможен, доколкото най-често той домува на място с чужда юрисдикция. С нарастване на влиянието на блогосферата, се засилва и стремежа на някои заинтересовани кръгове да следят не само издателите на блогове, но и техните читатели. Това особено важи за блогове с екологично и политическо съдържание. Следенето се улеснява неимоверно много на база на наредби за събиране на трафични данни. Ако събраните данни бъдат анализирани, за всеки един потребител може да се получи социограма, чрез която да се определи политическата му ориентация, дали подкрепя екологичните и антиправителствени протести и др. В едно достатъчно недемократично общество тази информация може да се използва срещу гражданите. Именно затова следва да бъдат разработени и реализирани технологии, които да им помагат безопасно да четат информация от блогове и подобни ресурси, без при това да се излагат на опасност от преследване заради тяхната политическа принадлежност, екологично мислене, желание за протест и др.

Как се съставя социограма на основата на четене на блогове? Много често хората си мислят за социограмата като за дървовидна структура, свързваща ги на различни структурни нива с техни близки, познати, приятели и т.н. На практика социограмата е обект с по-широко съдържание. Тя може да включва и политическата принадлежност на гражданина, интересите му към определен род информация и т.н. Такава социограма се прави най-лесно на основата на трафични данни и тук ще бъде показано принципно как става това, за частния случай на HTTP достъпа. Ако трафичните данни за активността по протокола HTTP бъдат съхранявани, то в тях се съдържа не само името на сървъра, който потребителя достъпва, но и името на достъпвания ресурс на самия сървър. Например:

http://blog.example.com/political/node1.html

Ако даден ресурс има рейтинг в шаблона за изграждане на социограмата, който го определя като блог с определена политическа ориентация, то е вероятно читателя му да я споделя. Ако той чете още поне 2 блога с подобна насоченост, вече може да се каже с голяма вероятност каква политическа ориентация има. При това на основа на достъпвания ресурс може да се провери какво съдържание е достъпвано, без да се налага то да влиза в състава на събираните трафични данни - просто при анализа записания URL се достъпва с обикновен браузър.

Доколкото RSS емисията е част от съдържанието на даден блог, то описанието на изтеглянето й в трафичните данни, служи на анализа по същия начин, по който и информацията за директния достъп чрез браузър. Например, изтеглянето на RSS емисията на даден блог, може да е описано в трафичните данни като достъп до URL

http://blog.example.com/political/rss_feed

Следователно от особена важност за препятстване на събирането на информация за посещаемостта на блогове по трафични данни, е да се скрие URL информацията или ако не може да бъде скрита, да се предлага на един адрес заедно с огромен брой друга разнородна информация, от анализа на която не може да се каже нищо конкретно за конкретните й читатели (например агрегиране на несъвместими по своите политически възгледи блогове).

Дори в трафичните данни да не се описват HTTP URL стойности, то ако даден блог или подобен ресурс използват самостоятелен IP адрес, несподелен с други подобни ресурси, идентификацията на IP адреса на сървъра е достатъчна за да се определи какво точно посещава дадения потребител.

Всъщност не само проблема с трафичните данни е този, който агрегатора с предложената по-долу конструкция трябва да преодолее. Никой не може да гарантира, че данни за активността на един или друг потребител не се събират от журналните файлове на уеб сървърите, които обслужват блог приложенията. Съществуват множество фирмени блогове, които използват какви ли не тактики за проучването на потребителите си и заливането им след това с нежелани оферти, "префенциални" цени или откровено изнудване. Ето една проста схема - потребител се регистрира в електронен магазин. IP адреса му в почти всички случаи се описва в някаква база от данни. След това потребителя преглежда фирмения блог, блог на работещ в същата фирма или просто агрегатора на форум, в който се обсъждат продуктите на фирмата. Съвсем лесно е на база на IP адреса посетил блога, да се претърси базата от данни на електронния магазин, да се идентифицира потребителя и според разглежданата тематиката в блога, да се генерира съответния целенасочен SPAM и т.н.

Докато трафичните данни са донякъде законово регламентирани, използването на данни за потребителя с търговски цели, като посоченото горе, е невъзможно за контрол, трудно доказуемо е и в повечето случаи нанася вреди на крайния потребител.

Целта на тази статия е да покаже принципна схема за изграждането на блогов RSS агрегатор, който да предлага на своите посетители възможност да изтеглят дадена RSS емисия от колекция с емисии, без при това да може да се разкрие коя точно емисия е изтегляна и от кой посетител.

Създаване, управление и използване на LUKS дялове

Vesselin Kolev — 2009-04-10T18:28:44Z

Защитата на информацията върху информационни носители от кражба е дефакто задължителна за всеки, който работи с чувствителна информация. Скандалите с изгубване на лични данни върху служебни лаптопи станаха твърде чести, а щетите от тях са огромни. При това достояние на обществеността стават само някои от случаите на загуба или кражба на данни. Други или не са оповестени или дори не са установени, защото информацията е била открадната чрез копиране. Особено опасни са кражбите на носители с данни, представляващи финансова и военна тайна. Въпреки казаното по-горе, е масова практика чувствителна и дори строго секретна информация да се разнася в явен и некриптиран вид или до нея да има безпрепятстван и несанкциониран достъп. Настоящата документация има за цел да предложи на всички заинтересовани (особено на държавните и финансови институции) документация за защитата на информация върху носители чрез използването на LUKS дялове. LUKS е съкращение от Linux Unified Key Setup. Повече информация би могла да бъде намерена на официалната страница на проекта или в Wikipedia.

LUKS дяловете всъщност не са истински дялове, а тип файлова система, но функционират като дялове, поради което за тях ще бъде използвана точно тази терминология. Целта на LUKS дяла е да скрие файловата система в него от неоторизиран достъп чрез криптиране. Често пъти за такива файлови системи се използва понятието "криптирани файлови системи" ("encrypted file systems"), което поне за случая на LUKS не е съвсем коректно. Причината е, че не се криптира файловата система, а дяла, в който тя е разположена. Освен това в LUKS дяла могат да се съдържат структури от по-ниско ниво на файлова система: софтуререн RAID и LVM.

Настоящата документация показва целия процес на създаване на LUKS дялове и използването им, като в добавка представя в детайли инсталационния процес на Fedora върху криптирани дялове. Обхватът е разширен чрез приложения, които да дадат допълнителна, макар и несвързана с LUKS информация, която може да е полезна на потребителя за разбиране на някои основни постановки в изложението.

Документацията е предназначена за сравнително напреднали потребители на дистрибуциите Fedora и Red Hat Enterprise Linux 5 (и дериватите му). Авторът не носи никаква гаранция за причинена загуба на информация или други щети, възникнали в хода на прилагане на описаните по-долу методики и операции.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/luks.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Използвани практики по BGP префиксна филтрация и префиксно описание

Vesselin Kolev — 2009-06-24T20:02:44Z

Към датата на написване на този материал, глобалната BGP таблица, отразяваща достижимите в IPv4 мрежи, наброява около 280 000 префикса, а тази за IPv6 - около 2000. Докато за тази, касаеща IPv6 мрежи е разбираемо да съдържа все още малък брой префикси, то основателен въпрос е защо таблицата за IPv4 пространството е толкова голяма. Отговорът на този въпрос нито е лесен, нито еднозначен.

Най-често се приема, че тъй като IPv4 адресното пространство е много популярно и използвано, на раздаващите го регистри им се налага да извършват огромен брой сравнително малки адресни алокации за крайните потребители, а малки алокации за много крайни потребители, водят до голям брой BGP префикси. Да, подобен процес е със сигурност една причина за големия обем на глобалната BGP таблица, касаеща IPv4 адресното пространство, но тя със сигуртно не е единствената такава.

Истинският въпрос, който много рядко се задава, е какво се случва с адресните алокации за крайни потребители, след като те бъдат алокирани. Казано с други думи, дали крайният потребител създава оптимален брой префикси за алокацията си или те са неоправдано много. Регистрите, които извършват алокации могат да контролират в някаква степен сегментацията на майчиното пространството, но дали такъв самоконтрол налагат крайните потребители върху префиксното описание на своята алокация. Печалната истина, която може да се види при анализ на глобалната BGP таблица в IPv4 е, че неправилното префиксно описание, което крайните потребители извършват върху своите алокации, води до увеличаване на глобалната таблица с може би 50%. Това неправилно описание се приема от техните транзитни доставчици, които го препращат към своите транзите и така, докато тези лошо префикси не станат част от глобалната BGP таблица, като я увеличават напълно излишно.

Целта на тази публикация е запознае крайните потребители - оператори на автономни системи, със съществуващите практики за префиксна филтрация и намаляване на намаляване на обема BGP префиксните описания, които те излъчват в глобалната BGP таблица (все едно дали това касае IPv4 или IPv6).

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/bgp_prefix_practice.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

"Машрутна полиция ли са IP регистрите" - коментар по "Използвани практики по BGP префиксна филтрация и префиксно описание"

Vesselin Kolev — 2009-06-26T18:23:02Z

Този коментар е по повод основателни въпроси и уточнения след публикуването на "Използвани практики по BGP префиксна филтрация и префиксно описание". Темата е "Машрутна полиция ли са IP регистрите". Описаното в този коментар отразява както личното становище на автора, така и практиката, наложена в системата за глобална маршрутизация в Интернет, наложена от транзитните доставчици, LIR субектите и крайните потребители на адресни пространства.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/bgp_prefix_practice_comment_1.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Конструкция на AS112 в мрежата на Софийския Университет "Св. Климент Охридски"

Vesselin Kolev — 2009-26-26T20:11:41Z

В рамките на IP адресното пространство версия 4 (IPv4), има адресни сегменти, които са отделени за частно (локално) използване. Това ще рече, че те не се маршрутизират глобално, а само локално, за локални (частни) цели. RFC3330 (първото указване е в RFC1918, а RFC3330 е по-обобщаващ документ, който прави "карта" на адресните сегменти за специално използване в рамките на IPv4 адресното пространство), указва кои от адресните пространства в рамките на IPv4 могат да бъдат използвани за частни цели. Такива са (представянето по-долу е в CIDR):

10.0.0.0/8
172.16.0.0/12
169.254.0.0/16
192.168.0.0/16

Уместен е въпросът "а след като всеки може да използва тези адресни пространства или част от тях, кой тогава извършва записите в съответната in-addr.arpa зона на домейна, отговарящ за съответното адресно пространство". Отговорът на този въпрос е "този, който оперира съответното адресно пространство за частни цели". Съгласно този отговор, всеки оператор, който използва адресен сегмент за частни цели (т.е. в споменатите по-горе група от адресни сегменти), трябва да изгради сървър за имена, който да се използва от хостовете, които достъпват адресно пространство за частни цели, за намиране на стойността на PTR ресурсните записи за всеки хост от частната мрежа. В най-простия случай това са хостовете от мрежата за частно ползване. В по-сложни мрежови топологии е възможна ограничена видимост между публични и частни адресни пространства и в този случай е необходимо не само хостовете от адресното пространство за частно ползване, но и хостовете от публичните адресни пространства да знаят кой е сървъра за имена, отговорен за съответната in-addr.arpa зона, за да могат да намират съответните стойности на PTR ресурсните записи за даден хост от адресното пространство за частно ползване. Доколкото всеки оператор на частна мрежа може да дефинира своя in-addr.arpa зона на домейн за използваното от него адресно пространство, то всеки такъв оператор може да изгради своя in-addr.arpa зона на домейн върху негов сървър за имена.

Горното може да се илюстрира с пример. Нека даден оператор използва адресно пространство 192.168.100.0/24. Той трябва да изгради зоната на домейна 100.168.192.in-addr.arpa върху свой сървър за имена и да направи съответните PTR ресурсни записи за хостовете в 192.168.100.0/24. Освен това трябва да направи така, че всички хостове от 192.168.100.0/24 да използват такъв сървър за имена, който да обслужва заявките именно към локалната за хостовете зона на домейн 100.168.192.in-addr.arpa, а не да ги насочва по обичайния за заявките в системата за имена в Интернет път, който да минава през кореновите сървъри за имена и от там през съответната йерархия.

Какво се случва обаче, ако даден хост комуникира с хостове от мрежа за частно ползване, но сървърите за имена, които използва, не извършват локално обслужване на заявки за извличане на стойността на PTR записа в съответния in-addr.arpa локален домейн, отговорен за мрежата за частно ползване? Тогава заявките следват йерархичната схема за имена и "излизат" в Интернет. Ако заявката попадне в йерархията, тя най-накрая ще стигне до сървърите за имена на IANA, които в глобален мащаб са отговорни за обслужване на in-addr.arpa домайните за адресните пространства за частно ползване. Тези сървъри за имена са:

prisoner.iana.org (192.175.48.1)
blackhole-1.iana.org (192.175.48.6)
blackhole-2.iana.org (192.175.48.42)

Ако всички масово използват глобалните сървъри за имена, отговорни тези домейни, то те ще бъдат затрупани със заявки, поради това, че използването на частни адресни пространства е много полулярно.

Това е актуализира версия на този документ. Основно са преработени почти всички раздели. Създадена е скица на BGP топологията. Премахнати са някои остарели като фактология части в текста. Изходният код на документа е вече XHTML 1.1.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/as112-in-su.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Техническа бележка: Анализ на некоректна филтрация на BGP префикси касаещи мрежовите алокации 79.124.0.0/18 и 79.124.64.0/19, извършена от БТК

Vesselin Kolev — 2009-26-29T10:21:28Z

Описана е некоректна префиксна филтрация на БТК, касаеща префикси с origin AS8877.

Бележката е достъпна в пълен обем на адрес:

http://vesselin.org/notes/xhtml/AS8866_AS8877_bad_BGP_filters.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Техническа бележка: Лоша BGP практика на AS8877 с оператор "Пауърнет Телекомюникейшънс"

Vesselin Kolev — 2009-26-29T10:21:28Z

Описана е лоша практика по префиксно описание на префикси с origin AS8877.

Бележката е достъпна в пълен обем на адрес:

http://vesselin.org/notes/xhtml/AS8877_bad_BGP_origins.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Техническа бележка: Лоша BGP практика на AS8877 с оператор "Пауърнет Телекомюникейшънс"

Vesselin Kolev — 2009-07-15T21:57:28Z

Целта на извършената актуализация е да направи член на рефлекторната схема маршрутизатор на Биологическия факултет на Софийския Университет "Св. Климент Охридски" и по този начин да се повиши качеството на свързаността към мрежите на останалите факултети и Интернет. Освен това, използваната версия на Quagga позволява обслужване на префикси с origin 32-битови номер на автономни системи.

Маршрутизаторът на Биологически факултет на СУ е BGP origin за IPv4 адресно пространство 62.44.109.0/24 и IPv6 адресното пространство 2a01:288:8007::/48. IPv6 префиксът се агрегира от граничните маршрутизатори на AS5421 към префикс 2a01:288:8000::/35 и ще подлежи на преномерация след получаването от страна на СУ на IPv6 адресен сегмент със статус "ASSIGNED PI".

Бележката е достъпна в пълен обем на адрес:

http://vesselin.org/notes/xhtml/bgp_reflector_su_update_15_jul_2009.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Използвани практики по BGP префиксна филтрация и префиксно описание

Vesselin Kolev — 2009-07-24T18:17:44Z

Това е нова версия (2.4.0) на статията "Използвани практики по BGP префиксна филтрация и префиксно описание", достъпна на адрес:

http://vesselin.org/papers/xhtml/bgp_prefix_practice.html

Прибавени са някои префикси, а също така и поддръжка на филтрацията на 32-битови ASN.

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

"Черна дупка" 192.0.2.0/24 в мрежата на Софийския Университет "Св. Климент Охридски"

Vesselin Kolev — 2009-07-30T19:42:28Z

Софийският Университет "Св. Климент Охридски", в рамките на мероприятията по подобряване на сигурността на своето и локалното българско интернет пространство, стартира проект за "черна дупка" 192.0.2.0/24. Терминацията на трафика към тази мрежа се извършва на сървър на Университета. Префиксът се излъчва към партньорите за локална свързаност на СУ.

Специалистите от направление "Мрежи и комуникации" се ангажират с безпристрастното и надеждно терминиране на паразитния трафик, без да използват ролята си в ущърб на друг субект в интернет пространството.

Бележката е достъпна в пълен обем на адрес:

http://vesselin.org/papers/xhtml/blackhole_192_0_2_0.html

Информация за RSS емисиите на http://vesselin.org, може да бъде намерена на адрес:

http://vesselin.org/xhtml/rss.html

Принципен проблем на префиксната филтрация в маршрутизиращия софтуер без поддръжка на 32-битови ASN

Vesselin Kolev — 2009-08-02T21:11:41Z

В рамките на мероприятията по подобряване на свързаността на Софийския Университет "Св. Климент Охридски" и внедряването на ключови нови технологии, граничните маршрутизатори на AS5421 вече обработват BGP префикси с origin 32-битов номер на автономна система.

Защо това не е излишна екстра, може да се види в раздел 2 на тази статия, но към казаното там може да се добави и следното. Регионалните интернет регистри (в частност RIPE за Европа), вече по подразбиране алокират 32-битови номера на автономни системи. Получаването на 16-битов номер на автномна система става само по изключение, след необходима обосновка пред регистъра. Следователно 32-битовите номера на автономни системи са дефакто вече стандарт и неподдържането им носи единствено и само минуси за съответния участник в глобалната маршрутизация, основана на протокола BGP4/4+.

От гледна точка на 32-битовите номера на автономни системи, използвани в протокола BGP4/4+, в Интернет има два типа машрутизатори: (i) такива, които могат да четат стойност на origin с такъв разред в информацията за префиксите и (ii) такива, които не могат да я четат (поддържат само 16-битови номера на автномни системи). На пръв поглед изглежда, че маршрутизаторите от втория тип не биха обработвали префикси, които имат за origin 32-битов ASN. На практика обаче, тази обработка протича, без отчитане на 32-битовия номер. Основателният въпрос в случая е как става това и каква стойност на origin се използва при обработката (ясно е, че в рамките на BGP няма как да се обработи префикс без атрибут origin).

За да се отговори на последния въпрос, не е нужно да се прибягва до подробно описание на разширението в протокола BGP за 32-битови идентификатори на автономни системи (въпреки, че е полезно да се знаят такива детайли от тези, които управляват маршрутизацията). Нужно е да се опише само най-общо принципа. А той е следният. Когато един маршрутизатор следва да бъде първоизточник на префикс с 32-битов номер на автономна система, той трябва да поддържа в своя софтуер за маршрутизация такъв разред за номерация на автономната система. Когато той формира информацията за префикса, в полето за origin винаги поставя 16-битовия идентификатор със стойност 23456, а в специално разширение към информацията за префикса, указва стойността на 32-битовия origin. Следователно информацията за префикса носи едновремено 16-битов и 32-битов номер на автномна система. По този начин префиксът може да се излъчи чрез BGP към всякакъв маршрутизатор, без оглед дали последния поддържа или не 32-битови номера на автономни системи. И причината за тази възможност е, че маршрутизаторите, които не поддържат 4-байтови ASN, четат само 16-битовото поле за origin. При преносът в рамките на глобалната система за маршрутизация, информацията за 32-битовия ASN не се премахва, а се запазва, но се чете и обработва само от тези маршрутизатори, които имат поддържка на такъв разред номера. Следователно не е нужно всички маршрутизатори по пътя на префикса да поддържат 32-битови автномни системи. Реално това е задължително само за този маршрутизатор, който е формирал префикса с 32-битова стойност на origin атрибута.

На база на обяснението по-горе става ясно, че разликата между маршрутизаторите (i) и (ii) е в това, че в информацията за BGP префикса, първите виждат 32-битовия ASN, а вторите виждат само 16-битовия ASN 23456. Казано по друг начин, (ii) сякаш виждат "маскирана" стойността на атрибута origin. Както ще стане ясно по-долу, това може да доведе до проблеми при филтрацията от страна на маршрутизатори без поддръжка на 32-битови номера на автономни системи, рефлектиращи в проблеми със сигурността на мрежата (локална и глобална).

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/xhtml/rss.html

Поддръжка на 32-битови ASN върху маршрутизаторите на AS5421

Vesselin Kolev — 2009-08-08T23:32:08Z

Съгласно препоръките на регионалният IP регистър за Европа, RIPE, всяка нова алокация на номер на автономна система за LIR или краен потребител, трябва да бъде 32-битово число. Подобна политика се налага заради изчерпването на блока от 16-битови номера на автономни системи. Детайли относно разпределението на номерата на автономни системи по регистри, могат да бъдат намерени на съответната страница на IANA.

Софийският Университет "Св. Климент Охридски" (СУ), като учебно заведение и същевремено участник в Интернет, следва да прилага и следва възприетите стандарти и норми на управлението на адресни и др. номерационни ресурси. В добавка на това, трябва да се спомене и ролята на Университета в обучението на специалисти по мрежи и комуникации. Особено второто задължава СУ да внедрява колкото е възможно повече нови технологии и особено тези от тях, които са важни за ресурсното управление в Интернет.

Друга основателна причина за поддръжка на 32-битови ASN, освен въвеждането им от регионалните IP регистри, е и филтрацията на префикси по техния origin. Описание на ползата от въвеждане на 32-битови ASN за нуждите на префиксната филтрация, може да се намери в статията "Принципен проблем на префиксната филтрация в маршрутизиращия софтуер без поддръжка на 32-битови ASN".

Поради изброените по-горе причини, екип на направление "Мрежи и комуникации" на УИЦ на СУ, въведе поддръжката на 32-битови номера на автономни системи в използвания в AS5421 маршрутизиращ софтуер. Оттук нататък, всеки нов маршрутизатор в AS5421, който получава и обработва пълната BGP таблица, ще поддържа 4-байтови ASN.

Статията е достъпна в пълен обем на адрес:

http://vesselin.org/xhtml/rss.html

Галерия: border-lozents.uni-sofia.bg

Vesselin Kolev — 2009-08-08T23:33:49Z

От 5 август 2009г., граничният маршрутизатор на AS5421 border-main.uni-sofia.bg е свален от употреба и на негово място е въведена нова хардуерна конфигурация, като името на хост е сменено съгласно новата мрежова топология на border-lozenets.uni-sofia.bg.

Новата хардуерна конфигурация е базирана на Dell PowerEdge 2650 и дарение от Nestle (огромни благодарности за дарението!!!). Параметрите на конфигурацията са налични на страницата на производителя. Целта на въвеждането в продукция на подобна конфигурация за граничен маршрутизатор, е увеличаването на степента на използване на каналите за свързаност на Софийския Университет "Св. Климент Охридски" и повишаване на качеството на свързаността, вкл. възможност за безпроблемен пренос на големи количества интерактивен трафик, свързан с поточна мултимедия, по-специално телефония (VoIP), DNS и др. Маршрутизаторът функционира в мрежовия възел на кампус "Лозенец".

Същата конфигурация е използвана за реализирана на машрутизатора loz-gw.uni-sofia.bg (домуващ също в кампус "Лозенец").

Галерията е достъпна на адрес:

http://vesselin.org/xhtml/rss.html

Галерия: Нискобюджетен маршрутизатор за факултетските мрежи в Университетската мрежа

Vesselin Kolev — 2009-08-12T18:35:17Z

В рамките на мрежата на Софийския Университет "Св. Климент Охридски", следва да бъде гарантирана алтернативната свързаност на отделните факултетски мрежи, които се намират зад своите локални маршрутизатори (шлюзове). Ако задачата за пълната резервираност трябва да бъде решена точно, следва да се използва информацията от BGP, синтезирана върху двата гранични маршрутизатора на AS5421: border-lozents.uni-sofia.bg и border-rectorate.uni-sofia.bg. На пръв поглед това би било сложна задача, защото се налага изравняване на огромно количество информация за маршрутите върху много маршрутизатори. От друга страна обаче, се оказва, че един персонален компютър, базиран на добър хардуер, би могъл да свърши работа. Обикновено организациите и работещите в тях мрежови инженери по навик използват за целта скъпи маркови маршрутизатори, но Университета не може да си позволи подобни разходи и затова се наложи да бъдат изградени нискобюджетни аналози. С тяхна помощ доставката на свързаност на факултетските мрежи бе опростена до BGP рефлекторна схема, в която се формира "пълна" BGP таблица и се разпространява от рефлекторните сървъри към маршрутизаторите на факултети - клиенти на рефлектора.

По-долу са показани снимки от конфигурация, предназначена за маршрутизатор на факултетска мрежа, генерираща максимален трафик от 10000 пакета в секунда. Дънната платка и използваните етернет адаптори биха могли да обработят повече от споменатия максимален трафик (може да се направи тест и това да се покаже), но на практика, поради различни причини, не се генерира поток пакети надвишаващ 10000 в секунда.

Само за сведение, процесорът на конфигурацията е Pentium III (Coppermine) с работна тактова честота 930 MHz, а оперативната памет е с капацитет 1GB (2x512MB SD-RAM). За твърд диск е използван IDE Flash модул - 2GB.

Галерията е достъпна на адрес:

http://vesselin.org/xhtml/rss.html

Презентация: Система за динамична вътрешна маршрутизация на Софийския Университет "Св. Климент Охридски", базирана на решения с отворен код

Vesselin Kolev — 2009-12-08T18:13:22Z

Система за динамична вътрешна маршрутизация на Софийския Университет "Св. Климент Охридски", базирана на решения с отворен код

Повод: OpenFest 2009 (лектор Николай Николов, УИЦ на СУ), 7 ноември 2009 г.

OpenOffice/Presentation: present-openfest-2009.odp [ електронен подпис | TimeStamp ]

PDF: present-openfest-2009.pdf [ електронен подпис | TimeStamp ]