Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: sourceserver.info. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

Mastermind

Anfänger

  • »Mastermind« ist der Autor dieses Themas

Beiträge: 16

Wohnort: Oberbayern

Rootserver vorhanden: Ja

  • Nachricht senden

1

Mittwoch, 12. Januar 2011, 01:50

Root Server sicher machen!

Hallo zusammen,

ich bräuchte eure Hilfe!
Da unser Root jetzt innerhalb von 2 Monaten 2x gehackt wurde würde ich gerne mal so in die runde fragen wie ihr eure Server gegen angriffe sichert!

Mein System läuft mit Debian Lenny x86!
Auf dem Server läuft 1 Gameserver und 1 TS Server! sonst nichts!

Bisher lief fail2ban drauf und Serveranbieter meinte dass es reicht aber anscheinend doch nicht!
Der Server wird morgen neu aufgesetzt und Ich möchte dann endlich ruhe haben!

Da meine erfahrung mit Linux nocht nicht so groß ist hoffe ich dass mir wär ein paar gute Tipps geben kann!

mfg Mastermind

General_V

Super Moderator

Beiträge: 1 043

Wohnort: Mönchengladbach

Beruf: Brückenkranführer / Staplerfahrer

Rootserver vorhanden: Nein

  • Nachricht senden

2

Mittwoch, 12. Januar 2011, 09:05

Re: Root Server sicher machen!

Naja die meisten haben immer so ein kleines Passwort das sehr leicht zu knacken ist, da kann ich dir nur sagen überlege die mal ein gescheites PW, es sollte Bustaben und Zahlen enthalten und wenns geht nicht zu kurz. Fail2ban habe ich eben so drauf und es läuft sehr gut und kann nicht Klagen.

3

Mittwoch, 12. Januar 2011, 09:36

Re: Root Server sicher machen!

Welches Serverprogramm wurde denn gehackt?
Wenn nur Teamspeak und Gameserver laufen, würde ich mal auf ersteres tippen?!
Anstelle von fail2ban, würde ich bei so einem System auf denyhosts setzen. Oder noch besser: Authkey + Passphrase als einzige Loginmöglichkeit. Dann braucht man keine Programme, wie denyhosts, fail2ban usw.

Standartsachen:
- Ports verlegen, so dass Autobots ins Leere laufen und man echte Angriffe einfacher sehen kann. (Wenn jemand dann angreift, hat er sich gezielt deinen Server rausgepickt und einen Portscan gemacht)
- direkten Root Zugriff verbieten.
- Nur einem User SSH Zugriff erlauben und den Rest per su - username erreichen.
- alles mit Eigenständigen Usern verwalten, bzw. starten
- root nur für administrative Sachen, wie Debian Updates usw. einsetzen

Zum Absichern eines TS3 Servers ist hier ein ganz netter Thread:
http://serversupportforum.de/forum/teamspeak/42928-teamspeak3-server-sicher-aufsetzen.html?s=48e428f9f09eec5af6d1bed172568fee">http://serversupportforum.de/forum/team ... d172568fee</a>
Webbasierender Config Ersteller: www.ulrich-block.de für CS 1.6, CSS, DODS und TF2.

Ebenso wird werden verschiedene Debian Gameserverkernel zum Download angeboten.

4

Mittwoch, 12. Januar 2011, 09:50

Re: Root Server sicher machen!

Wichtig (d.h. ergänzend zu dem was Terrorkarotte geschrieben hat) ist noch ein aktueller Kernel. Bis 2.6. 34 IIRC gab es eine Sicherheitslücke, mit der jeder User Root-Zugriff erlangen konnte. Dazu muss man zwar erstmal Zugriff als normaler User bekommen, aber das geht im Zweifelsfall über Sicherheitslücken in PHP-Scripten o.ä. (Distributionen mit longtime support haben evtl auch ältere Kernel-Versionen gepatcht, aber das gilt ja nicht, wenn man selbst compiliert!)
http://fpsmeter.org
http://wiki.fragaholics.de (Linux Kernel HOWTO!)
http://www.fragaholics.de

Bitte keine technischen Fragen per PM!

Lestat666

unregistriert

5

Mittwoch, 12. Januar 2011, 18:53

Re: Root Server sicher machen!

Was genau wurde da gehackt?
Wie hast Du den Hack festgestellt?

DeaD_EyE

Administrator

Beiträge: 3 980

Wohnort: Hagen

Beruf: Mechatroniker (didaktische Systeme)

Rootserver vorhanden: Nein

  • Nachricht senden

6

Mittwoch, 12. Januar 2011, 19:19

Re: Root Server sicher machen!

TS3 war mal eine Zeit lang auch sehr anfällig für Hacks. Hast du deine Version auch immer barv aktuell gehalten?
Dann steht noch die Frage offen, ob du die Todsünde begangen hast. Lief der TS3 mit Root-Rechten? Gleiches gilt beim Gameserver.

Dann ist fraglich was gemacht wurde. Hat sich ein fremder User auf das System per SSH eingeloggt? Wurden die Logdateien vor dem Löschen sichergestellt? Ist dein eigener PC Trojanerfrei? Es ist auch schon sehr oft passiert, dass der PC des Admins mit Viren und Trojanern versucht gewesen ist. Gerade dann wird es kritisch. Selbst beim Verwenden einen SSH-Keys mit Passphrase kann der Hacker über den bereits installierten Keylogger das PW von deinem SSH-Key mitlesen. Welche IP und Port du verwendest, sieht der Hacker über den Live-Bilder deines Desktops. Wenn man Paranoid ist, loggt man sich niemals von fremden PCs auf seinen Root ein. Genausowenig riskitert man es sich auf dem PC zuhause Viren einzufangen.

Aber ohne weitere Informationen können wir nur Vermutungen anstellen.

Letzendlich würde ich die von Terrorkarotte vorgeschlagene Methode verwenden. Allein wenn man nur den SSH-Port verlegt, werden dadurch viel weniger Script-Kiddys angezogen. Viel mehr kann es dann aber auch sein, dass sich die richtigen Hacker dann für den Host anfangen zu interessieren. Die Meinungen gehen dabei weit außeinander ob es Sinn macht die Standardport zu ändern oder nicht. Ich persönlich habe meinen SSH-Port auch geändert. Mit Portsentry kann man dann noch die Portscans unterbinden, die viele einsetzen um die offenen Ports zu finden. Somit ist es sehr unwahrscheinlich, dass jemand von außen herein kommt.

Viel wahrscheinlicher ist, dass jemand über einen laufenden Dienst wie Teamspeak3 auf den Server einbricht. Beim SRCDS wäre ich auch vorsichtig. Früher wurde mal bekannt, dass sich mit dem SRCDS sogar Dateien an einen beliebigen Pfad hochladen ließen. Es konnten sogar Dateien überschrieben werden. Ein findiger Hacker könnte so z.B. einmal ein Shellscript hochladen, dass beim nächsten Login des Server-Users automatisch das Schadprogramm nachlädt, welches dann später im Hintergrund aktiv bleibt und auf deinem Root ein Torrent-Server macht. Ist schon alles vorgekommen ^^

oldi1960

Fortgeschrittener

Beiträge: 179

Wohnort: Berlin

Beruf: Feinmechaniker

Rootserver vorhanden: Ja

  • Nachricht senden

7

Mittwoch, 12. Januar 2011, 20:21

Re: Root Server sicher machen!

TS3 ich hatte das Problem beim aktuell halten also einfach überschreiben das ich sämtliche Bugs immer mitgenommen habe vor allem das Gäste kicken konnten,erst eine Neuinstallation hatt den Bug beseitigt.Würde es was bringen TS3 in einer Vituellen Umgebung laufen zu lassen z.b. mit Xen?
Gruß aus Berlin
Oldi1960

CHUluck4

Fortgeschrittener

Beiträge: 313

Wohnort: düsseldorf

Beruf: Industriemechaniker

  • Nachricht senden

8

Mittwoch, 12. Januar 2011, 20:54

Re: Root Server sicher machen!

Du hättest auch einfach den Gästen die Rechte nehmen können.

Mastermind

Anfänger

  • »Mastermind« ist der Autor dieses Themas

Beiträge: 16

Wohnort: Oberbayern

Rootserver vorhanden: Ja

  • Nachricht senden

9

Donnerstag, 13. Januar 2011, 00:46

Re: Root Server sicher machen!

Wie der Hacker rein gekommen ist weiß ich nicht! Er hatte auf alle fälle das Root passwort und benutzte den Server um andere IP`s zu scannen! Zum Glück habe Ich es noch am selben Tag bemerk! Festgestellt habe ich es da der Server down ging und Ich den Support informierte. Der hat mir dann gesagt dass er wieder On ist aber warum Ich andere IP`s scanne! Dann habe Ich mir die logs runter geladen und hab gesehen dass eine andere IP aus USA mehrmals als root eingeloggt war!

Root habe ich nur für Updates benutzt! Für Gameserver und Teamspeak hatte Ich 2 extra User angelegt!

Teamspeak habe Ich immer die aktuelle Version drauf!

Für den Heim PC/Laptop habe Ich "Search & Destroy" und "Antivir" in unregelmäßigen abständen drüber laufen lassen!
Ich werde mich erst mit den neuen daten anmelden sobald alle PC`s Viren frei sind!
Ich benutze auch ein SSH tool fürs IPad! Wie sicher ist sowas? Werden die apps von Apple geprüft bevor sie im Store landen?

Habt ihr evtl. Howto`s für die oben genannten sicherheits vorkehrungen ansonsten werd ich Google anwerfen!

10

Donnerstag, 13. Januar 2011, 09:36

Re: Root Server sicher machen!

also wenn er wirklich das root-passwort hat, halte ich das für wahrscheinlich, dass er das entweder per brute-force angriff erlangt hat (war/is es ein sehr einfaches root-pw? sprich kommt es in einem wörterbuch vor oder ist nur eine leichte abwandlung davon?) oder es mitgelesen hat (höchstwahrscheinlich per keylogger auf einem PC, von dem aus du dich eingeloggt hast).

btw: wenn der root bereits kompromittiert ist, hilft eigentlich nur eine komplette neuinstallation (inkl. kompletter formatierung). du kannst dir ab dann nicht mehr sicher sein, dass du wirklich die volle kontrolle über den root wiedererlangst. vielleicht hat dir der angreifer schon längst ein root-kit installiert...

PS: fail2ban hilft übrigens wunderbar gegen brute-force angriffe, das ändern des ports hingegen nicht (bzw. nur solang, bis jemand mal nen portscan macht).
http://fpsmeter.org
http://wiki.fragaholics.de (Linux Kernel HOWTO!)
http://www.fragaholics.de

Bitte keine technischen Fragen per PM!

DeaD_EyE

Administrator

Beiträge: 3 980

Wohnort: Hagen

Beruf: Mechatroniker (didaktische Systeme)

Rootserver vorhanden: Nein

  • Nachricht senden

11

Donnerstag, 13. Januar 2011, 17:15

Re: Root Server sicher machen!

Gegen Portscans hilft Portsentry.
Wenn der SSH-Daemon dann noch auf einem anderen Port läuft, ist es fast unmöglich herauszufinden, auf welchem Port der SSH-Dienst läuft.

Mastermind

Anfänger

  • »Mastermind« ist der Autor dieses Themas

Beiträge: 16

Wohnort: Oberbayern

Rootserver vorhanden: Ja

  • Nachricht senden

12

Donnerstag, 13. Januar 2011, 19:06

Re: Root Server sicher machen!

Der Server wurde neu installiert! SSH Daemon läuft auf einem anderen Port und das Passwort ist jetzt ein anderes und länger!
Meinen Laptop hab Ich jetzt 3x mit Antivir durchsucht und mit Search&Destroy! Ein Trojaner 'JAVA/ClassLoader.BO' wurde gefunden und gelöscht!
Sollte ich noch was drüber laufen lassen oder kann ich los legen weil hab mich bis jetzt aus sicherheitsgründen mal noch nicht eingeloggt!

Was ich auch immer komisch fand war das wenn ich mit einem anderen Benutzer per Filezilla eingeloggt habe z.b. den von Gameserver den Ich über das Gameinterface erstellt hatte konnte ich trotzdem in alle Verzeichnisse gehen und nicht nur ins /Home/Gameserver, zwar nicht schreiben aber lesen! Bei meinem Homeserver und meinem VServer hab ich das ganze mit "adduser" gemacht da ist das dann nicht so!

Meine Frage:
Wenn ich das ganze über "adduser" mach muss ich dann noch extra was einstellen weil im Interface kann ich ja noch port, Quota usw einstellen oder geht das auch so?

Koffein

Fortgeschrittener

Beiträge: 353

Rootserver vorhanden: Nein

  • Nachricht senden

13

Donnerstag, 13. Januar 2011, 19:31

Re: Root Server sicher machen!

Also zu deinem eigenem Rechner,
ich würd ihn komplett neuinstallieren.

Es gibt Fälle da fressen sich die Viren bis in die Hardware,
da bringt dann eine Neuinstallation auch nicht viel erfolg :D

Mastermind

Anfänger

  • »Mastermind« ist der Autor dieses Themas

Beiträge: 16

Wohnort: Oberbayern

Rootserver vorhanden: Ja

  • Nachricht senden

14

Donnerstag, 13. Januar 2011, 21:46

Re: Root Server sicher machen!

Könnte evtl. schnell mal wer über die Portsentry.conf sehen! Es läuft zwar aber nach nem test werde ich nicht geblockt!
Meinen SSH port hab ich hier mal schnell mit "9999" eingetragen!

Hab mir zwar ein tut gesucht aber leider komm ich nicht drauf warum dass es nicht funktioniert!
Pfad von iptables stimmt!

Spoiler Spoiler

# PortSentry Configuration
#
# $Id: portsentry.conf.Debian,v 1.6 2001/07/19 21:02:20 agx Exp $
#
# Original portsentry.conf by Craig H. Rowland <crowland@psionic.com>
# modified for Debian by Guido Guenther <agx@debian.org>
#
# IMPORTANT NOTE: You CAN NOT put spaces between your port arguments.
#
# The default ports will catch a large number of common probes
#
# All entries must be in quotes.


#######################
# Port Configurations #
#######################
#
#
# Some example port configs for classic and basic Stealth modes
#
# I like to always keep some ports at the "low" end of the spectrum.
# This will detect a sequential port sweep really quickly and usually
# these ports are not in use (i.e. tcpmux port 1)
#
# ** X-Windows Users **: If you are running X on your box, you need to be sure
# you are not binding PortSentry to port 6000 (or port 2000 for OpenWindows users).
# Doing so will prevent the X-client from starting properly.
#
# These port bindings are *ignored* for Advanced Stealth Scan Detection Mode.
#

# Un-comment these if you are really anal:
#TCP_PORTS="1,7,9,11,15,70,79,80,109,110,111,119,138,139,143,512,513,514,515,540,635,1080,1524,2000,2001,4000,4001,5742,6000,6001,6667,12345,12346,20034,27665,30303,32771,32772,32773,32774,31337,40421,40425,49724,54320"
#UDP_PORTS="1,7,9,66,67,68,69,111,137,138,161,162,474,513,517,518,635,640,641,666,700,2049,31335,27444,34555,32770,32771,32772,32773,32774,31337,54321"
#
# Use these if you just want to be aware:
TCP_PORTS="9999,1,11,15,79,111,119,143,540,635,1080,1524,2000,5742,6667,12345,12346,20034,31337,32771,32772,32773,32774,40421,49724,54320"
UDP_PORTS="9999,1,7,9,69,161,162,513,635,640,641,700,32770,32771,32772,32773,32774,31337,54321"

#
# Use these for just bare-bones
#TCP_PORTS="1,11,15,110,111,143,540,635,1080,1524,2000,12345,12346,20034,32771,32772,32773,32774,49724,54320"
#UDP_PORTS="1,7,9,69,161,162,513,640,700,32770,32771,32772,32773,32774,31337,54321"

###########################################
# Advanced Stealth Scan Detection Options #
###########################################
#
# This is the number of ports you want PortSentry to monitor in Advanced mode.
# Any port *below* this number will be monitored. Right now it watches
# everything below 1024.
#
# On many Linux systems you cannot bind above port 61000. This is because
# these ports are used as part of IP masquerading. I don't recommend you
# bind over this number of ports. Realistically: I DON'T RECOMMEND YOU MONITOR
# OVER 1024 PORTS AS YOUR FALSE ALARM RATE WILL ALMOST CERTAINLY RISE. You've been
# warned! Don't write me if you have have a problem because I'll only tell
# you to RTFM and don't run above the first 1024 ports.
#
#
ADVANCED_PORTS_TCP="1024"
ADVANCED_PORTS_UDP="1024"
#
# This field tells PortSentry what ports (besides listening daemons) to
# ignore. This is helpful for services like ident that services such
# as FTP, SMTP, and wrappers look for but you may not run (and probably
# *shouldn't* IMHO).
#
# By specifying ports here PortSentry will simply not respond to
# incoming requests, in effect PortSentry treats them as if they are
# actual bound daemons. The default ports are ones reported as
# problematic false alarms and should probably be left alone for
# all but the most isolated systems/networks.
#
# Default TCP ident and NetBIOS service
ADVANCED_EXCLUDE_TCP="113,139"
# Default UDP route (RIP), NetBIOS, bootp broadcasts.
ADVANCED_EXCLUDE_UDP="520,138,137,67"


######################
# Configuration Files#
######################
#
# Hosts to ignore
IGNORE_FILE="/etc/portsentry/portsentry.ignore"
# Hosts that have been denied (running history)
HISTORY_FILE="/var/lib/portsentry/portsentry.history"
# Hosts that have been denied this session only (temporary until next restart)
BLOCKED_FILE="/var/lib/portsentry/portsentry.blocked"

##############################
# Misc. Configuration Options#
##############################
#
# DNS Name resolution - Setting this to "1" will turn on DNS lookups
# for attacking hosts. Setting it to "0" (or any other value) will shut
# it off.
RESOLVE_HOST = "0"

###################
# Response Options#
###################
# Options to dispose of attacker. Each is an action that will
# be run if an attack is detected. If you don't want a particular
# option then comment it out and it will be skipped.
#
# The variable $TARGET$ will be substituted with the target attacking
# host when an attack is detected. The variable $PORT$ will be substituted
# with the port that was scanned.
#
##################
# Ignore Options #
##################
# These options allow you to enable automatic response
# options for UDP/TCP. This is useful if you just want
# warnings for connections, but don't want to react for
# a particular protocol (i.e. you want to block TCP, but
# not UDP). To prevent a possible Denial of service attack
# against UDP and stealth scan detection for TCP, you may
# want to disable blocking, but leave the warning enabled.
# I personally would wait for this to become a problem before
# doing though as most attackers really aren't doing this.
# The third option allows you to run just the external command
# in case of a scan to have a pager script or such execute
# but not drop the route. This may be useful for some admins
# who want to block TCP, but only want pager/e-mail warnings
# on UDP, etc.
#
#
# 0 = Do not block UDP/TCP scans.
# 1 = Block UDP/TCP scans.
# 2 = Run external command only (KILL_RUN_CMD)

BLOCK_UDP="1"
BLOCK_TCP="1"

###################
# Dropping Routes:#
###################
# This command is used to drop the route or add the host into
# a local filter table.
#
# The gateway (333.444.555.666) should ideally be a dead host on
# the *local* subnet. On some hosts you can also point this at
# localhost (127.0.0.1) and get the same effect. NOTE THAT
# 333.444.555.66 WILL *NOT* WORK. YOU NEED TO CHANGE IT!!
#
# ALL KILL ROUTE OPTIONS ARE COMMENTED OUT INITIALLY. Make sure you
# uncomment the correct line for your OS. If you OS is not listed
# here and you have a route drop command that works then please
# mail it to me so I can include it. ONLY ONE KILL_ROUTE OPTION
# CAN BE USED AT A TIME SO DON'T UNCOMMENT MULTIPLE LINES.
#
# NOTE: The route commands are the least optimal way of blocking
# and do not provide complete protection against UDP attacks and
# will still generate alarms for both UDP and stealth scans. I
# always recommend you use a packet filter because they are made
# for this purpose.
#

# Generic
#KILL_ROUTE="/sbin/route add $TARGET$ 333.444.555.666"

# Generic Linux
#KILL_ROUTE="/sbin/route add -host $TARGET$ gw 333.444.555.666"

# Newer versions of Linux support the reject flag now. This
# is cleaner than the above option.
KILL_ROUTE="/sbin/route add -host $TARGET$ reject"

# Generic BSD (BSDI, OpenBSD, NetBSD, FreeBSD)
#KILL_ROUTE="/sbin/route add $TARGET$ 333.444.555.666"

# Generic Sun
#KILL_ROUTE="/usr/sbin/route add $TARGET$ 333.444.555.666 1"

# NEXTSTEP
#KILL_ROUTE="/usr/etc/route add $TARGET$ 127.0.0.1 1"

# FreeBSD
#KILL_ROUTE="route add -net $TARGET$ -netmask 255.255.255.255 127.0.0.1 -blackhole"

# Digital UNIX 4.0D (OSF/1 / Compaq Tru64 UNIX)
#KILL_ROUTE="/sbin/route add -host -blackhole $TARGET$ 127.0.0.1"

# Generic HP-UX
#KILL_ROUTE="/usr/sbin/route add net $TARGET$ netmask 255.255.255.0 127.0.0.1"

##
# Using a packet filter is the PREFERRED. The below lines
# work well on many OS's. Remember, you can only uncomment *one*
# KILL_ROUTE option.
##

# ipfwadm support for Linux
#KILL_ROUTE="/sbin/ipfwadm -I -i deny -S $TARGET$ -o"
#
# ipfwadm support for Linux (no logging of denied packets)
#KILL_ROUTE="/sbin/ipfwadm -I -i deny -S $TARGET$"
#
# ipchain support for Linux
#KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY -l"
#
# ipchain support for Linux (no logging of denied packets)
#KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY"
#
# iptables support for Linux
KILL_ROUTE="/sbin/iptables -I INPUT -s $TARGET$ -j DROP"
#
# iptables support for Linux with limit and LOG support. Logs only
# a limited number of packets to avoid a denial of service attack.
# KILL_ROUTE="/sbin/iptables -I INPUT -s $TARGET$ -j DROP && /sbin/iptables -I INPUT -s $TARGET$ -m limit --limit 3/minute --limit-burst 5 -j LOG --log-level DEBUG --log-prefix 'Portsentry: dropping: '"
#
# For those of you running FreeBSD (and compatible) you can
# use their built in firewalling as well.
#
#KILL_ROUTE="/sbin/ipfw add 1 deny all from $TARGET$:255.255.255.255 to any"
#
#
# For those running ipfilt (OpenBSD, etc.)
# NOTE THAT YOU NEED TO CHANGE external_interface TO A VALID INTERFACE!!
#
#KILL_ROUTE="/bin/echo 'block in log on external_interface from $TARGET$/32 to any' | /sbin/ipf -f -"


###############
# TCP Wrappers#
###############
# This text will be dropped into the hosts.deny file for wrappers
# to use. There are two formats for TCP wrappers:
#
# Format One: Old Style - The default when extended host processing
# options are not enabled.
#
#KILL_HOSTS_DENY="ALL: $TARGET$"

# Format Two: New Style - The format used when extended option
# processing is enabled. You can drop in extended processing
# options, but be sure you escape all '%' symbols with a backslash
# to prevent problems writing out (i.e. \%c \%h )
#
KILL_HOSTS_DENY="ALL: $TARGET$ : DENY"

###################
# External Command#
###################
# This is a command that is run when a host connects, it can be whatever
# you want it to be (pager, etc.). This command is executed before the
# route is dropped or after depending on the KILL_RUN_CMD_FIRST option below
#
#
# I NEVER RECOMMEND YOU PUT IN RETALIATORY ACTIONS AGAINST THE HOST SCANNING
# YOU!
#
# TCP/IP is an *unauthenticated protocol* and people can make scans appear out
# of thin air. The only time it is reasonably safe (and I *never* think it is
# reasonable) to run reverse probe scripts is when using the "classic" -tcp mode.
# This mode requires a full connect and is very hard to spoof.
#
# The KILL_RUN_CMD_FIRST value should be set to "1" to force the command
# to run *before* the blocking occurs and should be set to "0" to make the
# command run *after* the blocking has occurred.
#
#KILL_RUN_CMD_FIRST = "0"
#
#
#KILL_RUN_CMD="/some/path/here/script $TARGET$ $PORT$ $MODE$"
# for examples see /usr/share/doc/portsentry/examples/


#####################
# Scan trigger value#
#####################
# Enter in the number of port connects you will allow before an
# alarm is given. The default is 0 which will react immediately.
# A value of 1 or 2 will reduce false alarms. Anything higher is
# probably not necessary. This value must always be specified, but
# generally can be left at 0.
#
# NOTE: If you are using the advanced detection option you need to
# be careful that you don't make a hair trigger situation. Because
# Advanced mode will react for *any* host connecting to a non-used
# port below your specified range, you have the opportunity to
# really break things. (i.e someone innocently tries to connect to
# you via SSL [TCP port 443] and you immediately block them). Some
# of you may even want this though. Just be careful.
#
SCAN_TRIGGER="0"

######################
# Port Banner Section#
######################
#
# Enter text in here you want displayed to a person tripping the PortSentry.
# I *don't* recommend taunting the person as this will aggravate them.
# Leave this commented out to disable the feature
#
# Stealth scan detection modes don't use this feature
#
#PORT_BANNER="** UNAUTHORIZED ACCESS PROHIBITED *** YOUR CONNECTION ATTEMPT HAS BEEN LOGGED. GO AWAY."

# EOF

Koffein

Fortgeschrittener

Beiträge: 353

Rootserver vorhanden: Nein

  • Nachricht senden

15

Donnerstag, 13. Januar 2011, 22:16

Re: Root Server sicher machen!

ssh deamon neugestartet?

Mastermind

Anfänger

  • »Mastermind« ist der Autor dieses Themas

Beiträge: 16

Wohnort: Oberbayern

Rootserver vorhanden: Ja

  • Nachricht senden

16

Donnerstag, 13. Januar 2011, 22:45

Re: Root Server sicher machen!

hab ich gemacht

Koffein

Fortgeschrittener

Beiträge: 353

Rootserver vorhanden: Nein

  • Nachricht senden

17

Samstag, 15. Januar 2011, 05:19

Re: Root Server sicher machen!

So nach einem halben Jahr dachte ich setzt den Root mal wieder neu auf ;)

Wollte es jetzt auch so einstellen,
das ich mich per Schlüssel anmelde,
hab also meinen Schlüssel erstellt etc..etc..
Einloggen per Schlüssel klappt auch,
aber man kann sich trotzdem noch mit seinem Passwort einlogen :shaem2:

Hier mal die Punkte aus der sshd_config...

Quellcode

1
2
3
4
5
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys
#PasswordAuthentication no
UsePAM no


Damit müsste das einloggen per Passwort doch eigentlich verboten sein, oder?

18

Samstag, 15. Januar 2011, 10:20

Re: Root Server sicher machen!

Quellcode

1
#PasswordAuthentication no


Wenn du die Stelle, an der du Passwortlogins verbietest auskommentierst, wird es erlaubt.
Versuch mal

Quellcode

1
PasswordAuthentication no


;)
Webbasierender Config Ersteller: www.ulrich-block.de für CS 1.6, CSS, DODS und TF2.

Ebenso wird werden verschiedene Debian Gameserverkernel zum Download angeboten.

Koffein

Fortgeschrittener

Beiträge: 353

Rootserver vorhanden: Nein

  • Nachricht senden

19

Samstag, 15. Januar 2011, 14:03

Re: Root Server sicher machen!

Danke ;)
Bei manchen Dateien muss ein # davor stehen bleiben, da so die Variablen sind,
bei manchen nicht.. komisches System :P

Aber jetzt funktioniert!
Man kriegt direkt einen Disconnect wenn man nur einen Benutzernamen eingibt :P

Koffein

Fortgeschrittener

Beiträge: 353

Rootserver vorhanden: Nein

  • Nachricht senden

20

Samstag, 15. Januar 2011, 16:06

Re: Root Server sicher machen!

//EDIT

So ich würde gerne den Usern die Sich versperren...
Sprich sie sollen wenn man sich per sftp(Über Winscp) einwählen,
nur ihr /home/USERNAME sehen und sollten nicht in die übergeordneten Ordner wechseln können...

Hab schon versucht über usermod -s /bin/false USERNAME ,
dann kann der User sich allerdings nichtmehr einloggen, könnte vielleicht in Konflikt mit dem Schlüssel treten?!

Jemand eine Lösung wie ich es trotzdem schaffe?