Remote Netlab

(1)

Självständigt arbete på grundnivå

Independent degree project - first cycle

Huvudområde Major Subject Remote Netlab Tobias Engkvist

(2)

MITTUNIVERSITETET Sundsvall

Examinator: Magnus Eriksson, magnus.eriksson@miun.se Handledare: Lennart Franked, lennart.franked@miun.se Författare: Tobias Engkvist, toen1400@student.miun.se Utbildningsprogram: Nätverksdrift, 120HP

Huvudområde: DT080G, Datateknik B-nivå, Självständigt arbete 7,5 hp Termin, år: 4, 2016

Poäng kurs: 7.5HP

(3)

Sammanfattning

Detta projekt har haft som fokus att skapa ett system där användare med hjälp av SSH ska kunna logga in på en servern och utföra konfigurationer på switchar och routrar med olika krav såsom att enbart en användare får vara inloggad i systemet åt gången.

För att uppnå målen och kraven så användes ett par olika skript med språk såsom shell, bash, perl och expect. Resultatet visar en färdig produkt och att detta projekt var genomförbart. Lösningsförslaget finns presenterat i form av ett flödesschema och sedan vanlig text slutligen presenteras och diskuteras även andra alternativa lösningar.

Keywords: ssh,shell,bash,perl,expect

(4)

Abstract

The projects main focus have been to create a system mainly for the users that study network technology on a more advanced level. In order for the students to start to configure the switches and routers they need to access a server with the SSH protocol which was one of the requirement. Another requirement was that only one user should be able to configure at same time (so two users should NOT be able to configure the switches and routers at the same time). The scripting languages that was used was bash, shell, perl and expect in order to achive these goals and requirement. The result do show a finished product and that this project was manageable. The solution is presented as a flowchart as a overview and some regular text that explains the scripts in more depth. There are ofcourse a ton of other ways to solve this problem and a few of them are presented and discussed in the later chapters.

Keywords: ssh,shell,bash,perl,expect

(5)

List of Figures

2.1 Figuren visar en övervakning över hur iptables tillåter och blockerar paket. . . . 4 2.2 Figur visar hur olika paket blir muliplexade, att de blir ’muxade’ och skickas

sedan över samma kanal . . . . 5 3.1 Figuren visar en översikt i logiken bakom skripten och hur användaren blir inlåst

i systemet . . . . 8 4.1 Figur som visar hur logiken bakom skripten ser ut. . . . 10 4.2 Figur som visar uppstartsfrågan, om en användare vill påbörja en session eller inte. 10 4.3 Figur som visar jobben som installeras till crontab för användaren. . . . 10 4.4 Figur som visar jobben som finns förinstallerade för ’superanvändaren’ . . . . 11 4.5 Figur som visar att enbart användare med IP 88.129.140.146 får tillgång till

systemet(i detta fall administratören och den användare som körde skriptet) med SSH . . . . 11 4.6 Figur som visar att användare med IP-adress 192.168.1.110 inte kommer åt en

testmiljö eftersom att den inte är tillåten. . . . 11 4.7 Figur som visar att enbart användare med IP 88.129.140.146 (vilket är administ-

ratör) får tillgång till systemet . . . . 12

(8)

1 Introduktion

Att kunna ansluta mot en server eller en annan enhet såsom en router eller en switch uppkopplad mot internet eller kanske på ett privat nätverk från en helt annan plats är något som sparar både tid och pengar. En tekniker behöver inte alltid åka till platsen där utrustningen står för att kunna komma åt enheten som behöver fixas eller kanske bara underhållas utan det räcker med att teknikern och enheten som teknikern försöker ansluta mot har en uppkoppling mot internet. Detta måste dock ske på ett säkert och smidigt sätt och protokollet SSH(secure shell) möjliggör detta.

1.1 Bakgrund

Studenter som studerar nätverksteknik på en mer avancerad nivå på distans saknar i dagsläget ett smidigt verktyg att kunna testa och konfigurera switchar eller routrar. Studenterna måste köpa egen utrustning eller på något sätt kunna röra sig till Mittuniversitetet där de studerar för att kunna testa konfigurationer.

1.2 Syfte

Syftet med detta projekt var att på ett smidigt sätt kunna ge studenter som studerar på distans tillgång till laborationssalen för switchar och routrar under en tidsbegränsad period med hjälp av SSH protokollet.

1.3 Mål

Målet med detta projekt är att det ska finnas en fungerande och tidsbegränsad SSH tunnel mellan studenters datorer och ett rack innehållande switchar och routrar. Efter att tiden har gått ut så ska konfigurationsfilen sparas på användarens katalog, alternativt så ska det mejlas studenten och efter detta så ska samtliga switchar och routrar anslutna till servern rensas och startas om. Det är av tung vikt att enbart en enda student kan få tillgång till routrarna och switcharna och ingen fler samtidigt. Däremot hur många som är inloggad via SSH mot servern är irrelevant.

1.4 Tidsplan

Tanken är att jobba agilt med en regelbunden kommunikation mellan beställaren och lever- antören. Mellan varje videomöte så kommer beställaren och leverantören ha minst ett

(9)

Chapter 1. Introduktion

avstämningsmöte kring hur projektet fortlöper och vad som blivit gjort och vad som ska göras.

1.5 Avgränsningar

Det ska sättas upp en SSH tunnel mellan studenters dator och en server, servern ska sedan kunna ansluta mot ett rack där det står switchar och routrar. Det behöver inte finnas något bokningssystem och studenterna ska inte kunna välja själva tidsintervallet själva.

1.6 Frågeställning

Det detta projekt kommer att besvara är:

1. Finns det något färdigt program som löser detta?

2. Vilka lösningar finns det och vad för fördelar och nackdelar har dessa?

3. Är det möjligt att implementera någon utav dessa lösningar inom tidsramen för detta projekt?

4. Är något skriptspråk bättre än det andra?

(10)

2 Teori

2.1 SSH

SSH(Secure Shell) är ett protokoll som används för att på ett säkert sätt kunna ansluta mot andra enheter från en annan plats. De tre huvudsakliga protokollen som används är transport lager protokoll, protokollet för användarautentisering och anslutningsprotokollet.

Det transport lager protokollet tillhandahåller är då autentisering, konfidentialitet och integritet, om man önskar så går det även att välja till att komprimera data. Det protokollet för användarautentisering gör är att autentisera klientsidan mot server.

Det anslutningsprotokollet gör är att multiplexa den krypterade tunneln till ett flertal logiska kanaler.

De vanligaste attackerna som SSH skyddar mot är ’replay’ attack, ’man-in-the-middle’

attack och till viss del DDoS.

Det finns ett par olika sätt att autentisera användarna då de ska använda SSH (ansluta mot exempelvis en server med SSH). Först sättet att autentisiera sig på är med hjälp av publika nycklar, det andra sättet är med lösenord och det tredje sättet är en host-baserad autentisieringsmetod. Dessa autentisieringsmetoder används i olika grader och har olika syften, om exempelvis en enda enhet ska kunna komma åt systemet så kanske publika nycklar eller host-based autentisering bör övervägas att användas som autentisieringsmetod.[1]

2.2 Fillåsning

Det finns två olika typer av låsningsmetoder och dessa är ’Advisory’ och ’Mandatory’ lås.

Vad båda vill uppnå är att de enbart ska tillåta en process åtkomst mot samma fil på samma gång. Ett exempel på varför ett lås behövs är för att förhindra att det nedan inträffar[2]

1. Process A öppnar och läser en fil.[2]

2. Process B öppnar också och läser samma fil.[2]

3. Process A gör lite ändringar i filen och sparar denna.[2]

4. Process B har ingen aning om dessa ändringar och gör ändringar i samma fil på samma rad och sparar denna.[2]

5. De ändringar som gäller nu är de som process B har gjort.[2]

(11)

Chapter 2. Teori

Figure 2.1 Figuren visar en övervakning över hur iptables tillåter och blockerar paket.

Det ’Mandatory’ låset gör är att det skapar en kö, om process A öppnar upp för att läsa eller skriva i en textfil så ställs process B i kö tills process A stänger filen. ’Advisory’

tillåter att processerna samarbetar och process A och process B kommer kunna öppna och skriva i samma fil om de samarbetar. Implementationen av de olika låsen sker oftast med C programmering.[2]

2.3 IPTABLES

Iptables är en brandvägg som finns tillgänglig till de flesta unix-lika system. Med hjälp av iptables så går det att tillåta eller neka trafik beroende på olika regler som går att ställa in. Det går att filtrera trafiken på exempelvis IP, TCP, portnummer och andra protokoll.

Dessa regler försvinner efter en omstart av systemet men med hjälp av skript så finns det sätt att lägga till reglerna under uppstart.[3]

Som iptables fungerar så jämförs den inkommande eller utgående trafiken mot ett set regler, börjar uppifrån och går nedåt. Även om reglerna börjar uppifrån och nedåt så betyder det inte att resterande regler ignoreras. Om det exempelvis finns en policy högst upp som blockerar all inkommande och utgående trafik och en regel längre ned som tillåter port 22 så kommer port 22 att vara tillåten.[4] Figur 2.1 illustrerar hur dessa regler kan se ut.

Det är väldigt viktigt att brandväggen är uppdaterad. iptables är en paket filtrerande brandvägg och innehåller 3 olika kedjor såsom ’FORWARD’, ’INPUT’ och ’OUTPUT’. Varje paket som hanteras av kerneln går igenom någon av dessa kedjor. Regler i ’INPUT’ och

’OUTPUT’ appliceras mot IP-adresser från eller mot exempelvis en organisation medans

’FORWARD’ mer har med nätverkskortet att göra. Utöver detta så har iptables mer avancerad funktioner såsom NAT (network address translation).[5]

2.4 Perl

Perl är ett programmeringsspråk som har stöd för över 100 olika plattformar. Perl är det optimala programmeringsspråket att använda för skalbara projekt.[6] En av anledningarna

(12)

Chapter 2. Teori

Figure 2.2 Figur visar hur olika paket blir muliplexade, att de blir ’muxade’ och skickas sedan över samma kanal

till att perl är så stort och ett bra verktyg är just för att det är open source, det tillåter att vanliga användare och utvecklare kan se källkoden och nyttja den till sina fördelar, exempelvis att kunna skriva egna bibliotek. Ett exempel på detta är att cpan tillhandahåller IPTables::IPv4 vilket gör det möjligt att på ett smidigt sätt kunna skapa regler med hjälp av perl till iptables och då skriptet körs så aktiveras dessa regler.[7]

2.5 POLA

POLA(Principle of least astonishment) är principer som främst utvecklare följer då de ska utveckla mjukvarudesignen på ett system eller utveckla ett användargränssnit. Vad principen innebär är det att ett system ska bete sig så som användaren förväntar sig att systemet ska fungera, en lampknapp på standard ska exempelvis slå på lampan eftersom att det är det användaren förväntar sig.[8]

Det finns olika typer av operativsystem. En unix server bygger i grund och botten på ett ’flera användare operativ system’ vilket innebär att flera användare ska kunna komma åt systemet samtidigt, det är själva tanken med en unix-server och det finns verktyg som tillåter detta såsom telnet eller den mer säkra SSH.[9]

2.6 Definition av termer och förkortningar

• Multiplex: Förenklad definition så multiplex att kunna skicka flera meddelanden samtidigt över samma krets eller kanal såsom data och voip.Figur 2.2 illustrerar hur detta ser ut.[10]

• Minicom: Detta är ett terminalbaserat program som finns till bland annat debian och ubuntu. Minicom används för att kunna kommunicera med exempelvis switchar och routrar via konsolporten.[11]

• CPAN: ’Comprehensive Perl Archive Network’ är ett register som innehåller olika moduler till perl, olika bibliotek som för det mesta är skrivna i perl.[12]

(13)

3 Metod

3.1 Förberedelse

Första steget under förberedelsen var att se till så att det finns åtkomst mot servern. Det som installerades på servern var en standardkonfiguration av operativsystemet Debian[13], en statisk IP adress och en standard konfiguration av SSH med en vanlig lösenords autentisering.

För att undvika att administratören ska låsa ut sig själv ur systemet helt och hållet under laborationsfasen så skapades ett skript som körs varje timme med hjälp av crontab.

Det skriptet gör är att rensa ur alla regler ur iptables(utom standardregler som sedan läggs tillbaka för att förhindra DDoS och annat) så om ett misstag skulle göras så försvinner dessa regler varje timme. Detta innebär att ingen behöver starta om servern manuellt eller behöva ansluta mot den på plats så att all administrering kan göras på distans. Skriptet finns bifogat som bilaga A.

3.2 Implementera iptables

Enbart en användare ska kunna använda utrustningen åt gången och den lösning som valdes att implementera var iptables. För att kunna lägga till regler i brandväggen så krävs det att användaren har ’root’ eller ’superuser’ rättigheter vilket användarna INTE ska ha tillgång till så ett minimum av två olika skripts behövdes för att uppfylla detta. Det första skriptet vilket finns som Bilaga B(getIP.pl) skrevs i perl, då användaren kör detta skript så läses IP-adressen in och sparas i en textfil med namnet report.txt. Textfilen som skapas kan enbart den användare som körde skriptet modifiera så även om andra användare försöker att köra skriptet i efterhand så kommer det inte skapas en ny fil eller informationen i textfilen att skrivas över.

Sedan gör skriptet två andra saker som är noterbara och diskuteras mer under de andra rubrikerna under metoden men den första delen är att det skapar en katalog i användarens hemkatalog och den andra noterbara delen är att skriptet skapar en ny ’screen’ som sedan körs i bakgrunden.

Bilaga C vilket är det andra skriptet skrevs som ett bashskript och det körs en gång i minuten i bakgrunden med hjälp av crontab. Skriptet i sig fungerar som så att om det finns en textfil med namnet report.txt så ska skriptet lägga till regler i brandväggen som tillåter att IP-adressen i report.txt(vilket är användaren) och administratören tillåts åtkomst med SSH mot servern, resterande SSH sessioner avslutas och nya sessioner blockeras. Nästa steg är att report.txt flyttas till ’/etc/lock’(anledningen till detta finns under rubriken ’Tidsbegränsa

(14)

Chapter 3. Metod

användare’) med ett nytt namn IP.txt. Sedan så ändras användaren till root och gruppen till root och behörigheterna ändras så att enbart root kan läsa, modifiera och exekvera denna fil. Det som skriptet sedan gör är att om nu report.txt INTE existerar så görs en utskrift

’No file exists’ och den utskriften skickas till /dev/null i crontab så meddelandet visas aldrig för användaren, sedan så händer inget mer.

3.3 Spara konfigurationen

Det program som användes för att ansluta USB-serial enheten mot switcharna och routrarna var minicom. För att på ett smidigt sätt kunna spara konfigurationerna från switcharna och routrarna så användes både bash, expect och till viss del perl. Det första skriptet vilket finns bifogat som bilaga F (save_conf.sh) fungerar som så att expect skapar en minicom session och kör förinställda kommandon, i detta fall så körs ’enable’, ’terminal lenght 0’ och ’show running-config’ och sedan så sparas konfigurationerna i en textfil. Detta skript upprepas för de enheterna som är inkopplade, vilket är 3 switchar och 3 routrar så sammanlagt genereras 6 stycken textfiler med olika namn. Minicom är dock ett program som kräver någon slags interaktion med ett ’shell’ så för att kunna automatisera skriptet, dvs för att crontab skulle kunna köra skriptet så skapades ett nytt skript som sätter miljövariabeln(shell) och sedan kör save_conf.sh. Detta skript finns bifogat som bilaga G.

För att användarna skulle kunna komma åt textfilerna(konfigurationerna) så skapades ett skript som finns bifogat som Bilaga H som flyttar konfigurationerna från ’/home/lock- /config’ till användarkatalogen ’config’ och med hjälp av crontab så kollas det om filerna finns i katalogen varje minut. Sist för att användaren inte ska behöva lägga in dessa cronjobs själva så skapades ett nytt bash skript som finns under Bilaga I vilket GetIP kallar på som lägger in olika regler i crontab.

3.4 Tidsbegränsa användare

Systemet ska vara anpassat utifrån att användare ska kunna boka in tider och enbart ha tillgång till systemet en viss period så för att lösa detta så skapades två nya skript. Det första skriptet som finns under bilaga D nekar all åtkomst via SSH och med hjälp av crontab körs detta skript klockan 08:00, 12:00 ,16:00, 20:00, 00:00 och 04:00. För att förhindra att detta skript körs om ingen användare använt systemet så körs först en koll att om textfilen som flyttades till ’/etc/lock’ med namnet IP.txt existerar så blockera allt på port 22, finns inte IP.txt så ska ingenting göras. Det andra skriptet vilket finns som bilaga E låser upp systemet, detta körs via crontab 08:05, 12:05, 16:05, 20:05, 00:0 och 04:05 och så kontrollerar skriptet att om textfilen IP.txt existerar så ska alla användare som har ett login till servern kunna ansluta igen med SSH igen och slutligen så plockas IP.txt bort och nästa användare kan köra skriptet i Bilaga B för att kunna starta sin session. Figur 3.1 illustrerar ett flödesschema kring hur logiken bakom skripten fungerar.

3.5 Automatisera

Det finns en risk att användaren inte kommer ihåg att köra skriptet så för att automatisera detta så skapades ett skript i /etc/profile.d/ som promptar användaren om de vill starta en session, detta skript finns bifogat som Bilaga J. Om användaren väljer att de vill starta en

(15)

Chapter 3. Metod

Figure 3.1 Figuren visar en översikt i logiken bakom skripten och hur användaren blir inlåst i systemet

session så körs GetIP.pl som skapar textfilen med IP-adressen. Sedan så kallar GetIP.pl på ett annat skript vilket i sin tur installerar två stycken jobb i crontab på användarnivå, vilket diskuterades mer under tidigare sektionen ’Spara konfigurationen’ som finns på sida 7.

(16)

4 Resultat

En överblick på hur resultatet blev presenterat visas som ett flödesschema som en figur under 4.1. Sedan mer detaljerat hur skripten fungerar och vad som händer presenteras i texten nedan.

Då användaren loggar in med sin användare så dyker det först upp en fråga som figur 4.2 illustrerar. Om användaren skriver in en 1 för ’yes’ så startar sessionen och GetIP.pl körs vilket i sin tur triggar igång de andra skripten, om användaren skriver in nummer 2 så händer inget. GetIP.pl kör ett annat skript som lägger till 2 nya jobb i crontab och hur dessa ser ut illustrerar figur 4.3, dessa regler skrivs över varje gång skriptet körs så det blir inte några duplicerade rader. Som beskrivet i metoden så skapar GetIP en fil som skapar en kedjereaktion och figur 4.4 illustrerar ett utdrag från ’superanvändarens’ crontab som triggas vid olika tidpunkter. Det sista detta skript gör är att skapa en ’screen’ som ligger i bakgrunden. detta medför i att även om användaren loggar ut så kommer ändå skript som exempelvis sparar switcharna och routrarnas konfigurationer kunna köras.

Efter att cronjobben blivit installerade på användarens crontab och textfilen skapats så stängs först användaren in i systemet med hjälp av iptables vilket figur 4.5 visar. Användaren kan sedan börja laborationen eller vad de nu ska göra utan att någon annan användare kan logga in och störa (utom då administratören). Figur 4.6 visar att reglerna fungerar även om det är i en testmiljö med annorlunda IP-adresser i det fallet(anledningen är att i skrivande stund har författaren enbart tillgång till en enda skarp IP-adress).

5 minuter innan sessionen avslutas så körs det ett skript som sparar konfigurationerna och sedan flyttar dessa till användarens katalog som har namnet config(GetIP.pl skapar denna katalog men det beskrivs mer tydligt i metoden) och sedan då sessionen ska avslutas så körs det ett annat skript som låser ute alla användare inklusive den som konfigurerade, den enda användaren som får tillgång till systemet i detta läge är administratören vilket figur 4.7 kan verifiera. Efter att 5 minuter har gått så låses systemet, alla startade ’screens’

plockas bort och textfilen IP.txt i ’/etc/lock’ plockas bort. Sedan så låses systemet upp igen och en ny användaren kan då starta en ny session.

(17)

Chapter 4. Resultat

Figure 4.1 Figur som visar hur logiken bakom skripten ser ut.

Figure 4.2 Figur som visar uppstartsfrågan, om en användare vill påbörja en session eller inte.

Figure 4.3 Figur som visar jobben som installeras till crontab för användaren.

(18)

Chapter 4. Resultat

Figure 4.4 Figur som visar jobben som finns förinstallerade för ’superanvändaren’

Figure 4.5 Figur som visar att enbart användare med IP 88.129.140.146 får tillgång till systemet(i detta fall administratören och den användare som körde skriptet) med SSH

Figure 4.6 Figur som visar att användare med IP-adress 192.168.1.110 inte kommer åt en testmiljö eftersom att den inte är tillåten.

(19)

Chapter 4. Resultat

Figure 4.7 Figur som visar att enbart användare med IP 88.129.140.146 (vilket är administratör) får tillgång till systemet

(20)

5 Diskussion

Syftet med detta projekt var att skapa ett system där användare kan med hjälp av SSH komma åt en server och sedan kunna ansluta sig mot routrar och switchar. Detta som krav att det max fick vara 1 användare får komma åt utrustningen åt gången samt att varje session skulle vara tidsbegränsad. Med hjälp av alla de olika skripten som fungerar tillsammans och triggas av varandra så har syftet blivit uppnått.

Det resultat som blev presenterad under resultatdelen blev som väntat, en färdig produkt som uppfyller de krav som ställdes. En anmärkning var dock att det blev väldigt många skript och blandat med språk. Systemet skulle vara helt automatiserat och det första som händer då en användare loggar in med SSH är att de blir tillfrågad om de vill påbörja en session eller inte och efter det så är allt automatiskt.

Initialt så var tanken att användarna manuellt skulle behöva köra GetIP.pl vilket triggar igång alla andra skripts men denna lösning blev mycket snyggare. En annan sak som kanske bör diskuteras är alla de skriptspråk som användes. Det blev en hel del mer språk än vad som var tänkt. Till en början så var det bash,shell och perl som skulle användas men expect kom in i bilden. Minicom har ett eget skriptspråk ’runscript’ men det kunde inte uppfylla de krav som fanns och hade diverser problem (det gick bland annat inte att avsluta minicom automatiskt utan att döda processen manuellt). Sedan så krävde minicom ett interaktivt fönster så expect var optimalt för att lösa det.

En av frågorna i frågeställningen var om det fanns något färdigt program som löser detta.

Det fanns olika sätt att lösa detta problem på men ett färdigt program som ska uppnå detta hittade jag inte. Det som är presenterat i resultatet är bara ett sätt att lösa problemet på men ett annat sätt vore att använda C-programmering. Med hjälp av mutex låsningar eller liknande så går det att låsa processen tillfälligt medans en användare nyttjar systemet.

En annan lösning vore kanske att gå emot POLA och med hjälp av PAM enbart tillåta en användare. Detta kräver i grund och botten att man bygger en egen kernel och konfigurerar om PAM.

En annan lösning vilket kanske är en av favoriterna är att skapa två olika instanser i servern(alternativt använda två olika servrar). Om ett visst kriterium uppfylls så ska användaren hamna i en instans och uppfylls ett annat så ska användaren hamna i en annan instans. Om låt oss säga användare A kommer har bokat systemet klockan 08:00-12:00 så med hjälp av användarnamnet eller IP-adressen så kommer användaren in till den instans där användaren kan konfigurera routrarna och switcharna. Om nu användare B loggar in i systemet under tiden som användare A använder systemet så skickas användare B till en annan instans där det exempelvis enbart går att boka tider eller hämta föregående konfigurationer.

En av frågorna var om ett skriptspråk var bättre än det andra och vad jag kommit fram

(21)

Chapter 5. Diskussion

till är att de alla har sina styrkor och svagheter. Expect skript är exempelvis väldigt bra då man vill ha information snabbt från en SSH eller telnet session och shell eller bash är starka språk att använda om man vill göra enklare saker direkt mot terminalen såsom att flytta en fil eller liknande. Sedan perl är bra om man vill göra lite mer avancerade saker som kanske inte alltid involverar terminalen. Så det ena utesluter inte det andra utan de används på olika sätt.

5.1 Vidare arbeten

Ett vidare arbete för detta system vore att skapa ett bokningssystem för användarna, att via moodle boka in en tid till systemet och sedan ska användaren länkas mot servern och enbart denna användare få tillgång till systemet.

Ett annat sätt vore att göra bokningssystemet direkt på SSH servern men det kräver en djupare analys. Ett exempel på detta presenterades i diskussion där det går att använda två olika servrar, alternativt skapa två olika instanser(om möjligt) och låta ena servern stå för bokning och den andra för konfigurationer.

En brist i systemet som det är nu är det att det inte finns något effektivt sätt för användaren att hämta sina konfigurationer men det optimala vore att länka användarna mot samma databas som moodle är länkad mot och sedan göra ett skript som automatiskt mejlar ut konfigurationerna till användaren efter att de sparats i någon av katalogerna.

Då man konfigurerar switchar och routrar så är man väldigt sällan ensam under lab- orationerna, så något som skulle kunna läggas till är att flera användare får konfigurera samtidigt, exempelvis 2-3 personer. Ett snyggt sätt att göra detta på vore att använda sig av grupper, men som skripten är konstruerade så är den mindre snyggare lösningen den enklare lösningen. Den mindre snyggare lösningen involverar att skriptet som hämtar och lagrar IP-adressen från användaren hämtar och lagrar fler IP-adresser, detta kräver lite modifikationer i ett par skript men går att göra.

5.2 Etik

Att skapa skript som gör allt åt oss är både bra och dåligt. Kan ju börja med att diskutera de bra aspekterna och det första är att det blir en mindre risk för att något blir fel, en maskin jobbar utifrån de instruktioner den fått medans en människa kan göra fel. Om vi återkopplar mot skripten som är skapade, om alla dessa skripts kördes manuellt så kanske användaren glömmer att låsa in sig själv i systemet och börjar konfigurera saker, efter någon timme så kommer en annan användare in och kör skriptet som låser in den nya användaren vilket resulterar i att den användare som konfigurerade routrarna och switcharna blir utkastad ur systemet. En annan sak är att administratören kanske inte alltid behöver gå in i systemet och göra saker som kanske kräver ’root’ behörigheter. Däremot ju mer som automatiseras desto mindre personer behövs det för att underhålla systemet så i slutändan kan det resultera i mindre jobb. Om det nu skulle göras ett vidarearbete och dessa skript blir väldigt effektiva så kanske det inte ens behövs en labbsal längre? Bara lägga in switcharna och routrarna i ett stängt utrymme och låta användarna nyttja systemet från en annan fysisk plats och då kanske ett jobb försvinner.

(22)

References

[1] Ylonen T, Lonvick C. The Secure Shell (SSH) Protocol Architecture. IETF; 2006. RFC 4251 (Proposed Standard). Available from: http://www.ietf.org/rfc/rfc4251.txt.

[2] 2 Types of Linux File Locking (Advisory and Mandatory Lock Examples);. Accessed:

2016-04-02. Available from: http://www.thegeekstuff.com/2012/04/linux-file- locking-types/.

[3] IptablesHowTo;. Accessed: 2016-04-04. Available from: https://help.ubuntu.com/

community/IptablesHowTo.

[4] How the Iptables Firewall Works;. Accessed: 2016-04-05. Available from: https://www.

digitalocean.com/community/tutorials/how-the-iptables-firewall-works.

[5] Nemeth E, Snyder G, Hein TR, Whaley B. Unix and linux system administration handbook. vol. 4th edition. Prentice Hall, Upper Saddle River,NJ; 2011.

[6] About Perl;. Accessed: 2016-04-08. Available from: https://www.perl.org/about.

html.

[7] IPTables::IPv4;. Accessed: 2016-04-08. Available from: http://search.cpan.org/

~dpates/IPTables-IPv4-0.98/IPv4.pm.

[8] Principle of least astonishment;. Accessed: 2016-04-11. Available from: https://en.

wikipedia.org/wiki/Principle_of_least_astonishment.

[9] What are time sharing and multiuser operating systems, and what are some examples?;.

Accessed: 2016-04-11. Available from: https://www.quora.com/What-are-time- sharing-and-multiuser-operating-systems-and-what-are-some-examples.

[10] Definition of multiplex;. Accessed: 2016-04-03. Available from: http://www.merriam- webster.com/dictionary/multiplex.

[11] Minicom;. Accessed: 2016-04-12. Available from: https://help.ubuntu.com/

community/Minicom.

[12] Perl Modules;. Accessed: 2016-06-04. Available from: http://www.cpan.org/

modules/.

[13] Få tag på Debian;. Accessed: 2016-04-11. Available from: https://www.debian.org/

distrib/.

(23)

A Data

Bilaga A

#!/ b i n / sh

e c h o " F a i l s a f e a k t i v e r a d . "

i p t a b l e s −F i p t a b l e s −X

i p t a b l e s −P INPUT ACCEPT i p t a b l e s −P FORWARD ACCEPT i p t a b l e s −P OUTPUT ACCEPT

i p t a b l e s −A INPUT − i l o −j ACCEPT i p t a b l e s −A OUTPUT −o l o −j ACCEPT Bilaga B

#!/ u s r / b i n / p e r l

#u s i n g w a r n i n g s , s t r i c t and o t h e r needed modules u s e s t r i c t ;

u s e w a r n i n g s ;

u s e SVN : : U t i l s : : C l i e n t I P qw ( s s h _ c l i e n t _ i p ) ;

#Adding c l i e n t IP and f i l e t o v a r i a b l e s . my $IP = s s h _ c l i e n t _ i p ( ) ;

my $ f i l e n a m e = ’ / home/ l o c k / r e p o r t . t x t ’ ;

my $ c r o n t a b = ’ / home/ l o c k / s c r i p t s / AddUserCron . sh ’ ; my $MakeFolder =’ mkdir /home/$USER/ c o n f i g ’ ;

#open f i l e and p r i n t s u s e r IP a d d r e s s t o i t , i f f i l e d o e s n ot e x i s t t h e f i l e w i l l be

#c r e a t e d c o n t a i n i n g o n l y t h e IP−a d r e s s

open (my $fh , ’ > ’ , $ f i l e n a m e ) o r d i e " Could n o t open f i l e ’ $ f i l e n a m e ’ $ ! " ; p r i n t $ f h $IP , "\ n " ;

c l o s e $ f h ;

#Adds a c r o n j o b t o c r o n t a b f o r t h e r u n n i n g c o n f i g u r a t i o n s and c r e a t e s a f o l d e r t o put

(24)

Appendix A. Data

#them i n t o

system ( $ c r o n t a b ) ; system ( $MakeFolder ) ;

system ( ’ s c r e e n −dmS save_conf ’ ) ; Bilaga C

#!/ b i n / bash

#a d d i n g f i l e l o c a t i o n t o v a r i a b l e f i l e =/home/ l o c k / r e p o r t . t x t

#d e c l a r i n g a d m i n i s t r a t o r and s e r v e r IP and v a r i a b l e s f o r i p t a b l e s and s t a t e s

#s e e . a d d i p . t x t f o r IP i n f o r m a t i o n r e g a r d i n g t h e s e r v e r

adm_ip=$ ( head −n −1 /home/ l o c k / s c r i p t s / . a d d i p . t x t | g r e p −o ’ [ 0 − 9 . ] ∗ ’ ) s r v _ i p=$ ( t a i l −n −1 /home/ l o c k / s c r i p t s / . a d d i p . t x t | g r e p −o ’ [ 0 − 9 . ] ∗ ’ )

#Adding v a r i a b l e s

IPTABLES=/ s b i n / i p t a b l e s

n e w s t a t e="−m s t a t e −−s t a t e NEW, ESTABLISHED −j ACCEPT"

s t a t e ="−m s t a t e −−s t a t e ESTABLISHED −j ACCEPT"

r e l s t a t e ="−m s t a t e −−s t a t e ESTABLISHED,RELATED −j ACCEPT"

# i f f i l e r e p o r t s . t x t e x i s t t h e n t h e s e r u l e s w i l l be added i f [ −r $ f i l e ] ; t h e n

IP=$(</home/ l o c k / r e p o r t . t x t )

#F l u s h e s t h e i p t a b l e r u l e

$IPTABLES −F

$IPTABLES −X

#Drops a l l t r a f i c i n p u t t r a f f i c but a c c e p t outbound

$IPTABLES −P INPUT DROP

$IPTABLES −P OUTPUT ACCEPT

$IPTABLES −P FORWARD ACCEPT

#Allow admin and IP from t e x t f i l e t o SSH i n t o t h e s e r v e r

$IPTABLES −A INPUT −p t c p −s $adm_ip −d $ s r v _ i p −−s p o r t 5 1 3 : 6 5 5 3 5 −−d p o r t 22

$ n e w s t a t e

$IPTABLES −A INPUT −p t c p −s $IP −d $ s r v _ i p −−s p o r t 5 1 3 : 6 5 5 3 5 −−d p o r t 22

$ n e w s t a t e

#Adding r u l e s from f i l e

sudo sh /home/ l o c k / s c r i p t s / i p t a b l e s . sh

#Moving and c h a n g i n g a c c e s s

sudo chown r o o t : r o o t /home/ l o c k / r e p o r t . t x t sudo chmod 000 /home/ l o c k / r e p o r t . t x t

sudo mv /home/ l o c k / r e p o r t . t x t / e t c / l o c k / IP . t x t

(25)

Appendix A. Data

e l s e

e c h o "No f i l e e x i s t s "

f i

Bilaga D

#!/ b i n / sh

e c h o " F a i l s a f e a k t i v e r a d . "

#a d d i n g f i l e l o c a t i o n t o v a r i a b l e f i l e =/ e t c / l o c k / IP . t x t

$IPTABLES −F

$IPTABLES −X

$IPTABLES −P INPUT DROP

$IPTABLES −P FORWARD DROP

$IPTABLES −P OUTPUT DROP

$IPTABLES −A INPUT − i l o −j ACCEPT

$IPTABLES −A OUTPUT −o l o −j ACCEPT

$IPTABLES −A INPUT −p t c p −s $adm_ip −d $ s r v _ i p −−s p o r t 5 1 3 : 6 5 5 3 5 −−d p o r t 22

$ n e w s t a t e

$IPTABLES −A OUTPUT −p t c p −s $ s r v _ i p −d $adm_ip −−s p o r t 22 −−d p o r t 5 1 3 : 6 5 5 3 5

$ s t a t e

sudo sh /home/ l o c k / s c r i p t s / i p t a b l e s . sh e l s e

e c h o " Nothing happens "

f i Bilaga E

(26)

Appendix A. Data

#!/ b i n / bash

#a d d i n g f i l e l o c a t i o n t o v a r i a b l e f i l e =/ e t c / l o c k / IP . t x t

IP=$(</ e t c / l o c k / IP . t x t )

sudo sh / u s r / l o c a l / s c r i p t s / i p t a b l e s . sh

#Removes t h e f i l e s o t h a t t h e s c r i p t s wont run i f t h e f i l e do n o t e x i s t sudo rm / e t c / l o c k / IP . t x t

sudo k i l l a l l s c r e e n e l s e

e c h o " no s u c h f i l e e x i s t s "

f i Bilaga F

#!/ u s r / b i n / e x p e c t s e t t i m e o u t 75

spawn minicom −C /home/ l o c k / c o n f i g /SW1 . t x t −b 9600 −D / dev / ttyUSB0 s l e e p 3

s e n d "\ r \ r "

s e n d "\ n e n a b l e \n"

s e n d "\ n t e r l e n 0 \n"

s e n d "\ n sh run \n"

s l e e p 2

s e n d " d e l e t e f l a s h : v l a n . da t \ r \ r \ r "

s e n d " d e l e t e nvram : s t a r t u p −c o n f i g \ r \ r \ r "

s e n d " r e l o a d \ r \ r \ r "

s l e e p 6

spawn minicom −C /home/ l o c k / c o n f i g /SW2 . t x t −b 9600 −D / dev / ttyUSB1

(27)

Appendix A. Data

s l e e p 3 s e n d "\ r \ r "

s l e e p 2

s e n d " r e l o a d \ r \ r \ r "

s l e e p 6

spawn minicom −C /home/ l o c k / c o n f i g /SW3 . t x t −b 9600 −D / dev / ttyUSB2 s l e e p 3

s e n d "\ r \ r "

s l e e p 2

s e n d " r e l o a d \ r \ r \ r "

s l e e p 6

spawn minicom −C /home/ l o c k / c o n f i g /R1 . t x t −b 9600 −D / dev / ttyUSB3 s l e e p 3

s e n d "\ r \ r "

s l e e p 2

s e n d " r e l o a d \ r \ r \ r "

s l e e p 6

s e n d "\ r \ r "

s l e e p 2

s e n d " r e l o a d \ r \ r \ r "

s l e e p 6

(28)

Appendix A. Data

s e n d "\ r \ r "

s l e e p 2

s e n d " r e l o a d \ r \ r \ r "

s l e e p 6

e x i t Bilaga G

#!/ b i n / bash

#S e t s t h e t e r m i n a l and t h e n run a new s c r i p t TERM=v t 1 0 0

e x p o r t TERM

/home/ l o c k / s c r i p t s / s a v e _ c o n f . sh Bilaga H

#!/ b i n / bash

#s a v e s a l l t h e f i l e s w i t h t h e . t x t e x t e n s i o n t o FILE and t h e n moves them t o t h e u s e r

#home

f o r FILE i n ‘ l s /home/ l o c k / c o n f i g / ∗ . t x t ‘ do mv $FILE $HOME/ c o n f i g

e c h o "$FILE moved"

done Bilaga I

#!/ b i n / bash

c r o n ="/home/ l o c k / s c r i p t s / c r o n . sh > / dev / n u l l "

Move="/home/ l o c k / s c r i p t s / MoveFile . sh > / dev / n u l l "

j o b 1 ="55 0 7 , 1 1 , 1 5 , 1 9 , 2 3 , 0 3 ∗ ∗ ∗ $ c r o n "

j o b 2 ="∗ ∗ ∗ ∗ ∗ $Move"

c a t <( f g r e p − i −v " $ c r o n " <( c r o n t a b − l ) ) <( e c h o " $ j o b 1 " ) | c r o n t a b − c a t <( f g r e p − i −v "$Move" <( c r o n t a b − l ) ) <( e c h o " $ j o b 2 " ) | c r o n t a b − Bilaga J

#!/ b i n / bash

(29)

Appendix A. Data

#A c l o c k t h a t shows t h e t i m e and i n f o r m a t i o n f o r t h e u s e r . now="$ ( d a t e +"%T" ) "

e c h o "Do you want t o s t a r t a s e s s i o n ?"

e c h o " Remeber t h a t you s h o u l d o n l y s t a r t a s e s s i o n a f t e r 0 8 : 0 5 , 1 2 : 0 5 , 1 6 : 0 5 , 2 0 : 0 5 , 0 0 : 0 5 , 0 4 : 0 5 ( t i m e between 0 8 : 0 0 − 0 8 : 0 5 , 1 2 : 0 0 − 1 2 : 0 5 and s o on i s t h e "

e c h o " c r i t i c a l DO NOT START TIME . ) "

e c h o " I f you don ’ t s t a r t a s e s s i o n a f t e r t h e s p e c i f i e d t i m e you wont g e t p r i v a c y and t h e c o n f i g u r a t i o n s wont a u t o m a t i c a l l y become s a v e d . "

e c h o "Time now i s : "$now

#C r e a t e s a y e s and a no c h o i c e f o r t h e u s e r .

#Loops i t u n t i l t h e u s e r makes a c h o i c e and t h e n q u i t t h e s c r i p t

# i f t h e u s e r u s e s a n y t h i n g but 1 and 2 which i s y e s o r no t h e u s e r i s prompted t o p r e s s

#1 o r 2

s e l e c t yn i n " Yes " "No " ; do c a s e $yn i n

Yes ) e c h o " P l e a s e w a i t 1 minute b e f o r e s t a r t i n g t o c o n f i g u r e " ; p e r l /home/ l o c k / GetIP . p l ; b r e a k ; ;

No ) e c h o "Be c a r e f u l a s o t h e r u s e r s can l o c k you o ut a t any g i v e n t i m e ! " ; b r e a k ; ;

∗ ) echo " P l e a s e p r e s s 1 f o r y e s and 2 f o r no " ; ; e s a c

done

Remote Netlab

Självständigt arbete på grundnivå

Independent degree project - first cycle

Contents

List of Figures

1 Introduktion

2 Teori

3 Metod

4 Resultat

5 Diskussion

References

A Data