Izgradnja LAMP poslužitelja i sve to lijepo konfiguriranje s pouzdanim rukovanjem podacima, domenom i TLS certifikatom samo je pola uspjeha. Također ćete morati biti sigurni da je vaša infrastruktura zaštićena od mnogih zastrašujućih prijetnji na internetu.
U ovom članku - koji je izdvojen iz 9. poglavlja moje knjige Manning, Linux u akciji - istražit ću sigurnost web stranica pravilnom upotrebom sistemskih grupa, izolacijom procesa i redovitim revizijama resursa vašeg sustava. Nije cijela priča (moja knjiga o Linuxu u akciji obuhvaća dodatne alate poput instaliranja TLS certifikata i rada sa SELinuxom), ali sjajan je početak.
Grupe sustava i načelo najmanje privilegiranosti
Programeri koje podržavate (napokon) su shvatili da trebaju ograničiti javni pristup podacima i konfiguracijskim datotekama koje žive na aplikacijskom poslužitelju, a da istovremeno omogućuju pristup raznim razvojnim i IT timovima.
Prvi dio rješenja su grupe . Grupa je sistemski objekt - gotovo isto što i korisnik - osim što se nitko nikada neće prijaviti u sustav kao grupa. Moć grupa je u tome kako se oni, poput korisnika, mogu "dodijeliti" datotekama ili direktorijima, omogućavajući bilo kojim članovima grupe da dijele ovlasti grupe. To je prikazano na slici.
Pokušajte i sami: upotrijebite uređivač teksta za stvaranje nove datoteke. Dodajte tekst "Hello world" kako biste lako mogli znati kada mu možete uspješno pristupiti. Sada uredite njegova dopuštenja pomoću chmod 770 tako da vlasnik i grupa datoteke imaju puna prava nad datotekom, ali drugi je ne mogu ni pročitati.
nano datafile.txt chmod 770 datafile.txtAko vaš sustav osim vašeg računa već nema dodatnog korisnika, stvorite ga pomoću addusera - na način Debian / Ubuntu - ili useradda ako ste na CentOS-u. useradd će raditi i na Ubuntuu.
Naredba useradd (za razliku od Debian addusera) zahtijeva od vas
generirajte korisničku lozinku odvojeno:
# useradd otheruser # passwd otheruser Enter new UNIX password: Retype new UNIX password: passwd: password updated successfullyUpotrijebite su za prebacivanje na novog korisnika. Jednom kada unesete korisničku lozinku, sve naredbe koje izvršite pokrenut će se kao taj korisnik. Radit ćete samo s autoritetom tog korisnika: ni više ni manje. Ako pokušate pročitati datoteku datafile.txt (pomoću mačke), nećete imati sreće jer, kao što se sjećate, drugima je odbijeno odobrenje za čitanje. Kad završite, upišite exit da biste napustili novu korisničku ljusku i vratili se u svoju izvornu ljusku.
$ su otheruser Password: $ cat /home/ubuntu/datafile.txt cat: /home/ubuntu/datafile.txt: Permission denied $ exitSve je to očekivano i lako razumljivo. I, kao što ste vidjeli, nemogućnost čitanja datoteke koja pripada drugom čitaču ponekad može predstavljati problem. Pogledajmo što možemo učiniti s tim pridruživanjem datoteke grupi i pravilnim konfiguriranjem dozvola datoteke.
Stvorite novu grupu koju možete koristiti za upravljanje podacima aplikacije, a zatim uredite svojstva datoteke podataka pomoću chown-a. Argument ubuntu: app-data-group ostavlja vlasništvo nad datotekama u rukama korisnika ubuntu, ali mijenja svoju grupu u vašu novu grupu podataka-podataka.
groupadd app-data-group chown ubuntu:app-data-group datafile.txtPokrenite ls s "long" izlazom prema datoteci da biste pogledali nova dopuštenja i status. Imajte na umu da je, kako se i očekivalo, ubuntu vlasnik datoteke, a app-data-group njegova grupa.
$ ls -l | grep datafile.txt -rwxrwx — — 1 ubuntu app-data-group 6 Aug 9 22:43 datafile.txtMožete koristiti usermod da biste svog korisnika dodali u grupu aplikacija-podataka-grupe, a zatim, još jednom, da se prebacite na ljusku koja raspoređuje račun drugog korisnika. Ovaj put, iako dopuštenja datoteke zaključavaju druge - a vi se trenutno ponašate kao "drugi" korisnik - trebali biste je moći pročitati zahvaljujući članstvu u grupi.
# usermod -aG app-data-group otheruser $ su otheruser $ cat datafile.txt Hello WorldKoristite su za prebacivanje između korisničkih računa. Slučajno je to bio sadržaj moje datoteke datafile.txt. Ovakva je organizacija ispravan i učinkovit način za rješavanje mnogih složenih problema s dozvolama koji će se pojaviti na višekorisničkom sustavu.
Zapravo se ne samo da se pojedinim korisnicima daje pristup koji im treba, već mnogi sistemski procesi ne bi mogli obavljati svoj posao bez posebnog članstva u grupi. Kratko pregledajte datoteku / etc / group i zabilježite koliko sistemski procesi imaju svoje vlastite grupe.
Djelomičan popis sadržaja datoteke / etc / group:
$ cat /etc/group root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4:syslog tty:x:5: disk:x:6: lp:x:7: mail:x:8: news:x:9: uucp:x:10: man:x:12: proxy:x:13: […]Procesi izolacije unutar spremnika
Zabrinuti da će više usluga koje imate pokrenute na jednom poslužitelju, treba li prekršiti jednu uslugu, a sve biti u opasnosti? Jedan od načina da se ograniči šteta koju mogu izazvati neoprezni ili zlonamjerni korisnici jest izoliranje resursa i procesa sustava. Na taj način, čak i ako netko možda želi proširiti svoj doseg preko zadane granice, neće imati fizički pristup.
Stari pristup problemu bio je osiguravanje zasebnog fizičkog stroja za svaku uslugu. No, virtualizacija može puno olakšati - i priuštiti cijenu - izgradnju "prigušene" infrastrukture.
Ova se arhitektura često naziva mikrouslugama i htjeli biste da pokrenete više spremnika s jednim, možda koji pokreće samo bazu podataka, drugi Apache i treći koji sadrži medijske datoteke koje bi mogle biti ugrađene u vaše web stranice. Uz brojne prednosti izvedbe i učinkovitosti povezane s arhitekturama mikroservisa, to može uvelike smanjiti izloženost svakoj pojedinoj komponenti.
Pod pojmom "kontejneri" ne mislim nužno na one koji uvjeravaju LXC.
Danas su za ovu vrstu primjene Dockerovi kontejneri daleko više
popularan. Ako vas zanima više o Dockeru, pogledajte moje tečajeve Pluralsight-a koji se dotiču te teme.
Traženje opasnih vrijednosti User ID-a
Iako će bilo koji administratorski korisnik moći privremeno preuzeti ovlaštenje korijena koristeći sudo, samo je root zapravo root. Kao što ste već vidjeli, nije sigurno izvoditi redovite funkcije kao root. Ali može se dogoditi - bilo nevinom nesrećom ili zlonamjernim neovlaštenim promjenama - da redoviti korisnik može učinkovito dobiti administratorska prava u punom radnom vremenu.
Dobra vijest je da je lako uočiti varalice: njihovi ID brojevi korisnika i / ili grupa bit će, poput root, nula (0). Pogledajte datoteku passwd u / etc /. Ova datoteka sadrži zapis za svaki redovni i sistemski korisnički račun koji trenutno postoji. Prvo polje sadrži naziv računa (u ovom slučaju root i ubuntu), a drugo polje može sadržavati x umjesto lozinke (koja će se, ako postoji, pojaviti šifrirana u datoteci / etc / shadow). Ali sljedeća dva polja sadrže ID-ove korisnika i grupe. U slučaju ubuntu-a u ovom primjeru, oba ID-a su 1000. I, kao što vidite, root ima nule.
$ cat /etc/passwd root:x:0:0:root:/root:/bin/bash […] ubuntu:x:1000:1000::/home/ubuntu:/bin/bashIf you ever see a regular user with a user or group ID of 0, however, then you know there’s something nasty going on and you should get to work fixing it.The quick and easy way to spot a problem is to run this awk command against the passwd file, which will print out any line whose third field contains only a 0. In this case, to my great relief, the only result was root . You can run it a second time substituting $4 for $3 to pick up the group ID field.
$ awk -F: ‘($3 == “0”) {print}’ /etc/passwd root:x:0:0:root:/root:/bin/bashAuditing system resources
The more things you’ve got running, the greater the odds of something breaking. So it makes sense that you’ll want to keep track of what’s running. This will apply to network ports (if they’re “open” then, by definition, there must be a way in), services (if they’re active, then people can run them), and installed software (if it’s installed, it can be executed).
For audits to be useful you’ll have to remember to run them once in a while. Since you just know you’re going to forget, you’ll be much better off incorporating your auditing tools into a script that not only executes regularly but, ideally, also parses the results to make them more readable.
Here, however, I’ll focus on introducing you to three key audit tools to help you scan for open ports, active services, and unnecessary software packages. Getting it automated will be your job.
Scanning for open ports
A port is considered “open” if there’s some process running on the host that’s listening on that port for requests. Keeping an eye on your open ports can keep you plugged into what’s really going on with your server.
You already know that a regular web server is probably going to have HTTP (80) and SSH (22) open, so it shouldn’t come as a surprise to come across those. But you’ll really want to focus on other unexpected results. netstat will display open ports along with a wealth of information about how they’re being used.
In this example run against a fairly typical multi-purpose server, -n tells netstat to include the numeric ports and addresses. -l includes only listening sockets, and -p adds the process ID of the listening program. Naturally, if you see something, do something.
# netstat -npl Active Internet connections (only servers) Proto Local Address Foreign Address State PID/Program name tcp 127.0.0.1:3306 0.0.0.0:* LISTEN 403/mysqld tcp 0.0.0.0:139 0.0.0.0:* LISTEN 270/smbd tcp 0.0.0.0:22 0.0.0.0:* LISTEN 333/sshd tcp 0.0.0.0:445 0.0.0.0:* LISTEN 270/smbd tcp6 :::80 :::* LISTEN 417/apache2 […]In recent years, ss has begun to replace netstat for many uses. Just in case you find yourself at a party one day and someone asks you about ss , this example (which lists all established SSH connections) should give you enough information to save you from deep embarrassment:
$ ss -o state established ‘( dport = :ssh or sport = :ssh )’ Netid Recv-Q Send-Q Local Address:Port Peer Address:Port tcp 0 0 10.0.3.1:39874 10.0.3.96:ssh timer:(keepalive,18min,0)Scanning for active services
Getting a quick snapshot of the systemd-managed services currently enabled on your machine can help you spot activity that doesn’t belong. systemctl can list all existing services, which can then be narrowed down to only those results whose descriptions include enabled. This will return only active services.
# systemctl list-unit-files — type=service — state=enabled [email protected] enabled bind9.service enabled cron.service enabled dbus-org.freedesktop.thermald.service enabled docker.service enabled [email protected] enabled haveged.service enabled mysql.service enabled networking.service enabled resolvconf.service enabled rsyslog.service enabled ssh.service enabled sshd.service enabled syslog.service enabled systemd-timesyncd.service enabled thermald.service enabled unattended-upgrades.service enabled ureadahead.service enabledIf you do find something that shouldn’t be there, you can use systemctl to both stop the service and make sure it doesn’t start up again with the next boot.
systemctl stop haveged systemctl disable havegedThere’s actually nothing dark and sinister about the haveged service I’m
stopping in this example: it’s a very small tool I often install to generate
random background system activity when I’m creating encryption keys.
Searching for installed software
Could someone or something have installed software on your system without you knowing? Well, how would you know if you don’t look? yum list installed or, on Debian/Ubuntu, dpkg — list will give you the whole briefing, while remove should delete any packages that don’t belong.
yum list installed yum remove packageNameHere’s how it goes on Ubuntu:
dpkg --list apt-get remove packageNameIt’s also a good idea to be aware of changes to your system configuration files - which is something I cover in chapter 11.
This article is excerpted from my Manning “Linux in Action” book. There’s lots more fun where this came from, including a hybrid course called Linux in Motionthat’s made up of more than two hours of video and around 40% of the text of Linux in Action. Who knows... You might also enjoy my recently published Learn Amazon Web Services in a Month of Lunches.