<p>Syftet med den här rapporten är att beskriva ett antal olika tillvägagångssätt man kan använda sig av då man har behov av att dela in ett lokalt nätverk i olika segment och med det även kunna reglera trafikflödet mellan segmenten. De lösningar som presenteras i arbetet är inriktade mot mikro- och småföretag.Anledningen till att vi har valt att arbeta med det här området är att vi anser att det är viktigt för organisationer att har en strukturerad och segmenterad design på sitt interna datornätverk.Vi har arbetat genom att i förväg samla in information om olika tekniker som kan tänkas lösa vårt problem, och därefter testat olika scenarion med dessa tekniker. Data har samlats in efter varje genomfört scenario och sammanställts i statistisk form för att kunna avgöra vilken metod som var att föredra.Vi har testat lösningar där man segmenterar nätverket i en lager 2-switch medan man möjliggör och förhindrar trafikflöde mellan segmenten i en router. Även lösningar där man använder en lager 3-switch har testats. På så sätt kan routningen ske direkt i switchen och det blir betydligt mindre belastning i routern. Resultatet visar att då man vill segmentera ett nätverk så är det rekommenderat att man använder sig av VLAN och ACL:er och eventuellt i kombination med en brandvägg.Slutresultatet av rapporten är att en lösning med ”router on a stick” är den billigaste lösningen och troligen den som de flesta mindre företag skulle klara sig med. Vilken lösning man väljer beror dock helt på hur mycket pengar man vill lägga på sitt nätverk samt vad kraven är.</p> / <p>The purpose of this report is to describe a number of approaches that can be used when you are in need of dividing a local area network in a number of segments, and with that also be able to control how data traffic is allowed to traverse between the different segments. The solutions that are presented are focused towards micro and small companies.The reason that we have chosen to work with this matter is that we believe it is important for organizations to have a structured and segmented design of its internal computer network.We have been working by in advance collecting information about various techniques that might solve our problem, and then testing different scenarios using these techniques. Data have been collected after each tested scenario and compiled in statistical form in order to determine which method that was preferable.We have been testing solutions were you segment the network in a layer 2 switch while you allow or deny communication between the segments in a router, and also solutions were you use a layer 3 switch. In that way you can let the routing be performed in the switch, which leads to significantly lower load on the router. The result was that if you are about to segment a local area network it is recommended that you use VLAN and ACL:s, and possibly in combination with a firewall.The final result of this report is that a solution using the “router on a stick”-technique is the cheapest one, and probably the one that most small companies would get along with. However, the solution that you choose depends completely on how much money you want to spend on your network, and also what the needs are.</p>

Syftet med den här rapporten är att beskriva ett antal olika tillvägagångssätt man kan använda sig av då man har behov av att dela in ett lokalt nätverk i olika segment och med det även kunna reglera trafikflödet mellan segmenten. De lösningar som presenteras i arbetet är inriktade mot mikro- och småföretag.Anledningen till att vi har valt att arbeta med det här området är att vi anser att det är viktigt för organisationer att har en strukturerad och segmenterad design på sitt interna datornätverk.Vi har arbetat genom att i förväg samla in information om olika tekniker som kan tänkas lösa vårt problem, och därefter testat olika scenarion med dessa tekniker. Data har samlats in efter varje genomfört scenario och sammanställts i statistisk form för att kunna avgöra vilken metod som var att föredra.Vi har testat lösningar där man segmenterar nätverket i en lager 2-switch medan man möjliggör och förhindrar trafikflöde mellan segmenten i en router. Även lösningar där man använder en lager 3-switch har testats. På så sätt kan routningen ske direkt i switchen och det blir betydligt mindre belastning i routern. Resultatet visar att då man vill segmentera ett nätverk så är det rekommenderat att man använder sig av VLAN och ACL:er och eventuellt i kombination med en brandvägg.Slutresultatet av rapporten är att en lösning med ”router on a stick” är den billigaste lösningen och troligen den som de flesta mindre företag skulle klara sig med. Vilken lösning man väljer beror dock helt på hur mycket pengar man vill lägga på sitt nätverk samt vad kraven är. / The purpose of this report is to describe a number of approaches that can be used when you are in need of dividing a local area network in a number of segments, and with that also be able to control how data traffic is allowed to traverse between the different segments. The solutions that are presented are focused towards micro and small companies.The reason that we have chosen to work with this matter is that we believe it is important for organizations to have a structured and segmented design of its internal computer network.We have been working by in advance collecting information about various techniques that might solve our problem, and then testing different scenarios using these techniques. Data have been collected after each tested scenario and compiled in statistical form in order to determine which method that was preferable.We have been testing solutions were you segment the network in a layer 2 switch while you allow or deny communication between the segments in a router, and also solutions were you use a layer 3 switch. In that way you can let the routing be performed in the switch, which leads to significantly lower load on the router. The result was that if you are about to segment a local area network it is recommended that you use VLAN and ACL:s, and possibly in combination with a firewall.The final result of this report is that a solution using the “router on a stick”-technique is the cheapest one, and probably the one that most small companies would get along with. However, the solution that you choose depends completely on how much money you want to spend on your network, and also what the needs are.

Economic incentives and the need to efficiently deliver Internet have led to the growth of Internet eXchange Points (IXPs), i.e., the interconnection networks through which a multitude of possibly competing network entities connect to each other with the goal of exchanging traffic. At IXPs, the exchange of traffic between two or more member networks is dictated by the Border gateway Protocol (BGP), i.e., the inter-domain routing protocol used by network operators to exchange reachability information about IP prefix destinations. There is a common “honest-closed-world” assumption at IXPs that two IXP members exchange data traffic only if they have exchanged the corresponding reachability information via BGP. This state of affairs severely hinders security as any IXP member can send traffic to another member without having received a route from that member. Filtering traffic according to BGP routes would solve the problem. However, IXP members can install filters but the number of filtering rules required at a large IXP can easily exceed the capacity of the network devices. In addition, an IXP cannot filter this type of traffic as the exchanged BGP routes between two members are not visible to the IXP itself. In this thesis, we evaluated the design space between reactive and proactive approaches for guaranteeing consistency between the BGP control-plane and the data-plane. In a reactive approach, an IXP member operator monitors, collects, and analyzes the incoming traffic to detect if any illegitimate traffic exists whereas, in a proactive approach, an operator configures its network devices to filter any illegitimate traffic without the need to perform any monitoring. We focused on proactive approaches because of the increased security of the IXP network and its inherent simplified network management. We designed and implemented a solution to this problem by leveraging the emerging Software Defined Networking (SDN) paradigm, which enables the programmability of the forwarding tables by separating the controland dataplanes. Our approach only installs rules in the data-plane that allow legitimate traffic to be forwarded, dropping anything else. As hardware switches have high performance but low memory space, we decided to make also use of software switches. A “heavy-hitter” module detects the forwarding rules carrying most of the traffic and installs them into the hardware switch. The remaining forwarding rules are installed into the software switches.We evaluated the prototype in an emulated testbed using the Mininet virtualnetwork environment. We analyzed the security of our system with the help of static verification tests, which confirmed compliance with security policies. The results reveal that with even just 10% of the rules installed in the hardware switch, the hardware switch directly filter 95% of the traffic volume with nonuniform Internet-like traffic distribution workloads. We also evaluated the latency and throughput overheads of the system, though the results are limited by the accuracy of the emulated environment. The scalability experiments show that, with 10K forwarding rules, the system takes around 40 seconds to install and update the data plane. This is due to inherent slowness of emulated environment and limitations of the POX controller, which is coded in Python. / Ekonomiska incitament och behovet av att effektivt leverera Internet har lett till tillväxten av Internet eXchange Points (IXP), dvs de sammankopplingsnät genom vilka en mängd möjligen konkurrerande nätverksenheter förbinder varandra med målet att utbyta trafik. Vid IXPs dikteras utbytet av trafik mellan två eller flera medlemsnät av gränsgatewayprotokollet (BGP), dvs det inter-domänroutingprotokollet som används av nätoperatörer för att utbyta tillgänglighetsinformation om IP-prefixdestinationer. Det finns ett gemensamt antagande om "honest-closed-world" vid IXP, att två IXP-medlemmar endast utbyter datatrafik om de har bytt ut motsvarande tillgänglighetsinformation via BGP. Detta tillstånd försvårar allvarligt säkerheten eftersom varje IXP-medlem kan skicka trafik till en annan medlem utan att ha mottagit en rutt från den medlemmen. Filtrering av trafik enligt BGP-vägar skulle lösa problemet. IXPmedlemmar kan dock installera filter men antalet filtreringsregler som krävs vid en stor IXP kan enkelt överskrida nätverksenheternas kapacitet. Dessutom kan en IXP inte filtrera denna typ av trafik eftersom de utbytta BGP-vägarna mellan två medlemmar inte är synliga för IXP-enheten själv.I denna avhandling utvärderade vi utrymmet mellan reaktiva och proaktiva metoder för att garantera överensstämmelse mellan BGP-kontrollplanet och dataplanet. I ett reaktivt tillvägagångssätt övervakar, samlar och analyserar en inkommande trafik en IXP-medlem för att upptäcka om någon obehörig trafik finns, medan en operatör konfigurerar sina nätverksenheter för att filtrera någon obehörig trafik utan att behöva övervaka . Vi fokuserade på proaktiva tillvägagångssätt på grund av den ökade säkerheten för IXP-nätverket och dess inneboende förenklad nätverkshantering. Vi konstruerade och genomförde en lösning på detta problem genom att utnyttja det nya SDN-paradigmet (Software Defined Networking), vilket möjliggör programmerbarheten hos vidarebefordringsborden genom att separera kontrolloch dataplanerna. Vårt tillvägagångssätt installerar bara regler i dataplanet som tillåter legitim trafik att vidarebefordras, släppa allt annat. Eftersom hårdvaruomkopplare har hög prestanda men lågt minne, bestämde vi oss för att även använda programvaruomkopplare. En "heavy-hitter" -modul detekterar vidarebefordringsreglerna som transporterar större delen av trafiken och installerar dem i hårdvaruomkopplaren. De återstående spolningsreglerna installeras i programvaruomkopplarna.Vi utvärderade prototypen i en emulerad testbädd med hjälp av virtuella nätverksmiljö Mininet. Vi analyserade säkerheten för vårt system med hjälp av statiska verifieringsprov, vilket bekräftade överensstämmelse med säkerhetspolicyerna. Resultaten visar att med bara 10% av de regler som installerats i hårdvaruomkopplaren filtrerar hårdvaruomkopplaren direkt 95% av trafikvolymen med ojämn Internetliknande trafikfördelningsarbete. Vi utvärderade också latensoch genomströmningsomkostnaderna för systemet, även om resultaten begränsas av noggrannheten hos den emulerade miljön. Skalbarhetsexperimenten visar att med 10K-vidarebefordringsregler tar systemet cirka 40 sekunder för att installera och uppdatera dataplanet. Detta beror på inneboende långsamma emulerade miljöer och begränsningar av POX-kontrollern, som kodas i Python.

Paketfiltrering är en av nyckelfunktionerna i de flesta av dagens brandväggar, vilket gör paketfiltrering till en viktig del av det dagliga arbetet för många systemadministratörer. Sedan uppkomsten av paketfiltrering har nätverkskomplexiteten ökat drastiskt, Många av dagens tjänster har behov av olika protokoll för att kommunicera. I kombination med detta måste brandväggen bearbeta en större mängd data än tidigare för att tillgodose dagens nätverkstopologier.Denna studie syftar till att undersöka om det finns någon skillnad i prestanda mellan två moderna iterationer av de populära UNIX-brandväggarna IPtables och FreeBSD PF. Detta sker genom att de två brandväggarna utsätts för olika antal regler, samtidigt som de genomströmmas av olika stora paketflöden.De båda brandväggarna kommer att jämföras baserat på tre attribut, CPU, genomströmning och latens. tre olika bandbredder testas. 100, 500 och 1000Mbit/s. Testet omfattar längre tester som upprepas flera gånger för att öka studiens giltighet. Testerna som utförs görs på ursprungliga operativsystemet för varje brandvägg. Linux Ubuntu 16 för IPtables och FreeBSD 11 för FreeBSD PF.Studien kom fram till att brandväggarnas prestanda är likvärdiga i genomströmning och latens vid lägre regelmängder. Vid högre regelmängder skiljer sig prestandan och PF är bättre anpassad för stora regeluppsättningar. IPtables anses vara den bättre brandväggen för låga regeluppsättningar på grund av dess låga CPU-användning. / Packetfiltering is one of the key features in most of today’s firewalls. With many packetfilters being used daily in a system administrator’s work. Over the years since founding of the packetfilter technology the complexity of the network has increased drastically, where many of today’s services relies on different protocols to communicate, combined with a much larger amount of data that the firewall must process to satisfy todays network topologies.This study aims to explore if there is any difference in performance between two modern iterations of popular UNIX firewalls, IPtables and FreeBSD PF. By submitting them to different number of rulesets while at the same testing them under a series of different packet flows through the firewall.Both firewalls will be compared based on three attributes, CPU, throughput and latency, and three different bandwidths will be tested. 100, 500 and 1000Mbits/s. The test include longer tests that is repeated multiple times to increase the validity of the study. The tests were performed on the native operating system of each firewall. Linux Ubuntu 16 for IPtables and FreeBSD 11 for FreeBSD PF.The study concluded that the performance of the firewalls is equal in throughput and latency at lower volumes. At higher amounts of rulesets, performance is different between the firewalls and PF is considered better for large rules, while IPtables are considered to be a better firewall for low rulesets due to its low CPU usage.