Hallole, gegeben sei der Fall (hach, klingt das schön), dass auf dem Rechner 10.20.30.41 'ssh' läuft. Ein Angreifer würde aber normalerweise einen Rechner nach dem anderen durchprobieren. Vorher also 10.20.30.40 oder 10.20.30.42 auf 'ssh' testen. Man ahnt es schon, ich würde gerne diesen "Angriff" erkennen und noch schnell 'ssh' auf 10.20.30.41 für die entsprechende Quelle verbieten. Wobei nach einer gewissen Zeit die Quelle wieder erlaubt werden sollte. 'snort' und ähnliche Tools erkennen zwar Angriffe, aber außer mitschreiben oder Meldung verschicken haben die (anscheinend) keine anderen Möglichkeiten. Gesehen habe ich mal ein Script, das /var/log/secure belauscht und dann entsprechend handelt. Das wirkt aber nicht sehr ästhetisch auf mich. Gibt es da mittlerweise vielleicht was besseres. Vielleicht als neues "Target" für 'netfilter/iptables' oder so. Adele -- Andreas Burkhardt Linux +49 172 3026633 Training Cauerstraße 32 Consulting D-10587 Berlin http://burkhardt.IT Administration
Am Donnerstag, den 25.11.2004, 15:50 +0100 schrieb Andreas Burkhardt:
Hallole,
gegeben sei der Fall (hach, klingt das schön), dass auf dem Rechner 10.20.30.41 'ssh' läuft. Ein Angreifer würde aber normalerweise einen Rechner nach dem anderen durchprobieren. Vorher also 10.20.30.40 oder 10.20.30.42 auf 'ssh' testen.
Man ahnt es schon, ich würde gerne diesen "Angriff" erkennen und noch schnell 'ssh' auf 10.20.30.41 für die entsprechende Quelle verbieten. Wobei nach einer gewissen Zeit die Quelle wieder erlaubt werden sollte.
'snort' und ähnliche Tools erkennen zwar Angriffe, aber außer mitschreiben oder Meldung verschicken haben die (anscheinend) keine anderen Möglichkeiten.
Gesehen habe ich mal ein Script, das /var/log/secure belauscht und dann entsprechend handelt. Das wirkt aber nicht sehr ästhetisch auf mich.
Hi Andreas, ich würde für diesen Fall, denke ich, den guten alten Logsurfer bemühen um dynamisch auf solche Dinge reagieren zu können. Wird nur eine kleine Bastelaufgabe die Regeln wieder zu entfernen, aber das sollte auch kein Problem darstellen. Gruß Daniel P.S.: Sicherheit hat nichts mit Ästhetik zu tun ;-) -- Daniel Hanke Linux/Unix Systemadministrator, RHCE windream GmbH - Wasserstrasse 219 - 44799 Bochum Telefon +49 234 9734 0 - Telefax +49 234 9734 520 http://www.windream.com
Daniel Hanke wrote:
Hi Andreas,
ich würde für diesen Fall, denke ich, den guten alten Logsurfer bemühen um dynamisch auf solche Dinge reagieren zu können. Wird nur eine kleine Bastelaufgabe die Regeln wieder zu entfernen, aber das sollte auch kein Problem darstellen.
Hmm, das sieht sehr ansprechend aus. Und es ist in C. Sollte also schnell genug sein. Jep, entfernen sollte ich die Sperren gelegentlich wieder.
Gruß Daniel
P.S.: Sicherheit hat nichts mit Ästhetik zu tun ;-)
Oh, doch. Lösungen wie /etc/cron.daily/ empfinde ich einfach als schön. Somit ist das die _richtige_ Lösung, besser als alles in /etc/crontab einzutragen. -- Andreas Burkhardt Linux +49 172 3026633 Training Cauerstraße 32 Consulting D-10587 Berlin http://burkhardt.IT Administration
On Thursday 25 November 2004 15:50, Andreas Burkhardt wrote:
gegeben sei der Fall (hach, klingt das schön), dass auf dem Rechner 10.20.30.41 'ssh' läuft. Ein Angreifer würde aber normalerweise einen Rechner nach dem anderen durchprobieren. Vorher also 10.20.30.40 oder 10.20.30.42 auf 'ssh' testen.
warum glaubst du dass die Reihenfolge sortiert ist? Portscans laufen auch unsortiert.
Man ahnt es schon, ich würde gerne diesen "Angriff" erkennen und noch schnell 'ssh' auf 10.20.30.41 für die entsprechende Quelle verbieten. Wobei nach einer gewissen Zeit die Quelle wieder erlaubt werden sollte.
ich halte das nicht für sinnvoll.
Gibt es da mittlerweise vielleicht was besseres. Vielleicht als neues "Target" für 'netfilter/iptables' oder so.
wie soll das gehen? Wenn SSH auf Rechner A angesprochen wird, schliesst sich der SSH Port auf Rechner B? Da kann man ja mit einfachem IP spoofing den Admin von seinen eigenen Rechnern abklemmen. -- ciao, Uwe Gansert Uwe Gansert, Server Technologies Team SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nürnberg, Germany e-mail: uwe.gansert@suse.de, Tel: +49-(0)911-74053-0, Fax: +49-(0)911-74053-476, Web: http://www.suse.de
ist es da nicht sinnvoller die ip zu sperren, wenn es 2 oder 3 mal ein
fehlgeschlagenes login am betreffenden rechner gab?! einmal falsch
einloggen darf sich jeder mal, passiert mir auch mal. Und mit 2 versuchen
ist es glaub ich nicht so schnell möglich ein passwort zu erraten und ssh2
abhören...?!
Mit freundlichen Grüßen
A.Gegner
Uwe Gansert
gegeben sei der Fall (hach, klingt das schön), dass auf dem Rechner 10.20.30.41 'ssh' läuft. Ein Angreifer würde aber normalerweise einen Rechner nach dem anderen durchprobieren. Vorher also 10.20.30.40 oder 10.20.30.42 auf 'ssh' testen.
warum glaubst du dass die Reihenfolge sortiert ist? Portscans laufen auch unsortiert.
Man ahnt es schon, ich würde gerne diesen "Angriff" erkennen und noch schnell 'ssh' auf 10.20.30.41 für die entsprechende Quelle verbieten. Wobei nach einer gewissen Zeit die Quelle wieder erlaubt werden sollte.
ich halte das nicht für sinnvoll.
Gibt es da mittlerweise vielleicht was besseres. Vielleicht als neues "Target" für 'netfilter/iptables' oder so.
wie soll das gehen? Wenn SSH auf Rechner A angesprochen wird, schliesst sich der SSH Port auf Rechner B? Da kann man ja mit einfachem IP spoofing den Admin von seinen eigenen Rechnern abklemmen. -- ciao, Uwe Gansert Uwe Gansert, Server Technologies Team SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nürnberg, Germany e-mail: uwe.gansert@suse.de, Tel: +49-(0)911-74053-0, Fax: +49-(0)911-74053-476, Web: http://www.suse.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
age@ifak-system.com wrote:
ist es da nicht sinnvoller die ip zu sperren, wenn es 2 oder 3 mal ein fehlgeschlagenes login am betreffenden rechner gab?! einmal falsch einloggen darf sich jeder mal, passiert mir auch mal. Und mit 2 versuchen ist es glaub ich nicht so schnell möglich ein passwort zu erraten und ssh2 abhören...?!
1. Wie mache ich das? Die IP sperren. 2. Wir haben öffentliche Adressen. Auf der Netzwerkadresse laufen natürlich keine Server. Auf den Broadcast auch nicht. Wenn ich also auf den Router Verbindungswünsche auf diese beiden Adressen sehe, dann ist das ein Angreifer. Und ich sehe z.Z. viele Wünsche. Auf unterschiedliche Ports.
Mit freundlichen Grüßen
A.Gegner
-- Andreas Burkhardt Linux +49 172 3026633 Training Cauerstraße 32 Consulting D-10587 Berlin http://burkhardt.IT Administration
Am Donnerstag, den 25.11.2004, 16:14 +0100 schrieb Uwe Gansert:
wie soll das gehen? Wenn SSH auf Rechner A angesprochen wird, schliesst sich der SSH Port auf Rechner B? Da kann man ja mit einfachem IP spoofing den Admin von seinen eigenen Rechnern abklemmen.
-- ciao, Uwe Gansert
Firewall mit Servern in der DMZ an welche die Anfragen weitergeleitet werden? Also nicht Rechner B sperrt sondern die Firewall die davor ist. Zusätzlich noch Portknocking einbauen um dem Admin immer Zugriff zu gewähren :-) Gruß Daniel -- Daniel Hanke Linux/Unix Systemadministrator, RHCE windream GmbH - Wasserstrasse 219 - 44799 Bochum Telefon +49 234 9734 0 - Telefax +49 234 9734 520 http://www.windream.com
On Thursday 25 November 2004 16:35, Daniel Hanke wrote:
Firewall mit Servern in der DMZ an welche die Anfragen weitergeleitet werden? Also nicht Rechner B sperrt sondern die Firewall die davor ist. Zusätzlich noch Portknocking einbauen um dem Admin immer Zugriff zu gewähren :-)
security by obscurity -- ciao, Uwe Gansert Uwe Gansert, Server Technologies Team SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nürnberg, Germany e-mail: uwe.gansert@suse.de, Tel: +49-(0)911-74053-0, Fax: +49-(0)911-74053-476, Web: http://www.suse.de
Am Donnerstag, den 25.11.2004, 16:38 +0100 schrieb Uwe Gansert:
On Thursday 25 November 2004 16:35, Daniel Hanke wrote:
Firewall mit Servern in der DMZ an welche die Anfragen weitergeleitet werden? Also nicht Rechner B sperrt sondern die Firewall die davor ist. Zusätzlich noch Portknocking einbauen um dem Admin immer Zugriff zu gewähren :-)
security by obscurity
Wo denn bitte? Kann da jetzt nicht ganz folgen. Mit leeren Phrasen um sich werfen kann jeder. -- Daniel Hanke Linux/Unix Systemadministrator, RHCE windream GmbH - Wasserstrasse 219 - 44799 Bochum Telefon +49 234 9734 0 - Telefax +49 234 9734 520 http://www.windream.com
On Thursday 25 November 2004 16:48, Daniel Hanke wrote:
Am Donnerstag, den 25.11.2004, 16:38 +0100 schrieb Uwe Gansert:
On Thursday 25 November 2004 16:35, Daniel Hanke wrote:
Firewall mit Servern in der DMZ an welche die Anfragen weitergeleitet werden? Also nicht Rechner B sperrt sondern die Firewall die davor ist. Zusätzlich noch Portknocking einbauen um dem Admin immer Zugriff zu gewähren :-)
security by obscurity
Wo denn bitte? Kann da jetzt nicht ganz folgen.
also bitte. Du willst einen Mechanismus der sich darauf verlässt, dass ein anderer Rechner vorher kontaktet/gescannt wurde, um dann einen weiteren Rechner zu schützen mit Hilfe von Informationen die vom Angreifer stammen. Dieser Schutz kann aber per Port knocking ausgehebelt werden, damit nicht jeder einfach den Admin aussperren kann, was dieses Konzept leider mit sich bringt. Das findest du nicht etwas seltsam? Warum lässt du nicht zusätzlich den ssh daemon noch je nach Mondstand auf einem anderen Port lauschen? Dann ist es noch sicherer.
Mit leeren Phrasen um sich werfen kann jeder.
und sich verrückte Konzepte ausdenken offenbar auch. Naja, vielleicht habe ich dich auch falsch verstanden. -- ciao, Uwe Gansert Uwe Gansert, Server Technologies Team SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nürnberg, Germany e-mail: uwe.gansert@suse.de, Tel: +49-(0)911-74053-0, Fax: +49-(0)911-74053-476, Web: http://www.suse.de
Am Donnerstag, den 25.11.2004, 17:12 +0100 schrieb Uwe Gansert:
On Thursday 25 November 2004 16:48, Daniel Hanke wrote:
Am Donnerstag, den 25.11.2004, 16:38 +0100 schrieb Uwe Gansert:
On Thursday 25 November 2004 16:35, Daniel Hanke wrote:
Firewall mit Servern in der DMZ an welche die Anfragen weitergeleitet werden? Also nicht Rechner B sperrt sondern die Firewall die davor ist. Zusätzlich noch Portknocking einbauen um dem Admin immer Zugriff zu gewähren :-)
security by obscurity
Wo denn bitte? Kann da jetzt nicht ganz folgen.
also bitte. Du willst einen Mechanismus der sich darauf verlässt, dass ein anderer Rechner vorher kontaktet/gescannt wurde, um dann einen weiteren Rechner zu schützen mit Hilfe von Informationen die vom Angreifer stammen. Dieser Schutz kann aber per Port knocking ausgehebelt werden, damit nicht jeder einfach den Admin aussperren kann, was dieses Konzept leider mit sich bringt. Das findest du nicht etwas seltsam? Warum lässt du nicht zusätzlich den ssh daemon noch je nach Mondstand auf einem anderen Port lauschen? Dann ist es noch sicherer.
Nein. Nicht wirklich. Der Admin brauch seinen Zugriff. Also macht man diesen Zugang so sicher wie möglich. Dann bau dir doch für den Portknocker Einmal-"Schlüssel". Mit dem Stand des Mondes ist gar nicht so schlecht... Sogesehen wäre ja jedes Passwort "Security by obsurity". Das vergibst du ja auch um den Zugriff zu verhindern. Das lässt sich aber auch mit dem richtigen Passwort aushebeln ;-) Ich würd sagen alle Netzwerkverbindungen raus. Eingabegeräte weg, CD, Diskette etc ausbauen und die Anschlüsse auf dem Board unbrauchbar machen. Dann den Rechner zur Bank in den Tresorraum. Dann ist er sicher. Fast... Nur zu gebrauchen auch nicht. Gruß Daniel -- Daniel Hanke Linux/Unix Systemadministrator, RHCE windream GmbH - Wasserstrasse 219 - 44799 Bochum Telefon +49 234 9734 0 - Telefax +49 234 9734 520 http://www.windream.com
On Thursday 25 November 2004 17:25, Daniel Hanke wrote: also von mir aus kannst du dir das gerne so einrichten. Denk aber dran, sobald der Angreifer die IP des ssh Rechners kennt, ist der Schutz wertlos. Weiterhin, sollte der Angreifer deinen Mechanismus kennen, kann er deine Firewall mit wenig Aufwand mit Regeln fluten. Dein Schutz verlässt sich einzig und allein darauf das ihn niemand kennt und sobald man ihn kennt ist er wertlos und sogar eine Gefahr und darum finde ich es nicht sehr sinnvoll. Du kannst aber natürlich bei dir aufsetzen was du magst aber zu deinem eigenen Schutz würde ich dann niemandem davon erzählen. :) -- ciao, Uwe Gansert Uwe Gansert, Server Technologies Team SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nürnberg, Germany e-mail: uwe.gansert@suse.de, Tel: +49-(0)911-74053-0, Fax: +49-(0)911-74053-476, Web: http://www.suse.de
Daniel Hanke wrote:
Zusätzlich noch Portknocking einbauen um dem Admin immer Zugriff zu gewähren :-)
security by obscurity
Wo denn bitte? Kann da jetzt nicht ganz folgen.
also bitte. Du willst einen Mechanismus der sich darauf verlässt, dass ein anderer Rechner vorher kontaktet/gescannt wurde, um dann einen weiteren Rechner zu schützen mit Hilfe von Informationen die vom Angreifer stammen. Dieser Schutz kann aber per Port knocking ausgehebelt werden, damit nicht jeder einfach den Admin aussperren kann, was dieses Konzept leider mit sich bringt. Das findest du nicht etwas seltsam?
Nein. Nicht wirklich. Der Admin brauch seinen Zugriff. Also macht man diesen Zugang so sicher wie möglich. Nein, der Zuganng hat sicher zu sein oder darf nicht existieren. Wenn Dein SSH verwundbar ist und (noch) nicht gepatcht werden kann, sollte es abgeschaltet werden.
Ansonsten lebst du von der Hoffnung - von der Hoffnung, daß der Gegner nicht so schlau ist wie Du. Dann bau dir doch für den
Portknocker Einmal-"Schlüssel". Mit dem Stand des Mondes ist gar nicht so schlecht... Sogesehen wäre ja jedes Passwort "Security by obsurity".
Die Grenzen sind sicherlich fließend, jedoch kann ein Paßwort so gewählt werden, daß es in vernünftiger Zeit (was vernünftig ist, entscheidet dein Sicherheitsbedürfnis) nicht mehr knackbar ist. Gruß Thomas -- Jetzt aber schnell (nur für Bayern): www.volksbegehren-wald.de
Thomas Stark wrote:
Daniel Hanke wrote:
Zusätzlich noch Portknocking einbauen um dem Admin immer Zugriff zu gewähren :-)
security by obscurity
Wo denn bitte? Kann da jetzt nicht ganz folgen.
also bitte. Du willst einen Mechanismus der sich darauf verlässt, dass ein anderer Rechner vorher kontaktet/gescannt wurde, um dann einen weiteren Rechner zu schützen mit Hilfe von Informationen die vom Angreifer stammen. Dieser Schutz kann aber per Port knocking ausgehebelt werden, damit nicht jeder einfach den Admin aussperren kann, was dieses Konzept leider mit sich bringt. Das findest du nicht etwas seltsam?
Nein. Nicht wirklich. Der Admin brauch seinen Zugriff. Also macht man diesen Zugang so sicher wie möglich.
Nein, der Zuganng hat sicher zu sein oder darf nicht existieren. Wenn Dein SSH verwundbar ist und (noch) nicht gepatcht werden kann, sollte es abgeschaltet werden.
Man kann ein SSH nicht abschalten, wenn man im Urlaub ist. Und ich würde fast wetten, daß im SSH noch Fehler sind. Also abschalten!?!? Hmmm, manchmal braucht man aber diese Möglichkeit zum Administration aus der Ferne
Ansonsten lebst du von der Hoffnung - von der Hoffnung, daß der Gegner nicht so schlau ist wie Du.
Davon leben wir, solange wir Rechner ans Netz anschließen.
Dann bau dir doch für den
Portknocker Einmal-"Schlüssel". Mit dem Stand des Mondes ist gar nicht so schlecht... Sogesehen wäre ja jedes Passwort "Security by obsurity".
Noe, nicht ganz. Obscure wäre ein SSH auf dem Port 2222. Etwas mehr Sicherheit, aber nicht wirklich unauffindbar. Meine Idee dabei war, das kaum jemand sich den Port 2222 als erstes anschaut. Und wenn er dort nachschaut, hat er bereits verloren. Außer jemand schaut sich pro Tag nur einen Port an. Aber das wäre jemand, der unbedingt in _Deine_ Maschine will. Die meisten Angreifer suchen aber nur irgendeine Maschine für ihren Spam oder Viren oder Filme.
Die Grenzen sind sicherlich fließend, jedoch kann ein Paßwort so gewählt werden, daß es in vernünftiger Zeit (was vernünftig ist, entscheidet dein Sicherheitsbedürfnis) nicht mehr knackbar ist.
Gruß Thomas
-- Andreas Burkhardt Linux +49 172 3026633 Training Cauerstraße 32 Consulting D-10587 Berlin http://burkhardt.IT Administration
Hallo Liste,
also ich denke mal (ohne spinnen zu wollen) eine guter server mit
fernzugriff sieht etwa so aus:
es läuft ssh2 mit einer guten zertifikatsverschlüsselung, eine IDS bzw ein
programm welches portscans erkennt und danach dynamisch z.B. IPs oder gar
ssh2 zeitweise ganz sperrt und portknocking. Ich denke mal das so eine
rechner gut absichert ist und man trotzdem noch als berechtigter admin
drauf zugreifen kann. Ach ja die Firewall hab ich ja ganz vergessen, aber
die brauch ich wohl nicht extra zu erwähnen. Ich kann mir nicht vostellen
das sowas in einem sinnvollen zeitrahmen knackbar ist. Jetzt werden wieder
einige sagen: ja ssh2 und netzwerkverkehr abhören usw....dazu sag ich nur,
ja alles ist knackbar, auch wenn ich das bei ssh2 erstmal sehen möchte,
aber wie sagte ein befreundeter admin heute zu mir: die größten gefahren
kommen nicht aus dem internet, die kommen meistens aus dem eigenen
netzwerk. Wie gesagt meistens.....
Ach ja. noch eine idee, root an ssh am besten gar nicht zulassen (den nimmt
eh jeder zweite angreifer) und einen tunnel über einen extra angelegten
user aufbauen und dann den server über z.B. webmin fernwarten. Und da die
verbindung zum webmin eh ssh2 verschlüsselt ist und dann vielleicht auch
noch über https läuft ....................(ist das eigentlich schon mit
kanonen auf spatzen schiessen? :-))
Mit freundlichen Grüßen
A.Gegner
Andreas
Burkhardt To: suse-linux@suse.com
Daniel Hanke wrote:
Zusätzlich noch Portknocking einbauen um dem Admin immer Zugriff zu gewähren :-)
security by obscurity
Wo denn bitte? Kann da jetzt nicht ganz folgen.
also bitte. Du willst einen Mechanismus der sich darauf verlässt, dass ein anderer Rechner vorher kontaktet/gescannt wurde, um dann einen weiteren Rechner zu schützen mit Hilfe von Informationen die vom Angreifer stammen. Dieser Schutz kann aber per Port knocking ausgehebelt werden, damit nicht jeder einfach den Admin aussperren kann, was dieses Konzept leider mit sich bringt. Das findest du nicht etwas seltsam?
Nein. Nicht wirklich. Der Admin brauch seinen Zugriff. Also macht man diesen Zugang so sicher wie möglich.
Nein, der Zuganng hat sicher zu sein oder darf nicht existieren. Wenn Dein SSH verwundbar ist und (noch) nicht gepatcht werden kann, sollte es abgeschaltet werden.
Man kann ein SSH nicht abschalten, wenn man im Urlaub ist. Und ich würde fast wetten, daß im SSH noch Fehler sind. Also abschalten!?!? Hmmm, manchmal braucht man aber diese Möglichkeit zum Administration aus der Ferne
Ansonsten lebst du von der Hoffnung - von der Hoffnung, daß der Gegner nicht so schlau ist wie Du.
Davon leben wir, solange wir Rechner ans Netz anschließen.
Dann bau dir doch für den
Portknocker Einmal-"Schlüssel". Mit dem Stand des Mondes ist gar nicht so schlecht... Sogesehen wäre ja jedes Passwort "Security by obsurity".
Noe, nicht ganz. Obscure wäre ein SSH auf dem Port 2222. Etwas mehr Sicherheit, aber nicht wirklich unauffindbar. Meine Idee dabei war, das kaum jemand sich den Port 2222 als erstes anschaut. Und wenn er dort nachschaut, hat er bereits verloren. Außer jemand schaut sich pro Tag nur einen Port an. Aber das wäre jemand, der unbedingt in _Deine_ Maschine will. Die meisten Angreifer suchen aber nur irgendeine Maschine für ihren Spam oder Viren oder Filme.
Die Grenzen sind sicherlich fließend, jedoch kann ein Paßwort so gewählt werden, daß es in vernünftiger Zeit (was vernünftig ist, entscheidet dein Sicherheitsbedürfnis) nicht mehr knackbar ist.
Gruß Thomas
-- Andreas Burkhardt Linux +49 172 3026633 Training Cauerstraße 32 Consulting D-10587 Berlin http://burkhardt.IT Administration -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
participants (5)
-
age＠ifak-system.com -
Andreas Burkhardt -
Daniel Hanke -
Thomas Stark -
Uwe Gansert