BG Development


Страници: (22) [1] 2 3 ... последна »  ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> КАК СЕ ПРАВИ ПАКЕТЕН СНИФЪР, как да създадем собствен TCP/IP sniffer
BlackScreen
  Публикувано на: 23-09-2018, 09:25
Quote Post



Име: Георги Тодоров Герасимов
Група: Потребител
Ранг: Посетител

Мнения: 85
Регистриран на: 23.09.18



КАК СЕ ПРАВИ ПАКЕТЕН СНИФЪР (TCP/IP SNIFFER)

(въведение)


Днес ще поговорим по въпроса, който вълнува всеки истински ентусиаст, а именно: Как се прави пакетен sniffer?

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

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

Защо е така?

Причината е, че по този начин студентите получават перфектни практически познания за това какво е мрежова сигурност, как на практика изглежда OSI, как функционира TCP/IP, как се ползват сокети и пр.. Всичко това са практически познания, които са солидна база за да продължим с истинското обучение. Това няма нищо общо със сортировки и или рекурсиони процедури. Това, което доста често се забравя е, че инженерните методи, дори обвързаните с висшата математика, се различават съществено от фундаменталните. Просто инженерните са частен случай на фундаменталното познание.
И ако ми позволите нещо, което също се забравя:

INTERNET Е СЪЗДАДЕН ЗА ВОЕННИ НУЖДИ. ЦЕЛТА Е ДА СЕ СЪХРАНЯТ КОМУНИКАЦИИТЕ СЛЕД ЯДРЕНА АТАКА.

Никога не забравяйте това. Повярвайте предстои много внимателно да анализираме защо тази истина е толкова важна и каква е ролята и в съвременните компютърни системи.
Сега да се върнем на пакетния снифър.

1. ЦЕЛ

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

2. АНАЛИЗ

Входящият и изходящ трафик се осъществява посредством пакети.
Всеки един пакет се състои от заглавна част (header) и област, съдържаща полезната информация.
Полезната информация може да бъде в двоичен или в текстови вид.
Устройствата, през които преминават пакетите комуникират при използване на TCP/IP протокол.
Всяко апаратно устройство има свой MAC адрес и евентуално IP такъв.
Условно задачата може да бъде разделена на две направления както следва:

- Прихващане на входящите и изходящи пакети;
- Анализиране на заглавната част и съдържанието на пакета.

Това, което искаме да получим е:

- Идентификатор на пакета;
- Дължина на пакета;
- Жизнен цикъл на пакета (TTL);
- Използван протокол;
- Адрес и порт, от който се изпраща пакета;
- Адрес и порт, на който се получава пакета;
- Съдържание на пакета, във вид, който подлежи на анализ;
- Друг вид информация, ако е възможно (например времеви маркери).

3. ПОСЛЕДОВАТЕЛНОСТ НА ИЗПЪЛНЕНИЕ

Последователността е елементарна и мисля, че сме я коментирали многократно.

1. Получаваме списък с всички възможни интерфейси, които комуникират с други устройства, посредством TCP/IP.
2. Определяме кой от интерфейсите е активен.
3. Създаваме сокет за съответния интерфейс.
4. В отделен поток започваме да "слушаме" сокета и това продължава, докато не ни писне или ни стане скучно.
5. Получените данни се извеждат посредством синхронизиран процес в удобен за потребителя интерфейс.
6. Това, което сме направили трябва да работи ВЯРНО И НАДЕЖДНО.
7. В крайна сметка ИСКАМЕ ДА НАПРАВИМ НЕЩО БЪЛГАРСКО, А НЕ ДА ХВАЛИМ ТОВА, КОЕТО НЯКОЙ НЯКЪДЕ БИЛ НАПРАВИЛ. Потребителите се учат как се ползва. Ние се учим как се прави, което е различно.

Това е. Друго няма.

Може евентуално да се замислим дали да не записваме получената информация поточно във файл или да я записваме в някаква база данни, но това е друга тема.
Сега е важно да разберем, че ТОВА ДА СЕ НАПРАВИ СНИФЪР Е НЕЩО, КОЕТО ПРОСТО ИЗИСКВА ДА ЧЕТЕМ СТАНДАРТИ И НИЩО ДРУГО.


4. КАКВО НИ Е НЕОБХОДИМО

Преди всичко достъп до следните документи:

1. RFC 791 ( https://tools.ietf.org/html/rfc791 ), който ще използваме за да научим всичко за IP;
2. RFC 793 ( https://tools.ietf.org/html/rfc793 ), който ще използваме за да научим всичко за TCP;
3. RFC 768 ( https://tools.ietf.org/html/rfc768 ), който ще използваме за да научим всичко за UDP;
3. RFC 792 ( https://tools.ietf.org/html/rfc792 ), който ще използваме за да научим всичко за ICMP;


И сега нещо много забавно.

Всякакви индивиди ще ви убеждават, колко динамично са се развили технологиите. Ние обаче не им вярваме. Ние ЧЕТЕМ ВНИМАТЕЛНО.

Четем и какво виждаме?

Всички тези документи са от ... 1981 година, когато някои от вас дори не са били родени.
Не е зле да помислите върху това.

Сега обаче ще си сипем чаша кафе, ще ИЗВАДИМ ЛИСТ И МОЛИВ И ЩЕ ПРОЕКТИРАМЕ СТРУКТУРАТА НА НАШЕТО БЪДЕЩО ТВОРЕНИЕ.

Това мнение е било редактирано от BlackScreen на 23-09-2018, 09:26
PMEmail Poster
Top
BlackScreen
  Публикувано на: 23-09-2018, 09:34
Quote Post



Име: Георги Тодоров Герасимов
Група: Потребител
Ранг: Посетител

Мнения: 85
Регистриран на: 23.09.18



КАК СЕ ПРАВИ ПАКЕТЕН СНИФЪР (TCP/IP SNIFFER)
( част I )


И така след две кафета, набързо надраскан проект върху лист от тетрадка и малко писане на код, нашият sniffer е готов. Нека видим как изглежда в първоначалния му вид (държа да подчертая, че това е работен проект).

Мисля, че не е нужна кой знае каква подготовка за да видим какво получаваме като резултати.


user posted image



Контролерът е Realtek PCIe GBE ( IPv4 - 192.168.1.2 ).

След като се включи процесът на сканиране ние получаваме текуща информация за входящите и изходящи пакети. Ясно се вижда заглавната част на IP, както и съдържанието на пакета.
Обръщам внимание, че в момента не се визуализира заглавната част на TCP или UDP пакетите, така както го правим за IP.
Все пак за да внесем яснота по въпроса нека видим каква точно информация получаваме и колко от нея виждаме.
За тази цел ще разгледаме част от променливите, които програмата ползва.

И така първо ще се запознаем със структурата на заглавната част на IP.

type

// IP заглавна част (IP header)
// Пълно описание в RFC 791

TIPHeader = packed record
IPHeader_VerLen: UCHAR; // Версия и дължина на заглавната част
IPHeader_ToS: UCHAR; // Тип на използвания сървис
IPHeader_Length: USHORT; // Дължина на целия пакет
IPHeader_ID: USHORT; // Идентификация
IPHeader_Offset: USHORT; // Флагове и отместване
IPHeader_TTL: UCHAR; // Жизнен цикъл на пакета в ms
IPHeader_Protocol: UCHAR; // Протокол
IPHeader_xSum: USHORT; // Контролна сума
IPHeader_Src: ULONG; // IP-адрес на подателя (sender)
IPHeader_Dest: ULONG; // IP-адрес на получателя (receiver)
end;

PIPHeader = ^TIPHeader;

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

type

// IP заглавна част (IP header)
// Пълно описание в RFC 791

TIPHeader = packed record
IPHeader_VerLen: PAnsiChar; // Версия и дължина на заглавната част
IPHeader_ToS: PAnsiChar; // Тип на използвания сървис
IPHeader_Length: Word; // Дължина на целия пакет
IPHeader_ID: Word; // Идентификация
IPHeader_Offset: Word; // Флагове и отместване
IPHeader_TTL: PAnsiChar; // Жизнен цикъл на пакета в ms
IPHeader_Protocol: PAnsiChar; // Протокол
IPHeader_xSum: Word; // Контролна сума
IPHeader_Src: DWord; // IP-адрес на подателя (sender)
IPHeader_Dest: DWord; // IP-адрес на получателя (receiver)
end;

PIPHeader = ^TIPHeader;

Разликата е в това как декларирам променливите.

В първият случай го правя така както се прави на C++ или C#. Използвам

UCHAR - Осем битово (8 bit) ПОЛОЖИТЕЛНО цяло число. Променя се в интервала 0 до 255 (0000 0000 до 1111 1111).
USHORT - 16 битово цяло число, което може да приема само положителни стойности в интервала от 0 до 65535 ( 0000 0000 0000 0000 до 1111 1111 1111 1111).
ULONG - 32 битово цяло число, което може да приема само положителни стойности. Взима стойности в интервала от 0 до 18 446 744 073 709 551 615..

Във втория случай ползвам класическа Delphi декларация.

Byte - Осем битово (8 bit) ПОЛОЖИТЕЛНО цяло число. Променя се в интервала 0 до 255 (0000 0000 до 1111 1111).
Word - дума - 16 битово цяло число, което може да приема само положителни стойности в интервала от 0 до 65535 ( 0000 0000 0000 0000 до 1111 1111 1111 1111)
DWord - двойна дума - 32 битово цяло число, което може да приема само положителни стойности. Взима стойности в интервала от 0 до 18 446 744 073 709 551 615.

И сега искам много да внимавате.

Една от най-често допусканите грешки е, че се слага знак на равенство между DWord и Cardinal.

Cardinal е GENERIC INTEGER, което означава, че е възможно на някои платформи числото ДА НЕ Е 32 бита, да да има друга дължина

DWord е FUNDAMENTAL, което означава, че независимо на каква платформа изпълнявате програмата (и под каква ОС) това ВИНАГИ ЩЕ БЪДЕ 32 бита.

Малко камъче, което често прави на пух и прах и най-добре написаното приложение.

Защо направих това?

Исках да ви покажа, че НА DELPHI МОГА ДА ДЕКЛАРИРАМ ПРОМЕНЛИВИ, ПО НАЧИН БЛИЗЪК ДО ТОЗИ В C++ ИЛИ C#. Лично за мен е без значение, но ... по-добре е да следваме доказали своята ефективност и надеждност решения, защото в internet е пълно с нефункциониращ (или неправилно функциониращ код).

А сега нека разгледаме структурата на заглавната част (header) на TCP пакета ...

// TCP заглавна част (TCP header)
// Пълно описание в RFC 793

TTCPHeader = packed record
SourcePort: USHORT; // Порт на подателя
DestinationPort: USHORT; // Порт на получателя
SequenceNumber: ULONG; // Номер на последователност
AcknowledgeNumber: ULONG; // Номер на потвърждаване
AataOffset: UCHAR; // Отместване на частта за данни
Flags: UCHAR; // Флагове
Windows: USHORT; // Размер на прозореца
Checksum: USHORT; // Контролна сума
UrgentPointer: USHORT; // Приоритет
end;

PTCPHeader = ^TTCPHeader;

Искам да обърнете специално внимание на текста, оцветен в червен цвят.

ВНИМАВАЙТЕ МНОГО ДОБРЕ.

ОТ ЗАГЛАВНАТА ЧАСТ НА IP ПОЛУЧАВАМЕ IP АДРЕСИТЕ НА ПОДАТЕЛЯ И ПОЛУЧАТЕЛЯ НА ПАКЕТИТЕ.

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

Започвате ли да разбирате каква е разликата между IP и TCP?

Погледнете структурата на техните заглавни части (на header-ите). ТЯ Е РАЗЛИЧНА. Това е важно да бъде разбрано.

И още ...

Направи ли ви впечатление, че до момента и дума не е станало каква операционна система ползваме?
Знаете ли защо е така?

ЗАЩОТО ТОВА НЯМА АБСОЛЮТНО НИКАКВО ЗНАЧЕНИЕ.


На програмата и е все тази дали ползвате Linux, UNIX, Windows, iOS, OS X, Android, Xenix или каквото се сетите. Нейната задача е да следи какво се получава и какво излиза от избраният комуникационен интерфейс. Това е.



Забележка: Както предполагам сте забелязали проектът е написан на Delphi. Основната причина за това е, че към настоящият момент това е единственият програмен език в света, който е сертифициран по CC, категория 7 (моля да не се бърка с cat.7 в СКС, защото е нещо много различно.

Следва продължение ...

Това мнение е било редактирано от BlackScreen на 23-09-2018, 09:46
PMEmail Poster
Top
JanBirdX
Публикувано на: 23-09-2018, 09:52
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1542
Регистриран на: 21.02.05



не виждам кода който се закача за интерфейса? и защо ли си мисля че е ос зависим.
PMEmail Poster
Top
BlackScreen
  Публикувано на: 23-09-2018, 09:58
Quote Post



Име: Георги Тодоров Герасимов
Група: Потребител
Ранг: Посетител

Мнения: 85
Регистриран на: 23.09.18



KAK СЕ ПРАВИ ПАКЕТЕН СНИФЪР (TCP/IP SNIFFER)
(част II)


Хубаво е, че правим TCP/IP снифър, но какво реално ще получим като информация?

Обърнахте ли внимание на декларативната част, която публикувах? Какво ви направи впечатление? Какво не е наред?

Спомняте ли си, че написах, че е важно да получим ВЯРНА информация?
Е, информацията е вярна, снифърът работи прекрасно, но ... ИНФОРМАЦИЯТА НЕ Е ПЪЛНА.

И точно тук става доста интересно.

КАКВО Е КАЧЕСТВО НА ОБСЛУЖВАНЕТО?

Запознати ли сте с Quality of Service (QoS)?

Това е нещо много интересно, което касае анализа на заглавната част (header) на IP пакета.
Терминът Quality of Service (QoS) обединява три термина както следва:

ToS - Type of Service;
DSCP - Differentiated Services Code Point
CoS - Class of Service.
Всички те са обвързани с подредбата и обработката на последователността на обслужване на пакетите, в зависимост от приоритета, който им е зададен.

Тази обработка се извършва посредством един от следните алгоритми:

DWRED - Distributed Weighted Random Early Detection;
WFQ - Weighted Fair Queueing);
CAR - Committed Access Rate.
КАКВО МОЖЕ ДА НАУЧИМ ОТ АНАЛИЗА НА QoS?

Много неща могат да се научат ако се анализират първите шест, старши бита на DSCP.
Нека отново разгледаме структурата на заглавната част на IP пакета.


user posted image



От началото на пакета до четвъртия бит имаме информация за версията (Version) тя може да изглежда така: 1011 (четири бита).

От бит 4 до бит 7 (още една тетрада или казано простичко - четири бита) имаме информация за ДЪЛЖИНАТА НА ЗАГЛАВНАТА ЧАСТ НА IP ПАКЕТА (
Internet Header Length - IHL). Тази дължина е винаги по-малка от ДЪЛЖИНАТА НА ЦЕЛИЯ ПАКЕТ (Total Length - битове от 16 до 31)

И сега обърнете внимание на Differentiated Services Code Point (DSCP).

ТОВА СА ТОЧНО ТЕЗИ 6 (ШЕСТ) БИТА, ОТ КОИТО МОЖЕ ДА ПОЛУЧИМ ИНФОРМАЦИЯ ЗА QoS.

От тях може да научим не само приоритета на обслужване на пакетите, но също така и приоритета на отстраняване на пакетите.

АНАЛИЗЪТ НА ТЕЗИ БИТОВЕ МОЖЕ ДА НИ ПОКАЖЕ КАКВА ИНФОРМАЦИЯ ТЕЧЕ ПО МРЕЖАТА. МОЖЕ ДА РАЗБЕРЕМ ДАЛИ СЕ ПРЕДАВА ГЛАСОВА ИНФОРМАЦИЯ, ДАЛИ СЕ ПРЕДAВА ПОТОЧНО ВИДЕО И ПР. И ПР..

ПРОСТО ВСЕКИ ВИД ИНФОРМАЦИЯ ПОЛЗВА РАЗЛИЧЕН ПРИОРИТЕТ НА ОБСЛУЖВАНЕ НА IP.



Стойност Приоритет

0 ( 0000 ) routine
1 ( 0001 ) priority
2 ( 0010 ) immediate
3 ( 0011 ) flash
4 ( 0100 ) flash-override
5 ( 0101 ) critical
6 ( 0110 ) internet
7 ( 0111 ) network



И за да не бъдем голословни, нека видим как изглежда това, ако ЗАПИТАМЕ УЧТИВО РУТЕРА.

Router(config)# class-map match-all VOIP

1751-uut1(config-cmap)# match ip dscp ?

<0-63> Differentiated services codepoint value

af11 Match packets with AF11 dscp (001010)
af12 Match packets with AF12 dscp (001100)
af13 Match packets with AF13 dscp (001110)
af21 Match packets with AF21 dscp (010010)
af22 Match packets with AF22 dscp (010100)
af23 Match packets with AF23 dscp (010110)
af31 Match packets with AF31 dscp (011010)
af32 Match packets with AF32 dscp (011100)
af33 Match packets with AF33 dscp (011110)
af41 Match packets with AF41 dscp (100010)
af42 Match packets with AF42 dscp (100100)
af43 Match packets with AF43 dscp (100110)
cs1 Match packets with CS1(precedence 1) dscp (001000)
cs2 Match packets with CS2(precedence 2) dscp (010000)
cs3 Match packets with CS3(precedence 3) dscp (011000)
cs4 Match packets with CS4(precedence 4) dscp (100000)
cs5 Match packets with CS5(precedence 5) dscp (101000)
cs6 Match packets with CS6(precedence 6) dscp (110000)
cs7 Match packets with CS7(precedence 7) dscp (111000)
default Match packets with default dscp (000000)
ef Match packets with EF dscp (101110)

Router1(config-cmap)# match ip dscp af31

В скобите след dscp може да видите, резултатите в двоичен вид.

Има и нещо по-хубаво. Нарича се policy-map. icon_lol.gif

policy-map Police-GE0/1
class Voice-GE0/1
priority 5000
set dscp ef
class Route-GE0/1
set dscp cs6
priority 1000
class Signal-GE0/1
set dscp cs3
priority 4500
class class-default
fair-queue

Но сега да се върнем към нашият пакетен снифър и ДА ИЗВЪРШИМ МАЛКА КОРЕКЦИЯ В ДЕКЛАРАЦИЯТА.



// IP заглавна част (IP header)
// Пълно описание в RFC 791

TIPHeader = packed record
Version: TBits; // Версия
HeaderLength: TBits; // Дължина на заглавната част
DSCP: TBits; // Differenciated Services Code Point
ECN: TBits; // Уведомяване за пренатовареност - Explicit Congestion Notification (ECN) RFC 3168 (2 бита)
ToS: Byte; // Тип на използвания сървис
PacketLength: Word; // Дължина на целия пакет
ID: Word; // Идентификация
Flags: TBits; // Флагове
FragmentOffset: Word; // Отместване на фрагмента
TTL: Byte; // Жизнен цикъл на пакета в ms
Protocol: Byte; // Протокол
CheckSum: Word; // Контролна сума
Sender: DWord; // IP-адрес на подателя
Recipient: DWord; // IP-адрес на получателя
Options: DWord; // Параметри ако HeaderLength > 5
end;

PIPHeader = ^TIPHeader;


ТОВА ВЕЧЕ Е ПРОФЕСИОНАЛНО РЕШЕНИЕ И ИМА ОГРОМНА РАЗЛИКА МЕЖДУ ВСИЧКО, КОЕТО МАСОВО СЕ ТИРАЖИРА В INTERNET.

Това ще ни позволи да прихващаме пакетна стеганография и да не допускаме някой да имплантира нежелано съдържание в пакетите.

Мисля, че сами може да направите сравнение.
PMEmail Poster
Top
BlackScreen
Публикувано на: 23-09-2018, 10:06
Quote Post



Име: Георги Тодоров Герасимов
Група: Потребител
Ранг: Посетител

Мнения: 85
Регистриран на: 23.09.18



Малки разяснения ...

Заглавната част на IP пакета се състои от 5 (пет) октета (секции с дължина 32 Bit) и една допълнителна секция Options с дължина 12 Bit.
Вътрешно тези секции са разделени на отделни сегменти, всеки с различна дължина. Всеки един сегмент съдържа важна информация за IP, която е записана в двоичен вид (под формата на единици и нули).
Структурата на IP пакета има следния вид:

Октет 0 

1. Version - Информация за версията, която се ползва. Битове от 0 до 3. Дължина 4 бита (една тетрада - 4 Bit).

0 1 2 3
+---+---+---+
| Version |
+---+---+---+


2. Internet Header Length (IHL) - Дължина на заглавната част на пакета. Служи за анализ на целостта, както и като своеобразна контрола за внесени изменения в заглавната част. Битове от 4 до 7. Дължина 4 бита (една тетрада - 4 Bit). Максимална дължина - 1111 в двоичен код.

4 5 6 7
+---+---+---+
| IHL |
+---+---+---+


3. Differentiated Services Code Point (DSCP) - Един от най-важните за анализ параметри. Съдържа информация за приоритета на пакета, задръжката и производителността. Основен елемент на Quality of Service (QoS). От тук получаваме информация за управлението на трафика. Битове от 8 до 14, разпределени както следва:

Битове от 8 до 10 - Приоритет на пакета

000 - Best effort - Нормален приоритет;
001 - Class 1;
010 - Class 2;
011 - Class 3;
100 - Class 4;
101 - Express Forwarding (EF);
110 - Stays the same (used for IP routing protocols);
111 - Stays the same (link layer and routing protocol keep alive);

Забележка: Това поле е тема на отделно обсъждане. За повече информация RFC 2475 ( https://tools.ietf.org/html/rfc2474 ) и Cisco: Implementing Quality of Service Policies with DSCP ( https://www.cisco.com/c/en/us/support/docs/...dscpvalues.html ), от където вземаме и примерите, които подлагаме на анализ;


Бит 11 - Задръжка на пакета ( 0 - нормално задържане, 1 - ниско ниво на задържане );

Бит 12 - Производителност ( 0 - нормална, 1 - висока );

8 9 10 11 12
+---+---+---+---+
| DSCP |
+---+---+---+---+


4. Explicit Congestion Notification (ECN) съгласно RFC 3168 - Степен на надеждност. Битове от 13 до 15, разпределени както следва:

Бит 13 - Надеждност ( 0 - нормална, 1 - висока )

Битове 14 и 15 са резервни.

13 14 15
+---+---+
| ECN |
+---+---+


ВАЖНО!

Когато обединим DSCP и ECN (битове от 8 до 15 - дължина на секцията 8 Bit) получаваме Type of Service (ToS).

ToS e термин, който към момента вече не е актуален. С Навлизането на IPv6 се използва термина Traffic Class, но структурата е напълно идентична с тази на ToS.

Структурата на ToS има следния вид:

8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+
| DSCP | ECN | => Type of Service (IPv4) or Traffice Class (IPv6)
+---+---+---+---+---+---+---+


Сега нека направим анализ на реални данни (нарича се "сух пробег").


ПРИМЕР:

1. Нека анализираме следният резултат, получен от направена заявка към Cisco рутер.

af11 Match packets with AF11 dscp (001010)

Записваме информацията в следния вид: 001-0-1-0** ( битовете са 8, но последните два не са изписани и сме ги заменили със *)
Сега анализираме по групи, в съответствие с това, което вече знаем:

Първите три бита са: 001 - Пакетът е с висок приоритет
Четвъртият бит е със значение 0 - Пакетът е с нормално задържане
Петият бит е със значение 1 - Пакетът е с висока производителност
Шестият бит е със значение 0 - Пакетът е с нормална надеждност

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

cs7 Match packets with CS7(precedence 7) dscp (111000)

Записваме информацията в следния вид: 111-0-0-0** ( битовете са 8, но последните два не са изписани и сме ги заменили със *)

Сега анализираме по групи, в съответствие с това, което вече знаем:

Първите три бита са: 111 - Stays the same приоритет на пакета (по Cisco)
Четвъртият бит е със значение 0 - Пакетът е с нормално задържане
Петият бит е със значение 0 - Пакетът е с ниска производителност
Шестият бит е със значение 0 - Пакетът е с нормална надеждност

И за да завършим разглеждането на първият октет ...

5. Total Length - Информация за дължината на пакета. Тази дължина е дължината на заглавието и данните взети заедно. Битове от 16 до 31. Дължина 16 Bit.

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Total Length |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+


Както виждате само от анализа на октет 0 от заглавната част на IP пакета, ние получихме доста интересна информация, която може да ни помогне при решаване на въпроси, свързани със сигурността на обмена на данни.

Надявам се това да е от полза за младите колеги. Много от така изнесената информация няма да намерите на български език, а още по-трудно е да я откриете систематизирана по този начин.
Тази информация е изключително важна защото без нея на практика вие няма да знаете как да използвате анализаторът на IP пакети (който е основен елемент от нашия sniffer).
Въпросът е в това, че освен автоматично да събираме информация за входящите и изходящи пакети ние би следвало да автоматизираме и процеса на последващият им анализ.

Ако внимателно сте прочели написаното вие вече сте добили представа как точно общуват машините (устройствата) една с друга. Разбирането на тази логика е от изключително значение за по нататъшните ни разглеждания.

А сега малко за избора на програмен език и защо ползваме Delphi?

Спомняте ли си как точно дефинирахме DSCP в нашият снифър?

Ние го направихме по следния начин:

DSCP: TBits; // Differenciated Services Code Point


На практика DSCP е променлива, която се състои от поредица от битове.
Нека DSCP да е със значение 00101000 ( осем бита или един байт - TWord)
Ако го разгледаме като последователност (масив, едномерен масив) от битове, ще имаме следното:

DSCP[1]:= 0;
DSCP[2]:= 0;
DSCP[3]:= 1;
DSCP[4]:= 0;
DSCP[5]:= 1;
DSCP[6]:= 0;
DSCP[7]:= 0;
DSCP[8]:= 0;

Ако искаме да проверим каква е стойността на петият бит, простo използваме следният код:

if DSCP[5] = TRUE then Result:= 'Пакетът е с висока производителност';


Как се чете това?

Ако петият бит от DSCP е равен на 1 ( логическa ИСТИНА - TRUE ) тогава пакетът е с висока производителност.

Както виждате ние извършваме анализ на изключително ниско ниво (анализ на ниво битове), без да ползваме assembler.
Написаното е ясно и лесно се чете.

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

Това мнение е било редактирано от BlackScreen на 23-09-2018, 10:09
PMEmail Poster
Top
BlackScreen
  Публикувано на: 23-09-2018, 10:13
Quote Post



Име: Георги Тодоров Герасимов
Група: Потребител
Ранг: Посетител

Мнения: 85
Регистриран на: 23.09.18



ЗАЩО Е НУЖНО САМИ ДА СИ ПРАВИМ SNIFFER?


Защо наистина? Та в internet пълно с напълно безплатни снифъри, които можем да си изтеглим и да ползваме.

Имат големи възможности и са много cool ...

ДА. ТОВА Е ТАКА, НО ТОЧНО ТАМ Е НАЙ-ГОЛЯМАТА ВИ ЗАБЛУДА!


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

Мислите, че ви лъжа? Мислите, че старецът просто си пише разни глупости за да се прави на велик? Добре. Нека да видим.

Какво прави стандартният пакетен снифър? Най-грубо казано прихваща два или три протокола (основно TCP и UDP) и ако е добре направен може да извършва някакъв статистически анализ.

Сега да видим какви протоколи прихваща това, което се учим как се прави. Е, не е кой знае какво но ето списъка с протоколите, които прихваща и анализира.

0 HOPOPT, IPv6 Hop-by-Hop Option. [ RFC 2460 ]
1 ICMP, Internet Control Message Protocol. [ RFC 792 ]
2 IGAP, IGMP for user Authentication Protocol. IGMP, Internet Group Management Protocol. RGMP, Router-port Group Management Protocol. [ RFC 1112 ]
3 GGP, Gateway to Gateway Protocol. [ RFC 823 ]
4 IP in IP encapsulation. [ RFC 2003 ]
5 ST, Internet Stream Protocol. [ RFC 1190, RFC 1819 ]
6 TCP, Transmission Control Protocol. [ RFC 793 ]
7 UCL, CBT.
8 EGP, Exterior Gateway Protocol. [ RFC 888 ]
9 IGRP, Interior Gateway Routing Protocol.
10 BBN RCC Monitoring.
11 NVP, Network Voice Protocol. [ RFC 741 ]
12 PUP.
13 ARGUS.
14 EMCON, Emission Control Protocol.
15 XNET, Cross Net Debugger. [ IEN 158 ]
16 Chaos. 
17 UDP, User Datagram Protocol. [ RFC 768 ]
18 TMux, Transport Multiplexing Protocol. [ IEN 90 ]
19 DCN Measurement Subsystems.
20 HMP, Host Monitoring Protocol. [ RFC 869 ]
21 Packet Radio Measurement.
22 XEROX NS IDP.
23 Trunk-1.
24 Trunk-2.
25 Leaf-1.
26 Leaf-2.
27 RDP, Reliable Data Protocol. [ RFC 908 ]
28 IRTP, Internet Reliable Transaction Protocol. [RFC 938 ]
29 ISO Transport Protocol Class 4. [RFC 905 ]
30 NETBLT, Network Block Transfer.
31 MFE Network Services Protocol.
32 MERIT Internodal Protocol.
33 DCCP, Datagram Congestion Control Protocol.
34 Third Party Connect Protocol.
35 IDPR, Inter-Domain Policy Routing Protocol.
36 XTP, Xpress Transfer Protocol.
37 Datagram Delivery Protocol.
38 IDPR, Control Message Transport Protocol.
39 TP++ Transport Protocol.
40 IL Transport Protocol.
41 IPv6 over IPv4. [RFC 2473 ]
42 SDRP, Source Demand Routing Protocol.
43 IPv6 Routing header.
44 IPv6 Fragment header.
45 IDRP, Inter-Domain Routing Protocol.
46 RSVP, Reservation Protocol.
47 GRE, General Routing Encapsulation.
48 DSR, Dynamic Source Routing Protocol.
49 BNA.
50 ESP, Encapsulating Security Payload.
51 AH, Authentication Header.
52 I-NLSP, Integrated Net Layer Security TUBA.
53 SWIPE, IP with Encryption.
54 NARP, NBMA Address Resolution Protocol.
55 Minimal Encapsulation Protocol.
56 TLSP, Transport Layer Security Protocol using Kryptonet key management.
57 SKIP.
58 ICMPv6, Internet Control Message Protocol for IPv6. MLD, Multicast Listener Discovery.
59 IPv6 No Next Header.
60 IPv6 Destination Options.
61 Any host internal protocol.
62 CFTP.
63 Any local network.
64 SATNET and Backroom EXPAK.
65 Kryptolan.
66 MIT Remote Virtual Disk Protocol.
67 Internet Pluribus Packet Core.
68 Any distributed file system.
69 SATNET Monitoring.
70 VISA Protocol.
71 Internet Packet Core Utility.
72 Computer Protocol Network Executive.
73 Computer Protocol Heart Beat.
74 Wang Span Network.
75 Packet Video Protocol.
76 Backroom SATNET Monitoring.
77 SUN ND PROTOCOL-Temporary.
78 WIDEBAND Monitoring.
79 WIDEBAND EXPAK.
80 ISO-IP.
81 VMTP, Versatile Message Transaction Protocol.
82 SECURE-VMTP
83 VINES.
84 TTP.
85 NSFNET-IGP.
86 Dissimilar Gateway Protocol.
87 TCF.
88 EIGRP.
89 OSPF, Open Shortest Path First Routing Protocol. MOSPF, Multicast Open Shortest Path First.
90 Sprite RPC Protocol.
91 Locus Address Resolution Protocol.
92 MTP, Multicast Transport Protocol.
93 AX.25.
94 IP-within-IP Encapsulation Protocol.
95 Mobile Internetworking Control Protocol.
96 Semaphore Communications Sec. Pro.
97 EtherIP.
98 Encapsulation Header.
99 Any private encryption scheme.
100 GMTP.
101 IFMP, Ipsilon Flow Management Protocol.
102 PNNI over IP.
103 PIM, Protocol Independent Multicast.
104 ARIS.
105 SCPS.
106 QNX.
107 Active Networks.
108 IPPCP, IP Payload Compression Protocol. [ RFC 2393 ]
109 SNP, Sitara Networks Protocol.
110 Compaq Peer Protocol.
111 IPX in IP.
112 VRRP, Virtual Router Redundancy Protocol. [RFC 3768, RFC 5798 ]
113 PGM, Pragmatic General Multicast.
114 any 0-hop protocol.
115 L2TP, Level 2 Tunneling Protocol. [ RFC 3931 ]
116 DDX, D-II Data Exchange.
117 IATP, Interactive Agent Transfer Protocol.
118 ST, Schedule Transfer.
119 SRP, SpectraLink Radio Protocol.
120 UTI.
121 SMP, Simple Message Protocol.
122 SM.
123 PTP, Performance Transparency Protocol.
124 ISIS over IPv4.
125 FIRE.
126 CRTP, Combat Radio Transport Protocol. ( Признавам, че този ми е любим )
127 CRUDP, Combat Radio User Datagram.
128 SSCOPMCE.
129 IPLT.
130 SPS, Secure Packet Shield.
131 PIPE, Private IP Encapsulation within IP.
132 SCTP, Stream Control Transmission Protocol.
133 Fibre Channel. [ RFC 6172 ]
134 RSVP-E2E-IGNORE. [ RFC 3175 ]
135 Mobility Header. [ RFC 3775 ]
136 UDP-Lite, Lightweight User Datagram Protocol. [ RFC 3828 ]
137 MPLS in IP. [ RFC 4023 ]
138 MANET protocols. [ RFC 5498 ]
139 HIP, Host Identity Protocol. [ RFC 5201 ]
140 Shim6, Level 3 Multihoming Shim Protocol for IPv6. [ RFC 5533 ]
141 WESP, Wrapped Encapsulating Security Payload. [ RFC 5840 ]
142 ROHC, RObust Header Compression. [ RFC 5858 ]

. . .

и т.н и т.н.


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

Ние нямаме такива претенции. Ние искаме ТОВА, КОЕТО ПРАВИМ ДА РАБОТИ ТАКА, ЧЕ С НЕГО ДА МОЖЕ ДА СИ ВЪРШИМ РАБОТАТА.

Ние правим работен инструмент, а не детска играчка.
PMEmail Poster
Top
BlackScreen
  Публикувано на: 23-09-2018, 10:17
Quote Post



Име: Георги Тодоров Герасимов
Група: Потребител
Ранг: Посетител

Мнения: 85
Регистриран на: 23.09.18



KAK СЕ ПРАВИ ПАКЕТЕН СНИФЪР (TCP/IP SNIFFER)
(част III)


ТЕСТВАНЕ НА НАПРАВЕНОТО ДО МОМЕНТА

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

Ето и първите резултати:

Едно от малките подобрения е възможността да се визуализира детайлна информация, за заглавната част на IP, която както знаем се отличава от заглавните части на TCP, UDP и пр..
Обърнете внимание, че тук информацията се извежда в двоичен вид, така както е описана в RFC, което позволява бърз контрол и проверка за наличие на пакетна стеганография.
В същото време информацията се извежда в текстови вид (удобен за анализ), като и тук има специфика. Освен прилагане на последнитте нововъведения (най-вече тези наложени от Cisco) се запазва и познатата и много удобна форма на ToS, която ни предоставя доста богата информация.
Извеждането на вида на използвания протокол е в пълно съответствие с утвърдените норми на RFC и се изписва така както трябва. Към това са добавени и времеви маркери, за да бъде документацията издържана.
Заглавната част се визуализира октет по октет, като е запазена разписаната в документацията номерация (0, 1, 2 и т.н.).

user posted image



Информацията за съдържанието на пакетите се извежда освен като символен низ и в шестнадесетичен код и в двоичен такъв. Ясно се вижда къде ESET се е намесил при отваряне на web-ресурс.
Получените данни могат да се записват както в текстови файл (поточно или по друг начин) така и в СУБД по избор на потребителя за последващ статистически анализ.

Та въпросът ми е: Защо ние да не можем да правим по добри снифъри от онези другите?
Къде ни е проблемът? Тази "играчка" е просто нещо спомагателно, а не проект, който е финансиран с мега бюджет или разчита на бизнес ангели или инвеститори.
Най-забавно е, че кодът е абсолютно патентно чист. На практика от internet са ползвани само документите, касаещи RFC и нищо друго.
Ядрото на крайния продукт е описано тук в тази тема.

Как работи системата?

Ами ... Много просто работи. icon_lol.gif

1. Сканираме за мрежови устройства.
2. Виждаме кое от тях се използва за комуникация.
3. Създаваме сокет.
4. Сокетът се пуска "да слухти" в поток докато не му кажем да спре да го прави.
5. Когато нещо се "появи" първо анализираме IP протокола.
6. След като сме го направили и знаем какъв пакет влиза или излиза (дали е TCP, UDP или някой друг от онези в списъка) ние анализираме заглавната му част и съдържанието ми, като ги привеждаме в "приличен вид".
7. Когато ни писне спираме процеса и отиваме да пием бира.

Това е. От това по-просто не знам.

Следващата (и много по забавна стъпка) е да накараме това нещо кротко да филтрира входящият и изходящ трафик.
За образователни цели, ще следим всички процеси за да се учим. Съвсем друг е въпросът, че това "чудо" може да се пусне като процес, който ще бъде напълно невидим за всичко. Ако добавим към това и проверка за debug и други благини става доста забавно. icon_lol.gif

РАЗРАБОТКАТА НА СНИФЪР Е НЕЩО ХУБАВО, ЗАЩОТО НИ УЧИ КАК ДА ИЗПОЛЗВАМЕ СОКЕТИ!


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

Надявам се, че бях полезен.

Това мнение е било редактирано от BlackScreen на 23-09-2018, 10:18
PMEmail Poster
Top
gat3way
Публикувано на: 23-09-2018, 10:19
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 3110
Регистриран на: 22.06.12



Това прилича на превод от някой руски сайт на нещо писано някъде началото на века...
PMEmail Poster
Top
BlackScreen
  Публикувано на: 23-09-2018, 10:35
Quote Post



Име: Георги Тодоров Герасимов
Група: Потребител
Ранг: Посетител

Мнения: 85
Регистриран на: 23.09.18



Какво научихме до тук?

Ако трябва да бъда откровен научихме следното:

1. Delhi е изключително мощен език за програмиране и базов инструмент при разработката на съвременни кибернетични оръжия (CGE системи).
2. Само по себе си познаването на един или друг програмен език без да се познава същността на процесите не ви дава нищо.
3. Delphi може да бъде използван като инструмент за създаване на приложения от клас AA+ и по-висок (да не се бърка с енергийния клас), ако познавате добре функционалните възможности на езика.
4. Delph е инструмент за разработка на приложения за експлотационен контрол, работещи в реално време.
5. Това, което може да направите на C, C++, C# може да направите и на Delphi, но обратното просто не е вярно.
6. За да програмирате на Delphi се изисква да имате сериозни познания и опит. каквото и да си говорим Delphi е единственият императивно структуриран обектно-ориентиран програмен език със строга статическа типизация на използваните променливи. Ако може да ми посочите друг език, отговарящ дори частично на това определение ще ви бъда задължен.
7. Това, че в България Delphi е мръсна дума не означава, че за развитите държави изучаването на този програмен език не е въпрос на държавна политика. Това е сложна тема, но ще се радвам да я обсъдим.

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

ПРОГРАМНИЯТ ЕЗИК КАТО КИБЕР-ОРЪЖИЕ


В тази публикация съм посочил малка част от програмните езици, с които ми се е налагало да работя. Някои определено са меко казано ... екзотични. icon_lol.gif

Това мнение е било редактирано от BlackScreen на 23-09-2018, 10:49
PMEmail Poster
Top
BlackScreen
  Публикувано на: 23-09-2018, 10:40
Quote Post



Име: Георги Тодоров Герасимов
Група: Потребител
Ранг: Посетител

Мнения: 85
Регистриран на: 23.09.18



Уважаеми gat3way,

ТОВА НЕ Е ПРЕВОД А АВТОРСКИ МАТЕРИАЛ. ЯСНО СЪМ ПОСОЧИЛ КОЙ СЪМ И КАК СЕ КАЗВАМ.

Просто може да наберете името ми в Google и ще видите какво ще получите като резултати.
Що се отнася до абсурдната Ви забележка за "началото на века" ако не се лъжа форума, който ползваме е достъпен благодарение на TCP/IP, а днес е 23.09.2018 година.

Забележката Ви е абсурдна и от гледна точка на това, което съм написал за Quality of Service (QoS). Все пак ако поне малко познавате OSI модела няма как да не знаете от кога са промените, които визирам. icon_lol.gif icon_lol.gif icon_lol.gif

Разбирам раздразнението Ви, но ще се радвам ако Вие предложите нещо, което САМ сте направили, за да мога и аз да го изкоментирам във Ваш стил. icon_razz.gif

С уважение

Георги Тодоров Герасимов

P.S. При някои самочувствието е пропорционално на невежеството. icon_lol.gif
При този вид липсата на конструктивизъм е заменена със злобни забележки и използване на терминология, която често самите индивиди не разбират. icon_lol.gif

Това мнение е било редактирано от BlackScreen на 23-09-2018, 10:56
PMEmail Poster
Top
1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (22) [1] 2 3 ... последна » Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2018 | BG Development | All Rights Reserved
RSS 2.0