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

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, 10 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, 11 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, 11 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, 11 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, 11 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, 11 Monate

2
1
0 0

Re: [rwth-security] Direkter Scan von RPC-Diensten

von Fabian Kiendl

On Mon, 16 Jul 2001, Jens Hektor wrote: > Portscan detected from 213.23.16.53 (esndi7-213-023-016-053.arcor-ip.net) to > service sometimes-rpc7 Portscans an sich sind leider noch nicht strafbar, aber gibt es ein Procedere, nach dem die RWTH gegen erfolgreiche Angriffe rechtlich vorgeht? Wenn jemand so dreist ist, einen deutschen Internet-by-Call Provider zu verwenden, besteht da eine gewisse Aussicht auf Erfolg. Laeuft eine Kiste wegen Neuinstallation einen Tag lang nicht, sind bei 30 Usern bei BAT IIa/2 schon fast 4000 Mark an Arbeitszeit vernichtet. F. Kiendl II. Physikalisches Institut

5 Jahre, 11 Monate

1
0
0 0

Re: [rwth-security] "VBS_Homepage_A" ueberschwemmt das Web

von Fabian Kiendl

On Wed, 9 May 2001, Guido Bunsen wrote: > der Virus wird seit heute nacht nicht mehr in die Hochschule gelassen. Werden auch die Mails erfasst, die nicht ueber den Mailserver des ReZe gehen, sondern ueber Instituts-Server (wie @physik.rwth-aachen.de)? F. Kiendl II. Physikalisches Institut

5 Jahre, 11 Monate

1
0
0 0

Template fuer Firewalling-Skript

von Fabian Kiendl

Hier mal beispielhaft ein Satz ipchains-"Beschwoerungsformeln", den ich als Standard-Firewall-Sicherung fuer Linux-Maschinen mal zur Diskussion stellen moechte (anzuhaengen an /etc/rc.d/boot.local): # verboten ist, was nicht erlaubt ist ipchains -P input DENY # lokales Loopback-Interface bleibt offen ipchains -A input -j ACCEPT -i lo # Antworten auf von "innen" aufgebaute Verbindungen reinlassen ipchains -A input -j ACCEPT -p tcp ! -y # Remote-Administration per ssh freigeben # ggfs. mit Option -s 137.226.0.0/255.255.0.0 auf RWTH einschraenken ipchains -A input -j ACCEPT -d 0/0 22 -p tcp # lokales Netz darf alles (ggfs. weiter einschraenken!) ipchains -A input -j ACCEPT -s 137.226.xxx.0/255.255.255.0 # alle abgelehnten Pakete werden mitgeloggt (Vorsicht: /var Flood Gefahr) ipchains -A input -j DENY -l Fabian Kiendl II. Physikalisches Institut

5 Jahre, 11 Monate

1
0
0 0

Re: [rwth-security] RWTH-IN-2000-1009: Einbruch in Linux (fwd)

von Fabian Kiendl

On Tue, 10 Oct 2000, Jens Hektor wrote: > hier ein typisches Beispiel, dass die Wichtigkeit des Patchens > demonstriert: Wohnheim, RedHat Linux 6.2, keine Patches, Installation > 3 Wochen alt und keine wesentlichen Ver�nderungen an Originalinstallation, > Do. oder Fr. Einbruch �ber wu-ftpd-L�cke, Mo. als scannend gemeldet, > Mo. gesperrt, Di. untersucht: Hintert�r (SSH) Port 47017, Trojaner, Scantools. Noch wichtiger: Gleich nach der Installation saemtliche nicht benoetigten Dienste mit den Firewalling-Funktionen des Kernels zumindest fuer alle Rechner ausserhalb des lokalen Netzes sperren. Die meisten Leute gucken nicht mehr als 1x pro Woche auf die Patch-Page ihrer Distribution - eine Ewigkeit fuer die Skript-Kiddies. Und wieder eine Kiste mit beiden Schultern auf der Matte. Fabian Kiendl II. Physikalisches Institut

5 Jahre, 11 Monate

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

rwth-security