Netwerk verkeer forwarden van clients via homeserver

[jb044]

Mijn vraag

Ben bezig om squid als transparante proxy in te zetten en daarvoor is het nodig dat verkeer via de homeserver gaat. Gebruik nu op die server AlmaLinux 9.5 met de standaard firewalld firewall en het liefst hou ik dat zo. Dus de vraag is: hoe stel je firewalld zo in dat ie het toestaat dat verkeer geforward wordt? Als ik het goed heb is masquerading niet eens nodig: clients hebben 192.168.178.x de server 192.168.178.46, de server heeft slechts 1 netwerk interface.

Relevante software en hardware die ik gebruik

- AlmaLinux 9.5
- firewalld
- uiteraard is iptables ook gewoon aanwezig

Wat ik al gevonden of geprobeerd heb

- iptables rules aanmaken voor forwarding: timeouts op de client als ik de server als gateway instel.
- een firewalld policy aangemnaakt met ingress zone internal en egress zone public, eveneens timeouts op de client met de server als gateway.

Uiteraard kan ik meer info geven, maar wou het voor nu zo overzihtelijk mogelijk houden

[Hero of Time]

Een gateway is om naar andere subnetten te kunnen, zoals het internet. Een Proxy is geen gateway, een proxy is een doorgeefluik dat namens clients online resources benadert en zaken kan cachen om minder bandbreedte te gebruiken. Maar alleen voor web zaken. Je kan bijvoorbeeld niet een proxy gebruiken om een SMB share te benaderen die in een ander netwerk staat.

Je moet dus niet in je IP configuratie de proxy server als gateway instellen. Je moet in de browser het adres van de proxy en de poort waarop deze luistert opgeven.

[jb044]

In dit geval gaat het om squid in intercepting mode, verkeer naar poort 443 en 80 wordt dan doorgestuurd naar squid en door squid afgehandeld. Squid was meer ter referentie bedoeld, mijn probleem is dat forwarding op de server kennelijk door firewalld wordt tegengehouden. Het gaat dus wel om routering van verkeer via een gateway.

Dus de concrete vraag is hoe pas je met Linux firewalld aan dat forwarding van iig ipv4 is toegestaan en het liefst natuurlijk alleen voor het bronnetwerk dat ik wil routeren (is dat correct Nederlands? ). Snap dat je in het geval van een gateway/router meestal 2 netwerk interfaces hebt, maar dat is hier dus niet zo. Ik hoop dat dit met Linux mogelijk is en bij voorkeur met firewalld want dat bevalt me buiten dit verder prima, het doet wat het moet doen en aanpassen van bv een toegestane poort is makkelijk en gebruiksvriendelijk.

Ik zag online wat voorbeelden van een firewalld policy met daarbij een ingress (inkomende) zone en een egress (uitgaande) zone, maar dat werkte niet en het voorbeeld was voor 2 netwerk interfaces.

[Hero of Time]

In dat geval verwijs ik je naar een stuk documentatie: https://wiki.squid-cache.org/SquidFaq/InterceptionProxy.

There are also significant disadvantages for this strategy, as outlined by Mark Elsen:

• Intercepting HTTP breaks TCP/IP standards because user agents think they are talking directly to the origin server.
• Requires IPv4 with NAT on most operating systems, although some now support TPROXY or NAT for IPv6 as well.
...
• Interception Caching only supports the HTTP protocol, not gopher, SSL, or FTP. You cannot setup a redirection-rule to the proxy server for other protocols other than HTTP since the client will not know how to deal with it.

En:

Requirements and methods for Interception Caching

• You need to have a good understanding of what you are doing before you start. This involves understanding at a TCP layer what is happening to the connections.

Er zitten dus nogal wat haken en ogen aan en je moet een heel specifieke reden hebben om dit te gaan gebruiken, want het is zeker geen normale setup. Ook lettende op het feit dat het niet met HTTPS werkt en zo'n beetje alle sites tegenwoordig SSL gebruiken, gaat het sowieso niet veel doen.

[jb044]

Och, ook squid ontwikkelt zich nog steeds. Heb al meerdere voorbeelden gezien van mensen die het wel degelijk werkend hebben met een meer courante versie van squid. Wat het in mijn geval kennelijk nogal moeilijk maakt is dat de geintercepten en de interceptende (nogmaals is dit correct Nederlands ) in hetzelfde subnet zitten, en het lijkt erop dat dat ervoor zorgt dat squid in een loop terecht komt met standaard iptables masq rules.

Aniewees, dat was allemaal mijn vraag niet. Het ging simpelweg om firewalld en hoe je daarmee een server als gateway laat fungeren in een enkel subnet. Was even vergeten dat we in bijzondere tijden leven, dus ik heb het gewoon aan de Warp terminal gevraagd. Hij moest even nadenken en spoot toen commando's uit, toegegeven het ging niet allemaal in 1x goed maar hij corrigeerde dit gelijk door --help vlaggetjes aan commando's toe te voegen om te achterhalen welke variant van zijn probeersel wel zouden werken.

En tada het werkte. Ik denk dat ik al warm zat en hooguit een 'accept' aan de firewalld had moeten toevoegen. Dat en traceroute moest nog wat extra regels hebben voordat het werkte. Maar daarna kon ik duidelijk zien dat een traceroute naar tweakers.net via mijn mac door mijn server ging en de isp router als 2e hop had.

Is het allemaal zo simpel? Nou nee, squid is de 3e stap, 2e stap is nu om fatsoenlijk internet via de server te realiseren want kennelijk moet je met zo'n firewalld policy alles expliciet toestaan. Maar eerst is het tijd voor mijn bedje.

Sorry dat ik het hier vroeg, zelfredzaamheid en AI zijn kennelijk betere opties!

[jb044]

Ok dat was een reactie gevoed door het moment Al vind ik het wel verbazingwekkend hoe goed zoiets als de Warp terminal kan werken in de praktijk!

Uiteindelijk besloten dat dit een heiloze weg was. Denk dat deze oplossing meer geschikt is voor grootschalige bedrijfsnetwerken waar het niet erg is dat het nogal wat specialistische kennis vereist. Er waren 2 grote opstakels: DNAT was kennelijk niet goed genoeg, zeker niet als je ook ipv6 wilt gebruiken. Kennelijk kom je dan uit op TPROXY wat zoals ik begrijp een onderwerp is waar je beter eerst een goed en dik boek over kunt lezen. En 2 mijn eenvoudige frtizbox gaat het niet ondersteunen om andere gateways voor dhcp in te stellen dus ik zou ook nog een nieuwe dhcp server nodig hebben. Best wel overkill allemaal voor een beschieden thuis netwerk!

En het belangrijkste: het probleem waar het allemaal mee begon zou ik er niet mee oplossen. Dat bleek dus te zijn dat bepaalde software op OSX en Android kennelijk niet gebruik maakt van een eigen cert dat je in de cert store van het OS opslaat. De melding was erg cryptisch maar het kwam gewoon neer op "invalid cert, connection aborted'. Dus squid weer gewoon als proxy ingesteld en de access log wat nauwgezetter in de hgaten gehouden. Tot nu toe gevonden:
- com.android.gms
- verbindingen naar icloud.com
- twitter

Meldingen in cache.log zijn al een stuk minder geworden en de komende tijd maar eens rustig aan kijken wat ik nog meer kan vinden. Voorlopig gaat 90+% van mijn web verkeer gewoon prima via squid en dat was het idee:

- pihole + unbound via proton vpn
- squid via proton vpn
- rest van de server gewoon rechtstreeks via mijn isp

Dus ik heb en controle over hoe het allemaal werkt en privacy maar ook de flexibiliteit om zelf servers te ontsluiten, dus voorlopig ben ik tevreden over het resultaat

[Hero of Time]

Dat DHCP server stukje is dan nog wel het eenvoudigste om op te lossen. Op je Fritzbox uitzetten en op je Squid server installeren en configureren. Een DHCP server vraagt echt geen drol aan resources, een smartphone van >10 jaar oud doet dat nog met twee vingers in de neus. Sterker nog, met Pi-Hole heb je al een alternatieve DHCP server beschikbaar!

Maar een interception proxy is, zoals m'n link al aangaf, een compleet ander beest dan een normale proxy server voor internet. Dat laatste is veel eenvoudiger te configureren en vereist aanzienlijk minder kennis van netwerken, zoals m'n tweede quote eerder al aangaf.

[ Voor 6% gewijzigd door Hero of Time op 29-03-2025 19:20 ]

[jb044]

Ja daar zeg je wat, de pi-hole dhcp server, ik haakte iig een beetje af toen ik bij TPROXY aankwam. Kwam erg complex over. En zoals ik al probeerde aan te geven, de problemen die ik nu ervaar hebben te maken met apps die mijn extra squid cert kennelijk niet oppikken terwijl ze dat eigenlijk wel zouden moeten doen. Dus dan is het alleen maar fijn dat het om een reguliere proxy gaat die je makkelijk aan of uit kan zetten en niet een 'stiekeme' proxy die helemaal transparant in het netwerk is opgenomen.

[jb044]

Enne, voor potentiele meelezers: "Ook lettende op het feit dat het niet met HTTPS werkt en zo'n beetje alle sites tegenwoordig SSL gebruiken, gaat het sowieso niet veel doen."

Dit is dus gewoon niet waar, squid heeft al een hele tijd ssl bumping, dit werkt gewoon en is ook stabiel. Je komt in het wild hooguit enkele sites tegen waar het niet werkt, of waar je dit wellicht niet zou willen, je bank bv

Het enige dat je nodig hebt is een self signed CA die je in je OS cert chain importeerd en als het om een gedeeld netwerk gaat: het fatsoen om er wel transparant over te zijn! Het is immers een "man in the middle" ssl hack.

[Hero of Time]

Dat is inderdaad het punt, dat het een MitM in feite is en sites waar HSTS aan staat, wat dus extra certificaatvalidatie doet, valt zo'n aanval gelijk in het water en wordt de verbinding afgebroken en krijg je een foutmelding te zien erover. Veel sites hebben niet die moeite genomen, maar gevoelige zaken zoals je bank en overheid doen dat wel.

Ik zie het op ons werk ook, onze anti-virus kan ook certificaten nadoen en voor elke site waar je het certificaat van bekijkt in de browser, is de uitgever de AV. Wel met de datums van het oorspronkelijke cert.

[jb044]

Waar heb jij het over?

Alleen sites als ssllabs detecteren dat er iets 'off' is en ik gok dat dat ook alleen maar is omdat squid nette software is. Https is echt alleen veilig als jij de volledige controle over je device hebt. Net zoals dat slotje alleen weinig zegt. In het voorbeeld van mijn bank: ik wil daar een extended ssl cert zien, waarbij dus ook met grote zekerheid te zeggen is dat $bank ook echt die bank is. Met een self signed ssl cert daar tussen kan ik dat dus niet, maar niets let mij om het wel te doen.

[jb044]

Ook op ssllabs moet ik terugkomen: dat was omdat ik de Mozilla aanbevolen config voor squid gebruik om veilige ssl al bij squid af te dwingen, ook als de client het allemaal prima zou vinden. Kennelijk triggered dat wat bij hun test (al was het geen rode knipperende waarschuwing, maar gewoon een melding). Zonder dat ik ciphers en protocollen blacklist verdwijnt ook die melding.

In dit geval niets dan goede bedoelingen en ben ik zelf de testcase .... maar geloof me als iemand je zo gek kan krijgen om een willekeurige CA te installeren ben je goed de sjaak!

[Hero of Time]

jb044 schreef op zaterdag 29 maart 2025 @ 23:10:
Waar heb jij het over?[Afbeelding]

Kijk eens heel goed naar wat je daar toont. Dat is juist jouw eigen CA die zich voordoet als Tweakers. Want de uitgever hoort DigiCert te zijn. Bij jouw is het geen onderdeel van het certificaat. Het SAN ontbreekt, de fingerprints komen niet overeen en alle overige extended informatie van het certificaat ontbreekt.

Dat is ook gelijk de reden waarom je bij SSLLabs die melding krijgt dat er iets niet klopt. Er wordt alleen het primaire domein of common name nagedaan, maar niks van de subject alt names.

Je valt mij nu weer aan alsof ik niet weet waar ik het over heb. Waarom doe je dat? Is waar je nu mee bezig bent onderdeel van je werk, of doe je dit puur voor de lol?

[jb044]

Ik weet niet of je niet weet waar je het over hebt, ik ken je niet. Wel val ik erover dat je op een concrete vraag gaat uitleggen dat een proxy niet hetzelfde is als een gateway. Dat is behoorlijk aanmatigend, alsof het fiet dat ik een vraag stel mij een clueless prutser maakt!

Ook verdraai je steeds zaken, ik krijg een melding op ssllabs als ik een wat een stricte ssl config in squid afdwing, als ik dat uitzet: louter groene vinkjes. Wat squid doet betreft louter het verkeer tussen client en squid, verder is er een reguliere ssl connectie tussen squid en de doelserver. Het is vast mogelijk om bv met client side js alsnog te detecteren dat er iets niet in de haak is, maar standaard zullen er geen alarmbellen afgaan. Dat maakt het ook wat spooky. En ja ik doe dit puur voor de lol op mijn eigen netwerk en mensen afluisteren speelt in dit geval geen rol van betekenis. Maar al met al krijg ik wel een goed beeld van hoe het er ongetwijfeld in grootschalige corporated netwerken aan toegaat, erg leerzaam!

Het maakt mij verder niet uit hoor, maar ik krijg wel de indruk dat je geloofd dat dit alles niet mogelijk is en dat je alles wat het tegendeel aantoont dan maar terzijde schuift, wel bijzonder

[lordgandalf]

HSTS staat welke ca providers je website accepteerd aka dit zijn mijn ssl providers als je een andere provider ziet dan accepteer dit niet. dus als je zo eens site in jouw transparante proxy bekijkt checkt de webbrowser of jouw CA voorkomt op de lijst en dat is niet het geval dus blok. En kom je dus niet op de site.

Leesvoer: https://www.ssl.com/nl/di...-transport-security-hsts/

[jb044]

Ja, ik loop er nu nog tegenaan dat sommige apps op OSX en Android kennelijk verifiieren dat de cert hash overeenkomt met wat zij verwachten, dus die splice ik expliciet in squid. Dan werkt het weer.

In de browser nog geen problemen gehad, niet op OSX, niet op Android en ook niet op Linux.

[jb044]

Ik snap overigens de link met een MIM oplossing als squid en HSTS niet, squid kan gewoon een https verbinding overnemen, het is niet vereist dat er eerst een http verbinding wordt gemaakt die vervolgens geupgrade wordt. Natuurlijk moet je wel de squid CA in je cert chain hebben opgenomen anders werkt het niet. Dus toepassingen zijn beperkt tot consensus en bedrijfssituaties waarin je geen controle hebt over devices.

Wel deze gevonden: Wikipedia: HTTP Public Key Pinning wat obsolete is. Loop er dus wel tegenaan dat mobile apps en ook OSX apps dit dus nog steeds doen. In dat geval biedt squid je de optie om selectief domeinen niet te 'bumpen' maar te 'splicen', oftewel de aanvankelijke connectie wordt nog steeds geinspecteerd dus je ziet wel domeinen langskomen in je logs maar de rest van de connectie wordt met rust gelaten dus daar zie je verder niks van.

[djmuggs]

Een transparante proxy naar een niet SSL website is heel makkelijk, dat werkt gewoon out of the box.

Maar de betrouwbare websites en online diensten gebruiken SSL(HTTPS) intussen, dus het lastige is hoe laat ik al aan mijn devices op mijn netwerk via transparante proxy (SSL) vertrouwd een https verbinding opzetten?
Dan krijg je een soort van MITM oplossing, de makkelijkste weg is je eigen CA aan alle devices toevoegen.
Maar hoe doe je dat met devices die niet van jou zijn?

Hoop organisaties gebruiken een transparante proxy voor netwerk inspectie, dus je kan mee kijken met de gebruiker ook al is het SSL verkeer.
Maar dit zijn dan vaak managed devices, dus je eigen CA toevoegen is dan makkelijk.

Ik heb ook situaties gezien waar een transparante proxy voor onverwacht gedrag zorgt waardoor bepaalde SSL toepassingen niet meer werken.

Simpel gezegd, een transparante proxy en afhankelijk van de SSL toepassing heeft een hoop uitdagingen welke een hoop tijd en effort vragen om te onderhouden.
Dus weet waar je aan begint.

Ohwjah, de TLS 1.3 standaard maakt het nog iets moeilijker om toe te passen.

[ Voor 3% gewijzigd door djmuggs op 31-03-2025 20:47 ]

[jb044]

Thx voor je behulpzame antwoord! Bij de rest krijg ik het gevoel dat ik op iets heel kleins heb gestapt en het ruikt ook erg naar spruitjes, dat gaat echt helemaal nergens over .... en ja ook de wat vreemde optie om een router te maken met maar 1 netwerk interface had ik met hulp van Warp terminal AI in 10 seconden werkend, het vervolg squid niet zozeer Maakt ook niet uit want dat wou ik ook liever niet. Squid als reguliere en zichtbare proxy is voor mijn toepassing prima.

Heb nog geen problemen met TLS 1.3 gehad maar wellicht komt dat nog dan. Nee waar het allemaal mee begon was een nogal cryptische melding van squid die later bleek in te houden dat sommige apps de checksum van het server cert voor een domein checken en dus niet akkoord gaan met mijn surrogaat, of de ca daarvoor nou in de keychain zit of niet dus. Dus die domeinen stuur ik gewoon direct door met squid en dan werkt het weer gewoon. De wat grote apps dus, Facebook, LinkedIn etc.

[jb044]

Nog een voordeel van een reguliere proxy: heb nu een simpele proxy.pac gemaakt zodat ik in browsers die dat ondersteunen transparant .onion adressen kan doorsturen naar een tor proxy.

En kwam nog een leuke tegen, had wat liefde en aandacht nodig maar werkt ook nog:

https://squid-users.squid...voked-server-certificates

Je kan ervoor zorgen dat squid extra checks op certificaten doet zodat je voorkomt dat je juist niets doorhebt als er toch wat loos is (Diginotar anybody!), deze: https://revoked.grc.com laadt bijvoorbeeld wel in mijn chrome en Vivaldi maar niet in Firefox.

[ Voor 3% gewijzigd door jb044 op 01-04-2025 00:44 ]

[lordgandalf]

het ding is gewoon als je de verbinding niet gewoon 1-op-1 doorlaat zoals je nu aangeeft maar als je heb onderbreekt dat je dan op dingen als bank websites tegen HSTS aanloopt. Maar dat is in jouw geval dus niet van toepassing aangezien je de verbindingen niet afbreekt.

[jb044]

Kom hier niet om te wellis/nietissen, maar Vrees dat iig de ING er niet veel van bakt, dat ik dat niet wens en dus bewust geen MIM toepas op mijn connecties met die bank doet er verder niet zo veel toe. In de browser is het misschien ook lastig, geen idee of iets als DANE actief gecheckt wordt door courante browsers maar bij de ING heb je doorgaans de app nodig om te kunnen inloggen en die zou juist vrij makkelijk beschermd kunnen worden. Zoals ik al eerder heb aangegeven heb ik wel problemen met Android appjes die mijn squid MIM constructie niet slikken. Ofwel gebruiken zij de User cert store van Android niet, ofwel gebruiken zij wel DANE ofwel hebben ze simpelweg een signature van hun domein certificaten ingebakken. Ze trappen er gewoon niet in! ING dus wel, zoals bovenstaande screenshots laten zien wordt ik gewoon via squid met een fake cert richting client, ingelogd en kan ik mijn bankzaken vervolgens ongestoord maar wel gemonitoord en wel doen!!!!

En ja ik kon het niet laten om hun HSTS header nog even te highlighten

Om het vrolijk af te sluiten: c proggie + openssl shell script werkt nu prima. Met wat pointers van mensen die wel verstand hebben van c heb ik de daemon nu goed en betrouwbaar aan de praat. En het shell script heb ik met veel trial en error nu zo gemaakt dat ie niet uitgaat van OCSP (want iig Lets encrypt heeft daar moeite mee en zal de standaard binnenkort helemaal uit faseren!). In het geval van ontbrekende OCSP data probeert ie nu om de CRL van het certificaat op te halen en te checken voodat ie een certificaat uiteindelijk reject. Dus:
- niet op de OCSP whitelist: revoked
- in de CRL blacklist: revoked
- geen OCSP of CRL data: rejected

Mocht iemand er behoefte aan hebben dan wil ik mijn code met alle plezier delen, de bron was al public domain: want stond met zoveel woorden in een forum, maar flaky en gedateerd. Was sowieso al van plan er binnenkort een blog post aan te wijden.

[jb044]

Quote van een dev @work: "Er staat een nieuwe ACC versie van de app klaar met het nieuwe certificaat erin"

Denk dus dat dat is waar ik tegenaanloop op mijn Android telefoon, goed om te weten

[jb044]

Was ik weer

Denk eerst maar een reply op dit topic ipv een nieuwe. Op zich werkt het nu allemaal wel, behalve op Android, kennelijk is het redelijk gangbaar om appjes te pinnen op een ssl cert. Dus ik bleef bezig met uitzonderingen toevoegen, dus besloten om in dit geval squid gewoon default te laten werken met connects ipv ssl interceptie behalve voor zaken die ik op Android in de browser doe. Dit werkt en zou je ook mogen verwachten behalve met de Odido app.

Daar zag ik errors "capi.odido.nl", toen ik daar wat verder naar ging kijken bleek dat pi-hole daar een dnssec error op logde. Pi-hole gebruikt unbound als upstream dns. Als ik dat domein opvraag met google of cloudflare dns krijg ik gewoon een ip terug.

Hier zie ik wel degelijk wat dingen die niet zouden kloppen: https://dnsviz.net/d/capi.odido.nl/dnssec/ maar hij concludeert wel "secure".

Ben geen dnssec expert, meer iemand die hoopt dat als dat niet klopt ik als niets vermoedende eindgebruiker beschermd wordt Maar is mijn unbound verkeerd geconfigureerd of doet Odido in dit geval iets niet goed?