»

[sCHween]

Tasch auch
Ich denke es is mal wieder an der Zeit etwas technisches zu besprechen.

Wir könnten mal aufzählen was ihr für richtig haltet betreffend Server und Security...

• System aktuell halten
• SSH sichern
  • root Login verbieten
  • auf Protokoll 2 umsteigen
  • nach X Versuchen bannen Main Page - Fail2ban
• Ports absichern
• Proc Einstellungen
  # auf Broadcast-Pings nicht antworten
  echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
  # halt die Klappe bei komischen ICMP Nachrichten
  echo 0 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
  # Kicke den ganzen IP Spoofing Shit
  # (Source-Validierung anschalten)
  echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
  # Setze Default-TTL auf 61 (Default fuer Linux ist 64)
  echo 61 > /proc/sys/net/ipv4/ip_default_ttl
  # sende RST-Pakete wenn der Buffer voll ist
  echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow
  # warte max. 30 secs auf ein FIN/ACK
  echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
  # unterbreche Verbindungsaufbau nach 3 SYN-Paketen
  # Default ist 6
  echo 3 > /proc/sys/net/ipv4/tcp_syn_retries
  # unterbreche Verbindungsaufbau nach 3 SYN/ACK-Paketen
  # Default ist 6
  echo 3 > /proc/sys/net/ipv4/tcp_synack_retries
• Sec Soft
  • chkrootkit
  • rkhunter
  • clamAV
  • alles mit nem Cron starten
• Backup

Software sichern (Installationsabhängig)

• PHP effektiv gegen Hacker-Angriffe absichern
  PHP effektiv gegen Hacker-Angriffe absichern
• Mail relay testen
  Mail relay testing

[redwood]

das kann noch ergänzt werden mit unnötige dienste abschalten.

hm da streitet man sich. ob man doch auf die normalen pings antworten soll, da sonst der angreifer im zusammen hang mit dns eh weiss das es ein server ist. ich persönlich bin aber ebenfalls fürs nicht antworten.

vorsicht beim testen auf so seiten von mail relay, währe nicht das erste mal das der server noch offen ist und wegen des tests direkt auf der blacklist landet. lieber zu erst selber testen.

beim backup auch eine rücksicherung machen.