Seiten: [1] 
|
 |
|
|
Autor
|
Thema: Geschwindigkeit von Sicherheitsfixes (Gelesen 1282 mal)
|
|
Andreas
Administrator
 Offline
Einträge: 1319
Linux von Innen
|
 |
Geschwindigkeit von Sicherheitsfixes
« am: 16. Oktober 2022, 10:49:55 »
|
|
Seit Monaten beobachte ich auf meinen Servern (alle inzwischen Arch-basiert) eine ansteigende Menge an Einbruchsversuchen. Die verwendeten Techniken sind öfter "neu" für mich - ich schaue mir ja jeden Tag die Logs an. Vorgestern hat eine gewaltige Angriffswelle für ein paar Stunden die volle Bandbreite einiger Server voll ausgeschöpft. Woher die Angriffe kommen kann ich natürlich sagen (IP-Geolocation) - nicht aber wer der Verursacher ist. Vermuten tue ich Aktivitäten rund um den aktuellen Konflikt mit Russland. Ich glaube nicht dass dort Interesse an den Inhalten meines Servers besteht - wohl aber an seiner Anbindung an die deutschen Datennetze. Man will Server entern um sie dann als weitere Angriffsmaschinen zu verwenden - wofür auch immer.
Meine Server haben bislang alles überstanden - einige andere in der gleichen Serverfarm wie meiner nicht. Zumindest haben letzte Nacht 6 Server aus dem gleichen Rechenzentrum versucht bei mir einzubrechen. Die Sicherheitslücke kenne ich inzwischen - ist schon vor einer Woche bei Arch gefixt worden. Bei Debian noch nicht... Dazu habe ich das hier gefunden:
https://curius.de/2022/02/sicherheitsupdates-bei-debian-wie-viel-verzoegerung-ist-normal/
Ich habe die geenterten Maschinen meinem Provider bereits gemeldet.
Ich denke aktuellste Software ist ein sehr wichtiger Aspekt. Natürlich betrifft das Server in besonders hohem Maße - aber auch "Privatrechner" können geentert und als Teil eines Botnetzes benutzt werden. Das betrifft auch mehr und mehr Linux-Systeme. Allerdings werden Systeme von "update-faulen" Nutzern besonders oft kompromittiert - und bei den Distris natürlich Distris die auf "alte, erprobte" Software setzen und dabei die Sicherheit in den Hintergrund gerät.
EDIT:
Ich habe gerade einen nmap-scan auf unseren Server (wo auch suletuxe.de drauf ist) losgelassen und habe das hier herausbekommen:
nmap -O -v 85.10.198.2
Starting Nmap 7.92 ( https://nmap.org ) at 2022-10-16 15:11 CEST
Initiating Ping Scan at 15:11
Scanning 85.10.198.2 [4 ports]
Completed Ping Scan at 15:11, 0.05s elapsed (1 total hosts)
Initiating SYN Stealth Scan at 15:11
Scanning myserver (85.10.198.2) [1000 ports]
Discovered open port 25/tcp on 85.10.198.2
Discovered open port 53/tcp on 85.10.198.2
Discovered open port 443/tcp on 85.10.198.2
Discovered open port 21/tcp on 85.10.198.2
Discovered open port 143/tcp on 85.10.198.2
Discovered open port 80/tcp on 85.10.198.2
Discovered open port 993/tcp on 85.10.198.2
Discovered open port 587/tcp on 85.10.198.2
Discovered open port 995/tcp on 85.10.198.2
Completed SYN Stealth Scan at 15:11, 4.30s elapsed (1000 total ports)
Initiating OS detection (try #1) against myserver (85.10.198.2)
Retrying OS detection (try #2) against myserver (85.10.198.2)
Nmap scan report for myserver (85.10.198.2)
Host is up (0.015s latency).
Not shown: 989 filtered tcp ports (no-response)
PORT STATE SERVICE
21/tcp open ftp
25/tcp open smtp
53/tcp open domain
80/tcp open http
143/tcp open imap
443/tcp open https
587/tcp open submission
993/tcp open imaps
995/tcp open pop3s
3000/tcp closed ppp
60020/tcp closed unknown
Aggressive OS guesses: Linux 5.0 - 5.4 (94%), Linux 5.0 (90%), Ubiquiti Pico Station WAP (AirOS 5.2.6) (89%), Linux 5.4 (88%), Linux 3.10 (87%), Linux 4.15 - 5.6 (87%), HP P2000 G3 NAS device (86%), Linux 5.3 - 5.4 (86%), Linux 2.6.32 (86%), Linux 2.6.32 - 3.1 (86%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 7.709 days (since Sat Oct 8 22:10:54 2022)
TCP Sequence Prediction: Difficulty=261 (Good luck!)
|
|
LG
Andreas
|
| « Letzte Änderung: 16. Oktober 2022, 13:15:55 von Andreas » |
 Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 487
|
|
Re:Geschwindigkeit von Sicherheitsfixes
« Antwort #1 am: 16. Oktober 2022, 16:53:18 »
|
|
Dann drücke ich dir fest die Daumen, dass man bei dir keine Lücke findet. 
Private Personen, die "Alterprobte Anwendungen" verwenden, sollten darauf achten, dass diese Anwendungen wenigstens Sicherheitspatches bekommen. Und nicht etwa komplett mehr gewartet werden (wie z.b. Python2) auch wenn diese Software noch perfekt ihren Dienst erledigt, kann diese auf die Zeit, in der sie altert, ein Einfallstor sein.
Bei dem Artikel den du gepostet hast
https://curius.de/2022/02/sicherheitsupdates-bei-debian-wie-viel-verzoegerung-ist-normal/
Stellte jemand in den Artikelverfasser eine Frage,worauf hin er eine passende Antwort bekommen hat:
Calabi-Yau 5. Februar 2022 Beim 12:45
Ich habe als Linux-Laie eine Verständnisfrage – auch wenn sie versierten Linux-Usern vielleicht dumm erscheinen mag: Wenn es bei Debian zu Verzögerungen bei Sicherheitsupdates wie dem o.g. Samba kommt, leiden dann auf Debian basierende Distros (z.B. das beliebte MX Linux) unter den gleichen Verzögerungen?
Avatar-FotoGerrit 5. Februar 2022 Beim 12:49
Distributionen, die einfach nur die Debian-Paketquellen einbinden, wie z. B. MX Linux oder Linux Mint Debian Edition (LMDE) haben diese Probleme auch. Du kannst in der sources.list nachsehen, ob da direkt Debian-Paketquellen hinterlegt sind.
Distributionen, die zwar von Debian abstammen, aber eigenen Paketquellen pflegen wie z. B. Ubuntu und Derivate haben die Probleme nicht.
|
|
Mit andren Worten, die Downstream Linux Mint Version, die von Ubuntu abstammt, hat dieses Problem nicht. Ich weiß, ich weiß, dafür aber andere 
|
| « Letzte Änderung: 16. Oktober 2022, 17:02:56 von Sebastian » |
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Seiten: [1] 
|
|
|
|
|
|
|
