Självständigt arbete på grundnivå

Transkript

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, Handledare: Lennart Franked, Författare: Tobias Engkvist, 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 ii

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 iii

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 iv

5 Contents Sammanfattning Abstract Contents List of Figures iii iv v vii 1 Introduktion Bakgrund Syfte Mål Tidsplan Avgränsningar Frågeställning Teori SSH Fillåsning IPTABLES Perl POLA Definition av termer och förkortningar Metod Förberedelse Implementera iptables Spara konfigurationen Tidsbegränsa användare Automatisera Resultat 9 5 Diskussion Vidare arbeten Etik v

6 Contents References 15 A Data 16 vi

7 List of Figures 2.1 Figuren visar en övervakning över hur iptables tillåter och blockerar paket Figur visar hur olika paket blir muliplexade, att de blir muxade och skickas sedan över samma kanal Figuren visar en översikt i logiken bakom skripten och hur användaren blir inlåst i systemet Figur som visar hur logiken bakom skripten ser ut Figur som visar uppstartsfrågan, om en användare vill påbörja en session eller inte Figur som visar jobben som installeras till crontab för användaren Figur som visar jobben som finns förinstallerade för superanvändaren Figur som visar att enbart användare med IP får tillgång till systemet(i detta fall administratören och den användare som körde skriptet) med SSH Figur som visar att användare med IP-adress inte kommer åt en testmiljö eftersom att den inte är tillåten Figur som visar att enbart användare med IP (vilket är administratör) får tillgång till systemet vii

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 1.3 Mål 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. 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 leverantören. Mellan varje videomöte så kommer beställaren och leverantören ha minst ett 1

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? 2

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] 3

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 2.4 Perl 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] 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 4

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] 5

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 6

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 7

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. 8

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. 9

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. 10

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 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 inte kommer åt en testmiljö eftersom att den inte är tillåten. 11

19 Chapter 4. Resultat Figure 4.7 Figur som visar att enbart användare med IP (vilket är administratör) får tillgång till systemet 12

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 13

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 laborationerna, 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. 14

22 References [1] Ylonen T, Lonvick C. The Secure Shell (SSH) Protocol Architecture. IETF; RFC 4251 (Proposed Standard). Available from: [2] 2 Types of Linux File Locking (Advisory and Mandatory Lock Examples);. Accessed: Available from: [3] IptablesHowTo;. Accessed: Available from: community/iptableshowto. [4] How the Iptables Firewall Works;. Accessed: Available from: 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; [6] About Perl;. Accessed: Available from: html. [7] IPTables::IPv4;. Accessed: Available from: ~dpates/iptables-ipv4-0.98/ipv4.pm. [8] Principle of least astonishment;. Accessed: Available from: wikipedia.org/wiki/principle_of_least_astonishment. [9] What are time sharing and multiuser operating systems, and what are some examples?;. Accessed: Available from: [10] Definition of multiplex;. Accessed: Available from: [11] Minicom;. Accessed: Available from: community/minicom. [12] Perl Modules;. Accessed: Available from: modules/. [13] Få tag på Debian;. Accessed: Available from: distrib/. 15

23 A Data Bilaga A #!/ bin / sh echo " 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 #!/ usr / bin / p e r l #using warnings, s t r i c t and other needed modules use s t r i c t ; use warnings ; use SVN : : U t i l s : : ClientIP qw( ssh_client_ip ) ; #Adding c l i e n t IP and f i l e to v a r i a b l e s. my $IP = ssh_client_ip ( ) ; my $ f i l e n a m e = /home/ l o c k / r e p o r t. txt ; my $crontab = /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 user IP address to i t, i f f i l e does not e x i s t the 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 only the IP a d r e s s open (my $fh, >, $ f i l e n a m e ) or d i e "Could not open f i l e $filename $! " ; p r i n t $fh $IP, "\n " ; c l o s e $fh ; #Adds a cronjob to crontab f o r the running 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 to put 16

24 Appendix A. Data #them i n t o system ( $crontab ) ; system ( $MakeFolder ) ; system ( s c r e e n dms save_conf ) ; Bilaga C #!/ bin / bash #adding f i l e l o c a t i o n to v a r i a b l e f i l e =/home/ l o c k / r e p o r t. txt #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. addip. txt f o r IP i n f o r m a t i o n r e g a r d i n g the s e r v e r adm_ip=$ ( head n 1 /home/ l o c k / s c r i p t s /. addip. txt grep o [ 0 9. ] ) srv_ip=$ ( t a i l n 1 /home/ l o c k / s c r i p t s /. addip. txt grep o [ 0 9. ] ) #Adding v a r i a b l e s IPTABLES=/sbin / i p t a b l e s newstate=" 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. txt e x i s t then t h e s e r u l e s w i l l be added i f [ r $ f i l e ] ; then IP=$(</home/ l o c k / r e p o r t. txt ) #Flushes the 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 input t r a f f i c but accept 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 to SSH i n t o the s e r v e r $IPTABLES A INPUT p tcp s $adm_ip d $srv_ip s p o r t 513:65535 dport 22 $newstate $IPTABLES A INPUT p tcp s $IP d $srv_ip s p o r t 513:65535 dport 22 $newstate #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 changing a c c e s s sudo chown root : root /home/ l o c k / r e p o r t. txt sudo chmod 000 /home/ l o c k / r e p o r t. txt sudo mv /home/ l o c k / r e p o r t. txt / e t c / l o c k /IP. txt 17

25 Appendix A. Data e l s e f i Bilaga D echo "No f i l e e x i s t s " #!/ bin / sh echo " F a i l s a f e a k t i v e r a d. " #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. addip. txt f o r IP i n f o r m a t i o n r e g a r d i n g the s e r v e r adm_ip=$ ( head n 1 /home/ l o c k / s c r i p t s /. addip. txt grep o [ 0 9. ] ) srv_ip=$ ( t a i l n 1 /home/ l o c k / s c r i p t s /. addip. txt grep o [ 0 9. ] ) #Adding v a r i a b l e s IPTABLES=/sbin / i p t a b l e s newstate=" 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" #adding f i l e l o c a t i o n to v a r i a b l e f i l e =/e t c / l o c k /IP. txt #i f f i l e r e p o r t s. txt e x i s t then t h e s e r u l e s w i l l be added i f [ r $ f i l e ] ; then $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 tcp s $adm_ip d $srv_ip s p o r t 513:65535 dport 22 $newstate $IPTABLES A OUTPUT p tcp s $srv_ip d $adm_ip s p o r t 22 dport 513:65535 $ s t a t e e l s e f i Bilaga 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 echo " Nothing happens " 18

26 Appendix A. Data #!/ bin / bash #adding f i l e l o c a t i o n to v a r i a b l e f i l e =/e t c / l o c k /IP. txt #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. addip. txt f o r IP i n f o r m a t i o n r e g a r d i n g the s e r v e r adm_ip=$ ( head n 1 /home/ l o c k / s c r i p t s /. addip. txt grep o [ 0 9. ] ) srv_ip=$ ( t a i l n 1 /home/ l o c k / s c r i p t s /. addip. txt grep o [ 0 9. ] ) #Adding v a r i a b l e s IPTABLES=/sbin / i p t a b l e s newstate=" 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. txt e x i s t then t h e s e r u l e s w i l l be added i f [ r $ f i l e ] ; then IP=$(</ e t c / l o c k /IP. txt ) e l s e f i Bilaga F #Adding r u l e s from f i l e sudo sh / usr / l o c a l / s c r i p t s / i p t a b l e s. sh #Removes the f i l e so that the s c r i p t s wont run i f the f i l e do not e x i s t sudo rm / e t c / l o c k /IP. txt sudo k i l l a l l s c r e e n echo "no such f i l e e x i s t s " #!/ usr / bin / expect s e t timeout 75 spawn minicom C /home/ l o c k / c o n f i g /SW1. txt b 9600 D /dev/ttyusb0 s l e e p 3 send "\ r \ r " send "\n enable \n" send "\n t e r l e n 0 \n" send "\ n sh run \n" s l e e p 2 send " d e l e t e f l a s h : vlan. dat \ r \ r \ r " send " d e l e t e nvram : startup c o n f i g \ r \ r \ r " send " 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. txt b 9600 D /dev/ttyusb1 19

27 Appendix A. Data s l e e p 3 send "\ r \ r " send "\n enable \n" send "\n t e r l e n 0 \n" send "\ n sh run \n" s l e e p 2 send " d e l e t e f l a s h : vlan. dat \ r \ r \ r " send " d e l e t e nvram : startup c o n f i g \ r \ r \ r " send " 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. txt b 9600 D /dev/ttyusb2 s l e e p 3 send "\ r \ r " send "\n enable \n" send "\n t e r l e n 0 \n" send "\ n sh run \n" s l e e p 2 send " d e l e t e f l a s h : vlan. dat \ r \ r \ r " send " d e l e t e nvram : startup c o n f i g \ r \ r \ r " send " 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. txt b 9600 D /dev/ttyusb3 s l e e p 3 send "\ r \ r " send "\n enable \n" send "\n t e r l e n 0 \n" send "\ n sh run \n" s l e e p 2 send " d e l e t e f l a s h : vlan. dat \ r \ r \ r " send " d e l e t e nvram : startup c o n f i g \ r \ r \ r " send " 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 /R2. txt b 9600 D /dev/ttyusb4 s l e e p 3 send "\ r \ r " send "\n enable \n" send "\n t e r l e n 0 \n" send "\ n sh run \n" s l e e p 2 send " d e l e t e f l a s h : vlan. dat \ r \ r \ r " send " d e l e t e nvram : startup c o n f i g \ r \ r \ r " send " r e l o a d \ r \ r \ r " s l e e p 6 20

28 Appendix A. Data spawn minicom C /home/ l o c k / c o n f i g /R3. txt b 9600 D /dev/ttyusb5 s l e e p 3 send "\ r \ r " send "\n enable \n" send "\n t e r l e n 0 \n" send "\ n sh run \n" s l e e p 2 send " d e l e t e f l a s h : vlan. dat \ r \ r \ r " send " d e l e t e nvram : startup c o n f i g \ r \ r \ r " send " r e l o a d \ r \ r \ r " s l e e p 6 e x i t Bilaga G #!/ bin / bash #Sets the t e r m i n a l and then run a new s c r i p t TERM=vt100 export TERM /home/ l o c k / s c r i p t s / save_conf. sh Bilaga H #!/ bin / bash #saves a l l the f i l e s with the. txt e x t e n s i o n to FILE and then moves them to the user #home f o r FILE in l s /home/ l o c k / c o n f i g /. txt do mv $FILE $HOME/ c o n f i g echo "$FILE moved" done Bilaga I #!/ bin / bash cron="/home/ l o c k / s c r i p t s / cron. 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 " job1 ="55 07,11,15,19,23,03 $cron " job2=" $Move" cat <( f g r e p i v " $cron " <(crontab l ) ) <(echo " $job1 ") crontab cat <( f g r e p i v "$Move" <(crontab l ) ) <(echo " $job2 ") crontab Bilaga J #!/ bin / bash 21

29 Appendix A. Data #A c l o c k that shows the time and i n f o r m a t i o n f o r the user. now="$ ( date +"%T")" echo "Do you want to s t a r t a s e s s i o n?" echo "Remeber that you should only 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, 04:05 ( time between 08:00 08:05, 12:00 12:05 and so on i s the " echo " c r i t i c a l DO NOT START TIME. ) " echo " I f you don t s t a r t a s e s s i o n a f t e r the s p e c i f i e d time you wont get privacy and the 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 saved. " echo "Time now i s : "$now #Creates a yes and a no c h o i c e f o r the user. #Loops i t u n t i l the user makes a c h o i c e and then q u i t the s c r i p t #i f the user uses anything but 1 and 2 which i s yes or no the user i s prompted to p r e s s #1 or 2 s e l e c t yn in "Yes" "No" ; do case $yn in Yes ) echo " Please wait 1 minute b e f o r e s t a r t i n g to c o n f i g u r e " ; p e r l /home/ l o c k /GetIP. pl ; break ; ; No ) echo "Be c a r e f u l as other u s e r s can l o c k you out at any given time! " ; break ; ; ) echo " Please p r e s s 1 f o r yes and 2 f o r no " ; ; esac done 22