[Ubuntu] Iptables + transparent proxy

[battler]

Ik heb squid net draaien werkt helemaal goed in transparent mode.
Nu is het vervelende dat wanneer ik mijn firewall dicht ga timmeren, sommige
sites niet meer werk. Het gaat dus niet om alles sites maar er is ook geen touw aan
vast te knopen wel sites wel en niet.

Het probleem zin hem in mijn iptables, en dan specifieker in de INPUT en OUTPUT regels.

Op deze manier werkt alles.

sudo iptables -P FORWARD DROP
sudo iptables -P INPUT ACCEPT
sudo iptables -P OUTPUT ACCEPT

Maar (na heel veel frustratie heb ik dit er allemaal ingegooid).
sudo iptables -A INPUT -j ACCEPT -p tcp --dport 80 -s 0.0.0.0/0 -i eth0
sudo iptables -A INPUT -j ACCEPT -p tcp --dport 80 -s 0.0.0.0/0 -i eth1
sudo iptables -A INPUT -j ACCEPT -p tcp --sport 80 -d 0.0.0.0/0 -i eth0
sudo iptables -A INPUT -j ACCEPT -p tcp --sport 80 -d 0.0.0.0/0 -i eth1
sudo iptables -A INPUT -j ACCEPT -p tcp --sport 80 -d 0.0.0.0/0 -0 eth0
sudo iptables -A INPUT -j ACCEPT -p tcp --sport 80 -d 0.0.0.0/0 -0 eth1
sudo iptables -A INPUT -j ACCEPT -p tcp --dport 80 -s 0.0.0.0/0 -0 eth0
sudo iptables -A INPUT -j ACCEPT -p tcp --dport 80 -s 0.0.0.0/0 -0 eth1

sudo iptables -A INPUT -j ACCEPT -p tcp --dport 3128 -s 0.0.0.0/0 -i eth0
sudo iptables -A INPUT -j ACCEPT -p tcp --dport 3128 -s 0.0.0.0/0 -i eth1
sudo iptables -A INPUT -j ACCEPT -p tcp --sport 3128 -d 0.0.0.0/0 -i eth0
sudo iptables -A INPUT -j ACCEPT -p tcp --sport 3128 -d 0.0.0.0/0 -i eth1
sudo iptables -A INPUT -j ACCEPT -p tcp --sport 3128 -d 0.0.0.0/0 -0 eth0
sudo iptables -A INPUT -j ACCEPT -p tcp --sport 3128 -d 0.0.0.0/0 -0 eth1
sudo iptables -A INPUT -j ACCEPT -p tcp --dport 3128 -s 0.0.0.0/0 -0 eth0
sudo iptables -A INPUT -j ACCEPT -p tcp --dport 3128 -s 0.0.0.0/0 -0 eth1

Dit werkt niet
Ik moet eerlijk zeggen dat ik ook niet snap wat en welke porten ik moet open zetten.
Misschien dat iemand mij dit kan uitleggen; op dit moment zie ik het zo

lan Client doet een request op port 80.
Firewall --> input op eth1 (lan nic) source ip /24 dport 80
deze wordt toegelaten.
Iptables gooit port 80 om naar port 3128
Squid pakt port 3128 op request de data op port 80?
Datakomt binnen op port 80 en wordt direct doorgestuurd naar client?

Sorry als het een beetje vaag is, maar ik snap het echt even niet

[Bergen]

1. Is dit je hele firewallscript? Of heb je een stuk achterwege gelaten? Want ik mis bijvoorbeeld aan het begin het flushen van de oude tabellen.

2. Zet je behalve de nieuwe regels de default policy wel op DROP/REJECT? Anders hebben die regels niet zoveel nut. Als de default policy is dat alles geaccepteerd moet worden, hoef je niet nogmaals opnieuw toestemming te geven met nieuwe accept-regels.

3. Als je alles wel op drop/reject hebt gezet missen we nog vanalles. Ik kan me voorstellen dat je dingen als FTP en HTTPS later wilt doen, maar DHCP en DNS lijkt me iets wat je wel meteen wilt regelen, anders heb je hier niet veel aan.

4. Inbound verkeer van buiten af op poort 80 en 3128 zou ik dicht laten, tenzij je een webserver of proxyserver voor de buitenwereld wilt draaien, maar ik geloof niet dat dat de bedoeling is.

---

Jij bekijkt het nu geloof ik zo:
* Je pc verbindt met een webserver op poort 80 en verstuurt een request voor een website.
* De server verbindt met jouw pc op poort 80 en stuurt het antwoord terug. (En met 3128 hetzelfde verhaal.)

Maar zo werkt het niet. Het werkt zo:
* Een verbinding met de webserver wordt geopend, op poort 80.
* Je pc verstuurt een request en de server stuurt het antwoord terug, op de nog openstaande verbinding.
* De verbinding wordt weer gesloten.
Met andere woorden: alleen outbound poort 80 moet open. Jouw pc verbindt met de server, niet andersom.

Misschien nog even een interessant linkje naar een goeie tutorial erbij...
http://www.linuxhomenetwo..._Firewalls_Using_iptables

[ Voor 32% gewijzigd door Bergen op 11-07-2008 23:13 ]

[battler]

1: Sorry voor de onduidelijkheid. Dit is maar een heel klein gedeelte van mijn iptables.
DNS, DHCP, RDP, FTP, SSH, Telnet e.d werken allemaal al.

2: Ik wil alles op DROP hebben, en alleen specifiek lan via proxy toegang geven tot wan.
Maar dit specifiek toegang geven lukt niet. Ik mis iets in mijn INPUT en OUTPUT wat wel vereist is voor een proxy.

Als alleen outbound port 80 open moet.
- Moet dit dan met FORWARD of met INPUT en OUTPUT.
(mijn conclusie is INPUT en OUTPUT).

Ik neem aan dat de firewall port 80 naar het wan open moet hebben.
Maar het lan gedeelte moet toch ook kunnen verbinden met firewall op port 80?
Als ik je goed begrijp moet ik het zo doen:

sudo iptables -A OUTPUT -j ACCEPT -p tcp --sport 80 -d 0.0.0.0/0 -o eth0 (dit werkt niet btw.)

[ Voor 38% gewijzigd door battler op 11-07-2008 23:22 ]

[Bergen]

Nouja, er worden alleen outbound connecties gemaakt. Het retourverkeer zijn ook pakketjes en je moet wel apart aangeven dat dat 'established' verkeer ook binnen mag komen:

De HTTP-requests:

iptables -A OUTPUT -o eth0 -p tcp --dport 80 -j ACCEPT

Het verkeer wat terugkomt:

iptables -A INPUT -i eth0 -p tcp --sport 80 -m state --state ESTABLISHED,RELATED -j ACCEPT

sudo iptables -A OUTPUT -j ACCEPT -p tcp --sport 80 -d 0.0.0.0/0 -o eth0 (dit werkt niet btw.)

--sport = source port. Je verbindt echter niet vanaf poort 80, maar naar poort 80, dus de destination port (dport) ipv de source port (sport). De destination opgeven met 0.0.0.0/0 (oftewel, alle IP-adressen) heeft trouwens geen zin. Dat stukje kun je wel weglaten.

[ Voor 34% gewijzigd door Bergen op 12-07-2008 02:45 ]

[ChaserBoZ_]

Misschien niet helemaal wat je zoekt, maar als je je iptables config door shorewall laat doen bijvoorbeeld, scheelt je waarschijnlijk hoop werk, en op de shorewall site staan goede voorbeelden hoe te doen wat jij nu wilt

[battler]

Bedankt, gelukkig heb ik het hele iptables verhaal al helemaal werkend. Er zijn veel applicaties die als firewall fungeren of een schil om iptables heen zjin. Helaas zijn deze applicaties het vaak net niet. Maar in iedergeval bedankt voor de tip.

[Bergen]

Er gaat niets boven handmatig de regels schrijven. Full control!

[battler]

Ik heb al applicaties geprobeerd als firestarter en interfaces als webmin en IPcop.
Alleen zo precies als je het zelf kan configge lukt het nooit bij die apps. Het is veel werk want ik ben nu denk ik op 25% van mijn totale firewall maar heb al 2 A4'tjes vol.

Voor de mensen die geintresseerd zijn in het IPTABLES verhaal:

code:

#http wan (is nog verder te specificeren met een destionation)
sudo iptables -A OUTPUT -o eth0 -p tcp --dport 80 -s 10.0.1.2 -j ACCEPT
sudo iptables -A INPUT -i eth0 -p tcp --sport 80 -s 0.0.0.0/0 -m state --state ESTABLISHED,RELATED -j ACCEPT

code:

#http lan
sudo iptables -A OUTPUT -o eth1 -p tcp --sport 3128 -s 192.168.0.1 -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -i eth1 -p tcp --dport 3128 -s 192.168.0.0/24 -j ACCEPT

Volgens dit is de werking van proxy als volgt.

De data wordt verstuurd op port 80 door een client.
Wordt via de volgende regel redirect naar 3128

Vervolgens komt de data binnen op de lan interface met --sport 3128

code:

#squid transparant proxy, port redirect
sudo iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128

code:

#http lan
sudo iptables -A OUTPUT -o eth1 -p tcp --sport 3128 -s 192.168.0.1 -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -i eth1 -p tcp --dport 3128 -s 192.168.0.0/24 -j ACCEPT

Hier gaat het waarschijnljik de proxy in, die een request doet op port 80.

code:

#http wan
sudo iptables -A OUTPUT -o eth0 -p tcp --dport 80 -s 10.0.1.2 -j ACCEPT
sudo iptables -A INPUT -i eth0 -p tcp --sport 80 -s 0.0.0.0/0 -m state --state ESTABLISHED,RELATED -j ACCEPT

[deadinspace]

battler schreef op maandag 14 juli 2008 @ 09:57:
Het is veel werk want ik ben nu denk ik op 25% van mijn totale firewall maar heb al 2 A4'tjes vol.

Wat probeer je wel niet te bereiken dan?

code:

sudo iptables -A OUTPUT -o eth0 -p tcp --dport 80 -s 10.0.1.2 -j ACCEPT
sudo iptables -A OUTPUT -o eth1 -p tcp --sport 3128 -s 192.168.0.1 -m state --state ESTABLISHED,RELATED -j ACCEPT

Waarom deze OUTPUT regels? Vanaf 192.168.0.1.3128? Waarom uberhaupt OUTPUT beperken?

Oh, en zet alsjeblieft niet sudo voor elk iptables command, dat is niet de meest handige manier om dat aan te pakken.

Naar de rest van je rules kijkend heb ik de indruk dat je wat te ingewikkeld bezig bent. Oh, en een subtiele hint: [code][/code]. Gebruik ze

[CrankyGamerOG]

deadinspace schreef op maandag 14 juli 2008 @ 10:49:
[...]

Wat probeer je wel niet te bereiken dan?


[...]

Waarom deze OUTPUT regels? Vanaf 192.168.0.1.3128? Waarom uberhaupt OUTPUT beperken?

Oh, en zet alsjeblieft niet sudo voor elk iptables command, dat is niet de meest handige manier om dat aan te pakken.

Naar de rest van je rules kijkend heb ik de indruk dat je wat te ingewikkeld bezig bent. Oh, en een subtiele hint: [code][/code]. Gebruik ze

Hij zal wel moeten met sudo in ubuntu he of hij moet het root account toegankelijk maken.

[battler]

Die output regels zijn nodig omdat er een DROP op alle INPUT, OUTPUT en FORWARD staat.
Dus ik zal toch echt per regel moeten definiëren dat er wel of niet naar buiten gegaan moet worden.
Voor de rest van je tekst ben ik het met je eens. Ik weet ook niet of dat ik het wel goed aan pak.
Ik ben bang dat ik dingen over het hoofd zie, dus regels configureer die toepasbaar (te misbruiken) zijn op/door meerdere doeleinden. Ik zal hem eerst helemaal afmaken, en dan drop ik het waarschijnlijk op got voor grondige inspectie. Ik moet er wel bij vermelden dat dit gewoon voor thuis gebruik is en gelukkig dus niet zo heel nauw luistert.

[deadinspace]

CrankyGamerOG schreef op maandag 14 juli 2008 @ 10:52:
Hij zal wel moeten met sudo in ubuntu he of hij moet het root account toegankelijk maken.

Dan hoeft hij nog niet sudo voor elke iptables aanroep in zijn script te zetten... Gewoon geen sudo in een script gebruiken (is sowieso geen briljant idee tenzij het gegarandeerd nooit om een wachtwoord vraagt), en dan sudo voor de aanroep van het script zetten.

battler schreef op maandag 14 juli 2008 @ 10:56:
Die output regels zijn nodig omdat er een DROP op alle INPUT, OUTPUT en FORWARD staat.
Dus ik zal toch echt per regel moeten definiëren dat er wel of niet naar buiten gegaan moet worden.

Mja, ik vind OUTPUT zo dichtzetten een beetje overdreven. Hou je ook rekening met uitgaande DHCP queries, en hun antwoorden? En DNS? ARP? NTP?

Het kan wel natuurlijk, maar je krijgt er nogal wat rules door, en zo'n bomen/bos verhaal.

[CrankyGamerOG]

deadinspace schreef op maandag 14 juli 2008 @ 12:40:
[...]


[...]

Mja, ik vind OUTPUT zo dichtzetten een beetje overdreven. Hou je ook rekening met uitgaande DHCP queries, en hun antwoorden? En DNS? ARP? NTP?

dat kan jij wel vinden, maar als jij niet oplet met wat je uitgaand hebt dan zie je ook niet wat er gebeurt,
, een goeie firewall laat alleen geauthoriseerd verkeer naar buiten imho.

Probeer op mijn netwerk maar eens een nieuwe service te installeren die naar buiten wilt ,
uh uh uh you didnt say the magic word, uh uh uh

[ Voor 13% gewijzigd door CrankyGamerOG op 14-07-2008 13:08 ]

[deadinspace]

CrankyGamerOG schreef op maandag 14 juli 2008 @ 13:07:
dat kan jij wel vinden

Ja, dat vind ik ja, zeker voor een thuisnetwerk. Door OUTPUT onnodig dicht te zetten wordt je firewall script onnodig ingewikkeld waardoor je makkelijk andere (veel belangrijker) zaken over het hoofd ziet. Bovendien sloop je er meer mee dan je denkt, tenzij je goed weet waar je mee bezig bent.

maar als jij niet oplet met wat je uitgaand hebt dan zie je ook niet wat er gebeurt

Monitoring is niet hetzelfde als blokkeren in de firewall.

Probeer op mijn netwerk maar eens een nieuwe service te installeren die naar buiten wilt

En dus moet je elke keer je firewall aanpassen als je eens een keer een extra service installeert. Had je fijn een NTP serverice geinstalleerd op die machine met een irritant out-of-sync lopende klok, helpt dat geen zier omdat je NTP niet open had gezet in de firewall. Om over dingen als bittorrent maar te zwijgen.

[CrankyGamerOG]

deadinspace schreef op maandag 14 juli 2008 @ 13:49:
[...]

Ja, dat vind ik ja, zeker voor een thuisnetwerk. Door OUTPUT onnodig dicht te zetten wordt je firewall script onnodig ingewikkeld waardoor je makkelijk andere (veel belangrijker) zaken over het hoofd ziet. Bovendien sloop je er meer mee dan je denkt, tenzij je goed weet waar je mee bezig bent.

[...]

Monitoring is niet hetzelfde als blokkeren in de firewall.

[...]

En dus moet je elke keer je firewall aanpassen als je eens een keer een extra service installeert. Had je fijn een NTP serverice geinstalleerd op die machine met een irritant out-of-sync lopende klok, helpt dat geen zier omdat je NTP niet open had gezet in de firewall. Om over dingen als bittorrent maar te zwijgen.

Nee goed, je hebt een valide punt , maar dat geld alleen als je niet echt weet waar je mee bezig bent, weet je dit wel dan is het nog geen 5 sec werk om NTP open te gooien toch ?
En je weet 100% zeker dat je isp je niet 1 2 3 afsluit omdat je een virus of whatever hebt

[battler]

Sudo voor elke regel is inderdaad totaal niet nodig aangezien het in een script staat.
Dit is er bij in geslopen tijdens het conffige ik zal het er ooit een keer uit moeten halen maar dat is niet erg.
M.B.T OUTPUT Block. Voor mij werkt dit ontzettend fijn. Ik kijk goed welke porten er nodig zijn en open moeten zijn en dat pas ik dan toe. Sterker nog als en iets anders dan DNS en DHCP open moet zijn op de lan interface, specificeer ik ook gelijk de source adres. Heeft voor mij nog geen problemen opgeleverd.

[Bergen]

Mee eens, ik houd er ook niet van om de hele boel maar open te gooien. Per service aangeven wat er open mag vind ik veel prettiger. Zoveel werk is het nou ook weer niet als je een nieuwe service hebt. Bovendien is het leerzaam om te weten wat er allemaal open en dicht moet voor een service.