Мрежова сигурност - теми и проекти

12 януари 2003 г.

$Ringlet: doc/ringlet/bg_BG.CP1251/articles/netsec-research/article.sgml,v 1.5 2004/01/25 12:38:07 roam Exp $

Кратко описание на темите и проектите за програмиране, предложени от Петър Пенчев <roam@ringlet.net> за курса Мрежова сигурност, четен във Факултета по математика и информатика на Софийския университет през зимния семестър на 2003 г.


1. Въведение

Това е кратко описание на проектите, предложени от Петър Пенчев <roam@ringlet.net> за курса Мрежова сигурност, заедно с малко по-подробни инструкции от оригиналното изброяване на темите и задачите за програмиране. Предложени са четири теми за изследване и три проекта за програмиране.

Теми за изследване

Проекти за програмиране


2. Сигурна поддръжка и достъп до World-Wide Web

2.1. Задание

Да се опишат различните услуги и програми, използвани при създаване и достъп до съдържание, разпространявано чрез World-Wide Web. Особено внимание да се обърне на т.нар. active content от всички типове и мерките, които се вземат и при сървъри, и при клиенти за предотвратяване на пробиви в сигурността, предизвикани от active content.


3. Сигурност при peer-to-peer реализации на file sharing

3.1. Задание

Да се опишат различните технологии за peer-to-peer file sharing (Napster, Kazaa и др.) и възможностите за атаки върху тях - подмяна на файлове, неправомерен достъп до ресурси на клиентския компютър (достъп до файловата система, изпълнение на код, ...) и други. Да се опишат мерките за защита, взети от различните file sharing системи, и възможностите за тяхното преодоляване.


3.2. Примерен план

Примерен план за темата ``сигурност при peer-to-peer реализации на file sharing''

  • Въведение: системи за peer-to-peer file sharing:

    • какво представляват;

    • как и защо са възникнали;

    • как и защо са еволюирали и за какви цели се използват.

  • За всеки от използваните протоколи за връзка:

    • име, цел, евентуално кратка история;

    • от кои системи се използва;

    • основни идеи на протокола, кратко описание на процеса за връзка, обмена на информация за търсени/налични файлове, предаване на метаданни за файловете (размер, атрибути, timestamps и др.), предаване на самите файлове (частично или изцяло);

    • основни структури от данни, използвани от протокола;

    • особености на протокола - възможности, предлагани от него, които не се предлагат от другите протоколи за peer-to-peer file sharing;

    • известни слабости в дизайна и реализациите на протокола (с указване за кои системи/реализации се отнасят);

    • потенциални слабости в дизайна и реализациите на протокола (optional);

    • съществуващи проблеми с известните реализации на протокола и начини за предпазване;

    • други цели, за които протоколът е бил първоначално разработен или използван впоследствие, ако има такива.


4. Сигурност при реализации на file sharing от тип клиент/сървър

4.1. Задание

Да се опишат различните технологии за client-server file sharing (NFS, SMB, NetWare, ...) и възможностите за атаки срещу тях - подмяна на файлове, представяне на фалшиви "удостоверения за самоличност" (credentials), неправомерен достъп до ресурси на клиента или сървъра (достъп до файловата система, изпълнение на код, ...) и други. Да се опишат мерките за защита, взети от различните file sharing системи, и възможностите за тяхното преодоляване.


4.2. Примерен план

Примерен план за темата ``сигурност при реализации на file sharing от тип клиент/сървър''

  • Въведение: системи за client/server file sharing:

    • какво представляват;

    • как и защо са възникнали;

    • как и защо са еволюирали и за какви цели се използват.

  • За всеки от използваните протоколи за връзка:

    • име, цел, евентуално кратка история;

    • от кои системи се използва;

    • какви реализации има за различните операционни системи;

    • основни идеи на протокола, кратко описание на процеса за връзка, автентикация, обмена на информация за търсени/налични файлове, предаване на метаданни за файловете (размер, атрибути, timestamps и др.), предаване на самите файлове (частично или изцяло);

    • основни структури от данни, използвани от протокола;

    • използвани методи за автентикация;

    • особености на протокола - възможности, предлагани от него, които не се предлагат от другите протоколи за client/server file sharing;

    • известни слабости в дизайна и реализациите на протокола (с указване за кои системи/реализации се отнасят);

    • потенциални слабости в дизайна и реализациите на протокола (optional);

    • съществуващи проблеми с известните реализации на протокола и начини за предпазване;

    • други цели, за които протоколът е бил първоначално разработен или използван впоследствие, ако има такива.


5. Сигурен достъп до Интернет в България

5.1. Задание

Да се разгледат различните методи за връзка с Интернет, предоставяни от българските доставчици (dial-up, ISDN, наета линия, residential LAN, ...). За всеки метод (евентуално и за различните доставчици, когато има разлики в начина на предоставяне на услугата) да се опишат възможностите на атакуващи лица, разположени на различни места (между клиента и доставчика, физически близо до клиента, физически близо до доставчика, споделен ресурс особено в случая на LAN и подобни, както и други възможности според методите), да подслушват и/или подменят трафика, както и да използват неправомерно ресурси на клиента или доставчика с помощта на придобитата информация.


5.2. Примерен план

FIXME: write me up.


6. Бърз анализ на трафик, преминал през мрежа

6.1. Задание

Да се създаде инструмент, който допълва работата на tcpdump или WinDump, като взима за входни данни файлове, съдържащи запис на преминал трафик (tcpdump -w), и прави статистика за активността на всеки IP адрес, който е изпращал или получавал пакети през това време. Статистиката да съдържа времето (timestamp) на първия и последния изпратен/получен пакет, както и общия размер на трафика, преминал през всеки IP адрес. В статистиката да бъдат включени IPv4 и IPv6 пакетите, изпратени към или получени от всеки IP адрес, като е желателно да има възможност те да бъдат разделени на входящ и изходящ трафик.

При избора на език за програмиране и използвани библиотеки да се поддържа възможност за компилация на поне 3 различни класа операционни системи.

Note: Инструментът анализира само tcpdump / WinDump savefiles, т.е. файлове, съдържащи информация за получените от tcpdump / WinDump пакети, създадени с помощта на опцията -w на командата tcpdump или WinDump. НЕ се изисква или очаква да бъдат правени опити за анализ на информацията, която tcpdump / WinDump извежда на стандартния изход по време на работата си!

Класове операционни системи

  1. ``стари'' версии на Microsoft® Windows®: Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows ME;

  2. ``истински'' версии на Microsoft Windows: Microsoft Windows NT, Microsoft Windows 2000, Microsoft Windows XP, Microsoft Windows 2003 Server;

  3. ``Unix-like'' операционни системи: SCO Unix®, Sun Solaris®, SGI IRIX®, Linux, FreeBSD, NetBSD, OpenBSD, BSD/386® (също известна като BSDi), HP/UX®, IBM AIX®, Apple MacOS X® и т.н.;

  4. Apple® MacOS® преди MacOS X®;

  5. други: MS-DOS®, CP/M, BeOS, VxWorks и т.н. (за любителите на приключения и/или силни усещания :)


7. Детектор на ARP poisoning и ARP flood атаки

7.1. Задание

Да се напише програма, която следи трафика, пристигащ по един или повече мрежови интерфейси, и открива вероятни опити за ARP poisoning и ARP flood атаки. Според настройките (зададени в конфигурационен файл, но поддържащи промяна на параметри чрез команден ред и/или текстов/графичен интерфейс) програмата да може да работи в пасивен или активен режим: в пасивен режим следи и изпраща предупреждения, в активен режим да може да преустанови изпращането и получаването на мрежови трафик по атакуваните интерфейси в зависимост от възможностите на операционната система.

Да се предвиди възможност за изпращане на различни видове предупреждения: системни журнални файлове (log files), известяване на един или повече потребители, които използват компютъра, изпращане на съобщения чрез e-mail и други.

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


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

8.1. Задание

Да се разшири един от протоколите SMTP, FTP, HTTP, DNS или SSH, реализиран от едно от изброените по-долу сървърни приложения с добавяне на нова команда DBUG. Командата DBUG трябва да предоставя възможност за извършване на поне три от следните дейности:


8.1.1. READ - четене на цял файл или на зададен фрагмент от него

Синтаксис: READ fname [start [end [unit]]]

Table 1. Параметри на командата READ

Параметър Задължителен? Тип Описание
fname да string Име на файл за четене
start не integer Начална позиция за четене
end не integer Крайна позиция за четене
unit не character Единица, в която са зададени параметрите start и end: l за редове, c или b за символи/байтове, k за килобайтове, m за мегабайтове.

Note: Ако start или end започват със знак - (минус), позицията се пресмята от текущия край на файла.


8.1.2. WRITE - запис на последователност от байтове от определена позиция във файла нататък

Синтаксис: WRITE fname start unit truncf string

Table 2. Параметри на командата WRITE

Параметър Задължителен? Тип Описание
fname да string Име на файл за четене
start да integer Начална позиция за четене
unit да character Единица, в която са зададени параметрите start и end: l за редове, c или b за символи/байтове, k за килобайтове, m за мегабайтове.
truncf да integer Ако е различен от 0, файлът трябва да бъде съкратен (truncated) непосредствено до края на записания низ, т.е. записаните символи да се окажат последните символи във файла.
string да string Низ, който да бъде записан във файла.

Note: Ако start започва със знак - (минус), позицията се пресмята от текущия край на файла.


8.1.3. LIST - извеждане на списък на файловете в дадена директория в свободен формат

Синтаксис: LIST dirname

Съдържанието на директорията - списъкът от файлове и информацията за тях - може да бъде изведено в произволен формат, зависещ от операционната система и използваните библиотеки.

Table 3. Параметри на командата LIST

Параметър Задължителен? Тип Описание
dirname да string Име на директория, съдържанието на която ще бъде изведено

8.1.4. EPLF - извеждане на списък на файловете в дадена директория във формат EPLF

Синтаксис: EPLF dirname

Съдържанието на директорията - списъкът от файлове и информацията за тях - трябва да бъде изведено във формата EPLF, описан от проф. Daniel J. Bernstein на http://cr.yp.to/ftp/list/eplf.html.

Table 4. Параметри на командата EPLF

Параметър Задължителен? Тип Описание
dirname да string Име на директория, съдържанието на която ще бъде изведено

8.1.5. MLST - извеждане на списък на файловете в дадена директория във формат MLST

Синтаксис: MLST dirname

Съдържанието на директорията - списъкът от файлове и информацията за тях - трябва да бъде изведено във формат MLST, описан в draft-ietf-ftpext-mlst-16.txt.

Table 5. Параметри на командата MLST

Параметър Задължителен? Тип Описание
dirname да string Име на директория, съдържанието на която ще бъде изведено

8.1.6. EXEC - изпълнение на външна програма

Синтаксис: EXEC progname [args...]

Ако програмата извежда данни на стандартния изход, те трябва да бъдат предадени на клиента като отговор на командата.

Table 6. Параметри на командата EXEC

Параметър Задължителен? Тип Описание
progname да string Име на външната програма, която да бъде изпълнена. Програмата трябва да бъде изпълнена чрез извикване на системна функция, еквивалентна на execlp(3), т.е. ако не съществува файл с посоченото име, то да бъде третирано като име на програма, която да бъде търсена в стандартния път (променливата PATH от обкръжението на изпълняваната програма).
args не string Един или повече параметъра, които да бъдат подадени на командния ред на изпълнената външна програма.

8.1.7. EXSH - изпълнение на интерактивен команден интерпретатор

Синтаксис: EXSH [program-path]

Всички данни, постъпили от клиента в същата сесия, се предават на командния интерпретатор или на програмите, изпълнени от него, като стандартен вход; всички данни, изведени от командния интерпретатор или програмите, изпълнени от него, на стандартния изход или стандартния изход за грешка, се предават на клиента.

Table 7. Параметри на командата EXEC

Параметър Задължителен? Тип Описание
program-path не string Име на външната програма (команден интерпретатор), която да бъде изпълнена. Програмата трябва да бъде изпълнена чрез извикване на системна функция, еквивалентна на execlp(3), т.е. ако не съществува файл с посоченото име, то да бъде третирано като име на програма, която да бъде търсена в стандартния път (променливата PATH от обкръжението на изпълняваната програма).

8.2. Разширяване на протоколи

8.2.1. SMTP - Simple Mail Transfer Protocol

Новата команда DBUG се добавя като SMTP команда, достъпна във всички фази на SMTP сесията. Параметрите се подават в рамките на същия ред текст, съдържащ командата, разделени с интервали; имената на параметрите не се подават, а се подразбират от позицията на параметъра на реда.

Ако командата изисква отговор, той се предава като последователност от байтове или редове текст според нуждата, без изпращане на стандартните за SMTP кодове за резултат/грешка.

Example 1. Пример за използване на DBUG с SMTP

SMTP заявка, която прочита първите два реда от файла /etc/passwd, разположен върху SMTP сървъра:

DBUG read /etc/passwd 1 2 l
# $FreeBSD: src/etc/master.passwd,v 1.34 2003/04/27 05:45:29 imp Exp $
root:*:0:0:Charlie &:/root:/bin/csh

8.2.2. FTP - File Transfer Protocol

Новата команда DBUG се добавя като FTP команда, достъпна във всички фази на FTP сесията. Параметрите се подават в рамките на същия ред текст, съдържащ командата, разделени с интервали; имената на параметрите не се подават, а се подразбират от позицията на параметъра на реда.

Ако командата изисква отговор, той се предава като последователност от байтове или редове текст според нуждата, без изпращане на стандартните за FTP кодове за резултат/грешка.

Example 2. Пример за използване на DBUG с FTP

FTP заявка, която прочита първите два реда от файла /etc/passwd, разположен върху FTP сървъра:

DBUG read /etc/passwd 1 2 l
# $FreeBSD: src/etc/master.passwd,v 1.34 2003/04/27 05:45:29 imp Exp $
root:*:0:0:Charlie &:/root:/bin/csh

8.2.3. HTTP - Hypertext Transfer Protocol

Новата команда DBUG се добавя като нов тип заявка (request type), т.е. на същото ниво като GET, POST и т.н. Форматът на заявката следва стандартния за HTTP формат, като самата команда (READ, LIST, EXEC и т.н.) и параметрите й се подават като URI в следния вид:

     DBUG command=команда&param1=value1&param2=value2 HTTP/1.x
   

В горния пример команда трябва да бъде заместено с името на командата за изпълнение (READ, LIST и т.н.), а param1, param2 и т.н. - с имената на параметрите, както е описано по-горе в заданието. Използваният протокол може да бъде HTTP 1.0 или HTTP 1.1 по избор на клиента (подаващ командата DBUG).

Example 3. Пример за използване на DBUG с HTTP

HTTP заявка, която прочита първите два реда от файла /etc/passwd, разположен върху HTTP сървъра:

DBUG command=read&fname=/etc/passwd&start=1&end=2&unit=l HTTP/1.0
# $FreeBSD: src/etc/master.passwd,v 1.34 2003/04/27 05:45:29 imp Exp $
root:*:0:0:Charlie &:/root:/bin/csh

8.2.4. DNS - Domain Name System

Заявката DBUG се добавя като специална обработка на заявки от тип A за hostnames с top-level domain dbg. Второто ниво на hostname е името на командата, която да бъде изпълнена (READ, LIST и т.н.), а оттам нататък (в обратен на нормалния ред за четене :) следват параметрите. Имената на параметрите не се задават изрично, а се подразбират от позицията в заявката.

Ако командата изисква отговор, той се предава като последователност от байтове в секцията answer на отговора на DNS заявката.

Example 4. Пример за използване на DBUG с DNS

DNS заявка, която прочита първите два реда от файла /etc/passwd, разположен върху DNS сървъра:

%nslookup L.2.1./etc/passwd.read.dbg

Non-authoritative answer:
Name:    L.2.1./etc/passwd.read.dbg
Address: # $FreeBSD: src/etc/master.passwd,v 1.34 2003/04/27 05:45:29 imp Exp $
root:*:0:0:Charlie &:/root:/bin/csh
     

8.2.5. SSH - Secure Shell Protocol

Заявката DBUG се предава като SSH пакет от тип SSH2_MSG_IGNORE, който съдържа данни, започващи със символите DBUG. Останалата част от данните в пакета е командата и параметрите й, подадени както при SMTP и FTP.

Ако командата изисква отговор, той се предава като последователност от байтове в пакет от тип SSH2_MSG_IGNORE.