Kā aizsargāt savu Linux tīmekļa serveri

LAMP servera izveide un tā visa laba konfigurēšana ar uzticamu datu apstrādi, domēnu un TLS sertifikātu ir tikai puse cīņas. Jums arī jāpārliecinās, ka jūsu infrastruktūra ir aizsargāta pret daudzajiem biedējošajiem draudiem internetā.

Šajā rakstā, kas tika izvilkts no manas Maninga grāmatas “Linux darbībā” 9. nodaļas, es izpētīšu vietnes drošību, pareizi izmantojot sistēmas grupas, procesu izolējot un regulāri pārbaudot jūsu sistēmas resursus. Tas nav viss stāsts (mana grāmata Linux darbībā ietver papildu rīkus, piemēram, TLS sertifikātu instalēšanu un darbu ar SELinux), bet tas ir lielisks sākums.

Sistēmas grupas un vismazākās privilēģijas princips

Jūsu atbalstītie izstrādātāji (beidzot) ir sapratuši, ka viņiem ir jāierobežo publiska piekļuve lietojumprogrammu serverī esošajiem datiem un konfigurācijas failiem, vienlaikus ļaujot piekļūt dažādām izstrādātāju un IT komandām.

Risinājuma pirmā daļa ir grupas . Grupa ir sistēmas objekts - gandrīz tāds pats kā lietotājs - izņemot to, ka neviens nekad sistēmā nepierakstīsies kā grupa. Grupu spēks ir tajā, kā tās, tāpat kā lietotājus, var “piešķirt” failiem vai direktorijiem, ļaujot visiem grupas dalībniekiem dalīties grupas pilnvarās. Tas ir parādīts attēlā.

Izmēģiniet pats: izmantojiet teksta redaktoru, lai izveidotu jaunu failu. Pievienojiet tekstu “Sveika pasaule”, lai jūs varētu viegli pateikt, kad varat tam veiksmīgi piekļūt. Tagad rediģējiet tā atļaujas, izmantojot chmod 770, lai faila īpašniekam un grupai būtu pilnas tiesības uz failu, bet citi to pat nevarētu lasīt.

nano datafile.txt chmod 770 datafile.txt

Ja jūsu sistēmā bez jūsu konta vēl nav papildu lietotāja, izveidojiet to, izmantojot nu adduser - Debian / Ubuntu veidu - vai useradd, ja izmantojat CentOS. useradd darbosies arī Ubuntu.

Komanda useradd (atšķirībā no Debian adduser) jums to prasa

ģenerēt lietotāja paroli atsevišķi:

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

Izmantojiet su, lai pārslēgtos uz jauno lietotāju. Kad esat ievadījis lietotāja paroli, visas izpildītās komandas tiks izpildītas kā šis lietotājs. Jūs strādāsit tikai ar šī lietotāja autoritāti: ne vairāk, ne mazāk. Ja mēģināt izlasīt failu datafile.txt (izmantojot kaķi), jums nepaveiksies, jo, kā jūs atceraties, citiem tika liegta lasīšanas atļauja. Kad esat pabeidzis, ierakstiet exit, lai atstātu jauno lietotāja apvalku un atgrieztos pie sākotnējā apvalka.

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

Tas viss ir sagaidāms un viegli saprotams. Un, kā jūs redzējāt, dažreiz var būt problēma, ja nevarat lasīt citam lasītājam piederošo failu. Apskatīsim, ko mēs varam darīt, saistot failu ar grupu un pēc tam pareizi konfigurējot faila atļaujas.

Izveidojiet jaunu grupu, kuru varat izmantot lietojumprogrammas datu pārvaldīšanai, un pēc tam rediģējiet datu faila rekvizītus, izmantojot chown. Arguments ubuntu: app-data-group atstāj faila īpašumtiesības ubuntu lietotāja rokās, bet maina tā grupu uz jūsu jauno app-data-group.

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

Palaidiet ls ar “long” izvadi pret failu, lai skatītu tā jaunās atļaujas un statusu. Ņemiet vērā, ka, kā paredzēts, faila īpašnieks ir ubuntu un tā grupa ir app-data-group.

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

Varat izmantot usermod, lai pievienotu lietotāju lietotņu datu grupas grupai, un pēc tam vēlreiz - su, lai pārslēgtos uz čaulu, kurā tiek izvietots otra lietotāja konts. Šoreiz, pat ja faila atļaujas bloķē citus - un jūs šobrīd noteikti rīkojaties kā “cits” lietotājs, jums vajadzētu būt iespējai to izlasīt, pateicoties dalībai grupā.

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

Izmantojiet su, lai pārslēgtos starp lietotāju kontiem. Tas bija mana faila datafile.txt saturs. Šāda veida organizācija ir pareizs un efektīvs veids, kā risināt daudzus sarežģītos atļauju jautājumus, kas radīsies daudzlietotāju sistēmā.

Patiesībā tas tiek izmantots ne tikai individuālajiem lietotājiem vajadzīgās piekļuves nodrošināšanai, bet daudzi sistēmas procesi nevarētu paveikt savu darbu bez īpašas dalības grupā. Ātri apskatiet failu / etc / group un atzīmējiet, cik sistēmas procesiem ir savas grupas.

Daļējs / etc / group faila satura uzskaitījums:

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

Procesu izolēšana konteineros

Vai esat noraizējies par to, ka vairāki serveri, kurus izmantojat vienā serverī, vai visi pakalpojumi ir pakļauti riskam? Viens no veidiem, kā ierobežot neuzmanīgu vai ļaunprātīgu lietotāju nodarītos zaudējumus, ir sistēmas resursu un procesu izolēšana. Tādā veidā, pat ja kāds varētu vēlēties paplašināt sasniedzamību ārpus noteiktā limita, viņam nebūs fiziskas piekļuves.

Vecā pieeja problēmai bija nodrošināt atsevišķu fizisku mašīnu katram pakalpojumam. Bet virtualizācija to var padarīt daudz vienkāršāku un pieejamāku - izveidot “noslāpētu” infrastruktūru.

Šo arhitektūru bieži dēvē par mikropakalpojumiem, un, ja jūs palaižat vairākus konteinerus, iespējams, vienā darbinot tikai datu bāzi, citā Apache un trešajā ir multivides faili, kas, iespējams, ir iegulti jūsu tīmekļa lapās. Papildus daudzajiem veiktspējas un efektivitātes ieguvumiem, kas saistīti ar mikropakalpojumu arhitektūrām, tas var ievērojami samazināt katra atsevišķa komponenta risku.

Ar “konteineriem” es ne vienmēr domāju tos, kas pārliecināti par LXC.

Šajās dienās šāda veida izvietošanai Docker konteineri ir daudz vairāk

populārs. Ja jūs vēlaties uzzināt vairāk par Docker, skatiet manus Pluralsight kursus, kas skar šo tēmu.

Tiek meklētas bīstamas User ID vērtības

Kaut arī jebkurš administratora lietotājs varēs īslaicīgi uzņemties root autoritāti, izmantojot sudo, tikai root ir faktiski root. Kā jūs jau redzējāt, nav droši veikt regulāras funkcijas kā root. Bet var notikt - vai nu nevainīgu nelaimes gadījumu, vai ļaunprātīgas manipulācijas dēļ - parasts lietotājs var efektīvi iegūt administratora tiesības uz pilnu slodzi.

Labā ziņa ir tā, ka viltvārdus ir viegli pamanīt: viņu lietotāju un / vai grupas ID numuri, tāpat kā saknes, būs nulle (0). Apskatiet failu passwd mapē / etc /. Šajā failā ir ieraksts par katru pašreiz pastāvošo parasto un sistēmas lietotāja kontu. Pirmajā laukā ir konta nosaukums (šajā gadījumā sakne un ubuntu), un otrajā laukā paroles vietā var būt x (kas, ja tāds pastāv, parādīsies šifrēts failā / etc / shadow). Bet nākamajos divos laukos ir lietotāja un grupas ID. Šajā piemērā esošā ubuntu gadījumā abi ID ir 1000. Un, kā redzat, saknei ir nulle.

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

Šis raksts ir izvilkts no manas Maninga grāmatas “Linux darbībā” . Tur ir daudz vairāk jautrības , kad tas nāca no , ieskaitot hibrīdu kursu sauc Linux kustībā , kas ir sastāv no vairāk nekā divu stundu video un aptuveni 40% no teksta Linux darbībā. Kas zina ... Jūs varētu baudīt arī manu nesen publicēto Mācieties Amazon tīmekļa pakalpojumus pusdienu mēnesī .