Koнстантин Спиров

СИГУРНОСТ, ЗАЩИТА НА КОНФИДЕНЦИАЛНАТА ИНФОРМАЦИЯ И ЕТИЧЕСКИ ПРОБЛЕМИ В ИКТ

Курсова работа по “Информационни и Комуникационни Технологии “

10 юни 1998, версия 1.0c

Бележка в Internet версията: Материалите в тази курсова работа могат да бъдат свободно използвани от всеки, който пожелае. За да се свържете с мен, натиснете тук.

 

 

КЛЮЧОВИ МОМЕНТИ

Пробиви в сигурността. Видове атаки.

Защита на сигурността. Софтуерни технологии.

Спамингът и проблемите с неоторизираната реклама.

Дискусии около цензурата и конфиденциалността.

България и новите предизвикателства.

Списък с използвани книги и статии.

Нещо в заключение.

 

 

Пробиви в сигурността

Както беше изтъкнато по време на лекцията за Information Resource Management-а, информацията е ресурс, който трябва да бъде управляван строго и от който може да зависи успехът на един бизнес.

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

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

Читателят вероятно ще забележи, че следващата част от изложението прилича повече на наръчник по източни бойни изкуства, отколкото на курсова работа. Наистина, една от най-често споменаваните думи по-нататък ще бъде “атака”. Под “атака” ще разбираме опита за получаване на неоторизиран достъп до определени ресурси, независимо дали става въпрос за server, или просто защитена програма.

Под “пробив” в сигурността ще разбираме всяка софтурна или хардуерна особеност на дадена система, която позволява успешна атака.

Всеки пробив във сигурността може да бъде причислен към една от следните групи:

Пробиви от клас C: позволяват така наречените denial of service атаки. Този вид атаки дава възможност на отдалечените потребители да предизвикват временна неработоспособност на системата.

Пробиви от клас B: позволяват на потребител, вече регистриран в дадена система да увеличи своите права.

Пробиви от клас А: позволяват на външен потребител да придобие неоторизиран достъп. Това е най-опасният вид пробиви.

Scheme 1

Пробиви от клас C:

Възможността за denial of service атаки почти винаги се дължи на грешки в операционната система (по-точно в нейните мрежови драйвери) или в сървър софтуера. Подобни проблеми възникват в два възможни случая:

Случай 1 – съществува проблем, специфичен за операционната система или сървърa. След неговото локализиране, производителите почти веднага предлагат “кръпки”, оправящи грешката.

Случай 2 – проблемът е по-скоро при проектирането на даден протокол, отколкото при драйверите на операционната система или софтуера на сървъра. Често се проявява в множество различни операционни системи едновременно. Пробивите от клас C (случай 2), обикновено са по-тежни за затваряне и са решими само частично. Примери SYN flooding, mail bombing, ping атаки (виж по-надолу).

Ще дадем няколко примера класически denial of service атаки:

По-известни denial of service атаки в Windows NT:

  • Проблемът с порт 80 - открит в Microsoft Windows NT 4.0 с Internet Information Server версия 2.0. Решен в Internet Information Server 3.0 или Service Pack 1а. Достатъчно е потребителят да направи telnet към порт 80 на сървъра и компютърът "увисва".
  • Доста по-дълго време подобен проблем съществуваше и с портове 135 и 1031, но в този случай нападателят трябваше да изпрати две-три линии информация..
  • Проблемът в DNS (Domain Name Server-а) на NT 4.0 - оправен чак в Service Pack 3.0. Възможно е потребителят умишлено да пусне пакет, който не може да бъде обработен и това да предизвика спиране работа на DNS-a.
  • Проблемът с OOB (Out Of Band) TP/IP пакетите -- проявява се даже в Service Pack 3.0, този трик е използван от програмата WinNuke. Пращането OOB пакети към NetBios порта води до увисване с извеждане на "синия екран" (програмистът от Microsoft e решил, че подобни пакети са невъзможни и е вмъкнал assert в кода на драйвера).
  • Проблемът, открит в края на Юли 1997 година с Internet Information Server 3.0. Оказва се, че всеки потребител на Internet може да причини увисването на IIS, чрез пращане на дълго URL с точно определена дължина ("вълшебното число обикновено е 8192 байта).

Ping 'о Death атаките (ping -l 65510 host.ip) - проблем, открит не само в Windows NT 4.0 (до Service Pack 2), но и в socket драйверите на множество други платформи като MacOs 7.xx, Solaris 2.5 x.86, Minix 2.4, Windows '95 (до OSR 2), PCTCP за Windows 3.1, AIX 3 и 4, Linux (версия на ядрото до 2.024). Типична илюстрация на случай 2 в клас C пробивите - IP пакетите според RFC-791 могат да бъдат дълги до 65,535 (2^16-1) октета (при мрежовите стандарти се използва терминът октет вместо байт, т.к. в някои системи байтовете нямат осем бита дължина).

Пакетите, с дълбина по-голяма, отколкото може да бъде поета от транспортното ниво отдолу се разбиват на множество малки части, след което се реконструират от получателя. Максималната дължина на един такъв фрагмент (Maximum Transmission Unit, виж RFC-1063), варира в зависимост от показателите на мрежата, при Ethernet тя е някъде около 1500.

Ако от максималната дължина от 65535 се извадят осемте октета за ICMP ECHO request-a (RFC-792) и още двадесет октета заради header-а, получават се 65507 октета максимална дължина на данните. Да допуснем, че е получен пакет с дължина на данните 655010. При обратното реконструиране, шестнадесетбитовата променлива в която се държи отместването плюс дължината на текущия пакет се препълва. Тази грешка е открита в над осемнадесет различни платформи и често води до kernel dump-ове, забивания или рестартирания на системата.

Любопитно: Windows'95 държи своебразен рекорд сред клиенските платформи в максималната дължина на ping-а - тя е цели 65527 октета! Грешката е оправена чак в Windows'98, където за всеки случай е сложен лимит от 65500 октета.

При стари server-ски платформи, за които не се очаква да се появи patch, се използва следното решение - просто забраняване на фрагментираните ping-ове. Така системата все пак отговаря на ping-ове с по-обикновена дължина (стандартната е 64 байта).

SYN flooding атаките - в момента не съществува напълно задоволително решение за защита срещу този вид атаки, тъй като проблемът е по-скоро в дизайна на TCP/IP. Всеки Web, Mail или FTP server е потенциала мишена. Атаката се осъществява чрез създаване на огромно количество наполовина отворени връзки (отново имаме пробив от клас C, случай 2).

Преди да започнем с обяснението на SYN flooding-а, нека нека първо припомним няколко основни факта за TCP, които ще ни потрябват и при обясняването на IP Spoofing атаките. Протоколът TCP се използва при двупосочни връзки (процес със процес). За да се избегне грешната инициализация в началото и да се потвърди установяването на връзка, се използва техниката на така наречените последователни числа.

В началото, клиентът праща TCP пакет с определено число. TCP пакетът, който връща server-ът съдържа в отговор собственото му първоначално число и потвърждение -- числото на клиента плюс едно. Когато клиентът получи този пакет, той трябва да прати отново потвърждение -- числото на server-а плюс едно. Следователно за установяване на TCP връзка, трябват три пакета (за повече информация за TCP, виж RFC-793).

В този процес играят роля и флаговете SYN и ACK -- единият се вдига при инициализацията, вторият при потвърдението:

                Клиент                    Сървър
                ------                    ------
            N   SYN-------------------->

                   <-------------------- M N+1   SYN-ACK

          M+1   ACK-------------------->

SYN flooding-ът отваря бързо и многократно множество връзки от неверни, но съществуващи адреси. Server-ът изпраща обратно SYN-ACK пакета и разбира се не получава потвърждение. За съжаление timeout-a (времето, през което server-ът чака за потвърждение), не може да бъде твърде малък за да не се изолират географски отдалечените места.

SYN flooding-ът е успешен ако стекът на сървъра бъде препълнен преди да изтече първият timeout (след това server-ът започва да затваря връзките със същата скорост, с която сa отваряни от атакуващия компютър и SYN flooding-ът води единствено до забавяне на работата). При успех, обаче, server-ът изгубва способност да установява нови връзки (това не се отразява не вече съществуващите връзки). При някои стари server-и, където няма проверка за препълване, успешният SYN flooding води и до "увисване".

Срещу SYN fooding-а все още няма универсална защита, но практиката показва, че известно намаляване на timeout-а и увеличаване броя на socket-ите вършат работа. Допълнителна подсигуровка са евристични алгоритми, които при възникване опасност от препълване избират една от предишните непотвърдени връзки и я затварят.

Ping flooding атаки - лесни за практическа реализация, но понякога изключително досадни. Четири или повече процеса от атакуващия компютър правят непрекъсващи ping-ове, примерно с дължина 256 октета. SYN и ping flooding-ът обикновено се използва за атакуване на малките провайдери, и то през празничните дни, когато е вероятно да няма дежурен. В момента провайдерите от първо или второ ниво могат да проследят и изолират източници на подобни атаки за около 30 минути дори в случаите, когато данните за идентификация на потребителя и host-а, като netname полето, описано в RFC 1050 са подменени. Обикновено подобни видове flooding-и се правят през чужди shell account-и, тъй като (особено в US) вече има прецеденти на осъдени за подобни "игри".

Атаки чрез mail bombing - тривиална, но изключително често срещанa атака. Задръстване на пощенските кутии на определен потребител, чрез изпращане на дълги или многократни съобщения. Много от популярните email клиенти не могат да download-ват избирателно съобщенията. В такива случаи, получаване на съобщение с дължина около един мегабайт би могло да бъде истинско нещастие за начинаещия потребител (напредналият би влязъл с telnet na порт 110 и би изтрил на ръка съобщенията с DELE както е описанио в RFC-1081).

Mail bombing-ът е допълнителна неприятност и за малките Internet провайдери с бързи линии, където се плаща на трафик. Подобни mail bombing атаки се състоят в редовното абониране на root-а с помощтта на скрипт за максимално количество mailing листи без обратно потвърждение (за съжаление продължава да има твърде много такива), или даже black листи чрез пускане на множество фалшиви съобщения от името на root-а в любими за спамерите USENET групи като alt.test (за по-подробен анализ, виж главата за спаминга).

Пробиви от клас B

Най-известни пробиви от клас B са пропуските, позволяващи telnet базираните атаки.
Твърде много exploitet-и съществуват в момента за различни UNIX-и - едни са shell файлове, други са програми на C. Едни използват твърде "богатите" възможности на програмата sendmail, други "експлоатират" грешки в системните програми на UNIX (например липса на проверка за дължината на стринг при предаване параметри, водещо до препълване на буфера, инсталиращо точно точно определен код на точно определено място). Подобни програми са се появявали при почти всички стари версии на Red Hat и Slackware Linux, a с гордост можем да заявим, че и "ние сме дали нещо на света", виж например +AIX +"Georgi Guninski" в някоя система за търсене). Целите са: или потребителят да се добере до shadow-натия файл с паролите, след което да го разкодира с програма като Cracker Jack, или да се превърне директно в root (exploitet-ите на Гунински правят точно това).

Факт е, че вече десетки години клонингите на UNIX претендират за сигурност и надеждност и въпреки това непрекъснато се откриват подобни пробиви. Напоследък се забелязва тенденцията повечето Internet провайдери решават проблема с telnet базираните атаки по съвсем радикален начин -- забранявайки telnet.

Пример за пробив от клас B: преди около една година, когато клиентите на българския провайдер TTM влизаха в router-а (вървящ под AIX), е съществувала възможност да се направи talk или download с опция &sh, което е позволявало на всеки потребител да влезе в shell.

 

Пробиви от клас A

Пробиви от клас А, дължащи се на грешки в web server-и.

От примерите, които дадохме досега за denial of service атаки при web server-ите, читателят не трябва да остава със заблуждението, че грешките при програмирането на сървърите не могат да създават и по-големи опасности. Ще дадем няколко примера за пробиви от клас А причинени от подобни грешки -- тук вече външният потребител получава възможност да черпи информация за най-уязвимите части на дадена система и да подготвя директни атаки.

  • Netscape Communication Server for NT версия 1.12 не използва връзките между разширенията на .pl файловете и perl.exe на ниво File Manager. В бележките към продукта се препоръчва perl.exe да се държи в /cgi-bin директорията, а скриптовете да се викат така: /cgi-bin/perl.exe?&my_script.pl. По-късно е било забелязано, че този похват позволява на ВСЕКИ да изпълнява последователности от команди през perl.exe, например въвеждането на URL /cgi-bin/perl.exe?&-e+unlink+%3C*%3E би изтрило всички файлове в текущата директория на сървъра!
  • Проблем с .bat файловете под Windows NT 4.0. имплементиращи CGI скриптиве. За първи път открит от Ян Редфърн. Представете си следния съвсем прост .bat файл в /cgi-bin директорията:
    @echo off
    echo Content-type: text/plain
    echo
    echo Тest!.
    Колкото и да е странно, изходът от URL /cgi-bin/test.bat?&dir, показва накрая и резултата от dir (тъй като .bat файловете се пускат от command.com, дали това не е някакъв неуместен опит за наподобяване на UNIX от страна на командния интерпретатор на NT? :-) ).
  • Старите версии на Internet Information Server 3.0 позволяват на потребителя да вземе СЪДЪРЖАНИЕТО на на CGI скриптовете, когато слага точка на URL-то. Проблемът се появява, когато в скрипт директориите на файловете е сложено разрешение за четене (не само за изпълнение).

Податливост към IP Spoofing

IP Spoofing-ът е един от най-обсъжданите, на-популярните и най-малко разбираните методи за атака. Една от причините без съмнение е шумът, който се вдигна в US около залавянето и осъждането на Кевин Митник (приложил го за първи път в края на 1994 година). Сагата е описана най-подробно в известната книга на Джон Маркофф, а субективният (според някои пълен със журналистическо самохвалство и сатанизиране Митник) тон на книгата доведе единствено до обратния ефект -- превърна Кевин Митник в легенда. (Митник се превърна в мит :-) )

Длъжни сме да отбележим, че Кевин Митник съвсем не е измислил IP Spoofing-а.
IP Spoofing-ът е бил теоритично предсказан още през 1985 година от Робърт Морис от AT&T при изследване слабостите на BSD UNIX TCP/IP софтуера. Чак десет години по-късно Кевин Миткик успява за първи път да приложи успешно IP Spoofing-а на практика.

Три ключови момента е важно да се разберат за IP Spoofing-а: Тази техника е изключително трудна за практическо приложение, платформите, под които е възможна се броят на пръсти и е съвсем лесна за блокиране (виж RFC1948).

Тъй като целта на IP spoofing-а е външна машина да бъде припозната с trusted машина от вътрешната мрежа, необходимо е първо на истинския trusted компютър да бъде приложена deial of service атака като SYN flooding. Друг деликатен момент е налучкването на алгоритъма за избор на нови числа -- в точно определен момент атакуващият компютър трябва да отговори (вместо временно блокиралия) с точно определено последователно число. Освен това съвременните router-и просто могат да бъдат конфигурирани да отхвърлят пакети от Internet, претендиращи да идват от локалната мрежа.

Интересна модификация на идеята за spoofing атаките е така наречения DNS spoofing, за тази цел е необходимо кракерът да е "завладял" DNS машината. Подобен род атаки беше теоритично възможен например при работа с java applet-и, написани с JDK 1.0. За повече информация, виж например: Java Security: From HotJava to Netscape and Beyond," by Drew Dean, Edward W. Felten, and Dan S. Wallach.

 

Подадливост към атаки от тип "троянски кон"

Опасността от атаки от тип "троянски кон" може да се третира като пробив клас B (в случаите на web скриптове), и от клас А (при пускане на native code програми). Тази опасност обикновено се дължи не толкова на на самата компютърна система, колкото на грешки при проектирането на общата архитектура на сигурността (виж следващата глава).

Понякога обаче, както е при случая с WWW скриптовете, по обективни причини рано или късно се налага чуждите скриптове да работят на един от сървърите. Тогава най-важна е компетентността на оператора.

Троянски коне в web скрипт

Пускането некомпетентен администратор на web скриптове, съдържащи троянски коне е пробив клас B. Правилатата, които трябва се спазват са точно две: да се чете внимателно всяка линия от кода на скриптовете и да се не слагат в системите скриптове от съмнителни източници. И Perl, и Java обикновени езици за програмиране, а на програмите, интерпретирани локално е позволено всичко.

Троянските коне в native code

Въпреки че класическите троянски коне, пращани на ситемните оператори от времето на BBS-ите имаха непосредствено разрушително действие (каква по-типична denial of service атака), пускането на native code програми, пращани от външни потребители е пробив от клас A (в някои среди още се помни случаят с "хакнатия" българския програмист Т.T. комуникационен протокол MPT, разпространил се почти навсякъде из Софийските BBS-и и който при получаване на пакет с определена контролна сума отваря shell).

И до днес множество журналисти и начинаещи потребители не могат да правят разлика между компютърен вирус и троянски кон, макар че тя е очевидна -- компютърният вирус (както и червеят) се репродуцира, троянският кон се използва при атаки на конкретни системи. Компютърният вирус копира кода си в неизвестни предварително програми (или макроси), кодът на троянският кон се вмъква в точно определена програма.

Когато при програми, разработвани от големи екипи програмисти, един от тях успее умишлено вложи троянски кон без знанието на останалите, то той се нарича "тайна вратичка".

Забавно: през 1990 година, при въвеждаме на програмата за контрол на осъствията в една от столичните математически гимназии, софтуерът изисквал парола за достъп по избор директора (неизвестна дори за учениците, автори на програмата). Директорът добре си криел паролата и чак време на абитуренския бал научил с изненада от самите ученици, че определена комбинация от клавиши просто махала диалога "въведете парола" и влизала в главното меню.

По принцип новополучените програми никога не се пускат или проверяват на същия компютър, на който е Internet съвръра (също така, желателно е този компютър да е физически изолиран от локалната мрежа в колкото се може повече случаи). Често обаче, съвсем малките любителски Intranet системи и публични BBS-и, базирани на Fidonet технологията продължават да използват един и същи компютър.

 

Защита на сигурността. Софтуерни технологии.

От всичко, изложено дотук можем да си направим няколко важни извода. На първо
място -- съществуват твърде много начини за атака. На второ място -- програмистите грешат твърде много. И на трето място -- животът ни е твърде кратък.

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

Програми, които диагностицират системите за пробиви в сигурността се наричат скенери. Често скенерите са част от същия пакет, в който е и firewall-ът.

Защита на сигурността чрез firewall

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

Една от изгодите при използване на firewall е ясна -- избягване на опасностите, описани в предишната глава. Важно е да се отбележи, че добрата защита на една корпоративна система никога не означава пълна защита -- firewall-ът може да повиши сигурността, но той никога не може да гарантира пълна сигурност (ако извадите мрежовия кабел сървъра и назначите един служител да го пази, кой ще ви опази от служителя :-) ).

Допълнителна изгода от използването на firewall е възможността за контрол на трафика отвътре навън в корпоративната мрежа (например firewall-ът на UNCTAD в Женева филтрира всякакъв chat и voice mail трафик, което значително риска от неефикасна работа на служителите и загубено работно време). И последно -- firewall-ът често играе ролята на "посланник" в Internet, на същият server се задава публична информация за организацията и възможната връзка със служителите й (примери - UUnet.uu.net, gatekeeper.dec.com). Във firewall server-a може да бъдат вградени и множество други възможности, които не са пряко свързани с функцята му като firewall, но (в зависимост от използваната технология), мястото им е в същата програма. Типичен пример са proxy server-ите, които се използват и за кеширане.

Понякога Firewall-ът може да определя "опасните" услуги като telnet и NFS и да ги филтрира. Изгодата е двойна - на първо място се намаляват рисковете за злоупотреба отвън и второ - дават се по-голяма свобода на корпоративните служители свободно да използват "опасните" услуги.

Firewall-ът и архитектурата на сигурността

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

Основни типиве firewall

Съобразно петслойната архитектура на ТCP/IP (напомняме, че горните три слоя от OSI се използват заедно), съществуват два основни вида firewall -- на ниво мрежа и на ниво приложение.

Firewall-ите на мрежово ниво обикновено са router-базрани -- отговорът (да/не) се съставя въз основа на зададените правила, и данните в IP datagram-а: адрес на източника и TCP/UDP порта, адрес на назначението и TCP/UDP порта, и (евентуално) съдържанието на data полето (за повече подробности за IP и IP datagram-а, виж RFC-760).

Firewall-ите на ниво мрежа като правило са по-бързи. Въпреки по-ниското ниво на работа, съществуват съвременни модели с доста сложни възможности -- много от тях могат да пазят статистика за информацията, преминала през тях, да определят (и забраняват) работата с дадени програми или протоколи от по-високо ниво, използвайки данните за портовете и идентификационни стрингове от data полето, или да използват почти евристични алгоритми за предотвратяване на "трудни" denial of service атаки като SYS flooding-а, описан в предишната глава.

Firewall-ите на ниво апликация обикновено са хостове, под които върви proxy server. Proxy-тата често се използват вместо router при желание за забрана на директния трафик между две мрежи. Възможно е един proxy server да се върже директно за друг, и така да се получи цяла верига. Тъй като те се "разбират" с протоколи от по-високо ниво като http, ftp и т.н., често имплементират и системи за защита на сигурността, специфични за дадени протокол. Много от тях притежават механизми за проверка на потребителя (във всички случаи се налага да се проверява поне на ниво порт дали заявката е от локалното пространство, в противен случай може да се получи прецедентът с българския провайдер Битекс, където повече от година подобна проверка не се правеше и proxy сървърът бе редовно използван от група компютърни пирати).

Firewall-ите на ниво апликация обикновено се използват в по-ограничителни модели на сигурността и генерират по-интелигентни report-и.

Използване на NAT router-и като firewall на мрежово ниво

NАТ router-ите (NAT = Network Address Translation) са описани изключително обстойно в [9].
Подобно на случая с proxy server-ите и тук се позволява от страната на частната мрежа адресите да са недействителни (или неизползвани като например 192.168.xxx.xxx.). Тук обаче промяната е на ниво IP - когато пакет премине през NAT router-а навън, source адреса се сменя с един от истинските NAT адреси, при връщане на пакет, той бива променен като NAT адреса се сменя с локалния адрес. При динамичния NAT routing не се знае предварително кой локален адрес на кой NAT адрес ще бъде съпоставен, което е една доста добра защита при опит за достъп отвън.

Една от причините NAT-router-ите да станат толкова популярни е маскарейдинга, въведен в Linux. (Имайки предвид масовото му използване днес, можем да изпитваме само гордост, че при разработката на source кодовете на тази част от проекта Linux са учавствали и българи!) Тази технология бе толкова радушно приета днес, защото е едно възможно решение на проблемите, възникнали с липсата на достатъчно статични IP адреси в IPv4. Чрез маскарейдинга се позволява на множество компютри от локалната мрежа да използват един единствен IP адрес, получавайки по този начин достъп до възможности, които не могат да се осъществят на ниво proxy - например ping и tracerоute.

Linux маскарейдинга (в RFC евентуално ще се появи като като NAPT - Network Address Port Translation) представлява NAT routing, при m>=1, n=1. Тук имаме само един NAT адрес, но множество локални адреси, достъпни едновременно. Трикът, който се използва е следният: портове над 61000 се резервират и всички пакети, минаващи през непривилигировани портове от локалните компютри се преадресират, като при преминаване отвътре-навън на IP пакет с нова комбинация вътрешен адрес и порт, в резервираното пространство на host-а се прибавя нов порт. По този начин пакети, насочени към NAT host-а се преадресират коректно в зависимост от порта. Тази техника отново може да се използва за прикриване на локалната мрежа, тъй като не се знае предварително към кой порт ще се осъществи връзката.

 

 

Спамингът и проблемът с неоторизираната реклама.

Ако група от социолози направят обективно проучване кои са най-мразените личности в Интернет, много вероятно е непосредствено след Бил Гейтс да се появят имената на почти неизвестните в България Лорънс Кантър и Марта Сайгъл. И до днес се спори за тяхната лична вина и хиляди пъти се задават едни и същи въпроси, започващи с: “Какво щеше да стане ако не бяха..." Единственият факт, който се приема безусловно от всички е, че 12 Април 1994 е една от най-големите дати в историята на Internet. Тази дата е една важна крачка в израстването на Мрежата, ознаменуваща края на детския романтизъм и началото на юношеските й мъки.

На 12 Април 1994 година, над 10000 отделни копия от едно досадно рекламно съобщение политaт към хилядите нюзгрупи на Usenet. Забележете, отделни копия, без да се използва механизма на crossposting-а! Млада юридическа фирма, желаеща да посредничи в US лотарията за Зелени Карти (лотария, добре известна и в България), праща своето рекламно съобщение в почти всички известни немодерирани конференции в грубо нарушение на каквито и да е локални правила за дискусия.

Нещо повече – може да се каже съобщението има измамнически характер, защото участието в лотарията Зелени Карти е свободно и не се изискват никакви такси. Много по-късно, виновниците за това безобразие Кантър и Сайгъл твърдят в своята книга “Как да създадем бъдещето на информационната супермагистрала”, че са били стари потребители на Internet, и много добре са си давали сметка какво правят." [1]. Но (както твърди Кантър) “Ние не искахме да пропуснем своята златна възможност да станем богати!”

Реакцията е мигновена и много по-ужасна от очакваната. Липсата на crossposting налага необходимостта да се почистват всеки път 10000 отделни съобщения, но главната, истинска неприятност са оплакванията от потребителите. Близо една седмица почти всички newsserver-и по света са задръстени от веригите съобщения на недоволните. Някои експерти поставят оценка над 50 мегабайта (!!!) среден трафик в рамките на всеки отделен newsserver. Напомняме, че през 1994 година 100 мегабайта беше типичният капацитет на дисковото пространство на домашен компютър!

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

За да разберем на какво се дължи тази изключително емоционална реакция, трябва да си даваме сметка, че всяка отделна немодерирана нюзгрупа едно малко общество от хора, правещи опит за позитивно общуване, като правилата се определят на общата добра воля на участниците. Поради възможността за на свободен достъп до немодерираните нюзгрупи, спазването на правилата никога не може да бъде гарантирано напълно, то се крепи винаги на косъм, на някакъв общ "заговор”, чувство за лоялност към това, което обединява . При наличие на толкова драстично и грубо вмешателство е много лесно да се скъса крехката вяра в общността.

Белята е сторена, само за няколко месеца немодерираните нюзгрупи са заляти с подражание на първоначалното съобщение от множество различни автори, като всяко следващо е на все по-ниско (или низко) ниво. Приблизително по същото време започват да циркулира и електронният вариант на make-money-fast съобщенията и друг вид кроспостинги и боклук, за който жителите на Интернет използват общото наименование spam (консерва с месо).

Любопитно: Етимологията на думичката "spam" и до днес си остава загадка. Съществуват няколко теории, най-разпространената е, че спамингът символизира mass mail-овете, които са неприятни, разплути и с лош дъх като стара консерва с месо. Интересна е и една друга теория, описана една статия на Статън Мак'Кандиш, според която за първи път подобен термин се е появил преди години в скеч на Monty Python, когато група викинги нападали някаква гостилница, чието меню се състояло единствено от "спам", и келнерът започнал ентусиазирано да обяснява: "аз има спам, спам и яйца, яйца и спам, спам-спам и яйца, спам спам и спам..." [2]

Един виц на тема Monty Python: Сър Брайън от Бел прекрачва моста на смъртта. В този момент изпод земята се чува глас: "Спри, преди да прекрачиш този мост, трябва да отговориш на три въпроса. Първо: как се казваш?" "Сър Брайън от Бел!" "Второ - какво е твоето предназначение?" "Да намеря свещения Граал!" "И трето, кои са четирите малки букви, които не са легалален флаг в Berkley Unix при командата ls?" "Aaa-и-еее!".

Скоро след "заливането" на Usenet със "spam" съобщенията, "прекъсвачите" станаха важна част от живота на Usenet. Идеята на програми като Cancelmoose е съвсем проста -- в една служебна област, наречена control се изпращат съобщения, "убиващи" оригинала. Заради начина на организация на Usenet, може да се случи "убиецът" да пристигне даже преди "жертвата", това не е проблем. Една от главните идеи на тази технология е да се даде възможност на потребителите, натиснали погрешка бутона "send" при необмислени съобщения да изчистят собственото си творение, въпреки, че то вече е започнало да "пътува" и да се размножава.

При филтрирането на spam съобщенията, обаче, съществува допълнително объркване -- налага се да се прекъсват чужди съобщения. Как да се определят критериите за това, още повече че участниците в Usenet общностите са едни от най-върлите противници на цензурата? (Опасенията им съвсем не са без основание, още повече че вече е света има примери за злоупотреба с тази технология. По време на така наречената "война" в alt.religion.scientology, описана добре в книгата на Wendy Grossman "Net Wars" [8], църквата по "сциентология" наема няколко бивши оператори на BBS-и, които използват тази техника за да "изчистват" съобщения на "нарушителите на авторските права"... Така през декември 1994 от тази област започват да изчезват множество "неудобни" съобщения, докато през април 1995 адвокат на църквата не признава публично прецедента. Copyrigth тероризъм на църквата по "сциентология" e един от най-странните етически проблеми, възниквали някога в Internet, тъй в този случай проблемите са обърнати наопаки -- носителят на авторските права тероризира Internet общността, забранявайки да се водят дискусии на важна тема от религиозно естество. Това е и почти карикатурен пример за опасността от изпадане в другата крайност -- желанието и възможността на една малка секта да наложи вето на дискусията около собствените си "свещени книги", защото те са предмет на нейното авторско и търговско право. Уви, длъжни сме да се убедим, че в света винаги ще има хора, на които, ако им се позволи биха се опитали да си присвоят авторското и търговското право и върху изгрева, звездите, въздуха, гласа ни... )

Днес прекъсването на съобщения в Usenet е изключително ревностно контролирана практика (виж например news.admin.net-abuse за детайли), oператорите, прекъснали съобщения пращат стриктни доклади, аргументиращи всяко свое действие. През последните четири години в немодерираните области на Usenet се появиха и множество други проблеми, като например "spew" съобщенията (периодичното изпращане с помощта на робот на многократно повтарящо се съобщение, виж например съобщенията с подател "Бранник Стоименов" в soc.culture.bulgaria). Допълнителен проблем са и гейтовете към list server-и или не-TCP/IP базирани мрежи като Fido, където Cancelmoose не работи. Но въпреки всички подобни проблеми, може да се твърди, че днес проблемът със spam съобщенията в newsgroup-ите е почти решен.

Втората половина на 1996 година, обаче ни поднася поредната неприятна изненада. Желаещите "бърза печалба" измислят нова техника -- junk mail-овете. В подобни съобщения се рекламира каво ли не -- финансови пирамиди, еротични телефони, долнокачествен софтуер, "free stuff", "сайтове за възрастни -- ако случайно сте под осемнадесет години, много ви моля да не четете това съобщение". Spammer-ите налучкват новa възможност -- вече newsgroup-ите се използват единствено за "лов" на email адреси, а съобщенията с реклама се пращат директно. Впрочем "ловът" на адреси достига невероятни мащаби, при които обхождането на Usenet групите е само един от похватите -- на server-и се въртят spider програми, които обхождат хаотично web страниците и търсят за символа "@", на хлапета в съмнителни IRC канали се предлагат изгодни "сделки", като цените понякога са достигали до няколко цента за адрес (изключително нагли са множество еротични сайтове във Финландия, при които увеличаването на посещаемостта се постига чрез наемането на собствени спамери -- за всеки се отваря по една входна страница, броят се посещенията и се заплаща на click. За съжаление са ми е известни и български деца, които се занимават с подобна дейност. Най-фрапиращото за мен е поведението на родителите им -- понякога те не само че са в течение, но даже се хвалят какви изключителни компютърни специалисти са техните синове, колко предприемчиви и хитри са и как изкарват пари за семейството си.)

Интересен метод за лов на адреси беше демонстриран наскоро и в нашия list-server (ict@fs.fmi.uni-sofia.bg). Mass mail-ът, който пристигна (за съжаление по небрежност на наш студент, което отново ме убеждава в ползата от настоящата курсова работа) беше адресиран от "Американската Асоциация за Борба с Рака", която щяла да получи по три цента за всеки изпратен e-mail адрес, заради едно малко и срадащо момиченце на име Джесика ("моля, разпространете това съобщение наоколо"). За съжаление, даже подобни абсолютно нелогични и нелепи лъжи често имат ефект. (Добра аналогия са mass съобщеният в ICQ, които продължават да циркулират вече втора година, независимо, че в главната страница на Mirabilis винаги е стояло предупреждение за тях.)

(Примерът с "малката Джесика" е изключително показателен и в друго отношение -- открива ни до какво страшно морално падение може да стигне човек, воден от желанието си за бърза печалба, крачка по крачка, без изобщо да го забележи какво се случва с него. Страннен е този феномен -- мрежата ни дава един съвсем различен начин на общуване -- без да чуваме гласа си, без да усещаме собствения си дъх. За много хора това спасение -- те имат проблеми с комуникацията в реалния си живот, но ето -- сега сякаш успяват да се превърнат в някой друг, си намират нови приятели. Но именно тук е и уловката -- независимо от начина за общуване, отговорност носим ние, не нашето второ аз (старите MUD потребители наричат това "второто аз" аватар - за да разберете до какви невероятни крайности може да стигне вживяването в новата роля, ще посочим за "виртуалното изнасилване" в мултипотребителското пространство LambdaMOO през 1993 година - виж например [6]).

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

Описаният проблем с "раздвояването" е изключително важен за разбиране на психологията на спамерите. Не го върши спамерът -- не, той не чувства своята отговорност, върши го "второто му аз". Нима едно тринадесетгодишно хлапе, което ви изпраща най-възможно гадните реклами на порнографски сайтове би се изправило срещу вас -- очи в очи и би ви дало тяхна рекламна брошура, отпечатана на хартия? Никога! Но в Мрежата сякаш всичко става по-лесно.

Става по-лесно да общуваме, става по-лесно и да се караме помежду си. По време на така наречените "flame"-ове в областите на Usenet и Fidonet, потребителите понякога си разменят такива ужасни думи, които никога биха си казали в лице в лице.

Не трябва да виним Мрежата за това -- виновни сме си самите ние. Мрежата е само едно различно средство за общуване или една сила повече. Както един скалпел може да спаси човешки живот в ръцете на хирурга или да отнеме човешки живот в ръцете на убиеца, така и Интернет може да се използва от всеки и за всичко. Но хирургът внимава, когато държи скалпела, внимаваме ли и ние, когато държим клавиатурата?)

Смутителят на вашето спокойствие изобщо не се смята за натрапник. Не -- той претендира, че се грижи за вашето право да не бъдете обезпокоявани: "Ако това съобщение е достигнало до вас заради грешка, моля ПРОСТО отговорете с REMOVE в полето subject!" Обикновено подобни отговори имат точно обратния ефект -- spammer-ът се убеждава, че адресът е активен и продължава да го разменя или продава. Това са така наречените "черни листи", излизането от тях понякога е едно единствено -- да си смените пощенската кутия.

(Това е и втория голям удар върху Usenet, нанесен от спамерите, защото през последните три години много от потребителите започнаха да изпитват страх когато пишат в групите, опасявайки се, че техния email адрес ще влезе в "черните списъци". Изключително силен аргумент срещу спамерите, които се оплакват че са цензурирани, защото коя цензура е по-страшна -- цензурата на техния рекламен боклук или масовата автоцензура заради тях?)

В момента по-големите Internet или Е-mail доставчици като CompuServe и Netаddress предлагат като доброволна и допълнителна опция филтрирането на spam съобщенията. Това не винаги е толкова лесно да се осъществява, тъй като филтрирането на съобщения от фиксирани домейни или адреси рядко е най-подходящото решение (с изключение по-"престижните" спамери като Cyber Promotions, останалите се грижат за некоректната идентификация и обикновено използват чужди SMTP сървъри). Един от начините е ангажирането на допълнителни служители, които да четат и проверяват, което не е проблем за по-големите доставчици. По-прост и лесен трик е използването на пощенски кутии -- капани. Съобщение от адреса-капан се пуска в Usenet конференции като alt.test, потребител със същата идентификация влиза мълчаливо в подозрителни канали на IRC като #hack.com, стои там известно време и т.н. Към кутията е прикачена програма, която провярява всяко новопристигнало съобщение (то не може да бъде нищо друго, освен spam), след което търси за други негови копия в пощенските кутии на потребителите и ги изчиства.



by Bill Holbrook

Другa идея за борба е промяната на американския закон срещу junk fax-овете, като същият бъде разширен за случаите на рекламата по e-mail. За по-подробна информация, виж www.cauce.org.

 

 

Дискусии около цензурата и конфиденциалността.

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

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

Симетрично кодиране с тайни ключове

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

Най-известният в момента алгоритъм, използващ тази технология е DES (Data Encryption Standart), разработен от IBM и обявен през 1976 година за американски правителствен стандарт и който дълго време (дори и днес) се използва масово в комерсиални и правителствени проекти. Изключително бърз (над 100 пъти по-бърз от RSA, тъй като при него избощо не се използват реални променливи). Ключът му е 64 битов, с ефективна дължина от 56 бита.

Навремето DES се е смятал за изключително силен и сигурен (при около 2^56 възможни ключа трябват около 2000 години скорост на изчерпване около милион ключа в секунда).
През юни 1997 година, обаче група Internet потребители, разпределяйки кооперирано изчислителната мощност до която имат достъп, за около три месеца успяват да проверят осемнадесет квадрилиона (от седемдесет и двата) възможни комбинации и най-после декодират едно от съобщенията -- предизвикателства, гласящо:

"Strong cryptography makes the world a safer place."

Така алгоритъмът DES, смятал се за най-сигурния в света повече от 20 години, най-после е победен чрез "брутална атака" със скорост 7 милиарда ключа в секунда. За повече информация, виж http://www.frii.com/~rcv/deschall.htm.

IDEA, eдин от най-силните в момента алгоритми в света на базата на секретен ключ, е публикуван през 1990 година от двама швейцарци. Идеята на IDEA (International Data Encription Algorithm) е била да се даде достатъчно добра алтернатива на DES, която да се използва извън Америка. Ключът при него е 128 битов, но той продължава да е много бърз (само около два пъти по-бавен от DES). Днес все още се смята за изключително сигурен.

IDEA има един основен недостатък - не може да се използва при последователни потоци от данни -- кодираният блок трябва да е дълъг поне 64 бита, за да се гарантира силно кодиране. Следователно IDEA би бил удачно решение при прехвърляне на файлове, страници, форми, но в случаи като telnet не върши добра работа.

Един от основните алгоритми, които се използва в момента от американските военни при разработката на кодиращи чипове е Skipjack. Алгоритъмът не е напълно известен, тъй като някои негови части са обявени за тайна от правителството на САЩ, знае се само само, че е симетричен алгоритъм, с приблизително същата скорост, каквато е в DES и използва 80 битов ключ на 32 паса. Възможно е скоро да започне и неговото комерсиално приложение, известно е например, че АТ&Т има планове да използва Skipjack при кодирането на телефонните линии. (Предположението при избор на осемдесет битовия ключ е, че от сега нататък на всеки осемнадесет месеца процесорната мощ на компютрите в света ще се увеличава два пъти. Тогава биха трябвали около 35 години, преди да се повтори ситуацията с DES.)

Друг известен кодиращ алгоритъм е RC4, използва 112 битов ключ. Той трябваше да е търговска тайна, или поне се смяташе до момента когато негов source код изтече в Usenet. През 1995 година, две групи от Internet потребители независимо една от друга успяха да разкодират само десетина дни предизвикателство, отнасящо се до SSL нивото на международната версия на Netscape, което използва RC4-40.

(SSL или Secure Socket Layer е новото шесто ниво в TCP/IP, вместено между ниво апликация и транспортното ниво -- естественият стремеж е защитата на данните да не се обвързва с конкретен софтуерен производител.)

Асиметрично кодиране с публични ключове.

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

Първите разработки на това, което днес знаем като криптография с публичен ключ (public key cryptography), възниква за първи път на Уинфред Дифъл от Страндфордския Научен Институт. През 1977 година, силно повлияни от статията на Дифъл и Хелман "Новите направления в криптографията", публикувана една година по-рано, трима новаци в тази област на име Роналд Ривест, Ади Шамир и Леонард М. Аделман започват да дискутират заедно възможностите за практическа реализация на идеите от статията. Алгоритъмът RSA бил записан за първи път от Рон Ривест, който една априлска нощ на 1977 година не можел да заспи, защото имал силно главоболие. По-късно тримата автори приготвят статия до списание Scientific American, който излиза през септември същата година. В нея има и предложение до всички заинтересовани да получат техническите подробности срещу плик обратен адрес и марка. Военните, както винаги, разбират твърде късно и опитите им да предотврятят изтичането на информацията извън Щатите се оказват неуспешни -- бележките на вече масово вървят от ръка на ръка, копират се и се преписват -- тримата автори са успели да извадят духа от бутилката.

"Вълшебният" трик, използван от алгоритъма RSA е следният: Изберете си две много големи прости числа p и q и нека произведението им n=pq. Да означим j(n)=(p-1)(q-1) -- това е броят на всички взаимно прости с n числа в интервала [1..n-1] (или с други думи броят на всички числа в групата, имащи обратен елемент). Изберете сега число e<n, което е взаимно просто с j(n) и намерете обратният елемент на e по модул j(n), или с други думи такова число d, че ed mod j(n) = 1. Обикновено е и d се наричат съответно публична и частна експонента. Публичен ключ се нарича наредената двойка (n,e), тайният ключ е числото d, а числата p, q и j(n) трябва да се унищожат. Кодиращият алгоритъм е следният: ако m се кодира като c, с се пресмята с помощтта на c=m^e mod n. Декодиращият алгоритъм е следният: ако c се декодира като m, m се пресмнята като m=c^d mod n.

Да се уверим сега, че алгоритъмът е коректен, или че (m^e mod n)^d mod n дава наистина m. От алгебрата знаем, че степенуването на степен по модул n е малко по-сложно отколкото в групата на целите числа -- (m^e mod n)^d mod n = (m^(ed mod j(n))) mod n. Но ed mod j(n) за щастие е 1. Получи се m mod n, като разбира се m<n.

Предположението, че RSA може да бъде много сигурен се дължи на липсата на достатъчно бързи алгоритми за изчерпване на простите делители на твърде големи числа. Възможно да се намери d от (n,e) чрез j(n), но за тази цел трябва да бъдат реконструирани p и q, което е изключително бавно. Сигурността на RSA зависи от дължината на ключовете -- в момента 384 битови ключове са съвсем лесно пробиваеми с директни атаки, но се смята, че 1024 битови ще бъдат сигурни векове (а с програмата PGP масово се използват 2048 битови ключове). Разбира се последните предположения биха били в сила само ако не се измисли начин, по който може да бъде изваден e-ти корен по модул n, не е доказано, че не могат да съществуват подобни прости аналитични атаки.

За гарантиране че при транслацията ще се използват коректните публични и тайни ключове, в съвременните системи се използват сертификати. (Представете си иначе следната проста ситуация -- A иска да изпраща кодирани файлове до Б и търси публичния ключ му ключ Б1. Системният оператор C генерира двойка ключове C1 (публичен) и C2 (таен) и подменя B1 с C1. А изпраща съобщение до Б с ключ C1 вместо B1, C го разкодира с C2, кодира го с B1 и го изпраща до Б, Б го разкодира с тайния си ключ B2. Б е убеден, че никой не е чел съобщението от A. Сега си представете, че Б изпраща съобщение до A и го подписва с тайния си ключ B2, C го разкодира с B1, променя го и го праща към A, кодирано с C2. А го разкодира с C1 и e убеден, че съобщението е от B. Този вид атака се нарича "man in the middle attack". Повече подробности за видовете атаки среу PGP и RSA на адрес:
http://axion.physics.ubc.ca/pgp-attack.html
).

Най-популярнатото приложение, която използва RSA, разбира се се нарича PGP. След 1991 година, когато Фил Зимерман реализира за първи път своята "криптография за масите" и я пуска като freeware програма, той си има дълги години сериозни юридически неприятности. PGP е много по-бърза от класическите RSA програми, тъй като тя комбинира кодиране с публичен ключ със симетрично кодиране -- файлът се кодира с IDEA, а IDEA ключът се прилага, кодиран със съответния RSA ключ. При декодиране първо се декодира IDEA ключът с RSA , след това информацията се декодира с IDEA.

Интересен е и методът, чрез който програмата PGP бе изнесена в Европа. Като използваха прецедента с Фил Зимерман, който бе оправдан за издаването source кода на хартия, група от стотици ентусиасти организираха акция, при която програмата PGP беше отпечатана на хартия в кодиран вид (разделена на блокове с контролни суми), изнесена през границата като няколкостотин подвързани тома хартия, след което обратно сканирана в Европа. Оказа се, че този "експорт метод" от Съединените Щати е законен. За повече подробности, виж www.pgpi.com.

След Втората Световна Война, правителствата навсякъде по света правят опити за контрол върху използването на кодиране на данните. През 1976 година, щатската NSA (Natinal Security Agency), класифицира всяка форма на криптиране като оръжие. Въпреки това, хора като Фил Зимерман продължават упорито да защитават собствените си възгледи.

Според едно изказване на г-н Славински, председател на Комитета по Пощи и Далекосъобщения пред радио Свободна Европа, в момента държавите от Европейския Съюз били разделени на две части в отношението си към кодиращите алгоритми. Държавите от "северния фланг" били привърженици на свободната употреба на кодиращи алгоритми, по-южните държави търсели начини за регулиране (за коментар около неясната позиция на България, виж по-нататък).

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

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

Друг основен проблем с който се сблъскват всички опити за контрол е, че Internet е твърде голям и свързва прекалено много държави с различно законодателство. Това, което е незаконно в една държава може да е законно в друга. В Англия е пиромански книги като "готварска книга на анархиста" са забранени, но какво пречи на англичаните да вземат този текст от някой американски сайт? В Германия никога няма да видите порнографки материали на публичните сървъри, но какво пречи на германците да посещават финландските сайтове?

Съществуват случаи, когато самият потребител би пожелал да бъде предпазен от случаен достъп до определени ресурси, например да забрани на сина си "червените" страници - софтуери CyberSitter позволяват това. Проблем, обаче, e рискът базата от данни да бъде разкодирана и използвана за обратните цели (точно това се случи през 1996 година с CyberSitter). Още -- съществуват сайтове, които биха могли да теглят информация от забранените зони, пример anonymizer.com. Освен това този вид филтриране никога не е с пълна точност, обикновено информацията за site-овете, които трябва да бъдат цезурирани закъснява с около една седмица, независимо че в издирването на "опасните" сайтове участват огромно количество студенти. Но колкото е по-голяма групата участващи в проекта, толкова повече съществува опасност в базата от данни да попадне нещо, на което мястото не е там, например в случая с CyberSitter се е оказало, че сайтът на американската асоциация на жените е бил определен като порнографски!

Всъщност в момента в света съществува едно единствено практически осъществимо решение за стопроцентов контрол на трафика. Това е така нареченият "китайски вариант", или human proxy -- тук вече не става въпрос за филтриране на информацията, обратното -- конструира се база от данни с разрешените сайтове и за всяка отделна заявка извън базата се разрешава достъп -- от другата страна на линията стои жив човек, той зарежда страницата преди вас и проверява за "нецелесъобразна информация". Подобни опити са правени и в Куба, Тайван, Кувейт u Саудитска Арабия (за повече информация - виж http://www.eff.org/pub/Global/Dispatches). Това ли искаме? За щастие едва ли! :-)

 

 

България и новите предизвикателства.

"Нашите програмисти са най-добрите", "България има млад и бляскав потенциал". С радост слушаме, как всекидневно вестниците ни заливат с подобни клишета, без да си даваме сметка, че от определена гледна точка такива констатации са не само повод за гордост, но и повод за известна тревога.

Дори нашите компютърни специалисти да бяха наистина най-добрите в света (а аз лично малко се страхувам от подобни суперлативи), това съвсем не отговаря на един друг въпрос -- знаят ли те как да използват своите умения? Могат ли да работят в един екип заедно с останалата "не толкова умна" част от света? Подготвени ли са за новите предизвикателства?

Наистина, ако по някакви неведоми причини вождът на племето Буго-Буго изведнъж се сдобие с твърде красив и твърде лъскав пулт за управления на ядрени ракети, дали това наистина би било толкова голям повод за радост, колкото изглежда в началото? :-)

Несъмнено нещо се променя. Типичен пример е завършекът на сагата с българската следа в компютърните вируси. Тя е дъвкана твърде много (виж например [4] и [5]), но бих искал да изтъкна отново няколко изключително важни и обнадеждаващи факта, които (за съжаление) все още се разбират от твърде малко журналисти. България беше един от лидерите в производството на компютърни вируси само до 1992-1993 година. Към средата на деветдесетте години, страната ни изключително бързо изгуби лидерските си позиции и в момента е на едно от последните места в класацията.. Това съвсем не означава, че нашите програмисти са станали по-малко способни или по-малко компетентни! (Спомням си, че моят колега Валери Тодоров предсказа появата на макро вирусите година и половина преди да се чуят сигнали за първите екземпляри по света. Но вирусите бяха написани от чуждестранни автори, защото на специалисити като Валери вече не им минава и през ум да си губят ценното и добре платено време като системни програмисти за да пишат някакви нови вируси - този факт би трябвало да ни дава поне някакъв дребен повод за оптимизъм.)

Но... за съжаление... все още всички се учим да бъдем част от света.

Българската Телекомуникационна Компания също се учи да бъде част от света, поне ако се съди от някои странни идеи, за които се твърди че трябвало да влязат в новия закон за далекосъобщенията. Според тях, било необходимо Internet провайдерите да се грижат да не предоставят порнографска информация на потребителите и същите да предоставяли при регистрацията си “използваните схеми на кодиране”.

Първото изискване е доста странно, още повече, че се предлага от БТК – компания, която под формата на така наречените "услуги с добавена стойност", през последните две години заля България с еротични телефони. (Б.А. наскоро забелязах и един още по-неприятен прецедент – телефон за детски приказки 15 импулса на митнута. Мисля, че читателят ще се съгласи, това е даже по-неморално от еротичните телефони!) Нека все пак да изтъкнем два довода, които правят това изискване да звучи малко объркващо:

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

Доколкото до второто изискване, нека отбележим следното:

  1. Не е възможно Internet провайдерът да контролира алгоритмите за кодиране, използвани при пренасяне на данни от потребителите. Как би могло да стане това? Може би трябва се назначи по един служител, който да стои на всяка линия от router-а, да гледа отворените socket-и и да прецянява, дали информацията която тече не е кодирана? Или може би да се забрани директната връзка, цялата информация да минава през firewall, да се log-ва, да се чете на ръка няколко пъти дневно, след което да се трие, за да не се се препълнят hard дисковете на системата? Китайски вариант на proxy? Или може би от БТК имат някаква още по-“добра” идея?
  2. Даже проблемите по точка 1 да бяха преодолими (а те не са!), на авторът на този текст му е изключително любопитно да разбере, как някой български “експерт” би могъл да разкодира данни, минали през програмата PGP с 2048 битов ключ? Алгоритмите, които се използват от PGP (IDEA+ и RSA) са добре описани, source кодът е публично достъпен, но нима знанието на един кодиращ алгоритъм е достатъчно за разкодиране на информацията, кодирана с този алгоритъм? Как би могло да стане това?

(Да приключим темата с “новаторските” предложения на БТК, отбелязвайки, че и двете изисквания показват единствено некомпетентността на държавния чиновник, дал идеята за тях и че ако след време приватизацията на БТК премине успешно, нека не се притесняваме, ако промените там започнат с незабавни уволнения. )

Авторът на този текст съвсем няма намерение да снема отговорността и от Internet провайдерите. Малко по-долу ще посочим множество негативни прецеденти от последните две години. Това обаче, което трябва да изтъкнем е, че безотговорното поведение на потребителите на БТК съвсем не оправдава ниското качество на нейните услуги. Къде в цивилизования свят някой е чувал за следната причина dialup потребител да излиза от Internet без да си е свършил работата "мина твърде много време и дуплексът ми ще се сърди"?

Проблемите с Internet провайдерите не са малко, и те започнаха още от ранните години на българския Internet. Първоначало проблем бяха високите цени, липсата на конуренция и неясния, а понякога дори съмнителен routing на трафика. И до днес не съм чул, например, някакво смислено обяснение за причината, поради която частни Internet доставчици използваха acad.bg! Когато пазарът се промени след появата на flat rate доставчиците и падането на цените повече от пет пъти след 1996 година, проблем се оказа изграждането на национален backbone -- мечта, която започна да се реализира чак през 1998 година. Въпреки споровете около домейна .bg, тромавата и бюрократична регистрация на нови имена и съмнителната историческа роля на фирма Цифрови Системи - Варна, никой не отрича, че засега качеството самата услуга е задоволително. Появата на доставчици на едро като Orbitel, Spectrum Link или Net Is Sat и изкючителният успех на Internet Expo'98 показаt в икономическо отношение българският Internet се развива с напълно задоволителна скорост. Започнаха да се появяват и много други услуги в "западен" стил, като например системата за търсене dir.bg.

Следователно главните проблеми, които започват да стоят пред нас сега не са толкова от икономическо, колкото от социално естество. И тук отново пред нас застава диалемата, вече спомената в началото на нашата глава -- с вожда на племето Буго-Буго и ядрените ракети.

Нека отбележим само няколко от многобройните случаи през последните две години, в които български Internet потребители и доставчици са се оказвали на ниво Буго-Буго. Съжалявам, ако не съм точен или изчерпателен, повечето данни са от несигурни източници, а е възможно след като завърша този текст и го предам, да се сетя за поне още толкова прецеденти.

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

1996-1997 година:

  • Огромни караници между фирмите CIT на г-н Димитър Ганчев и отцепили се служители в Тechno-Llink, за радост на абонатите на ехоконференцията на Fido bg.internet. SYN flooding на mail server-a на CIT от Techno-Link.

  • Скоро след предишния прецедент, в българското WWW пространство изниква първият еротичен сайт в България - Tech-no-Link (www.technolink.bg), който естествено няма нищо общо с услугата Техно-Линк (www.techno-link.com). Забавно е да се отбележи, че в info.ripe.net, домайните technolink.bg, bol.bg и isoc.bg доскоро имаха еднакви телефони за контакт! Любопитен е и domain-ът www.kit.bg (да не се бърка с www.cit.bg), както и www.bulgariaonline.bg (да не се бърка с www.online.bg).

  • Клиент с арендована линия от фирма Bulnet се оплаква в един компютърен вестник, че служители на фирма BIS Online са направили успешен опит за проникване в неговата система. Когато разгневен се е обадил в офиса на BIS, получил отговор: "ние само тествахме сигурността на системата ви". Ситуацията е коментирана пред мен по следния начин, "не е честно човек, който забрави вратата на апартамента си отворена да се оплаква от съседа си, който е влязъл, оставил е бележка и е затворил входа".

  • Клиенти на SprintNet u SCITOR се оплакват многократно, че не могат да се доберат до комутируемите линии на системите, защото са задръстени от "хакери" в CompuServe.

  • CompuServe, America Online и Genie една след друга "отрязват" България. Линиите на SCITOR и GlobalOne веднага се "отпушват".

  • Във Варна е арестувана група от "колетни" кракери. "В кауша им е мястото", заявява по този повод Иван Татарчев според очевидец. Малко по късно всички са пуснати на свобода.

  • В София е арестувана група от пирати, фалшифицирали фонокарти по системата "Булфон". Повечето от тях остават доста по-дълго в затвора, отколкото варненските си колеги.

  • Софийският харер Query споделя в ехоконференции на малката мрежа Fido-България, че е получавал предложения от известна икономическа групировка да осъществява компютърни обири, но е отказал. Съобщението изтича и във вестник 168 часа.

  • Неизвестен кракер на име Dav осъществява няколко успешни атаки във Факултета по Математика и Информатика към Софийския Университет, като последната през Декември 1997 е изключително злобна и разрушителна. Слуховете, че този човек е самият автор на вируса Dark Avenger по-късно са отхвърлени.

1998 година

  • Вестник ComputerWorld упорито продължава да разпраща информация по Internet до всички компютърни фирми в България, без да използва mailing list или BСС. В някои от съобщенията бива открит и macro вирус под Еxcel.

  • Благодарение на листата с адреси от тези съобщения, между фирмите започва да циркулира junk mail.

  • Група кракери в bol.bg са успешно изловени от г-н Димитър Ганчев.

  • Представители на същата групичка кракери регистрират domain veni-markovski.com.

  • Фирмата Бонмарин използва spaming за реклама на мултимедийните продукти на ММ-Арт. От софийски офис на същата фирма изтича информация, че в един от компютрите в локалната мрежа най-малко осем часа дневно се върти spider и продължава да събира нови адреси.

  • В едно underground издание на български фрикери е публикуван нов начин за влизане през "любимите" Sprint и SCITOR в "отязания" CompuServe -- като първо се минава през сървър в Лондон. Методът е несигурен.

  • БТК в Бургас се опитва да наложи по-високи тарифи за връзка с местен провайдер. Опитът се проваля.

  • Служител в офис на същия този провайдер (студент от ФМИ) се хваща на въдицата и разпраща из България mass-mail от spammer в America Online (вече описаното по-горе съобщение с "малката Джесика").

  • Поредната караница в mailing листата на софийските провайдери около проблемите с domain-a .bg. Тонът стига до хамалски ругатни.

  • Неизвестен кракер осъществява серия от продължителни ping flooding атаки срещу www.padishah.com на г-н Вени Марковски.

  • Представител на малката компютърна фирма Номител Електроникс започва редовно да тероризира българските Internet потребители с рекламите си. Даже в ICQ.

  • следва...
  • следва...
  • следва... :-(

 

 

Право на отговор

Важна бележка:

Всеки, който се чувства по някакъв начин засегнат от материалите по-горе може да
бъде публикуван без всякакви промени или коментари. Целта ми в последната глава
беше не да показвам кой точно е "Буго-Буго"!


From - Sat Jul 25 00:02:06 1998
X-Sender: mitko@mvr.bol.bg (Unverified)
To: Kosio Spirov
From: Dimitar Ganchev
Subject: СИГУРНОСТ, ЗАЩИТА НА КОНФИДЕНЦИАЛНАТА ИНФОРМАЦИЯ И ЕТИЧЕСКИ
  ПРОБЛЕМИ В ИКТ

>SYN flooding на
>      mail server-a на CIT през Techno-Link.

Това трябва да се чете "CIT ОТ Techno-link", а не "CIT ПРЕЗ Techno-Link".
Има много голяма и изключително съществена разлика между едното и другото.
Ако някой не я прави (разликата), толкова по-зле за него.

>злоупотребата с чужда
>      търговска марка

Колкото и странно да ти звучи, Техно-линк бяха пропуснали да регистрират
търговската си марка. Това стана едва след като Прософт ги купиха. Освен
това според българското законодателство няма пречка име на фирма да съвпада
с име на търговска марка. Грижа на този, който иска да си запази името е да
направи както едното, така и другото. Техно-линк не бяха регистрирали фирма
с такова име, затова съдът сметна за напълно уместно да я регистрира на мое
име.

Често срещана грешка е хората да си мислят, че BOL.BG има нещо общо с
България Он Лайн. Този домейн е регистриран от фирма БОЛ ООД.

Фирма "България Он Лайн ООД" е регистрирала домей bulgariaonline.bg, срещу
което Фондация Приложни изследвания и Комуникации, собственик на марката
"България Онлайн" заведе прокурорска преписка срешу нас. Преписката бе
прекратена, тъй-като според Търговския закон една фирма има право и дори е
длъжна да използва името, с което е регистрирана в търговския регистър.
Регистрация на име в патентното ведомство не води до регистрацията му в
търговския регистър и не е в противоречие с него. Много хора не го разбират.

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

>В София е арестувана група от пирати, фалшифицирали фонокарти по системата
"Булфон".
>      Повечето от тях остават доста по-дълго в затвора, отколкото
варненските си колеги.

Това какво общо има с темата "български Internet потребители и доставчици
са се оказвали на ниво Буго-Буго"?

Причината да стоят по-дълго в затвора е, че все още у нас няма правно
понятие "компютърно престъпление". Но в новия наказателен кодекс и в новия
закон за авторското и сродните му права тези деяния ще се инкриминират и
тогава ще лежат в затвора всички, които на Login: са написали нещо, което
не е трябвало. В момента дори тече дискусия (в МС) дали да се инкримира
опитът за проникване, или самото проникване. От МВР искат да преследват и
опитите, от гражданската администрация - само проникването (едните казват,
че ако няма проникване, няма и изнасилване, а другите твърдят, че тогава ше
трбява да спрат да преследват и опитите за убийство и първо да чакат да
паднат няколко трупа, което да се установи надлежно със смъртен акт и чак
тогава да се намесват). До есента ще се разберат.

> От server, близък до www.padishah.com на г-н Вени Марковски се осъществява
> ping flooding атака срещу български Internet доставчик на едро.

Това вече минава всякакви граници. Точно обратното. Ние бяхме floodнати,
което естествено доведе до flood и на всички доставчици на едро, към които
сме закачени. Това не значи, че сами сме се floodнали. Мисля, че можеше
поне да попиташ въпросните доставчици на едро и те щяха да ти кажат. Както
Стефан от Орбител, така и Пешо от Спектър, така и Сашо от Уником потрошиха
сума време, докато трасират от къде идват флудовете. Предполагам, че дори
все още си спомнят подробностите. Сигурен съм, че последното, което им идва
на ум, е че това е било наше дело.

Относно лицата за контакти на даден домейн: моето име е лице за контакти на
24 (двадесет и четири) домейена, което представлява 4.60% от домейните в
България (общо 522 към 4 юли 1998). Имайки предвид, че според правилата за
регистрация една фирма може да регистрира само един домейн и ако приложим
методите на Галъп излиза, че аз притежавам 4.60% от фирмите в България.
Това би било много хубаво, но за съжаление не е вярно. Аз само осъществявам
достъпа им до Интернет, или ги консултирам в тази област. Иначе всеки може
да провери в съда на кои фирми съм собственик, това е публична информация и
аз не мога да я крия.

Димитър Ганчев


Списък с използвани книги и статии

1. Laurence A. Canter and Martha S. Siegel, How to Make a Fortune on the Information Superhighway (HarperCollins 1994).

2. Stanton McCandlish, Archeology of Spam (EFF 1995).

3. TCP SYN Flooding and IP Spoofing Attacks (CIAC Information Bulletin, September 1996)

4. Васил Хабов, Българската следа в компютърните вируси.

5. Веселин Бончев, Българскате фабрики за производство на компютърни вируси.

6. Julian Dibbell, "A Rape in Cyberspace; or How an Evil Clown, a Haitian Trickster Spirit, Two Wizards, and a Cast of Dozens Turned a Database into a Society," Village Voice, December 21, 1993.

7.Maximum Security: A Hacker's Guide to Protecting Your Internet, Mark Tabal (Sams Publishing 1998)

8. Net Wars, Wendy Grossman (NY Press 1997)

8. Internet Firewalls Frequently Asked Questions, Marcus J. Ranum and Matt Curtin

9. IP NETWORK ADDRESS TRANSLATION, Michael Hasenstein, 1997:

10. The World Wide Web Security FAQ, Lincoln D. Stein Version 1.4.0, July 10, 1997

11. Understanding Digital Signatures: Establishing Trust over the Internet and Other Networks, Gail Grant (Commerce Net Press 1997)

12. Firewalls Complete, Marcus Goncalves (The McGraw-Hill Companies Inc 1997)

 

Нещо в заключение

 

--- Дете мое, мисля, че те хванах да подслушваш…
--- Да подслушвам ли?
--- Ти подслуша разговора между две свои съученички.
--- А, това ли? Не знаех че е подслушване – не беше ли магия?
--- Да подслушваш с помощта на магия е същото, както да го правиш по друг начин.“

Из "Плаването на Разсъмване" на К.С.Луис (книга, написана през 1952 година)

 

 

Обратно в главната страница на Косьо Спиров


This page hosted by Get your own Free Home Page


Access Counter