Hogyan védhetjük meg a Linux webszervert

A LAMP szerver felépítése és az összes szép konfigurálása megbízható adatkezeléssel, tartományral és TLS tanúsítvánnyal csak a harc fele. Arra is ügyelnie kell, hogy infrastruktúrája védve legyen az internet sok ijesztő fenyegetésétől.

Ebben a cikkben - amelyet a Manning könyvem 9. fejezetéből vettünk ki, a Linux in Action - a webhelyek biztonságát a rendszercsoportok megfelelő használata, a folyamatok elkülönítése és a rendszererőforrások rendszeres ellenőrzése révén vizsgálom. Nem ez a teljes történet (a Linux in Action könyvem további eszközöket tartalmaz, például a TLS-tanúsítványok telepítését és a SELinux-szal való együttműködést), de remek kezdet.

Rendszercsoportok és a legkevesebb privilégium elve

Az általad támogatott fejlesztők rájöttek (végre), hogy korlátozniuk kell az alkalmazáskiszolgálón élő adatokhoz és konfigurációs fájlokhoz való nyilvános hozzáférést, miközben továbbra is lehetővé teszik a hozzáférést a különböző fejlesztői és informatikai csapatokhoz.

A megoldás első része csoportok . A csoport rendszerobjektum - nagyjából megegyezik a felhasználóval -, kivéve, hogy soha senki nem jelentkezik be a rendszerbe csoportként. A csoportok ereje abban rejlik, hogy miként lehet a felhasználókhoz hasonlóan fájlokhoz vagy könyvtárakhoz "hozzárendelni", lehetővé téve a csoport bármely tagjának, hogy megosszák a csoport hatáskörét. Ezt szemlélteti az ábra.

Próbálja ki ezt maga: egy szövegszerkesztővel hozzon létre új fájlt. Adjon hozzá egy „Hello world” szöveget, hogy könnyedén meg tudja mondani, mikor érheti el sikeresen. Most szerkessze az engedélyeit a chmod 770 használatával, hogy a fájl tulajdonosa és csoportja teljes jogokkal rendelkezzen a fájl felett, mások azonban még el sem tudják olvasni.

nano datafile.txt chmod 770 datafile.txt

Ha a rendszernek még nincs extra felhasználója a fiókján kívül, hozzon létre egyet az adduser - Debian / Ubuntu mód - vagy a useradd használatával, ha CentOS-t használ. A useradd az Ubuntun is működik.

A useradd parancs (szemben a Debian adduserrel) megköveteli

külön generáljon felhasználói jelszót:

# useradd otheruser # passwd otheruser Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully

Használja a su gombot az új felhasználóra váltáshoz. Miután megadta a felhasználó jelszavát, az összes végrehajtott parancs futtatásra kerül. Csak annak a felhasználónak a jogosultságával fog dolgozni: sem többet, sem kevesebbet. Ha megpróbálja elolvasni a datafile.txt fájlt (a cat használatával), akkor nem lesz szerencséje, mivel, ahogy emlékszik, másoknak megtagadták az olvasási engedélyt. Ha végzett, írja be az exit parancsot, hogy elhagyja az új felhasználói héjat, és visszatérjen az eredeti héjhoz.

$ su otheruser Password: $ cat /home/ubuntu/datafile.txt cat: /home/ubuntu/datafile.txt: Permission denied $ exit

Mindez várható és könnyen érthető. És amint látta, néha problémát okozhat, ha nem olvassa el a másik olvasóhoz tartozó fájlt. Lássuk, mit tehetünk a fájl társításával egy csoportba, majd a fájl engedélyeinek megfelelő konfigurálásával.

Hozzon létre egy új csoportot, amelynek segítségével kezelheti az alkalmazás adatait, majd az chown használatával szerkesztheti az adatfájl tulajdonságait. Az ubuntu: app-data-group argumentum a fájl tulajdonjogát az ubuntu felhasználó kezébe hagyja, de a csoportját az új app-data-groupra cseréli.

groupadd app-data-group chown ubuntu:app-data-group datafile.txt

Futtassa az ls fájlt a „hosszú” kimenettel az új engedélyek és állapot megtekintéséhez. Ne feledje, hogy ahogy az várható volt, az ubuntu a fájl tulajdonosa, az app-data-csoport pedig a csoportja.

$ ls -l | grep datafile.txt -rwxrwx — — 1 ubuntu app-data-group 6 Aug 9 22:43 datafile.txt

A usermod használatával felveheti a felhasználót az app-data-group csoporthoz, majd ismét su, hogy átváltson egy shellre, amely a másik felhasználó fiókját telepíti. Ezúttal annak ellenére, hogy a fájl jogosultságai kizárják a többieket - és jelenleg Ön határozottan „másik” felhasználóként viselkedik -, a csoporttagságának köszönhetően képesnek kell lennie arra, hogy elolvassa.

# usermod -aG app-data-group otheruser $ su otheruser $ cat datafile.txt Hello World

A su használatával válthat a felhasználói fiókok között. Ez történetesen a datafile.txt fájlom tartalma volt. Ez a fajta szervezet a helyes és hatékony módszer a többfelhasználós rendszeren felmerülő bonyolult engedélyekkel kapcsolatos problémák kezelésére.

Valójában nem csak arra használják, hogy az egyes felhasználók számára hozzáférést biztosítsanak a számukra, hanem számos rendszerfolyamat nem tudná elvégezni a munkáját speciális csoporttagságok nélkül. Gyorsan nézze át az / etc / group fájlt, és vegye figyelembe, hogy hány rendszerfolyamatnak van saját csoportja.

Az / etc / group fájl tartalmának részleges felsorolása:

$ 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: […]

Elkülönítési folyamatok konténereken belül

Aggódik, hogy az egyetlen kiszolgálón futtatott több szolgáltatás, meg kell-e szakítani egy szolgáltatást, mind veszélybe kerülnek? A gondatlan vagy rosszindulatú felhasználók által okozott károk korlátozásának egyik módja a rendszer erőforrásainak és folyamatainak elkülönítése. Így még akkor is, ha valaki szeretné kiterjeszteni elérését egy meghatározott határon túl, nem lesz fizikai hozzáférése.

A probléma régi megközelítése az volt, hogy minden szolgáltatáshoz külön fizikai gépet láttak el. De a virtualizáció sokkal könnyebbé és megfizethetőbbé teheti egy „elhallgatott” infrastruktúra kiépítését.

Ezt az architektúrát gyakran mikroszolgáltatásnak nevezik, és több tárolót kellene elindítania, amelyek közül az egyik talán csak egy adatbázist, egy másik Apache-t futtat, és egy harmadik olyan médiafájlokat tartalmaz, amelyek esetleg be vannak ágyazva a weboldalain. A mikroszolgáltatási architektúrákhoz kapcsolódó számos teljesítmény- és hatékonysági előny mellett ez jelentősen csökkentheti az egyes komponensek kockázati kitettségét.

A „konténerek” alatt nem feltétlenül értem az LXC meggyőzését.

Manapság az ilyen jellegű telepítéshez a Docker konténerek sokkal többek

népszerű. Ha többet szeretne megtudni a Dockerről, nézze meg a témát érintő Pluralsight tanfolyamaimat.

Veszélyes User ID-értékek keresése

Bár bármely rendszergazda felhasználó átmenetileg átveheti a root jogosultságokat a sudo használatával, valójában csak a root a root. Mint már látta, nem biztonságos a rendszeres funkciók gyökérként történő végrehajtása. De előfordulhat - akár ártatlan balesetből, akár rosszindulatú manipulációból -, hogy egy rendes felhasználó hatékonyan, teljes munkaidőben megszerezheti az adminisztrátori jogokat.

A jó hír az, hogy könnyű felismerni az impozánsokat: felhasználói és / vagy csoport azonosító számuk a gyökérhez hasonlóan nulla lesz (0). Vessen egy pillantást a passwd fájlra az / etc / könyvtárban. Ez a fájl egy rekordot tartalmaz minden létező rendszeres és rendszer felhasználói fiókhoz. Az első mező tartalmazza a fiók nevét (ebben az esetben a root és az ubuntu), a második mező pedig egy x-et tartalmazhat a jelszó helyett (amely, ha létezik, akkor az / etc / shadow fájlban titkosítva jelenik meg). De a következő két mező tartalmazza a felhasználói és csoportazonosítókat. Ebben a példában az ubuntu esetében mindkét azonosító 1000. És amint láthatja, a gyökérnek nulla.

$ cat /etc/passwd root:x:0:0:root:/root:/bin/bash […] ubuntu:x:1000:1000::/home/ubuntu:/bin/bash

If 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/bash

Auditing 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 enabled

If 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 haveged

There’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 packageName

Here’s how it goes on Ubuntu:

dpkg --list apt-get remove packageName

It’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.