Re: Was will Samba von mir ?? (Nachtrag zu Mail von 13:45)
Am Donnerstag, 24. April 2003 12:29 schrieb Steffen Moser:
Hallo,
* On Thu, Apr 24, 2003 at 10:48 AM (+0200), Peter Wiersig wrote:
Was steckt hinter dem "couldn't find service c" ??
Du willst mal eine Paket-Filter Regel einfuegen, die smb-Pakete aus dem Internet wegfiltert.
ACK!
Meine Vermutung: Jemand hat versucht von aussen auf die NT-Systemfreigabe \\RECHNER\C$ zuzugreifen.
Eher auf "C" und nicht auf "C$" - sonst hätte Samba "C$" in's Logfile geschrieben... ;-)
Vermutlich gibt es Win9x-User, die direkt das Laufwerk C: unter dem Share-Namen "C" (vermutl. ohne Passwort) freigegeben haben (das "C$" als versteckte Freigabe ist ja standardmäßig Sache von WinNT) und genau das scheint der Wurm bzw. der Angreifer ausnutzen.
Hallo, das ist hochinteressant. Ich bin in der Tat dabei, mein Server- System neu aufzubauen und schließe daher die Möglichkeit nicht aus, dass irgendwo ein "Türchen" noch auf ist. (prüf ich anschließend) Im eigenen Netz habe ich zwei Windows- Rechner, die allerdings beide nicht liefen als die Fehlermeldungen in der /var/log/messages auftauchten. In diesem Zusammenhang habe ich "Antivir" laufen lassen, mit folgendem Resultat: checking drive/path (list): / /dosc/Programme/Kazaa Lite/Speed Up.exe Date: 2.01.2003 Time: 01:23:42 Size: 42816 warning: invalid program start address /dosc/Programme/Kazaa Lite/dksigtool.exe Date: 9.01.2003 Time: 17:39:18 Size: 9552 warning: invalid program start address ----- scan results ----- directories: 18588 files: 44712 alerts: 0 warnings: 2 scan time: 00:04:45 ------------------------ Thank you for using AntiVir. boss:/home/heiner # "dosc" ist der Mount- Punkt für "c", hier auf dem Server. Könnte dies der Übeltäter des Ganzen sein oder ist es noch fürchterlicher? Was sollte ich noch tun, ich meine außer die Ports abzudichten? Shields up hat die Ports gescannt und folgende geöffnet vorgefunden: 80 HTTP OPEN! The web is so insecure these days that new security "exploits" are being discovered almost daily. There are many known problems with Microsoft's Personal Web Server (PWS) and its Frontpage Extensions that many people run on their personal machines. So having port 80 "open" as it is here causes intruders to wonder how much information you might be willing to give away. 139 NetBIOS OPEN! As you probably know by now, the NetBIOS File Sharing port is the single largest security hole for networked Windows machines. The payoff from finding open Windows shares is so big that many scanners have been written just to find open ports like this one. Closing it should be a priority for you! die anderen galten als "closed" "stealth" wäre sicher besser. Wie dichte ich die am besten ab? Viele Grüße Heiner -- ******************************* H e i n e r G e w i e h s Marketing - Fachkaufmann D- 63868 Großwallstadt Mail: heiner.gewiehs@gewiehs.de *******************************
Am Donnerstag, 24. April 2003 14:30 schrieb Heiner Gewiehs:
Am Donnerstag, 24. April 2003 12:29 schrieb Steffen Moser:
* On Thu, Apr 24, 2003 at 10:48 AM (+0200), Peter Wiersig wrote:
Was steckt hinter dem "couldn't find service c" ??
Du willst mal eine Paket-Filter Regel einfuegen, die smb-Pakete aus dem Internet wegfiltert. ACK!
NACK, was du wirklich willst, ist dir die Optionen "interfaces" und "bind interfaces only" von Samba ansehen. Hängt aber auch davon ab, was das für ein Netz ist. Ich antizipiere mal ein paar freundliche Windows-Kisten und der Linux-Rechner, der gleichzeitig das Tor zum bösen Internet ist. Richtig?
Was sollte ich noch tun, ich meine außer die Ports abzudichten?
Ports sind per default dicht, wenn kein Dienst läuft. Also schalte alles ab, was du nicht brauchst. Bei dem, was du nur nach innen brauchst, sorgst du dafür, dass es nicht an externen Interfaces lauscht. Meist wird das mit "listen" oder "interface" in den Konfigurationsdateien gesteuert. Bei dem, was du wirklich nach außen brauchst, musst du auf sichere Software achten, sprich updates installieren, wenn Sicherheitslöcher gefixt wurden.
Shields up hat die Ports gescannt und folgende geöffnet 80 HTTP OPEN!
Brauchst du den nach außen? Wenn nicht, abschalten.
139 NetBIOS OPEN!
Das sollte man nun wirklich nicht nach außen aufmachen, es sei denn, man hat verdammt gute Gründe und weiß genau, was man tut.
die anderen galten als "closed" "stealth" wäre sicher besser.
Stealth ist ein Marketing-Buzzword und in keinster Weise besser als closed. Im Gegenteil.
Wie dichte ich die am besten ab?
Sorge dafür, dass die Dienste nicht am externen Interface lauschen: Bei Samba geht das z.B. mit den Direktiven "interfaces" und "bind interfaces only". Den Rest macht dein Linux für dich. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Andreas Feile wrote:
Martin Borchert, Donnerstag, 24. April 2003 15:21:
Stealth ist ein Marketing-Buzzword und in keinster Weise besser als closed. Im Gegenteil.
Im Gegenteil?
<http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Deny> <http://logi.cc/linux/reject_or_deny.php3> micha
Am Donnerstag, 24. April 2003 15:31 schrieb Andreas Feile:
Martin Borchert, Donnerstag, 24. April 2003 15:21:
Stealth ist ein Marketing-Buzzword und in keinster Weise besser als closed. Im Gegenteil. Im Gegenteil?
Gegenteil wie "Bietet keinen zusätzlichen Nutzen oder gar Sicherheitsgewinn". Gegenteil wie "Völlig dämliche und irreführende Wortwahl". Gegenteil wie "Vorsätzliche Verdummung der User". Reicht das erstmal? Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Martin Borchert, Donnerstag, 24. April 2003 15:57:
Im Gegenteil?
Gegenteil wie "Bietet keinen zusätzlichen Nutzen oder gar Sicherheitsgewinn". Gegenteil wie "Völlig dämliche und irreführende Wortwahl". Gegenteil wie "Vorsätzliche Verdummung der User".
Reicht das erstmal?
Nein. Ich wüßte gerne, wieso das so ist. Vielleicht liege ich ja falsch, aber ich stelle mir das so ähnlich vor wie eine Teergrube. Wenn ich auf alle Anfragen schön mit "Port geschlossen" antworte, dann geht ein Portscan sehr schnell, und der Interessent weiß immerhin auch, daß er es überhaupt mit einer gültigen IP-Adresse zu tun hat. Verwerfe ich dagegen alle anfragenden Pakete, dann dauert der Portscan schon mal wesentlich länger, und der Interessent weiß nachher immer noch nicht, ob sich unter der fraglichen IP-Adresse überhaupt ein Rechner verbirgt. -- Andreas Feile www.feile.net
Andreas Feile wrote:
Verwerfe ich dagegen alle anfragenden Pakete, dann dauert der Portscan schon mal wesentlich länger, und der Interessent weiß nachher immer noch nicht, ob sich unter der fraglichen IP-Adresse überhaupt ein Rechner verbirgt.
geh davon aus, das der Scanner so geschrieben ist, das er alle Ports gleichzeitig checkt. Dann dauert der ganze Portscan exakt eine Timeout-Dauer. Das sind boese Leute, die halten sich nicht solange an einem Port auf, bis ne Antwort kam. -- Falls dir meine Antwort nicht passt -> hast du http://www.lugbz.org/documents/smart-questions_de.html gelesen und befolgt?
Peter Wiersig, Donnerstag, 24. April 2003 16:10:
geh davon aus, das der Scanner so geschrieben ist, das er alle Ports gleichzeitig checkt. Dann dauert der ganze Portscan exakt eine Timeout-Dauer. Das sind boese Leute, die halten sich nicht solange an einem Port auf, bis ne Antwort kam.
OK. Aber ich verstehe nicht, warum es ein Nachteil sein soll, auf entsprechende Anfragen nicht zu reagieren. Immerhin würde doch so der Netzwerkverkehr halbiert, wenn kein Antwortpäckchen übertragen werden müßte...? -- Andreas Feile www.feile.net
Andreas Feile wrote:
Immerhin würde doch so der Netzwerkverkehr halbiert, wenn kein Antwortpäckchen übertragen werden müßte...?
Das RST Paket besteht ja nur aus dem Header. Du lieferst ja nicht den Datenteil mit zurueck. /usr/src/linux/net/ipv4/netfilter/ipt_REJECT.c line 86 Peter -- Falls dir meine Antwort nicht passt -> hast du http://www.lugbz.org/documents/smart-questions_de.html gelesen und befolgt?
On Thu, Apr 24, 2003 at 04:37:38PM +0200, Andreas Feile wrote:
OK. Aber ich verstehe nicht, warum es ein Nachteil sein soll, auf entsprechende Anfragen nicht zu reagieren.
Es gibt drei Sorten von Connectversuchen: - Legitime Connectversuche, etwa zum Netzdebugging. Das ist mit einem Drop nicht mehr möglich. Mit einem REJECT 3:10 weiß der Debugger, was Sache ist. - Scans von Scriptkiddies. Die können einer ordentlich geschützten Kiste sowieso nichts anhaben. Wenn man denen ein REJECT 3:10 (administratively prohibited, port firewalled) sendet, dann wissen sie immerhin, daß sie keine Chance haben, und außerdem ist deren Scan möglicherweise schneller vorbei. - Scans von Leuten, die wirklich was drauf haben. Ob Du denen einen DROP oder einen REJECT 3:10 sendest macht wirklich keinen Unterschied. Entweder Deine Kiste ist dicht oder nicht. Wenn nicht, hältst Du die mit einem DROP nicht nennenswert auf. => Der DROP ist sinnlos und verbessert Deine Situation nicht. Empfehlenswert ist ein REJECT 3:10. Kristian
Kristian Koehntopp, Donnerstag, 24. April 2003 19:00:
Es gibt drei Sorten von Connectversuchen: [...] => Der DROP ist sinnlos und verbessert Deine Situation nicht. Empfehlenswert ist ein REJECT 3:10.
OK, das leuchtet mir ein. Leider sagt mir aber ein REJECT 3:10 nicht sehr viel - wie bekäme man das als iptables Standard-Policy hin? $IPTABLES -P INPUT REJECT Diese Regel läßt iptables aber nicht zu: "Bad policy name". Ich habe dann versucht, den reject-Typ anzugeben, etwa: $IPTABLES -P INPUT REJECT --reject-with icmp-net-prohibited Aber auch diese Regel kann ich nicht setzen: iptables v1.2.2: Unknown arg `--reject-with' Irgendwas hab ich da bei iptables nicht recht verstanden - aber was? -- Andreas Feile www.feile.net
* On Fri, Apr 25, 2003 at 01:16 AM (+0200), Andreas Feile wrote:
- wie bekäme man das als iptables Standard-Policy hin?
$IPTABLES -P INPUT REJECT
Diese Regel läßt iptables aber nicht zu: "Bad policy name". Ich habe dann versucht, den reject-Typ anzugeben, etwa:
$IPTABLES -P INPUT REJECT --reject-with icmp-net-prohibited
Aber auch diese Regel kann ich nicht setzen: iptables v1.2.2: Unknown arg `--reject-with'
Irgendwas hab ich da bei iptables nicht recht verstanden - aber was?
AFAIK kannst Du "REJECT" nicht als Default Policy setzen. Du kannst aber stattdessen die Default Policy z.B. auf "DROP" setzen und dann als letzte Regel einfügen: iptables -A INPUT -j REJECT bzw. eben noch um einen "--reject-with"-Parameter erweitert. Dann sollte für alle Pakete, für die keine vorhergehende Regel greift, diese Regel (also "REJECT") angewandt werden - und das ist ja nichts Anderes als eine Default Policy. Das "DROP" spielt dann keine Rolle mehr. Gruß Steffen
Steffen Moser, Freitag, 25. April 2003 09:44:
iptables -A INPUT -j REJECT
Nun, diese Regel wäre in meinem Fall etwas zu weitgehend. Aber ich habe folgendes versucht: #!/bin/bash IPTABLES=/usr/sbin/iptables WANDEV=ppp0 $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -P FORWARD ACCEPT $IPTABLES -A INPUT -i $WANDEV -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT -i $WANDEV -j REJECT Komischerweise greift jetzt immer noch die Default-Policy DROP, wenn ich diese Regeln aktiviere. Jedenfalls weist Shields UP alle Ports als Stealth aus. Wenn ich dagegen ein $IPTABLES -F mache, dann kommt bei allen Ports closed. Daraus schließe ich, daß die zweite Regel nie zur Anwendung kommt. Warum ist das so? Es kann doch bei einem Portscan von außen die erste Regel nicht greifen...? -- Andreas Feile www.feile.net
* On Fri, Apr 25, 2003 at 10:13 AM (+0200), Andreas Feile wrote:
Steffen Moser, Freitag, 25. April 2003 09:44:
iptables -A INPUT -j REJECT
Nun, diese Regel wäre in meinem Fall etwas zu weitgehend. Aber ich habe folgendes versucht:
Stimmt.
#!/bin/bash IPTABLES=/usr/sbin/iptables WANDEV=ppp0
$IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP
Möglicherweise verhindert ja diese Regel, dass die ICMP-Nachricht, die beim "REJECT" entsteht, rausgeschickt wird. Setze mal für OUTPUT die Default Policy testweise auf ACCEPT.
$IPTABLES -P FORWARD ACCEPT
$IPTABLES -A INPUT -i $WANDEV -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT -i $WANDEV -j REJECT
Komischerweise greift jetzt immer noch die Default-Policy DROP, wenn ich diese Regeln aktiviere. Jedenfalls weist Shields UP alle Ports als Stealth aus. Wenn ich dagegen ein $IPTABLES -F mache, dann kommt bei allen Ports closed.
Daraus schließe ich, daß die zweite Regel nie zur Anwendung kommt.
Ob eine Regel zur Anwendung kommt, kannst Du ja mal testen, indem Du eine neue Chain definierst, die ein "REJECT" macht und gleichzeitig ein "LOG". Gruß Steffen
Am Donnerstag, 24. April 2003 16:07 schrieb Andreas Feile:
Martin Borchert, Donnerstag, 24. April 2003 15:57:
[closed besser als stealth]
Nein. Ich wüßte gerne, wieso das so ist. Vielleicht liege ich ja falsch, aber ich stelle mir das so ähnlich vor wie eine Teergrube. Wenn ich auf alle Anfragen schön mit "Port geschlossen" antworte, dann geht ein Portscan sehr schnell, und der Interessent weiß immerhin auch, daß er es überhaupt mit einer gültigen IP-Adresse zu tun hat. Verwerfe ich dagegen alle anfragenden Pakete, dann dauert der Portscan schon mal wesentlich länger, und der Interessent weiß nachher immer noch nicht, ob sich unter der fraglichen IP-Adresse überhaupt ein Rechner verbirgt.
http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Deny http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Verstecken Der Text lohnt sich auch insgesamt wirklich. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Martin Borchert, Donnerstag, 24. April 2003 16:27:
http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Deny http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Verstecken
Der Text lohnt sich auch insgesamt wirklich.
OK, gelesen. Lutzens Beiträge waren schon immer knackig formuliert (sitzt der eigentlich immer noch bei der ICANN?) Habe keine weiteren Fragen mehr ;) -- Andreas Feile www.feile.net
On Thu, Apr 24, 2003 at 04:59:52PM +0200, Andreas Feile wrote:
OK, gelesen. Lutzens Beiträge waren schon immer knackig formuliert (sitzt der eigentlich immer noch bei der ICANN?)
Lutz arbeitet bei der IKS in Jena. Lutz hat im August 2000 für die ICANN-Wahlen kandidiert (http://www.heise.de/ct/icann/kandidaten/donnerhacke/, http://www.iks-jena.de/mitarb/lutz/icann.en.html, http://members.icann.org/nom/cp/14.html), aber kein Mandat bekommen (http://www.iks-jena.de/mitarb/lutz/icann.nachwahl.html). Stattdessen ist Andy Müller-Maguhn gewählt worden (http://members.icann.org/nom/cp/EU.html). Kristian
Martin Borchert wrote:
Am Donnerstag, 24. April 2003 14:30 schrieb Heiner Gewiehs:
die anderen galten als "closed" "stealth" wäre sicher besser.
Stealth ist ein Marketing-Buzzword und in keinster Weise besser als closed. Im Gegenteil.
ACK micha
Martin Borchert, Donnerstag, 24. April 2003 15:21:
Ports sind per default dicht, wenn kein Dienst läuft. Also schalte alles ab, was du nicht brauchst. Bei dem, was du nur nach innen brauchst, sorgst du dafür, dass es nicht an externen Interfaces lauscht. Meist wird das mit "listen" oder "interface" in den Konfigurationsdateien gesteuert.
Wie sage ich das Cyrus? Weder in der imapd.conf noch in der cyrus.conf finde ich eine Möglichkeit, das zu belauschende Interface zu definieren. -- Andreas Feile www.feile.net
On Thu, Apr 24, 2003 at 03:54:33PM +0200, Andreas Feile wrote:
Wie sage ich das Cyrus? Weder in der imapd.conf noch in der cyrus.conf finde ich eine Möglichkeit, das zu belauschende Interface zu definieren.
$ man cyrus.conf ... listen=<no default> The UNIX or internet socket to listen on. This string field is required and takes one of the follow ing forms: path [ host : ] port where path is the explicit path to a UNIX socket, host is either the hostname or bracket-enclosed IP address of a network interface, and port is either a port number or service name (as listed in /etc/ser vices). ... $ cat /etc/cyrus.conf ... imap cmd="imapd" listen="192.168.254.12:imap" prefork=0 ... Kristian
Am Donnerstag, 24. April 2003 15:54 schrieb Andreas Feile:
Martin Borchert, Donnerstag, 24. April 2003 15:21:
Ports sind per default dicht, wenn kein Dienst läuft. Also schalte alles ab, was du nicht brauchst. Bei dem, was du nur nach innen brauchst, sorgst du dafür, dass es nicht an externen Interfaces lauscht. Meist wird das mit "listen" oder "interface" in den Konfigurationsdateien gesteuert. Wie sage ich das Cyrus? Weder in der imapd.conf noch in der cyrus.conf finde ich eine Möglichkeit, das zu belauschende Interface zu definieren.
Ich habe zwar noch nie mit dem Ding gearbeitet, aber eben mal kurz nachgesehen. Und wenn es in deiner cyrus.conf sowas nicht gibt, liegt da wohl was im Argen: man 5 cyrus.conf ------------------------- ... listen=<no default> The UNIX or internet socket to listen on. This string field is required and takes one of the following forms: path [ host : ] port ... ------------------------- SuSE 8.1, cyrus-imapd 2.1.9 Alternativ tuts oft auch google. Klickst du erst hier: http://www.google.com/search?q=cyrus%20restrict%20interface&ie=UTF-8&oe=UTF-8 Und dann auf das erste Suchergebnis. obDisclaimer: Keine Ahnung, ob und wie das funktioniert, wie gesagt, mit Cyrus hatte ich noch nie etwas zu tun. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
On Thu, Apr 24, 2003 at 04:19:28PM +0200, Martin Borchert wrote:
obDisclaimer: Keine Ahnung, ob und wie das funktioniert, wie gesagt, mit Cyrus hatte ich noch nie etwas zu tun.
Das funktioniert. Ich habe das mal gebraucht, um Cyrus auf einem Veritas Cluster Server aufzusetzen. Im Wesentlichen ist das ein Setup, wo eine Maschine eine IP-Nummer hat und eine Anwendung eine andere, eigene virtuelle IP-Nummer hat. Fällt eine Maschine aus, übernimmt die andere Maschine die IP-Nummer der Anwendung und fährt dort eine Übernahme der Platten des externen Arrays mit dem Veritas Volume Manager. Nun hat die überlebende Maschine die IP-Nummer der toten Kiste und deren Platten und kann eine zweite Instanz des Cyrus hochfahren, um deren Aufgaben zeitweise zu übernehmen. Damit das funktioniert, darf sich der Cyrus nur an die IP-Nummer der Anwendung binden. Kristian
* On Thu, Apr 24, 2003 at 03:21 PM (+0200), Martin Borchert wrote:
Am Donnerstag, 24. April 2003 14:30 schrieb Heiner Gewiehs:
Am Donnerstag, 24. April 2003 12:29 schrieb Steffen Moser:
* On Thu, Apr 24, 2003 at 10:48 AM (+0200), Peter Wiersig wrote:
Was steckt hinter dem "couldn't find service c" ??
Du willst mal eine Paket-Filter Regel einfuegen, die smb-Pakete aus dem Internet wegfiltert. ACK!
NACK, was du wirklich willst, ist dir die Optionen "interfaces" und "bind interfaces only" von Samba ansehen.
Stimmt, da habe ich zu schnell drübergelesen. :-/ Es ist IMHO natürlich sinnvoller, solche Restriktionen möglichst schon mal direkt bei den Applikationen (hier: Samba) zu konfigurieren (oder gar nicht benötigte Dienste abzuschalten) als erst über den Paketfilter.
die anderen galten als "closed" "stealth" wäre sicher besser.
Stealth ist ein Marketing-Buzzword und in keinster Weise besser als closed. Im Gegenteil.
ACK! Wobei ich hier annehme, dass mit "stealth" ein DROP gemeint ist und "closed" bedeutet, dass eine entsprechende ICMP-Nachricht zurückkommt (also im Grunde ein "REJECT"). Gruß Steffen
Am Donnerstag, 24. April 2003 15:21 schrieb Martin Borchert:
Am Donnerstag, 24. April 2003 14:30 schrieb Heiner Gewiehs:
Am Donnerstag, 24. April 2003 12:29 schrieb Steffen Moser:
* On Thu, Apr 24, 2003 at 10:48 AM (+0200), Peter Wiersig wrote:
Was steckt hinter dem "couldn't find service c" ??
Hallo, nach meiner Rückkehr von der gestrigen, nicht geplanten Aushäusigkeit, habe ich feststellen müssen, dass sich diese Diskussion doch etwas verselbständigt hat.
NACK, was du wirklich willst, ist dir die Optionen "interfaces" und "bind interfaces only" von Samba ansehen.
in der smb.conf fand ich nur folgenden Eintrag, von "bind interfaces only" nicht zu sehen: ; interfaces = 192.168.1.1/255.255.255.0 meine Netzwerkkarten haben folgende IP eth0 = LAN = 192.168.1.2 eth1 = DSL = 192.168.2.1
Hängt aber auch davon ab, was das für ein Netz ist. Ich antizipiere mal ein paar freundliche Windows-Kisten und der Linux-Rechner, der gleichzeitig das Tor zum bösen Internet ist. Richtig?
Stimmt - 2 Win98SE- Rechner am Linux SuSE- Server 8.2
Was sollte ich noch tun, ich meine außer die Ports abzudichten?
Ports sind per default dicht, wenn kein Dienst läuft. Also schalte alles ab, was du nicht brauchst. Bei dem, was du nur nach innen brauchst, sorgst du dafür, dass es nicht an externen Interfaces lauscht. Meist wird das mit "listen" oder "interface" in den Konfigurationsdateien gesteuert.
# # Listen: Allows you to bind Apache to specific IP addresses and/or # ports, in addition to the default. See also the <VirtualHost> # directive. # #Listen 3000 #Listen 12.34.56.78:80 Das wäre dann der Punkt aus der httpd.conf? Ich müsste also hier festlegen, dass er nur nach innen lauscht? also: "Listen 192.168.1.2:80" ?
Bei dem, was du wirklich nach außen brauchst, musst du auf sichere Software achten, sprich updates installieren, wenn Sicherheitslöcher gefixt wurden.
Das ist der Apache in der Version 1.3.27, die der SuSE 8.2 beiliegt. Updates sind gelaufen.
Shields up hat die Ports gescannt und folgende geöffnet 80 HTTP OPEN!
Brauchst du den nach außen? Wenn nicht, abschalten.
Nee, nach außen brauch ich den eigentlich noch nicht! Nach innen wegen PHP4 und MySQL. reicht hier eine IPtables Regel? iptables -A INPUT -i eth0 -p tcp --dport 80 -j REJECT oder wie Kristian empfahl, 3:10 an REJECT anhängen entsprechend auch für Port 139?
139 NetBIOS OPEN!
Das sollte man nun wirklich nicht nach außen aufmachen, es sei denn, man hat verdammt gute Gründe und weiß genau, was man tut.
Vermutlich hat sich Samba diesen Port selbst freigemacht. Ich habe, bevor ich Apache, Samba und PHP4 installiert und automatisch starten ließ, schon einen Port- Scan laufen lassen - da waren alle Ports als "closed" gemeldet.
Wie dichte ich die am besten ab?
Sorge dafür, dass die Dienste nicht am externen Interface lauschen: Bei Samba geht das z.B. mit den Direktiven "interfaces" und "bind interfaces only".
; interfaces = 192.168.1.1/255.255.255.0 also Kommentarzeichen weg und interfaces = 192.168.1.2/255.255.255.0 wäre das ok?
Den Rest macht dein Linux für dich.
Martin
Viel Grüße Heiner -- ******************************* H e i n e r G e w i e h s Marketing - Fachkaufmann D- 63868 Großwallstadt Mail: heiner.gewiehs@gewiehs.de *******************************
Hallo, * On Fri, Apr 25, 2003 at 10:19 AM (+0200), Heiner Gewiehs wrote:
Am Donnerstag, 24. April 2003 15:21 schrieb Martin Borchert:
Am Donnerstag, 24. April 2003 14:30 schrieb Heiner Gewiehs:
Am Donnerstag, 24. April 2003 12:29 schrieb Steffen Moser:
* On Thu, Apr 24, 2003 at 10:48 AM (+0200), Peter Wiersig wrote:
Was steckt hinter dem "couldn't find service c" ??
Hallo,
nach meiner Rückkehr von der gestrigen, nicht geplanten Aushäusigkeit, habe ich feststellen müssen, dass sich diese Diskussion doch etwas verselbständigt hat.
NACK, was du wirklich willst, ist dir die Optionen "interfaces" und "bind interfaces only" von Samba ansehen.
in der smb.conf fand ich nur folgenden Eintrag, von "bind interfaces only" nicht zu sehen: ; interfaces = 192.168.1.1/255.255.255.0
Dann setze das "bind interfaces only = Yes" mal aktiv. Damit sollte dann Samba nur auf "eth0" lauschen. Und zusätzlich zu den Interfaces noch "127.0.0.1" hinzufügen. Also so: interfaces = 192.168.1.1/255.255.255.0 127.0.0.1 bind interfaces only = Yes Das "127.0.0.1" braucht man zumindest früher, wenn "bind interfaces only" aktiv war und man den Samba-Server als WINS-Server betrieb, damit der Samba-Server selber "sich" für WINS-Anfragen erreichen konnte. Ob man es noch braucht, weiß ich nicht, aber schaden sollte es i.A. nicht.
meine Netzwerkkarten haben folgende IP eth0 = LAN = 192.168.1.2 eth1 = DSL = 192.168.2.1
Für die "eth1" braucht es eigentlich gar keine IP-Adresse (ich nehme an, Du hast darauf PPPoE laufen, wie man es z.B. bei T-DSL einsetzt). Das PPPoE nutzt das "eth1" direkt auf Ethernet-Ebene, daher könntest Du eigentlich (ich weiß nicht, ob YaST das unterstützt) das "eth1" ohne IP-Adresse konfigurieren. Das Device, mit dem Du mit der Außenwelt verbunden bist, ist vermutl. das "ppp0".
Hängt aber auch davon ab, was das für ein Netz ist. Ich antizipiere mal ein paar freundliche Windows-Kisten und der Linux-Rechner, der gleichzeitig das Tor zum bösen Internet ist. Richtig?
Stimmt - 2 Win98SE- Rechner am Linux SuSE- Server 8.2
Man kann noch ein "hosts allow" setzen und da z.B. reinschreiben: hosts allow = localhost, 192.168.1. Damit dürfen dann nur Rechner auf Deinen Samba-Server zugreifen, die in Deinem lok. Netz "192.168.1.0/24" sind. Aber eigentlich sollte dies bereits durch die alleinige Bindung an das interne Device so sein. Steffen
Am Freitag, 25. April 2003 11:30 schrieb Steffen Moser:
Hallo,
* On Fri, Apr 25, 2003 at 10:19 AM (+0200), Heiner Gewiehs wrote:
Am Donnerstag, 24. April 2003 15:21 schrieb Martin Borchert:
Am Donnerstag, 24. April 2003 14:30 schrieb Heiner Gewiehs:
Am Donnerstag, 24. April 2003 12:29 schrieb Steffen Moser:
* On Thu, Apr 24, 2003 at 10:48 AM (+0200), Peter Wiersig wrote:
Hallo noch einmal, ich hab's endlich! Glaube, nun ist Ruhe!! Kein Generve in der /var/log/messages von wegen "Was steckt hinter dem "couldn't find service c" ??"
Dann setze das "bind interfaces only = Yes" mal aktiv. Damit sollte dann Samba nur auf "eth0" lauschen. Und zusätzlich zu den Interfaces noch "127.0.0.1" hinzufügen. Also so:
interfaces = 192.168.1.1/255.255.255.0 127.0.0.1 bind interfaces only = Yes
Das "127.0.0.1" braucht man zumindest früher, wenn "bind interfaces
Das habe ich getan. Vielen Dank Steffen!! Von Martin Borchert kam der Tipp mit dem Indianer http://httpd.apache.org/docs/bind.html und der Rat "bind" zu benutzen, was auch zutreffend war. Ich habe dabei noch eine Übersicht gefunden, die nicht schlecht, da sehr übersichtlich ist: http://httpd.apache.org/docs/mod/core.html#bindaddress Also, "Probe my Ports" hat alle Ports als "closed" gemeldet. In der var/log/messages tauchen auch keine Sondermeldungen mehr auf. Vielen Dank aber auch an die anderen, die mich mit ihren Hinweisen auf die richtige Spur gebracht haben. Schönes Wochenende Heiner -- ******************************* H e i n e r G e w i e h s Marketing - Fachkaufmann D- 63868 Großwallstadt Mail: heiner.gewiehs@gewiehs.de *******************************
Am Freitag, 25. April 2003 10:19 schrieb Heiner Gewiehs:
Am Donnerstag, 24. April 2003 15:21 schrieb Martin Borchert:
NACK, was du wirklich willst, ist dir die Optionen "interfaces" und "bind interfaces only" von Samba ansehen. in der smb.conf fand ich nur folgenden Eintrag, von "bind interfaces only" nicht zu sehen: ; interfaces = 192.168.1.1/255.255.255.0
meine Netzwerkkarten haben folgende IP eth0 = LAN = 192.168.1.2 eth1 = DSL = 192.168.2.1
Eth1 interessiert nicht. Wichtig ist ppp0. Das ist bei t-dsl das wirkliche externe Interface. Mal abgesehen davon kann man samba auch direkt die devices mitgeben, auf denen es lauschen soll. Finde ich persönlich übersichtlicher: interfaces = eth0 lo bind interfaces only = yes
# Listen: Allows you to bind Apache to specific IP addresses and/or # ports, in addition to the default. See also the <VirtualHost> # directive. # #Listen 3000 #Listen 12.34.56.78:80 Das wäre dann der Punkt aus der httpd.conf? Ich müsste also hier festlegen, dass er nur nach innen lauscht? also: "Listen 192.168.1.2:80" ?
Nicht ganz. Wichtig ist das "in addition to the default". Laut http://httpd.apache.org/docs/bind.html solltest du "bind" benutzen. Und unter Umständen musst du auch noch 127.0.0.1 hinzufügen.
Shields up hat die Ports gescannt und folgende geöffnet 80 HTTP OPEN! Brauchst du den nach außen? Wenn nicht, abschalten. Nee, nach außen brauch ich den eigentlich noch nicht! Nach innen wegen PHP4 und MySQL. reicht hier eine IPtables Regel? iptables -A INPUT -i eth0 -p tcp --dport 80 -j REJECT oder wie Kristian empfahl, 3:10 an REJECT anhängen entsprechend auch für Port 139?
Brauchst du nicht. Wenn auf einem Port kein Dienst lauscht, schickt dein Linux das entsprechende icmp-Paket. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
participants (7)
-
Andreas Feile -
Heiner Gewiehs -
Kristian Koehntopp -
Martin Borchert -
Michael Meyer -
Peter Wiersig -
Steffen Moser