CentOS 6.4 + Squid + IPTables / Poort toelaten

[dulghar]

Voor een klein clubje mensen hebben wij bij ons bedrijf een aparte Internet verbinding liggen. Om deze wel veilig te houden, loopt de verbinding naar buiten via een linux bakje met hierop CentOS, Squid en IPTables. Nu hebben de gebruikers voor normaal internet verkeer geen problemen, maar sinds kort hebben een aantal mensen software van GLS, om verzendlabels af te drukken.

Om de labels af te kunnen drukken, moet de software hiervoor verbinding leggen met een server van GLS over poort 3030 en/of 3031. En daarin stuit ik nu op problemen. Wat ik ook probeer, ik krijg het niet voor elkaar om verbinding via/naar poort 3030 of 3031 toe te laten. Heeft iemand een idee wat ik hiervoor in moet stellen?

In IPTables heb ik de volgende regels staan voor deze servers:

code:

-A OUTPUT -o eth1 -p tcp --dport 3030 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth1 -p tcp --dport 3031 -m state --state NEW,ESTABLISHED -j ACCEPT

Daarnaast heb ik in squid.conf de volgende regel staan:

code:

acl Safe_ports port 3030        # GLS Labels
acl Safe_ports port 3031        # GLS Labels backup

Toch lijkt elke verbinding met de servers op deze poortnummers geblokkeerd te worden. Iemand een idee waar dit nog aan zou kunnen liggen?

[Orion84]

Hoe ziet de policy / regels op je input chain er uit?

Output en Input hebben in iptables niet echt iets te maken met de richting van het verkeer van of naar het internet hè. Input gaat om pakketjes die vanaf het netwerk een netwerkkaart binnenkomen. Output gaat om pakketjes die vanuit het OS van de server zelf, via de netwerkkaart naar het netwerk willen.

Met deze regels sta je dus je linux machine toe om naar GLS te connecten over die poorten, maar je zal ook nog wat met je INPUT chain moeten om te zorgen dat andere machines ook via je linux machine naar die poorten kunnen.

En zorg je ook dat het verkeer dat vanuit GLS terugkomt netjes doorgang vindt?

[ Voor 6% gewijzigd door Orion84 op 18-07-2013 15:55 ]

[dulghar]

De inkomende verbindingen lopen via eth0. Onderstaande staat meteen in het begin van iptables.

code:

-A INPUT -i eth0 -j ACCEPT

Moet ik daarna nog steeds specifiek een poort aangeven welke doorgelaten wordt? Bijvoorbeeld:

code:

-A INPUT -p tcp -m tcp --dport  3030 -m state --state NEW,ESTABLISHED -j ACCEPT

[Hero of Time]

Je staat nu NEW en ESTABLISHED toe, maar niets dat hier gerelateerd aan is, dus RELATED. Oftewel, je stuurt een verzoek voor een verbinding, new, dan krijg je established terug, maar al het verkeer wat hierna komt, related, wordt tegengehouden. Gaat niet goed.

Ik ben geen ster in IPTables en het kan een heel drama zijn. Kijk daarom goed naar voorbeelden en zorg ten alle tijden dat je fysiek bij het systeem kan in geval je jezelf eruit gooit (been there, done that).

[Kees]

Hero of Time schreef op donderdag 18 juli 2013 @ 16:00:
Je staat nu NEW en ESTABLISHED toe, maar niets dat hier gerelateerd aan is, dus RELATED. Oftewel, je stuurt een verzoek voor een verbinding, new, dan krijg je established terug, maar al het verkeer wat hierna komt, related, wordt tegengehouden. Gaat niet goed.

Ik ben geen ster in IPTables en het kan een heel drama zijn. Kijk daarom goed naar voorbeelden en zorg ten alle tijden dat je fysiek bij het systeem kan in geval je jezelf eruit gooit (been there, done that).

Related is wat anders, al het verkeer wat over de established verbinding komt is established, maar daarom is het nog niet perse een slecht idee om het erbij te zetten, het zou een soort van ftp kunnen zijn waarbij de andere kant ook weer een connectie naar jou opent

[ Voor 11% gewijzigd door Kees op 18-07-2013 16:28 ]

[Orion84]

dulghar schreef op donderdag 18 juli 2013 @ 15:59:
De inkomende verbindingen lopen via eth0. Onderstaande staat meteen in het begin van iptables.

code:

-A INPUT -i eth0 -j ACCEPT

Moet ik daarna nog steeds specifiek een poort aangeven welke doorgelaten wordt? Bijvoorbeeld:

code:

-A INPUT -p tcp -m tcp --dport  3030 -m state --state NEW,ESTABLISHED -j ACCEPT

Nee, die algemene accept regel zou denk ik voldoende moeten zijn. Hoe ziet je forward chain er uit? Want die zit er natuurlijk ook nog tussen.

En voor de zekerheid: kijk even naar de output van iptables -L in plaats van wat er in je script staat. Wellicht werkt je script niet helemaal lekker, of zijn er nog andere processen die firewall regels schrijven

Edit: en voor de duidelijkheid: ik heb 0 ervaring met Squid, dus heb ook geen idee in hoeverre dat een boosdoener zou kunnen zijn.

[ Voor 14% gewijzigd door Orion84 op 18-07-2013 16:42 ]

[alm]

Wat ik me af zit te vragen of het verkeer via Squid loopt of via Masquerading (ofwel NAT)? Wellicht lukt het niet via Squid en dien je het via Masquerading af te handelen... Als de applicatie geen proxy ondersteund dan is dit laatste denk ik de enige optie.

[deadinspace]

Orion84 schreef op donderdag 18 juli 2013 @ 15:53:
Output en Input hebben in iptables niet echt iets te maken met de richting van het verkeer van of naar het internet hè.

QFT

alm schreef op donderdag 18 juli 2013 @ 16:58:
Wat ik me af zit te vragen of het verkeer via Squid loopt of via Masquerading (ofwel NAT)? Wellicht lukt het niet via Squid en dien je het via Masquerading af te handelen... Als de applicatie geen proxy ondersteund dan is dit laatste denk ik de enige optie.

Als je een HTTP-proxy in een transparante configuratie opzet (wat m.i. meestal wenselijk is), dan hoeven applicaties geen proxy te ondersteunen.

Maar het is goed mogelijk dat de verbindingen van die software helemaal geen HTTP is, en dan is dat weinig relevant.

Tot slot zou ik zelf niet zo snel uitgaand alles dichtzetten... Magoed, dat is een kwestie van smaak.

[ Voor 17% gewijzigd door deadinspace op 18-07-2013 20:21 ]

[Lizard]

Misschien dat het er niets mee te maken heeft, maae SeLinux staat standaard aan op CentOS 6.4.
Dit kan soms ook problemen opleveren met het gebruik van niet standaard poorten.

[dulghar]

Ik denk dat ik eerst nog iets moet toelichten. Een vrij essentieel deel wat ik conpleet vergeten ben te melden in de OP.

Onze server koppelt een aantal netwerk aan elkaar en werkt voor het ene netwerk als proxy en het andere netwerk als doorgeefluik.

Details:
eth0 = Netwerk 1 (gaat het internet op via squid)
eth1 = Internet
eth2 = niet gebruikt
eth3 = Netwerk 2 (maakt géén gebruik van squid, gaat rechtstreeks)

Nu speelt het volgende. Wanneer ik de applicatie via Netwerk 1 laat gaan - en dus ook via squid - krijg ik geen verbinding met de externe server. Laat ik de applicatie nu via Netwerk 2 lopen, wordt er zonder problemen verbinding gemaakt. Dat laat mij denken dat het probleem ergens in Squid zit.
Voor de hand liggend antwoord zou dan zijn, laat de applicatie standaard via Netwerk 2 lopen, maar dan hebben de collega's weer andere problemen.

@Lizard: SELinux staat niet op 'enforced'

[Hero of Time]

Kijk even in je Squid configuratie of je bepaalde sites of poorten op transparant kan zetten of excluden van z'n cache. Hebben mensen die op Netwerk 1 zitten een proxy ingesteld staan of niet? Dat is mij niet helemaal duidelijk.

Een andere optie, hoewel niet ideaal, is om met routering naar GLS het verkeer over Netwerk 2 te laten lopen, als dat mogelijk is.

[Orion84]

deadinspace schreef op donderdag 18 juli 2013 @ 20:20:
[...]

QFT

[afbeelding]

Ah, ja, goed om dat plaatje er weer even bij te hebben

[...]
Tot slot zou ik zelf niet zo snel uitgaand alles dichtzetten... Magoed, dat is een kwestie van smaak.

Persoonlijk vind ik het ook logischer om de output chain een accept all policy te geven en het filteren op de forward en input chains te doen. Sterker nog: packets die puur ter routering behandeld worden komen niet eens langs de output chain, dus het heeft geen zin om daar specifieke regels toe te voegen. Alleen in dit geval gaat het verkeer natuurlijk via Squid, waardoor het juist wel via de Input en Output chains loopt gok ik?

@topicstarter: mocht je toch het vermoeden krijgen dat het niet aan squid, maar aan de firewall ligt, post dan even (de relevante delen) van de output van iptables -L. Want met alleen een paar selectieve stukjes firewall script blijft het wat gokken hoe een en ander effectief precies is ingesteld.

[dulghar]

Hero of Time schreef op vrijdag 19 juli 2013 @ 09:53:
Kijk even in je Squid configuratie of je bepaalde sites of poorten op transparant kan zetten of excluden van z'n cache. Hebben mensen die op Netwerk 1 zitten een proxy ingesteld staan of niet? Dat is mij niet helemaal duidelijk.

Een andere optie, hoewel niet ideaal, is om met routering naar GLS het verkeer over Netwerk 2 te laten lopen, als dat mogelijk is.

Mensen die via Netwerk 1 werken hebben inderdaad een proxy ingesteld. Op netwerk 2 gaat alle verkeer buiten squid om.

@Orion84:

code:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
SSH_CHECK  tcp  --  anywhere             anywhere            tcp dpt:ssh state NEW
ACCEPT     icmp --  anywhere             anywhere            icmp echo-request
ACCEPT     icmp --  anywhere             anywhere            icmp destination-unreachable
ACCEPT     icmp --  anywhere             anywhere            icmp redirect
ACCEPT     icmp --  anywhere             anywhere            icmp time-exceeded
DROP       all  --  anywhere             10.x.x.255
DROP       all  --  anywhere             10.x.x.255
DROP       all  --  anywhere             192.168.x.255
DROP       all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
REJECT     tcp  --  anywhere             10.x.x.x            state NEW tcp dpt:microsoft-ds reject-with icmp-port-unreachable
REJECT     udp  --  anywhere             anywhere            udp dpt:netbios-nsreject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable
DROP       all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:arepa-cas state NEW,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:eppc state NEW,ESTABLISHED

Chain RH-Firewall-1-INPUT (1 references)
target     prot opt source               destination

Chain SSH_ATTACK (1 references)
target     prot opt source               destination
LOG        all  --  anywhere             anywhere            LOG level info prefix `SSH ATTACK: '
DROP       all  --  anywhere             anywhere

Chain SSH_CHECK (1 references)
target     prot opt source               destination
           all  --  anywhere             anywhere            recent: SET name: SSH side: source
SSH_ATTACK all  --  anywhere             anywhere            recent: UPDATE seconds: 60 hit_count: 4 name: SSH side: source
ACCEPT     all  --  anywhere             anywhere

[Orion84]

Daar staan dus de zaken die je eerder noemde niet tussen?

Zou je hem even kunnen vervangen door de output van iptables -L -v (zonder -v mist namelijk de info op welke interface de regel betrekking heeft, wat het wat onoverzichtelijk maakt, zeker omdat je 3 actieve interfaces hebt).

[dulghar]

Orion84 schreef op vrijdag 19 juli 2013 @ 11:57:
Daar staan dus de zaken die je eerder noemde niet tussen?

Zou je hem even kunnen vervangen door de output van iptables -L -v (zonder -v mist namelijk de info op welke interface de regel betrekking heeft, wat het wat onoverzichtelijk maakt, zeker omdat je 3 actieve interfaces hebt).

Bij deze.

code:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  lo     any     anywhere             anywhere
37697 6850K ACCEPT     all  --  eth0   any     anywhere             anywhere
 128K   46M ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
    2   104 SSH_CHECK  tcp  --  any    any     anywhere             anywhere            tcp dpt:ssh state NEW
   27  1565 ACCEPT     icmp --  any    any     anywhere             anywhere            icmp echo-request
   20  3377 ACCEPT     icmp --  any    any     anywhere             anywhere            icmp destination-unreachable
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere            icmp redirect
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere            icmp time-exceeded
    0     0 DROP       all  --  any    any     anywhere             10.x.x.255
    0     0 DROP       all  --  any    any     anywhere             10.x.x.255
37380 3074K DROP       all  --  any    any     anywhere             192.168.x.255
 5014  644K DROP       all  --  any    any     anywhere             anywhere

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
2581K 1967M RH-Firewall-1-INPUT  all  --  any    any     anywhere             anywhere
2533K 1963M ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
46542 3390K ACCEPT     all  --  br3    eth1    anywhere             anywhere
   16   804 REJECT     tcp  --  br3    eth0    anywhere             10.x.x.x            state NEW tcp dpt:microsoft-ds reject-with icmp-port-unreachable
  462 43812 REJECT     udp  --  br3    eth0    anywhere             anywhere            udp dpt:netbios-ns reject-with icmp-port-unreachable
 1249  130K REJECT     all  --  br3    eth0    anywhere             anywhere            reject-with icmp-port-unreachable
    0     0 DROP       all  --  any    any     anywhere             anywhere

Chain OUTPUT (policy ACCEPT 151K packets, 70M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  any    eth1    anywhere             anywhere            tcp dpt:arepa-cas state NEW,ESTABLISHED
    0     0 ACCEPT     tcp  --  any    eth1    anywhere             anywhere            tcp dpt:eppc state NEW,ESTABLISHED

Chain RH-Firewall-1-INPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain SSH_ATTACK (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  any    any     anywhere             anywhere            LOG level info prefix `SSH ATTACK: '
    0     0 DROP       all  --  any    any     anywhere             anywhere

Chain SSH_CHECK (1 references)
 pkts bytes target     prot opt in     out     source               destination
    2   104            all  --  any    any     anywhere             anywhere            recent: SET name: SSH side: source
    0     0 SSH_ATTACK  all  --  any    any     anywhere             anywhere            recent: UPDATE seconds: 60 hit_count: 4 name: SSH side: source
    2   104 ACCEPT     all  --  any    any     anywhere             anywhere

[Orion84]

Ah, ja, daarmee zijn een aantal regels al wat logischer dan in eerste instantie leek.

Hoe dan ook staan de regels die je in je startpost noemt hier dus volgens mij niet tussen?

Verder zitten er nog wel wat onlogische dingetjes in:
- Output policy staat al op Accept, waarom dan nog specifieke accept regels toevoegen? Al het andere verkeer wat door de output chain gaat wordt toch al geaccepteerd.
- Policies staat op accept, maar enkele chains eindigen wel in een DROP rule. Zet dan gewoon de policy op DROP?
- Gekke constructie met die RH-Firewall-1-INPUT chain waar niks in zit (ook geen algemene RETURN rule). Ik vraag me af hoe FORWARD pakketjes nu precies gefilterd worden, maar wellicht dat iptables bij een lege chain automatisch returnt of hem zelfs negeert?

[dulghar]

Orion84 schreef op vrijdag 19 juli 2013 @ 13:57:
Ah, ja, daarmee zijn een aantal regels al wat logischer dan in eerste instantie leek.

Hoe dan ook staan de regels die je in je startpost noemt hier dus volgens mij niet tussen?

De regels in de startpost horen bij:

code:

Chain OUTPUT (policy ACCEPT 151K packets, 70M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  any    eth1    anywhere             anywhere            tcp dpt:arepa-cas state NEW,ESTABLISHED
    0     0 ACCEPT     tcp  --  any    eth1    anywhere             anywhere            tcp dpt:eppc state NEW,ESTABLISHED

Verder zitten er nog wel wat onlogische dingetjes in:
- Output policy staat al op Accept, waarom dan nog specifieke accept regels toevoegen? Al het andere verkeer wat door de output chain gaat wordt toch al geaccepteerd.

Deze regels (zie regels OP) heb ik eens toegevoegd om te kijken of dit enige vorm van verbetering geeft.

- Policies staat op accept, maar enkele chains eindigen wel in een DROP rule. Zet dan gewoon de policy op DROP?

Hierin zitten meerdere regels die voor dit topic niet van belang zijn. Vandaar dat ik ze er hier uit heb gehaald. De meeste regels zijn accept.

- Gekke constructie met die RH-Firewall-1-INPUT chain waar niks in zit (ook geen algemene RETURN rule). Ik vraag me af hoe FORWARD pakketjes nu precies gefilterd worden, maar wellicht dat iptables bij een lege chain automatisch returnt of hem zelfs negeert?

Van deze regel heb ik ook geen idee. Ik heb deze er niet ingezet. Deze regel zat er reeds in toen we de server kregen van onze leverancier (welke deze ook voor heeft geconfigureerd).

Nog wel leuk om toe te voegen. De configuratie van squid en iptables is exact gelijk aan de configuratie van onze vorige server. Via onze vorige server werkte het zonder problemen. Deze draaide op CentOS 5.X.

[Orion84]

Ah, ok, dat is het irritante van dat die poortnummers vertaald worden in de standaard services die er bijhoren. Ik vat 'm nu iets beter

Anyway: als ik me niet vergis gaat een pakketje door de INPUT chain van eth0, dan naar squid en dan naar de OUTPUT chain van eth1. Daar legt de firewall ze geen strobreed in de weg voor zover ik kan opmaken uit je iptables output.

Dus dan zou het toch in squid moeten zitten?

[alm]

Orion84 schreef op vrijdag 19 juli 2013 @ 13:57:
- Gekke constructie met die RH-Firewall-1-INPUT chain waar niks in zit (ook geen algemene RETURN rule). Ik vraag me af hoe FORWARD pakketjes nu precies gefilterd worden, maar wellicht dat iptables bij een lege chain automatisch returnt of hem zelfs negeert?

Da's een standaard Red Hat Enterprise Linux (en dus ook CentOS) firewall chain. Denk dat ze daar de zaken in zetten die je via de Firewall GUI configureert.

dulghar schreef op vrijdag 19 juli 2013 @ 15:06:
Nog wel leuk om toe te voegen. De configuratie van squid en iptables is exact gelijk aan de configuratie van onze vorige server. Via onze vorige server werkte het zonder problemen. Deze draaide op CentOS 5.X.

Door verschillende kernels, iptables en wellicht squid versies, zou daar wel eens verschil in kunnen zitten. Is de output van iptables -L -v (en eventueel -n voor numerieke weergave) hetzelfde als op de oude server? Je bent immers van CentOS 5.x naar CentOS 6.4 overgegaan... Is alles helemaal up-to-date ('yum update' gedraaid bijvoorbeeld)?

[dulghar]

Nou, na lang zoeken lijkt het probleem zeer waarschijnlijk in een andere hoek te zitten.
De output van beide iptables was gelijk, dus daar kon het probleem haast niet in zitten.

Uiteindelijk zijn we erachter gekomen, na een wireshark-sessie dat, wanneer in de software van GLS de proxy server aangevinkt en ingevuld wordt, deze hier eigenlijk niets mee doet. Er wordt geen enkel verkeer van de software naar de opgegeven proxy-server gestuurd. Dus het probleem ligt nu bij GLS. Daar mogen ze uitzoeken waardoor dit niet werkt.

Blijkbaar is de software van GLS ge-update naar de nieuwste versie, nadat wij onze server hebben vervangen. De reden hiervoor was dat, toen wij de server hebben vervangen, SELinux een goede werking van Squid voorkwam. Hierdoor werkte de GLS software niet meer en hebben de collega's in het magazijn de software ge-update om te kijken of dit het probleem zou verhelpen. Kortom, mooie samenloop van omstandigheden.

Dank aan allen voor het meedenken.

[Thc_Nbl]

Je kan ook via een proxy scriptje de hostname of domain buiten squid om laten gaan.
Dat heb ik voor de mijnpost gedaan.
GLS gaat het namelijk niet oplossen voor je, net zoals Mijnpost dat niet deed.
Reden voor hun is dat het namelijk wel goed werkt zonder de proxy.
Dus je probleem zit in de proxy. ( instellingen )

in een proxy bestandje kan je het volgende zetten.
( of via policies pushen naar de client pc's. )

voorbeeldje bestand wpad.dat of proxy.pac.

function FindProxyForURL(url, host) {
if (shExpMatch(url,"*.*.gls.nl/*")) {return "DIRECT";}

if (isInNet(myIpAddress(), "192.168.1.0", "255.255.255.0"))
return "PROXY 192.168.1.254:8080";
}

Ik heb de proxy setting via DHCP en autodiscovery gedaan ( dns setting )

suc6.

[alm]

Dat werkt alleen als je ook zonder proxy instelling op de pc het internet op kunt en dat is in bovenstaande blijkbaar niet een mogelijkheid.