- rwth-security - lists.rwth-aachen.de

Re: TLS 1.3 (nun wohl final als RFC 8446) - UPDATE

von Bernd Kohler

Hallo zusammen, das Transport Layer Security (TLS) Protocoll in der Version 1.3 ist nach einigen Iterationen [0] nun als RFC 8446 [1] final. Zeit, sich mit den Änderungen/Neuerungen zu befassen - gehen wir also in medias res - alle bekannten Schwachstellen der Vorgängerversionen sollen ausgemerzt werden - es soll eine Latenzminimierung (interessant/relevant für Edge Computing, wie IoT Geräte) - Optimierung der Architektur, um das Nachrüsten von Algorithmen (wie bspw. SIDH - Supersingular Isogeny Deffie-Hellman, welcher auch Quantencomputern standhalten soll) zu erleichtern. - neues, schlankeres Handshake-Verfahren - neue Signaturalgorithmen - Änderung des konzeptionellen Aufbaues einer Cipher Suite - bei den Chipher Suites wird aufgeräumt - statisches RSA fällt weg - DSA Cipher Suites fallen weg - Diffie-Hellmann (DH) Cipher Suites fallen weg (nicht Elliptische Kurven, ECDH) - unsichere Hashfunktionen sind nicht mehr zulässig - SHA1 fälllt weg - MD5 fällt weg - Stream-Verschlüsselung mit RC4 fällt weg - Blockchiffre-Modus CBC fällt weg - es werden alle Handshake-Nachrichten (bis auf ServerHello Initialisierung) verschlüsselt - vorher im Klartext übertragene Protokollerweiterungen können als EncryptedExtension-Nachricht verschlüsselt übertragen werden - es wird auf überflüssige Nachrichten (wie Change-Cipher-Spec, außer bei Mittelbox-Kompatibilität) verzichtet - alle nicht AEAD Cipher werden entfernt (Authenticated Encryption with Associated Data, Verschlüsselung mit integrierter Vorkehrung zur Gewährleistung der Datenintegrität). - Kompression wird abgeschafft - eine Neuverhandlung der Protokollversion (downgrade und upgrade) ist prinzipiell ausgeschlossen, eine Nachtverhandlung (ClientHello) auf bspw. 1.2 wird mit der generischen Meldung "unexpected_message" beendet - Der neue TLS 1.3 Aufbau der Cipher Suite trennt Authentifizierungs- und Schlüsselaustauschverfahren von dem Algorithmus der Verbindungsabsicherung (TLS Record Protection Algorithm) und von der Hash-Funktion. Es wird weder der Schlüssel- austausch- noch der Authentifizierungsmechanismus vorgegeben (nun vereinbarte optionen) - Neuer Aufbau der Cipher Suite ermöglicht Forward Secrecy trotz 0-Rount Trip Time Resumption (RTT, beschleunigte Wiederaufnahme einer abgebauten Verbindung) mittels beim erstmalingen Verbindungsaufbau erzeugten Schlüssel - TLS 1.3 Cipher Suite in openssl nach [2]: - TLS13-AES-256-GCM-SHA384 - TLS13-AES-128-GCM-SHA256 - TLS13-AES-128-CCM8-SHA256 - TLS13-AES-128-CCM-SHA256 - TLS13-CHACHA20-POLY1305-SHA256 - symmetrische Stream Cihper CHAHA20 - message authentication code (MAC) POLY1305 - Hashfunktion SHA256 - neue HMAC-based Key (Extract-and-Expand) Derivation Function (HKDF, RFC 5869) - Signaturerstellung (im Schlüsselaustauschverfahren) - Edwards-Curve Digital Signature Algorithm (EdDSA, RFC 8032) - Ed25519 (SHA512/256 und Curve 25519) - Ed448 (Ed448-Goldilocks) - Elliptic Curve Digital Signature Algorithm (ECDSA, u.a. RFC 5656) - RSA mit zugehöriger Hashfunktion (außer bspw. MD5) - Padding neben PKCS #1 (Version 1.5 RFC 2313) nun auch PSS (Probabilistic Signature Scheme, u.a. RFC 8017, obsolet RFC 2437) Padding - SHA1 für Signatur eines Zertifikates weiterhin noch erlaubt, nicht jedoch (mit Ausnahme bei Rückwärtskompatibilität zu TLS 1.2) für signierten TLS-Handshake - es können Zertifikate vom Typ X.509v3 (bspw. in der DFN-PKI, siehe [3]) verwendet werden - Einsatz von OpenPGP Zertifikate ist untersagt - Schlüsselvereinbarung (mit Forward Secrecy) nur noch via - Elliptic Curve Diffie-Hellmann Exchange (ECDHE) - Finite-Field Diffie-Hellmann Exchange (Kompatibilität mit älteren Client) - Pre Shared Key (PSK, Wiederherstellung einer Sitzung) - PSK mit (EC)DH (ebenfalls zur Wiederaufnahme) - kein MtE (MAC then Encrypt), Nutzung von AEAD (Authenticated Encryption with Associated Data) -Cipher - Entschlüsselungsfehler werden nichts sagend mit "bad_record_mac" quittiert, die Verbindung wird beendet - TLS 1.3 Handshake erspart einen ganzen Roundtrip (nur noch 3 statt 6 Schritte), einige Hundert Millisekunden schneller (ClientHello: Liste unterstützter Cipher + Versuch Schlüsselvereinbarungsprotokoll des Servers zu erraten und passenden mitzuliefern ServerHello: Wählt Protokoll der angebotenen Schlüsselvereinbarung und sendet eigenen Key-Share, Zertifikat und ServerFinished) - Symmetrische Verschlüsselung bereits nach einem Roundtrip (1-RTT) Eine Übersicht über die Client, welche bereits TLS 1.3 unterstützen, findet sich auf [4] VG Bernd p.s.: Nein ich habe mir noch nicht den finalen RFC durchgelesen, sondern mal eben den Artikel aus der aktuelle iX 8/2018 [0] https://datatracker.ietf.org/doc/rfc8446/ [1] https://tools.ietf.org/rfc/rfc8446.txt [2] https://wiki.openssl.org/index.php/TLS1.3 [3] https://www.pki.dfn.de/fileadmin/PKI/anleitungen/DFN-PKI-Zertifikatprofile_… [4] https://caniuse.com/#feat=tls1-3 -- Bernd Kohler IT Center Abteilung: Netze RWTH Aachen University Wendlingweg 10 52074 Aachen Tel: +49 241 80-29793 Fax: +49 241 80-22666 kohler(a)itc.rwth-aachen.de https://www.itc.rwth-aachen.de

5 Jahre, 8 Monate

1
0
0 0

Side-Channel PoC Attack Targets Encryption Software Glitch

von Bernd Kohler

Hallo zusammen, sofern nicht selber schon gesehen/-lesen hier [0] FYI "Side-Channel PoC Attack Targets Encryption Software Glitch" Worum geht es? "A group of researchers at Georgia Tech were able to retrieve the encryption keys from mobile device analog signals unintentionally produced by processors – within seconds and without physical access to the devices. The private RSA encryption keys are pulled from encryption software program OpenSSL (specifically version 1.1.0g)." Da bei dem Smartphone "very close but without physical contact" und dem embedded device "eight inches away" (20,32 cm) genannt wird, würde das i.d.R. nicht ungeschehen erfolgen. Wie in dem Artikel beschrieben, haben die Entdecker einen patch an die Entwickler von openSSL geschrieben, der am 20. May aufgenommen wurde. Alle, die Images für bspw. Android bereitstellen sind nun in der Pflicht. VG Bernd [0] https://threatpost.com/side-channel-poc-attack-targets-encryption-software-… -- Bernd Kohler IT Center Abteilung: Netze RWTH Aachen University Wendlingweg 10 52074 Aachen Tel: +49 241 80-29793 Fax: +49 241 80-22666 kohler(a)itc.rwth-aachen.de https://www.itc.rwth-aachen.de

5 Jahre, 8 Monate

1
0
0 0

VirtualBox VRDP Guest-to-Host Escape

von Bernd Kohler

Hallo zusammen, sofern nicht selber schon gesehen/-lesen hier das SecuriTeam Secure Disclosure [0] FYI "VirtualBox VRDP Guest-to-Host Escape" Betroffen ist der built-in RDP Server von VirtualBox in Kombination mit einem Windows Gast System. Wer also noch nicht die aktuelle Version 5.2.18 [1] von VirtualBox verwendet, darf jetzt gerne aktualisieren ;) VG Bernd [0] https://blogs.securiteam.com/index.php/archives/3736 [1] https://www.virtualbox.org/wiki/Downloads -- Bernd Kohler IT Center Abteilung: Netze RWTH Aachen University Wendlingweg 10 52074 Aachen Tel: +49 241 80-29793 Fax: +49 241 80-22666 kohler(a)itc.rwth-aachen.de https://www.itc.rwth-aachen.de

5 Jahre, 8 Monate

1
0
0 0

Re: BSI IT-Grundschutz

von Bernd Kohler

Hallo zusammen, neben der überarbeiteten Version des 1994 eingeführten IT-Grundschutzkatalog [0] des BSI, gibt es auf [1] auch zwei Online Kurse zu diesem Thema, behandelt wird: - Informationssicherheit mit IT-Grundschutz - Notfallmanagement Sofern nicht selber schon gesehen/-lesen hier FYI VG Bernd [0] https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzDownloads/itgr… [1] https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzSchulung/itgru… -- Bernd Kohler IT Center Abteilung: Netze RWTH Aachen University Wendlingweg 10 52074 Aachen Tel: +49 241 80-29793 Fax: +49 241 80-22666 kohler(a)itc.rwth-aachen.de https://www.itc.rwth-aachen.de

5 Jahre, 8 Monate

1
0
0 0

Wer verwendet nun noch Fax mittels Multifunktionsdrucker ;)

von Bernd Kohler

Hallo zusammen, sofern nicht selber schon gesehen/-lesen hier FYI der Artikel [0] von Checkpoint Research zu dem Thema "Sending Fax Back to the Dark Ages" Die Demo "Remote Code Execution on a fax machine via phone line" hierzu findet sich auf [1]. Im Prinzip geht es darum, dass über die Fax-Leitung ein Multifunktionsgerät als Eisntiegspunkt für weitere malicious Aktivitäten im LAN übernommen wird. Ob dies bei unseren Multifunktionsgeräten möglich ist kann ich aus der Ferne nich beurteilen, zudem will ich mir noch das PoC weitere Details anschauen. Wer weitere Infos hat darf natürlich gerne antworten ;) VG Benrd p.s.: die klassischen Fax-Only Geräte, die i.d.R. keinen LAN Anschluß besitzen sind natürlich nicht betroffen. [0] https://research.checkpoint.com/sending-fax-back-to-the-dark-ages/ [1] https://www.youtube.com/watch?v=1VDZTjngNqs -- Bernd Kohler IT Center Abteilung: Netze RWTH Aachen University Wendlignweg 10 52074 Aachen Tel: +49 241 80-29793 Fax: +49 241 80-22666 kohler(a)itc.rwth-aachen.de www.itc.rwth-aachen.de The real world meets IPv6 - first DDoS attack http://h-online.com/-1440502

5 Jahre, 9 Monate

1
0
0 0

Re: [rwth-security] OpenSSH Sicherheitslücke

von Hans-Bernhard Broeker

On Wed, 17 Sep 2003, Daniel Sievers wrote: > halte, sehe ich das richtig, dass die weder ein Announcement noch ein > Update-Paket zur OpenSSH Verwundbarkeit (und ebenso mysql) anbieten bis > jetzt? Oder bin ich blind? www.suse.de -> Security Zumindest das Announcement an ihre eigene Mailing-Liste ist raus, inklusive Pointer auf das Update-Paket. Mag sein, dass das nur die Bugs von gestern betraf, nicht die anscheinend heute nachgeschobenen Fixes. Vielleicht haben sie ja beschlossen, Announcement und Fix erst noch zu ergaenzen bevor sie's ins Web stellen. -- Hans-Bernhard Broeker (broeker(a)physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.

5 Jahre, 9 Monate

1
0
0 0

Re: [rwth-security] [MS/Generic, IIS] Neuer Wurm nutzt mehrere Schwachstellen zur Verbreitung aus (fwd)

von Fabian Kiendl

On Wed, 19 Sep 2001, Rolf Obrecht wrote: > f�r den Fall, dass es sich noch nicht herumgesprochen hat... Und da geht das Theater auch schon los, ich hab hier tonnenweise dieser wurmtypischen HTTP-Requests. Fast alle aus 137.x.y.z genau wie ich. Auf fruchtbaren (furchtbaren?) Boden gefallen ist der Wurm wohl auf einem Sack Arbeitsplatzrechner bei Novell, es sind aber auch ein paar Webserver an US-Unis dabei, teils bereits gesaeubert, teils noch nicht. F. Kiendl II. Physikalisches Institut

5 Jahre, 9 Monate

1
0
0 0

Re: [rwth-security] /default.ida?NNNNN... in Webserverlogdatei

von Fabian Kiendl

On Thu, 26 Jul 2001, Nils Junike wrote: > Irgendwie sieht das ganze f�r mich wie ein Angriff aus, der irgend einen > Bufferoverflow ausnutzt (immerhin m�sste eine Variable mit 255 "N" -und noch > irgendwas danach- angelegt werden). Ich wuerde mir mal mit nslookup die Namen zu den IP-Adressen anzeigen lassen und bei den Leuten, bei denen die Namen nicht nach Dialup-Provider aussehen, einfach mal eine Mail an den Postmaster der Domain schicken. Wer nicht weiss, dass seine Kiste versifft ist, macht sie auch nicht dicht. Die Namen, die mir angezeigt wurden, sahen alle bis auf einen nach irgendwelchen Buero-Rechnern aus, die normal keine Webserver-Funktion haben. Out-of-the-box standardinstalliert, tut's, gut, und die Dienste lassen wir eben Dienste sein. Der einzige Webserver unter den Befallenen war www.labor-ministry.gr, man kann also sagen, Code Red kommt in den besten Familien vor... F. Kiendl II. Physikalisches Institut

5 Jahre, 9 Monate

1
0
0 0

Re: Direkter Scan von RPC-Diensten - DFN-CERT#32202

von kohlrausch＠cert.dfn.de

-----BEGIN PGP SIGNED MESSAGE----- Hallo, > leider ist es jetzt dass eingetreten, was ich schon länger erwartet hatte: > ein direkter Scan auf Port 32772. Hinter diesem Port lauschen in der Regel > auf Suns (aber auch anderen Systemen) RPC-Dienste, zu denen doch zahlreiche > Verwundbarkeiten bekannt sind. > > sunrpc > 111/tcp > 111/udp > CA-2001-05, Exploitation of snmpXdmid > IN-2001-01, Widespread Compromises via "ramen" Toolkit > IN-2000-10, Widespread Exploitation of rcp.statd and wu-ftpd > Vulnerabilities > CA-2000-17, Input Validation Problem in rpc.statd > CA-1999-16, Buffer Overflow in Sun Solstice AdminSuite Daemon > sadmind > CA-1999-12, Buffer overflow in amd > CA-1999-08, Buffer overflow in rpc.cmsd > CA-1999-05, Vulnerability in statd exposes vulnerability in > automountd > CA-1998-12, Remotely Exploitable Buffer Overflow Vulnerability in > mountd > CA-1998-11, Vulnerability in ToolTalk RPC service > Einige Scanner (z.B. nmap) bieten die Moeglichkeit, direkt nach RPC Diensten zu scannen. Ich habe soeben erfahren, dass es einen Buffer Overflow Fehler im yppasswdd gibt, der Solaris 2.6 und 7 betrifft. Dieser Fehler in dem RPC-Dienst kann ueber das Netz ausgenutzt werden. Meines Wissens nach gibt es noch *keinen* Patch fuer diese Schwachstelle (zumindest noch kein offizielles SUN Advisory). Weitere Informationen ueber diese Schwachstelle finden Sie unter der URL http://www.securityfocus.com/bid/2763 und die urspruengliche Mail ueber bugtraq ist unten angefuegt. Wir werden diesen Vorfall unter der folgenden Nummer fuehren: DFN-CERT#32202 Bitte verwenden Sie diese Nummer fuer alle weitere Kommunikation. Mit freundlichen Gruessen, Jan Kohlrausch, DFN-CERT - -- Jan Kohlrausch | mailto:kohlrausch@cert.dfn.de DFN-CERT GmbH | http://www.cert.dfn.de/team/kohlrausch/ Oberstr. 14b. | Phone: +49(40) 808077 555 D-20144 Hamburg | FAX: +49(40) 808077 556 Germany | PGP-Key: finger kohlraus(a)ftp.cert.dfn.de Date: Mon, 28 May 2001 14:14:23 -0400 (EDT) From: Jose Nazario <jose(a)biocserver.BIOC.cwru.edu> X-Sender: <jose(a)biocserver.BIOC.CWRU.Edu> To: <bugtraq(a)securityfocus.com> Subject: solaris 2.6, 7 yppasswd vulnerability Message-ID: <Pine.LNX.4.30.0105281412380.28508-200000(a)biocserver.BIOC.CWRU.Edu> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="377562320-744030613-991073663=:28508" Status: OR - --377562320-744030613-991073663=:28508 Content-Type: TEXT/PLAIN; charset=US-ASCII aleph, please pass this on to bugtraq. this is *not* a crimelabs find, only some information i haven't yet seen on bugtraq. this is culled from the writeups by myself and matt fearnow (and is available on the incidents.org website http://www.incidents.org/news/yppassword.php). thanks. ____________________________ jose nazario jose(a)cwru.edu PGP: 89 B0 81 DA 5B FD 7E 00 99 C3 B2 CD 48 A0 07 80 PGP key ID 0xFD37F4E5 (pgp.mit.edu) - --377562320-744030613-991073663=:28508 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="yppasswd.txt" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.4.30.0105281414230.28508(a)biocserver.BIOC.CWRU.Edu> Content-Description: Content-Disposition: attachment; filename="yppasswd.txt" ICAgICAgICAgICAgICAgICAgICAgICAgVnVsbmVyYWJpbGl0eSBSZXBvcnQN Cg0KICAgICAgICBWdWxuZXJhYmlsaXR5OiBCdWZmZXIgb3ZlcmZsb3cgaW4g eXBwYXNzd2Qgc2VydmljZQ0KICAgICAgICAgICAgICBBZmZlY3RzOiBTb2xh cmlzIDYsIDcgKFNQQVJDIHRlc3RlZCwgeDg2IHVua25vd24pDQogICAgICAg ICAgICAgIEV4cGxvaXQ6IEluIGNpcmN1bGF0aW9uIChodHRwOi8vd3d3Lmhh Y2suY28uemEvKQ0KICAgICAgICAgVmVuZG9yIFBhdGNoOiBOb3QgeWV0Lg0K ICAgICAgICAgICAgICAgICAgICAgICBWYXJpb3VzIHBlb3BsZSBoYXZlIGNv bnRhY3RlZCBTdW4gYWJvdXQgdGhpcy4gTm8NCiAgICAgICAgICAgICAgICAg ICAgICAgb2ZmaWNpYWwgd29yZCB5ZXQuDQogICAgICAgICAgICAgICAgICAg ICAgIFdvcmthcm91bmRzIHN1cHBsaWVkIChpbmNsdWRlZCkuDQogICAgICAg ICAgICAgIENyZWRpdHM6ICdtZXRhcmF5Jw0KICAgICBBY2tub3dsZWRnZW1l bnRzOiBIYWNrZXJuZXdzIGZvciBoZWFkcyB1cA0KICAgICAgICAgICAgICAg ICAgICAgICBTdGVwaGVuIExlZSA8bGVlQG1haWxob3N0LnNqdS5lZHU+DQog ICAgICAgICAgICAgICAgICAgICAgIE1lbGFuaWUgSHVtcGhyZXkgPG1lbGFu aWVAbWF0aGNzLnNqc3UuZWR1Pg0KCQkgICAgICAgTmVpbCBMb25nIDxuZWls LmxvbmdAY29tcHV0aW5nLXNlcnZpY2VzLm94Zm9yZC5hYy51az4NCgkJICAg ICAgIE1hdHQgRmVhcm5vdyAoU0FOUykNCg0KRGVzY3JpcHRpb24NCg0KUGxl YXNlIG5vdGUgdGhhdCB0aGlzIGlzIGEgcHJlbGltaW5hcnkgY2hhcmFjdGVy aXphdGlvbiBvZiB0aGUgU29sYXJpcw0KeXBwYXNzd29yZCBidWZmZXIgb3Zl cmZsb3cuIFRoaXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgdG8gcHJvdmlkZSBh dCBsZWFzdA0Kc29tZSBpbmZvcm1hdGlvbiBhYm91dCBpdC4gUGxlYXNlIGNo ZWNrIGJhY2sgb3ZlciB0aGUgbmV4dCBmZXcgZGF5cyBhcyB0aGUNCmluZm9y bWF0aW9uIGlzIG1hZGUgbW9yZSBjb21wbGV0ZS4NCg0KQSBidWZmZXIgb3Zl cmZsb3cgZXhwbG9pdCAoZm9yIHRoZSBTUEFSQyBhcmNoaXRlY3R1cmUpIGhh cyBiZWVuIGZvdW5kIGluDQp0aGUgd2lsZCB3aGljaCB0YWtlcyBhZHZhbnRh Z2Ugb2YgYW4gdW5jaGVja2VkIGJ1ZmZlciBpbiB0aGUgJ3lwcGFzc3dkJw0K c2VydmljZSBvbiBTb2xhcmlzIDIuNiwgNyBtYWNoaW5lcy4gVGhlIEludGVs L3g4NiB2ZXJzaW9uIG9mIFNvbGFyaXMgMi42DQphbmQgNyBtYXkgYmUgdnVs bmVyYWJsZSBidXQgaGFzIG5vdCB5ZXQgYmVlbiB0ZXN0ZWQuDQoNClRvIGNo ZWNrIHlvdXIgc3lzdGVtIGZvciB2dWxuZXJhYmlsaXR5LCB1c2UgInJwY2lu Zm8gLXAgfCBncmVwIDEwMDAwOSIgb3INCnlvdSBjYW4gdXNlICJwcyAtZWYg fCBncmVwIHlwcGFzc3dvcmQiLiBJZiB5b3Ugc2VlIHNvbWV0aGluZywgeW91 ciBzeXN0ZW0NCmlzIHZ1bG5lcmFibGUgdG8gdGhpcyBleHBsb2l0Lg0KDQpF eHBsb2l0IGxvZyBtZXNzYWdlOg0KDQpNYXkgIDkgMTM6NTY6NTYgdmljdGlt LXN5c3RlbSB5cHBhc3N3ZGRbMTkxXTogeXBwYXNzd2RkOiB1c2VyDQpAQEBA QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEwNCkBA QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQA0K QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA DQpAQEBAQEBAQEBAQEBAQEBAQFAiDQpgIj8tIj8tIj8tIj8gOyAvYmluL3No LWMgZWNobyAncmplIHN0cmVhbSB0Y3Agbm93YWl0IHJvb3QgL2Jpbi9zaCBz aA0KLWknPno7L3Vzci9zYmluL2luZXRkIC1zIHo7cm0gejs6IGRvZXMgbm90 IGV4aXN0DQoNCg0KU3ltcHRvbXM6IHR3byBpbmV0ZHMgcnVubmluZzoNCg0K dmljdGltLXN5c3RlbTojIHBzIC1lZiB8IGdyZXAgaW5ldGQNCnJvb3QgICAy MDkgICAgIDEgIDAgICBBcHIgMzAgPyAgICAgICAgMDoxOCAvdXNyL3NiaW4v aW5ldGQgLXMgLXQNCnJvb3QgIDgyOTcgICAgIDEgIDAgMTM6NTY6NTYgPyAg ICAgICAgMDowMCAvdXNyL3NiaW4vaW5ldGQgLXMgeg0KDQoNCkVmZmVjdDog cm9vdCBzaGVsbCBvbiBwb3J0IDc3L1RDUA0KDQpzaGUtcmE6JCB0ZWxuZXQg dmljdGltLXN5c3RlbSByamUNClRyeWluZyAxOTIuMTY4LjEwLjUuLi4NCkNv bm5lY3RlZCB0byB2aWN0aW0tc3lzdGVtLmV4YW1wbGUuY29tLg0KRXNjYXBl IGNoYXJhY3RlciBpcyAnXl0nLg0KIw0KDQpEZXRlY3Rpb24NCg0KV2hpbGUg cnVubmluZyB0aGUgY29kZSBhZ2FpbnN0IGEgIm5vbiB2dWxuZXJhYmxlIiBT b2xhcmlzIHN5c3RlbSwNClNub3J0IHBpY2tzIHVwIHRoZSBmb2xsb3dpbmc6 DQoNCk1heSAxMCAyMDo1MjozMyBtYWNldyBzbm9ydFszMDgyNF06IElEUzE5 L3BvcnRtYXAtcmVxdWVzdC1hbW91bnRkOg0KMTkyLjE2OC40LjM4OjY1NCAt PiAxOTIuMTY4LjEyLjMwOjExMQ0KDQpNYXkgMTAgMjA6NTI6MzMgbWFjZXcg c25vcnRbMzA4MjRdOiBJRFMxOS9wb3J0bWFwLXJlcXVlc3QtYW1vdW50ZDoN CjE5Mi4xNjguNC4zODo2NTQgLT4gMTkyLjE2OC4xMi4zMDoxMTENCg0KTWF5 IDEwIDIwOjUyOjMzIG1hY2V3IHNub3J0WzMwODI0XTogSURTMTkvcG9ydG1h cC1yZXF1ZXN0LWFtb3VudGQ6DQoxOTIuMTY4LjQuMzg6NjU0IC0+IDE5Mi4x NjguMTIuMzA6MTExDQoNClRoZSBmb2xsb3dpbmcgaXMgdGhlIHNub3J0IHJ1 bGUgZnJvbSB3aGl0ZWhhdHMsIHRoYXQgcGlja2VkIHRoaXMgdXA6DQoNCmFs ZXJ0IFVEUCAkRVhURVJOQUwgYW55IC0+ICRJTlRFUk5BTCAxMTEgKG1zZzog DQoiSURTMTkvcG9ydG1hcC1yZXF1ZXN0LWF1dG9mc2QiOyBycGM6IDEwMDk5 LCosKjspDQoNClByb3RlY3Rpb24NCg0KVGhlIGJlc3Qgc29sdXRpb24gaXMg dG8gZmlyZXdhbGwgeW91ciBib3hlKHMpIHRoYXQgYXJlIHJ1bm5pbmcgTklT IGZyb20NCnRoZSBpbnRlcm5ldC4gSG93ZXZlciB0aGlzIHdpbGwgbm90IHN0 b3AgdGhlIGluc2lkZXIgYXR0YWNrLg0KDQpTdW4gaGFzIG5vdCByZWxlYXNl IGFuIG9mZmljaWFsIHBhdGNoIGZvciB0aGlzIHlldC4gQSB3b3JrYXJvdW5k IDEpIHdvdWxkDQpiZSB0byB0dXJuIG9mZiB5cHBhc3N3ZGQuIFRoaXMgaXMg YXJvdW5kIGxpbmUgMTMzIG9yIHNvIGluDQovdXNyL2xpYi9uZXRzdmMveXAv eXBzdGFydC4gSnVzdCBjb21tZW50IGl0IG91dC4gVGhlIGhhY2sgZG9lc24n dCBhcHBlYXINCnRvIHdvcmsgaWYgeXBwYXNzd29yZCBpcyBkaXNhYmxlZCB3 aXRoIE5JUyBzdGlsbCBydW5uaW5nLiBQbGVhc2Ugbm90ZSBpbg0KZG9pbmcg dGhpcywgeXBwYXNzd29yZCBpcyBub3QgcnVubmluZyBhbmQgdXNlcnMgY2Fu bm90IGNoYW5nZSB0aGVpcg0KcGFzc3dvcmQuDQoNCkFub3RoZXIgd29yayBh cm91bmQgMikgaXMgaWYgeW91IHN0aWxsIG5lZWQgdG8gcnVuIHlwcGFzc3dv cmQgaXMgdG8gZG8NCnRoZSBmb2xsb3dpbmc6DQoNCnNldCBub2V4ZWNfdXNl cl9zdGFjayA9IDENCnNldCBub2V4ZWNfdXNlcl9zdGFja19sb2cgPSAxDQpp biAvZXRjL3N5c3RlbSAoYWZ0ZXIgYSByZWJvb3Qgb2YgY291cnNlKQ0KDQpP ZiBjb3Vyc2UgYSBkaWZmZXJlbnQgZXhwbG9pdCBjb3VsZCB3b3JrIGFyb3Vu ZCB0aGF0IGJ1dCBob3BlZnVsbHkgdGhpcw0Kd2lsbCBwZXJtaXQgcGVvcGxl IHRvIHVzZSB5cHBhc3N3ZCB1bnRpbCBhIHBhdGNoIGlzIGZvcnRoY29taW5n LiBUaGlzIHN0ZXANCmhhcyBub3QgYmVlbiB0ZXN0ZWQgeWV0Lg0KDQpSZWZl cmVuY2VzDQoNCkZ1cnRoZXIgaW5mb3JtYXRpb24gY2FuIGJlIGZvdW5kIGF0 Og0KKiBodHRwOi8vd3d3LmluY2lkZW50cy5vcmcNCiogaHR0cDovL3d3dy5z YW5zLm9yZy9pbmZvc2VjRkFRL3VuaXgvTklTLmh0bSwgU2VjdXJpdHkgSXNz dWVzIGluIE5JUw0KKiBodHRwOi8vd3d3LnNhbnMub3JnL2luZm9zZWNGQVEv dW5peC9zZWNfc29sYXJpcy5odG0gU2VjdXJpbmcgU29sYXJpcw0KDQpDcmVk aXRzDQoNClRoaXMgc2VjdXJpdHkgYWR2aXNvcnkgd2FzIHByZXBhcmVkIGJ5 IE1hdHQgRmVhcm5vdyBvZiB0aGUgU0FOUyBJbnN0aXR1dGUNCmFuZCBKb3Nl IE5hemFyaW8uDQoNCkFsc28gY29udHJpYnV0aW5nIGVmZm9ydHMgZ28gdG8g TWVsYW5pZSBIdW1waHJleSBmb3IgdGhlIDEpIHdvcmthcm91bmQgYW5kDQpO ZWlsIExvbmcgZm9yIHRoZSAyKSB3b3JrYXJvdW5kIGFuZCB0byBTdGVwaGVu IExlZS4gQWNrbm93bGVkZ2VtZW50czoNCkhhY2tlcm5ld3MgZm9yIGhlYWRz IHVwLCBhbmQgJ21ldGFyYXknIGZvciBkaXNjb3ZlcmluZyB0aGlzIHZ1bG5l cmFiaWxpdHkuDQoNCg== - --377562320-744030613-991073663=:28508-- -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQEVAgUBO170oeI9ttyl3QPRAQHmAQf+PsHKwcY49HWHr3GCpZVWaCdRQ3p8YwVy pJC48vAqUaPNz7CqjCZzRPmCMaaSigtq3qsR2mhO+Tkij45m55YyKE25pribTIb9 aQZ7L9JGp7+4MeCyMGWfuZGvtYQxWoMW4FqYLXqMVwW7e9AtfXQALlDYTTxtDK1G EPgNM5rm3SvLJrpaEBLT0vy7f9F8T3+I9XxzXtHXvUf5MDmyfgm2Nt0r7g80FLH7 OH+OJDsGnuvQ+mefOm9l2u/10qB5LygcZ+JIQ2ZXlpF+yW9B9LQxb83qhJnquSrO HQtm1SoFqg1l1iQsesON5ZhZmBT5dEh/HBjRGhXHvMNnKaoRPJG1Mw== =gMGM -----END PGP SIGNATURE-----

5 Jahre, 9 Monate

1
0
0 0

Re: [rwth-security] Sichere Linux-Server-Distributionen?

von Fabian Kiendl

On Thu, 19 Jul 2001, Andreas Welbers wrote: > hat jemand von Euch schon Erfahrungen mit den diversen "angeblich" > speziell abgesicherten Linux-Distributionen sammeln koennen, die > gerade fuer den Aufbau von Servern wichtig sind? Geht IMHO auch einfacher, indem man einfach sein System "bottom up" aufbaut. D.h. man faengt mit einer Minimalinstallation gleich welcher Distribution an und installiert dann nur das absolut Notwendigste nach (Webserver, ssh-Server, ftp-Server?). Dann weiss man genau, man braucht fuer *diese* Pakete aktuelle Patches. Wie heisst es noch so schoen: Was sie zu hacken nicht verstanden, war der Dienst, der nicht vorhanden! An sich selbstverstaendlich und superwichtig: nur Admins duerfen einen Shell-Zugang zu der Maschine haben! Die meisten Exploits im Basissystems sind naemlich keine remote-Exploits, sondern erfordern, dass man schon lokaler User ist. Ohne Ansatzpunkt bleibt die Brechstange nutzlos. > Ich wollte eine solche Distribution fuer den Aufbau eines sicheren > Internet-Web/FTP-Server eingesetzen Wozu ueberhaupt ftp? Wenn eh niemand was uploaden soll, kannst du die Dateien doch mit auf den Webserver packen. Wieder ein Dienst weniger. F. Kiendl II. Physikalisches Institut

5 Jahre, 9 Monate

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

rwth-security