vServer absichern?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

      vServer absichern?

      Hallo,

      ich habe einen vServer für TS, Minecraft und einer Website gemietet. Da ich nur Grundkentnisse in Linux habe, möchte ich nur wissen ob ich den vServer auch richtig abgesichert habe.

      Was ich bis jetzt eingestellt habe:

      - Fail2Ban installiert mit Firewall (myslug.de/index.php?title=Firewalling:_iptables_und_Fail2Ban)
      Spoiler anzeigen
      # Fail2Ban configuration file.
      #
      # This file was composed for Debian systems from the original one
      # provided now under /usr/share/doc/fail2ban/examples/jail.conf
      # for additional examples.
      #
      # To avoid merges during upgrades DO NOT MODIFY THIS FILE
      # and rather provide your changes in /etc/fail2ban/jail.local
      #
      # Author: Yaroslav O. Halchenko <[email protected]>
      #
      # $Revision: 281 $
      #

      # The DEFAULT allows a global definition of the options. They can be override
      # in each jail afterwards.

      [DEFAULT]

      # "ignoreip" can be an IP address, a CIDR mask or a DNS host
      ignoreip = 127.0.0.1
      bantime = 600
      maxretry = 3

      # "backend" specifies the backend used to get files modification. Available
      # options are "gamin", "polling" and "auto".
      # yoh: For some reason Debian shipped python-gamin didn't work as expected
      # This issue left ToDo, so polling is default backend for now
      backend = polling

      #
      # Destination email address used solely for the interpolations in
      # jail.{conf,local} configuration files.
      destemail = ...

      #
      # ACTIONS
      #

      # Default banning action (e.g. iptables, iptables-new,
      # iptables-multiport, shorewall, etc) It is used to define
      # action_* variables. Can be overriden globally or per
      # section within jail.local file
      banaction = iptables-multiport

      # email action. Since 0.8.1 upstream fail2ban uses sendmail
      # MTA for the mailing. Change mta configuration parameter to mail
      # if you want to revert to conventional 'mail'.
      mta = sendmail

      # Default protocol
      protocol = tcp

      #
      # Action shortcuts. To be used to define action parameter

      # The simplest action to take: ban only
      action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]

      # ban & send an e-mail with whois report to the destemail.
      action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
      %(mta)s-whois[name=%(__name__)s, dest="%(destemail)s", protocol="%(protocol)s]

      # ban & send an e-mail with whois report and relevant log lines
      # to the destemail.
      action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
      %(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s]

      # Choose default action. To change, just override value of 'action' with the
      # interpolation to the chosen action shortcut (e.g. action_mw, action_mwl, etc) in jail.local
      # globally (section [DEFAULT]) or per specific section
      action = %(action_)s

      #
      # JAILS
      #

      # Next jails corresponds to the standard configuration in Fail2ban 0.6 which
      # was shipped in Debian. Enable any defined here jail by including
      #
      # [SECTION_NAME]
      # enabled = true

      #
      # in /etc/fail2ban/jail.local.
      #
      # Optionally you may override any other parameter (e.g. banaction,
      # action, port, logpath, etc) in that section within jail.local

      [ssh]

      enabled = true
      port = ssh
      filter = sshd
      logpath = /var/log/auth.log
      maxretry = 6

      # Generic filter for pam. Has to be used with action which bans all ports
      # such as iptables-allports, shorewall
      [pam-generic]

      enabled = false
      # pam-generic filter can be customized to monitor specific subset of 'tty's
      filter = pam-generic
      # port actually must be irrelevant but lets leave it all for some possible uses
      port = all
      banaction = iptables-allports
      port = anyport
      logpath = /var/log/auth.log
      maxretry = 6

      [xinetd-fail]

      enabled = false
      filter = xinetd-fail
      port = all
      banaction = iptables-multiport-log
      logpath = /var/log/daemon.log
      maxretry = 2


      [ssh-ddos]

      enabled = false
      port = ssh
      filter = sshd-ddos
      logpath = /var/log/auth.log
      maxretry = 6

      #
      # HTTP servers
      #

      [apache]

      enabled = false
      port = http,https
      filter = apache-auth
      logpath = /var/log/apache*/*error.log
      maxretry = 6

      # default action is now multiport, so apache-multiport jail was left
      # for compatibility with previous (<0.7.6-2) releases
      [apache-multiport]

      enabled = false
      port = http,https
      filter = apache-auth
      logpath = /var/log/apache*/*error.log
      maxretry = 6

      [apache-noscript]

      enabled = false
      port = http,https
      filter = apache-noscript
      logpath = /var/log/apache*/*error.log
      maxretry = 6

      [apache-overflows]

      enabled = false
      port = http,https
      filter = apache-overflows
      logpath = /var/log/apache*/*error.log
      maxretry = 2

      #
      # FTP servers
      #

      [vsftpd]

      enabled = false
      port = ftp,ftp-data,ftps,ftps-data
      filter = vsftpd
      logpath = /var/log/vsftpd.log
      # or overwrite it in jails.local to be
      # logpath = /var/log/auth.log
      # if you want to rely on PAM failed login attempts
      # vsftpd's failregex should match both of those formats
      maxretry = 6


      [proftpd]

      enabled = false
      port = ftp,ftp-data,ftps,ftps-data
      filter = proftpd
      logpath = /var/log/proftpd/proftpd.log
      maxretry = 6


      [wuftpd]

      enabled = false
      port = ftp,ftp-data,ftps,ftps-data
      filter = wuftpd
      logpath = /var/log/auth.log
      maxretry = 6


      #
      # Mail servers
      #

      [postfix]

      enabled = false
      port = smtp,ssmtp
      filter = postfix
      logpath = /var/log/mail.log


      [couriersmtp]

      enabled = false
      port = smtp,ssmtp
      filter = couriersmtp
      logpath = /var/log/mail.log


      #
      # Mail servers authenticators: might be used for smtp,ftp,imap servers, so
      # all relevant ports get banned
      #

      [courierauth]

      enabled = false
      port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
      filter = courierlogin
      logpath = /var/log/mail.log


      [sasl]

      enabled = false
      port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
      filter = sasl
      # You might consider monitoring /var/log/warn.log instead
      # if you are running postfix. See bugs.debian.org/507990
      logpath = /var/log/mail.log


      # DNS Servers


      # These jails block attacks against named (bind9). By default, logging is off
      # with bind9 installation. You will need something like this:
      #
      # logging {
      # channel security_file {
      # file "/var/log/named/security.log" versions 3 size 30m;
      # severity dynamic;
      # print-time yes;
      # };
      # category security {
      # security_file;
      # };
      # };
      #
      # in your named.conf to provide proper logging

      # Word of Caution:
      # Given filter can lead to DoS attack against your DNS server
      # since there is no way to assure that UDP packets come from the
      # real source IP
      [named-refused-udp]

      enabled = false
      port = domain,953
      protocol = udp
      filter = named-refused
      logpath = /var/log/named/security.log

      [named-refused-tcp]

      enabled = false
      port = domain,953
      protocol = tcp
      filter = named-refused
      logpath = /var/log/named/security.log
      - Root login gesperrt (ist nur offen, wenn ich mit WinSCP etwas hochlade.)
      - Server jede Woche updaten.
      - Port geändert
      - Nur Protocol 2 erlaubt

      Gibt es noch weitere Kriterien, die ich beachten sollte?

      Boomer2084

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Boomer2084 ()

      Was hast du fürn WebServer installiert?
      Apache ist schon von anfang an drauf installiert. Daran geändert habe ich bisher noch nichts. PHP o.Ä habe ich auch noch nichts geändert oder installiert.

      Unter welchem Nutzer laufen TS & Minecraft?
      Sämtliche Programme laufen über den root, worauf ich mit den Befehl "su" zugreife.

      Was ich noch vergessen habe zu erwähnen ist, dass auf dem Server Ubuntu 10.04 - LAMP läuft.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Boomer2084 ()

      Meh ... Programme unter root laufen lassen is net so dolle. Der Prozess läuft mit root rechten und sollte TeamSpeak oder (viel warscheinlicher aufgrund von Java) der Minecraft-Server ein Sicherheitsleck haben, hat ein möglicher Angreifer direkt alle Rechte. Leg lieber eigene Accounts an und gib denen sichere Passwörter.

      Dann noch drauf achten, dass chmod stimmt (vorallem im www-Ordner) und dann siehts erstmal sicher aus.

      Gruß
      florian0
      Voll nervig das kein vServer host nen betriebssystem anbietet was up to date ist.
      10.04 ist schon uralt...

      Wie florian schon sagte auführen als root ist sehr unschön.
      Installier die apf-firewall um deine ports zu sperren.
      Je nachdem ob du ddos gefahr hast gibt es anti ddos scripte die via iptables nen temp ban verhängen bei zu vielen zugriffen.
      Sichere PW's
      Regelmäßige updates und eventuell auch ma dein OS upgraden.

      hangman schrieb:

      Wenn es bei der deutschen Sprache eine Syntax Prüfung gäbe, wären so einige Menschen stumm


      Danke für die Hilfe.

      Eine Firewall ist schon eingerichtet. Ich habe jetzt alle Programme mit einem anderen User gestartet.

      Allerdings gibt es jetzt ein Problem...

      Seitdem startet der Minecraft-Server garnicht oder nur sehr langsam. Rechte sind natürlich vergeben. Er scheint beim laden der Mods große Probleme zu haben. Auch mit neu angelegten Minecraft-Daten besteht das Problem. Beim Root tretet das problem auch auf. Die Daten sind im Home-Ordner gespeichert. Bei starten habe ich zwei verschiedene Arten verwendet.

      1.) McMyAdmin mit 3gb ram
      2.) java -Xmx3000M -Xms3000M -jar ftb-beta-A.jar nogui

      java version "1.6.0_24"

      Gibts dafür auch noch einen Rat? Hat zwar nicht viel mit dem jetzigen Thema zu tun aber egal...

      Welche Virtualisierungsplatform?
      Welches Java?
      Schafft das die CPU überhaupt bzw. hast du so viel RAM verfügbar?

      Schau mal mit top in nem zweiten SSH-Fenster was die Load average sagt.

      Gruß
      florian0
      Ich frag mich immer wie man solche Angaben wie 5 GHz oder (wie bei mir) 110% CPU-Leistung deuten soll ...
      Die Load Average (LA) ist abhängig von der CPU Anzahl. Wenn du nur einen CPU(Kern) hast, dann ist 1.0 die Grenze des CPUs. Alles was mehr ist, staut sich auf. Bei 2 Kernen sinds halt 2.0, bei 4 4.0 usw.
      Jenachdem wie viele Kerne du hast, ist deine aktuelle LA gut oder schlecht. (Wie findet man bei einem vServer die Anzahl der Kerne raus?)

      Wie viele Leute sind auf dem MC-Server, und was machen die da? Oder ist das nur beim Starten?

      Java und vServer ist immer so ne Sache ... ich hab das Gefühl OpenJDK ist langsamer als das Sun-Java6. Hatte ne ziemlich hohe LA sogar wenn der MC-Server (Bukkit ohne große Plugins) im Idle-Modus war. Mit Java6 von Sun wurds dann besser. Desweiteren solltest du mit Java den FlexRAM nach Möglichkeit nicht nutzen. FlexRAM steht dir nicht garantiert 100% zu Verfügung. Und wenn die Java-VM nicht genug RAM bekommt, dankt sie dir das mit unbeschreiblich geilen Bugs :P

      Versuchs erstmal mit dem Java von Sun.

      Gruß
      florian0

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von florian0 ()

      Also ich bin mir bei der CPU und dem Memory auch nicht ganz sicher aber ich glaube beim CPU war es genauso wie bei der Load average. Du hast 4 Kerne also ist die max CPU usage 400%.

      Haben die Dateien denn auch die Rechte es Benutzers?
      Oft wird die Binary dem Benutzer zugeordnet aber unterdateien werden vergessen.

      sudo chown -R benutzer:benutzergruppe /path/to/minecraft
      sudo chmod -R 750 /path/to/minecraft

      Der erste command erste weißt allen Dateien den benutzer und die gruppe zu.
      Der zweite command vergibt die Rechte der Dateien
      7 Der Benutzer darf alles Lesen,Schreiben,Ausführen
      5 Die Gruppe darf Lesen und Ausführen
      0 Andere benutzer dürfen gar nix

      hangman schrieb:

      Wenn es bei der deutschen Sprache eine Syntax Prüfung gäbe, wären so einige Menschen stumm