Server breached

[smeerbartje]

Gisteravond wou ik via ssh inloggen op m'n servertje in de meterkast. Echter kreeg ik een connection refused. Vaag, dacht ik nog. Na wat onderzoek bleek het te komen doordat het maximum aantal ingelogde ssh sessies was bereikt. Niet goed, aangezien ik de enige ben die de server gebruikt. Even de openstaande sessies bekeken met het volgende commando:

code:

sudo lsof -i -n | egrep 'ssh'

En wat schets mijn verbazing, er zijn een hoop aantal externe adressen via SSH verbonden. Zie screenshot:



Niet relaxt. Ik hen maar gelijk de server opnieuw geinstalleerd / clean install, maar nu zou ik graag willen weten hoe ze binnen zijn gekomen en wat ze hebben gedaan. Ik heb voordat ik een format deed de /var/log gebackupped. Hoe kan ik de logfiles onderzoeken om erachter te komen wat hij/zij deed?

Tevens ben ik op zoek naar de beste manier om een (thuis) servertje te beveiligen? Wat ik na de clean install heb gedaan is het volgende:

1. SSH poort gewijzigd; niet meer de default (22)
2. Middels IP tables geregeld dat connecten op de SSH poort niet vaker mag dan x keer binnen x minuten
3. Password logins uitgezet, inloggen mag enkel met keys
4. Root login doen we niet

Nog tips voor verdere beveiliging?

[ Voor 19% gewijzigd door smeerbartje op 21-11-2014 10:01 ]

[BoAC]

Waarschijnlijk is er een gebruikersnaam met brute force gevonden. Dus ik zou zoeken naar een succesvolle inlog in de log
Ik denk dat alle servers met ssh open deze vorm van aanvallen heeft. Oplossing is:
1. Alleen specifieke gebruikers toegang geven via allow users in je sshd_config
2. fail2ban gebruiken die na 5 login fails betreffend ipadres blocked voor bepaalde tijd

Had je toevallig ook veel php procesjes?

[smeerbartje]

De server kende maar één gebruiker: mijzelf . Dus er zijn genoeg succesvolle logins te vinden in de loggin. Ik zal eens zoeken of er ook wordt gelogd vanuit WAAR de login plaats heeft gevonden. In mijn geval zijn dat niet veel verschillende IP's. Werk heeft namelijk een static address.

Wat betreft de PHP processen: nee, niet overdreven veel actieve processen. Er waren alleen veel SSH processen actief. Ik heb nog steeds geen idee wat ze deden .

[ Voor 22% gewijzigd door smeerbartje op 21-11-2014 10:06 ]

[filenox]

Vanaf waar er is ingelogd staat in /var/log/auth.log Een mogelijke op manier om toekomstige hacks te voorkomen is een veel sterker wachtwoord te gebruiken en in te loggen met een public/private key.

Je ssh-poort veranderen helpt natuurlijk ook

[ Voor 11% gewijzigd door filenox op 21-11-2014 10:08 ]

[ThinkPad]

Waarom staat je SSH open naar internet? Dat is vragen om moeilijkheden...
Je kunt beter een VPN opzetten en daarmee op afstand inloggen op je server.

Welke SSH client is dat trouwens? Kleurenschema ziet er wel fijn uit.

[ Voor 32% gewijzigd door ThinkPad op 21-11-2014 10:11 ]

[ShadowBumble]

Ik persoonlijk heb het zo opgezet :

1 Hardend Server met een minimale install, SSH op een niet gangbare poort, UFW die alle IP's blocked voor SSH behalve die ik handmatig toevoeg.

En vanuit die ene server kan ik de rest van mijn netwerk gebruiken ( eventueel door SSH Tunnels ).

[TimDJ]

ShadowBumble schreef op vrijdag 21 november 2014 @ 10:10:
Ik persoonlijk heb het zo opgezet :

1 Hardend Server met een minimale install, SSH op een niet gangbare poort, UFW die alle IP's blocked voor SSH behalve die ik handmatig toevoeg.

En vanuit die ene server kan ik de rest van mijn netwerk gebruiken ( eventueel door SSH Tunnels ).

Dan zou ik altijd nog even zorgen voor een backup route want als die ene server nu net crashed ben je overal uitgesloten.

[SeatRider]

Gevoelsmatig had ik ook niet eerst de server geflushed en daarna een onderzoek ingesteld. Beter koppel je de machine van het internet af, en ga je daarna speuren, voordat je hem opnieuw installeert.

[ShadowBumble]

TimDJ schreef op vrijdag 21 november 2014 @ 10:12:
Dan zou ik altijd nog even zorgen voor een backup route want als die ene server nu net crashed ben je overal uitgesloten.

Sja dan moet ik wachten tot ik thuis ben, maar functioneel zal er intern niks crashen omdat toevallig de hop server op zijn gat ligt, er draaien daarop namelijk geen functionele dingen.

[Jumpman]

ShadowBumble schreef op vrijdag 21 november 2014 @ 10:10:
Ik persoonlijk heb het zo opgezet :

1 Hardend Server met een minimale install, SSH op een niet gangbare poort, UFW die alle IP's blocked voor SSH behalve die ik handmatig toevoeg.

En vanuit die ene server kan ik de rest van mijn netwerk gebruiken ( eventueel door SSH Tunnels ).

Dit voorkomt enorm veel problemen. Echter als je veel onderweg bent, en vaak van uit andere plaatsen inlogt is dit lastig.

[smeerbartje]

SeatRider schreef op vrijdag 21 november 2014 @ 10:12:
Gevoelsmatig had ik ook niet eerst de server geflushed en daarna een onderzoek ingesteld. Beter koppel je de machine van het internet af, en ga je daarna speuren, voordat je hem opnieuw installeert.

I know , maar de server dient ook als router thuis... en vrouwlief kan niet zonder Netflix .

[Pacjack]

Je hebt alvast goede maatregelen genomen. Ik zou ook nog instellen dat niemand toegang heeft tot ssh behalve een lijst van bekende ip-adressen; Dat doe je met hosts_access.

/etc/hosts.deny:
sshd: ALL

/etc/hosts.allow:
sshd: ipadres, ipadres, ipadres

[smeerbartje]

Thanks allemaal; alleen nu de vraag: WAT gebeurde er toen ze "binnen" waren? In de logging zie ik verder weinig activiteit. Ik heb nu trouwens SFTP logging ook op verbose gezet; wellicht handig voor in de toekomst. Ik verwacht namelijk dat ze files o.i.d. via SSH hebben gekopieerd. Ik kan het alleen nu niet (meer) zien .

http://serverfault.com/qu...tp-logging-is-there-a-way

[ Voor 52% gewijzigd door smeerbartje op 21-11-2014 10:30 ]

[ShadowBumble]

Jumpman schreef op vrijdag 21 november 2014 @ 10:18:
[...]


Dit voorkomt enorm veel problemen. Echter als je veel onderweg bent, en vaak van uit andere plaatsen inlogt is dit lastig.

1 Commando naar een Specifieke set poorten in een Specifieke volgorde en het IP word gewoon toegevoegd voor een korte tijd en word daarna automatisch er weer uitgehaald.

http://en.wikipedia.org/wiki/Port_knocking

[gekkie]

Hmm ik gebruik pam_abl .. blijven ze het fijn proberen alleen wordt elke poging na de threshold als foutief bestempeld (ook als het ww onverhoopt juist zou zijn). En de machine mailt bij een geslaagde SSH inlog (SSH of sftp) de lijst met op dat moment actieve gebruikers direct naar m'n logging account). In theorie zou het dus niet zo lang on opgemerkt moeten blijven mocht iemand er onverhoopt binnen komen.

[ThinkPad]

Dan blijft de vraag: Waarom wil je SSH open hebben staan naar internet? Met een VPN hoeft dat toch niet? Heb je ook gelijk het voordeel dat je andere services en apparaten op je netwerk kunt benaderen.

[ Voor 31% gewijzigd door ThinkPad op 21-11-2014 10:42 ]

[smeerbartje]

gekkie schreef op vrijdag 21 november 2014 @ 10:37:
Hmm ik gebruik pam_abl .. blijven ze het fijn proberen alleen wordt elke poging na de threshold als foutief bestempeld (ook als het ww onverhoopt juist zou zijn). En de machine mailt bij een geslaagde SSH inlog (SSH of sftp) de lijst met op dat moment actieve gebruikers direct naar m'n logging account). In theorie zou het dus niet zo lang on opgemerkt moeten blijven mocht iemand er onverhoopt binnen komen.

Hoe mail je de lijst met actieve gebruikers?

[filenox]

smeerbartje schreef op vrijdag 21 november 2014 @ 10:47:
[...]

Hoe mail je de lijst met actieve gebruikers?

Waarschijnlijk via een script met iets als 'who | grep pts' in oid

[DJMaze]

SSH op een andere poort is security through obscurity.
Het werkt gewoon niet, een port scan en voila!
Zo moest ik ooit SFTP'en bij een beveiligd bedrijf, bleek de gewone FTP op poort 22 te draaien

Een 4096 bits pub/priv key is je beste methode.
En in sshd_config

code:

PasswordAuthentication no

eventueel ook (afhankelijk van sudo instellingen)

code:

PermitRootLogin without-password

[ Voor 4% gewijzigd door DJMaze op 21-11-2014 11:15 ]

[filenox]

Security through obscurity is enkel een probleem als het de enige manier van security is, anders heeft het sowieso een toegevoegde waarde Zo zullen bots niet voor elke pc een portscan gaan doen voor elke pc die ze willen bruteforcen

[ Voor 25% gewijzigd door filenox op 21-11-2014 11:18 ]

[Keipi]

DJMaze schreef op vrijdag 21 november 2014 @ 11:14:
SSH op een andere poort is security through obscurity.
Het werkt gewoon niet, een port scan en voila!
Zo moest ik ooit SFTP'en bij een beveiligd bedrijf, bleek de gewone FTP op poort 22 te draaien

Een 4096 bits pub/priv key is je beste methode.
En in sshd_config

code:

PasswordAuthentication no

eventueel ook (afhankelijk van sudo instellingen)

code:

PermitRootLogin without-password

Als je je SSH open hebt staan naar het internet en jij één van de weinige bent die het gebruikt is een andere SSH poort wel degelijk aan te raden. Tegen gerichte aanvallen is het niet effectief vanwege portscans maar er zijn standaard een hoop willekeurige IP's die alle IP's op port 22 zitten te pingen. Bij een response op port 22 word er vervolgens een brute-force tegenaan gegooid.

Het is dus verstandig om dit te vermijden door een andere SSH port te gebruiken.

Voor de rest heeft TS wel al vrij goede stappen ondernomen. In sshd_config zetten welke IP's/users wel en niet allowed zijn is nog aan te raden. Je moet dan wel zorgen dat 'root' natuurlijk niet in de allowed sectie staat.

[Kelfox]

ThinkPadd schreef op vrijdag 21 november 2014 @ 10:40:
Dan blijft de vraag: Waarom wil je SSH open hebben staan naar internet? Met een VPN hoeft dat toch niet? Heb je ook gelijk het voordeel dat je andere services en apparaten op je netwerk kunt benaderen.

En met VPN heb je geen poort open staan naar buiten? Waarom zou het veiliger zijn om een VPN service open te hebben staan op poort 1111 ipv SSH op poort 1111?

[Wolfboy]

Leuk alternatief voor fixed IP adressen is gewoon port knocking gebruiken. Nog steeds een vorm van security by obscurity maar mensen moeten bijhoorlijk gokken om op een random poort met een random patroon te gaan knocken. In de praktijk is de kans hierop om en nabij 0.

[begintmeta]

Om een key te gokken moet je ook al behoorlijk gokken.

gekkie schreef op vrijdag 21 november 2014 @ 10:37:
Hmm ik gebruik pam_abl .. blijven ze het fijn proberen alleen wordt elke poging na de threshold als foutief bestempeld (ook als het ww onverhoopt juist zou zijn). En de machine mailt bij een geslaagde SSH inlog (SSH of sftp) de lijst met op dat moment actieve gebruikers direct naar m'n logging account). In theorie zou het dus niet zo lang on opgemerkt moeten blijven mocht iemand er onverhoopt binnen komen.

Wat doe je mbt denial-of-service-gevoeligheden?

Ik schat de kans op bruteforcesucces misschien gewoon wat te klein in, maar meestal laat ik het gewoon bij de standaardpoort met een key.

[ Voor 3% gewijzigd door begintmeta op 21-11-2014 13:01 ]

[ninjazx9r98]

Als je echt op zoek wilt gaan wat er precies aan de hand is of beter gezegd was had je de server niet moeten schratchen/herinstalleren. Buiten de informatie uit /var/log heb je nu helemaal niets meer en bij de info uit /var/log moet je jezelf afvragen hoe betrouwbaar dat is aangezien dat gemanipuleerd/aangepast kan worden.
Dat gezegd hebbende, mogelijk heb je met iemand te maken die weinig tot geen moeite heeft gedaan om zijn sporen uit te wissen en kun je mogelijk een en ander terug vinden.

[Heli0s]

Als je al gehackt bent, is het sowieso lastig te achterhalen wat er is gebeurd. Een beetje slime hacker zal aangepaste versies van de standaard tools als ls, who etc installeren om zijn sporen uit te wissen. Ook, zoals ninjazx9r98 al zegt, zullen de logs in /var/log aangepast of verwijderd zijn.

Wat ik niet gelezen hebt is je firewall standaard op DROP of REJECT zetten en alleen open zetten wat je echt gebruikt.

[Thc_Nbl]

Ik vermoed dat je server niet helemaal up2date was.

ik draai al jaren gewoon op port 22 samen met fail2ban en nog nooit 1 hack gehad.
geen root toestaan, en als extra, een "AllowGroups Custumsshgroup" toegevoegd aan ssh.
en daar zitten 2 gebruikers in. 1 die ik gebruik, 1 reserve met een 25+ char wachtwoord.

Ik zou eens goed gaan nadenken welke software er allemaal op draaide en of deze wel allemaal up2date was.

wat ik vermoed is, je had ook een webserver draaien.
Via deze webserver hebben ze wat in /tmp ofzo gezet en daarvandaan een ssh server gestart.
gebeurd wel vaker..

Als je alleen inlogd via ssh, zet er dan een firewall regeltje bij dat SSH niet naar buiten mag.

[ShadowBumble]

Heli0s schreef op vrijdag 21 november 2014 @ 13:34:
Wat ik niet gelezen hebt is je firewall standaard op DROP of REJECT zetten en alleen open zetten wat je echt gebruikt.

Altijd zorgen dat je Firewall op DROP staat, bij REJECT krijg de verzender van het packetje een "refused" melding en weet hij dus dat die poort gefiltered is, bij een DROP word het packetje gewoon silent weggegooit.

Kortom altijd drop gebruiken

[Heli0s]

Dat is niet helemaal waar, aan een time out kun je ook zien dat er iets 'dicht' zit of er niet is. Daarnaast is het eigenlijk de bedoeling dat je hem op reject in stelt zodat legitieme services meteen kunnen zien of een poort of server open staat zonder te hoeven wachten op een time out.

[Thralas]

Keipi schreef op vrijdag 21 november 2014 @ 11:32:
Het is dus verstandig om dit te vermijden door een andere SSH port te gebruiken.

Not an issue met PasswordAuthentication disabled. Ik vind het ook weinig toevoegende security through obscurity. Datzelfde geldt wmb. voor het disablen van root logins.

Pacjack schreef op vrijdag 21 november 2014 @ 10:23:
Je hebt alvast goede maatregelen genomen. Ik zou ook nog instellen dat niemand toegang heeft tot ssh behalve een lijst van bekende ip-adressen; Dat doe je met hosts_access.

tcp_wrappers is enigzins gedateerd en niet universeel beschikbaar (mijn distro shipped het inmiddels niet meer). Ik zou gewoon firewallen met iptables..

@TS: die ssh-sessies draaien als root, dus je root user had een dictionary password of je kernel was out-of-date en je gaf een user shell weg (webserver?). Which one is it? Dat eerste kun je prima bevestigen met de logs die je hebt.

[FitzJac]

Dit is ook altijd aan te raden: SSHGuard

[gekkie]

filenox schreef op vrijdag 21 november 2014 @ 10:53:
[...]
Waarschijnlijk via een script met iets als 'who | grep pts' in oid

Onder andere, al trigger ik in pam.d/common-session, die dan een scriptje execute met gegevens over die login sessie (en machine). Met who | grep pts mis je namelijk helaas sftp, en nu krijg ik ook een mailtje bij een 'su'.

begintmeta schreef op vrijdag 21 november 2014 @ 12:58:
Om een key te gokken moet je ook al behoorlijk gokken.

[...]

Wat doe je mbt denial-of-service-gevoeligheden?

Ik schat de kans op bruteforcesucces misschien gewoon wat te klein in, maar meestal laat ik het gewoon bij de standaardpoort met een key.

Idd is het opzich al semi-overbodig, de kans dat je er uberhaupt in komt zonder of bug .. of voorkennis is al nihil. Maar goed een bruteforce dermate vertragen dat het totaal geen kans maakt kan ook geen kwaad.

Voor noodgevallen een normal user account met een semi random generated username .. kans dat die ook (voor een beperkte tijd) gelockt is is vrij klein. Maar goed zolang je normale account al niet echt voorkomt op de standaard lijstjes (root admin .. alle service names .. cq amerikaanse voornamen etc) is de kans nagenoeg nihil)

[ Voor 18% gewijzigd door gekkie op 21-11-2014 18:07 ]

[smeerbartje]

Heli0s schreef op vrijdag 21 november 2014 @ 13:34:
Als je al gehackt bent, is het sowieso lastig te achterhalen wat er is gebeurd. Een beetje slime hacker zal aangepaste versies van de standaard tools als ls, who etc installeren om zijn sporen uit te wissen. Ook, zoals ninjazx9r98 al zegt, zullen de logs in /var/log aangepast of verwijderd zijn.

Wat ik niet gelezen hebt is je firewall standaard op DROP of REJECT zetten en alleen open zetten wat je echt gebruikt.

M'n IPTABLES rules zien er als volgt uit. Is dit een beetje safe?

code:

#!/bin/sh
# em1 / em1  = internal NIC
# p1p1 / p1p1 = WAN NIC

# Check for root
if [ "$(id -u)" != "0" ]; then
   echo "This script must be run as root" 1>&2
   exit 1
fi

echo "Clear old firewall rules..."
iptables --flush
iptables --flush FORWARD
iptables --flush INPUT
iptables --flush OUTPUT
iptables --table nat --flush
iptables --table nat --delete-chain
iptables --table mangle --flush
iptables --table mangle --delete-chain
iptables --delete-chain

echo "Drop all INPUT and FORWARD..."
iptables -P INPUT DROP
iptables -P FORWARD DROP

echo "Drop all IPv6 traffic..."
ip6tables -P INPUT DROP
ip6tables -P OUTPUT DROP
ip6tables -P FORWARD DROP

echo "Accept everything on lo and em1 (local network)..."
iptables -A INPUT -i lo -p all -j ACCEPT
iptables -A OUTPUT -o lo -p all -j ACCEPT
iptables -A INPUT -i em1 -p all -j ACCEPT -s 192.168.1.0/24
iptables -A OUTPUT -o em1 -p all -j ACCEPT -d 192.168.1.0/24

echo "IP Forwarding and Routing for gateway use..."
iptables -A FORWARD -o p1p1 -i em1 -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o p1p1 -j MASQUERADE

echo "Enable Packet Forwarding..."
echo 1 > /proc/sys/net/ipv4/ip_forward

echo "Maintain established connections..."
iptables -A INPUT --in-interface p1p1 --match conntrack --ctstate ESTABLISHED,RELATED --jump ACCEPT

echo "Allow port 1234 (SSH) connections to the firewall..."
iptables -A INPUT -p tcp --dport 1234 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT
iptables -A INPUT -m recent --update --seconds 600 --hitcount 8 --rttl --name SSH --rsource -j DROP

echo "Allow port 80 (HTTP) connections to the firewall..."
iptables -A INPUT -i p1p1 -p tcp --dport 80 -m state --state NEW -j ACCEPT

[Sendy]

Volgens mij zie je hier dat je een established TCP verbinding hebt. Dat is nogal nodig voor ieder contact. Waarschijnlijk zijn het inlogpogingen.

Ik zie bijvoorbeeld ook

code:

22320 ?        Ss     0:00  \_ sshd: unknown [priv]
22321 ?        S      0:00      \_ sshd: unknown [net]

terwijl ik aan het inloggen ben.


Je kan ook nog onderzoeken wat die processen dan voor files en sockets open hebben.

[ Voor 19% gewijzigd door Sendy op 21-11-2014 22:14 ]

[syl765]

Het kan echt geen kwaad om ssh open te stellen voor het Internet.
Je moet er alleen voor zorgen dat men je wachtwoord niet vind. Het kan natuurlijk heel goed dat je op je werkstation besmet bent geraakt en dat men via een keylogger jou ssh wachtwoord hebben gevonden. Wat men verder uitspookt op je server blijft gissen. Als men goed bezig is dan zorgen ze er wel voor dat in de log files niet veel meer te vinden is. Misschien gebruikten ze jou server alleen om door te steken naar andere servers. Aangezien de server er niet meer is zul je het nooit weten.
Wil je het weten, tuig een virtuele bak op maak checksums van alle bestanden.
Open ssh met oude wachtwoord en kijk wat er gebeurt.
Je zal zien dat er bestanden worden veranderd. Kan heel leerzaam zijn en je zal ook de allereerste inlog meemaken. Het kan natuurlijk achterdocht wekken aangezien de sleutel anders is maar misschien denken ze dat je gewoon de zoveelste bent die zijn server opnieuw opbouwt en weer aan het Internet hangt.
Je maakt eigenlijk een honeypot. Geloof me je blijft je verbazen hoe inventief men is en wat men allemaal doet.

Er zijn ook kant en klare oplossingen.
http://www.honeynet.org/node/1177

[ Voor 18% gewijzigd door syl765 op 22-11-2014 10:21 ]

[smeerbartje]

Iemand nog op- of aanmerkingen m.b.t. m'n IPTABLES rules?

[Basz0r]

Je iptables config ziet er op eerste oog veilig uit, maar heb je in de tussentijd ook al gedacht aan een tool zoals bijvoorbeeld DenyHosts? Die blokkeert op basis van authenticatie pogingen die geregistreerd worden in '/var/log/auth.log' IP addressen. Als je ervoor zorgt dat deze maximaal 3 keer een foutieve inlognaam / wachtwoord mogen proberen, blokkeer je al een hele hoop zooi weg. In combinatie met rate limiting op de SSH poort (zoals nu in je iptables config is ingesteld) zit je daar voorlopig wel goed mee. En natuurlijk een complex wachtwoord gebruiken in combinatie met een niet zo'n gebruikelijke username.

[ddkiller0900]

Waarschijnlijk ook verstandig om te doen, draai je services in een chroot. Zo doe ik het thuis in ieder geval. Voor de rest beheer ik alles via een vpn waarvoor een certificaat, gebruikersnaam en wachtwoord nodig is. Eventueel kan ik het nog uitbreiden met 2 weg authenticatie.

[Megamind]

Waarom gebruik je niet gewoon Configserver Firewall? Dan heb je gelijk fail2ban, whitelisting, email als er ingelogd wordt etc.

Veiliger dan zelf proberen het op te lossen.

[Wolfboy]

smeerbartje schreef op zaterdag 22 november 2014 @ 10:03:
Iemand nog op- of aanmerkingen m.b.t. m'n IPTABLES rules?

De volgorde, op dit moment flush je de regels eerst en stel je daarna pas de policy in. Je bent dus een (zeer korte) tijd vulnerable. Beter om die volgorde gewoon direct om te draaien

Daarnaast zou ik alle regels direct aan een interface koppelen om fouten te voorkomen.

[smeerbartje]

Wat bedoel je met het direct koppelen aan de interface? Kun je een voorbeeldje geven? Thanks trouwens...

[geekeep]

(even een klein bruggetje naar een gerelateerd onderwerp)

Vraag me al een tijdje af of mensen met een Raspberry Pi op het netwerk en een ssh service draaien of een vpn server opzetten enig besef hebben van het risico van een verbinding toegankelijk via 'het internet'. De standaard inloggegevens van pi/raspberry blijven vaak ongewijzigd, alsook de default ssh/vpn poort.
Zo lijdt het toenemende internet-of-things helaas aan een onderbelichte kant m.b.t. veiligheid. Zie bijvoorbeeld ook https://www.security.nl/p...mera%27s+slecht+beveiligd

Gelukkig zijn de voorgestelde suggesties in dit topic (port change, fail2ban, iptable rules, private key i.p.v. wachtwoord, custom ip access), ook van toepassing op een RPi + zo'n beetje elke Linux gebaseerde omgeving. Maar toch vrees is voor een steeds groter aandeel van inbraak(pogingen) via allerlei apparaten die aan het internet hangen (denk aan NASsen, settop-boxen, smart TVs, thermostaten, koelkasten, magnetrons, ovens, etc).

[Wolfboy]

smeerbartje schreef op maandag 24 november 2014 @ 21:23:
Wat bedoel je met het direct koppelen aan de interface? Kun je een voorbeeldje geven? Thanks trouwens...

Bij sommige regels heb je geen input/output interface gespecificeerd. Als je dat wel doet dan ben je er zeker van dat je niet per ongeluk dingen gaat whitelisten die eigenlijk niet whitelisted zouden moeten worden

Bij deze regels bijvoorbeeld is geen enkele "-i" of "-o" parameter. In het geval van firewalls ben ik bij voorkeur zo expliciet mogelijk, elke regel op een specifieke netwerkinterface met een specifieke state, poort en interface.

iptables -A INPUT -p tcp --dport 1234 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT
iptables -A INPUT -m recent --update --seconds 600 --hitcount 8 --rttl --name SSH --rsource -j DROP

[Thralas]

En inmiddels heeft TS nog steeds niet achterhaald wat 'ie nu fout heeft gedaan. Daar kun je ontzettend veel van leren

[smeerbartje]

@Wolfboy: thanks.
@Thralas: klopt, zoals je kunt lezen heb ik die kans niet meer door een clean install...

[Thralas]

Je hebt logs. Daar kun je in ieder geval uit halen (tenzij ze cleaned zijn, hah!):

• Of de aanvaller in 1x via SSH is ingelogd, of na een bruteforce
• Als welke user hij initieel is ingelogd
• Indien niet als root: of je kernel up-to-date was

[Elijan9]

Je bent gehacked dus die logs kun je niet echt vertrouwen. Misschien dat je wel er het e.a. uit kunt halen, maar reken er niet op dat je kunt achterhalen wat er allemaal gedaan is... Het geeft hooguit een indicatie van hoe professioneel de hacker was. (Het IP adres uit de screenshot komt vanuit Amazon AWS, je kunt daar misbruik melden bij [e-mail] met jouw screenshot, wel doen!)

.edit: dat IP adres is nogal actief met ssh maar wordt nog niet geblokeerd door fail2ban: http://www.blocklist.de/en/view.html?ip=54.164.137.237 Het weet zich nog enigszins onder de radar te houden.

De maatregelen die je hebt genomen zijn verstandig, ik zou ook nog rkhunter installeren, dat doe ik standaard op al mijn Linux machines. En laat cron jouw mailen als er iets fout gaat. (Ikzelf gebruik ssmtp met Gmail, je hoeft niet meteen sendmail of postfix te installeren om een mail te kunnen sturen als er iets mis gaat.)

Maar het is natuurlijk ook mogelijk dat de hacker via een andere weg jouw wachtwoord heeft weten te achterhalen, misschien staat er wel een keylogger op één van de systemen waarmee je hebt ingelogd op het servertje? Hoe voorspelbaar was jouw wachtwoord, of heb je hetzelfde wachtwoord ook elders gebruikt?
(En vergeet niet dat plain-text wachtwoorden op jouw netwerk afgevangen kunnen zijn tijdens de hack. Misschien tijd om alle wachtwoorden weer eens te veranderen...)

[ Voor 8% gewijzigd door Elijan9 op 26-11-2014 11:42 ]

[smeerbartje]

Elijan9, dankje. Heb inderdaad ssmtp i.c.m. mijn google apps account. Werkt als een tiet. Rkhunter en logwatch reports krijg ik dan ook netjes elke dag binnen.

Sinds enkele dagen logwatch op m'n server gezet. Handig tooltje zeg! Alleen een vraagje qua interpretatie van de daily reports. Zie onderstaande screenshot; wat betekent "didn't receive an ident from these IPs"? Is dit gewoon een shell sessie die wordt geopend, maar waarnaar daarna geen credentials zijn ingevoerd? Dan hoef ik me dus geen zorgen te maken...

[ Voor 20% gewijzigd door smeerbartje op 29-11-2014 09:16 ]

[gekkie]

Nadeel aan login reports per dag vindt ik dan weer dat het de kans (tijd) laat voor een hacker om z'n sporen grotendeels uit te wissen. Ik heb liever gelijk een mail @login, er vanuit gaande dat de rest van de infrastructuur wel werkt en niet gehackt is (internet connectie), een hacker niet bedacht is op het feit dat mijn machine gelijk gaat mailen en te weinig tijd heeft om dit te voorkomen.
Hierdoor ben ik in iedergeval op de hoogte dat er iets is gebeurd .. ook al zijn er daarna pogingen gedaan het te verdoezelen.

[smeerbartje]

Naja, de server is voor privé gebruik; speelt als router en draait een aantal hobby-projectjes. Niet veel uptime vereist dus . Qua reporting volstaat een dag dus.

[syl765]

Waar gekkie waarschijnlijk op doelt is dat een beetje hacker voor de daily zijn sporen al heeft gewist.
Jij gaat vertrouwen op je rapporten en aangezien je niets vreemds ziet zal je gaan aannemen dat alles ok is, wat dus niet het geval is.
Ondertussen doet de hacker rustig zijn ding.

[ Voor 3% gewijzigd door syl765 op 05-12-2014 20:05 ]

[smeerbartje]

Inmiddels draait m'n clean-installed servertje al een paar weken feilloos. Echter zo af-en-toe zie ik in m'n daily logwatch mailtje het volgende voorbij komen: "nobody" als closed samba session. Wie is dit en hoe wordt dit veroorzaakt? Dit moet volgens mij iemand zijn vanuit het lokale netwerk, maar wie o wie?

[ThinkPad]

Is dat niet gewoon dat je de mappen op de server benaderd zonder in te loggen, als gast dus? Op m'n Synology NAS is een 'guest' user, waarmee ik hetzelfde kan. Anders moet ik een username + ww opgeven als ik een map wil benaderen.

[smeerbartje]

Ja dat lijkt het te zijn inderdaad; ik definieer een samba share nu als volgt en het probleem lijkt opgelost.

code:

[downloads]
     valid users=smeerbartje
     comment="Downloads on Server"
     path=/home/smeerbartje/downloads
     browseable=yes
     write list=smeerbartje
     writeable=yes

Ik had eerst guest account toegang enabled, nu niet meer dus. Ik vraag me nog wel af wié (welke guest) voor de logging heeft gezorgd.

[ Voor 18% gewijzigd door smeerbartje op 22-12-2014 17:12 ]

[MartinMeijerink]

Wat een paniek om niks (en op een paar na lult iedereen maar met je mee), je bent helemaal niet gehackt, je hebt gewoon poort 22 naar buiten toe openstaan, en daar zijn netwerkverbindingen naartoe opgezet. Het is heel makkelijk reproduceerbaar, tik maar eens in:

for i in $(seq 1 20);do telnet $TARGET 22 & done

hierbij is $TARGET dan het ip-adres van de host waar je de verbindingen mee opzet.
Check tegelijkertijd op de targethost het aantal ESTABLISHED verbindingen, je zult er 20 extra zien.
Helemaal niks aan de hand dus, ze zijn dus niet binnen, ze staan alleen in je voorportaal die gewoon voor iedereen toegankelijk is, dit is normaal (by design).
Lastig is het alleen wel, want je kan dan zelf tijdelijk ff geen verbinding meer opzetten, daarom is de oplossing om ssh op een andere poort te zetten, en noem dit geen security by obscurity, deze oplossing is nl. zinvol om logvervuiling te voorkomen en om te voorkomen dat je voorportaal af en toe vol zit

[smeerbartje]

MartinMeijerink schreef op maandag 22 december 2014 @ 19:19:
Wat een paniek om niks (en op een paar na lult iedereen maar met je mee), je bent helemaal niet gehackt, je hebt gewoon poort 22 naar buiten toe openstaan, en daar zijn netwerkverbindingen naartoe opgezet. Het is heel makkelijk reproduceerbaar, tik maar eens in:

for i in $(seq 1 20);do telnet $TARGET 22 & done

hierbij is $TARGET dan het ip-adres van de host waar je de verbindingen mee opzet.
Check tegelijkertijd op de targethost het aantal ESTABLISHED verbindingen, je zult er 20 extra zien.
Helemaal niks aan de hand dus, ze zijn dus niet binnen, ze staan alleen in je voorportaal die gewoon voor iedereen toegankelijk is, dit is normaal (by design).
Lastig is het alleen wel, want je kan dan zelf tijdelijk ff geen verbinding meer opzetten, daarom is de oplossing om ssh op een andere poort te zetten, en noem dit geen security by obscurity, deze oplossing is nl. zinvol om logvervuiling te voorkomen en om te voorkomen dat je voorportaal af en toe vol zit

Held! You made my day! Een andere oplossing is dus het uitschakelen van "non key"-loggins. Dus eisen dat public-private key authenticatie wordt gebruikt.