Gang på gang, etter å ha gjennomført en revisjon, som svar på mine anbefalinger om å skjule havnene bak en hvitliste, blir jeg møtt med en vegg av misforståelser. Selv veldig kule admins/DevOps spør: "Hvorfor?!?"
Jeg foreslår å vurdere risiko i synkende rekkefølge etter sannsynlighet for forekomst og skade.
- Konfigurasjonsfeil
- DDoS over IP
- Ren styrke
- Tjenestesårbarheter
- Sårbarheter i kjernestabelen
- Økte DDoS-angrep
Konfigurasjonsfeil
Den mest typiske og farligste situasjonen. Hvordan det skjer. Utvikleren må raskt teste hypotesen; han setter opp en midlertidig server med mysql/redis/mongodb/elastic. Passordet er selvfølgelig komplekst, han bruker det overalt. Det åpner tjenesten for verden - det er praktisk for ham å koble til fra PC-en sin uten disse VPN-ene dine. Og jeg er for lat til å huske iptables-syntaksen; serveren er uansett midlertidig. Et par dager til med utvikling - det ble flott, vi kan vise det til kunden. Kunden liker det, det er ikke tid til å gjøre det om, vi lanserer det i PROD!
Et eksempel bevisst overdrevet for å gå gjennom hele raken:
- Det er ingenting mer permanent enn midlertidig - jeg liker ikke denne setningen, men i henhold til subjektive følelser forblir 20-40% av slike midlertidige servere i lang tid.
- Et komplekst universelt passord som brukes i mange tjenester er ondt. Fordi en av tjenestene der dette passordet ble brukt kan ha blitt hacket. På en eller annen måte strømmer databasene med hackede tjenester til en, som brukes til [brute force]*.
Det er verdt å legge til at etter installasjon er redis, mongodb og elastic generelt tilgjengelig uten autentisering, og etterfylles ofte . - Det kan se ut til at ingen vil skanne 3306-porten din i løpet av et par dager. Det er en vrangforestilling! Masscan er en utmerket skanner og kan skanne med 10M porter per sekund. Og det er bare 4 milliarder IPv4 på Internett. Følgelig er alle 3306 porter på Internett plassert på 7 minutter. Charles!!! Sju minutter!
"Hvem trenger dette?" - du protesterer. Så jeg blir overrasket når jeg ser på statistikken over droppede pakker. Hvor kommer 40 tusen skanneforsøk fra 3 tusen unike IP-er fra per dag? Nå skanner alle, fra mammas hackere til myndigheter. Det er veldig enkelt å sjekke – ta hvilken som helst VPS for $3-5 fra et hvilket som helst** lavprisflyselskap, aktiver logging av pakker som har mistet, og se på loggen på en dag.
Aktiverer logging
I /etc/iptables/rules.v4 legg til på slutten:
-A INPUT -j LOG --log-prefiks "[FW - ALL] " --log-nivå 4
Og i /etc/rsyslog.d/10-iptables.conf
:msg,contains,"[FW - " /var/log/iptables.log
& Stoppe
DDoS over IP
Hvis en angriper kjenner IP-en din, kan han kapre serveren din i flere timer eller dager. Ikke alle lavpris-vertsleverandører har DDoS-beskyttelse og serveren din vil ganske enkelt bli koblet fra nettverket. Hvis du gjemte serveren din bak et CDN, ikke glem å endre IP, ellers vil en hacker google den og DDoS serveren din omgå CDN (en veldig populær feil).
Tjenestesårbarheter
All populær programvare finner før eller siden feil, selv de mest testede og kritiske. Blant IB-spesialister er det en halv vits - sikkerheten til infrastrukturen kan trygt vurderes ved tidspunktet for siste oppdatering. Hvis infrastrukturen din er rik på porter som stikker ut i verden, og du ikke har oppdatert den på et år, vil enhver sikkerhetsspesialist fortelle deg uten å se at du er lekk, og mest sannsynlig allerede har blitt hacket.
Det er også verdt å nevne at alle kjente sårbarheter en gang var ukjente. Se for deg en hacker som fant en slik sårbarhet og skannet hele Internett på 7 minutter for tilstedeværelse... Her er en ny virusepidemi) Vi må oppdatere, men dette kan skade produktet, sier du. Og du vil ha rett hvis pakkene ikke er installert fra de offisielle OS-lagrene. Erfaringsmessig bryter oppdateringer fra det offisielle depotet sjelden produktet.
Ren styrke
Som beskrevet ovenfor er det en database med en halv milliard passord som er praktisk å skrive fra tastaturet. Med andre ord, hvis du ikke genererte et passord, men skrev inn tilstøtende symboler på tastaturet, kan du være trygg på* at de vil forvirre deg.
Sårbarheter i kjernestabelen.
Det hender også **** at det ikke engang spiller noen rolle hvilken tjeneste som åpner porten, når selve kjernenettverksstakken er sårbar. Det vil si at absolutt enhver tcp/udp-socket på et to år gammelt system er utsatt for en sårbarhet som fører til DDoS.
Økte DDoS-angrep
Det vil ikke forårsake noen direkte skade, men det kan tette kanalen din, øke belastningen på systemet, IP-adressen din vil havne på en eller annen svarteliste*****, og du vil motta misbruk fra hosteren.
Trenger du virkelig alle disse risikoene? Legg til hjemme- og jobb-IP til hvitelisten. Selv om det er dynamisk, logg på via vertens administrasjonspanel, gjennom nettkonsollen, og legg til en til.
Jeg har bygget og beskyttet IT-infrastruktur i 15 år. Jeg har utviklet en regel som jeg sterkt anbefaler til alle - ingen havn bør stikke ut i verden uten en hvitliste.
For eksempel er den sikreste webserveren*** den som åpner 80 og 443 kun for CDN/WAF. Og tjenesteporter (ssh, netdata, bacula, phpmyadmin) bør være minst bak hvitelisten, og enda bedre bak VPN. Ellers risikerer du å bli kompromittert.
Det var alt jeg ville si. Hold portene stengt!
- (1) UPD1: du kan sjekke det kule universelle passordet ditt (ikke gjør dette uten å erstatte dette passordet med et tilfeldig i alle tjenester), om det dukket opp i den sammenslåtte databasen. du kan se hvor mange tjenester som ble hacket, hvor e-posten din ble inkludert, og følgelig finne ut om det kule universelle passordet ditt har blitt kompromittert.
- (2) Til Amazons kreditt har LightSail minimale skanninger. Tilsynelatende filtrerer de det på en eller annen måte.
- (3) En enda sikrere webserver er den bak en dedikert brannmur, sin egen WAF, men vi snakker om offentlig VPS/Dedikert.
- (4) Segmentmak.
- (5) Firehol.
Kun registrerte brukere kan delta i undersøkelsen. , vær så snill.
Stikker portene dine ut?
-
alltid
-
Noen ganger
-
Aldri
-
Jeg vet ikke, faen
54 brukere stemte. 6 brukere avsto.
Kilde: www.habr.com