Bronies.de zieht um!

[Saij]

100MBit ist Standard. Jeder Server oder vServer den ich bis jetzt hatte, hatte diese Anbindung. Next Level ist für mich GBit Macht schon auf Arbeit Fun

FTP KANN gesnifft werden. Nur bitte wer stellt sich mit ner Man-In-The-Middle Attack zig Tagelang hin und wartet bis DesertFOX mal wieder was hochlädt?
Da hab ich atm mehr Angst um die Meetup Gallery, den TS Server und den Webserver bei Bronies.de. Die sind da um längen anfälliger.

Und einen Server minimal halten ist nicht immer besser. Kenn da Server aus riesigen Clusterverbünden die einiges an Ports offen haben, man mit diesen Ports nichts anfangen kann.

Selbst wenn man den FTP knacken würde, man wäre in einer chroot gefangen.

---

Ein Portscan blockiert schon die Funktionalität des Servers, eben weil auch noch ein TCP Handshake probiert wird.
Deswegen kann man ja so schön einfach Synfloods machen (Zum Glück wurde das aber gefixt -.-)

[Tion]

(20.02.2013)Lazy Dream schrieb:  Komm nicht mit "Der Server kann Lücken haben". Das geht bei jeder Software.
Ich würde eher behaupten, dass der Apache hier noch ersetzt werden sollte.

Deswegen hält man die Anzahl der Server möglichst gering

(20.02.2013)Lazy Dream schrieb:  btw. Portscans gelten als Angriff.

Kommt drauf an, wie weit sie gehen - es ist ja auch nicht verboten, zu gucken, ob bei einem Auto die Türen offen sind...
Auf jeden Fall wollte ich nichts böses

Zitat: 100MBit ist Standard. Jeder Server oder vServer den ich bis jetzt hatte, hatte diese Anbindung. Next Level ist für mich GBit Macht schon auf Arbeit Fun

Angeber

Zitat: Selbst wenn man den FTP knacken würde, man wäre in einer chroot gefangen.

Respekt
Befindet sich das Forum auch in dem Ordner?

Zitat: Ein Portscan blockiert schon die Funktionalität des Servers, eben weil auch noch ein TCP Handshake probiert wird.

Jetzt fängt das an, ich bin froh gewesen, dass ich den Kurs mit 80 Prozent bestanden habe - der Handshake sind ja nur 3 Pakete (hin, zurück, 'packet erhalten' hin) die einen Server bei 65535 Ports über 10 Minuten wohl kaum auslassen werden

[Saij]

Wenn Fox die Konfiguration richtig gemacht hat befinden sich die Dateien in einem von der chroot Umgebung erreichbaren Pfad - sonst wäre es ja blöd

[Tion]

(20.02.2013)Saij schrieb:  Wenn Fox die Konfiguration richtig gemacht hat befinden sich die Dateien in einem von der chroot Umgebung erreichbaren Pfad - sonst wäre es ja blöd

Ohne die Diskussion noch länger zu führen (müde und kann nicht diskutieren) kann man das Forum also sabotieren, sollte man mit einer MiM-Attacke auf den Server kommen oder per Brute-Forest an das Passwort kommen?
Ich sollte wegen meiner Paranoia echt mal zum Arzt gehen

[Saij]

Bringt dir nur herzlich wenig wenn innerhalb von 10 Minuten entsprechende Backups eingespielt werden können
Du könntest btw eben so per MiM Attacke spiegel.de oder so attackieren. Selbst mit SFTP wäre es nicht sicher (hab das Root Passwort von meinem damaligen Berufsschulserver dank MiM geknackt, weil ich einfach auch das Handshaking mitgesnifft habe)

[Tion]

(20.02.2013)Saij schrieb:  Du könntest btw eben so per MiM Attacke spiegel.de oder so attackieren. Selbst mit SFTP wäre es nicht sicher (hab das Root Passwort von meinem damaligen Berufsschulserver dank MiM geknackt, weil ich einfach auch das Handshaking mitgesnifft habe)

Dann hattest du aber den private Key des Servers oder um die 8 Monate einen Super Computer, oder?
SSH läuft über PublicKey-Verfahren, und da bringt dir der Handshake wenig... Außer, du möchtest wild Pakete in die Verbindung injekten
Zumal mir gerade auffällt, dass die gängigen Clients doch den Public Key des Servers speichern und bei Änderung Alarm schlagen...

Oder meinst du Telnet? Das ist dann aber kein SFTP :confusing:

[Saij]

Nein nein.
Meinte schon SSH
Weiss leider nicht mehr ganz genau wie ich es gemacht habe (war nur ein gelangweilter Versuch während dem Unterricht), auf alle Fälle hab ich mit dem Schulcomputer und einem MiM Programm soweit alles mitgensifft, dass das Programm den Stream dekodieren konnte.

[Tion]

Weißt du welches Programm?
Weil SSH nutzt das Public-Key-Verfahren, und das geht nicht zu knacken, wenn man den Privat-Key nicht hat, und den gibt man normalerweise nicht raus...
Client und Server tauschen nur den Public-Key aus, damit der andere nur verschlüsseln kann - genau so funktionieren auch Signaturen, die man ja auch nicht fälschen kann, wenn man nicht den privaten Key hat

[Saij]

Das Programm nennt sich Cain (http://www.oxid.it/cain.html)
Daneben stimmt es nicht so ganz. Was du beschreibst ist die Authentifizierung über das Key Verfahren. Da werden die entsprechenden Public Keys so ausgetauscht, dass damit eine Authentifizierung möglich ist. Aber bei einer normalen Passwort Auth kann man schon anhand der gesniften Daten es entsprechend entschlüssel (Logik: alles was der Client verschlüsselt muss der Server wieder entschlüsseln können. Womit eine reversible Verschlüsselung genutzt werden muss.)

[Tion]

Verstehe gerade deinen Ansatz nicht

Ich gehe von normalen Passwort aus, nur nutzt SSH meines letzten Wissenstandes nach durchgehend das Public-Key-Verfahren, da es asymmetrisch ist und deswegen nur vom Server und dem Clienten verschlüsselt und entschlüsselt werden kann.

Server verschlüsselt Stream mit Public Key des Clients. Client kann mit seinem Private Key entschlüsseln.
Client verschlüsselt Stream mit Public Key des Servers. Server kann mit seinem Private Key entschlüsseln.

Um da zu sniffen braucht man die Private Keys des Servers und des Clients, nur geben die beiden den nicht her.

Das man mit dem Public Key authentifizieren kann ist dabei ein angenehmer Nebeneffekt, aber nicht das primäre Ziel.

Oder hat er auf ein symmetrisches Verfahren wie AES gewechselt? Ich finde, wer das tut, kann auch Telnet nutzen ^. ^

[Saij]

Beispiel von dir:
Server verschlüsselt Stream mit Private-Key ABC. Wie soll der Client, der nur den Public Key DEF vom Server kennt, diesen wieder entschlüsseln?
Es MUSS vorher eine Key übertragen werden, der diese Entschlüsselung möglich macht. Und den kann man auch mitsniffen.

[Tion]

Der Client hat Public Key pub1 und Private Key pri1
Der Server hat Public Key pub2 und Private Key pri2

Client sendet pub1
Server sendet pub2

Server sendet mit pub1 an Client, Client entschlüsselt mit pri1
Client sendet mit pub2 an Server, Server entschlüsselt mit priv2

So werden Sockets mit DES normalerweise implementiert

[Saij]

Jo. Und damit wird ein Key gesendet.
Was macht ein MiM Angreifer? Er hängt sich dazwischen und manipuliert den Traffic.

Client hat Pub1 und Pri1
Server hat Pub2 und Pri2
Angreifer hat Pub3 und Pri3

Client sendet Pub1 - aber an den Angreifer
Der Angreifer sendet Pub3 an den Server

Das Spiel natürlich dann noch umgedreht.

Und schon hat sich der Angreifer als eine Art Proxy etabliert und kann den Traffic schön mitsniffen.

[Tion]

Client merkt, dass der Server plötzlich einen anderen Public Key hat und es kommt der typische 'Der Verbindung wird nicht vertraut'-Dialog
Und der, der die MiM-Attacke ausführt, kann auch nicht einfach den Public Key des Servers nehmen, da er dann nichts mit dem Traffic anfangen kann

Bei SSH kann man eigentlich nur die Session übernehmen, indem man den Clienten übernimmt, und dann kann man au einfach einen Keylogger installieren

Wie kamen wir auf das Thema?

[Saij]

Du meintest SFTP sei sicherer.

[Tion]

Ach ja, genau, weil man es nicht sniffen kann und es von Vorteil ist, einen Server so minimal wie möglich zu halten

Btt, ich finde den neuen Server cool, auch wenn ich sie nicht lange miterleben durfte, haben die Serverfehler genervt

[MikuHatsune]

Ihr seid Nerds.. Ich verstehe bei der gesamten letzten Seite nur Bahnhof. O.o;

[Saij]

Ne wir sind nur Fachkräfte

[Tion]

(22.02.2013)MikuHatsune schrieb:  Ihr seid Nerds.. Ich verstehe bei der gesamten letzten Seite nur Bahnhof. O.o;

Und wir haben nur das oberflächliche besprochen - wir hätten noch darauf eingehen können, wie der TCP-Handshake genau funktioniert ( war es das AC-Flag, das zuerst gesetzt wird? Muss ich noch mal nachgucken ), und was DES mit Primzahlen zu tun haben

[Andorius]

In anderen Worten: Komplett ins Off-Topic abschlittern