Hoe specifiek sites blokkeren met ipchains

[Red devil]

Wegens mijn dwangmatige surfgedrag betreffende de volgende sites:

www.tweakers.net
gathering.tweakers.net
www.isonews.com
www.fokzine.net

vond ik dat het tijd werd om actie te ondernemen.
Al dat slappe geouwehoer altijd op het forum, je hebt er in 9 van de 10 gevallen niks aan en het vreet tijd!
Ik wil dus dat mijn linuxservertje tot 12.00 uur bovenstaande sites blokkeert en dan een half uurtje vrijgeeft. Daarna om 12.30 tot 17.30 moeten ze wederom op slot!

Ik weet dat ik dat via crontab kan regelen, echter de ipchains rules heb ik gewoon eens van iemand over zitten pasten.
Ik had iets in gedachten als:


ipchains -A input -j DENY -p all -l -s 213.239.154.16 -d 192.168.0.6
ipchains -A input -j DENY -p all -l -s 213.239.154.12 -d 192.168.0.6
ipchains -A input -j DENY -p all -l -s 205.134.182.35 -d 192.168.0.6

Toch doe ik iets fout, ik kan er nog steeds bijkomen. Iets met de regels flushen ofzo?

Alvast bedankt

[Verwijderd]

Jij blockt de input, dat helpt echter niet. Dit blokkeert verkeer van de tweaker server door de tweaker server naar jou toe. Wat jij wil is dat *jouw* verkeer naar hun toe en de daarbijbehorende reply van hun niet werkt.

Je moet dus uitgaande verkeer naar die servers blocken - dan knu je geen requests doen en komt er dus ook geen reply.

Overigens, 99% kans dat er in je firewall regels een soort "allow all outgoing traffic" staat, je moet deze regels dus *voor* de "allow all output" plaatsen anders helpt het natuurlijk niet

[Red devil]

thanx for tha tip
ff kijken!

[Verwijderd]

Op maandag 13 augustus 2001 10:54 schreef Red devil het volgende:
thanx for tha tip
ff kijken!

Als het gelukt is verwacht ik dus niks meer te horen

[Red devil]

Op maandag 13 augustus 2001 10:55 schreef beelzebubu het volgende:

[..]

Als het gelukt is verwacht ik dus niks meer te horen

helaas!

ipchains -A output -j DENY -p all -l -s 192.168.0.5 -d 213.239.154.16
ipchains -A output -j DENY -p all -l -s 192.168.0.5 -d 213.239.154.12
ipchains -A output -j DENY -p all -l -s 192.168.0.5 -d 205.134.182.35
heb al gekeken of er een allow statement in mijn script voorkwam, die kwam er niet in voor...

[pistole]

Het is een firewall/router, dus je moet iets met de forward chain doen...

[Red devil]

Op maandag 13 augustus 2001 11:04 schreef pistole het volgende:
Het is een firewall/router, dus je moet iets met de forward chain doen...

ok!
kan ik weer ff verder

[Verwijderd]

Op maandag 13 augustus 2001 10:58 schreef Red devil het volgende:
ipchains -A output -j DENY -p all -l -s 192.168.0.5 -d 213.239.154.16

Maak hier eens -s 0/0 van

[RvdH]

ipchains -A input -s 0/0 -d ip.van.t.net -j DENY ?

[Red devil]

Op maandag 13 augustus 2001 11:12 schreef beelzebubu het volgende:

[..]

Maak hier eens -s 0/0 van

hee dit werkt !

Maar betekent dit dat nu niemand in dit netwerk (+/- 10 man) niet meer op internet kan komen? Ik wilde namelijk alleen mezelf beperken. Maar och , als het niet anders kan.
Thanx!

[Red devil]

Op maandag 13 augustus 2001 11:15 schreef RickJansen het volgende:
ipchains -A input -s 0/0 -d ip.van.t.net -j DENY ?

deze ook eens proberen

[Verwijderd]

Op maandag 13 augustus 2001 11:15 schreef RickJansen het volgende:
ipchains -A input -s 0/0 -d ip.van.t.net -j DENY ?

output. Input is active input van tw.net gegenereerd verkeer, unrequested. Als je zelf de request doet werkt deze regel dus niet met TCP-verkeer. TCP zet verbinding op, jij doet request, zet verbibnding op en over die verbinding komt de data binnen. input blocken helpt dan niet meer. Je moet dus de request al blocken, dus output deny, niet input.

(overigens kan je binnen een verbinding ook weer blocken of doorlaten maar ik weet niet hoe dat zit met iptables, ik heb geen ervaring ermee, alleen met openBSD's ipfilter)..

[Red devil]

Op maandag 13 augustus 2001 11:18 schreef Red devil het volgende:

[..]

deze ook eens proberen

die van rick werkt ook.

Oh, doet het niet super, want na een tijdje komt de site toch tevoorschijn.


Heb maar eerst niet GoT geblokkeerd, eerst ook maar even uitzoeken hoe ik ze weer vrijgeef

[Red devil]

Heb nu domweg om de sites weer tevoorschijn te halen van DENY , ALLOW gemaakt.

ipchains -A output -j ALLOW -p all -l -s 0/0 -d 213.239.154.12
ipchains -A output -j ALLOW -p all -l -s 0/0 -d 205.134.182.35


Maar dan zegt ie:
ipchains: No target by that name
ipchains: No target by that name
ipchains: No target by that name

[Verwijderd]

'ACCEPT', niet 'ALLOW'

[RvdH]

Op maandag 13 augustus 2001 11:21 schreef beelzebubu het volgende:

[..]

output. Input is active input van tw.net gegenereerd verkeer, unrequested. Als je zelf de request doet werkt deze regel dus niet met TCP-verkeer. TCP zet verbinding op, jij doet request, zet verbibnding op en over die verbinding komt de data binnen. input blocken helpt dan niet meer. Je moet dus de request al blocken, dus output deny, niet input.

(overigens kan je binnen een verbinding ook weer blocken of doorlaten maar ik weet niet hoe dat zit met iptables, ik heb geen ervaring ermee, alleen met openBSD's ipfilter)..

Hmja ik gebruikte zo ongeveer die regel om mensen te IPbannen van t.net. Maargoed

[Red devil]

Op maandag 13 augustus 2001 11:28 schreef beelzebubu het volgende:
'ACCEPT', niet 'ALLOW'

ok nu accept gemaakt... echter zonder resultaat.. ze komen niet binnen.
wat raar?
Nog eens samengevat, mijn blokkeerregels:

ipchains -A output -j DENY -p all -l -s 192.168.0.5 -d 213.239.154.16
ipchains -A output -j DENY -p all -l -s 0/0 -d 213.239.154.12
ipchains -A output -j DENY -p all -l -s 0/0 -d 205.134.182.35

(heb de bovenste nog niet op 0/0 gezet, anders kan ik hier niet meer posten)

mijn vrijgeef-regels:

ipchains -A output -j ACCEPT -p all -l -s 0/0 -d 213.239.154.16
ipchains -A output -j ACCEPT -p all -l -s 0/0 -d 213.239.154.12
ipchains -A output -j ACCEPT -p all -l -s 0/0 -d 205.134.182.35

Klopt er nog steeds iets niet?

[Verwijderd]

Op maandag 13 augustus 2001 11:35 schreef Red devil het volgende:

ok nu accept gemaakt... echter zonder resultaat.. ze komen niet binnen.
wat raar?

Als "accept-mode" is het flushen van de oude regels voldoende. Dus gewoon "iptables -F" of "iptables --flush". Je hoeft er geen specifieke regels in te zetten om te accepten, dat mag namelijk by default al . Dus gewoon de firewall flushen en dan doet ie het wel weer.

[Red devil]

Op maandag 13 augustus 2001 11:37 schreef beelzebubu het volgende:

[..]

Als "accept-mode" is het flushen van de oude regels voldoende. Dus gewoon "iptables -F" of "iptables --flush". Je hoeft er geen specifieke regels in te zetten om te accepten, dat mag namelijk by default al . Dus gewoon de firewall flushen en dan doet ie het wel weer.

aha! dat makes sense!
Maar dan moet ik zeker ook even de ipchains herhalen die in mijn originele ipchains script stonden vermeld?
Ik deel namelijk bijv rechten uit per ip:

ipchains -P forward DENY


/sbin/ipchains -A forward -s 192.168.0.3/32 -j MASQ
# rechten voor Nico

Moet ik dus alles wat onder het commando ipchains -F forward (in mijn oude firewall script) staat in mijn vrijgeef-script meenemen?

[Red devil]

plz! dit is de laatste vraag!

[Verwijderd]

iptables -A FORWARD -s 192.168.1.6 -d www.tweakers.net -j DROP

dit is hem bijna shit...ff proberen

[Verwijderd]

Uhm....

Ik snap de vraag ff niet helemaal. J bedoelt of je de overige regels die niks met websites blokkeren te maken hebben wel in dat vrijgeef script moeten na iptables --flush?

Ja

Je kan ook een shell scriptje maken dat aan de hand van een argument op de commando regel wel of niet die reegls gebruikt, dus:

code:

# dom scriptje voor firewall

IPTABLES = "/sbin/iptables"

${IPTABLES} --flush

# doe hier wat random blocks/allows enzo

if $0 = "disable_websites"
#plaats hier de block regels voor de got/tnet websites
endif

#enz....

Dat scheelt weer een extra bestandje

[Red devil]

Op maandag 13 augustus 2001 12:07 schreef fkooman het volgende:
iptables -A FORWARD -s 192.168.1.6 -d www.tweakers.net -j DROP

dit is hem

thanx, voor de nieuwe server met 2.4.8 gebruik ik iptables, dit scheelt weer.

[Red devil]

Op maandag 13 augustus 2001 12:08 schreef beelzebubu het volgende:
Uhm....

Ik snap de vraag ff niet helemaal. J bedoelt of je de overige regels die niks met websites blokkeren te maken hebben wel in dat vrijgeef script moeten na iptables --flush?

Yep dat bedoelde ik ! bedankt voor de oplossingen!

[Verwijderd]

Op maandag 13 augustus 2001 12:09 schreef Red devil het volgende:

[..]

thanx, voor de nieuwe server met 2.4.8 gebruik ik iptables, dit scheelt weer.

HMja, die moet je zeker bovenaan je firewall zetten voordat je de ACCEPT rule voor die machine doet foutje...bedankt

[Red devil]

# run-parts
0 9 * * * root /home/ejb/blokkeren
0 12 * * * root /home/ejb/vrijgeven
30 12 * * * root /home/ejb/blokkeren
30 17 * * * root /home/ejb/vrijgeven


tot 9 uur 's ochtends mag het nog, daarna niet meer, dan van 12 tot half 1 weer wel en dan tot half 6 niet meer.

zelfbescherming ten top! bedankt en tot half 6 !

[Verwijderd]

in de rules staat je private ip-nr. Dit moet je firewall ipnr zijn. Je kan misschien beter je interne verkeer naar buiten toe blokkeren. (eth1=interne netwerkkaart)

ipchains -A input -i eth1 -j DENY -l -d 213.239.154.16

etc.

[Verwijderd]

Op maandag 13 augustus 2001 11:21 schreef beelzebubu het volgende:

[..]

output. Input is active input van tw.net gegenereerd verkeer, unrequested. Als je zelf de request doet werkt deze regel dus niet met TCP-verkeer. TCP zet verbinding op, jij doet request, zet verbibnding op en over die verbinding komt de data binnen. input blocken helpt dan niet meer. Je moet dus de request al blocken, dus output deny, niet input.

(overigens kan je binnen een verbinding ook weer blocken of doorlaten maar ik weet niet hoe dat zit met iptables, ik heb geen ervaring ermee, alleen met openBSD's ipfilter)..

Euhm beelzebubu, je ziet heirboven een klein beetje onzin te praten!

Simpelweg gezegd is INPUT verkeer, verkeer dat rechstreeks van de server naar jouw server/computer gaat waarop ipchains draait.
Output verkeer is verkeer dat van jouw server naar de remote server/computer gaat.
forward verkeer is verkeer, dat door jouw server heen geroute wordt.

Wat je hierboven dus over INPUT verkeer verkondigd is niet waar.