DRINGEND - er wordt geprobeerd te hacken

freakske_b · 29 mei 2018, 12:34

Ik ben verontrust over de logs van de fritzbox 7360 van mijn schoonouders. Er zijn voortdurend pogingen om in te loggen, terwijl ze zelf niets speciaals doen. Kan ik de fitzbox loginpogingen van dat ip-adres laten blokkeren?

29.05.18 11:26:57 Login of user admin to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 11:09:19 Login of user admin to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 10:51:39 Login of user admin to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 10:34:01 Login of user admin to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 10:16:27 Login of user admin to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 09:58:52 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 09:41:20 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 09:23:54 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 09:06:38 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 08:49:22 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 08:32:06 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 08:14:50 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 07:57:33 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 07:40:18 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 07:23:02 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 07:05:46 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 06:48:29 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 06:31:13 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 06:13:57 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 05:56:39 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 05:39:21 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 05:22:08 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 05:04:54 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 04:47:43 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 04:30:41 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 04:13:46 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 03:56:56 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 03:40:22 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 03:24:06 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 03:08:20 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 02:52:17 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 02:36:20 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 02:20:26 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 02:04:36 Login of user hallo to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 01:48:50 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 01:33:10 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 01:17:34 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 01:02:04 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 00:46:33 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 00:31:04 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 00:15:36 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
29.05.18 00:00:09 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 23:44:43 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 23:29:16 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 23:13:52 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 22:58:26 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 22:43:03 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 22:27:35 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 22:12:05 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 21:56:36 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 21:41:09 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 21:25:44 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 21:10:17 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 20:54:49 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 20:39:19 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 20:23:48 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 20:08:21 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 19:52:53 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 19:37:27 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 19:21:57 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 19:06:22 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 18:50:44 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).
28.05.18 18:34:58 Login of user nil to the FRITZ!Box user interface from the IP address 163.172.126.8 failed (incorrect password).

depeje · 29 mei 2018, 13:01

Rustig rustig. Dit soort aanvallen is schering en inslag. En als je geen standaardwachtwoorden gebruikt komen ze niet binnen. Dit is waarschijnlijk een scriptje dat onbeveiligde IoT apparaten zoekt.

Mijn mailserver krijgt dagelijks duizenden van deze inlogpogingen.

Je kan dat IP adres inderdaad blokkeren, maar dat is dwijlen met de kraan open.

freakske_b · 29 mei 2018, 13:14

depeje schreef:
Je kan dat IP adres inderdaad blokkeren, maar dat is dwijlen met de kraan open.

Hoe kan je dat ip adres blokkeren in je fritzbox? Ik lees dagelijks de automatische logs, en dit is de eerste keer dat dit gebeurd.

Tim.Bracquez · 29 mei 2018, 13:33

Ik ken FRITZ!Box niet in mogelijkheden, maar waarom zet je remote management niet uit? Dan kunnen ze zelfs niet proberen op http(s).

Remote beheer nodig? zet een VPN server op en connecteer zo naar je fritz

Op het internet lopen de botjes rond te scannen, niet default poorten nemen bespaart je een hoop in logging capaciteit, maar lost het niet op. Eigenlijk mag je die login pogingen als "normaal" beschouwen als je verbonden bent met het internet

CCatalyst · 29 mei 2018, 13:37

Je opties zijn
1. Toegang vanaf WAN niet langer toelaten (via specifieke optie of firewall)
2. Sterke paswoorden en geen default login gebruiken. Wat je in je logs ziet is meer reconnaissance dan hacking en lijkt vooral bedoeld om veel voorkomende login/paswoord combinaties te testen om er zien of er eentje werkt. Zolang je een sterk paswoord hebt moet je je geen zorgen maken hier.
3. IP blokkeren heeft geen zin, zie hieronder

depeje schreef:Dit is waarschijnlijk een scriptje dat onbeveiligde IoT apparaten zoekt.

Nee, dit lijkt specifiek voor Fritzbox. Tenzij je Fritzbox als IoT apparaat beschouwt. Geen idee wat ze dan precies gaan doen als ze binnen raken maar prolly botnet weer.

depeje schreef:Mijn mailserver krijgt dagelijks duizenden van deze inlogpogingen.

Wacht tot je een sshd draait

depeje schreef:Je kan dat IP adres inderdaad blokkeren, maar dat is dwijlen met de kraan open.

Inderdaad, als je een IP blokkeert pakken ze wel een ander. 't Is niet dat ze een gebrek hebben aan IP's.

freakske_b · 29 mei 2018, 13:46

Reactie van Telenet als ik vraag om het "aanvallend" ip adres te blokkeren voor inkomende connecties: ga naar de politie.

29 mei 2018, 13:52

Ik neem aan dat users "admin", "nil" en "hello" geen bestaande users zijn op je FritzBox

Wat je kan doen:

ervoor zorgen dat de FritzBox niet van buitenaf bereikbaar is via http
ervoor zorgen dat de FritzBox niet van buitenaf bereikbaar is via https
als je toch de remote toegang wil behouden (om de FritzBox van je ouders te kunnen managen), dan moet je de standatd poort (443) wijzigen naar een ander willekeurig nummer (1-65535), maar gebruik geen poorten tussen 400-450 want daar proberen FritzBox hackers ook binnen te geraken

Het veiligste is zoals Tim zegt: de toegang volledig afsluiten en de VPN server gebruiken.

freakske_b schreef:Reactie van Telenet als ik vraag om het "aanvallend" ip adres te blokkeren voor inkomende connecties: ga naar de politie.

Volledig zinloos om dat aan Telenet en/of de politie te melden.
Je kan toch geen klacht gaan indienen voor iedere inkomende portscan

?
Zorg ervoor dat je veilig werkt!

Tim.Bracquez · 29 mei 2018, 13:54

freakske_b schreef:Reactie van Telenet als ik vraag om het "aanvallend" ip adres te blokkeren

Contact beter de provider, dit is online.net voor dit ip: 163.172.126.8 https://apps.db.ripe.net/db-web-ui/#/qu ... ltsSection

is één van hun dedicated server klanten, online.net neemt abuse wel serieus voor zover ik ervaar, maar hoe dan ook een ip blokkeren heeft geen zin voor dit, ze gaan gewoon vanaf een ander ip proberen. Als je een ip wilt blokkeren om dit niet meer voor te hebben voeg 0.0.0.0/0 toe, dan zit je wel safe

(niet doen)

CCatalyst · 29 mei 2018, 13:54

freakske_b schreef:Reactie van Telenet als ik vraag om het "aanvallend" ip adres te blokkeren voor inkomende connecties: ga naar de politie.

Zoiets is dan ook niet de taak van Telenet. Je betaalt hen niet voor een managed firewall dienst, enkel voor internet (en eventueel andere connectiediensten).

Tim.Bracquez schreef: is één van hun dedicated server klanten, online.net neemt abuse wel serieus voor zover ik ervaar

Veel succes

- AS12876 is al jaren een bron van allerhande malicious traffic. Is van dezelfde familie als de beruchte Poney Telecom (nuff said).

https://www.valueweb.gr/poneytelecom-eu ... g-scripts/
https://badpackets.net/ongoing-large-sc ... s-as12876/

Tim.Bracquez · 29 mei 2018, 15:03

CCatalyst schreef: Veel succes - AS12876 is al jaren een bron van allerhande malicious traffic. Is van dezelfde familie als de beruchte Poney Telecom (nuff said).

Nogthans heb ik er een hoop servers 100+ en komt er mooi abuse binnen waarje als klant binnen de 48 uur op moet reageren of je server gaat op slot ! en sturen we vaak als provider ook naar hun abuse reports en die worden effectief opgevolgd. Dit is gewoon een gigantische provider, logisch dat er veel abuse is, dat is nog altijd geen reden om niet naar hun te sturen. Zeker ook met prijzen van de servers is dit een magneet hiervoor.

Gewoon sturen en die lossen dat op, die luisteren zelfs meer naar abuse dan sommige kleine bedrijven !

Het grote probleem is bij abuse, merken we zelf ook. Blokkeren we moet ip (nullroute zelfs) een dag later via een reseller besteld die klant gewoon een nieuwe server of met andere gegevens en doen ze juist hetzelfde. Dus abuse reports heeft zin omdat het die mensen op kosten jaagt, telkens nieuwe servers en telkens nieuwe (gestolen) creditcards

(zo leer je de anti-fraude filters goed op)

CCatalyst · 29 mei 2018, 16:19

Tim.Bracquez schreef:
CCatalyst schreef: Veel succes - AS12876 is al jaren een bron van allerhande malicious traffic. Is van dezelfde familie als de beruchte Poney Telecom (nuff said).
Nogthans heb ik er een hoop servers 100+ en komt er mooi abuse binnen waarje als klant binnen de 48 uur op moet reageren of je server gaat op slot ! en sturen we vaak als provider ook naar hun abuse reports en die worden effectief opgevolgd. Dit is gewoon een gigantische provider, logisch dat er veel abuse is, dat is nog altijd geen reden om niet naar hun te sturen. Zeker ook met prijzen van de servers is dit een magneet hiervoor.

Dit verhaal klopt ergens niet. Online SAS is allesbehalve de enige grote provider. Denk maar aan Amazon AWS, DigitalOcean, Azure, en wat weet ik nog allemaal, een deel waarvan nog wel groter zullen zijn dan Online SAS en die ook zeer goedkope hosting hebben. Desondanks heeft Poney al jaren - ik overdrijf niet, u Googlet maar eens op "Poney Telecom" - een reputatie van malware/botnets/spam, en nooit lijkt dat te stoppen. Ik ken geen enkele andere grote provider waar consistent non-stop zoveel bad packets vandaan komen (toch niet in de EU/VS, China en Rusland is iets anders). Ja, je zal wel eens een scan hebben van DigitalOcean of AWS, maar nooit met het volume van Poney.

Nu, het is goed mogelijk dat het de specifieke servers niet door Online zelf verhuurd worden, maar door een reseller. Maar desondanks hebben ze ofwel 1) hun zaken niet op orde daar of 2) weten ze maar al te goed wat er gebeurt en knijpen ze een oogje dicht.

Zoals https://www.systemtek.co.uk/2017/08/blo ... elecom-eu/ zegt:

Poney Telecom is an internet server company run from France has been at the centre of multiple allegations of organised international criminal activity for a few years with all warnings, court summons and legal demands to be closed ignored.

freakske_b · 29 mei 2018, 16:34

philippe_d schreef: [*]als je toch de remote toegang wil behouden (om de FritzBox van je ouders te kunnen managen), dan moet je de standatd poort (443) wijzigen naar een ander willekeurig nummer (1-65535), maar gebruik geen poorten tussen 400-450 want daar proberen FritzBox hackers ook binnen te geraken[/list]

Dit stond reeds aangepast naar een willekeurig nummer in die range.

Tim.Bracquez · 29 mei 2018, 16:40

CCatalyst schreef: Dit verhaal klopt ergens niet. Online SAS is allesbehalve de enige grote provider. Denk maar aan Amazon AWS, DigitalOcean, Azure, en wat weet ik nog allemaal, een deel waarvan nog wel groter zullen zijn dan Online SAS en die ook zeer goedkope hosting hebben. ... Ja, je zal wel eens een scan hebben van DigitalOcean of AWS, maar nooit met het volume van Poney.

Heb niet gezegd dat ze de grootste zijn...

Ik krijg meer attacks van aws in ons netwerk binnen dan van online SAS...

Abuse buiten houden is lastig en zeker met zoveel providers die dan ook nog eens ip spoofing "toestaan"

Spijtig usual business dit, alles wat connected is

29 mei 2018, 16:44

Idem dito alhier. En OVH doet er ook goed aan door...

CCatalyst · 29 mei 2018, 16:48

freakske_b schreef: Dit stond reeds aangepast naar een willekeurig nummer in die range.

Poortnummer veranderen is meer "security through obscurity" dan een echte security-maatregel en mag dat laatste nooit vervangen. Ik raad het noch aan noch af. Zelf doe ik het niet, teveel portnummers anders

(en telkens dezelfde poort gebruiken is nogal een "signature").

Zolang je een sterk paswoord hebt dat niet in de dictionaries staat zit je goed. Fail2ban etc kan je ook gebruiken als Fritzbox dat heeft.

Tim.Bracquez schreef:
Ik krijg meer attacks van aws in ons netwerk binnen dan van online SAS...

Die ervaring heb ik niet, ik kan enkel maar bevestigen wat er oa in die NANOG post staat (waarmee ik niet zeg dat we nooit iets van AWS krijgen). Misschien krijg je wel een vertekend beeld als je zelf binnen AS12876 host, goede malware zal vermijden van binnen de eigen ASN allerhande zaken te gaan doen, want "bulletproof hosting" is enkel maar bulletproof voor abuse-reports van buitenaf, niet van binnenuit.

Het echte probleem met Poney is ook precies die "bulletproof"-reputatie, en niet zozeer die trafiek. Abuse reports lijken weinig tot niets uit te halen of worden niet goed onderzocht (hier nog enkele voorbeelden).

Tim.Bracquez · 29 mei 2018, 17:01

CCatalyst schreef: Misschien krijg je wel een vertekend beeld als je zelf binnen AS12876 host, goede malware zal vermijden van binnen de eigen ASN allerhande zaken te gaan doen, want "bulletproof hosting" is enkel maar bulletproof voor abuse-reports van buitenaf, niet van binnenuit.

Nee, we hosten niet vanuit online SAS, is gewoon puur domme storage cluster voor backups enzo. Die servers enkel vanaf enkele ip's toegankelijk zelfs

We hebben ons eigen netwerk (RIPE LIR) met meer dan 1000 actieve servers. Hoe dan ook, abuse reports moet je gewoon doen naar de provider vanwaar het komt. Meeste providers doen hier echt wel iets aan hoe je ook op het internet leest, anders staan ze op blocklists en graan je nergens meer binnen met je ip's. Hoe groter je bent hoe lastiger, hangt ook af van type klanten.

Mogelijk als je een abuse report doet als provider (geautomatiseerd hier) gebeurd er wat meer

on4bam · 29 mei 2018, 18:28

krisken schreef:Idem dito alhier. En OVH doet er ook goed aan door...

OVH is de grootste bron van spam hier. Het meeste op mijn uba adres (en aangezien de UBA lang gehost was op OVH...)

29 mei 2018, 18:46

Aha, dat e-mailadres

Tegenwoordig is de UBA elders gehost hoor, en bij iedereen zou de hoeveelheid spam serieus minder zijn sindsdien. Het valt natuurlijk te overwegen om de UBA te overtuigen om bvb spamexperts in te schakelen. Kost je iets van een 2 euro per maand per domein (!!!).

on4bam · 29 mei 2018, 19:03

krisken schreef:Tegenwoordig is de UBA elders gehost hoor

Yup.. Fusa

petrol242 · 29 mei 2018, 19:24

philippe_d schreef:...
Je kan toch geen klacht gaan indienen voor iedere inkomende portscan ?
Zorg ervoor dat je veilig werkt!

Dit is toch geen poortscan? Er is wel degelijk een login poging. Het is wel waarschijnlijk een bot, gezien de tijden tussen de pogingen. Maar klacht indien is inderdaad zinloos.

Neem de raad van Tim.Bracquez en philippe_d ter harte en doe zoals ik. Sluit de externe toegang tot de fritzdoos af en benader hem via VPN als je niet op je eigen netwerk zit.

CCatalyst · 29 mei 2018, 19:35

Waar zou de VPN server eigenlijk moeten op luisteren als de externe toegang volledig afgesloten is? Of bedoel je met externe toegang volledig afsluiten enkel de toegang tot de GUI?

Hoe vermijd je dat de VPN server zelf een attack vector wordt?

Ik weet niet in welke mate OP mee is in dit verhaal, maar ga er niet zomaar van uit dat iedereen dit goed snapt.

petrol242 · 29 mei 2018, 19:45

De externe toegang tot het admin gedeelte is afgesloten. Dat is nog iets anders dan de internet toegang tout court.

Een versleutelde VPN verbinding binnen breken is nog wel andere koek dan een een random login poging op een user/paswoord systeem, ongeacht het ip-adres al gekend is. 100% zekerheid ga je nooit krijgen, maar de je schakelt toch al een pak risico's uit.

CCatalyst · 29 mei 2018, 19:58

petrol242 schreef:Een versleutelde VPN verbinding binnen breken is nog wel andere koek dan een een random login poging op een user/paswoord systeem

Tenzij ze een random login op een user/paswoord van de VPN server proberen.

Als je bedoelt dat hij enkel geconfigureerd mag zijn voor pubkey authentication, dan geef ik je gelijk.

petrol242 · 29 mei 2018, 20:01

Het gaat hier om de VPN server op de fritzbox zelf. De fritzbox gebruikt trouwens geen openvpn maar IPSec met Xauth PSK.

Edit : De server wordt ook trouwens pas actief als er dus een authentieke gebruiker met de juiste sleutel verbinding maakt. Anders blijft het publiek nummer gewoon onbereikbaar.

29 mei 2018, 22:35

CCatalyst schreef:Poortnummer veranderen is meer "security through obscurity" dan een echte security-maatregel en mag dat laatste nooit vervangen. Ik raad het noch aan noch af. Zelf doe ik het niet, teveel portnummers anders

Absoluut niet akkoord.
Dit is een van de klassieke misvattingen van security.
"Security through obscurity" heeft wel degelijk een plaats als security-maatregel, nl de allereerste barriere.
Het mag echter nooit de *enige* security maatregel zijn.
Als je me niet gelooft, ga dan maar ns naar een bank en vraag hen wat de interne layout van hun IT netwerk is

Het is dus wel degelijk zeer nuttig om die service op een andere port te zetten; alleen moet je er dan niet de default user/pass combinatie achter runnen.

CCatalyst · 30 mei 2018, 00:06

ITnetadmin schreef: "Security through obscurity" heeft wel degelijk een plaats als security-maatregel, nl de allereerste barriere.

Het mag echter nooit de *enige* security maatregel zijn.

Is wat ik min of meer ook zei, maar ik ga niet akkoord dat het een "barriere" is. Een firewall is een barriere. Een poortnummer veranderen is geen barriere, want dat houdt niemand tegen die dat poortnummer vindt. De deur mag dan wel op een andere en niet-conventionele plaats staan, ze staat nog steeds open en iedereen die genoeg zoekt zal ze vinden en erdoor wandelen.

Het probleem met de opvatting die je zegt is dat het in de praktijk kan leiden tot oververtrouwen in security through obscurity, tot op het punt dat men het gelijk stelt aan bv een firewall, met alle gevolgen vandien. Daarom dat ik ervoor kies om erg hard de nadruk te leggen op het optionele en aanvullende karakter ervan, om te onderstrepen dat je er inderdaad niet afhankelijk van mag zijn.

Ik vind het persoonlijk zelfs beter om op de klassieke poorten te werken, want:
1) je stelt immers volledig bloot dus je bent verplicht van je security volledig in orde te hebben (geen enkele marge)
2) je kan je een idee vormen van wie of wat er allemaal aan je deur komt kloppen. IP adres, tijdstip, poort, etc is allemaal intel die je adversaries gratis en massaal aan je leveren als je op de klassieke poorten uitluistert, intel die je kan gebruiken om je beveiliging nog te verbeteren. Luister je op alternatieve poorten uit, dan ga je veel minder te weten komen. Het verschil met een firewall hierbij is dat een draaiende sshd op poort 22 nog meer info kan verzamelen, zoals gebruikte login/passwd, gebruikte ciphers, "signature" enzomeer.

Je kan natuurlijk een programmaatje schrijven dat uitluistert op poort 22 om te zien wat er allemaal binnenkomt maar geen shell kan opstarten, maar... wat als men een buffer overflow daarin vindt

plots wordt je programmaatje dan op zich weer een extra attack vector.

freakske_b · 31 mei 2018, 18:49

Ik heb remote toegang via HTTPS uitgeschakeld, alleen nog via VPN mogelijk en daarmee is het opgelost.

MaT · 31 mei 2018, 21:16

Ik zie het toch een beetje als een oplossing voor een probleem dat er niet was.
Als je geen gebruikelijke user hebt (admin,root,..), je hebt een deftig wachtwoord (een kort op niets slaand zinnetje bijv of via een wachtwoord manager) en men doet hier 1 login poging om de 17min.... dan kan men 'hacken' tot wanneer je bejaard bent, je kinderen bejaard zijn , je kleinkinderen bejaard zijn, je achterkleinkinderen bejaard zijn, enz..

antutu · 01 jun 2018, 00:07

Interessant topic. Ik lees dat er dus bots zijn die willekeurige apparaten zoeken en proberen inloggen. Ik ken wel een beetje van PC's maar op gebied ben routers ben ik een complete leek (ik kan nog nét mijn wifi wachtwoord veranderen maar verder ben ik nog niet geweest). Ik gebruik de standaard Bbox van Scarlet, zijn er stappen die ikzelf absoluut moet nemen om mezelf tegen dergelijke aanvallen te wapenen of zijn deze routers niet vanbuitenaf te bereiken?

joriz · 01 jun 2018, 10:47

Is het niet zo dat bij een BBox3 UPNP niet uit te zetten valt? Hierdoor zijn clients/services achter de BBox toch meer vulnerable doordat deze zelf portmappings kunnen opzetten, of ben ik mis?

Gray · 01 jun 2018, 11:09

antutu schreef:Interessant topic. Ik lees dat er dus bots zijn die willekeurige apparaten zoeken en proberen inloggen. Ik ken wel een beetje van PC's maar op gebied ben routers ben ik een complete leek (ik kan nog nét mijn wifi wachtwoord veranderen maar verder ben ik nog niet geweest). Ik gebruik de standaard Bbox van Scarlet, zijn er stappen die ikzelf absoluut moet nemen om mezelf tegen dergelijke aanvallen te wapenen of zijn deze routers niet vanbuitenaf te bereiken?

Gebeurt ontzettend vaak, deze bronnen scannen het volledige internet af, gaan op zoek naar toestellen die interessant zijn (dikwijls routers waarvan men kan inloggen vanaf het internet) en dan gaan ze de default en wat veelvoorkomende paswoorden gebruiken om daarop aan te loggen.
Lukt dit, dan gaan ze weer een stapje verder en worden er "aanvallen" gelanceerd vanaf jouw router en internet (onder jouw naam).

Zoiets gebeurd ook "en masse" en volledig automatisch, het beeld van de zweterige puisten-nerd-"hacker" die het speciaal op jouw routertje heeft gemunt klopt dus helemaal niet.

Dat is overigens het voordeel dat de standaard provider routers wel hebben, deze zijn nu voldoende beveiligd itt de leek met een eigen router.

CCatalyst · 01 jun 2018, 11:20

MaT schreef:Ik zie het toch een beetje als een oplossing voor een probleem dat er niet was.

Akkoord.

Ik vrees ook voor valse gemoedsrust. Het is niet omdat de logs niets meer tonen, dat men niet blijft proberen van buitenaf.

Maar soit, OP doet ermee wat hij wilt. Zo lang er maar geen "DRINGEND - iemand zit in mijn netwerk" vervolgtopic komt.

Gray schreef: Dat is overigens het voordeel dat de standaard provider routers wel hebben, deze zijn nu voldoende beveiligd itt de leek met een eigen router.

https://www.routersecurity.org/ISProuters.php

Gray · 01 jun 2018, 11:30

akkoord, maar het omgekeerde, elke leek een eigen willekeurige router laten beheren is nog veel slechter kwa security.
Nu worden de routers beheerd door de provider, en tot scha en schande

, gebeurd dit nu toch al wat beter dan in het begin. Is er een ernstige vulnerability wordt dit gepatched.

Kun je het als security freak veiliger met je eigen router? Vast wel, maar 99,9% van de bevolking kan dit niet (of is er gewoon te lui voor

)

01 jun 2018, 18:03

De toekomstige miserie zit hem toch in de IoT devices, die zelf portmappings zullen maken en nooit gepatched zullen worden.