Der vorliegende Vortrag gibt einen Ueberblick ueber den neuen Kernel-Firewall von Linux 2.4, das Netfilter/iptables System. Es werden die Moeglichkeiten des neuen Systems erlaeutert sowie die Vergleiche mit den Vorgaengern praesentiert.

This thesis is focused on the possibility of better networking security operating system GNU/Linux with an appropriate set of rules Netfilter. There was established a program to allow easy configuration of rules for IP Address versions 4 and 6. This program not only allows to set individual rules, but also interfere with the newly required service and decide, how it will be further worked with. The first is the theoretical part describes the network communication with the model TCP/IP, the following is the introduction of Netfilter and outlining the local security. The practical part describes the various technologies and methods used for programming. The result of this work is easy to use program to set firewall rules for IP Address versions 6 with the possibility of deciding on the new established network traffic. The program is designed for new users of the operating system, who want to better secure their computer without the knowledge of Netfilter.

In this thesis, we exercised the componentization technique to componentize the Netfilter architecture in Linux network system. Netfilter is a software architecture for filtering packets. System administrator can register packet-matching rules and target handling function into the system. Netfilter matches packets according to the rules and processes them by the corresponding target functions. By componentizing the architecture, we can improve the elasticity and the reusability of Netfilter. Hot-swapping is an important procedure in componentized software system. In this study, we implemented hot-swapping based on the work developed by Fan[1]. It stores the relocation information of exporting symbols into the module symbol table. With this information, we are able to dynamically change the caller-callee relationship of modular components at run time. In addition, we extend their work to allow the same modular component to be loaded into Linux kernel for more than once so that the same component can be replicated in the system. We started with decomposing all the ¡§hook¡¨ functions into smaller and simpler components and then for each component, we added in-ports and out-ports and registered its own iptables, and we fixed the limitation of only one instance of a module allowed in kernel and broke the hard rule in iptables. As a result, after Netfilter componentization, we are able to illustrate new configurations that cannot be done in the original architecture, and the system becomes further compact with only necessary components loaded in the system. This reflects in slight performance improvement in our experiments, which is not usually seen in other frameworks due to componentization overhead.

The management of network bandwidth is more important along with the population growth of Internet. For the issue of network bandwidth management the first thing needs to be done is to analyze network traffic belongs to which protocol. And then we can restrict the usage of network bandwidth accroding to the mangement policy. The mean used to identify network traffic in the past is port-based one which based on the well-known default port number of application protocols. For example, the Hyper-Text Transfer Protocol (HTTP) uses port number 80 as his default port, therefor we could classify traffic which appears in port 80 as HTTP traffic. It is not enough for applications in our own day, especilly the Peer-to-Peer application that used random port number as his default port in order to evade the port-based classifiaction. In order to conquer the issue described above we developed a content-based protocol classifier which inspects the payload of packets. We also compared our system with other content-based protocol classifiers. In addition, we also provided a verification tool which verifies the result of protocol classifier by connecting to the host and testing the hehavior of specific application.

V této práci jsou zkoumaní základní principy odporů servisních útoků, nejběžnějších typů a účelu použití. Popsané dostupné techniky zmírnění různých typu útoků, nástrojů a přístupů v operačních systémech postavených na Linuxu. Nakonfigurován filtrcni server a pro účely testování simulovan SYN Flood, UDP Flood a ICMP Flood útoky. Bylo zjištěno, vhodne techniky vyrovnání tehto druhu útoku a realizováné příslušna konfigurace filtrování.

DDoS-Angriffe und die für diese genutzten Botnetze werden u. a. durch die zunehmende Verbreitung von IoT-Geräten stetig größer. Aufgrund der Vorteile einer frühzeitigen Unterbindung solcher Angriffe ist eine effektive Erkennung der DDoS-Teilnahme in Heimroutern sinnvoll. Diese Arbeit analysiert aktuell verbreitete DDoS-Angriffstypen und entwickelt sowie sammelt verschiedene Erkennungsmechanismen aus der Literatur. Mithilfe ausführlicher Untersuchungen und Tests bezüglich Filterverhalten und Ressourcenbedarf der Erkennungsmechanismen konnten DDoS-Angriffstypen identifiziert werden, welche effektiv im Heimrouter erkannt und unterbunden werden können.:1 Einleitung 1.1 Problemstellung 1.2 Zielstellung 2 Verbreitetste DDoS-Angriffstypen 2.1 Source IP Spoofing 2.2 Reflection/Amplification 2.2.1 SSDP 2.2.2 WS Discovery 2.2.3 QUIC-Reflection 2.3 TCP-Floods 2.3.1 SYN-Flood 2.3.2 RST- und FIN-Flood 2.3.3 SYN-ACK-Flood 2.3.4 ACK-Flood 2.4 UDP-Flood 2.5 Direkte Application-Layer-Angriffe 2.6 Übersicht 3 Erkennung 3.1 Source IP Spoofing 3.2 SSDP & WS Discovery 3.3 TCP 3.3.1 SYN-Flood 3.3.2 RST- und FIN-Flood 3.3.3 SYN-ACK-Flood 3.3.4 ACK-Flood 3.4 UDP 3.5 Allgemeine Erkennung 3.5.1 MULTOPS 3.5.2 TOPS 3.5.3 D-WARD 4 Implementierung 4.1 Source IP Spoofing 4.2 SSDP & WS Discovery 4.3 TCP (ohne SYN) 4.4 SYN-Flood 4.4.1 SYN Paketratenlimitierung 4.4.2 SYN Proxy 5 Untersuchung 5.1 Tests 5.1.1 Implementierungskomplexität 5.1.2 Speicher- und Rechenkapazitätsbedarf 5.1.3 Filterverhalten 5.2 Andere Erkennungsmethoden 5.2.1 Implementierungskomplexität 5.2.2 Speicher- und Rechenkapazitätsbedarf 5.2.3 Filterverhalten 5.3 Diskussion 6 Fazit & Ausblick Literaturverzeichnis Abbildungsverzeichnis Tabellenverzeichnis / DDoS attacks and the botnets used for them are constantly growing due to the increasing spread of IoT devices, among other things. Due to the advantages of stopping such attacks at an early stage, effective detection of DDoS participation in home routers makes sense. This thesis analyses currently widespread DDoS attack types and develops and collects various detection mechanisms from the literature. With the help of detailed investigations and tests regarding filter behaviour and resource requirements of the detections mechanisms, DDoS attack types were identified that can be effectively detected and prevented in the home router.:1 Einleitung 1.1 Problemstellung 1.2 Zielstellung 2 Verbreitetste DDoS-Angriffstypen 2.1 Source IP Spoofing 2.2 Reflection/Amplification 2.2.1 SSDP 2.2.2 WS Discovery 2.2.3 QUIC-Reflection 2.3 TCP-Floods 2.3.1 SYN-Flood 2.3.2 RST- und FIN-Flood 2.3.3 SYN-ACK-Flood 2.3.4 ACK-Flood 2.4 UDP-Flood 2.5 Direkte Application-Layer-Angriffe 2.6 Übersicht 3 Erkennung 3.1 Source IP Spoofing 3.2 SSDP & WS Discovery 3.3 TCP 3.3.1 SYN-Flood 3.3.2 RST- und FIN-Flood 3.3.3 SYN-ACK-Flood 3.3.4 ACK-Flood 3.4 UDP 3.5 Allgemeine Erkennung 3.5.1 MULTOPS 3.5.2 TOPS 3.5.3 D-WARD 4 Implementierung 4.1 Source IP Spoofing 4.2 SSDP & WS Discovery 4.3 TCP (ohne SYN) 4.4 SYN-Flood 4.4.1 SYN Paketratenlimitierung 4.4.2 SYN Proxy 5 Untersuchung 5.1 Tests 5.1.1 Implementierungskomplexität 5.1.2 Speicher- und Rechenkapazitätsbedarf 5.1.3 Filterverhalten 5.2 Andere Erkennungsmethoden 5.2.1 Implementierungskomplexität 5.2.2 Speicher- und Rechenkapazitätsbedarf 5.2.3 Filterverhalten 5.3 Diskussion 6 Fazit & Ausblick Literaturverzeichnis Abbildungsverzeichnis Tabellenverzeichnis

This master thesis deals with testing network prefix translation algorithm in IPv6. It tests existing implementation. This implementations are compared with each other. Some implementations end with error compilation. There are two options how to deal with this problem, it might be repaired or the port to the new kernel is created. Performance is tested with Spirent hardware packet generator.

Der vorliegende Vortrag gibt einen Ueberblick ueber den neuen Kernel-Firewall von Linux 2.4, das Netfilter/iptables System. Es werden die Moeglichkeiten des neuen Systems erlaeutert sowie die Vergleiche mit den Vorgaengern praesentiert.

No description available.