[iptables] bepaalde webpagina's blokkeren

[Zynth]

Ik heb een vraagje over het blocken van websites; als dat al mogelijk is.
Ik wil een bepaald aantal clients in mijn netwerk verbieden een
bepaald aantal webpagina's op te vragen.

bijvoorbeeld;
ip 192.168.0.5 t/m 192.168.0.20 mogen niét www.google.com en niet www.altavista.com opvragen.

is dit te realiseren met iptables?
Of zijn daar andere softwarepakketten voor (uiteraard voor linux )

[Brazza]

Dansguardian is er volgens mij voor linux. ff kijken @ SF.net

[rschu68]

Kan je dit niet simpel met squid-proxyserver blokkeren ?

P.S. hoe surfen je clients nu (rechstreeks via de router of anders ?)

[Zynth]

ik heb gewoon een iptables masquerading scripje.
Het is de bedoeling dat daarin dus bepaalde clients bepaalde www's niet mogen bezoeken...

[Freak_NL]

Ja, je kan met iptables simpelweg verkeer naar bepaalde IP's of IP-ranges blokkeren of weigeren.

Ja, daar zijn ook softwarepakketten voor. Een proxy lijkt me meer wat je zoekt, websites blokkeren met iptables is niet een erg nette oplossing. Squid is het bekendst onder Linux.

Je gaat toch niet serieus google blokkeren hoop ik?

Iptables howto's en tutorials: http://www.netfilter.org/

[ Voor 11% gewijzigd door Freak_NL op 08-05-2003 14:08 ]

[rschu68]

- Dus je hebt een aantal Linux-clients die elk hun eigen (waarschijnlijk hetzelfde) iptables script gebruiken ... of
- ...

Kan je iets meer input geven ?

[Freak_NL]

remke: Een masquerading setup voor iptables zegt Zynth, het lijkt me dus dat zich dat op de gateway plaatsvind.

[Zynth]

ok..

ik heb een server. Daarop draait een iptables firewall, die ook mijn clients laat internetten (is dus een gateway)
Maar nou moet ik een bepaald aantal clients verbieden om bepaalde websites te bekijken, en dat moet server-side (dus op de gateway) geregeld worden.
De vraag is dus wat daar de beste (en vooral meest simpele) oplossing voor is.

[Verwijderd]

code:

for host in host_to_be_restricted:
    iptables -A INPUT -s host -d google.com -j DROP
    iptables -A INPUT -s host -d av.com -j DROP

Zoiets?

[rschu68]

Ik denk dat SQUID het juiste antwoord is ...

http://www.squid-cache.org/Doc/FAQ/FAQ.html#toc23

[Zynth]

code:

for host in host_to_be_restricted:
    iptables -A INPUT -s host -d google.com -j DROP
    iptables -A INPUT -s host -d av.com -j DROP

dat lijkt me wel voldoende voor wat ik wil...
het hoeft maar simpel te zijn, alhoewel squid goed in mijn project zou passen.
(heeft ook PAM auth etc )
ff een dom vraagje nog; kan je ook een range opgeven in iptables?
zegmaar:
iptables -A INPUT -s 192.168.0.10/192.168.0.100 oid?
meerdere hosts per regel zou helemaal gaaf zijn

[ Voor 6% gewijzigd door Zynth op 08-05-2003 14:31 ]

[imdos]

transparante proxy(squid) met acces list en block list(squidguard bijv.)

[Zynth]

hmm... het werkt niet helemaal zoals hierboven beschreven staat.

mijn firewall is nu:

code:

#eth0 is internet, eth1 is intern netwerk

#Blocked ALLE Traffic naar de server
$IPTABLES -F
$IPTABLES -N block
$IPTABLES -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A block -m state --state NEW -i ! eth0 -j ACCEPT

#Allowed ALLEEN de opgegeven poorten: 22 80
$IPTABLES -A block -p tcp --destination-port 22 --syn -j ACCEPT
$IPTABLES -A block -p tcp --destination-port 80 --syn -j ACCEPT
$IPTABLES -A block -p tcp --destination-port 998 --syn -j ACCEPT
$IPTABLES -A block -p tcp --destination-port 9084 --syn -j ACCEPT
$IPTABLES -A block -p udp --destination-port 9084 -j ACCEPT

$IPTABLES -A FORWARD -i eth0 -d 192.168.0.0/24 -p udp --dport 9084 -m state --state NEW -j ACCEPT
$IPTABLES -t nat -A PREROUTING -i eth0 -p udp -d 130.89.168.140 --dport 9084 -j DNAT --to-destination 192.168.0.10:9084
$IPTABLES -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -j SNAT --to-source 130.89.168.140


$IPTABLES -A block -j DROP
$IPTABLES -A INPUT -j block
$IPTABLES -A FORWARD -p tcp --dport 9084 -i eth0 -d 192.168.0.10 -j ACCEPT



#DIT zou dus moeten werken...
$IPTABLES -A INPUT -s 192.168.0.10 -i eth1 -d google.com -j DROP


#--------------------------------------------
#Zet deze server in als gateway
$IPTABLES -t nat -A POSTROUTING -j MASQUERADE

om de een of andere reden werkt het dus niet.
Ik kan van 92.168.0.10 nog rustig queries doen naar www.google.com

[deadinspace]

Zynth schreef op 08 mei 2003 @ 14:29:
ff een dom vraagje nog; kan je ook een range opgeven in iptables?
zegmaar:
iptables -A INPUT -s 192.168.0.10/192.168.0.100 oid?
meerdere hosts per regel zou helemaal gaaf zijn

Je kunt wel een mask opgeven... Bijvoorbeeld 192.168.0.0/28 om 192.168.0.0 - 192.168.0.15 te blokkeren. Een decimale range is volgensmij niet mogelijk, maar zie de manpages, daar zou het in moeten staan.

Overigens zou je een chain kunnen maken waarin gecheckt wordt of de destination-host een "niet-toegelaten" site is, en dan alle hosts die daar niet naar toe mogen naar deze chain sturen. Op die manier hoef je voor elke host maar één regel te gebruiken ipv één regel per verboden site per host.

Je snapt trouwens wel dat als iemand op zo'n machine zijn IP kan veranderen, hij dan wel weer bij die sites kan he?

[Zynth]

ja, dat begrijp ik
Maar het probleem blijft dat de oplossing die ik 2 post hierboven heb gekregen, niet werkt

[deadinspace]

code:

[marcelm@nothing marcelm]$ host google.com
google.com has address 216.239.33.100
google.com has address 216.239.51.100
[marcelm@nothing marcelm]$ host www.google.com
www.google.com has address 216.239.57.99

Overigens kan het ook nog zijn dat Google round-robin DNS gebruikt, wat inhoudt dat je bij elke resolve een ander IP kunt krijgen (dit om de load te verdelen over meerdere machines). Misschien is het handiger om te testen met een eenvoudigere site die zekersteweten maar één IP heeft

edit:
Nu ik er even over nadenk: dat google.com resolved naar twee adressen komt door round-robin DNS. Een gewoon programma krijgt slechts één van beide IPs.

[ Voor 15% gewijzigd door deadinspace op 08-05-2003 22:05 ]

[bkor]

Je gebruikt INPUT ipv FORWARD. Bij ipchains (2.2 kernel) ging het pakket wel van INPUT->FORWARD->OUTPUT. Bij iptables (2.4 kernel.. geen idee wat ipchains onder 2.4 doet) gaat een pakket alleen nog via de FORWARD als een pakket niet voor de machine is.

Dus het volgende is iets beter (op 1 regel):
$IPTABLES -A FORWARD -s 192.168.0.10 -i eth1 -d google.com -j REJECT --reject-with icmp-host-prohibited

De REJECT vind ik netter omdat de client dan niet op een timeout hoeft te wachten. DROP gebruik ik alleen voor extern verkeer.

Alleen werkt mijn verbetering nogsteeds niet:

code:

$ host google.com
google.com has address 216.239.33.100
google.com has address 216.239.51.100
$ host www.google.com
www.google.com has address 216.239.33.99
$ host google.nl
google.nl has address 216.239.37.100
google.nl has address 216.239.39.100

Misschien is het beter om de range te blocken (216.239.32.0/19)

ow en squid is natuurlijk veel beter

Edit: te laat, maar ik heb het FORWARD wel gezien

[ Voor 4% gewijzigd door bkor op 08-05-2003 22:08 ]

[Freak_NL]

Misschien een heel vreemde vraag.. Maar waarom wil je het nuttigste deel van het Internet blokkeren?

[Zynth]

omdat je vaak in een voorbeeld iets roept wat mensen herkennen

maareh, de oplossing die hierboven gegeven wordt:
$IPTABLES -A FORWARD -s 192.168.0.10 -i eth1 -d google.com -j REJECT --reject-with icmp-host-prohibited

werkt als een trein.
Maar dan nu het laatste deel van wat ik nodig heb
nou wil ik nog een ip alléén toegang geven tot 1 website, bijvoorbeeld hotmail.com
Daarvoor probeerde ik dit:

code:

$IPTABLES -A FORWARD -s 192.168.0.10 -i eth1 -j REJECT --reject-with icmp-host-$
$IPTABLES -A FORWARD -s 192.168.0.10 -i eth1 -d google.com -j ALLOW

maar dat gaat niet goed
De eerste regel doet het; alles wordt idd ge-reject.
Maar op de tweede regel krijg ik een fout...

[ Voor 84% gewijzigd door Zynth op 09-05-2003 03:10 ]

[Verwijderd]

Wil niet lullig doen ofzo, maar due user die IP 192.168.0.10 kan ook gewoon .11 nemen en dan wel www.geilepornozaait.nl bekijken? Aangezien je 192.168.0.0/24 op intern_if gebruikt om te forwarden kan iemand een ander IP in 192.168.0.0/24 om meer rechten te krijgen.

Hoe je dit fixed is via een non-IP based authentication of via een DMZ.

Non-IP based: voorbeeld is al gegeven, Squid is een programma waar het mee kan. Squid kan authen. Squid kan ook transparent draaien (vb: al uitgaande naar externe NIC redirect je naar localhost port 3128). Squid kan niet allebei tegelijk. Too bad! Wat je ook in kunt stellen in Squid is dat ze alleen naar port 80/443 (http/https) mogen gaan. Kan ook in IPTables btw. En dan heb je nog AuthPF in OpenBSD voor PF, misschien is er ook zoiets voor IPTables. Je kunt het ook wel zelf in elkaar scripten/coden zo ingewikkeld is dat progje niet. AuthPF moet je naar SSHen, dan username/passwd en dan heeft AuthPF een aantal commando's die hij execute na de authenticatie bijv. iets voor IPsec. Handig met WiFI. Wat je er echter ook mee kunt gebruiken is PF (IPTables) bepaalde rules toevoegen zoals NAT rules van IPv4/32 naar bepaalde IP's of pass out's naar bepaalde IP's.

DMZ: 2 NIC's op de router (waar nu IPTables op draait). Een die NAT op NIC_1 voor alle trusted users bijv. 10.0.0.5/24 door naar het internet. Eventueel met een authenticatie waarbij je er zeker van bent dat die die users ook echt zo'n trusted user is dus niet dat een aardappel van NIC_2 gedeelte achter bak NIC_1 gedeelte zit. Maar goed, dat zou niet mogelijk mogen zijn. En dan NIC_2 doet NAT voor bijv. 192.168.0.25/24 waarbij elke user naar geen IP mag gaan, behalve *lijst IP's waarbij je rekening houdt met round-robin DNS*. Op deze manier kan user X niet zeggen van 'hey ff m'n IP veranderen' omdat NIC_2 alleen forward voor 192.168.0.25/24 en niet voor een 'superuser' 10.0.0.5/24

Nofi. Hoewel ik niet weet voor welke users dit is bedoelt en wat je verder voor security draait in je netwerk om deze problemen te voorkomen weet ik niet. Voor zover ik het nu zie vind ik je huidige authenticatie methode bagger. Op deze manier heeft je 'beveiliging' m.i. geen zin, omdat de beveiliging zo omzeilt kan worden. Aangezien je het belangrijk lijkt te vinden dat users bepaalde sites absoluut niet mogen zien vind ik het belangrijk dat je dit in acht neemt, maargoed, tis jouw netwerk en jouw keus ofcourse! Succes!

[Zynth]

nou, het is helemaal niet erg dat het niet zo veilig is, als het maar werkt.
Verder kunnen mensen op declients toch niet inlogen als admin en hebben ze geen rechten om aan netwerkinstallingen te zitten; dat is dus niet zo erg.

Mijn vraagje van 2 posts hierboven blijft dus staan; wat is er fout aan die 2e regel?

[eth0]

Verwijderd schreef op 09 May 2003 @ 05:17:
Wil niet lullig doen ofzo, maar due user die IP 192.168.0.10 kan ook gewoon .11 nemen en dan wel www.geilepornozaait.nl bekijken? Aangezien je 192.168.0.0/24 op intern_if gebruikt om te forwarden kan iemand een ander IP in 192.168.0.0/24 om meer rechten te krijgen.

Je kan ook nog met iptables op mac adress filteren

[_JGC_]

Waarom allemaal moeilijk doen als het ook makkelijk kan: Squid + squidguard + iptables.

Gebruik thuis Squid om bepaalde dingen te filteren, op de clients hoef ik niets in te stellen, die surfen ALTIJD via de proxy, of ze dat willen of niet.

Zelfde heb ik ook gedaan met mn virusscannende SMTP server: iedereen die naarbuiten mailt, gaat eerst door mn SMTP server.

[deadinspace]

Zynth schreef op 09 May 2003 @ 02:53:
maar dat gaat niet goed
De eerste regel doet het; alles wordt idd ge-reject.
Maar op de tweede regel krijg ik een fout...

*probeert*

Nee, het lukt niet... Mijn telepathische gaven zijn vandaag een beetje zwak, je zult dus zelf moeten vertellen wat de fout is die je krijgt.

Serieus: Als je niet vertelt wat er fout gaat, dan kunnen we ook niet helpen.

Verwijderd schreef op 09 May 2003 @ 05:17:
Wil niet lullig doen ofzo, maar due user die IP 192.168.0.10 kan ook gewoon .11 nemen en dan wel www.geilepornozaait.nl bekijken?

Zeg, wil je een OW voor porno?

Maar dat was al opgemerkt en de TS heeft al aangegeven dat hij dat weet

[bkor]

deadinspace schreef op 09 mei 2003 @ 14:42:
[...]
Nee, het lukt niet... Mijn telepathische gaven zijn vandaag een beetje zwak, je zult dus zelf moeten vertellen wat de fout is die je krijgt.

volgens mij krijgt hij een foutmelding zoals 'target ALLOW does not exist'.
TS: ACCEPT, niet ALLOW

code:

$IPTABLES -A FORWARD -s 192.168.0.10 -i eth1 -j REJECT --reject-with icmp-host-$
$IPTABLES -A FORWARD -s 192.168.0.10 -i eth1 -d google.com -j ALLOW

TS: Hier blokkeer je eerst al zijn verkeer en pas daarna laat je verkeer toe. Zo werkt iptables niet. Zodra je iets blokkeert wordt het ook geblokkeerd. Je zal dus eerst iets moeten accepten om vervolgens te gaan blokkeren. Als het maar 1 regel is dan kan je bij de reject regel gelijk de uitzondering maken, bv
$IPTABLES -A FORWARD -s bron -d ! google -j REJECT --etc

Maarre, het wordt tijd dat je een HOWTO of de manpage doorleest. Het staat er allemaal in.

[Confusion]

Overigens is censuur meestal niet de juiste oplossing voor een probleem.

[Verwijderd]

eth0 schreef op 09 May 2003 @ 10:19:

Je kan ook nog met iptables op mac adress filteren

Ja en ook dat kun je veranderen ifconfig hw class address, staat in de man ergens. In *BSD moet 't weer anders ik gebruik er sea.c voor. Da's wel wat lastiger aan te passen.

_JGC_ schreef op 09 mei 2003 @ 12:05:
Waarom allemaal moeilijk doen als het ook makkelijk kan: Squid + squidguard + iptables.

Gebruik thuis Squid om bepaalde dingen te filteren, op de clients hoef ik niets in te stellen, die surfen ALTIJD via de proxy, of ze dat willen of niet.

Zelfde heb ik ook gedaan met mn virusscannende SMTP server: iedereen die naarbuiten mailt, gaat eerst door mn SMTP server.

Dat laatste is ook gaaf! Qua relaying moet-ie relayen voor het/de LAN ip, right?

deadinspace schreef op 09 mei 2003 @ 14:42:

Zeg, wil je een OW voor porno?

alleen als-ie opensource is ik heb 't teruggelezen en idd daar was het al door jou opgemerkt, sorry.