Offene Ports (137,139, 445) Linux

Frankenheimer

╬Bruderschaft ALC╬
Thread Starter
Mitglied seit
30.09.2003
Beiträge
12.957
Ort
in einer Wohnung
Ich soll in meinem Praktikumsprojekt einen Linux Server aufsetzen und absichern. Nen Apache Webserver habe ich installiert und ich habe eine Authentifizierung von Linux Benutzern gegen ein Microsoft ADS eingerichtet.

(benötigt samba-winbind)

jetzt bin ich seit einigen wochen dabei die sicherheitslücken die ich mit nessus -erscannt habe zu schließen. unter anderem sind das folgende aussagen:

Netbios –ssn (139/tcp) security note

The remote native lan manager is: Samba 3.0.14.a-0.4-SUSE
The remote operation system is: unix
The remote SMB Domain Name is : TEST
An SMB server is running on this port.

Netbios-ns (137/udp) security warning

The following 7 NetBIOS names have been gathered

SLINUX (<-- Mein Rechnername)
SLINUX
SLINUX
__MSBROWSE__
TEST (<-- Domain)
TEST
TEST

This SMB server seems to be a SAMBA server. (this is not a security risk, this is for your information). This can be told because this server claims to have a null MAC address

If you do not want to allow everyone to find the NetBios name of your computer, you should filter incoming traffic to this port.

jetzt ist die frage, was genau ist mit FILTER traffic gemeint bzw wie gehe ich da vor? die aussagen im netz sind sehr widersprüchlich. einige meinen ich sollte den netbios dienst gleich ganz abschalten, aber ich befürchte das samba dann gar nicht mehr funktioniert. ich hatte es jetzt so gedacht dass ich nur im internen lan zugriff auf port 139 und 137 zulasse aber nach aussen hin dichtmache. wird das über ein config file gemacht oder über die firewall?
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
kommt drauf an

hängt dein apache server DIREKT im internet? sprich er hat direkt eine externe IP auf einer netzwerkverbindung?
dann schränke samba so ein dass er nur auf dem internen interface die ports öffnet

hat dein apache server nur eine interne IP und port80 wird von einer firewall zum apache server geleitet dann erübrigt sich der rest
 
ulukay schrieb:
kommt drauf an

hängt dein apache server DIREKT im internet? sprich er hat direkt eine externe IP auf einer netzwerkverbindung?
dann schränke samba so ein dass er nur auf dem internen interface die ports öffnet

hat dein apache server nur eine interne IP und port80 wird von einer firewall zum apache server geleitet dann erübrigt sich der rest
ich hoffe das ich dir ganz folgen konnte. ich habe apache auf port 8080 umgeleitet, unseren i-net port. von diesem ist er auch erreichbar. desweiteren habe ich bei apache ein paar änderungen in der conf datei vorgenommen, so dass er die version nicht direkt mit preisgibt. unter der lokalen ip meines rechners xxx.xxx.xxx.xxx:8080 ist der apache nun erreichbar. damit ist er nicht direkt im i-net, oder?
 
der apache ist nur im inet erreichbar wenn der externe port 8080, also von eurer inet ip auf deinen rechner geforwardet ist!
 
Nascar schrieb:
der apache ist nur im inet erreichbar wenn der externe port 8080, also von eurer inet ip auf deinen rechner geforwardet ist!
ich muss das erst nachgucken. das system läuft unter z/VM. ins i-net komm ich momentan nicht, aber ich habe auch keine proxydaten usw. eingestellt. aber was hat apache mit port 137 und 139 zu tun? ich dachte das betrifft erstmal nur die netbios namensvergabe?

sry ich bin in diesem bereich kein experte, ist das erste mal dass ich mich mit dem thema security befasse.
 
Also der Scan sagt ja nur das du darüber nachdenken solltest ob du die Netbios Ports nicht nur Rechnern deines LANs zur Verfügung stellen solltest.

Wenn das der Sinn der Übung ist dann schau dir mal IPTables an. Damit kannst du festlegen welcher Port über welches Interface und Proto und Richtung zur Verfügung gestellt wird.

Bezüglich der Config bin ich bei Suse nicht so firm da besonders die Struktur bei denen schon ganz schön verbogen ist (verglichen zu Debian und Co.). Aber sollte dort auch einfach über ein init Script gehen.

Aber ganz ehrlich. Sinn macht es nicht einen Filer mit nem Webserver zu kreuzen.

Denn "Security by obscurity is no security!"
 
die von dir genannten ports sind von samba und diehnen der datei und druckerfreigabe ;)
 
[g]nex schrieb:
Wenn das der Sinn der Übung ist dann schau dir mal IPTables an. Damit kannst du festlegen welcher Port über welches Interface und Proto und Richtung zur Verfügung gestellt wird.

das würde ich überflüssig finden da man jedes service unter linux so einstellen kann dass es nur auf eine bestimme IP adresse hört (wenns sein muss eben 127.0.0.1) - so erspart man sich einen software teil :)
 
ulukay schrieb:
das würde ich überflüssig finden da man jedes service unter linux so einstellen kann dass es nur auf eine bestimme IP adresse hört (wenns sein muss eben 127.0.0.1) - so erspart man sich einen software teil :)
das heisst im klartext? :d sry aber bei linux geschichten tue ich mich noch echt schwer, bin vielleicht nen paar monate aktiv dabei. ich such mich schon täglich bei google dumm und dämlich.
 
Ich denke er meint über hosts.allow/deny?
Genau das meinte ich mit Security by obscurity. Wenn dann sollte man auch noch iptables dazu einsetzen.
 
[g]nex schrieb:
Ich denke er meint über hosts.allow/deny?
Genau das meinte ich mit Security by obscurity. Wenn dann sollte man auch noch iptables dazu einsetzen.
ich werde mich jetzt gleich mal schlaumachen wie die konfiguration von host.allow und host.deny aussieht und was es mit den iptables auf sich hat.

ich habe übrigens nochmal ein check gemacht, diesmal aber vom internet aus, ich glaube von heise.de also port 137,139 und 445 sind ins i-net hinein gefiltert, also brauche ich mir erstmal keine sorgen machen dass meine "fehlkonfigurationen" oder offenen ports von seiten linux aus global übers i-net ausgenutzt werden können.

dennoch möchte ich den zugriff auch im lokalen netz einschränken, dann werde ich mir die tables mal anschauen. nur zum verständnis, diese ip tables sind die einschränkungen die dann als firewall gelten? also ports abblocken? greift die firewall von suse yast auf diese ip tables zu oder läuft das getrennt davon ab?
 
Frankenheimer schrieb:
nur zum verständnis, diese ip tables sind die einschränkungen die dann als firewall gelten? also ports abblocken? greift die firewall von suse yast auf diese ip tables zu oder läuft das getrennt davon ab?

IPTables IST die Firewall! Ich sage dir aber gleich, das IPTables kein Zuckerschlecken ist! Wenn du's allerdings mal beherrschst, hast du ein SEHR mächtiges Werkzeug! Vielleicht sogar mächtiger als PIX, Checkpoint usw ... :eek: Auf alle Fälle ist die SuSe Linux Firewall ein "drum herum gebasteltes" Script, mehr nicht!

Greetz

NetworkerZ
 
What is netfilter.org?

netfilter.org is home to the software of the packet filtering framework inside theLinux 2.4.x and 2.6.x kernel series. Software commonly associated with netfilter.org is iptables.

Software inside this framework enables packet filtering, network address [and port] translation (NA[P]T) and other packet mangling. It is the re-designed and heavily improved successor of the previous Linux 2.2.x ipchains and Linux 2.0.x ipfwadm systems.

netfilter is a set of hooks inside the Linux kernel that allows kernel modules to register callback functions with the network stack. A registered callback function is then called back for every packet that traverses the respective hook within the network stack.

iptables is a generic table structure for the definition of rulesets. Each rule within an IP table consists of a number of classifiers (iptables matches) and one connected action (iptables target).

netfilter, ip_tables, connection tracking (ip_conntrack, nf_conntrack) and the NAT subsystem together build the major parts of the framework.
--> http://www.netfilter.org/

Iptables baut auf Netfilter auf...;)
iirc brauchst du Netfilter support im Kernel um überhaup mit Iptables was machen zu können
--> http://www.gentoo.org/doc/en/home-router-howto.xml
 
Zuletzt bearbeitet:
Netfilter ist viel mehr ein Oberbegriff würde ich sagen. Mit Netfilter sind wohl die Module gemeint, iptables das ausführbare script, so mein Wissensstand. Tut ja aber auch nichts zur Sache. Für einen Laien sowieso schwer zu differenziern.

Greetz

NetworkerZ
 
[g]nex schrieb:
Ich denke er meint über hosts.allow/deny?
Genau das meinte ich mit Security by obscurity. Wenn dann sollte man auch noch iptables dazu einsetzen.

nö - ich rede direkt von den services!
bei samba z.b.:

interfaces = 192.168.1.1/24

das ist keine "Security by obscurity" sondern ein wesentlich besserer ansatz als -> zuerst port auf allen interfaces ausreissn -> und dann mit iptables rumfrickeln damit sie wieder zu sind

so sind sie nur da offn wo sie auch offen sein sollen

der andere weg ist der Windows Weg ;)
so erspart man sich iptables (zusätzliche konfiguration, zusätzliche software (also auchg zusätzliche fehlerquellen))
und wer denkt iptables ist mächtig der soll sich den paketfilter von openbsd mal ansehen :sabber:

und als "firewall" bezeichnet man keine software oder hardware sondern ein sicherheitskonzept
 
Zuletzt bearbeitet:
ulukay schrieb:
und wer denkt iptables ist mächtig der soll sich den paketfilter von openbsd mal ansehen :sabber:

Juhu, Grundsatzdiskussion :p Nein, im Ernst, da das wohl an mich gerichtet war: Du hast recht, ich sollte mir openbsd mal ansehen. Dies ändert jedoch nichts am daran, dass IPTables in den richtigen Händen mächtig ist ;)

Greetz

NetworkerZ
 
ich habe mich jetzt etwas schlau gemacht....zumindest habe ich es versucht. ergebnis ist, dass ich je länger ich mir die ganzen sachen anschaue umso verwirrter werde. iptables scheint nur eine möglichkeit zu sein das zu lösen. mit hosts.allow und hosts.deny komme ich auch nicht ganz klar, was ist gemeint?

dieses hosts.allow /deny gibts einmal in der /etc/samba/smb.conf als möglichen eintrag oder als dateien in /etc/

um nochmal auf die sicherheitslücken zurückzukommen die nessus mir auswirft:

Netbios –ssn (139/tcp) security note

The remote native lan manager is: Samba 3.0.14.a-0.4-SUSE
The remote operation system is: unix
The remote SMB Domain Name is : TEST
An SMB server is running on this port.

Netbios-ns (137/udp) security warning

SCAN vom Internet aus : Port 137 gefiltert


The following 7 NetBIOS names have been gathered

SLINUX77
SLINUX77
SLINUX77
__MSBROWSE__
TEST
TEST
TEST

This SMB server seems to be a SAMBA server. (this is not a security risk, this is for your information). This can be told because this server claims to have a null MAC address

If you do not want to allow everyone to find the NetBios name of your computer, you should filter incoming traffic to this port.

Risk factor: medium

könnte ich jetzt einfach als beispiel in der /etc/samba/smb.conf die zeilen

hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24
hosts deny = 0.0.0.0/0
einfügen wenn jetzt die letztgenannten ips von rechnern zugriff haben dürfen. würden die beiden oben genannten fehler dann verschwinden oder hätten angreifer dann immer noch die möglicheit an informationen zu kommen? kommt der fehler daher weil die ports offen sind, oder weil samba angreifern die informationen ausspuckt?

Microsoft-ds (445/tcp) security note & security hole
SCAN vom Internet aus: gefiltert

A CIFS server is running on this port

It was possible to log into the remote host using a NULL session. The concept of a Null session is to provide a null username and a null password, which grants the user the ‚guest‘ access

To prevent null sessions, se MS KB Article Q143474 (NT 4.0) an Q246261 (windows 2000)
Note that this won´t completely disable null sessions, but will prevent them from connecting to IPC$
Please see http://msgs.securepoint.com/cgi-bin/get/nessus-0204/50/1.html

The remote host defaults to guest when a user logs in using an invalid login. For instance, we could log in using the account ‚nessus/nessus‘

All the smb tests will be done as „/whatever‘ in domain TEST
CVE: CAN-1999-0504, CAN-1999-0506, CVE-2000-0222, CAN-1999-0505, CAN-2002-1117
dieser port ist ja auch aufgrund der existenz samba´s vorhanden bzw. offen. hier bin ich auf folgendes gestoßen im netz:

Wenn die obigen Methoden nicht anwendbar sind, könnten Sie auch eine spezifischere Ablehnung auf der IPC$-Freigabe setzen, die in einer kürzlich entdeckten Sicherheitslücke verwendet wird. Dies erlaubt Ihnen, Zugriff auf andere Freigaben anzubieten, während Sie den Zugriff von potenziell nicht vertrauenswürdigen Hosts auf IPC$ ablehnen.

Um dies zu tun, verwenden Sie folgendes:


[IPC$]
hosts allow = 192.168.115.0/24 127.0.0.1
hosts deny = 0.0.0.0/0

Dies weist Samba an, dass IPC$-Verbindungen nicht erlaubt sind, außer von den zwei angeführten Netzwerk-Adressen (localhost und dem Subnetz 192.168.115). Verbindungen zu anderen Freigaben sind weiter erlaubt. Da die IPC$-Freigabe die einzige Freigabe ist, auf die anonym zugegriffen werden kann, schafft dies einen gewisse Schutz vor Angreifern, die keine gültige Benutzernamen/Passwort-Kombination für Ihren Server kennen.

Wenn Sie diese Methode anwenden, werden Clients eine 'access denied'-Meldung erhalten, wenn sie versuchen, sich mit der IPC$-Freigabe zu verbinden. Diese Clients werden keine Freigaben durchsuchen können, und sie können auch manche andere Dienste nicht benutzen. Diese Methode wird nicht empfohlen, außer Sie können aus einem bestimmten Grund keine der anderen oben beschriebenen Methoden anwenden.

ist das die möglichkeit die fehlerquelle zu schließen....? ich bin ehrlich gesagt völlig ratlos. versuche morgen mal nen backup anzustoßen und dann kann ich mehr ausprobieren. hätte jemand mit ahnung (scheinen ja einige zu sein) vielleicht morgen mal zeit mir über icq oder mail etwas hilfe zu geben? von mir aus auch über diesen thread. ich komme mir hier als anfänger in den komplexen security einstellungen verloren vor. am liebsten würde ich samba komplett dicht machen, aber dann würde die authentifizierung von linux usern gegen ein ms ads nicht mehr gehen oder?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh