fedora 7 fürs inet abhärten?

[le bart]

so, bisher alles super, vnc und squid über tunnel, firewall regeln hab ich auch halbwegs kapiert, eine frage noch, laut messages gibt es immer wieder dhcp anfragen. bedeuten die einträge, dass der fremde mit seiner anfrage kommentarlos abgewiesen wird oder kriegt er die letzte meldung mitgeteilt? thx!

Dec 30 02:22:26 machin dhclient: DHCPREQUEST on eth0 to x.x.x.x port 67
Dec 30 02:22:26 maschin dhclient: DHCPACK from 63.247.71.225
Dec 30 02:22:26 maschin dhclient: bound to y.y.y.y -- renewal in 33743 seconds.

[le bart]

hab jetzt openvpn mit zertifikaten zum laufen gebracht, jetzt stellt sich mir die frage, ob ich in iptables sämtlichen traffic von tun erlauben soll (gleiche regel wie lo), oder ob ich jeweils die benötigten ports von tun zum localhost freigeben soll. glaubt ihr es gibt realistische chancen, dass jemand über den openvpn reinkommt?

[colossus]

Ney.

[Philipp]

Hast Du jetzt etwa KDE auf dem VPS Konto installiert?

[le bart]

ja, rennt auch 1a, nur brauch ichs nicht mehr, hab webmin entdeckt

[Philipp]

Normalerweise installiert man kein KDE oder sonstige grafische Oberfläche auf einen Webserver. Es sei den auf den Ding läuft Windows Server

Falls Du hauptsächlich Websites hosten willst, gibt es auch noch http://www.isp-control.net/ oder http://www.syscp.org/

[le bart]

danke

Original geschrieben von Philipp
Das wird aber nicht viel bringen. Für solche Fälle verwende ich fail2ban

Daniel B. Cid entdeckte, dass fail2ban, ein Werkzeug zum Blockieren von IP-Adressen, die Anmelde-Probleme verursachen, zu liberal für das Verarbeiten von SSH-Log-Dateien ist. Dies ermöglicht einem Angreifer, jede IP-Adresse zu blockieren.
http://www.debian.org/security/2008/dsa-1456
DARUM rennt auf meinem server nicht mal iptables, sondern nur jene software, die unbedingt notwendig ist. wozu hat man schließlich ein NAT davor?
Jeder Daemon, dass die Systemkomplexität erhöht und nicht unbedingt notwendig ist, ist ein Daemon zuviel
Sicherheitsrelevante Filter etc. haben nicht mMn nicht lokal, sondern auf dedizierten Maschinen, die dafür ausgelegt sind (in meinem Fall ein Linksys WRT54G) zu rennen.

[Philipp]

Original geschrieben von schichtleiter
Daniel B. Cid entdeckte, dass fail2ban, ein Werkzeug zum Blockieren von IP-Adressen, die Anmelde-Probleme verursachen, zu liberal für das Verarbeiten von SSH-Log-Dateien ist. Dies ermöglicht einem Angreifer, jede IP-Adresse zu blockieren.
http://www.debian.org/security/2008/dsa-1456

Und? Das Paket war Heute bei meinen täglichen Security Updates dabei

Original geschrieben von schichtleiter
Sicherheitsrelevante Filter etc. haben nicht mMn nicht lokal, sondern auf dedizierten Maschinen, die dafür ausgelegt sind (in meinem Fall ein Linksys WRT54G) zu rennen.

Also ich glaube kaum das man in Rechenzentren Consumerhardware wie den WRT54G verwenden sollte . Ausserdem sind meine Server üppig dimensioniert.

Es ist doch völlig egal, ob das heute upgedated wurde - Fakt is der Fehler war für lange Zeit offen (und vermutlich einigen Leuten bekannt, die jedoch kein Interesse daran hatten dass dies publik wird ) und während dieser Zeit hätte jeder der lustig ist den Server DoSen können.

Ob der Server im Rechenzentrum steht oder nicht, Sicherheits- und Applikationsebene gehört imho hardwaremäßig getrennt; damit meine ich eine getrennte Firewall. Eventuell könnte man diese auf einer Virtual Machine auf der selben Hardware laufen lassen, die optimale Lösung sind trotzdem 2 getrennte Maschinen (Beispiel: DDoS - die Firewall brennt ab und is im Eimer, dadurch is aber der eigentliche Server automatisch vom Netz getrennt, rennt weiter und es entsteht kein Datenverlust - die Dienste können sobald die Firewall ersetzt ist, wieder ans Netz gehen). Dass du dort vermutlich eine andere Hardware verwenden solltest, steht auf einem anderen Blatt, die Fähigkeit zur Adaptierung setzte ich prinzipiell voraus.

Die Dimensionierung der Hardware spielt für das Prinzip keine Rolle...