Vraag Is het normaal om honderden inbreekpogingen per dag te krijgen?


Ik heb net mijn server gecontroleerd /var/log/auth.log en ontdekte dat ik meer dan 500 mislukte aanmeldingsmeldingen per wachtwoord / inbraak krijg per dag! Mijn site is klein en de URL is onduidelijk. Is dit normaal? Moet ik maatregelen nemen?


196
2018-03-08 11:26


oorsprong


Totdat we alle overbodige externe poorten hadden afgesloten, herinner ik me dat we niet alleen veel hackpogingen kregen, maar op een dag was het zo erg dat we werden gehackt uit twee verschillende landen - op hetzelfde moment! Dus ja, 100s inbraakpogingen is volkomen normaal. - Django Reinhardt
We hebben servers die eens in de 16 seconden een nieuwe "reeks" aanvallen vertonen. Een enkele reeks is meestal een batch van ongeveer 100 pogingen in verschillende poorten. Alleen voor de kicks op een dag schakelde ik een niet-gepatchte server buiten onze firewall in; het duurde minder dan 10 minuten vanaf het moment dat het werd ingeschakeld om Pwnd te krijgen. Punt is dat internet echt een jungle is; probeer niet gegeten te worden. - NotMe
Ik kan zien dat ik mijn vraag op de verkeerde site heb geplaatst: superuser.com/questions/200896/... - Justin C
terwijl ik het met anderen eens ben, is dit normaal op gangbare poorten vereist (80, 443). Ik heb deze pogingen tegen mijn SSH-poort praktisch geëlimineerd door simpelweg de standaardpoort van 22 te veranderen in iets obscuurs zoals 6022 bijvoorbeeld. Alleen al dat te doen, elimineerde bijna 99% van dat soort aanvallen. - Kilo
Als u uw SSH-poort gaat wijzigen, zijn er veiligheidsredenen om deze onder poort 1024 te houden (alleen root kan poorten <1024 openen, dus het beschermt u tegen andere gebruikers die SSH kapen). - Brendan Long


antwoorden:


In het internet van vandaag is dit helaas heel normaal. Er zijn hordes botnets die proberen in te loggen op elke server die ze in hele IP-netwerken vinden. Meestal gebruiken ze eenvoudige woordenboekaanvallen op bekende accounts (zoals root- of bepaalde applicaties-accounts).

De aanvalsdoelen worden niet gevonden via Google- of DNS-vermeldingen, maar de aanvallers proberen gewoon elk IP-adres in een bepaald subnet (bijvoorbeeld van bekende root-serverhostingbedrijven). Het maakt dus niet uit dat uw URL (vandaar de DNS-invoer) nogal obscuur is.

Dat is waarom het zo belangrijk is om:

  • onbruikbaar maken van root-login in SSH (hoe)
  • gebruik overal sterke wachtwoorden (ook in uw webapps)
  • voor SSH, gebruik openbare-sleutelauthenticatie indien mogelijk en schakel wachtwoord-auth volledig uit (hoe)

Bovendien kunt u installeren fail2ban die de authlog zal scannen en als het een bepaald aantal mislukte inlogpogingen van een IP vindt, zal het doorgaan met het toevoegen van dat IP aan /etc/hosts.deny of iptables / netfilter om de aanvaller een paar minuten te blokkeren.

Naast de SSH-aanvallen, wordt het ook gebruikelijk om uw webserver te scannen op kwetsbare web-applicaties (sommige blog-apps, CMS's, phpmyadmin, etc.). Dus houd die up-to-date en veilig geconfigureerd!


207
2018-03-08 11:35



Toepassingen zoals fail2ban kunnen veel helpen om 'tijdelijk' te voorkomen dat die bots op gekke momenten 's ochtends je server raken :-) Ik heb de mijne ingesteld om 3 keer per ongeluk 24 uur lang te verbieden. - emtunc
En verplaats ssh's poort van 22 naar 222. Dat werkt best goed. - Tom O'Connor
+1, alleen openbare-sleutelverificatie :) - 0xC0000022L
@STATUS_ACCESS_DENIED: de acties die fail2ban neemt zijn slechts lijsten met shell-opdrachten die moeten worden uitgevoerd. Het is dus echt flexibel en gemakkelijk om naar behoren te werken met elke aangepaste configuratie. De beste referentie is om het te downloaden en te bekijken action.d/iptables.conf. - mattdm
Het blokkeren van aanvallers als dit is tijdverspilling. Als je rootaanmelding uitschakelt, is de kans groot dat niemand je juiste inlognaam, laat staan ​​wachtwoord, ooit zal raden. SSH zelf is al snelheidsvereisten voor wachtwoorden, dus zelfs als ze je gebruikersnaam kennen (willekeurige bots niet), als ze een goed wachtwoord hebben, zullen ze het nooit raden. - Brendan Long


Een paar honderd is prima ... Vorige maand ontdekte ik dat een van mijn servers 40k mislukte pogingen had. Ik ging door de moeite om ze te plotten: Kaart

Nadat ik de ssh-poort had gewijzigd en Port Knocking had geïmplementeerd, zakte het nummer naar 0 :-)


58
2018-03-08 11:36



Mooie kaart. Ik zou graag willen weten hoe dit te doen! - jftuga
@jftuga Ik heb eerst alle IP's uit de logs gehaald. grep 'Failed password' /var/log/secure* | grep sshd | grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' | sort | uniq(verwijder de | uniq aan het einde als u duplicaten wilt toestaan). U kunt ze vervolgens in een CSV plaatsen en uploaden naar zeemaps.com. Ik heb betere kaarten dan de mijne gezien, waar ze de telling zouden gebruiken om de kaart te kleuren (groen naar rood voor het aantal pogingen per graafschap) maar ik heb geen jet bedacht die uit - Bart De Vos
Wat bedoel je met 'geïmplementeerde poortkloppen'? Is er een app die ik kan installeren via apt-get om dit te doen? Het nummer dat naar 0 valt, klinkt prettig
Beveiliging door middel van obscuriteit krijgt een slechte omslag. Het is prima zolang het is een deel van de algemene strategie in plaats van de hele strategie. Wat is tenslotte nog een ander wachtwoord dan een obscure string? - Joel Coel
@Joel Coel, het is a geheim string, in tegenstelling tot de meeste beveiliging door obscuriteitsproblemen - een obscuur, maar niet noodzakelijkerwijs geheim proces. - tobyodavies


Ik gebruik voor een gebruik een "tarpit" naast het alleen toestaan ​​van public key-authenticatie en het niet toestaan ​​van root-aanmeldingen.

In netfilter er is een recent module, waarmee u kunt gebruiken (INPUT keten):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

Wat dat wel doet, is dat elke poging om verbinding te maken met poort 22 wordt vermeld door de recent module met IP en wat andere dingen onder de naam "tarpit" (als je nieuwsgierig bent, kijk naar /proc/net/xt_recent/tarpit). Vanzelfsprekend kunt u andere namen gebruiken.

Gebruik IP-adressen om IP-adressen weer te geven of te verwijderen:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

Dit percentage beperkt de pogingen tot 5 in 300 seconden. Houd er rekening mee dat gebruikers met een bestaande verbinding geen hinder ondervinden van die limiet, omdat ze al een bestaande verbinding hebben en meer mogen maken (zelfs boven de snelheidslimiet).

Pas de regels naar wens aan maar zorg ervoor dat ze in die volgorde worden toegevoegd (bijv. Bij het toevoegen en gebruik ze dan in deze volgorde, bij het invoegen en vervolgens in de omgekeerde volgorde).

Dit vermindert het geluid enorm. Het biedt ook daadwerkelijke beveiliging (tegen brute dwingen) in tegenstelling tot de waargenomen veiligheid van het veranderen van de poort. Ik zou echter nog steeds aanraden om de poort te wijzigen als dit haalbaar is in uw omgeving. Het zal ook het geluidsniveau aanzienlijk verminderen ...

Je kunt dit nog steeds combineren met fail2ban, hoewel ik het prima heb gedaan zonder het en alleen de bovenstaande regels.

BEWERK:

Het is mogelijk om jezelf hiertoe te vergrendelen, dus je kunt iets toevoegen als het volgende waarmee je je ban kunt wissen door op een bepaalde poort te kloppen:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove

29
2018-03-08 14:24



Ik gebruik dit en kan mezelf af en toe blokkeren, dus ik wil graag een andere poort instellen waarop je kunt "kloppen" om je verbod te wissen. - benlumley
@benlumley: goed punt. Poort kloppen kan op dezelfde manier nuttig zijn om de standaard poort te veranderen - of zelfs beide in combinatie ... - 0xC0000022L
@benlumley: zag je reactie (nu verwijderd door Sam). Ik vind het absoluut niet erg als het antwoord wordt bewerkt / verbeterd;) - 0xC0000022L


Je zou kunnen implementeren fail2banof vergelijkbare methoden, zoals SSH vergrendelen op uw IP. Jammer genoeg proberen bots de hele tijd toegang te krijgen tot brutoforce, dus het is heel normaal, je moet ervoor zorgen dat je een goed wachtwoord hebt.


15
2018-03-08 11:32



Als u SSH gebruikt, overweeg dan de openbare sleutelverificatie. Dit is een beetje veiliger dan wachtwoordverificatie. - Piskvor


Ja. Het is tegenwoordig heel normaal.

Gebruik zo mogelijk alleen verificatie met openbare sleutels voor administratieve doeleinden. Genereer een privésleutel op uw werkstation:

$ ssh-keygen -t dsa

Copypaste de inhoud van ~ / .Ssh / id_dsa.pub voor je servers ~ / .Ssh / authorized_keys (en /root/.ssh/authorized_keys, als u een directe root-login nodig hebt).

Configureer uw servers / Etc / ssh / sshd_config om alleen openbare sleutelauthenticatie te accepteren:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

Als u te veel servers heeft, kunt u gebruiken Marionet om publieke sleutels en configuraties naar ze uit te voeren.

Naar kijken Denyhosts en fail2ban om herhaalde SSH-inlogpogingen te blokkeren en te zien snuiven als u volledige IDS / IPS nodig hebt.


12
2018-03-09 23:32



Ik zou het gebruik van publieke-sleutelauthenticatie in SSH niet aanbevelen voor shell-toegang tot uw server. Als uw werkstation is gecompromitteerd of, nog erger gestolen, heeft iemand nu open toegang tot uw servers zonder een wachtwoord nodig te hebben. Publieke sleutelauthenticatie is meer voor situaties waar u iets als een script of programma nodig hebt om SSH-toegang tot een ander systeem te hebben zonder een wachtwoord nodig te hebben, zodat u geen wachtwoord voor platte tekst in uw script / programma hoeft in te bedden. - Registered User
@Afgedeelde account: u kunt een wachtwoordzin instellen voor de privésleutel van SSH. - Phil Cohen
De opmerking "Geregistreerde gebruiker" is misplaatst. Ter verduidelijking: stel altijd een goed wachtwoord in op uw persoonlijke sleutel en bewaar de privésleutel niet op servers. Bewaar de privésleutel op uw eigen werkstation. Nadat u de sleutel aan een ssh-agentprogramma hebt toegevoegd en uw wachtwoord hebt ingevoerd, kunt u inloggen op elk systeem waarop de openbare sleutel is geïnstalleerd, zonder dat u uw wachtwoord opnieuw hoeft in te voeren. Schakel agent-doorsturen in uw ssh-client in zodat u zich kunt aanmelden van server naar server. Het is slecht om je privésleutel te stelen, maar met een behoorlijk wachtwoord erop is het niet zo erg als een gestolen wachtwoord. - Martijn Heemels
Juist, denk er niet aan om de privésleutels van beheerders onversleuteld op te slaan. - yarek


gebruik http://denyhosts.sourceforge.net/

en ja, je zou public-key authenticatie moeten gebruiken en wachtwoordverificatie moeten uitschakelen.


8
2018-03-09 09:37



Het uitschakelen van wachtwoordauthentic is niet altijd een haalbare oplossing. - Publiccert


De pogingen zijn gemechaniseerd, dus de cijfers lijken OK (ja, ze zijn hoog in vergelijking met sommige sites en de lage in vergelijking met andere). Je moet de volgende stappen nemen: Je beschouwt je sites elke dag als aanvalsdoelen, zelfs als je geen aanval detecteert; geen aanval detecteren, wil nog niet zeggen dat het niet bestaat.


6
2018-03-08 11:33





Ik zou zeggen dat slechts 500 is een beetje laag.

Bij een vorige werkgever noemde een van de computerbeveiligingsonderzoekers de constante stroom inbraakpogingen het "internetequivalent van kosmisch geluidHij beschreef het als een normale, continue stroom van kwaadaardig verkeer dat op zoek was naar systemen op het internet en automatisch scripts misbruikte om te proberen het systeem te kapen. "Bot-netten en andere kwaadwillende systemen zouden het internet voortdurend scannen en opnieuw scannen op kwetsbare systemen net zoals SETI.


6
2018-03-08 17:06





Ja,

dit is gebruikelijk, maar dat betekent niet dat je het goede gevecht niet moet bevechten. Hier zijn enkele stappen over hoe u uw server veiliger kunt maken.

Vermijd DNS-geassocieerde IP-adressen

U kunt dit aantal sterk verminderen in gedeelde of colocatie-omgevingen door SSH-toegang uit te schakelen op IP-adressen die zijn gekoppeld aan domeinnamen. Niet-vermelde niet-domein IP-adressen ontvangen minder van dit soort verkeer, dus koop een niet-vermeld IP-adres en gebruik dit IP-adres alleen voor SSH-toegang.

Gebruik een VPN voor alle SSH-toegang

Als u zich in een omgeving bevindt waarin u kunt implementeren IPsec/ VPN naar een privaat netwerk binnen uw serveromgeving, dit is ideaal. Schakel alle SSH-internettoegang uit, zorg ervoor dat u een geïntegreerde lichtoplossing hebt. Stel uw VPN in, en sta alleen SSH-toegang toe vanaf uw VPN.

Implementeer IP-adresregels voor SSH-toegang

Als het VLAN geen optie is, configureert u uw router of firewallregels om alleen SSH-verbindingen toe te staan ​​van een bekend IP-adresbereik.

Als u deze stappen volgt, zult u 's nachts veel gemakkelijker slapen, wetende dat iemand uw hostingbedrijfennetwerk moet compromitteren om via SSH toegang te krijgen tot de server.


6
2018-03-08 21:56





Vrij normaal om honderden mislukte SSH-verbindingen te zien.

Als u de optie hebt, verander ik eenvoudig mijn haven SSH in iets niet-standaard. Het maakt je server niet noodzakelijk veiliger, maar het ruimt zeker de logs op (en laat je zien dat iemand opzettelijk probeert in te breken!)


5
2018-03-08 11:43





Naast het gebruik van een geautomatiseerd vergrendelingsmechanisme zoals fail2ban, heeft u nog een andere optie: neem in feite contact op met het misbruikadres ISP van de aanvaller. Het lijkt misschien volkomen nutteloos, maar in het geval van de scriptkiddie is hun ISP meer dan bereid om actie tegen hen te ondernemen.

Begin met om het misbruikadres te vinden arin.net en zoek het IP-adres op met whois. Mogelijk wordt u doorgestuurd naar een ander regionaal register, maar uiteindelijk kunt u de verantwoordelijke ISP vinden voor het IP-blok met het adres. Zoek naar het abuse @ -adres of mail het technische contact.

Stuur ze een beleefd bericht met de relevante logboekitems (verwijder alle persoonlijke gegevens) en vraag hen actie te ondernemen tegen de overtredende host.


5
2018-03-08 18:20



Vroeger deden we dit. De hoeveelheid tijd die werd besteed ten opzichte van het ontvangen voordeel was echter zo klein dat het er niet toe doet. - NotMe
Een variant van deze tactiek die effectiever is, maar veel risicovoller, is om de ISP te melden bij het tussenliggende knooppunt. Maar jij MOET zorg dat uw rapportgegevens solide zijn. Ik heb een hele ISP in ernstige problemen geraakt als ik dit deed, omdat ze hun misbruikrapporten negeerden. - staticsan
Toen ik dit een keer deed, bereikte het misbruikbericht de hacker in plaats van iemand die de servers beheerde. Sindsdien heb ik geen moeite meer, gewoon teveel moeite. - wump
Dit gaat echt niet helpen in de meeste gevallen en kan tijdrovend zijn - RichVel