Példa egy összetettebb tűzfal konfigurálására.

Vegyük az előző fejezetben már megismert céget. Hosszas tanakodás után a cégnél úgy döntenek, hogy a következő szolgáltatásokat fogják nyújtani a külvilág, és alkalmazottaik felé:

  1. Az alkalmazottak használhatják az Internetet webezésre,

  2. Az alkalmazottak elérhetik az Internetet ftp protokollon keresztül,

  3. Az alkalmazottak elérhetik az Interneten létesített leveles ládáikat POP3 protokollon,

  4. Az alkalmazottak elérhetik a DMZ-ben lévő gépeket HTTP,

  5. FTP,

  6. és SSH protokollon keresztül.

  7. Az Internetről elérhetőek a DMZ-ben lévő gépek HTTP,

  8. és FTP protokollal (csak anonymous módon).

  9. A DMZ-ben levo gepeken levo tartalom egy resze HTTP

  10. és FTP mirroron kersztul frissitodik.

Ezen protokollok közül most (még) csak a HTTP és az FTP-hez van natív proxy, így az ssh-hoz, és a POP3-hoz Plug proxyt kell használnunk. Ezen kívül érdemes külön szabályozást alkalmazni mind a három irányhoz (DMZ<->internet, belső<->internet, belső<->DMZ).

Első lépésként nevezzük el a szolgáltatásokat, hogy utána tudjunk rájuk hivatkozni.

  1. bihttp (belső hálózatról internet elérése http protokollon keresztül)

  2. biftp

  3. bipop

  4. bdhttp (belső hálózat - DMZ irányú http)

  5. bdftp

  6. bdssh

  7. idhttp (Internet - DMZ)

  8. idftp

  9. dihttp

  10. diftp

Nézzük meg a Service-eket egyenként, közelebbről. Elsőnek vegyük az Internet elérését a belső hálóról HTTP protokollon keresztül. (Vagyis a web proxy beállítása.) Legyünk szigorúak az alkalmazottakkal, és tiltsuk el őket a POST parancs használatától és a kliens típusát írjuk át egy általunk megadottra.

Example 4-12.


	    class BIHttp(HttpProxy):
	        def config(self):
	            HttpProxy.config(self)
	            self.transparent_mode = 0
	            self.request["POST"] = (Http.HTTP_DROP)
	            self.request_headers["User-Agent"] = \
			[Http.HTTP_CHANGE_VALUE, "Lynx/2.8.3rel.1"]

	  
Az ehhez tartozó Service és Listener definíció az InbandChainer tipusú Chainer-t használja, és nem transzparens módon működik, azaz a kliensekben be kell állítanunk a tűzfalat, mint webproxyt. Ha a cégnél már található egy hagyományos értelemben vett (cache) webproxy, akkor általában az is a tűzfalon belül található. Ebben az esetben az is megoldás ha TransparentChainert használunk, és a http proxynkat is transzparens üzemmódra állítjuk.

Hozzuk létre az FTP-hez szükséges osztályt is (belsőhálózat - Internet irány).

Example 4-13.

	    class BIFtp(FtpProxyAllow):
	        def config(self):
	            FtpProxy.config(self)
	            self.fw_server_data.ip_s="10.9.8.7"
	            self.fw_client_data.ip_s="192.168.1.1"
	  
A POP3 protokollhoz az előző fejezetben már megismert MyPlug osztályt rendeljük hozzá.

A kliensektől a DMZ-be irányuló forgalomnál mindent megengedünk, viszont ebben az irányban transparens-ként üzemeltetjük a proxy-t. Így a megfelelő osztály definíciója:

Example 4-14.


	    class BDHttp(HttpProxy):
	        def config(self):
		    self.transparent_mode = 1
	            self.fw_server_data.ip_s="10.9.8.7"
	            self.fw_client_data.ip_s="192.168.1.1"

	  
A belső hálózat - DMZ irányú ftp forgalomhoz kapcsolódó osztály csak a következő részben különbözik a belsőhálózat- Internet irányútól:

Example 4-15.

	    class BDFtp(FtpProxyAllow):
	        def config(self):
	            FtpProxyAllow.config(self)
	            self.fw_server_data.ip_s="10.9.8.7"
	            self.fw_client_data.ip_s="192.168.1.1"
	  

SSH-hoz pedig újfent a MyPlug osztályt fogjuk használni, ugyanúgy, mint a DMZ-ből az internet fele iranyuló HTTP es POP3 proxyknal is.

Végül az Internetről, a cég felé irányuló forgalmat vegyük szemügyre.

Example 4-16.


	    class IDHttp(HttpProxy):
	        def config(self):
	            HttpProxy.config(self)
		    self.transparent_mode = 1

	  

Az FTP részben annyi változás van az eddigiekhez képest, hogy csakis anonymous ftp csatlakozást engedünk meg. FIXME: ez itt nem igaz az új proxyra

Example 4-17.

	    def user(self, dir, uname):
	        if uname == "ftp"
		    return Z_ACCEPT
	        elsif uname == "anonymous"
		    return Z_ACCEPT
	        return Z_REJECT
	  
Már csak pár dolog van hátra. Az egyik, hogy a transparens proxy-k működéséhez szükséges némi csomagszintű rásegítés. Ezt 2.2-es kerneleknél az ipchains-szel, és annak REDIRECT funkciójával tehetjük meg.

Amihez szükségünk van erre: A belső hálózatról az Internet felé menő FTP és POP3 kapcsolat, illetve a DMZ felé menő HTTP, FTP és SSH kapcsolat. Ezt megtehetjük a következő parancsokkal:

Example 4-18.

	    ipchains -A input -j eth2 -d 192.168.0.0/24 80 -j REDIRECT 3080
	    ipchains -A input -j eth2 -d 192.168.0.0/24 22 -j REDIRECT 3022
	    ipchains -A input -j eth2 -d 192.168.0.0/24 21 -j REDIRECT 3021
	    ipchains -A input -j eth2 -d 0/0 21 -j REDIRECT 2021
	    ipchains -A input -j eth2 -d 0/0 110 -j REDIRECT 2110
	  
Az ftp-hez, ha a passiv modot is meg akarjuk engedni, akkor kell meg egy redirect rule sajnos ahhoz, hogy az adat csatorna ki tudjon epulni:

Example 4-19.

	    ipchains -A input -j eth2 -d 0/0 1024: -j REDIRECT 0
	  
A zónák definíciójában, az előző példához analóg módon állítsuk be a megengedett kapcsolatok típusokat és irányokat.

Example 4-20.

	  
	    Zorp.zones = [
	        InetZone("intranet","192.168.1.0", "255.255.255.0", None,
		    outbound_services["BIHttp","BIFtp","BIPop","BDHttp","BDFtp","BDSsh"],
		    inbound_services[]),
	        InetZone("DMZ", "192.168.0.0", "255.255.255.0", None,
	            outbound_services["DIHttp","DIFtp"],
		    inbound_services["BDHttp","BDFtp","BDSsh","IDHttp","IDFtp"]),
	        InetZone("internet", "0.0.0.0", "0.0.0.0", None,
		    outbound_services["IDHttp","IDFtp"],
		    inbound_services["BIHttp","BIFtp","BIPop","DIHttp","DIFtp"])]
	  
A teljes policy-t megtalálhatjuk az 1. függelékben.