Vraag "MOGELIJKE INBREUK!" In / var / log / secure - wat betekent dit?


Ik heb een CentOS 5.x-box op een VPS-platform. Mijn VPS-host heeft een ondersteuningsverzoek dat ik had over de connectiviteit verkeerd geïnterpreteerd en effectief enkele iptables-regels doorgespoeld. Dit resulteerde in ssh luisteren op de standaardpoort en het bevestigen van poortconnectiviteitstests. Vervelend.

Het goede nieuws is dat ik SSH geautoriseerde sleutels nodig heb. Voor zover ik weet, denk ik niet dat er sprake is geweest van een succesvolle inbreuk. Ik ben nog steeds erg bezorgd over wat ik zie in / var / log / secure:


Apr 10 06:39:27 echo sshd[22297]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:27 echo sshd[22298]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:31 echo sshd[22324]: Invalid user edu1 from 222.237.78.139
Apr 10 06:39:31 echo sshd[22324]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:31 echo sshd[22330]: input_userauth_request: invalid user edu1
Apr 10 13:39:31 echo sshd[22330]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:35 echo sshd[22336]: Invalid user test1 from 222.237.78.139
Apr 10 06:39:35 echo sshd[22336]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:35 echo sshd[22338]: input_userauth_request: invalid user test1
Apr 10 13:39:35 echo sshd[22338]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:39 echo sshd[22377]: Invalid user test from 222.237.78.139
Apr 10 06:39:39 echo sshd[22377]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:39 echo sshd[22378]: input_userauth_request: invalid user test
Apr 10 13:39:39 echo sshd[22378]: Received disconnect from 222.237.78.139: 11: Bye Bye

Wat betekent "MOGELIJKE INBEGRIPPoging" precies? Dat het succesvol was? Of dat het niet leuk vond dat het IP-adres van het verzoek afkomstig was?


86
2018-04-17 18:17


oorsprong




antwoorden:


Helaas is dit nu een veel voorkomend verschijnsel. Het is een geautomatiseerde aanval op SSH die 'gewone' gebruikersnamen gebruikt om te proberen in te breken in uw systeem. Het bericht betekent precies wat het zegt, het betekent niet dat je bent gehackt, alleen dat iemand het probeerde.


75
2018-04-17 22:06



Bedankt Lain. Dat geeft me een beter gevoel. Ik ben echt blij dat ik geautoriseerde sleutels nodig heb voor ssh. =) - Mike B
"reverse mapping checking getaddrinfo for" gaat meer over source IP / hostname gemaakt. Hetzelfde aangemaakte verkeer probeert slechte gebruikersnamen, maar slechte gebruikersnamen genereren niet het bericht 'MOGELIJKE INBREUK'. - poisonbit
@MikeyB: misschien wilt u naar toevoegen kijken fail2ban voor jou systeem. Dit kan worden geconfigureerd om de IP-adressen van deze aanvallers automatisch te blokkeren. - Iain
@poisonbit: rechts, dit betekent dat er een omgekeerde opzoekactie is die vervolgens niet op zijn beurt tot een A-record leidt, maar in de ronde maakt het allemaal deel uit van dezelfde geautomatiseerde aanval. - Iain
Merk op dat 'reverse mapping failed' kan betekenen dat de internetprovider van de gebruiker reverse DNS niet correct heeft geconfigureerd, wat vrij gebruikelijk is. Zie @Gaia's antwoord. - Wilfred Hughes


Het deel "MOGELIJKE INBREUK" specifiek, is gerelateerd aan het deel "omgekeerde toewijzing controle getaddrinfo". Het betekent dat de persoon die verbinding maakte, geen forward en reverse DNS correct had geconfigureerd. Dit is vrij gebruikelijk, vooral voor ISP-verbindingen, waar de "aanval" waarschijnlijk vandaan kwam.

Los van het bericht "MOGELIJKE INBRAAK", probeert de persoon daadwerkelijk in te breken met behulp van algemene gebruikersnamen en wachtwoorden. Gebruik geen eenvoudige wachtwoorden voor SSH; in feite het beste idee om wachtwoorden helemaal uit te schakelen en alleen SSH-sleutels te gebruiken.


49
2017-10-23 20:16



Als het wordt gegenereerd door een (geldige) verbinding via een internetprovider, kunt u een vermelding toevoegen aan uw bestand / etc / hosts om van deze fout met omgekeerde toewijzing af te komen. Vanzelfsprekend zou je dit alleen doen als je wist dat de fout goedaardig is en je je logs wilt opruimen. - artfulrobot


"Wat betekent" MOGELIJKE INBEGRIPPoging "precies?"

Dit betekent dat de eigenaar van het netblok de PTR-record voor een statische IP binnen zijn bereik niet heeft bijgewerkt en dat de PTR-record verouderd is, OF een ISP stelt geen juiste reverse records in voor zijn dynamische IP-klanten. Dit is heel gebruikelijk, zelfs voor grote ISP's.

Je krijgt uiteindelijk de msg in je logboek omdat iemand die afkomstig is van een IP met onjuiste PTR-records (vanwege een van de bovenstaande redenen) algemene gebruikersnamen probeert te gebruiken om SSH in je server te proberen (mogelijk bruteforce-aanval of misschien een eerlijke fout ).

Als u deze meldingen wilt uitschakelen, heeft u twee keuzes:

1) Als u een statisch IP-adres hebt, voeg uw reverse mapping toe aan uw / etc / hosts-bestand (zie meer info hier):

10.10.10.10 server.remotehost.com

2) Als u een dynamisch IP-adres hebt en echt willen dat die waarschuwingen verdwijnen, commentaar geven op de "GSSAPIAuthentication yes" in je bestand / etc / ssh / sshd_config.


30
2018-01-12 10:33



commentaar GSSAPIAuthentication helpt niet in mijn geval ( - SET


U kunt uw logs gemakkelijker lezen en controleren reverse lookp-ups uitschakelen in sshd_config (UseDNS nee). Dit voorkomt dat sshd de "ruis" -regels registreert die "MOGELIJKE BREAK-IN POGING" bevatten, waardoor je je kunt concentreren op de iets meer interessante regels die "Ongeldige gebruiker USER uit IPADDRESS" bevatten.


13
2018-04-17 18:23



Wat is het nadeel van het uitschakelen van sshd reverse lookups op een server die verbonden is met het openbare internet? Is er enig voordeel om deze optie ingeschakeld te laten? - Eddie
@ Eddie Ik denk niet dat de DNS-lookups uitgevoerd door sshd een nuttig doel dienen. Er zijn twee goede redenen om de DNS-lookups uit te schakelen. De DNS-lookups kunnen de aanmelding vertragen als de time-out van de lookups optreedt. En de "MOGELIJKE INBREUK POGING" berichten in het logboek zijn misleidend. Het enige dat echt betekent, is dat de client DNS verkeerd heeft geconfigureerd. - kasperd
@kasperd UseDNS is nodig, als men hostnamen in de. heeft / wil gebruiken from= richtlijn in authorized_keys bestanden. - gf_
Ik ben het niet eens @OlafM - "UseDNS no" vertelt sshd om de reverse mapping controle niet uit te voeren en daarom zal het geen regels toevoegen die "MOGELIJKE BREAK-IN POGING" bevatten naar de systeemlogboeken. Als neveneffect kan het ook de verbindingspogingen van hosts versnellen, of niet dat Reverse DNS correct is geconfigureerd. - TimT
Ja, ik deed het bij @OlafM ongeveer 4-5 jaar geleden onder Linux. Het verkortte mijn logs aanzienlijk en stopte logcheck mij lastig vallen met waardeloze e-mailrapporten. - TimT


Het is niet nodig om succesvol in te loggen, maar wat het zegt "posible" en "poging".

Een of andere slechte jongen of scriptkiddie stuurt je bewerkt verkeer met een valse oorsprong IP.

U kunt oorsprong-IP-beperkingen toevoegen aan uw SSH-sleutels en iets als fail2ban proberen.


5



Bedankt. Ik heb iptables ingesteld om alleen ssh-connectiviteit van geselecteerde bronnen toe te staan. Ik heb ook fail2ban geïnstalleerd en uitgevoerd. - Mike B