Userbase

doas/sudo vi /etc/hosts
79.132.231.171 userbase.be
79.132.231.171 http://www.userbase.be
<esc>:wq
reboot

Geen Cloudflare meer

Zal dat inderdaad even op de router zo moeten doen dan

JamesEarlGray: Zucht, cloudflare handeld reeds al enkele js libraries van userbase af, dus vrees als je dit had gepost omdat je cloudflare niet wou gebruiken dat je eigenlijk toch al een beetje via hun verkeer (userbase) aan het sturen was.

PS een social media account zou ik dan zeker niet gebruiken

Cloudflare kan als full firewall dienen op layer 7, eigenlijk het lastigste en meest kostelijke om te filteren / verwerken.

Hier blokkeer ik op meerdere sites al het directe verkeer, omdat anders attackers er anders gewoon rond kunnen...

https://support.cloudflare.com/hc/en-us ... -iptables-


BTW: load time van 5 sec op new post Page is nu naar 2 sec met cloudflare https://tools.pingdom.com/ zelfde moment getest, ene keer via CF en andere keer direct, dus doet zijn werk...

Mooi!

Alle vooruit, sinds cloudflare, werkt dit niet meer:

http://userbase.be/services/ip

Ik gebruik dat om te zien of mijn VPN verbinding goed zit. Ik weet dat ik hiervoor ook nog andere services op inet kan gebruiken, maar toch, ik vond het handig.
Kan dit gefixed worden aub?

Tim.Bracquez schreef:JamesEarlGray: Zucht, cloudflare handeld reeds al enkele js libraries van userbase af, dus vrees als je dit had gepost omdat je cloudflare niet wou gebruiken dat je eigenlijk toch al een beetje via hun verkeer (userbase) aan het sturen was.

Klopt en die scripts worden hier mooi consequent geblokkeerd door mijn default block list in ublock origin. ¯\_(ツ)_/¯ Dus da's geen argument voor mij.

JamesEarlGray schreef:Dus ja, als ik niet wil dat Cloudflare mijn wachtwoord kan zien, kan ik helaas geen gebruik meer maken van UB zo lang die enkel bereikbaar is via Cloudflare.

ook wegblijven van youtube, quasi alle google diensten en online streaming dan, want die gebruiken bijna allemaal cloudflare/akamai

Nob schreef:Alle vooruit, sinds cloudflare, werkt dit niet meer:

http://userbase.be/services/ip

lijkt niks met cloudflare te maken hebben, maar met dat de php versie geupdate (of config aangepast) is

@JamesEarlGray: Oei, dan werkt half het internet niet meer als je CF blocked

Is het volgende https?

Nob schreef:Alle vooruit, sinds cloudflare, werkt dit niet meer:

http://userbase.be/services/ip

Ik gebruik dat om te zien of mijn VPN verbinding goed zit. Ik weet dat ik hiervoor ook nog andere services op inet kan gebruiken, maar toch, ik vond het handig.
Kan dit gefixed worden aub?

Idem, gebruik die pagina om dezelfde reden ook vaak.

Als ik surf naar 79.132.xxx krijg ik trouwens steeds alleen maar de onderhoudspagina te zien...

Splitter schreef:
lijkt niks met cloudflare te maken hebben, maar met dat de php versie geupdate (of config aangepast) is

Toch wel, als je CF gebruikt haal je het IP van de client niet meer uit de gebruikelijke header maar wel uit HTTP_CF_CONNECTING_IP of zoiets.

Zou me niet verwonderen dat alle posts hier momenteel trouwens ook met het IP van een CF CDN server gelogd worden

Enige dat ik ook niet snap is waarom hij een PHP error krijgt, want REMOTE_ADDR zou toch beschikbaar moeten zijn (weliswaar met het IP van de CF CDN server), maar 'k ga daar niet wakker van liggen.

@dev: als je dit aanpast, niet zomaar REMOTE_ADDR vervangen door de CF header, wel testen voor de aanwezigheid van de CF header en dan pas substitueren

NuKeM schreef:
Als ik surf naar 79.132.xxx krijg ik trouwens steeds alleen maar de onderhoudspagina te zien...

Gewoon naar http://79.132.xxx surfen gaat idd niet werken omdat je ook een Host: userbase.be header moet sturen. Tenzij je dit manueel in je browser kunt forceren is de beste aanpak daarom via /etc/hosts. Dan surf je naar userbase.be die resolved naar 79.132.xxx en zal je browser die Host: header er ook op plakken.

Zonet eens getest en de IP lookup pagina werkt als je dit correct doet.

CCatalyst schreef:Zou me niet verwonderen dat alle posts hier momenteel trouwens ook met het IP van een CF CDN server gelogd worden

Dit lijkt inderdaad het geval bij een snelle check...

Na toevoegen van een domain override in mijn DNS resolver (pfsense) werkt userbase weer als voorheen

NuKeM schreef:

CCatalyst schreef:Zou me niet verwonderen dat alle posts hier momenteel trouwens ook met het IP van een CF CDN server gelogd worden

Dit lijkt inderdaad het geval bij een snelle check...

Na toevoegen van een domain override in mijn DNS resolver (pfsense) werkt userbase weer als voorheen

Dwz, traag?

Sent from my ONEPLUS A6003 using Tapatalk

Gewoon vlot, zonder derde partij ertussen Je weet wel, zoals het hoort

Het belangrijkste is dat die robots de "nieuwe" versie gebruiken hé .

**

Willen jullie https://userbase.be/services/ip2 eens testen op betrouwbaarheid aub? (ik had overigens niet plots ook IPv6-support verwacht)

Ok voor mij

Klopt bij mij ook.

Tim.Bracquez schreef:Toch slim dat jullie allemaal het ip van de server extra hier posten zodat bots die gewoon ook volgen.

Als je puur het IP volgt zonder Host header (wat bots zullen doen) dan kom je op een statische maintenance pagina uit die volgens mij niets van php inlaadt op de server. Dat zal wel niet resulteren in algemene traagheid.

meon schreef: (ik had overigens niet plots ook IPv6-support verwacht)

Jup userbase is full IPv6 nu, toch geweldig....

Bots passen wel headers aan, sorry maar we zitten in 2019... Bots zijn er wel op vooruit gegaan en passen heel wat header info aan om zo resultaten te krijgen die voor hun nuttig zijn, first hand experience in...

Je hebt zelfs speciaal tools om ip's te achterhalen van CF hosts en layer 7 attacks te sturen

Voor de mensen die paranoia zijn voor CF want us bedrijf, en je toch ddos / ssl wil offloaden.

https://www.ovh.nl/ssl-gateway/

Ook gratis wel beperkter, geen shared ssl denk letsencrypt met enkel eigen domeinen er in.

**

Ze gebruiken idd Cisco en Arista voor hun switching / routing. Die ssl oplossing gebruikt ondermeer haproxy etc.

Maar dat is het geval voor iedere provider, Alcatel / Cisco etc bij Proximus, Juniper etc bij Telenet kijk als je interessant genoeg bent kan je alles en iedereen afluisteren. Ofwel ga je encrypted op zo'n level end 2 end, ofwel knip je iedere kabel door en ga je in een bunker wonen zo diep onder de grond. De vraag is of je interessant genoeg bent om zoveel energie in te steken om je af te luisteren. Hier op userbase gebeurd niets wat ik me kan inbeelden dat een opsporings / veiligheidsdienst interessant kan vinden.

meon schreef:Willen jullie https://userbase.be/services/ip2 eens testen op betrouwbaarheid aub? (ik had overigens niet plots ook IPv6-support verwacht)

Werkt! Merci!

Werkt (IPv6)
Proximus Start, Fritz!Box.

meon schreef:Willen jullie https://userbase.be/services/ip2 eens testen op betrouwbaarheid aub? (ik had overigens niet plots ook IPv6-support verwacht)

Works! (getest op Orange, MV, Proximus)

Tim.Bracquez schreef:En stop aub met te freaken dat je data door CF gaat, ik denk dat een Proximus met al zijn vaste taps onveiliger is dan... Je zou eens moeten weten... Of Telenet die actief alle data filtert...

Erge is dan nog eens dat de meesten dat zich hierover zorgen maken gewoon op facebook en/of andere social media zit waarbij de app gewoon permanent overal toegang heeft en ook gebruikt wordt.

Tomsworld schreef:Maar dat is het geval voor iedere provider, Alcatel / Cisco etc bij Proximus, Juniper etc bij Telenet kijk als je interessant genoeg bent kan je alles en iedereen afluisteren. Ofwel ga je encrypted op zo'n level end 2 end, ofwel knip je iedere kabel door en ga je in een bunker wonen zo diep onder de grond. De vraag is of je interessant genoeg bent om zoveel energie in te steken om je af te luisteren. Hier op userbase gebeurd niets wat ik me kan inbeelden dat een opsporings / veiligheidsdienst interessant kan vinden.

Spijtig dat mijn streven naar meer privacy en minder delen van gegevens met elk bedrijf dat het maar probeert direct de mond wordt gesnoerd met dooddoeners en afgedaan als belachelijk.

Het is toch niet omdat ik graag heb dat er zo weinig mogelijk derde partijen mee kunnen luisteren naar het verkeer tussen mij en mijn bestemmeling (in dit geval userbase.be) dat ik daarom maar meteen moet aanvaarden dat iedereen dat kan én mag of dat ik anders maar in een grot moet wonen? Jezus!

Stel u voor dat de klimaatcrisis met dezelfde zwartwit-retoriek zou worden behandeld, het zou schoon zijn.

Ofschoon het mogelijk is dat men mij via firmware backdoors van cisco of andere merken kan afluisteren, wilt niet zeggen dat ik niet mag streven naar een beperkte blootstelling van mijn gegevens, wanneer die intrinsiek privaat kunnen beschouwd worden en enkel horen inzichtelijk te zijn door de eerste en tweede partij en dat in principe geen enkele derde partij daar zaken mee heeft.

En als dooddoeners wél mogen in deze discussie, waarom geven jullie mij niet direct alle wachtwoorden van al jullie accounts bij elke service of apparaat dan ook? Het maakt blijkbaar toch niet uit, toch?

@mods: misschien moeten we even een afsplitsing maken van dit topic? Kwestie van de traagheid van UB vs privacy toch even uit elkaar te houden.

Ik denk dat iedereen die antwoordde op je post “ik wil geen CF” bedoelde dat je nergens aangaf dat je nu ook al geen CF wou, door bijvoorbeeld je config van je firewall te posten of iets dergelijks, of een beetje meer uitleg gaf. Nu komt het een beetje raar over, omdat je voor 7 van de 10 websites die je bezoekt tóch al CF gebruikt.

Ook hier werkt script. Zie netjes mijn IP van thuis verschijnen waar ik via VPN mee verbonden ben.

Tim.Bracquez schreef: Bots passen wel headers aan, sorry maar we zitten in 2019... Bots zijn er wel op vooruit gegaan en passen heel wat header info aan om zo resultaten te krijgen die voor hun nuttig zijn, first hand experience in...

Ik eet mijn hoed op bij de eerste bot die puur op basis van de info in deze topic het IP van Userbase gaat bombarderen met Host headers om de PHP interpreter te activeren en de site plat te krijgen.

UB ligt niet (nog) onder vuur door nation-state actors he...

Ik zeg dit met een reden, bots die naar advertenties zoeken doen niet anders omdat concurrentie vaak dingen verbergt voor bepaalde ranges of aangepaste advertenties toont. En ja zelfs op UB zijn die al langs gekomen, kan ik je met zekerheid vertellen aangezien ik meerdere clusters onderhoud(server beheer) voor klanten die dit 24/7 doen... Deze proberen gewoon alle combinaties wat ze vinden vanaf meerdere bronnen. Ze zijn creatief

Het huidige probleem was gewoon een bot die de site niet plat wou leggen, maar gewoon beetje meer aan het zoeken was dan wat de server aankon. Blijkbaar heeft CF er voor dit opgelost.

meon schreef:Willen jullie https://userbase.be/services/ip2 eens testen op betrouwbaarheid aub? (ik had overigens niet plots ook IPv6-support verwacht)

Is het volgende always-on-https en hsts? Nu merk ik dat bvb dit topic niet volledig over https loopt...

Op CF onder SSL deze op "Full SSL" zetten minimaal

Full SSL: Your origin supports HTTPS, but the certificate installed does not match your domain or is self-signed. Cloudflare will connect to your origin over HTTPS, but will not validate the certificate.

Full (strict): Your origin has a valid certificate (not expired and signed by a trusted CA or Cloudflare Origin CA) installed. Cloudflare will connect over HTTPS and verify the cert on each request.

en "Automatic HTTPS Rewrites" opzetten

Automatic HTTPS Rewrites helps fix mixed content by changing “http” to “https” for all resources or links on your web site that can be served with HTTPS.

En eventueel: "Always Use HTTPS" aanzetten

Redirect all requests with scheme “http” to “https”. This applies to all http requests to the zone.

Converted schreef:Is het volgende always-on-https en hsts? Nu merk ik dat bvb dit topic niet volledig over https loopt...

Ik wilde niet elke optie ineens inschakelen , kwestie van als er iets fout loopt te kunnen zeggen op welk component.
In de statistieken van cloudflare kan ik zien dat nu 2/3e van de requests gecached wordt afgeleverd en zo' n 1/4e van de data. Ook al 59 'attacks' tegen gehouden, maar snap nog niet goed welke dat dan zijn...

Nu is het kwestie van bovenstaande in te schakelen:) @Tim.Bracquez

meon schreef:Willen jullie https://userbase.be/services/ip2 eens testen op betrouwbaarheid aub? (ik had overigens niet plots ook IPv6-support verwacht)

Vermits het werkt, kan dit dan in het menu gezet worden ipv de link die niet meer werkt?

meon schreef:

Converted schreef:Is het volgende always-on-https en hsts? Nu merk ik dat bvb dit topic niet volledig over https loopt...

Ik wilde niet elke optie ineens inschakelen , kwestie van als er iets fout loopt te kunnen zeggen op welk component.
In de statistieken van cloudflare kan ik zien dat nu 2/3e van de requests gecached wordt afgeleverd en zo' n 1/4e van de data. Ook al 59 'attacks' tegen gehouden, maar snap nog niet goed welke dat dan zijn...

Maak jij https dan ook in orde zoals @Tim.Bracquez heeft beschreven in zijn post?

selder schreef:Ik denk dat iedereen die antwoordde op je post “ik wil geen CF” bedoelde dat je nergens aangaf dat je nu ook al geen CF wou, door bijvoorbeeld je config van je firewall te posten of iets dergelijks, of een beetje meer uitleg gaf. Nu komt het een beetje raar over, omdat je voor 7 van de 10 websites die je bezoekt tóch al CF gebruikt.

Tuurlijk wil ik geen MITM die persoonlijk identificeerbare informatie kan onderscheppen en gewoon uitlezen, inclusief het wachtwoord van mijn account op de website in kwestie.

Ik weet heus wel dat cloudflare door andere websites wordt gebruikt, maar dat aanvaard ik maar, omdat 1/ ik er niet bij was toen ze die overstap hebben gemaakt, en 2/ ik geen persoonlijk identificeerbare informatie verstuur naar die websites; ik gebruik die eerder voornamelijk om te queryen naar videos en dergelijke.

Waar ik het hier specifiek over heb is cloudflare als reverse proxy gebruiken, niet als CDN voor javascript libs. Die javascripts libs requests kan ik blokkeren in uBlock Origin of vervangen door Decentraleyes, maar een reverse proxy valt niet te omzeilen behalve dan misschien door het IP-adres van de server (als die al rechtstreeks toegankelijk is via internet) in steen te beitelen in mijn hosts file, wat een irritant maar gelukkig eenmalig werkje is voor elk van mijn apparaten.

Over dat cloudflare of akamai door YouTube worden gebruikt: ik denk echt niet dat Google het aan die diensten toelaat om een login+pw te onderscheppen, dat gebeurt mooi via omleiding naar account.google.com en eventueel OAuth als het om een derde partij gaat, maar nooit de volledige login+pw.

Soit, als jullie graag willen dat Cloudflare je wachtwoord van UB in plaintext ontvangt, wees mijn gast, maar ik wil het niet en bij deze heb ik het ook gezegd.