Sieht bei mir genauso aus! Bin jetzt mit der Mail ein wenig überfrag!
Abusemeldung erhalten
- Jojo95
- Erledigt
-
-
named ist der Bind9 service.... also was soll uns das nun genau sagen bzw. genauer: was ist zu unternehmen!??
-
Mal ne blöde Frage: Warum macht ihr kein Port-Whitelisting um sicherzustellen, dass nur exakt die Ports aus dem Internet erreichbar sind, die ihr explizit freigegeben habt? Das würde nämlich verhindern, dass so ein blöder RPC-Dienst auf 0.0.0.0 lauscht && von außen erreichbar ist weil er entweder schon standardmäßig in der Distribution aktiviert war oder in der Zwischenzeit mit einem anderen Dienst mitinstalliert wurde, ohne dass ihr es gesehen habt.
-
Danke für den Tipp und den Link. Ich versuche das so zu konfigurieren
EDIT:
Ich glaube es hat funktioniert. Gibt es eine Möglichkeit zu überprüfen, ob es geklappt hat? -
EDIT:
Ich glaube es hat funktioniert. Gibt es eine Möglichkeit zu überprüfen, ob es geklappt hat?
Hi. Im Prinzip schon: Wenn du zum Beispiel nur den SSH-Port freigegeben hast könntest du gucken, ob Verbindungsversuche zu allen anderen Ports, die ein Dienst sonst noch nach außen hin aufgemacht hat (die aber jetzt durch das Whitelisting von außen nicht mehr erreichbar sind), noch funktionieren. Da alle Verbindungsversuche auf nicht-freigegebene Ports gedroppt werden solltest du keine Antwort mehr von irgendeinem anderen Port bekommen wenn du zum Beispiel nc hostname port von außerhalb ausführst. -
Gute Idee, das versuche ich gleich.
Wenn ich das Skript ein 2. mal ausführe, dann werden alle Whitelistening Regeln wieder entfernt, richtig?
Tatsächlich sind jetzt aus meiner Sicht mehr Regeln gesetzt als ich in dem Skript definiert habe.iptables -S
-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N WHITELIST
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j WHITELIST
-A INPUT -s 192.168.1.0/24 -j ACCEPT
-A WHITELIST -p tcp -m tcp --dport 22 -j ACCEPT
-A WHITELIST -p tcp -m tcp --dport 80 -j ACCEPT
-A WHITELIST -p tcp -m tcp --dport 443 -j ACCEPT
-A WHITELIST -p tcp -m tcp --dport 8080 -j ACCEPT
-A WHITELIST -p tcp -m tcp --dport 8445 -j ACCEPT
-A WHITELIST -p tcp -m tcp --dport 5222 -j ACCEPT
-A WHITELIST -p tcp -m tcp --dport 5269 -j ACCEPT
-A WHITELIST -p udp -m udp --dport 9987 -j ACCEPT
-A WHITELIST -p tcp -m tcp --dport 30033 -j ACCEPT
-A WHITELIST -p tcp -m tcp --dport 10011 -j ACCEPT
-A WHITELIST -p tcp -m tcp --dport 41144 -j ACCEPTDie Ports 22, 80, 443, 8080, 8445 habe ich im Skript in das WHITELISTENING Array geschrieben.
Danke
-
Ja, das sieht richtig so aus. Wenn du allerdings die Beispielports für TeamSpeak und XMPP nicht geöffnet haben willst, dann entfernst du die natürlich aus dem WHITELISTING-Array. Da kommen nur die Ports rein, die du wirklich aufhaben willst. Die anderen Regeln sind dazu da, dass zum Beispiel Verbindungen auf das Loopback-Interface auf 127.0.0.1 nicht gedroppt werden. Das ist richtig so. Allerdings:
Zitat-A INPUT -s 192.168.1.0/24 -j ACCEPT
Dieses Subnetz könntest du noch ändern auf das von Netcup damit die Kommunikation mit dem Gateway und anderen Diensten im lokalen Netzwerk nicht gestört werden. Die Subnetzmaske(n) kannst du über ip addr show eth0 herausfinden.
-
Danke für die Hilfe.
Es hat alles geklappt, ich konnte es auch testen.Ich war ganz fixiert auf die HTTP ports, deswegen hatte ich die übrigen Beispielports versehentlich noch drinnen gelassen - sorry
-
Danke für die Hilfe.
Es hat alles geklappt, ich konnte es auch testen.Ich war ganz fixiert auf die HTTP ports, deswegen hatte ich die übrigen Beispielports versehentlich noch drinnen gelassen - sorry
Ah, OK. Aber noch zu deiner anderen Frage, die ich vergessen habe zu beantworten:
Wenn du das Skript erneut ausführst entfernt es nur temporär während der Skriptlaufzeit alle Regeln und Chains, nur um sie dann wieder hinzuzufügen. Es könnte ja sein, dass du zum Beispiel in Zukunft einen weiteren Port hinzufügen willst. Dann fügst du den Port zu dem WHITELISTING-Array hinzu, führst das Skript erneut aus, und der zusätzliche Port ist auf der Whitelist. Ich habe noch keinen automatischen Mechanismus zum Deinstallieren eingebaut (wollte ich schon seit längerer Zeit mal machen - ich glaub, ich mach das mal bald). Wenn du alles wieder entfernen willst kannst du dir ein kleines Reset-Skript schreiben:
Bash
Alles anzeigen#!/bin/bash #=============================================================================== # Define IPTables commands for IPv4 and IPv6 #=============================================================================== IPTABLES_V4=iptables IPTABLES_V6=ip6tables #=============================================================================== # Wrapper function for IPTables with IPv4 and IPv6 #=============================================================================== IPTABLES() { ${IPTABLES_V4} $@ # Appends the given argument string to IPTables for IPv4 ${IPTABLES_V6} $@ # Appends the given argument string to IPTables for IPv6 } #=============================================================================== # Reset IPTables #=============================================================================== IPTABLES --policy INPUT ACCEPT IPTABLES --flush IPTABLES --delete-chain WHITELIST &> /dev/null IPTABLES --delete-chain BLACKLIST &> /dev/null
-
Das wundert mich.
Ich habe vorhin das Skript mit meinem + Beispielports laufen lassen. Anschließend habe ich die Beispielports entfernt und es wieder laufen lassen, dann waren nur die definierten Ports unter iptables -S zu sehen?Danke für das Skript, ich glaube aber es ging schon ohne.
-
Das wundert mich.
Ich habe vorhin das Skript mit meinem + Beispielports laufen lassen. Anschließend habe ich die Beispielports entfernt und es wieder laufen lassen, dann waren nur die definierten Ports unter iptables -S zu sehen?Ja, genau so meinte ich es auch. Lies nochmal, vielleicht hast du es falsch verstanden. Das Reset-Skript wäre nur notwendig wenn du ALLES wieder entfernen willst.
-
Achso Dann habe ich es tatsächlich falsch verstanden. Also alles gut, nur die benötigen Ports sind von außen erreichbar.
Danke für deine Hilfe und dein Skript, das ist wirklich sehr nützlich -
-
hallo,
das script funktioniert allerdings nicht bei den älteren vservern, da die keinen direkten iptables support haben! was dann? nur mühsam über vcp?
-
hallo,
das script funktioniert allerdings nicht bei den älteren vservern, da die keinen direkten iptables support haben! was dann? nur mühsam über vcp?
Du kannst in deinen Mount-Optionen für NFS die Option "nolock" (https://www.centos.org/docs/5/…lient-config-options.html) hinzufügen. Anschließend kannst du den alle Services, die etwas mit RPC zu tun haben, maskieren bzw. deaktivieren, sodass sie nicht mehr starten. NFS benötigt diese Dienste nur für das remote locking. Beachte aber, dass du dann Probleme bekommen könntest, wenn du von mehreren Servern gleichzeitig auf den Storage zugreifst..
-
[…] älteren vservern […] vcp […]
Falls Du ein altes Linux-VServer Produkt (mit geteiltem Kernel) meinst: Langsam ans Upgrade zu einem KVM-Server nachdenken!
-
Ich habe es nach der Anleitung gemacht und es funktioniert hervorragen.
Dumm nur, dass heute schon wieder eine abuse-Meldung eintraf Ich denke, dass Problem ist, dass der Dienst zwar nicht mehr korrekt 'funktioniert', der Scan vom BSI aber alleine auf open/closed/filtered testet. Und open wird anscheinend immer angemahnt. Dann muss also leider doch die iptables-Keule raus. Also her damit:
Aktuellen Status von außen mit nmap testen:
Code
Alles anzeigen# nmap --top-ports 20 meine-domain.de Starting Nmap 6.47 ( http://nmap.org ) at 2017-05-19 17:47 CEST Nmap scan report for meine-domain.de (aaa.bbb.ccc.ddd) Host is up (0.000012s latency). rDNS record for aaa.bbb.ccc.ddd: krassenummer.doofesgmx.net PORT STATE SERVICE 21/tcp closed ftp 22/tcp closed ssh 23/tcp closed telnet 25/tcp open smtp 53/tcp closed domain 80/tcp open http 110/tcp closed pop3 111/tcp open rpcbind 135/tcp closed msrpc 139/tcp closed netbios-ssn 143/tcp closed imap 443/tcp open https 445/tcp closed microsoft-ds 993/tcp closed imaps 995/tcp closed pop3s 1723/tcp closed pptp 3306/tcp closed mysql 3389/tcp closed ms-wbt-server 5900/tcp closed vnc 8080/tcp open http-proxy Nmap done: 1 IP address (1 host up) scanned in 2.14 seconds
Nun fügen wir ein paar iptables Regeln hinzu, nämlich:
- UDP Pakete auf Port 111 kommentarlos ignorieren
- Lokale TCP-Pakete auf Port 111 verarbeiten
- TCP-Pakete auf Port 111 die nicht von unserer eigenen IP kommen kommentarlos ignorieren
Bashiptables -A INPUT -p udp --dport 111 -j DROP iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT iptables -A INPUT -p tcp ! -s aaa.bbb.ccc.ddd --dport 111 -j DROP
Das Ergebnis der Bemühungen:
Bash
Alles anzeigen# nmap --top-ports 20 meine-domain.de Starting Nmap 6.47 ( http://nmap.org ) at 2017-05-19 18:17 CEST Nmap scan report for meine-domain.de (aaa.bbb.ccc.ddd) Host is up (0.000012s latency). rDNS record for aaa.bbb.ccc.ddd: krassenummer.doofesgmx.net PORT STATE SERVICE 21/tcp closed ftp 22/tcp closed ssh 23/tcp closed telnet 25/tcp open smtp 53/tcp closed domain 80/tcp open http 110/tcp closed pop3 111/tcp filtered rpcbind 135/tcp closed msrpc 139/tcp closed netbios-ssn 143/tcp closed imap 443/tcp open https 445/tcp closed microsoft-ds 993/tcp closed imaps 995/tcp closed pop3s 1723/tcp closed pptp 3306/tcp closed mysql 3389/tcp closed ms-wbt-server 5900/tcp closed vnc 8080/tcp open http-proxy Nmap done: 1 IP address (1 host up) scanned in 2.14 seconds
Quelle: https://www.cyberciti.biz/faq/…th-iptables-tcp-wrappers/
Hier noch ein paar Fragen die sich der eine oder andere Stellen mag:
- Soll ich trotzdem hosts.allow bearbeiten?
- Unbedingt! Wie im debian-Link meines ersten Postings angegeben, sollte eine firewall-Regel nur die erste Linie der Verteidigung sein. Falls diese Barriere aus irgendeinem Grund ausfällt, steht man mit heruntergelassenen Hosen da
- Im Link ist eine andere iptables-Syntax für die Ausnahme-IP angegeben, welche ist korrekt?
- MEINE! Nein, im Ernst: Der Befehl aus dem Link scheint fehlerhaft zu sein. Das Ausrufezeichen muss vor die betreffende Regel. So wird es auch bei iptables -h angezeigt. Falls Ihr ein komplettes Netz 'freischalten' wollt, könnt Ihr natürlich auch gerne die verwendete CIDR-Notation verwenden.
-
Was mache ich, wenn ich einen managed Server habe und die Meldung erhalten habe?
-
Was mache ich, wenn ich einen managed Server habe und die Meldung erhalten habe?
Bei Managed Serverprodukten ist netcup für das Betriebssystem zuständig. Insofern würde ich jetzt mal sagen: Einfach ignorieren.
-
Was mache ich, wenn ich einen managed Server habe und die Meldung erhalten habe?
Auf Nachfrage hat mich der Support gefragt, was er machen soll. Sperren oder deinstallieren.
Ich würde mich also an den Support wenden.