Gang på gang, efter at have gennemført en revision, som svar på mine anbefalinger om at skjule havnene bag en hvidliste, bliver jeg mødt af en mur af misforståelser. Selv meget seje administratorer/DevOps spørger: "Hvorfor?!?"
Jeg foreslår at overveje risici i faldende rækkefølge efter sandsynlighed for hændelse og skade.
- Konfigurationsfejl
- DDoS over IP
- råstyrke
- Tjenestesårbarheder
- Kernel stack sårbarheder
- Øget DDoS-angreb
Konfigurationsfejl
Den mest typiske og farligste situation. Hvordan det sker. Udvikleren skal hurtigt teste hypotesen; han sætter en midlertidig server op med mysql/redis/mongodb/elastic. Adgangskoden er selvfølgelig kompleks, han bruger den overalt. Det åbner tjenesten for verden - det er praktisk for ham at oprette forbindelse fra sin pc uden disse dine VPN'er. Og jeg er for doven til at huske iptables-syntaksen; serveren er alligevel midlertidig. Et par dage mere med udvikling - det blev fantastisk, vi kan vise det til kunden. Kunden kan lide det, der er ingen tid til at lave det om, vi lancerer det i PROD!
Et eksempel, der bevidst er overdrevet for at gå gennem hele raken:
- Der er ikke noget mere permanent end midlertidigt - jeg kan ikke lide denne sætning, men ifølge subjektive følelser forbliver 20-40% af sådanne midlertidige servere i lang tid.
- En kompleks universel adgangskode, der bruges i mange tjenester, er ond. Fordi en af de tjenester, hvor denne adgangskode blev brugt, kunne være blevet hacket. På den ene eller anden måde flokkes databaserne over hackede tjenester til en, som bruges til [brute force]*.
Det er værd at tilføje, at efter installationen er redis, mongodb og elastic generelt tilgængelige uden autentificering og ofte genopfyldes . - Det kan se ud til, at ingen vil scanne din 3306-port om et par dage. Det er en vrangforestilling! Masscan er en fremragende scanner og kan scanne ved 10M porte i sekundet. Og der er kun 4 milliarder IPv4 på internettet. Derfor er alle 3306 porte på internettet placeret på 7 minutter. Charles!!! Syv minutter!
"Hvem har brug for dette?" - du protesterer. Så jeg bliver overrasket, når jeg ser på statistikken over tabte pakker. Hvor kommer 40 scanningsforsøg fra 3 unikke IP'er fra om dagen? Nu scanner alle, fra mors hackere til regeringer. Det er meget nemt at tjekke - tag en hvilken som helst VPS for $3-5 fra ethvert ** lavprisflyselskab, aktivér logning af tabte pakker og se på loggen på en dag.
Aktiverer logning
I /etc/iptables/rules.v4 tilføjes i slutningen:
-A INPUT -j LOG --log-præfiks "[FW - ALLE] " --log-niveau 4
Og i /etc/rsyslog.d/10-iptables.conf
:msg,contains,"[FW - "/var/log/iptables.log
& hold op
DDoS over IP
Hvis en angriber kender din IP, kan han kapre din server i flere timer eller dage. Ikke alle lavpris-hostingudbydere har DDoS-beskyttelse, og din server vil simpelthen blive afbrudt fra netværket. Hvis du gemte din server bag et CDN, så glem ikke at ændre IP'en, ellers vil en hacker google det og DDoS din server omgå CDN'et (en meget populær fejltagelse).
Tjenestesårbarheder
Al populær software finder før eller siden fejl, selv de mest testede og kritiske. Blandt IB-specialister er der en halv joke - sikkerheden af infrastrukturen kan sikkert vurderes på tidspunktet for den sidste opdatering. Hvis din infrastruktur er rig på havne, der stikker ud i verden, og du ikke har opdateret den i et år, så vil enhver sikkerhedsspecialist fortælle dig uden at se, at du er utæt og højst sandsynligt allerede er blevet hacket.
Det er også værd at nævne, at alle kendte sårbarheder engang var ukendte. Forestil dig en hacker, der fandt sådan en sårbarhed og scannede hele internettet på 7 minutter for dets tilstedeværelse... Her er en ny virusepidemi) Vi skal opdatere, men det kan skade produktet, siger du. Og du vil have ret, hvis pakkerne ikke er installeret fra de officielle OS-lagre. Erfaringsmæssigt bryder opdateringer fra det officielle lager sjældent produktet.
råstyrke
Som beskrevet ovenfor er der en database med en halv milliard adgangskoder, som er praktiske at skrive fra tastaturet. Med andre ord, hvis du ikke genererede en adgangskode, men skrev tilstødende symboler på tastaturet, kan du være sikker på*, at de vil forvirre dig.
Kernel stack sårbarheder.
Det sker også ****, at det ikke engang er lige meget, hvilken tjeneste der åbner porten, når selve kernenetværksstakken er sårbar. Det vil sige, at absolut enhver tcp/udp-socket på et to år gammelt system er modtagelig for en sårbarhed, der fører til DDoS.
Øget DDoS-angreb
Det vil ikke forårsage nogen direkte skade, men det kan tilstoppe din kanal, øge belastningen på systemet, din IP ender på en sortliste*****, og du vil modtage misbrug fra hosteren.
Har du virkelig brug for alle disse risici? Tilføj din hjemme- og arbejds-IP til hvidlisten. Selvom det er dynamisk, skal du logge ind via hosterens adminpanel, gennem webkonsollen og blot tilføje endnu en.
Jeg har bygget og beskyttet IT-infrastruktur i 15 år. Jeg har udviklet en regel, som jeg stærkt anbefaler til alle - ingen havn bør stikke ud i verden uden en hvidliste.
For eksempel er den mest sikre webserver*** den, der kun åbner 80 og 443 for CDN/WAF. Og serviceporte (ssh, netdata, bacula, phpmyadmin) burde være mindst bag hvidlisten og endnu bedre bag VPN. Ellers risikerer du at blive kompromitteret.
Det var alt, jeg ville sige. Hold dine havne lukket!
- (1) UPD1: du kan tjekke din seje universelle adgangskode (gør ikke dette uden at erstatte denne adgangskode med en tilfældig i alle tjenester), om det dukkede op i den flettede database. du kan se, hvor mange tjenester der blev hacket, hvor din e-mail var inkluderet, og følgelig finde ud af, om din seje universelle adgangskode er blevet kompromitteret.
- (2) Til Amazons kredit har LightSail minimale scanninger. Tilsyneladende filtrerer de det på en eller anden måde.
- (3) En endnu mere sikker webserver er den, der står bag en dedikeret firewall, sin egen WAF, men vi taler om offentlig VPS/Dedikeret.
- (4) Segmentmak.
- (5) Firehol.
Kun registrerede brugere kan deltage i undersøgelsen. , Vær venlig.
Stikker dine porte ud?
-
Altid
-
Undertiden
-
Aldrig
-
Jeg ved det ikke, fanden
54 brugere stemte. 6 brugere undlod at stemme.
Kilde: www.habr.com