PFsense - block onderlinge verkeer tussen netwerk

[chr1st14n]

ik ben bezig met een projectje waarbij ik pfsense wil inzetten als router/firewall. Dit alles hangt achter een 50/50 glasvezel. Ik kan inmiddels al aardig uit de voeten met PFsense, maar blijf zitten met het volgende probleem.

Ik moet voor dit project verschillende gescheiden netwerken hebben (in mijn geval verschillende VLAN's). Alle vlans mogen wel internet verkeer hebben, maar er mag onderling geen verkeer tussen de vlans zijn. Als dit maar een paar vlans waren, dan had ik met de hand per netwerk de andere vlans geblokt, maar het zijn er inmiddels al meer dan 25, en het zullen er alleen maar meer worden.

Heeft iemand hier een idee hoe dit simpel te realiseren is?? ik heb al even lopen zoeken op internet, maar kom nog geen concrete dingen tegen..

en om bij elk nieuw netwerk alle andere vlans te gaan lopen blokken is niet echt een optimale situatie...

[Raven]

Kun je de handelingen die je per vlan moet doen niet in een script zetten waarbij je daarna alleen een vlan hoeft in te vullen en het script de rest doet?

[CyBeR]

chr1st14n schreef op vrijdag 20 juni 2014 @ 14:11:
ik ben bezig met een projectje waarbij ik pfsense wil inzetten als router/firewall. Dit alles hangt achter een 50/50 glasvezel. Ik kan inmiddels al aardig uit de voeten met PFsense, maar blijf zitten met het volgende probleem.

Ik moet voor dit project verschillende gescheiden netwerken hebben (in mijn geval verschillende VLAN's). Alle vlans mogen wel internet verkeer hebben, maar er mag onderling geen verkeer tussen de vlans zijn. Als dit maar een paar vlans waren, dan had ik met de hand per netwerk de andere vlans geblokt, maar het zijn er inmiddels al meer dan 25, en het zullen er alleen maar meer worden.

Heeft iemand hier een idee hoe dit simpel te realiseren is?? ik heb al even lopen zoeken op internet, maar kom nog geen concrete dingen tegen..

en om bij elk nieuw netwerk alle andere vlans te gaan lopen blokken is niet echt een optimale situatie...

Aannemelijkerwijs is elk VLAN weliswaar voorzien van een eigen subnet, maar vallen ze allemaal onder één aggregate netwerk? Bijvoorbeeld, 192.168.1.0/24 en 192.168.44.0/24 vallen beide onder 192.168.0.0/16.

Dan zet je dus een filter op alle interfaces waarop je verkeer naar 192.168.0.0/16 blokkeert.

[ShadowAS1]

CyBeR schreef op vrijdag 20 juni 2014 @ 15:19:
[...]


Aannemelijkerwijs is elk VLAN weliswaar voorzien van een eigen subnet, maar vallen ze allemaal onder één aggregate netwerk? Bijvoorbeeld, 192.168.1.0/24 en 192.168.44.0/24 vallen beide onder 192.168.0.0/16.

Dan zet je dus een filter op alle interfaces waarop je verkeer naar 192.168.0.0/16 blokkeert.

Als het goed is leest pfsense de firewall tabel van boven naar onder (boven is dus prioriteit) dus: zet per vlan bijv: het volgende

Source: 192.168.5.0/24 Dest: 192.168.5.0/24 allow

En

Source 192.168.5.0/24 Dest: 192.168.x.0/16 block

2 regels per vlan, moet werken als ik t me ff zo snel bedenk

[CyBeR]

ShadowAS1 schreef op vrijdag 20 juni 2014 @ 16:14:
[...]

Als het goed is leest pfsense de firewall tabel van boven naar onder (boven is dus prioriteit) dus: zet per vlan bijv: het volgende

Source: 192.168.5.0/24 Dest: 192.168.5.0/24 allow

Waarom zou je dat doen, precies? Dat heeft nul nut.

[johnkeates]

Ik weet niet hoeveel VLANs je verwacht te hebben, maar is het dan niet een stuk makkelijker om een default block rule op alles te hebben en dan gewoon te gaan whitelisten? Het enige wat je dan hoeft te doen is als je een VLAN aanmaakt die nog even toestaan met internet te communiceren. Ik weet niet of je DHCP gebruikt, maar stel dat je je VLAN aan het instellen bent en een DHCP pool opzet dan is het een kleine moeite om even extra je VLAN ook een allow rule te geven naar WAN (maar dus niet naar de andere VLANs).

[CyBeR]

johnkeates schreef op vrijdag 20 juni 2014 @ 16:23:
Ik weet niet hoeveel VLANs je verwacht te hebben, maar is het dan niet een stuk makkelijker om een default block rule op alles te hebben en dan gewoon te gaan whitelisten? Het enige wat je dan hoeft te doen is als je een VLAN aanmaakt die nog even toestaan met internet te communiceren. Ik weet niet of je DHCP gebruikt, maar stel dat je je VLAN aan het instellen bent en een DHCP pool opzet dan is het een kleine moeite om even extra je VLAN ook een allow rule te geven naar WAN (maar dus niet naar de andere VLANs).

Heb je een voorbeeld van hoe je dat wilde doen zonder te doen wat ik schreef? (En zonder gebruik te maken van een zone-based firewall overigens, waarmee dit probleem ook simpel te fixen is. maar waarvan PFSense niet voorzien is).

[PerfectPC]

ik ga er even vanuit dat je voor elke vlan een fw interface gaat maken en die aan een fysieke of vlan tagged fysieke interface gaat koppelen? (hoe je scripted fw interfaces en vlan interfaces moet maken weet ik niet)

vervolgens is het heel eenvoudig: stil in je floating rule de toegang naar het internet in en je bent klaar, default is alle verkeer denied... (https://doc.pfsense.org/index.php/Firewall_Rule_Basics)

(mocht je dit met een allow any any willen doen, kan je zoals hierboven beschreven eerst een deny rfc1918 to rfc1918 plaatsten, ofwel enable je gewoon de block rfc1918 optie per fw interface)

[ Voor 18% gewijzigd door PerfectPC op 21-06-2014 02:43 ]

[pablo_p]

CyBeR schreef op vrijdag 20 juni 2014 @ 16:20:
[...]
Waarom zou je dat doen, precies? Dat heeft nul nut.

Het kan nut hebben, maar is niet de beste manier om dat nut te bereiken. Er zijn situaties waarin het wel werkt met zo'n rule, maar niet zonder. Waar je namelijk rekening mee moet houden met een "deny 192.168/16 rule" is dat je dan ook verkeer naar de firewall blokkeert. En het kan zijn dat de firewall een functie heeft als dhcp, ntp, dns server. Nadeel is dat je impliciet ook management verkeer toestaat (ssh, https). Netter is om eerst een rule te maken waarin je de benodigde services naar de firewall toestaat en dan toegang tot de rest van de lokale subnets blokkeert (inclusief toegang tot interne interfaces van de firewall)

Twee extra dingen om in de gaten te houden met een permit any rule:
- blokkeer verkeer naar je outside interface IP adres (subnet igv DHCP), want anders kan dat adres gebruikt worden voor ongewenste management toegang tot de firewall.
- denk dan ook aan site-to-site VPN verkeer dat je expliciet moet blokkeren in bepaalde situaties.

[CyBeR]

pablo_p schreef op zaterdag 21 juni 2014 @ 09:26:
[...]


Het kan nut hebben, maar is niet de beste manier om dat nut te bereiken. Er zijn situaties waarin het wel werkt met zo'n rule, maar niet zonder. Waar je namelijk rekening mee moet houden met een "deny 192.168/16 rule" is dat je dan ook verkeer naar de firewall blokkeert. En het kan zijn dat de firewall een functie heeft als dhcp, ntp, dns server. Nadeel is dat je impliciet ook management verkeer toestaat (ssh, https). Netter is om eerst een rule te maken waarin je de benodigde services naar de firewall toestaat en dan toegang tot de rest van de lokale subnets blokkeert (inclusief toegang tot interne interfaces van de firewall)

Right, en die kun je uitzonderen in een eerdere firewall rule waar je die services toestaat. Maar verder heeft het toestaan van verkeer naar het lokale subnet weinig zin. En als je 25+ VLANs hebt mag ik toch hopen dat je zulke services als dhcp en dns e.d. ergens centraal hebt staan, en dan kun je dat subnet (als 't ook onderdeel is van je aggregate subnet) natuurlijk ook toestaan.

[chr1st14n]

sorry voor het late antwoord, maar was een weekendje weg.

Ik zat zelf ook al te denken aan een default block alles rule, maar hoe krijg ik dan internet?? Enige manier wat mij gelukt is om internet te krijgen is om een regel aan te maken van "VLAN_X_net" --> "any". En deze regel heft die block rule volgens mij weer op... heb ook al geprobeerd om naast de block rule een allow rule "VLAN_X_net" --> "WAN" te doen, maar dan krijg ik nog steeds geen internet in dat VLAN..

En het zal straks om aardig wat vlan's gaan, maar voor nu zijn het er iets meer dan een handje vol. Wij willen voor een redelijk aantal klanten straks bepaalde dingen voor hun bij ons draaien (voor de ene klant als externe backup, en de andere klant heeft al zijn server bij ons draaien omdat hij zelf maximaal adsl kan krijgen en wij een leuke glasvezel hebben liggen). Het is wel de bedoeling dat ze elk een eigen ipadres gaan gebruiken (kunnen via de ISP meerdere extra ip adressen krijgen). Elke klant krijgt dan zijn eigen VLAN en een eigen IP adres. Gaat hier dan om kleine MKB klantjes.

Er draait op moment nog niks in productie, dit omdat we nu nog volop aan het testen zijn wat het beste is om te doen.

[Wolly]

PFSense blocked by default alle verkeer, dus zolang jij niet toestaat dat VLANx-VLANy verkeer is toegestaan zal dat ook niet plaatsvinden.

[moppentappers]

Wat wellicht ook een optie is, is een back-up maken van de pfsense configuratie en vervolgens in de XML zorgen dat alles goed staat en die dan restoren.

[CyBeR]

chr1st14n schreef op dinsdag 24 juni 2014 @ 10:26:
sorry voor het late antwoord, maar was een weekendje weg.

Ik zat zelf ook al te denken aan een default block alles rule, maar hoe krijg ik dan internet?? Enige manier wat mij gelukt is om internet te krijgen is om een regel aan te maken van "VLAN_X_net" --> "any". En deze regel heft die block rule volgens mij weer op... heb ook al geprobeerd om naast de block rule een allow rule "VLAN_X_net" --> "WAN" te doen, maar dan krijg ik nog steeds geen internet in dat VLAN..

Je moet ook niet zeggen 'allow naar any' in het geval van een default block, maar 'allow naar !local'. Oftewel een inverse match van je lokale netwerk toestaan.

[pablo_p]

De meest gebruikte manier is om je rule base als volgt op te bouwen (als je geen zonebased FW hebt)
1. Specifieke rules vanaf dat netwerk naar gedeelde diensten (DHCP, NTP, DNS, backup, SMTP, etc)
2. Block rules naar alle andere interne subnets
3. Rules vanaf subnet destination any met specifieke protocols (eventueel destionation specifieker)

Als je bij rule 1 en 2 dezelfde objecten gebruikt voor destination in alle rulebases, kan je later als er iets verandert die object(groep) aanpassen en dan gaan automatisch alle rulebases mee.
Als je dit in he tbegin handig en hiërarchisch opzet, vereist het daarna minimaal onderhoud

[LiquidSmoke]

En PfSense ondersteund gewoon aliases, dus als je al je vlan's opneemt in een alias kun je snel uitbreiden of dingen wijzigen.

Aliases werken voor hosts, subnets, poorten en urls.

[chr1st14n]

LiquidSmoke schreef op dinsdag 24 juni 2014 @ 14:02:
En PfSense ondersteund gewoon aliases, dus als je al je vlan's opneemt in een alias kun je snel uitbreiden of dingen wijzigen.

Aliases werken voor hosts, subnets, poorten en urls.

Ik had hier al wat mee zitten spelen, maar dat deed toen niet wat ik wou. Misschien dat ik er dan toch maar wat beter naar moet kijken

[PerfectPC]

chr1st14n schreef op dinsdag 24 juni 2014 @ 14:20:
[...]


Ik had hier al wat mee zitten spelen, maar dat deed toen niet wat ik wou. Misschien dat ik er dan toch maar wat beter naar moet kijken

heb je wel gelezen wat CyBeR en ik hierboven al geschreven hebben?

in je floating stel je deze rules in:
deny ip 10.0.0.0/8 to 10.0.0.0/8 (of een ander rfc1918 subnet dat van toepassing is)
allow ip any any

klaar...

[Rolfie]

Wolly schreef op dinsdag 24 juni 2014 @ 10:30:
PFSense blocked by default alle verkeer, dus zolang jij niet toestaat dat VLANx-VLANy verkeer is toegestaan zal dat ook niet plaatsvinden.

heb je dit ook getest, want dit klopt helaas niet.

Intern laat hij het helaas toe en is het lastig te blockeren.

[Brahiewahiewa]

Ik vraag me af waar die eis vandaan komt dat er tussen VLAN's onderling geen verkeer mag zijn.
Waar ben je bang voor?

De clients in een VLAN hebben geen weet van andere subnets; althans het lijkt mij een beetje onnozel om op die clients alle routes in te voeren en vervolgens te gaan verbieden dat ze gebruikt worden.
Dus je bestrijdt alleen het scenario waarin een kwaadwillende aanvaller met kennis van de IP-layout van jouw netwerk, dingen probeert te doen die niet mogen. Zijn die "dingen" niet verder beveiligd ofzo?

[Rolfie]

Brahiewahiewa schreef op woensdag 25 juni 2014 @ 13:35:
Ik vraag me af waar die eis vandaan komt dat er tussen VLAN's onderling geen verkeer mag zijn.
Waar ben je bang voor?

De clients in een VLAN hebben geen weet van andere subnets; althans het lijkt mij een beetje onnozel om op die clients alle routes in te voeren en vervolgens te gaan verbieden dat ze gebruikt worden.
Dus je bestrijdt alleen het scenario waarin een kwaadwillende aanvaller met kennis van de IP-layout van jouw netwerk, dingen probeert te doen die niet mogen. Zijn die "dingen" niet verder beveiligd ofzo?

Dit is meestal een vrij basis regel. Als VLANs niet met elkaar mogen communiceren, dan moet je dit ook actief tegenhouden.
Als ik iets kwaadwilligs wil doen, en ik krijg een IP 10.20.30.x/24. Dan zou ik als eerste 10.20.31.1 en 10.20.29.1 eens proberen te benaderen.

En de standaard firewall regel is: Blokkeer alles, en zet daarna open wat je open wilt hebben.

[Brahiewahiewa]

Ja maar, zo'n 99% van alle clients heeft al regelmatig moeite met het bereiken van subnets waar ze wel toegang hebben. Waarom dan zoveel energie gestoken in het op deze manier bestrijden van iets wat al zelden voorkomt?

'k Bedoel: zet op je Windows servers audit logging aan, draai op je pfSense bak een monitor die portscans detecteert en je hebt 80% te pakken, die overige 20% is ook wel slim genoeg om je router te compromitteren om alsnog op andere VLAN's te komen.

't Is allemaal erg veel moeite die je doet; het levert heel weinig op maar 't is wel de kernvraag van de OP: "hoe kom ik van die administratie van al die VLAN-blokkades af?"

[ChaserBoZ_]

Rolfie schreef op woensdag 25 juni 2014 @ 17:48:
[...]


Dit is meestal een vrij basis regel. Als VLANs niet met elkaar mogen communiceren, dan moet je dit ook actief tegenhouden.
Als ik iets kwaadwilligs wil doen, en ik krijg een IP 10.20.30.x/24. Dan zou ik als eerste 10.20.31.1 en 10.20.29.1 eens proberen te benaderen.

En de standaard firewall regel is: Blokkeer alles, en zet daarna open wat je open wilt hebben.

.

Precies, als het niet hoeft, waarom dan kunnen communiceren met ? Het levert alleen maar risico's op. DNS/DHCP/NTP etc centraal & redundant regelen, en geen verkeer tussen clients (afgezien van wellicht VoIP voor als je PBX RTP relay niet toepast).

[chr1st14n]

Brahiewahiewa schreef op woensdag 25 juni 2014 @ 13:35:
Ik vraag me af waar die eis vandaan komt dat er tussen VLAN's onderling geen verkeer mag zijn.
Waar ben je bang voor?

...

Ik heb meer een "Voorkomen is beter dan genezen". Oftewel ik wil liever nu al voorkomen dat ze onderling wat kunnen, dan dat ik het later moet gaan uitzoeken .

Verder zijn we ondertussen al wel aardig aan het testen met verschillende configs, en we gaan de goede richting op. Alleen blijven we beetje hangen op het punt, dan als we als standaard regels alles blokken we met moeite internet krijgen....

Maar hier zijn we nog mee bezig. Mochten we het goed hebben, dan zal ik het hier neerzetten (misschien handig voor anderen)

[PerfectPC]

chr1st14n schreef op vrijdag 18 juli 2014 @ 11:09:
[...]


Alleen blijven we beetje hangen op het punt, dan als we als standaard regels alles blokken we met moeite internet krijgen....

Post je rulebase eens

[Tele]

Als alle VLAN's gelijk zijn qua rules kan een Interface group je wellicht verder helpen.