populaere irrtuemer: security by obscurity

[buddaaa]

ausserdem wird hier generel von port-verlegung abgeraten, nicht nur bei SSH. ist z.b. bei POP3, IMAP und openvpn auch kein problem.

Ich glaube nicht, daß ich bereit wäre, 300 Installationen von Outlook, AppleMail, Mozilla und Netscape zu überwachen und den knapp 600 Mailboxen (=Usern) zu sagen, welcher Port gerade mal der aktuelle ist.

und? ich hab allen von anfang an den port gesagt und keine probleme damit.

Laß uns diese Diskussion bitte beenden - Du drehst Dich inhaltslos im Kreis und mir fallen vom Kopfschütteln schon die Haare aus.

moment mal, Du beantwortest von meinen 4 absaetzen nur einen einzigen, den rest laesst Du unbeantwortet weil Du keine argumente mehr hast und "ich drehe mich inhaltslos im kreis" ???

komm, sei mal ehrlich zu Dir selber ;)

[outofbound]

Hi,

ums kurz zu machen:

Auf meinen beiden Honigtöpfen sind in den letzten Wochen etwa 1200 unique Angriffsversuche auf den SSH- Port eingegangen. Von diesen waren etwa 20 kritischer als Standard- Brute- Force Attacken auf den SSH- Port, bzw. 08/15 Exploits die durch Botnetze gejagt wurden, und die sowieso durch das einfach einspielen von Patches verhindert wurden.

Von diesen 20, die ich als "Attacking with Interests" bezeichnen möchte, kamen 14 auch auf dem zusätzlichen "verlegten" SSH- Port an, und zwar in etwa zeitgleich.

[edit]
10 Davon haben übrigens die Versionsangaben die geliefert wurden
schlichtweg ignoriert, und 2 sind tatsächlich auf das System gekommen, allerdings über einen anderen Weg, da fast alle Angriffe auf verschiedenste Dienste des Servers ausgelegt waren.
[/edit]

Aus Erfahrung weiss ich, dass es durchaus einfach ist sich Zugang zu einem Botnetz zu verschaffen mit dem man ganze A- Class Segments in etwa 20 bis 30 Minuten komplett durchscannen kann, um lohnende Angriffsziele zu finden. Diese sind nicht auf spezielle Ports beschränkt, sondern grasen einfach alles stupide ab.

Somit ist aus meiner Erfahrung (Und meine Produktivkisten bestätgigen das zusätzlich) der einzige Vorteil von einem verlegten SSH- Port, dass sich Angriffe die sowieso nicht erfolgreich wären nicht mehr in den Logfiles auftauchen.

Mir erscheint der Aufwand zur Pflege eines verlegten Ports (Kunde muss System neu einrichten, hat die Einstellungen gelöscht, etc) im
Gegensatz zum minimalen Sicherheitsgewinn nicht als lohnenswert.

Das Thema "falsche Sicherheit" wird dadurch auch deutlich: Unerfahrene Leute werden durch das verlegen des Ports dazu verleitet,
das einspielen von Patches zu unterlassen, eben weil ja auch in den
Logs nichts mehr auftaucht. (Seen my share of those!) Genau da liegt der Hund begraben: Für einen erfahrenen Admin ist das Problem der Sicherheit auch auf dem Standardport relativ klein, da er seine Systeme entsprechend warten wird. Ein Anfänger der dies aus mangelnder Erfahrung nicht kann, wird sich in falscher Sicherheit wiegen, ebenso wie eine Firewall vermittelt das der Server jetzt "sicher" ist.

Ich fahre seit Jahren meine Systeme nach dem Prinzip KISS (Keep it simple, stupid), und bis auf ein paar kleine Ausnahmen hat mich nichts erwischt, was nicht in kürzester Zeit wieder fixbar war.

[nochmehredit]
Ansonsten schliesse ich mich insbesondere isotopps Aussagen zu fast 100% an und bedanke mich bei ihm für die sachliche Betrachtungsweise. :) Thumbs up! :)
[/nochmehredit]
Gruss,

Out

[buddaaa]

Auf meinen beiden Honigtöpfen sind in den letzten Wochen etwa 1200 unique Angriffsversuche auf den SSH- Port eingegangen. Von diesen waren etwa 20 kritischer als Standard- Brute- Force Attacken auf den SSH- Port, bzw. 08/15 Exploits die durch Botnetze gejagt wurden, und die sowieso durch das einfach einspielen von Patches verhindert wurden.

Von diesen 20, die ich als "Attacking with Interests" bezeichnen möchte, kamen 14 auch auf dem zusätzlichen "verlegten" SSH- Port an, und zwar in etwa zeitgleich.

also das fazit fuer die portverlegung:

100% weniger bot-angriffe
30% weniger "richtige" angriffe

wobei mich noch interessieren wuerde ob dieser verlegt SSH-port einer aus der /etc/services war weil ich hatte im letzten halben jahr keinen einzigen full-port-scan?

Somit ist aus meiner Erfahrung (Und meine Produktivkisten bestätgigen das zusätzlich) der einzige Vorteil von einem verlegten SSH- Port, dass sich Angriffe die sowieso nicht erfolgreich wären nicht mehr in den Logfiles auftauchen.

also ich halte 30% unterschied zwischen standard- und verstecktem port schon fuer signifikant.

Mir erscheint der Aufwand zur Pflege eines verlegten Ports (Kunde muss System neu einrichten, hat die Einstellungen gelöscht, etc) im
Gegensatz zum minimalen Sicherheitsgewinn nicht als lohnenswert.

ich habs von anfang an gemacht und liefer den kunden sowieso eine beschreibung wo sie was eintragen muessen damit es weniger rueckfragen gibt. statt der 22 ne andere portnummer im winscp einzutragen ist kein aufwand.

Das Thema "falsche Sicherheit" wird dadurch auch deutlich: Unerfahrene Leute werden durch das verlegen des Ports dazu verleitet,
das einspielen von Patches zu unterlassen, eben weil ja auch in den
Logs nichts mehr auftaucht.

mal abgesehen davon, das die meisten heutzutage alle patches einspielen, die ihnen ihre distribution anbieten ohne vorher in logfiles zu schauen, wo ist der unterschied zwischen den folgenden beiden:

1. admin verlegt SSH-port auf 41324, fuehlt sich sicher und spielt keine patches mehr ein.

2. admin stellt von passwoertern auf SSH-keys um, fuehlt sich sicher und spielt keine patches mehr ein.

genau, da gibts keinen, ausser das 1. eine weitverbreitete theorie ist um rechtzufertigen das man in internet-foren ueber security-by-obscurity-nutzer lachen darf ;)

(Seen my share of those!) Genau da liegt der Hund begraben: Für einen erfahrenen Admin ist das Problem der Sicherheit auch auf dem Standardport relativ klein, da er seine Systeme entsprechend warten wird. Ein Anfänger der dies aus mangelnder Erfahrung nicht kann, wird sich in falscher Sicherheit wiegen, ebenso wie eine Firewall vermittelt das der Server jetzt "sicher" ist.

moment mal, willst Du jetzt erklaeren das firewalls ein system nicht tatsaechlich sicherer machen ?

und vor allem das man sie nicht benutzen sollte weil sie einen wieder in falscher sicherheit wiegen und man dann vergisst seine patches einzuspielen ?

Ich fahre seit Jahren meine Systeme nach dem Prinzip KISS (Keep it simple, stupid), und bis auf ein paar kleine Ausnahmen hat mich nichts erwischt, was nicht in kürzester Zeit wieder fixbar war.

da ist also noch genug spielraum zum optimieren, ich wuerde mal spontan mit portverlegung, versionen-verstecken und iptables anfangen :)

[outofbound]

Hi,

100% weniger bot-angriffe

Woraus liest du das? Also mein Incoming- Traffic sagt da was anderes,
nämlich das die Anzahl der Angriffe bleibt. Und das 100% aller
Botangriffe erfolglos waren, was direkt auf das einspielen von
Patches zurückzuführen ist. Also habe ich durch das Umbiegen ja
nichts gewonnen.

30% weniger "richtige" angriffe

Oder: 70% trotzdem, und die wären bei einem Ungewarteten System
durchgegangen. Beweis: Das alleinige Umbiegen hat nichts gebracht.

Und wenn ich mir diese Angriffe anschaue die durchgekommen sind,
dann muss ich meinem Gegenüber einen ordentlichen Respekt zollen.
Da waren ein paar sehr kreative Sachen dabei.

ich habs von anfang an gemacht und liefer den kunden sowieso eine
beschreibung wo sie was eintragen muessen damit es weniger
rueckfragen gibt. statt der 22 ne andere portnummer im winscp
einzutragen ist kein aufwand.

Tja, dann haben wir halt unterschiedliche Kunden und vielleicht auch
eine unterschiedlich Anzahl derer. Und vielleicht unterschiedliche
Service Agreements und Ansprüche unserer Kunden, und vielleicht
wollen meine Kunden von andererorts mit möglichst wenig Aufwand
umziehen, oder haben kein entsprechendes Wissen und wollen sich
keinen $teuren Studenten holen um ihre Bürorechner
umzukonfigurieren...

mal abgesehen davon, das die meisten heutzutage alle patches
einspielen, die ihnen ihre distribution anbieten ohne vorher in
logfiles zu schauen, wo ist der unterschied zwischen den folgenden
beiden:

Das glaubst du nicht wirklich oder? Lass dir versichert sein, dass
das bei "Root"serverbesitzern *wesentlich* weniger sind als man
vielleicht denken mag. Hier im Forum gibt es sicher einige, und
wie viele "Root"server stehen da draussen? 200.000? 300.000? eine
halbe Million?

1. admin verlegt SSH-port auf 41324, fuehlt sich sicher und spielt
keine patches mehr ein.
2. admin stellt von passwoertern auf SSH-keys um, fuehlt sich sicher
und spielt keine patches mehr ein.

genau, da gibts keinen, ausser das 1. eine weitverbreitete theorie
ist um rechtzufertigen das man in internet-foren ueber
security-by-obscurity-nutzer lachen darf ;)

Genau, und beiden sollte man den Betrieb eines Servers verbieten,
imho. Die erste setzt sich nur durch, weil sie einfacher zu erklären
ist um die prinzipielle Gefahr dahinter zu verdeutlichen.
Aber nochmal: Wir reden hier von der Grundantwort die hier den
Anfängern gegeben wird die *keine* Ahnung von solchen Systemen haben.
Und da ist Fakt: Das reine Umbiegen des Ports bringt ihnen gar
nichts. (Mal davon abgesehen das SSH nun wirklich nicht so oft
erwischt wird wie die Drölfmilliarden PHP- Applikationen). Jemand der
sich mit seinem System auskennt kann selbst entscheiden ob oder ob
nicht er seine Ports verbiegt. Aber einem Anfänger gegenüber ist
diese Aussage halt gefährlich, punktum. Du sagst ja selbst das du
dich nicht alleine auf die Sicherheit des Umbiegens verlässt, sondern
auch Systemwartung betreibst... nur das machen viele Leute nicht.
Und wenn schon der SSH- Dienst knackbar ist, dann will ich nicht
wissen wie es um die anderen Dienste auf diesen Systemen steht.

moment mal, willst Du jetzt erklaeren das firewalls ein system nicht
tatsaechlich sicherer machen ?

und vor allem das man sie nicht benutzen sollte weil sie einen wieder
in falscher sicherheit wiegen und man dann vergisst seine patches
einzuspielen ?

Gut, was bringt mir eine Firewall auf meinem Rootserver, die die
Sicherheit meines *Einzel*systems erhöht? Wir reden hier nicht
von Rechnernetzen, ja?

da ist also noch genug spielraum zum optimieren, ich wuerde mal
spontan mit portverlegung, versionen-verstecken und iptables anfangen
:)

Aehm, mal ehrlich, WOZU? Was in aller Welt will ich mit iptables,
kannst du mir das mal erklären? Logging betreiben? Oder Chinesen
aussperren? Warum sollte ich den Port verlegen? Ausser das die
Logfiles grösser werden und ich ab und zu mal eine Anzeige
durchpuste? Warum sollte ich meine Versionierungen verstecken? Wegen
den paar MB im Monat an Traffic?

Danke, da packe ich meine Probleme lieber an der Wurzel an, anstatt
die Symptome zu bekämpfen.

Ich bin schon sehr lange hier im Forum unterwegs, und grundsätzlich
wenn die Frage "Port umbiegen?" kommt, kann man davon ausgehen das
die Person erstmal ganz andere Sicherheitsaspekte lösen sollte, bevor
sie sich um sowas Gedanken machen sollte...

Gruss,

Out

[wgot]

Hallo,

moment mal, willst Du jetzt erklaeren das firewalls ein system nicht tatsaechlich sicherer machen?

das kommt darauf an, wie man den Begriff verwendet.

Firewalls im Sinne von Paketfiltern (z.B. iptables) erhöhen die Sicherheit nicht, zumindest nicht, wenn sie auf dem zu schützenden Server laufen.

grundsätzlich wenn die Frage "Port umbiegen?" kommt, kann man davon ausgehen das die Person erstmal ganz andere Sicherheitsaspekte lösen sollte, bevor sie sich um sowas Gedanken machen sollte.

Damit hast Du das zentrale Problem klar und deutlich ausgesprochen.

Leider wollen das die betroffenen Personen meist nicht hören. :roll:

Wirksame Absicherung erfordert regelmäßige Beschäftigung mit der Materie und erheblichen Zeiteinsatz, es ist nicht damit getan, irgendein Tool zu installieren und konfigurieren, und ein paar "Geheim"tipps Marke Portverlegung umzusetzen.

Wenn die Kiste sauber eingerichtet ist und regelmäßig geupdated wird kann man sich die Portverlegung usw sparen, es sei denn, man will sie vornehmen um die Logs kleiner zu halten, denn das ist der (fragwürdige) Nutzen des verlegten Ports.

Gruß, Wolfgang

[mattiass]

Wenn die Kiste sauber eingerichtet ist und regelmäßig geupdated wird kann man sich die Portverlegung usw sparen, es sei denn, man will sie vornehmen um die Logs kleiner zu halten, denn das ist der (fragwürdige) Nutzen des verlegten Ports.

Nicht nur Logs kleiner halten. Je nach allgemeiner Fitness des Servers kann eine Welle von Angriffen, die möglicherweise von einer gerooteten Kiste im gleichen Netz herrührt, teils unangenehme Lastspitzen verursachen. Einerseits ist der erste Handshake bei SSH sehr CPU-intensiv, andererseits kann eine Welle dauernder Verbindungsversuche auch I/O binden. Wobei auch dieses Argument etwas schwächer ist als vor sieben, acht, neun Jahren, wo noch viele Webserver auf ausgemusterten SS10 liefen...

Wenn ich kann (etwa zwei Drittel der Kundenjails), lege ich SSH deshalb auf 22222 -- wenn nicht lasse ich es bleiben, ein paar Prozent weniger CPU-Last und leichter lesbare Logfiles sind oft ein fairer Gegenwert...

[buddaaa]

Hi,

100% weniger bot-angriffe

Woraus liest du das? Also mein Incoming- Traffic sagt da was anderes,
nämlich das die Anzahl der Angriffe bleibt. Und das 100% aller
Botangriffe erfolglos waren, was direkt auf das einspielen von
Patches zurückzuführen ist. Also habe ich durch das Umbiegen ja
nichts gewonnen.

die zahlen waren 1200 bot-angriffe auf port 22 und 14 sinnvolle angriffe auf port XY.

30% weniger "richtige" angriffe

Oder: 70% trotzdem, und die wären bei einem Ungewarteten System
durchgegangen. Beweis: Das alleinige Umbiegen hat nichts gebracht.

doch, das alleinige umbiegen hat 30% weniger angriffe gebracht, wieso ist das "nichts" ?

ausserdem wuerde mich immer noch interessieren auf welchem port der andere SSH gelauscht hat, wenns port 23, 222 oder sowas war sind es wohl eher mehr als 30%.

Tja, dann haben wir halt unterschiedliche Kunden und vielleicht auch
eine unterschiedlich Anzahl derer. Und vielleicht unterschiedliche
Service Agreements und Ansprüche unserer Kunden, und vielleicht
wollen meine Kunden von andererorts mit möglichst wenig Aufwand
umziehen, oder haben kein entsprechendes Wissen und wollen sich
keinen $teuren Studenten holen um ihre Bürorechner
umzukonfigurieren...

ich versteh zwar nicht was service agreements mit der portnummer zu tun haben, aber bei der sorte kunden kriegst Du doch SSH-keys erst recht nicht durch. also hast Du auf Deinen systemen unsichere kundenpasswoerter, warum hast Du keine angst vor passwort-brute-forcing ?

Das glaubst du nicht wirklich oder? Lass dir versichert sein, dass
das bei "Root"serverbesitzern *wesentlich* weniger sind als man
vielleicht denken mag. Hier im Forum gibt es sicher einige, und
wie viele "Root"server stehen da draussen? 200.000? 300.000? eine
halbe Million?

naja, jeder mit ner windows-kiste aufm schreibtisch muss sich mit dem thema beschaeftigen und selbst wer nur einmal die woche in den heise-ticker schaut kriegts mit. und durch die online-update-funktionen in den distributionen ist es ja auch kaum noch arbeit. das war vieleicht vor 2-3 jahren so.

1. admin verlegt SSH-port auf 41324, fuehlt sich sicher und spielt
keine patches mehr ein.
2. admin stellt von passwoertern auf SSH-keys um, fuehlt sich sicher
und spielt keine patches mehr ein.

genau, da gibts keinen, ausser das 1. eine weitverbreitete theorie
ist um rechtzufertigen das man in internet-foren ueber
security-by-obscurity-nutzer lachen darf ;)

Genau, und beiden sollte man den Betrieb eines Servers verbieten,
imho.

nochmal: es geht nicht darum das nicht-patchen verwerflich ist, sondern ich wuerde gerne wissen warum port-umbiegen leute vom patchen abhalten soll und SSH-keys nicht???

Die erste setzt sich nur durch, weil sie einfacher zu erklären
ist um die prinzipielle Gefahr dahinter zu verdeutlichen.
Aber nochmal: Wir reden hier von der Grundantwort die hier den
Anfängern gegeben wird die *keine* Ahnung von solchen Systemen haben.
Und da ist Fakt: Das reine Umbiegen des Ports bringt ihnen gar
nichts. (Mal davon abgesehen das SSH nun wirklich nicht so oft
erwischt wird wie die Drölfmilliarden PHP- Applikationen). Jemand der
sich mit seinem System auskennt kann selbst entscheiden ob oder ob
nicht er seine Ports verbiegt. Aber einem Anfänger gegenüber ist
diese Aussage halt gefährlich, punktum.

warum ??? warum sollte er beim port-umbiegen glauben das er ohne patchen leben kann, aber bei SSH-keys (oder irgendeiner anderen sicherheitsmassnahme) nicht ???

Gut, was bringt mir eine Firewall auf meinem Rootserver, die die
Sicherheit meines *Einzel*systems erhöht? Wir reden hier nicht
von Rechnernetzen, ja?

jap, server-firewall, vorteile:
- der boese exploit kann keinen weiteren schadcode runterladen (den er in der regel braucht um root-rechte zu kriegen und datentransfer durch einen buffer overflow ist kompliziert)
- ohne root-rechte kann keiner boeser einen high-port aufmachen und mit meinem server schlonz verteilen
- TCP 53 nur fuer DNS-server die zone-transfer brauchen (falls es mal einen bug in bind gibt).
- iptables -A INPUT -m state --state INVALID -j DROP

Warum sollte ich den Port verlegen?

wegen den allermindestens 30% weniger angriffen

Warum sollte ich meine Versionierungen verstecken? Wegen
den paar MB im Monat an Traffic?

das zweite beispiel meines ersten posts ist ein klarer grund nicht die versionen seiner dienste anzuzeigen, aber obwohl sich schon 5-6 leute gegen versions-verstecken geaeussert haben ist noch niemand mit einem wort darauf eingegangen.

Danke, da packe ich meine Probleme lieber an der Wurzel an, anstatt
die Symptome zu bekämpfen.

wieso symptome ? security by obscurity verhindert das der boese ueberhaupt auf die idee kommt Dich anzugreifen, das ist ursaechlicher als alles andere und sehr weit weg von symptomen.

Ich bin schon sehr lange hier im Forum unterwegs, und grundsätzlich
wenn die Frage "Port umbiegen?" kommt, kann man davon ausgehen das
die Person erstmal ganz andere Sicherheitsaspekte lösen sollte, bevor
sie sich um sowas Gedanken machen sollte...

vieleicht, aber es schadet doch nicht es zusaetzlich zu machen.

[buddaaa]

grundsätzlich wenn die Frage "Port umbiegen?" kommt, kann man davon ausgehen das die Person erstmal ganz andere Sicherheitsaspekte lösen sollte, bevor sie sich um sowas Gedanken machen sollte.

Damit hast Du das zentrale Problem klar und deutlich ausgesprochen. :wink:

Leider wollen das die betroffenen Personen meist nicht hören. :roll:

vieleicht kannst Du mir ja erklaeren warum beim port-umbiegen die wahrscheinlichkeit, das der user danach mit seinen sicherheitsmassnahmen aufhoert, groesser ist als bei allen anderen massnahmen ?

Wirksame Absicherung erfordert regelmäßige Beschäftigung mit der Materie und erheblichen Zeiteinsatz, es ist nicht damit getan, irgendein Tool zu installieren und konfigurieren, und ein paar "Geheim"tipps Marke Portverlegung umzusetzen.

woher kommt die theorie das man nach der port-verlegung aufhoert und nach SSH-keys nicht ?

Wenn die Kiste sauber eingerichtet ist und regelmäßig geupdated wird kann man sich die Portverlegung usw sparen,

das wuerde ich auch mal als populaeren irrtum betrachten, was passiert den mit Deiner kiste wenn ein unbekannter SSH-exploit vor dem patch die runde macht? was garnicht so unwahrscheinlich ist, nicht alle loecher werden von den guten gefunden.

[rootsvr]

- der boese exploit kann keinen weiteren schadcode runterladen (den er in der regel braucht um root-rechte zu kriegen und datentransfer durch einen buffer overflow ist kompliziert)
- ohne root-rechte kann keiner boeser einen high-port aufmachen und mit meinem server schlonz verteilen
- TCP 53 nur fuer DNS-server die zone-transfer brauchen (falls es mal einen bug in bind gibt).

1. wget wird auch mit firewall gehen, zumindest täte es das bei mir. Alternativ ein perlscript mit rechten des www-data
2. doch ohne rootrechte kann man problemlos Ports >1024 aufmachen.
3. ka hab kein bind.

[mattiass]

1. wget wird auch mit firewall gehen, zumindest täte es das bei mir. Alternativ ein perlscript mit rechten des www-data
2. doch ohne rootrechte kann man problemlos Ports >1024 aufmachen.
3. ka hab kein bind.

1. Nunja, man kann ausgehende Verbindungen zu bestimmten Rechnern und Ports sperren.
2. Aber wenn die Firewall Verbindungen zu diesen Ports blockiert, ist schon ein wenig gewonnen.

[wgot]

Hallo,

es schadet doch nicht es zusaetzlich zu machen.

genau das ist der entscheidende Punkt:
es schadet doch nicht es zusaetzlich zu machen.

Es verführt aber dazu, in der Nase zu bohren. :oops:
Und das ist der andere entscheidende Punkt.

Gruß, Wolfgang

[mattiass]

genau das ist der entscheidende Punkt:
es schadet doch nicht es zusaetzlich zu machen.

Es verführt aber dazu, in der Nase zu bohren. :oops:
Und das ist der andere entscheidende Punkt.

Kapier ich nicht. Weil ich mein SSH ab und zu auf Port 22222 legte, bin ich ein Nasebohrer, der "portupgrade" vergisst?

[aubergine]

Ein korrekt konfigurierter und regelmäßig mit Updates versorgter Server hat damit kein Problem.

Wer zu faul für regelmäßige Updates ist kann die Konsequenzen mit verlegtem Port und verlogener Versionsnummer allenfalls etwas hinausschieben aber nicht verhindern.

Meine Server geben sich klar und ehrlich als Linux und Apache zu erkennen, trotzdem hab ich in den Logfiles laufend Angriffsversuche die völlig sinnlos sind, weil sie nur bei Windows und IIS funktionieren.

Nur schlecht das zu 90% erst das Exploit kommt und DANACH der Bugfix...

Von daher ist die Aussage sehr gewaagt.

[buddaaa]

1. wget wird auch mit firewall gehen, zumindest täte es das bei mir. Alternativ ein perlscript mit rechten des www-data

und bei mir wuerde es nicht gehen weil ich ausgehend folgende regeln die meinen web-usern nix erlauben ausser:
1. IMAP auf localhost fuer horde-webmail
2. plesk-update auf 69.64.46.38
3. zugriff auf tcp80 fuer den apache ssl-reverse-proxy.

Code: Select all

# allow sslproxy to ownip:80
/usr/sbin/iptables -A OUTPUT -m owner --uid-owner 30 -m state --state NEW -p TCP --dport 80 -d $IPADDR  -s $IPADDR -j ACCEPT
/usr/sbin/iptables -A OUTPUT -m owner --uid-owner 30 -m state --state NEW -p TCP --dport 80 -d $IPADDR2 -s $IPADDR2 -j ACCEPT
# allow imap for horde
/usr/sbin/iptables -A OUTPUT -m owner --uid-owner 30 -m state --state NEW -p TCP --dport 143 -d 127.0.0.1  -s 127.0.0.1 -j ACCEPT
# don't allow new outbound for wwwrun-user:
/usr/sbin/iptables -A OUTPUT -m owner --uid-owner 30 -m state  --state NEW -j LOG --log-prefix WWWRUNOUT
/usr/sbin/iptables -A OUTPUT -m owner --uid-owner 30 -m state  --state NEW -j DROP
# don't allow new outbound for psacln-group
/usr/sbin/iptables -A OUTPUT -m owner --gid-owner 10001 -m state  --state NEW -j LOG --log-prefix PSACLNOUT
/usr/sbin/iptables -A OUTPUT -m owner --gid-owner 10001 -m state  --state NEW -j DROP

# allow plesk key update ka.swsoft.com:5224
/usr/sbin/iptables -A OUTPUT -p TCP -d 69.64.46.38 --dport 5224 -m state --state NEW,ESTABLISHED -j ACCEPT
/usr/sbin/iptables -A INPUT  -p TCP -s 69.64.46.38 --sport 5224 -m state --state ESTABLISHED -j ACCEPT

# don't allow new outbound for plesk-user:
/usr/sbin/iptables -A OUTPUT -m owner --uid-owner 2523 -m state  --state NEW -j LOG --log-prefix PLESKOUT
/usr/sbin/iptables -A OUTPUT -m owner --uid-owner 2523 -m state  --state NEW -j DROP

= kein schadcode nachladen, keine exploit-versuche bei diensten die nur auf localhost laufen.

wobei das jetzt nur fuer die httpd-user ist, fuer andere dienste muss ich das noch basteln (also z.b. das named nur port 53 darf usw.)

2. doch ohne rootrechte kann man problemlos Ports >1024 aufmachen.

natuerlich, aber mein iptables wirft die eingehenden pakete alle weg.

[buddaaa]

Es verführt aber dazu, in der Nase zu bohren. :oops:
Und das ist der andere entscheidende Punkt.

die behauptung haben wir jetzt schon mehrfach gehoert, aber immer noch keine begruendung? warum verfuehrt port-verlegen mehr zum nasebohren als SSH-keys oder alle anderen sicherheitsmassnahmen ?

[wgot]

Hallo,

warum verfuehrt port-verlegen mehr zum nasebohren als SSH-keys oder alle anderen sicherheitsmassnahmen ?

weil Port-Verlegen keine Sicherheitsmaßnahme ist.

Gruß, Wolfgang

[buddaaa]

Ihr koennt gerne Euren SSH auf port 22 laufen lassen und alle versionsnummern anzeigen

Ein korrekt konfigurierter und regelmäßig mit Updates versorgter Server hat damit kein Problem.

glaubst Du wirklich ein gut konfigurierter uptodate-server ist 100% sicher ?

Wer zu faul für regelmäßige Updates ist kann die Konsequenzen mit verlegtem Port und verlogener Versionsnummer allenfalls etwas hinausschieben aber nicht verhindern.

Du kennst doch sicher den werdegang von 50% der exploits:
1. boeser bube findet luecke, schreibt exploit
2. exploit verbreitet sich in einschlaegigen kreisen, erst bei den profis, nach und nach die hierarchie rnuter zu den skript-kindern
3. ist er bei den skript-kindern kriegt die erste sicherheits-firma wind davon, benachrichtigung des herstellers
4. 1-10 tage spaeter erscheint ein patch des herstellers
5. 0-5 tage spaeter ist der patch getestet und in Deiner lieblings-distribution
6. 0-21 tage spaeter hast Du Deinen server gepatcht (laesst hier jemand autoupdate laufen wenn er 3 wochen in urlaub faehrt ? ;)

ab stufe 3 sind simple rootserver in gefahr (davor wohl eher firmen-server und andere interssante kisten), erst ab stufe 6 bist Du wieder geschuetzt. ist da etwas hinausschieben nicht sinnvoll? das skript-kind weiss auch, das es nur ein paar tage zeit hat, bis der patch draussen ist, desdewegen moechte es moeglichst viele server in moeglichst kurzer zeit erwischen. => lieber 32768 server auf port X scannen als einen server auf 32768 ports.

Meine Server geben sich klar und ehrlich als Linux und Apache zu erkennen, trotzdem hab ich in den Logfiles laufend Angriffsversuche die völlig sinnlos sind, weil sie nur bei Windows und IIS funktionieren.

auch an Dich die einladung mein zweites beispiel zu versionsnummern aus dem orginal-post zu zerpfluecken.

aber haltet bitte niemanden davon ab sein system sicherer zu machen!

Ganz im Gegenteil, wir versuchen immer wieder zur korrekten Absicherung motivieren. Dazu gehört auch, klarzustellen was keine Absicherung darstellt.

das waere ja ein nettes ziel, wenn es stimmen wuerde das security by obscurity keine absicherung ist.

Die Obscurity-Maßnahmen (und die immer wieder beliebten "Firewalls") bringen nicht mehr als eine Beruhigungspille - einen beruhigten Admin, sonst garnix.

obscurity senkt das risiko deutlich (bei mir kein full-port-scan in 6 monaten vs. 488 versuchen auf port 22).

zu den firewalls siehe mein anderen post.

Es gibt nichts schlimmeres als einen Admin, der meint sein Server sei sicher.

oh, da kenn ich einen, der hat mal folgendes gesagt:

Ein korrekt konfigurierter und regelmäßig mit Updates versorgter Server hat damit kein Problem.

... und dabei wissen wir doch alle das ein system erst dann 100% sicher ist, wenn wir es in einen aktiven vulkan geworfen haben ;)

[buddaaa]

warum verfuehrt port-verlegen mehr zum nasebohren als SSH-keys oder alle anderen sicherheitsmassnahmen ?

weil Port-Verlegen keine Sicherheitsmaßnahme ist.

selbst OutOfBound als obscurity-kritiker hat 30% weniger ernsthafte angriffe durch verlegung von SSH auf einen anderen port. warum ist es keine sicherheitsmassnahme ?

und abgesehen von der definitionsfrage einer sicherheitsmassnahme steht immer noch die begruendung aus, warum es mehr zum nasebohren fuehren soll als z.b. SSH-keys ?

[wgot]

Hallo,

auch an Dich die einladung mein zweites beispiel zu versionsnummern aus dem orginal-post zu zerpfluecken.

na denn, ich hol es mal hervor:

2. das skript-kind (...) natuerlich schreibt er ein skript (...)

Script-Kiddies schreiben keine Scripts, die spielen nur mit fertigen Scripts rum.


Spar Dir deine fiktiven Superexploits und denk mal drüber nach, was die vorgeschlagenenen Obscurity-Methoden gegen die tatsächlichen Einbruchstellen nutzen:

Fast alle geknackten Amateurserver wurden über PHP (als ersten Schritt) und unsicheren Kernel (als zweiten Schritt) geknackt, wobei auf den zweiten Schritt häufig auch verzichtet wird, weil zum Mißbrauch als Spamschleuder der erste Schritt genügt.

Unsichere Scripts und veraltete Kernel sind also die Hauptprobleme, mit welchen Firewalleinstellungen, gefälschten Apacheversionen und Portverlegungen möchtest Du dagegen vorgehen?

Gruß, Wolfgang

[buddaaa]

Hallo,

auch an Dich die einladung mein zweites beispiel zu versionsnummern aus dem orginal-post zu zerpfluecken.

na denn, ich hol es mal hervor:

2. das skript-kind (...) natuerlich schreibt er ein skript (...)

Script-Kiddies schreiben keine Scripts, die spielen nur mit fertigen Scripts rum.

ja super, Du kuerzt meine argumentation zusammen weil Du nichts dagegen sagen kannst und bringst schon wieder nur ne andere definition. genau wie in Deinem letzten post, willst nicht langsam mal inhaltlich mitreden ?

ansonsten: wie wuerdest Du jemand nennen, der mit 5 zeilen perl einen runtergeladenen exploit auf unzaehlige server loslaesst, ist das schon ein richtiger cracker oder doch eher ein skript-kind ?

Spar Dir deine fiktiven Superexploits

das ist nix fiktives, beles Dich halt mal ein bischen ueber exploits, googlegoogle, z.b. da:

http://geek.dariball.de/article.php?sto ... 8053818695

und denk mal drüber nach, was die vorgeschlagenenen Obscurity-Methoden gegen die tatsächlichen Einbruchstellen nutzen:

Fast alle geknackten Amateurserver wurden über PHP (als ersten Schritt) und unsicheren Kernel (als zweiten Schritt) geknackt, wobei auf den zweiten Schritt häufig auch verzichtet wird, weil zum Mißbrauch als Spamschleuder der erste Schritt genügt.

Unsichere Scripts und veraltete Kernel sind also die Hauptprobleme,

nach der argumentation sind jegliche sicherheitsmassnahmen ueberfluessig solange sie nicht gerade den kernel und PHP betreffen. was versuchst Du damit also zu beweisen ?

mit welchen Firewalleinstellungen, gefälschten Apacheversionen und Portverlegungen möchtest Du dagegen vorgehen?

siehe http://www.rootforum.org/forum/viewtopi ... 559#268559

[wgot]

Hallo,

selbst OutOfBound als obscurity-kritiker hat 30% weniger ernsthafte angriffe durch verlegung von SSH auf einen anderen port.

auf dieses Argument hat er Dir selbst schon geantwortet.

Bitte lese doch, was Dir andere schreiben und versuche es zu verstehen, anstatt fremde Beiträge nur als Abschußrampe für deine eigenen zu sehen.

Gruß, Wolfgang

[buddaaa]

selbst OutOfBound als obscurity-kritiker hat 30% weniger ernsthafte angriffe durch verlegung von SSH auf einen anderen port.

auf dieses Argument hat er Dir selbst schon geantwortet.

ja, und ich habe ihm auch schon lange darauf geantwortet.

Bitte lese doch, was Dir andere schreiben und versuche es zu verstehen, anstatt fremde Beiträge nur als Abschußrampe für deine eigenen zu sehen.

wieso abschussrampe, 30% weniger angriffe ist die pessimistischste interpretation seiner worte. die optimistische waere 98,9% weniger (1200 auf 14).

und ich warte immer noch auf die begruendung, warum port-verlegung zu mehr zum nasebohren fuehren soll als z.b. SSH-keys ?

[mattiass]

Laß uns diese Diskussion bitte beenden - Du drehst Dich inhaltslos im Kreis und mir fallen vom Kopfschütteln schon die Haare aus.

So. Und damit wir alle vor dem Einschalfen noch etwas zu lachen haben, sollten wir uns jetzt mal mit echter Security by Obscurity beschäftigen und eine Runde nach

KRYPTOCHEF

googeln!

http://www.schneier.com/blog/archives/2 ... se_kr.html

Eine geruhsame Nacht wünscht
Mattias

[buddaaa]

http://www.schneier.com/blog/archives/2 ... se_kr.html

also bruce schneiers zu security by obscurity war neulich folgende:

Who cares about the security properties? I want one.
http://www.hiddenpassageway.com/

;)

aus http://www.schneier.com/crypto-gram-0604.html[/b]

[EdRoxter]

Wieso wird hier eigentlich so polarisiert? Könnte es nicht - reiiiin theoretisch - auch Leute geben, die SecByObs als einzelnen Bestandteil einer Absicherung benutzen zusätzlich zu den sowieso obligatorischen Sachen wie Pubkey-Auth, regelmäßigsten Updates etc.?

Ich möchte wetten, solche Leute gibt's da draußen. Aber da ich auch ein fieser Polarisierer bin, würde ich sowas NIEMALS machen. Lieber Rootlogin erlauben, als Passwort 123456 wählen und einen sshd von vor 5 Jahren benutzen, als auch nur auf die Idee zu kommen, den Port umzulegen. Das wär ja pietätlos.


Tztztz...