Security Professionals
- ipfw add deny all from eindgebruikers to any
Telnet Sessie vanuit host
Hallo allen,
Vandaag kwam ik per toeval een vreemd pakketje tegen in het dataverkeer van een Ubuntu 12 LTS server die rechtstreeks aangesloten zit op het internet (VPS).
Het gaat om:
UDP (55 Bytes) from 37.34.xx.xx:57505 to 80.115.x.x:23 on eth0.
Het IP adres (from) is dus het IP address wat mijn VPS toegewezen heeft gekregen aan de public facing ethernet port.
Deze kwam ik toevallig tegen via IPTraf toen ik bezig was met wat iptables aanpassen - dit trok mijn aandacht.
Nu draaien er (voor zover ik weet en heb geinstalleerd) geen processen die een telnet sessie met welke host dan ook opzetten.
Tevens komt het IP adres mij ook totaal niet bekend voor.
Een nmap laat zien dat enkel port 22 en port 80 op die host open staat.
Een telnet sessie naar die host wordt niet beantwoord.
Wat ik mij afvraag, kan ik achterhalen welk proces deze sessie probeert te initiaten?
Kan me niet voorstellen dat er is ingebroken op de server, maar kan me ook niet voorstellen dat een legitiem programma dit doet.
Daarbij komt dat al een lange tijd geen DNS queries de server uit mogen gaan, dus het IP adres is ook niet via DNS verkregen, m.a.w. die is ergens ingeklopt.
Iemand ideeen?
Vandaag kwam ik per toeval een vreemd pakketje tegen in het dataverkeer van een Ubuntu 12 LTS server die rechtstreeks aangesloten zit op het internet (VPS).
Het gaat om:
UDP (55 Bytes) from 37.34.xx.xx:57505 to 80.115.x.x:23 on eth0.
Het IP adres (from) is dus het IP address wat mijn VPS toegewezen heeft gekregen aan de public facing ethernet port.
Deze kwam ik toevallig tegen via IPTraf toen ik bezig was met wat iptables aanpassen - dit trok mijn aandacht.
Nu draaien er (voor zover ik weet en heb geinstalleerd) geen processen die een telnet sessie met welke host dan ook opzetten.
Tevens komt het IP adres mij ook totaal niet bekend voor.
Een nmap laat zien dat enkel port 22 en port 80 op die host open staat.
Een telnet sessie naar die host wordt niet beantwoord.
Wat ik mij afvraag, kan ik achterhalen welk proces deze sessie probeert te initiaten?
Kan me niet voorstellen dat er is ingebroken op de server, maar kan me ook niet voorstellen dat een legitiem programma dit doet.
Daarbij komt dat al een lange tijd geen DNS queries de server uit mogen gaan, dus het IP adres is ook niet via DNS verkregen, m.a.w. die is ergens ingeklopt.
Iemand ideeen?
Reacties (15)
Door Do: Telnet Sessie vanuit host
Hallo allen,
Vandaag kwam ik per toeval een vreemd pakketje tegen in het dataverkeer van een Ubuntu 12 LTS server die rechtstreeks aangesloten zit op het internet (VPS).
Het gaat om:
UDP (55 Bytes) from 37.34.xx.xx:57505 to 80.115.x.x:23 on eth0.
Het IP adres (from) is dus het IP address wat mijn VPS toegewezen heeft gekregen aan de public facing ethernet port.
Deze kwam ik toevallig tegen via IPTraf toen ik bezig was met wat iptables aanpassen - dit trok mijn aandacht.
Nu draaien er (voor zover ik weet en heb geinstalleerd) geen processen die een telnet sessie met welke host dan ook opzetten.
Tevens komt het IP adres mij ook totaal niet bekend voor.
Een nmap laat zien dat enkel port 22 en port 80 op die host open staat.
Een telnet sessie naar die host wordt niet beantwoord.
Wat ik mij afvraag, kan ik achterhalen welk proces deze sessie probeert te initiaten?
Kan me niet voorstellen dat er is ingebroken op de server, maar kan me ook niet voorstellen dat een legitiem programma dit doet.
Daarbij komt dat al een lange tijd geen DNS queries de server uit mogen gaan, dus het IP adres is ook niet via DNS verkregen, m.a.w. die is ergens ingeklopt.
Iemand ideeen?
Het is geen telnet, want hoewel naast poort 23/TCP ook poort 23/UDP voor dat protocol gereserveerd is, ken ik geen implementatie van telnet die iets doet via UDP. Bovendien, in [1] komt "UDP" niet voor.Hallo allen,
Vandaag kwam ik per toeval een vreemd pakketje tegen in het dataverkeer van een Ubuntu 12 LTS server die rechtstreeks aangesloten zit op het internet (VPS).
Het gaat om:
UDP (55 Bytes) from 37.34.xx.xx:57505 to 80.115.x.x:23 on eth0.
Het IP adres (from) is dus het IP address wat mijn VPS toegewezen heeft gekregen aan de public facing ethernet port.
Deze kwam ik toevallig tegen via IPTraf toen ik bezig was met wat iptables aanpassen - dit trok mijn aandacht.
Nu draaien er (voor zover ik weet en heb geinstalleerd) geen processen die een telnet sessie met welke host dan ook opzetten.
Tevens komt het IP adres mij ook totaal niet bekend voor.
Een nmap laat zien dat enkel port 22 en port 80 op die host open staat.
Een telnet sessie naar die host wordt niet beantwoord.
Wat ik mij afvraag, kan ik achterhalen welk proces deze sessie probeert te initiaten?
Kan me niet voorstellen dat er is ingebroken op de server, maar kan me ook niet voorstellen dat een legitiem programma dit doet.
Daarbij komt dat al een lange tijd geen DNS queries de server uit mogen gaan, dus het IP adres is ook niet via DNS verkregen, m.a.w. die is ergens ingeklopt.
Iemand ideeen?
Als je niet meer details geeft (zoals het volledige 80.115.x.x adres, dat vermoedelijk wel bij RIPE (Europa incl. Rusland) geregistreerd is), kunnen wij niet helpen.
Aanvulling 15:35, zo te zien:
80.115.0.0 t/m 80.115.191.255 Ziggo NL
80.115.192.0 t/m 80.115.223.255 div. in Rusland
80.115.224.0 t/m 80.115.255.255 Ziggo NL
Zit je zelf bij Ziggo?
[1] https://tools.ietf.org/html/rfc854
26-02-2017, 15:49 door
Do
Het 80.115.x.x adres is bij Ziggo Consumers geregistreerd.
Ik zit zelf ook bij Ziggo, maar zit in een hele andere range.
Wat voor details zou je verder willen zien in dit geval?
Ik zit zelf ook bij Ziggo, maar zit in een hele andere range.
Wat voor details zou je verder willen zien in dit geval?
Ik zou in ieder geval de hele inhoud van het packet laten zien.
En kijken welk proces er aan dat interne adres/port hangt.
En kijken welk proces er aan dat interne adres/port hangt.
26-02-2017, 17:20 door
Erik van Straten
Het destination IP-adres zodat ik kan Googlen of het een eerder gemeld IP adres betreft cq. of het geblacklist is, maar dat kun je natuurlijk ook zelf doen.
Je kunt ook googlen naar het IP-adres van jouw VPS host om te zien of anderen hebben gemeld daar last van te hebben gehad.
Wellicht dat je met tools als netstat, lsof (zie bijv. [1]) of wireshark meer kunt achterhalen op de VPS host. Maar als deze grondig gecompromitteerd is (rootkit) moet je ervan uitgaan dat alle informatie, verkregen via die host zelf, gemanipuleerd kan zijn.
[1] https://danielmiessler.com/study/lsof/
Je kunt ook googlen naar het IP-adres van jouw VPS host om te zien of anderen hebben gemeld daar last van te hebben gehad.
Wellicht dat je met tools als netstat, lsof (zie bijv. [1]) of wireshark meer kunt achterhalen op de VPS host. Maar als deze grondig gecompromitteerd is (rootkit) moet je ervan uitgaan dat alle informatie, verkregen via die host zelf, gemanipuleerd kan zijn.
[1] https://danielmiessler.com/study/lsof/
Mira scan. Log al je poorten maar eens en je zult in grote hoeveelheden o.a 23 en 2323 tegenkomen van over heel de wereld.
Door Anoniem: Mira scan. Log al je poorten maar eens en je zult in grote hoeveelheden o.a 23 en 2323 tegenkomen van over heel de wereld.
TCP ja. maar dit gaat over UDP. Dat is toch wel wat bijzonders.
27-02-2017, 09:23 door
Do
Door Erik van Straten: Het destination IP-adres zodat ik kan Googlen of het een eerder gemeld IP adres betreft cq. of het geblacklist is, maar dat kun je natuurlijk ook zelf doen.
Je kunt ook googlen naar het IP-adres van jouw VPS host om te zien of anderen hebben gemeld daar last van te hebben gehad.
Wellicht dat je met tools als netstat, lsof (zie bijv. [1]) of wireshark meer kunt achterhalen op de VPS host. Maar als deze grondig gecompromitteerd is (rootkit) moet je ervan uitgaan dat alle informatie, verkregen via die host zelf, gemanipuleerd kan zijn.
[1] https://danielmiessler.com/study/lsof/
Je kunt ook googlen naar het IP-adres van jouw VPS host om te zien of anderen hebben gemeld daar last van te hebben gehad.
Wellicht dat je met tools als netstat, lsof (zie bijv. [1]) of wireshark meer kunt achterhalen op de VPS host. Maar als deze grondig gecompromitteerd is (rootkit) moet je ervan uitgaan dat alle informatie, verkregen via die host zelf, gemanipuleerd kan zijn.
[1] https://danielmiessler.com/study/lsof/
IP adressen laten niets verdachts zien in Google, had inderdaad hetzelfde al gecontroleerd.
Net je URL gecheckt v.w.b. lsof, wat een beest van een tool, thanks!
Ik ga daarmee eens aan de slag.
Door Anoniem:
Door Anoniem: Mira scan. Log al je poorten maar eens en je zult in grote hoeveelheden o.a 23 en 2323 tegenkomen van over heel de wereld.
TCP ja. maar dit gaat over UDP. Dat is toch wel wat bijzonders.Bijzonder vind ik het zeker, ben oprecht benieuwd welke applicatie hiervoor verantwoordelijk is of wat er anders speelt op die server.
Door Do:
Bijzonder vind ik het zeker, ben oprecht benieuwd welke applicatie hiervoor verantwoordelijk is of wat er anders speelt op die server.
Ja ik denk dat je server gehacked is. Even opnieuw installeren maar. Dat is met een VPS vaak simpel te doen ofBijzonder vind ik het zeker, ben oprecht benieuwd welke applicatie hiervoor verantwoordelijk is of wat er anders speelt op die server.
aan te vragen.
27-02-2017, 10:20 door
Do
Ik ben nu bezig met tcpdump om een capture te maken om te analyseren in Wireshark (ook al vermoed ik niet veel te vinden in de packets zelf).
LSOF lijkt de UDP pakketten voor port 23 niet te 'zien' - krijg er geen hits op.
Ook al zoek ik naar al het UDP verkeer richting dat specifieke IP, weer geen hits.
Dit terwijl ik met tcpdump zie dat er vanuit die server wel een UDP pakket naar dat target gaat.
Iemand een idee hoe ik via LSOF (of een ander programma) kan zien welk proces verantwoordelijk is in zo'n geval?
Meerdere parameters (zoals: -r2 , @Target, UDP, etc) geprobeerd en gegoogeld maar niks kunnen vinden.
LSOF lijkt de UDP pakketten voor port 23 niet te 'zien' - krijg er geen hits op.
Ook al zoek ik naar al het UDP verkeer richting dat specifieke IP, weer geen hits.
Dit terwijl ik met tcpdump zie dat er vanuit die server wel een UDP pakket naar dat target gaat.
Iemand een idee hoe ik via LSOF (of een ander programma) kan zien welk proces verantwoordelijk is in zo'n geval?
Meerdere parameters (zoals: -r2 , @Target, UDP, etc) geprobeerd en gegoogeld maar niks kunnen vinden.
27-02-2017, 10:36 door
Do
Okee, nieuwsflash: open de dump in Wireshark, selecteer het pakket, ga naar data en wat zie ik staan:
Cacti Monitoring System.
Gezien Cacti ook echt draait op die server gezocht naar die host en wat blijkt, daar stond het IP ingeklopt.
Ondanks dat het uiteindelijk nergens over ging toch weer een hoop geleerd.
Thanks heren!
Cacti Monitoring System.
Gezien Cacti ook echt draait op die server gezocht naar die host en wat blijkt, daar stond het IP ingeklopt.
Ondanks dat het uiteindelijk nergens over ging toch weer een hoop geleerd.
Thanks heren!
Door Anoniem:
Door Anoniem: Mira scan. Log al je poorten maar eens en je zult in grote hoeveelheden o.a 23 en 2323 tegenkomen van over heel de wereld.
TCP ja. maar dit gaat over UDP. Dat is toch wel wat bijzonders.Mijn honeypot zag zoveel bijzonder verkeer dat ik hem voor mijn gemoedsrust maar uitgezet heb. ;)
27-02-2017, 11:39 door
Erik van Straten
Googlen naar Cacti udp 23 laat zien dat Cacti kennelijk UDP poort 23 gebruikt voor ping - ook ik heb weer wat geleerd!
'lsof -i' is de basis voor het vervangen van netstat.
Waar Anoniem het eerder had over "Mira" bedoelde hij/zij, neem ik aan, "Mirai" maar Googlen daarnaar in combinatie met UDP 23 leverde bij mij niks bijzonders op.
Goed dat is achterhaald wat uiteindelijk de oorzaak was!
'lsof -i' is de basis voor het vervangen van netstat.
Waar Anoniem het eerder had over "Mira" bedoelde hij/zij, neem ik aan, "Mirai" maar Googlen daarnaar in combinatie met UDP 23 leverde bij mij niks bijzonders op.
Goed dat is achterhaald wat uiteindelijk de oorzaak was!
Waarschijnlijk zit er een agent op je conputer in te breken. Dat is nl vandaag de dag volkomen normaal. Dankzij de VVD, PVDA, CDA& PVV zijn over een tijdje alle it criminelen in dikbetaalde dienst van de overheid.
28-02-2017, 14:28 door
Do
Des te meer werk heb je in de private security sector. Wees blij.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
