Re: Byta till Shorewall? (Förr: Re: Trixa med ipchains...)
Heh, det här påminner mig om varför jag till och med tröttnade på Shorewall och gick över till FreeBSD och PF (samt bättre kärnmoduler för mitt atheros-kort, iofs) :-) Oscar 2008/8/4 Martin Leben [EMAIL PROTECTED] Magnus Ihse Bursie wrote: Nä, det har du rätt i. Jag har nog varit lite rädd i onödan för binds konfigurationsfiler bara. :) Tusen tack för hjälpen! Jag har implementerat din lösning och den fungerar hur bra som helst. Tänk att det var så enkelt. :) Gôtt att det funkar! Varsågod. :-) Känner själv lite vånda varje år när det är dags att fixa SSL-cert. När jag såg ditt brandväggskript i det ursprungliga brevet så påmindes jag dessutom om varför jag började använda Shorewall som brandvägg. Den beskrivs som ... a high-level tool for configuring Netfilter. När jag ändå håller på och prackar på folk mina konfigurationsfiler så kan jag lika gärna infoga min Shorewall-konfig för den som är intresserad. :-) Helt vanlig NAT plus en server på insidan. (eth1 är externt. Har statisk IP, därav avsaknaden av dhcp i interfaces:net eth1.) # cd /etc/shorewall # egrep -v ^( *$|#) * | egrep -v (Makefile|shorewall\.conf|README\.txt): interfaces:net eth1 detect tcpflags,norfc1918,nosmurfs,logmartians interfaces:loc eth0 detect dhcp,tcpflags,detectnets,nosmurfs masq:eth1 eth0 params:matthew=192.168.221.3 policy:loc net ACCEPT policy:loc $FW ACCEPT policy:loc all REJECT info policy:$FW all ACCEPT policy:net $FW DROP policy:net loc DROP info policy:net all DROP info policy:all all REJECT info routestopped:eth1 - rules:Ping/ACCEPT all all rules:SSH/ACCEPTall $FW rules:SMTP/DNAT net loc:$matthew rules:IMAP/DNAT net loc:$matthew rules:IMAPS/DNATnet loc:$matthew rules:HTTP/DNAT net loc:$matthew rules:HTTPS/DNATnet loc:$matthew rules:FTP/DNAT net loc:$matthew rules:DNAT net loc:$matthew:22 tcp 3527 zones:fwfirewall zones:net ipv4 zones:loc ipv4 (Ingen av filerna Makefile, shorewall.conf eller README.txt har jag pillat i, vad jag kan minnas.) God natt! /Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trixa med ipchains...
Hej Magnus! Ditt problem är rätt vanligt, men till att börja med skall jag förtydliga att detta inte är ipchains utan netfilter som ställs in med kommandot iptables. Ipchains har jag för övrigt obefintliga kunskaper om. För att vara ännu lite petigare så har du ett allvarligt problem i din brandvägg som öppnar upp möjligheten för en illasinnad person att köra godtyckligt UDP program på din dator 192.168.0.12 (vesta) på port 80. HTTP protokollet går nämligen enbart över TCP för att tillhandahålla en webbsida. Så till ditt problem. Du har redan fått ett par förslag på hur du kan lösa ditt problem med alt. 1 så det kommer jag inte kommentera. Däremot har du inte fått några förslag på hur du löser problemet med alt. 2. Detta tänker jag försöka förklara för dig och listan. Om någon har några andra åsikter, eller om jag missförstått något själv, så rätta mig gärna :-) Grundproblemet till att det inte fungerar med din externa adress inne ifrån ditt LAN är att du bara routar från $OUTSIDE. Om du väl hade routat från $INSIDE också så hade det ändå inte fungerat. Varför frågar du dig säkert. Svaret är lite komplicerat men jag skall försöka förklara. När du försöker surfa till tex http://wiki.ihse.net/ så kommer först en förfrågan till din DNS om vad wiki.ihse.net har för ipadress, svaret blir då 77.110.63.65 (din externa adress). Vidare kommer din webbläsare att försöka ansluta till just 77.110.63.65, eftersom du DNAT:at, Destination Network Address Translation, in denna till vesta kommer vesta i sin tur få en förfrågan på port 80 med avsändare satt till den dator du surfade ifrån och svaret på förfrågan skickas dit. Så långt har allt gått rätt till, men när svaret når den dator du surfar ifrån kommer denna att slänga paketet som ogiltigt då den inte räknade med att svert skulle komma från 192.168.0.2 (vesta) utan från 77.110.63.65 (routern). Lösningen till det här är att köra något som heter SNAT, Source Network Address Translation, på routern som gör i princip samma sak som DNAT, fast motsatt. Det DNAT åstadkommer är att den översätter vilken ip som förfrågan egentligen skall till, i ditt fall 192.168.0.2. SNAT berör istället varifrån förfrågan kom. Om du skulle köra det på din router skulle det innebära att även om du surfade från, låt säga 192.168.0.123 så skulle vesta (måldatorn) inte se detta utan istället din routers ipadress. Nedanstående skiss är en princip skiss över hur paketen går i ditt LAN. Utan SNAT: webbklient - router - vesta - webbklient Med SNAT: webbklient - router - vesta - router - webbklient Hoppas detta gjorde dig/er klokare. Mvh, Torbjörn Svensson Quoting Magnus Ihse Bursie [EMAIL PROTECTED]: Jag blir inte klok på hur jag ska göra för att få till det här. Någon som kan hjälpa till? /Magnus This message was sent using IMP, the Internet Messaging Program. pgpSvsggCXBUL.pgp Description: PGP Digital Signature
Trixa med ipchains...
Jag har följande scenario: * Ett LAN med ett antal datorer och gadgets på * En NSLU2 som kör Debian och som agerar brandvägg/router (och dessutom DNS-/DHCP-server etc, men det är inte relevant nu) * En domän (ihse.net) där jag har skapat adresser för specifika tjänster (t.ex. wiki.ihse.net, mail.ihse.net). * Jag gör port forwardning från min NSLU2 (som heter Jana) på t.ex. port 80 och 443 till en mer kraftfull dator inne på nätet (som heter Vesta) som har en Apache. * På Vesta har jag konfigurerat upp virtuella servrar, så att man kommer till webbmail om man surfar till mail.ihse.net och en wiki för wiki.ihse.net. * Dessa virtuella hostar har i DNS:en samma IP-adress, nämligen min externa IP-adress. Resultatet av denna konfiguration är att det går alldeles utmärkt att sitta nånstans på Internet och komma åt olika tjänster på mail.ihse.net och wiki.ihse.net. Men. Det går inte att komma åt tjänsterna på insidan av LAN:et. Eftersom wiki.ihse.net resolverar till min externa adress, kommer anropet från insidan av LAN:et att riktas till Jana (routern). Den ser att anropet kommer från insidan av LAN:et och försöker inte göra någon port forwarding. Istället får jag reda på att ingen lyssnar på port 80 på den adressen. Så, hur löser man detta? Jag har hittills gjort så att jag fuskat, och lagt in en rad för wiki.ihse.net som resolverar till Vesta:s adress i /etc/hosts på alla maskiner på LAN:et. Det har fungerat men känts lite hackigt. Nu har jag precis skaffat en Nokia N810 (grymt kul pryl, f.ö.! :-)) och min fru en laptop, och då blev det plötsligt uppenbart hur otillräcklig en sådan lösning är -- eftersom WLAN:et är på insidan av routern, så måste man ändra i /etc/hosts varje gång man tar N810:an/laptopen innanför eller utanför lägenheten. Det duger inte. Så jag är tillbaka nu på att försöka lösa problemet på ett bättre sätt. Men fasen vet hur. Två idéer: 1) Ändra så att DNS-servern lämnar ut olika adressuppgifter för wiki.ihse.net om förfrågan kommer inifrån LAN:et än utifrån. 2) Ändra ipchains-reglerna på routern, så att den gör som jag vill. Som jag förstått är det är 1) knepigt att få till och lite läskigt; jag vill ju inte att jag plötsligt börjar sitta och berätta för omvärlden att wikin ligger på 192.168... Alltså har jag satsat på 2. Men det är inte lätt. Jag har suttit och slitit lite med dokumentationen för ipchains, men jag får ingen rätsida på hur jag ska göra. Det brukar sluta med att Jana äter upp mina utgående accesser på port 80 vilket inte är riktigt vad jag tänkt mig. :-) Jag använder ett handhackat skript för att sätta upp mina nuvarande ipchains-regler. Så här ser de relevanta delarna ut just nu: --- INSIDE=eth0 OUTSIDE=eth1 EXTERNAL_IP=77.110.63.65 # Load firewalling modules modprobe iptable_filter modprobe ip_conntrack modprobe ip_conntrack_ftp modprobe ipt_LOG modprobe ipt_state # Load masquerading module modprobe iptable_nat ## Waste any previous iptables setup, and create new chain iptables -F iptables -X iptables -F -t nat iptables -X -t nat iptables -N jwall # Accept new connections from the inside iptables -A jwall -m state --state NEW -i ! $OUTSIDE -j ACCEPT # Accept all packets belonging to open connections iptables -A jwall -m state --state ESTABLISHED,RELATED -j ACCEPT # Accept IDENT packets iptables -A jwall -p TCP --destination-port ident -j ACCEPT # Accept ICMP packets iptables -A jwall -p ICMP -j ACCEPT # Ignore (drop) DHCP DISCOVER (?) packets iptables -A jwall -p UDP --source-port bootpc -d 255.255.255.255 --destination-port bootps -j DROP # Accept DNS iptables -A jwall -p UDP --destination-port domain -j ACCEPT iptables -A jwall -p TCP --destination-port domain -j ACCEPT # Drop the rest iptables -A jwall -j DROP ## Jump to our new chain from the INPUT and FORWARD chains iptables -A INPUT -j jwall iptables -A FORWARD -j jwall # Portforward http to vesta HTTPFORWARDADDR=192.168.0.12 HTTPPORT=80 iptables -t nat -A PREROUTING -i $OUTSIDE -p tcp --dport $HTTPPORT -j DNAT --to-destination $HTTPFORWARDADDR iptables -t nat -A PREROUTING -i $OUTSIDE -p udp --dport $HTTPPORT -j DNAT --to-destination $HTTPFORWARDADDR iptables -I FORWARD -i $OUTSIDE -p tcp --dport $HTTPPORT -j ACCEPT iptables -I FORWARD -i $OUTSIDE -p udp --dport $HTTPPORT -j ACCEPT --- Jag blir inte klok på hur jag ska göra för att få till det här. Någon som kan hjälpa till? /Magnus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trixa med ipchains...
Magnus Ihse Bursie wrote:
Det går inte att komma åt tjänsterna på insidan av LAN:et. Eftersom
wiki.ihse.net resolverar till min externa adress, kommer anropet från
insidan av LAN:et att riktas till Jana (routern). Den ser att anropet
kommer från insidan av LAN:et och försöker inte göra någon port
forwarding. Istället får jag reda på att ingen lyssnar på port 80 på den
adressen.
[...]
Så jag är tillbaka nu på att försöka lösa problemet på ett bättre sätt.
Men fasen vet hur. Två idéer:
1) Ändra så att DNS-servern lämnar ut olika adressuppgifter för
wiki.ihse.net om förfrågan kommer inifrån LAN:et än utifrån.
2) Ändra ipchains-reglerna på routern, så att den gör som jag vill.
Som jag förstått är det är 1) knepigt att få till och lite läskigt; jag
vill ju inte att jag plötsligt börjar sitta och berätta för omvärlden
att wikin ligger på 192.168... Alltså har jag satsat på 2.
Hej Magnus!
Ånej, jag tycker du ska gå tillbaka till den första lösningen. Den är inte alls
krånglig. :-) (Fast det är ju ingenting som man VET hur det funkar...!) Man gör
det genom att använda view i BIND. Man presenterar olika vyer beroende på
vilken IP-adress förfrågan kommer från. Infogar den konfiguration jag själv
använder nedan.
/etc/bind/db.example.com-intern och /etc/bind/db.example.com-extern som
nämns nedan är helt vanliga zon-filer.
Lycka till!
mvh
/Martin Leben
dwarf:/home# egrep -v ^(//|#|$) /etc/bind/named.conf
include /etc/bind/named.conf.options;
view intern {
match-clients { 127.0.0.0/8; 10.0.0.0/8; };
allow-transfer { 127.0.0.0/8; };
include /etc/bind/named.conf.intern;
};
view extern {
match-clients { any; };
recursion no;
allow-transfer { 127.0.0.0/8; };
include /etc/bind/named.conf.extern;
};
dwarf:/home# egrep -v ^(//|#|$) /etc/bind/named.conf.intern
zone . {
type hint;
file /etc/bind/db.root;
};
zone localhost {
type master;
file /etc/bind/db.local;
};
zone 127.in-addr.arpa {
type master;
file /etc/bind/db.127;
};
zone 0.in-addr.arpa {
type master;
file /etc/bind/db.0;
};
zone 255.in-addr.arpa {
type master;
file /etc/bind/db.255;
};
include /etc/bind/zones.rfc1918;
zone example.com {
type master;
file /etc/bind/db.example.com-intern;
};
zone 0.0.10.in-addr.arpa {
type master;
file /etc/bind/db.0.0.10;
};
dwarf:/home# egrep -v ^(//|#|$) /etc/bind/named.conf.extern
zone example.com {
type master;
file /etc/bind/db.example.com-extern;
};
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trixa med ipchains...
Magnus Ihse Bursie wrote: Så, hur löser man detta? Jag har hittills gjort så att jag fuskat, och lagt in en rad för wiki.ihse.net som resolverar till Vesta:s adress i /etc/hosts på alla maskiner på LAN:et. Kan du inte köra en DNS-server (endast för internt bruk) på maskinen Vesta, och ändra i DHCP-servern så att den anger Vesta som DNS för klienterna? -- | Janek Hellqvist | | [EMAIL PROTECTED] | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Trixa med ipchains...
Jag var i samma dilemma så jag valde att outsourcea min dns till loopia sen satte jag upp en interndns som sköter mitt svarta nät. Det fungerar bra för mig då jag väldigt sällan skaffar ny domän eller ändrar i dns'en. Men det borde ju fungera ifall du sätter upp en interndns och sedan forwardar allt som inte ska till ihse.net till din yttre dns på NSLU2. //-Job -Original Message- From: Magnus Ihse Bursie [mailto:[EMAIL PROTECTED] Sent: den 3 augusti 2008 15:06 To: debian-user-swedish@lists.debian.org Subject: Trixa med ipchains... Jag har följande scenario: * Ett LAN med ett antal datorer och gadgets på * En NSLU2 som kör Debian och som agerar brandvägg/router (och dessutom DNS-/DHCP-server etc, men det är inte relevant nu) * En domän (ihse.net) där jag har skapat adresser för specifika tjänster (t.ex. wiki.ihse.net, mail.ihse.net). * Jag gör port forwardning från min NSLU2 (som heter Jana) på t.ex. port 80 och 443 till en mer kraftfull dator inne på nätet (som heter Vesta) som har en Apache. * På Vesta har jag konfigurerat upp virtuella servrar, så att man kommer till webbmail om man surfar till mail.ihse.net och en wiki för wiki.ihse.net. * Dessa virtuella hostar har i DNS:en samma IP-adress, nämligen min externa IP-adress. Resultatet av denna konfiguration är att det går alldeles utmärkt att sitta nånstans på Internet och komma åt olika tjänster på mail.ihse.net och wiki.ihse.net. Men. Det går inte att komma åt tjänsterna på insidan av LAN:et. Eftersom wiki.ihse.net resolverar till min externa adress, kommer anropet från insidan av LAN:et att riktas till Jana (routern). Den ser att anropet kommer från insidan av LAN:et och försöker inte göra någon port forwarding. Istället får jag reda på att ingen lyssnar på port 80 på den adressen. Så, hur löser man detta? Jag har hittills gjort så att jag fuskat, och lagt in en rad för wiki.ihse.net som resolverar till Vesta:s adress i /etc/hosts på alla maskiner på LAN:et. Det har fungerat men känts lite hackigt. Nu har jag precis skaffat en Nokia N810 (grymt kul pryl, f.ö.! :-)) och min fru en laptop, och då blev det plötsligt uppenbart hur otillräcklig en sådan lösning är -- eftersom WLAN:et är på insidan av routern, så måste man ändra i /etc/hosts varje gång man tar N810:an/laptopen innanför eller utanför lägenheten. Det duger inte. Så jag är tillbaka nu på att försöka lösa problemet på ett bättre sätt. Men fasen vet hur. Två idéer: 1) Ändra så att DNS-servern lämnar ut olika adressuppgifter för wiki.ihse.net om förfrågan kommer inifrån LAN:et än utifrån. 2) Ändra ipchains-reglerna på routern, så att den gör som jag vill. Som jag förstått är det är 1) knepigt att få till och lite läskigt; jag vill ju inte att jag plötsligt börjar sitta och berätta för omvärlden att wikin ligger på 192.168... Alltså har jag satsat på 2. Men det är inte lätt. Jag har suttit och slitit lite med dokumentationen för ipchains, men jag får ingen rätsida på hur jag ska göra. Det brukar sluta med att Jana äter upp mina utgående accesser på port 80 vilket inte är riktigt vad jag tänkt mig. :-) Jag använder ett handhackat skript för att sätta upp mina nuvarande ipchains-regler. Så här ser de relevanta delarna ut just nu: --- INSIDE=eth0 OUTSIDE=eth1 EXTERNAL_IP=77.110.63.65 # Load firewalling modules modprobe iptable_filter modprobe ip_conntrack modprobe ip_conntrack_ftp modprobe ipt_LOG modprobe ipt_state # Load masquerading module modprobe iptable_nat ## Waste any previous iptables setup, and create new chain iptables -F iptables -X iptables -F -t nat iptables -X -t nat iptables -N jwall # Accept new connections from the inside iptables -A jwall -m state --state NEW -i ! $OUTSIDE -j ACCEPT # Accept all packets belonging to open connections iptables -A jwall -m state --state ESTABLISHED,RELATED -j ACCEPT # Accept IDENT packets iptables -A jwall -p TCP --destination-port ident -j ACCEPT # Accept ICMP packets iptables -A jwall -p ICMP -j ACCEPT # Ignore (drop) DHCP DISCOVER (?) packets iptables -A jwall -p UDP --source-port bootpc -d 255.255.255.255 --destination-port bootps -j DROP # Accept DNS iptables -A jwall -p UDP --destination-port domain -j ACCEPT iptables -A jwall -p TCP --destination-port domain -j ACCEPT # Drop the rest iptables -A jwall -j DROP ## Jump to our new chain from the INPUT and FORWARD chains iptables -A INPUT -j jwall iptables -A FORWARD -j jwall # Portforward http to vesta HTTPFORWARDADDR=192.168.0.12 HTTPPORT=80 iptables -t nat -A PREROUTING -i $OUTSIDE -p tcp --dport $HTTPPORT -j DNAT --to-destination $HTTPFORWARDADDR iptables -t nat -A PREROUTING -i $OUTSIDE -p udp --dport $HTTPPORT -j DNAT --to-destination $HTTPFORWARDADDR iptables -I FORWARD -i $OUTSIDE -p tcp --dport $HTTPPORT -j ACCEPT iptables -I FORWARD -i $OUTSIDE -p udp --dport $HTTPPORT -j ACCEPT --- Jag blir inte klok på hur jag ska göra för att få till det här. Någon som kan hjälpa till? /Magnus -- To UNSUBSCRIBE, email
Re: Trixa med ipchains...
Martin Leben wrote: Hej Magnus! Ånej, jag tycker du ska gå tillbaka till den första lösningen. Den är inte alls krånglig. :-) (Fast det är ju ingenting som man VET hur det funkar...!) Man gör det genom att använda view i BIND. Man presenterar olika vyer beroende på vilken IP-adress förfrågan kommer från. Infogar den konfiguration jag själv använder nedan. Nä, det har du rätt i. Jag har nog varit lite rädd i onödan för binds konfigurationsfiler bara. :) Tusen tack för hjälpen! Jag har implementerat din lösning och den fungerar hur bra som helst. Tänk att det var så enkelt. :) /Magnus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Byta till Shorewall? (Förr: Re: Trixa med ipchains...)
Den den 4 augusti 2008 00:20 skrev Martin Leben [EMAIL PROTECTED]: Magnus Ihse Bursie wrote: Nä, det har du rätt i. Jag har nog varit lite rädd i onödan för binds konfigurationsfiler bara. :) Tusen tack för hjälpen! Jag har implementerat din lösning och den fungerar hur bra som helst. Tänk att det var så enkelt. :) Gôtt att det funkar! Varsågod. :-) Känner själv lite vånda varje år när det är dags att fixa SSL-cert. När jag såg ditt brandväggskript i det ursprungliga brevet så påmindes jag dessutom om varför jag började använda Shorewall som brandvägg. Den beskrivs som ... a high-level tool for configuring Netfilter. När jag ändå håller på och prackar på folk mina konfigurationsfiler så kan jag lika gärna infoga min Shorewall-konfig för den som är intresserad. :-) Helt vanlig NAT plus en server på insidan. (eth1 är externt. Har statisk IP, därav avsaknaden av dhcp i interfaces:net eth1.) # cd /etc/shorewall # egrep -v ^( *$|#) * | egrep -v (Makefile|shorewall\.conf|README\.txt): interfaces:net eth1 detect tcpflags,norfc1918,nosmurfs,logmartians interfaces:loc eth0 detect dhcp,tcpflags,detectnets,nosmurfs masq:eth1 eth0 params:matthew=192.168.221.3 policy:loc net ACCEPT policy:loc $FW ACCEPT policy:loc all REJECT info policy:$FW all ACCEPT policy:net $FW DROP policy:net loc DROP info policy:net all DROP info policy:all all REJECT info routestopped:eth1 - rules:Ping/ACCEPT all all rules:SSH/ACCEPTall $FW rules:SMTP/DNAT net loc:$matthew rules:IMAP/DNAT net loc:$matthew rules:IMAPS/DNATnet loc:$matthew rules:HTTP/DNAT net loc:$matthew rules:HTTPS/DNATnet loc:$matthew rules:FTP/DNAT net loc:$matthew rules:DNAT net loc:$matthew:22 tcp 3527 zones:fwfirewall zones:net ipv4 zones:loc ipv4 (Ingen av filerna Makefile, shorewall.conf eller README.txt har jag pillat i, vad jag kan minnas.) God natt! /Martin Någon som satt upp/använder IPV6? Tips hur man sätter upp det (och brandvägg). Jag vill använda riktiga IP-adresser till mina servrar, och inte behöva hantera RNAT-adresser. Det är så bökigt...
ipchains
Hej! Jag har satt en brandmur mellan kabeltevemodemet och mitt interna nätverk, men jag vill komma åt vissa tjänster utifrån. Nu har jag satt upp rinetd för att göra det, men jag tänkte att det väl borde gå att göra med ipchains så att jag får se den externa adressen på intranätet, men jag vet inte hur. Så, vad skall jag skriva för att brandmuren (vars externa ip-adress på eth0 ändras via dhcp), automatiskt skall skicka vidare alla anrop på port X till en maskin på det interna nätverket? -- \\// peter - http://www.softwolves.pp.se/ Statement concerning unsolicited e-mail according to Swedish law: http://www.softwolves.pp.se/peter/reklampost.html
