...soll Systrace nicht zu umgehen sein... Naja, wer sowas behauptet ist arrogant oder extrem von sich eingenommen, was eigentlich keinen Unterschied ausmacht. Oder aber, er/sie/es kommt aus der Zukunft und weiß, das in 20 Jahren noch keine Lücken gefunden wurden.
Im Linux-Magazin 06/06 sind einige gute Artikel drin, die beschreiben, welches System welche Zielsetzung und damit verbundene Komplexitaet hat. SELinux wird im Gegensatz zu AppArmor hier mangelnde Usability und hoehere Komplexitaet nachgesagt. Als Fazit heisst es, SELinux wuerde die bisher konsquenteste Umsetzung von Zugriffsschutz per MAC implementieren und eher fuer Enterprise-Systeme ausgelegt sein, waehrend AppArmor versucht auch den normalen Anwender anzusprechen.
Von Stefan Schumacher am Di, 29. Mai 2007 um 09:13 #
Niels Provos hat in seinem Artikel (steht in der Bibliographie) eine Benchmark gemacht. Die Geschwindigkeitsverluste hängen zum einen natürlich vom Profil der Anwendung ab - je mehr Syscalls es gibt, desto stärker sind die einbußen. Systrace auf einem Systrace-überwachten System zu kompilieren verliert mehr an Geschwindigkeit als den Systrace-Tarball zu entpacken.
Ansonsten hängt der Verlust auch von den Regeln ab. Insbesondere Reguläre Ausdrücke sind extrem aufwändig aufzulösen und daher nach Möglichkeit zu vermeiden.
Auf unserem Datenbank- und Web-Server (PostgreSQL, Perl, Apache) läuft Systrace und für die Clients gibt es kaum wahrnehmbare Einbußen. Es hängt natürlich immer vom Einsatz- und Benutzerprofil ab.
Moin, ich suche seit langem eine Möglichkeit Angriffe auf einen SSH-Server zu entdecken, der nur eine Authentifizierung über einen DSA-Key erlaubt. Weiss jemand ob das damit geht?
Da findest du recht schnell, wie man den Loglevel erhöht und somit Angriffe leichter erkennbar sind. Mit Hilfe eines Bash-Skripts kannst du die Angriffe dann auch automatisch erkennen und dich verständigen lassen -> z.B.: über Mail.
Hätte ich dazu schreiben sollen, dass ich mit Googlen noch nicht weitergekommen bin. Zumindest bei dem Thema habe ich Tomaten auf den Augen. Ich habe bislang nur Meldung gesehen, wenn ich Passwort Authentifizierung zulasse.
Von Stefan Schumacher am Di, 29. Mai 2007 um 14:37 #
grep publickey /var/log/authlog May 29 14:35:20 ifph-rdws2 sshd[2606]: Accepted publickey for XXX from YYY port 62912 ssh2 May 29 14:35:20 ifph-rdws2 sshd[2687]: Accepted publickey for XXX from YYY port 62911 ssh2 May 29 14:35:44 ifph-rdws2 sshd[1506]: Accepted publickey for XXX from YYY port 62910 ssh2 May 29 14:35:44 ifph-rdws2 sshd[2639]: Accepted publickey for XXX from YYY port 62909 ssh2
Genau genommen nur das "Denied", da ich ja nicht sehen will, wer sich angemeldet hat, sondern bei wem es gescheitert ist. Ich bin mir allerdings gerade unsicher ob ich wenigstens die Accepted gesehen habe oder nicht. Falls nicht, ist irgendwas beim Log falsch....
Von Stefan Schumacher am Mi, 30. Mai 2007 um 15:55 #
Normalerweise zeigt SSH alle Logins und Loginversuche an. Wenn serverseitig nichts weiter geändert wird, springt er ja nach erfolglosem Login mittels Schlüssel weiter zum Login mittels Passwort. Also sollte man da auch drauf achten, oder Passwort-Authentifizierung gleich abschalten
Naja, wer sowas behauptet ist arrogant oder extrem von sich eingenommen, was eigentlich keinen Unterschied ausmacht. Oder aber, er/sie/es kommt aus der Zukunft und weiß, das in 20 Jahren noch keine Lücken gefunden wurden.
Ansonsten hängt der Verlust auch von den Regeln ab. Insbesondere Reguläre Ausdrücke sind extrem aufwändig aufzulösen und daher nach Möglichkeit zu vermeiden.
Auf unserem Datenbank- und Web-Server (PostgreSQL, Perl, Apache) läuft Systrace und für die Clients gibt es kaum wahrnehmbare Einbußen.
Es hängt natürlich immer vom Einsatz- und Benutzerprofil ab.
ich suche seit langem eine Möglichkeit Angriffe auf einen SSH-Server zu entdecken, der nur eine Authentifizierung über einen DSA-Key erlaubt.
Weiss jemand ob das damit geht?
Danke
Niels
Da findest du recht schnell, wie man den Loglevel erhöht und somit Angriffe leichter erkennbar sind. Mit Hilfe eines Bash-Skripts kannst du die Angriffe dann auch automatisch erkennen und dich verständigen lassen -> z.B.: über Mail.
May 29 14:35:20 ifph-rdws2 sshd[2606]: Accepted publickey for XXX from YYY port 62912 ssh2
May 29 14:35:20 ifph-rdws2 sshd[2687]: Accepted publickey for XXX from YYY port 62911 ssh2
May 29 14:35:44 ifph-rdws2 sshd[1506]: Accepted publickey for XXX from YYY port 62910 ssh2
May 29 14:35:44 ifph-rdws2 sshd[2639]: Accepted publickey for XXX from YYY port 62909 ssh2
Was fehlt daran?