WCM Forum

WCM Forum (http://www.wcm.at/forum/index.php)
-   Linux, UNIX, Open Source (http://www.wcm.at/forum/forumdisplay.php?f=13)
-   -   Debianserver aufsetzen - Endspurt (-probleme) (http://www.wcm.at/forum/showthread.php?t=94716)

Quintus14 21.04.2003 16:31

Debianserver aufsetzen - Endspurt (-probleme)
 
Hi,

ich hab' nun meinen Debian-Server in Betrieb genommen: Samba, Webmin, 2 Drucker.

Vor der Datenübernahme hab' ich bei den im Netzwerk freigegebenen Datenverzeichnissen sehr wohl File-Neuanlage und -Änderung getestet und - nachdem ich 'chmod 777 /home/meindatenwurzelverzeichnis/' gemacht hab' - auch für in Ordnung befunden.

Und daraufhin hab' ich heute die Daten übernommen.

Erstes Problem: in Unterverzeichnissen, die ich bei der Übernahme auf den Sambaserver von der Workstation-1 kopiert habe, hab' ich jetzt keine Schreibberechtigung von Workstation-2 aus!

Was tun?

Thx
Quintus


P.S.: in den File-Permissions, die Webmin standardmäßig anlegt, steht: "New Unix file mode / New Unix directory mode = 755"

Quintus14 21.04.2003 17:39

OK, anscheinend muss man in den Filepermissions unter "New Unix file mode" bzw. "New Unix directory mode" auch überall 777 angeben.

Hab' jetzt die Daten nochmals neu übernommen, scheint jetzt zu funktionieren.

Apropos: gibt's dafür auch einen Befehl, mit dem man die Persmissions eines ganzen Astes (Daten + Ordner) auf 777 verdrehen könnte (wenn ja, hätt' ich mir das Neupartitionieren, Formatieren und die 2. Datenübernahme sparen können)?

Thx
Qutinus

Sloter 21.04.2003 20:01

chmod -r * 777

Sloter

Quintus14 21.04.2003 20:47

@Sloter: danke :)


Webmin / langsam ohne Internet-Zugang:

Es ist nach wie vor so, dass der Seitenaufbau am Windows-Client lähmend langsam geht (bis zu einer Minute), wenn am Debian-Server an der 2. NIC das Internet nicht dran hängt.

Hinweis: ich hab' die Firewall noch nicht konfiguriert (soll nächste Woche passieren), daher hängt der Router meistens noch im internen Netz - und das mag Webmin anscheinend nicht.

Eine Idee, warum das so langsam geht bzw. was ich dagegen tun kann?



Webmin / https vs. http:

Beim ersten Probeaufsetzen, wo mir jede Menge sonstiger SW unabsichtlich installiert wurde ("Webmin komplett") ging der Zugriff vom Windows-PC mit "https" - jetzt funktioniert es nur mit "http" (ohne "s").

Soll ich da was nachinstallieren (was?) - oder ist es ohnedies belanglos?


Thx,
Quintus

Sloter 21.04.2003 21:07

Der hat ein Problem mit den DNS abfragen.
Wie kommen die Seiten?
Langsam Bild für Bild oder ist der Schirm leer und dann kommt alles auf einmal?

http-https
SSL schützt deinen Browserverkehr mit dem Server.
Ohne https könnte man Mitsnifen und deine Zugangsdaten auslesen.
IMHO aber im internen Netz egal.

Sloter

Quintus14 21.04.2003 21:15

Zitat:

Der hat ein Problem mit den DNS abfragen. Wie kommen die Seiten?
Langsam Bild für Bild.

Zitat:

SSL schützt deinen Browserverkehr mit dem Server.
Ohne https könnte man Mitsnifen und deine Zugangsdaten auslesen.
IMHO aber im internen Netz egal.
Müsste sich ja irgend ein SSL-Webmin-Tool nachinstallieren lassen und Webmin von http auf https umstellen lassen. Hmmmm...... naja, dann lassen wir es halt so, wenn es kein besonderes Risiko ist (interne Mitsnifer kann ich ausschließen).

MfG
Quintus

Quintus14 21.04.2003 21:28

NACHTRAG: die CUPS-Admin-SW ("http://meinserver:631") zeigt dieses Verhalten nicht - die funktioniert flott, egal, ob das Internet dranhängt oder nicht.

MfG
Quintus

Sloter 21.04.2003 21:47

Hm...kenne webmin zu wenig.
Mach mal top am Linuxserver und ruf die Seite auf.
Denke aber er wird nicht überlastet sein.
Tut leid, kann nicht weiterhelfen :(

Sloter

Quintus14 21.04.2003 21:56

Nein, dem Linuxserver ist zur Zeit furchbar fad. Vieleicht hat jemand anderer noch eine Idee, hier noch mal die Ausgangsfrage:
Zitat:

Es ist nach wie vor so, dass der Seitenaufbau vom WEBMIN am Windows-Client lähmend langsam geht (bis zu einer Minute), wenn am Debian-Server an der 2. NIC das Internet nicht dran hängt.
Thx,
Quintus


P.S.: Ab dem Zeitpunkt, ab dem die Firewall in Betrieb sein = der ISDN-Router fix an der 2. NIC hängen wird, stellt sich das Problem nicht mehr. Nur bis dahin nervt es....

Sloter 22.04.2003 00:24

Hast du einen Gateway auf der Winworkstation eingetragen?

Sloter

Quintus14 22.04.2003 06:59

Zitat:

Hast du einen Gateway auf der Winworkstation eingetragen?
Auf den Win-Workstations ist die IP-Adresse des Routers, der vorläufig noch im internen Netz hängt, als Gateway ordnungsgemäß eingetragen.

Auf dem Debian-Server ist auch der Router als Gateway definiert, allerdings unter einer anderen IP-# - diese muss ich im Router immer umändern, wenn ich selbigen auf die zweite NIC umhänge, damit der Linuxserver Kontakt zum Internet kriegt. Shorewall ist auch drauf, allerdings noch nicht konfiguriert.

Nachdem ich annehme, dass Shorewall (wenn man noch keine Ahnung davon hat, wie's geht) nicht in einer halben Stunde funktionieren wird, werde ich mit der Konfiguration derselben auf einen Tag warten, wo es nichts ausmacht, wenn der Internetbetrieb stundenlang nicht funktioniert. Nächste Woche voraussichtlich.

MfG
Quintus

Sloter 22.04.2003 21:06

Da laufen die Pakete im Kreis :)
Hat der Debianserver eine echte IP?

Sloter

Quintus14 22.04.2003 21:10

Shorewall Konfiguration - 1. Versuch
 
Shorewall-Konfiguration

Hab' jetzt begonnen, das Dokument http://www.shorewall.net/two-interface.htm durchzuackern, hab' auch das Sample runtergeladen und - wie geheißen - die Dateien nach /etc/shorewall entpackt.

Sollte funktionieren, denn wie in der Beispieldatei ist eth0 -> Router und eth1 -> intern.

Neu gestartet - er meckert beim Booten bzw. Start der Shorewall:
Zitat:

iptables: no chain/target/match by that name.
Dass Shorewall sich nicht starten lässt, wäre nicht das Schlimmste - ich komm' jetzt aber nicht mehr auf den Server, Webmin funktioniert nicht und Zugriff auf meine Daten gibt's auch keinen .... :heul::heul::heul:

Was tun?

Thx,
Quintus


P.S.: @Sloter: ja, der Debianserver hat echte IPs. Vielleicht kriegen wir doch kurzfristig die Shorewall zum Laufen, dann erübrigt sich das Problem vielleicht.

Quintus14 22.04.2003 22:34

Hilfe - die angefangene Shorewall-Konfiguration hat mir anscheinend einen Stealth-Modus eingeschaltet - ich kann den Server nicht mal mehr anpingen.

Wie krieg' ich das jetzt kurzfristig wieder weg (damit ich wenigstens auf die Daten komm)? Und wie die Shorewall aus der Autostart raus?

Thx
Quintus


P.S.: 'ifup -a' bringt lo eth0 eth1 already configured

flinx 22.04.2003 23:15

In deinem Link (http://www.shorewall.net/two-interface.htm) ganz unten gibts Tipps zu 'Starting and Stopping Your Firewall'. Hast das schon ausprobiert?

Quintus14 22.04.2003 23:27

Puh, *zweistundenschwitz* - ich konnt' mir soeben selbst helfen, hab' die 6 Beispiel-Files aus /etc/shorewall rausgelöscht (liegen noch sicherheitshalber woanders), die shorewall.conf umbenannt und neu gebootet - der Trick hat funktioniert, weil der Start der Shorewall jetzt in die Hose geht *).

Jetzt seh' ich zumindest meine Daten wieder :).

Muss an die Installation der Shorewall nochmal rangehen, wenn mehr Zeit ist (ein Kinobesuch der Family ist zu wenig).

Ich frag' mich nur, was da alles noch schief gelegen ist bzw. warum der Server auf Pings nicht geantwortet hat. Jemand eine Idee????

Thx,
Quintus :zzz:


*) = russische Methode


spunz 22.04.2003 23:40

ich kenn diese fw nicht, aber guck mal unter /etc/init.d/ ob nicht hier das startscript zu finden ist. wenn ja solltest du es zb mit "/etc/init.d/name stop" anhalten und mit start starten können.

für mich klingt das ganze eher danach das die firewall zur sicherheit mal alles dicht gemacht hat.

Quintus14 23.04.2003 07:54

Zitat:

für mich klingt das ganze eher danach das die firewall zur sicherheit mal alles dicht gemacht hat.
Richtig - steht auch in der Installations Procedure:
Zitat:

IF YOU ISSUE A "start" COMMAND AND THE FIREWALL FAILS TO START, YOUR SYSTEM WILL NO LONGER ACCEPT ANY NETWORK TRAFFIC.
Problem dabei war/ist nur: dass der Server weder mit '/etc/init.d/shorewall stop' noch mit dem im o.g. Dokument angegebenen 'shorewall clear' im Netz wieder sichtbar wird :(.

Russische, provisorische Lösung: Umbenennen des /etc/shorewall/-Directories und reboot.

----------------------------------------------------

Aber wie krieg' ich Shorewall jetzt zum Laufen? Folgendes hab' ich gemacht:
  • Die 6 Dateien aus dem Two-Interfaces-Sample entpackt und ins Shorewall-Verzeichnis kopiert - meine eth0 hängt auch am Router, eth1 ist intern, somit sollte das Beispiel gleich für mich passen.
  • Den Eintrag 'norfc1918' laut dem Two-Interfaces-Dokument aus der /shorewall/interfaces entfernt, weil ich den 192.168.x.x-Bereich intern nutze.
  • Die zwei Einträge 'NAT_ENABLED=Yes' sowie 'IP_FORWARDING=On' sollte man (ebenfalls lt. Two-Interfaces-Dokument) in die shorewall.conf schreiben - dort wiederum steht, man solle selbige als icmpdef wegkopieren und Änderungen ebendort vornehmen. Ich hab' die Einträge jetzt in der icmpdef vorgenommen.
Es bleibt dabei: Shorewall kann nicht ordnungsgemäß gestartet werden, Message: No chain/target/match by that name.

Dieselbe Fehlermessage schreibt er auch beim 'etc/init.d/shorewall stop'-command.

Was hat es mit der Fehlermeldung auf sich, was fehlt noch bzw. wie krieg' ich die Shorewall jetzt zum laufen ?

:heul: :heul: :heul:

Thx,
Quintus

spunz 23.04.2003 08:39

wie gesagt, ich kenne diese fw nicht. aber es wäre ev hilfreich wenn du deine config noch etwas genauer beschreiben könntest.

welche ip adressen auf welcher nic?
steht im log file genaueres? (guck mal unter /var/log)
was für eine chain will er da? gibts die auch?

Quintus14 23.04.2003 09:25

Zitat:

welche ip adressen auf welcher nic?
Dazu die /etc/network/interfaces:

-------------------

auto lo eth0 eth1

iface lo inet loopback

iface eth0 inet static
address 10.168.110.xx
netmask 255.0.0.0
gateway 10.168.110.yy

iface eth1 inet static
address 192.168.0.zzz
netmask 255.255.255.0

-------------------

Die Netzwerkverbindungen funktionieren tadellos, wenn ich den ISDN-Router vom internen Netz (Provisorium) auf Debian-Server's eth0 hänge, kriegt auch selbiger tadellosen Zugriff aufs Internet.
Zitat:

steht im log file genaueres? (guck mal unter /var/log)
Puh .... da steht viel, aber keine Shorewall.log - keine Ahnung, was wichtig ist.

Im Fraglichen Zeitraum, in dem ich gestern abends keinen Serverzugriff hatte, findet sich in einer syslog.0: 'Packet send failed to 10.255.255.255(137) ERRNO:Operation not permitted' - wobei interessant ist, wo er die IP-Nummer her hat.

Es findet sich auch: 'retransmit_or_expire_response_records: Failed to resend packet id 5788 to IP 10.255.255.255 on subnet 10.168.110.xx

Verwechselt der Kerl da IP-Nummern mit Subnet-Masken?
Zitat:

was für eine chain will er da? gibts die auch?
Wo seh' ich, was er will?

Thx
Quintus (bis mittags offline)

valo 23.04.2003 10:38

die 10.255.255.255 is die broadcast adresse für das 10.x.x.x netz, die firewall dürfte aber den zugriff aufs netzwerk blockiert haben, deswegen die meldung...

Quintus14 23.04.2003 13:56

... und was tu' ich jetzt in meinem Schmerz, damit die Firewall ins Laufen kommt, was liegt noch schief bzw. ist noch zu tun....?

Thx
Quintus

flinx 23.04.2003 14:35

Zitat:

Die zwei Einträge 'NAT_ENABLED=Yes' sowie 'IP_FORWARDING=On' sollte man (ebenfalls lt. Two-Interfaces-Dokument) in die shorewall.conf schreiben - dort wiederum steht, man solle selbige als icmpdef wegkopieren und Änderungen ebendort vornehmen. Ich hab' die Einträge jetzt in der icmpdef vorgenommen.
Hab die Doku nur kurz überflogen, aber ich würde dies nur in der shorewall.conf setzen. Hab auch in http://www.shorewall.net/Documentation.htm#Conf nichts von icmpdef gelesen.
Um Traffic von localen Netz zu empfangen, müsste man IMHO (nach durchlesen von http://www.shorewall.net/two-interface.htm) im /etc/shorewall/policy file noch loc fw ACCEPT setzen, um Traffic vom lokalen Netz auf die Firewall zu erlauben.
In /etc/shorewall/rules sollte dann natürlich nichts stehen, was den Traffic vom lokalen Netz zur Firewall blockiert.
Obiges mit Vorsicht genießen, habe shorewall selber auch nicht. :)

Quintus14 23.04.2003 16:53

Zitat:

...würde dies nur in der shorewall.conf setzen...
Nunmehr getan.
Zitat:

...im /etc/shorewall/policy file noch loc fw ACCEPT setzen,...
Laut http://www.shorewall.net/two-interface.htm ist vor einer ausgekreuzelten Zeile das Kreuzel wegzunehmen ("If you want your firewall system to have full access to servers on the internet, uncomment that line."). Schaut in der policy jetzt so aus (d.h. nicht ganz so, wie Du es schriebst):

-------------------------------------
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
# If you want open access to the Internet from your Firewall
# remove the comment from the following line.
fw net ACCEPT
net all DROP info
all all REJECT info
--------------------------------------


Die rules sieht so aus:

--------------------------------------
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
#
# Accept DNS connections from the firewall to the network
#
ACCEPT fw net tcp 53
ACCEPT fw net udp 53
#
# Accept SSH connections from the local network for administration
#
ACCEPT loc fw tcp 22
#
# Allow Ping To And From Firewall
#
ACCEPT loc fw icmp 8
ACCEPT net fw icmp 8
ACCEPT fw loc icmp 8
ACCEPT fw net icmp 8
---------------------------------------


Trotzdem bleibt es beim Starten der Shorewall beim Fehler:

ip_tables: (C) 2000-2002 Netfilter core team
iptables: No chain/target/match by that name.
/etc/init.d/shorewall: line2: 610 Terminated $SRWL "Restart"


In der /etc/init.d/shorewall lauten dann die ersten 2 Zeilen:

LOCKFILE = /var/lock/shorewall
SWRL = /sbin/shorewall


Was tun? Und was heißt diese blöde Fehlermeldung?

Thx
Quintus

flinx 23.04.2003 17:26

Zitat:

("If you want your firewall system to have full access to servers on the internet, uncomment that line.")
Ok, damit gibst du IMHO dem fw-Rechner Zugriff aufs I-net.

Zitat:

Trotzdem bleibt es beim Starten der Shorewall beim Fehler:
Wie genau startest du die Firewall? lt. http://www.shorewall.net/starting_an..._shorewall.htm sollte ein 'shorewall start' reichen.
Zitat:

/etc/init.d/shorewall: line2: 610 Terminated $SRWL "Restart"
Hmm... hast vielleicht 'Restart' anstatt 'restart' verwendet?

Bei den rules, wirst dann IMHO noch den Zugriff auf die Netzwerk-Shares gestatten müssen.

Quintus14 23.04.2003 17:56

Zitat:

Wie genau startest du die Firewall?
'/etc/init.d/shorewall start' oder '/etc/init.d/shorewall restart'.

Zitat:

Hmm... hast vielleicht 'Restart' anstatt 'restart' verwendet?
Groß-/Kleinschreibung hab' ich nicht verwendet.

Zitat:

Bei den rules, wirst dann IMHO noch den Zugriff auf die Netzwerk-Shares gestatten müssen.
Ich nehme an, in 'rules' gehört eine Zeile rein - wo genau und wie muss die heißen?

---------

Weiters komisch: es gibt eine 'shorewall.conf', eine 'icmp.def' sowie die von mir kopierte 'icmpdef' - in allen steht dasselbe drinnen, lediglich in der shorewall.conf stehen noch die zwei Einträge 'NAT_ENABLED=Yes' sowie 'IP_FORWARDING=On'.

Thx
Quintus

flinx 23.04.2003 18:17

Probier mal ein ( wie in http://www.shorewall.net/starting_an..._shorewall.htm) beschrieben ein 'shorewall check' auszuführen und schau, ob es irgendwelche Fehlermeldungen gibt. Wenn nein, dann probier 'shorewall start' (ohne /etc/init.d/).

Für samba:
http://www.shorewall.net/samba.htm

Quintus14 23.04.2003 19:54

Samba-Einträge in der 'rules' eingefügt und 'shorewall check' gemacht. Dieselbe Fehlermeldung:

Processing /etc/shorewall.conf ...
iptables: No chain/target/match by that name.
Terminated.


Immer die gleiche Fehlermeldung seit Beginn der Probs....

Die shorewall.conf sieht übrigens jetzt so aus (die letzten 2 Zeilen wurden von mir eingefügt):
---------------------------------------
run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
NAT_ENABLED=Yes
IP_FORWARDING=On
----------------------------------------


:confused: :confused: :confused:

Quintus

MANX 23.04.2003 20:03

Hi!

... da tut sich ja schon wieder ganz schön was ;)
Welche Version der shorewall (stable oder testing)? ich schau mir's mal an.
Was mir beim überfliegen der Problematik aufgefallen ist:
So 100%ig passt die two-interfaces Konfiguration nicht, da Du auf der Firewall kein Masquerading brauchst, das macht dann ja der Router.
Hat aber mit dem Problem nix zu tun.

Grüße

Manx

Quintus14 23.04.2003 20:24

Noch was, eine Spur: ich hab' bei http://www.shorewall.net/troubleshoot.htm nachgelesen: ganz zu Beginn des Dokuments steht, wie man den Start mittract - hab' ich natürlich dann gemacht.

Der untenstehende Auszug dürfte der Teil sein, wo es den Start schmeißt. Dürfte was mit 'echo-reply' der iptables zu tun haben (was immer das ist....).

-------------------------------------

+ version_file=/etc/shorewall/version
+ '[' -f /etc/shorewall/version ']'
++ cat /etc/shorewall/version
+ version=1.2.12
+ strip_file interfaces
+ local fname
+ '[' 1 = 1 ']'
++ find_file interfaces
++ '[' -n '' -a -f /interfaces ']'
++ echo /etc/shorewall/interfaces
+ fname=/etc/shorewall/interfaces
+ '[' -f /etc/shorewall/interfaces ']'
+ cut -d# -f1 /etc/shorewall/interfaces
+ grep -v '^[[:space:]]*$'
+ strip_file hosts
+ local fname
+ '[' 1 = 1 ']'
++ find_file hosts
++ '[' -n '' -a -f /hosts ']'
++ echo /etc/shorewall/hosts
+ fname=/etc/shorewall/hosts
+ '[' -f /etc/shorewall/hosts ']'
+ cut -d# -f1 /etc/shorewall/hosts
+ grep -v '^[[:space:]]*$'
+ run_user_exit shorewall.conf
++ find_file shorewall.conf
++ '[' -n '' -a -f /shorewall.conf ']'
++ echo /etc/shorewall/shorewall.conf
+ local user_exit=/etc/shorewall/shorewall.conf
+ '[' -f /etc/shorewall/shorewall.conf ']'
+ echo 'Processing /etc/shorewall/shorewall.conf ...'
+ . /etc/shorewall/shorewall.conf
++ run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
+++ echo -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
+++ sed 's/!/! /g'
++ iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
iptables: No chain/target/match by that name
++ '[' -z '' ']'
++ stop_firewall
++ stopping=Yes
++ deletechain shorewall

----------------------------------------

Hilft das was?

@Manx: dürfte stable sein - die testing-files haben wir ja erst eingebunden, wie wir Webmin 1.070 installiert haben (bin mir aber nicht sicher, ob da nicht shorewall irgendwo mit upgedatet wurde).

Thx
Quintus

MANX 23.04.2003 20:34

Hi!

Wie gesagt, keine Ahnung wie die shorewall funktioniert.
Wenn Du ihm in der shorewall.conf am Anfang:
"run_iptables -N icmpdef"
einfügst, legt er die chain icmpdef an (vielleicht ;)), und es sollte funktionieren.
Obwohl ich nicht weiß, ob diese chain nicht eine spezielle, durch ein spezielles Modul vorhandene, chain ist.

mal googlen

Manx

flinx 23.04.2003 20:41

Wenn ich mir http://www.shorewall.net/Documentation.htm#Conf anschau, dann steht dort:
Zitat:

/etc/shorewall/shorewall.conf
This file is used to set the following firewall parameters:
...
aber keiner der Parameter ist was mit run_iptables.
Hingegen
Zitat:

/etc/shorewall/common
The /etc/shorewall/common file is expected to contain iptables commands; rather than running iptables directly, you should run it indirectly using the Shorewall function 'run_iptables'. That way, if iptables encounters an error, the firewall will be safely stopped.
Ich würd mal die run_iptables Zeilen auskommentieren und es noch mal probieren.

Quintus14 23.04.2003 21:15

Zitat:

Wenn Du ihm in der shorewall.conf am Anfang: "run_iptables -N icmpdef" einfügst, legt er die chain icmpdef an
Teilerfolg: er kommt beim Starten jetzt 15 statt bisher 3 Zeilen weit.

Jetzt hängt's hier - die letzten Zeilen:
----------------------------------------
.....
Validating host files...
Determining Hosts in Zones...
Net Zone: eth0:0.0.0.0/0
Local Zone: eth1:0.0.0.0/0
/etc/shorewall/firewall: ip: command not found
/etc/shorewall/firewall: ip: command not found
Terminated

----------------------------------------

Wieso IP-Nummern 0.0.0.0 - die sollten doch bekannt sein - oder? Welcher 'command not found'?

Thx
Quintus


P.S.: 'shorewall clear' bingt auch: "Clearing shorewall ... /etc/shorewall/firewall: ip: command not found" - aber der Befehl nutzt endlich was!!!;)

MANX 23.04.2003 21:19

apt-get install iproute

Grüße

Manx

flinx 23.04.2003 21:23

Was steht bei dir in
/etc/shorewall/zones und
etc/shorewall/hosts ?

Quintus14 23.04.2003 21:55

/etc/shorewall/zones:
-------------------------------------
#ZONE DISPLAY COMMENTS
net Net Internet
loc Local Local Networks
-------------------------------------


etc/shorewall/hosts: da steht gar nichts drinnen - alles ausgekreuzelt.

=====================================


Der Durchbruch ist geschafft:
  • Der Shorewall-Start lief bis zum Ende fehlerlos durch :) :) :).
  • Die Firewall funzt mal grundsätzlich - ich schreib gegenständliches Posting bereits über den Server bzw. über die Firewall :) :) :).
  • FTP-Übertragung funzt auch :) :) :).
  • Drucken über den Server geht auch :) :) :).
  • Webmin und die CUPS-Webadministration gehen (fast erwartungsgemäß) noch nicht :( - ich denke, da fehlen noch irgendwo ein bis zwei Einträge. Welche/wo?
Ganz dickes "Danke" einmal zwischendurch :lol:.

MfG
Quintus


P.S.: Ich wäre geneigt, jenem gut halben Dutzend Linux-Gurus, die mir in den letzten Wochen so hilfreich zur Seite standen, einmal zu ein paar Runden Getränke im GH Prilisauer (Endstation 49er) einzuladen. Was hält Ihr davon?

Quintus14 23.04.2003 22:29

NACHTRAG:
  • 'Shorewall restart' funktioniert nicht: "iptables: Chain already exists / Terminated". Ich muss bei Konfigurationsänderungen ein 'shorewall stop' und ein 'shorewall start' machen. Irgendwas funzt da mit den iptables nicht ganz astrein.
  • Was tun, damit Webmin per http://meinserver:10000 und das Cups-Webadmin via http://meinserver:631 wieder funktioniert?
  • Ist die Firewall jetzt "dicht" - oder muss ich mich da noch um offene/geschlossene Ports etc. kümmern?

Thx
Quintus

flinx 23.04.2003 22:51

Grats. :)

Mir ist aufgefallen:
Zitat:

++ cat /etc/shorewall/version
+ version=1.2.12
+ strip_file interfaces
in der Doku ist von Version 1.4. die Rede.
Gibts für Debian nicht die neueste Version zum Download oder ist das die iptables Version (check mit '/sbin/iptables --version')?

zu icmpdef:
Wie hast das jetzt gelöst?
Steht das in der shorewall.conf (mit dem Befehl von Manx ?) oder in icmpdef?
Hab dazu noch http://www.shorewall.net/ping.html gefunden.

Zitat:

Was tun, damit Webmin per http://meinserver:10000 und das Cups-Webadmin via http://meinserver:631 wieder funktioniert?
In der /etc/shorewall/rules :
ACCEPT loc fw tcp 10000
ACCEPT loc fw tcp 631
hinzufügen und firewall restarten. Beim testen bzw. hinzufügen von neuen Regeln würd ich nach dem vorgeschlagenen Prinzip vorgehen:
Zitat:

When changing the configuration of a production firewall, I recommend the following:
mkdir /etc/test
cd /etc/test
<copy any files that you need to change from /etc/shorewall to . and change them here>
shorewall -c . check
<correct any errors found by check and check again>
/sbin/shorewall try .
If the configuration starts but doesn't work, just "shorewall restart" to restore the old configuration. If the new configuration fails to start, the "try" command will automatically start the old one for you.

When the new configuration works then just
cp * /etc/shorewall
cd
rm -rf /etc/test
Zitat:

Ist die Firewall jetzt "dicht" - oder muss ich mich da noch um offene/geschlossene Ports etc. kümmern?
IMHO kommt drauf an was in /etc/shorewall/rules resp. /etc/shorewall/policy drinnensteht.

Quintus14 23.04.2003 23:28

Zitat:

check mit '/sbin/iptables --version'
Ergibt v1.2.6a
'/sbin/shorewall version' ergibt 1.2.12
Zitat:

Wie hast das jetzt gelöst? Steht das in der shorewall.conf (mit dem Befehl von Manx ?) ....
Ja, Befehl von MANX - aber auf diese Methode funktioniert 'restart' nicht.

Die shorewall.conf sieht jetzt so aus:

------------------------------------
run_iptables -N icmpdef
run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
NAT_ENABLED=Yes
IP_FORWARDING=On
--------------------------------------
Zitat:

In der /etc/shorewall/rules : ACCEPT loc fw tcp 10000; ACCEPT loc fw tcp 631
Danke, funzt :lol: .
Zitat:

IMHO kommt drauf an was in /etc/shorewall/rules resp. /etc/shorewall/policy drinnensteht.
Den Inhalt dieser beiden Dateien hab' ich heute schon gepostet - Seite 2 dieses Threads.



Noch was ist mir (unangenehm) aufgefallen: wenn ich einen Windows-Client boote, dauert das "Wiederherstellen der Netzwerkverbindung (zum Server)" viel länger als früher. Ich bin da netzwerkmäßig nicht so sattelfest - aber es dürfte was mit nicht vorhandenem DNS zu tun haben. Kann/soll ich dem Debian-Server irgendwie beibringen, dass er sich um DNS kümmert?

Zur Info: ich hab' allen Rechnern und Printerservern und auch dem Router fixe IP-Nummern gegeben, beim Router, der jetzt auf der externen Seite hängt, ist DHCP ausgeschaltet. Weiters hab' ich in dieser Richtung nichts unternommen - fehlt da noch was?

Thx
Quintus :zzz:

flinx 23.04.2003 23:43

Zitat:

'/sbin/shorewall version' ergibt 1.2.12
Wär da eine neuere Version nicht sinnvoller? In den neueren Versionen werden sicher einige Probleme behoben sein.
Zitat:

Die shorewall.conf sieht jetzt so aus: ...
Versuch die run_iptables Zeilen alle auskommentieren.
Ev. solltest auch /etc/shorewall/icmpdef und /etc/shorewall/icmp.def umbenennen.
Schau dir dazu auch den Link mit der ping-Behandlung an. Für Shorewall Versionen < 1.3.14 schaut das offensichtlich etwas anders aus, als in der Doku.

Zitat:

Den Inhalt dieser beiden Dateien hab' ich heute schon gepostet - Seite 2 dieses Threads.
Ok, aber an der /etc/shorewall/rules hast aber sicher einiges geändert.

Zitat:

wenn ich einen Windows-Client boote, dauert das "Wiederherstellen der Netzwerkverbindung (zum Server)" viel länger als früher.
Könnte auch an Samba liegen. Aber ich würde vorschlagen, erst die Firewall fertig zu konfigurieren und dann das nächste. ;)


Alle Zeitangaben in WEZ +2. Es ist jetzt 15:32 Uhr.

Powered by vBulletin® Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag