nicht angemeldet
Alleroberstes Gebot für Sicherheit sind sichere Passwörter. Ein sicheres Passwort ist mindestens 8, lieber 10 Zeichen lang, ist kein Wort einer menschlichen Sprache, auch kein Name, enthält kleine und große Buchstaben und Zahlen, gerne auch noch Satzzeichen, und sieht hinreichend "zufällig" aus. Ideal, wenn es tatsächlich mit einem Zufallsgenerator erzeugt wurde.
Da man sich ein solches Passwort ohnehin idR. nicht merken kann und meistens niemals braucht ist 8 oder 10 Stellen imho ebenfalls zu kurz - da kannst ruhig eine längere Zeichenkette sein.
Bei unsicheren Protokollen wie etwa FTP hilft das natürlich nichts - wenn der Angreifer z.B. ein Scriptkiddie in der Nachbarschaft ist den Traffic des WLAN mitliest.
Noch schöner als ein Passwort für die Zugangskontrolle sind Krypto-Protokolle mit Public-Key-Authentisierung. Das ist vor allem beim SSH-Zugang von Vorteil, denn ein Account, der gar nicht mit Passwort zugänglich ist, kann mit Passwort auch nicht gehackt werden.
Alternativ ist natürlich auch eine Zugangsbeschränkung über ein VPN möglich.
Natürlich sollten geschichten wie Datenbankzugänge entsprechend Beschränkt sein - der Produkt-Account der Datenbank braucht idR. keine GRANT-, ALTER-oder CREATE-Rechte. Entsprechende erweiterte Rechte kann man im bedarfsfall schnell temporär hinzufügen (z.B. bei einem Update, welches die Struktur verändert).
Der zweite Punkt: Stetige Aktualisierung von eingesetzter Standardsoftware. Also alles, was man als Blog, Forum, Board, Gästebuch, Uploadskript, Mailer etc. aus typischen Standardquellen bezieht, sollte immer topaktuell gehalten werden.
Denn die Angreifer können mit einer simplen Google-Suche herausfinden, welche Softwareversion auf welcher Domain eingesetzt wird - und schlagen genau dann zu, wenn dafür eine Sicherheitslücke bekannt wird.
Für solche Zwecke gibst auch einschlägige Suchmaschinen und Tracker - wie z.B. milw0rm.
Setzt man eine Version einer Software mit einer sehr leicht auszunützenden Sicherheitslücke ein, ist man möglicherweise ein leichtes Ziel für ein automatisiertes Mass-Defacement.
Die Wahrscheinlichkeit, dass eine Sicherheitslücke in selbstgeschriebenen Skripten erfolgreich ausgenutzt werden kann, ist zwar gegeben - aber deren Ausnutzung ist viel unwahrscheinlicher, weil für solche eigenen Skripte keine auf HTTP basierenden Sicherheitsscanner nur sehr schwierig automatisiert herausfinden können, ob du angreifbar bist.
Zudem greift in diesem Fall - so seltsam es klingt security through obscurity doch ein bisschen. Ein Script welches nur auf meiner Seite Verwendung findet und ich selbst geschrieben habe hat möglicherweise Sicherheitslücken, aber diese sind (sofern nicht durch Brute-Force ausnutzbar) weniger kritisch als eine bekannte Sicherheitslücke in einem verbreiten System welches ich einsetze.