Server - Planänderung/"Sicherheits"/Realisierungsfragen

Huaba

Huaba

Semiprofi
Thread Starter
Mitglied seit
02.06.2007
Beiträge
4.583
Hi,

wer hier bissl unterwegs is wird sicher wissen dass ich nen ubuntuserver betreibe, auf dem ein cs und ein cod 5 server laufen. da wir bei meienr 3k leitung ab 6 spielern immer wieder laggs und recht hohe pings (~100) haben, will ich den zu nem kumpel stellen (16k full/10-20er ping)... dazu hät ich einige fragen:

- ich würde daraus dann gern anstelle des cod/cd LAN HAMACHI servers nen itnernetserver mit passwort einrichten. entstehen dadurch sicherheitslücken (passwort wird gut gewählt!)

- wie siehts mit ssh aus, putty.exe z.b... geht das via netzwerk, bzw. worauf muss man achten, damit kein anderer darauf zugreifen kann?

- wie siehts mit wake on lan oder sowas aus, kann ich den server von mir aus dann einschalten (ausschalten würd ja via putty gehn)..?

- auf was muss man sonst achten um nicht ein erhebliches risiko darzustellen?!

mfg

€: achja, als distri - ubuntu. lieber die serveredition ohne grafische oberfläche? weil die brauch ich ja e nicht :d allerdings bin ich am grübeln, ob cod5 ohne gui geht... =/
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Huaba schrieb:
- ich würde daraus dann gern anstelle des cod/cd LAN HAMACHI servers nen itnernetserver mit passwort einrichten. entstehen dadurch sicherheitslücken (passwort wird gut gewählt!)
Zum Vergrößern anklicken....

Da der Server sowieso hinter einen Router im Netzwerk steht muss der COD und CS Port sowieso forwarded werden, von daher wirst du keine allzugroßen Sicherheitsprobleme haben, es seiden die CS/COD Server haben Sicherheitslücken.

Huaba schrieb:
- wie siehts mit ssh aus, putty.exe z.b... geht das via netzwerk, bzw. worauf muss man achten, damit kein anderer darauf zugreifen kann?
Zum Vergrößern anklicken....

SSH-Server

Wieder den Port 22 forwarden, jeder der das Passwort kennt kann sich als root anmelden, so oder so. Jeder der den gefordwarded Port kennt kann sich zumindest versuchen anzumelden!

Huaba schrieb:
- wie siehts mit wake on lan oder sowas aus, kann ich den server von mir aus dann einschalten (ausschalten würd ja via putty gehn)..?
Zum Vergrößern anklicken....

Wake on LAN

:drool:
 
Alles geht meistens ohne GUI, auf jeden Fall solche Server-Sachen.

Zunächst musst du bei deinem Kumpel sicherstellen, dass die Ports dann auch auf deinen Server weitergeleitet werden, d.h. er Admin-Rechte auf dem Router hat.
Welche Ports du genau freigeben musst, kannst du zu Hauf im Netz lachlesen, exakt hab ich die jetzt nicht im Kopf.

Ein "Sicherheitsrisiko" entsteht, sobald der PC am Internet hängt, das ist ganz klar.

Die Idee mit Putty ist ganz ok, das benutzt ich hier selber im LAN auch, allerdings solltest du bei einer Verbindung übers Internet die SSH-Verbindung mit SSL verschlüsseln.
Dafür gibt es sicher auch Anleitungen im Netz, openssh sollte ja schon installiert sein.

Außerdem solltest du das Passwort von deinem Benutzernamen sehr sicher machen.
(Gut, angenommen jemand hat es wirklich auf deinen Server abgesehen, wird er auch dieses knacken, aber so kleine Freaks die einfach mal irgendwas testen, schreckt das dann doch ab).

Wie du im CS/CoD5 - Server ein Passwort einstellst, gibt es ebenfalls auf Internetseiten, das musst du jeweils in der server-config eingeben.

Für WakeOnLan musst du in deinem Server noch ethtool installieren (apt-get install ethtool) und ein Script an entsprechender Stelle erzeugen, wie das geht hat _nico bereits gepostet :bigok:

Eine kleine Anleitung findest du hier:


Ausschalten geht wie gesagt mit putty.

Ganz wichtig wäre wie gesagt eine verschlüsselte SSH-Verbindung ;)

Ansonsten ist das alles realisierbar :wink:

mfg
foxxx :)
 
Zuletzt bearbeitet:
danke euch beiden! Ubuntu wird grad installiert :-D
 
bitte ssh-login als root verbieten (sshd_config)
ssh mit ssl zu sichern ist unsinn
 
jetz stiftet ihr aber verwirrung :d die einen sagen mit, die andern ohne ssl... gründe? argumente? pro/kontra? ;)
 
Beide Methoden nutzen die selben Algorithmen zur Verschlüsselung, ja SSH greift sogar auf SSL-Libraries zu. Unsicher sind jeweils nur die Endpunkte (Server/Client). SSL soll einfache TCP-Verbindungen schützen und braucht immer ein ausführendes Programm (zb Dein Webbrowser), SSH kann allein arbeiten.

Ach was rede ich, es ist Unsinn, den Rest wird Dir foxxx sicher erläutern.
 
also auf jeden fall solltest du den ssh port ändern weil es über den standardport jeder arsch versuchen wird drauf zu kommen und du solltest einen extra benutzer anlegen für ssh und nur ihn erlauben sich auf dem system anzumelden
(wird in der /etc/ssh/sshd_config)
[code}
PermitRootLogin no (<= root login abstellen)
AllowUsers user1, user2 (<=erlaubt nur den angegebenen Benutzern den zugriff)
AllowGroups Grp1, grp2 (<=erlaubt nur den angegebenen Gruppen den zugriff)[/code}

und dann bist du dort erstmal sicher ;)

ssh und ssl, naja ssh ist doch schon verschlüsselt, warum also das ganze nochmal tun??

ansonsten alle unnötigen dienste abstellen.. und wenn ihr so öfters zockt dann mietet euch doch nen server..

PS. wir verwirren gerne ;)
 
Zuletzt bearbeitet:
also connecten kann ich schonmal drauf ;)

sodala... naja, das soll ja kein hochsicherheitsserver sein, ich will ja nur alle paar wochen mal mit paar freundn zocken für ne stunde :d

also ich hab jetz gemacht:
root login verboten!

ich grübel: wieso einen extra benutzer für ssh?
außerdem hab ich hier n verständnisproblem: ich hab bei benutzer "server" und als root (z.b. sudo bash, sudo blabla...) dasselbe PW. wieso? und was is der unterschied zwischen "sudo blabla" und "su root" und dann befehl eingeben?
wenn ich nen neuen nutzer machen sollte - welchen gruppen sollte dieser zugehören!?

port ändern, hab ich so gemacht, is das ok?
Die Datei /etc/ssh/sshd_config im Editor öffnen
Dort findet man die Zeile:
Port 22
Zum Vergrößern anklicken....
und dann nen port zw. 49152 und 65535 rein (wieso eigtl so hoch?! :d)

danke!
€: wegen dem ssh nutzer: neuen nutzer anlegen in der gruppe "wheel". nun dem n starkes PW geben... und nur noch dem user den login erlauben. so richtig?^^
 
Zuletzt bearbeitet:
ja so passts.....

btw: ich hab unsinn geredet, ich hatte nur neulich mit nem telnet-server zu tun, den wir dann mit ssl gesichert haben, aber ssh ist ja eigentlich schon telnet+ssl :shot:

Also ssh passt schon, halt die config anpassen und dann ist das alles ok ;)
 
sudo führt nur den aktuellen befehl mit root rechten aus dazu muss das benutzerpasswort nochmals eingegeben werden.
wenn man su eintippt wird das root passwort abgefragt und man arbeitet dann die ganze zeit mit root ausser man meldet sich ab oder beendet das terminal..
jedoch ist su bei Ubuntu standardmässig abgestellt. btw: wenn du Ubuntu-server nimmst kannst du auch gleich debian lenny nehmen.. ;)
 
jo ich tüftel grad rum, scsi controller und ne etwas größere festplatte sind grad aufm weg zu mir :sabber:

das mit ssh klappt jetz (foxxx sagt dazu lieber nix :d), mal sehen, werd die tage weiter rumtesten!

mfg
 
stimmt, ich bleib besser ganz still, sonst ...... wie gesagt, ich bleib still :fresse:

Aber Debian Lenny wäre die bessere Wahl gewesen :shot:

:hail: Debian Lenny :hail:

:banana:

So, und nun genug OT für diesen Beitrag, vielleicht fällt mir noch was sinvolles ein .....

ssh läuft .... dann mach doch weiter mit wake on lan ;)

mfg
foxxx :wink:
 
jo, wegen dem debian - das is e nur test. da kommt noch ne größere platte bzw n scsi controller rein, das sollte ja unter linux laufen oder? is der "Dawicontrol DC 2976 UW" + 2*cheetah 10.k7 ... wird das automatisch erkannt? wie siehts mit raid aus?

mfg

so, 2 stundn rumgespielt. WOL geht nicht ._. ethtool erkennt die karte und er meckert auchnicht wenn ich sie via
sudo ethtool -s eth0 wol g
Zum Vergrößern anklicken....
aktiviere. egal ob ich mit etherwake(ubuntu) oder nem anderen tool aufwecke - vergisses. =/
 
Zuletzt bearbeitet:
hast du auch das script in die entsprechende datei geschrieben, damit es kurz vorm herunterfahren aufgerufen wird ?

Außerdem muss Wake on Lan im Bios an sein.

Desweiteren musst du dann mit einem speziellen Magic Packet aufwecken.
Auf meinem Windows PC nutze ich dazu : http://www.pc-adviser.de/wake_on_lan.php

Das funktioniert bei mir einwandfrei.


Ich weiß nicht wie das unter Ubuntu funktioniert, und ich glaub auch, dass das einer der Hauptgründe für meinen Wechsel zu Debian war, dass diese System-grundlegenden Sachen unter Ubuntu nicht gut funktionieren wollen.....

Außerdem hat sich für der Server-Einsatz einfach Debian etabliert und ist weitgehend bekannt.

mfg
foxxx :wink:
 
Probier mal mein C#.Net Tool aus, habe ich mal vor ein paar Wochen geschrieben
und das sendet ein garantiert ein ordentliches Magic-Paket (sofern die MAC und der Netzbroadcast stimmt)

das Paket ist ein funktionierendes Magic-Packet das nach der Spezifikation von AMD erstellt wird und somit funktioniert sollte :)


welchen Kernel verwendet dein OS?
hab mal gelesen dass z.B. der Kernel 2.6.18 nicht bei vielen Netzwerk-Karten WOL problemlos unterstützt...

mfg
aelo

Ps.:
hier gäbe es übrigens auch noch weitere Parameter für andere WakeOn-Events:
http://www.nwlab.net/tutorials/ethtool/ethtool.html
die du eventuell mal austesten könntest...
allerdings ist nur beim Magic-Paket garantiert dass es sonst nicht aufwacht, weil die anderer Pakete werden ja öfters im Netzwerk versendet un dann kann der Server auch ungewollt gestartet werden xD
 

Anhänge

  • wakeonlantool_by_aelo.zip
    2,4 KB · Aufrufe: 60
Zuletzt bearbeitet:
geht auch ncih dein tool. habs nomal alles gecheckt, stimmt zu 1000%

Kernel: Linux server 2.6.27-11-generic

naja, das MUSS mit dem magic paket funzen ._. ich test morgen nochmal ne andere karte... hoffe das geht. danke euch allen!

nochmal infos:
01:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
Flags: bus master, medium devsel, latency 64, IRQ 5
I/O ports at 3400
Memory at ee001000 (32-bit, non-prefetchable)
Capabilities: <access denied>
Kernel driver in use: 8139too
Kernel modules: 8139cp, 8139too
Zum Vergrößern anklicken....


Settings for eth2:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
Link detected: yes
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
alles schon gemacht - keine chance. hab grad zum 6. mal das ubuntutut durchgemacht und die tipps von aelo, geht nicht^^

ich werd mal lenny testen, vll geht das dann :d

€: danke fürs tut foxxx!
 
Zuletzt bearbeitet:
das TUT ist echt lange, konnte bei mir unter Etch und Lenny nach der Installation von ethtool sofort den Befehl ins Script koppieren, den Server herunterfahren und schon funktionierte alles :-)
(egal welchen Kernel ich verwendete: getestet mit 2.6.18, 2.6.24, 2.6.26, 2.6.27, 2.6.28)

mfg
aelo
 
Zuletzt bearbeitet:
so, debian zum basteln drauf.

frage: wie mach ich beim aufruf eines nutzers von sudo das root-passwort notwendig ?
Zum Vergrößern anklicken....

;) sprich:

anmelden als "nutzer" -> nutzer_pw
sudo $befehl -> root_pw
su root -> root_pw

geht das? wär ja dann sozusagen ne doppelte Passwortsperre, oder reicht da einmal aus? oO

€: abgesehen davon.. es geht bei ssh nru port 22 ._. wieso das?! sobald ich den port 50000 z.b. einstell und den daemon neustarte kann ich nimemr connecten... es sind aber die richtigen dateien! verdammt nomal ._.

network error: software caused connection abort
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Bei sudo wird _immer_ das Passwort des (eigenen) Benutzers abgefragt, nicht das von root. Wer sudo benutzen darf und wofür wird in /etc/sudoers festgelegt. "su root" oder "su irgendeinnutzer" fragen immer das Passwort des Zielnutzers ab, nicht von jenem der das Kommando aufruft. Das sudo System hat gerade in Multiuserszenarien Vorteile, wenn mehrere Administratoren root Zugriff haben müssen. Angenommen einer wird entlassen, dann muss nicht überall das root Passwort geändert werden, sondern sein Account wird aus /etc/sudoers herausgenommen und vom System gelöscht und schon kann er nicht mehr root werden. Mann braucht den anderen Administratoren nun nicht (angenommen) 250 neue root Passwörter für alle Server zukommen lassen. Auch kann man die Befehle die mittels sudo verwendet werden dürfen beschränken, so dass meinetwegen bestimmte Nutzer nur Backups mit rootrechten durchführen dürfen, während andere nur Benutzerverwaltungsbefehle als root ausführen dürfen...

Zu SSH, nachdem du den Port geändert hast und SSH neustartest, hast du auch bei Putty auf den neuen Port umgestellt? Dann sollte das problemlos klappen...
 
ja hab ich umgestellt. das mit dem sudo/su is mir echt klar, aber ich wollts halt anders haben. aber gut, das is e egal.

ich scheiter grad an meinem lenny, bwz eher am WOL. wieder nach tut, langsam glaub ich echt es is n hardwarefehler. ich stell mich schon blöd an, aber jetz test ich da schon mehrere stunden... langsam reichts mir. ich werd jetz mal warten bis die restlichen teile kommen und an nem anderen pc rumtüfteln...
 
Also entweder bist du jetzt wirklich ne Idee zu dumm, oder bei deiner Hardware scheitert's

Da ich dich ja nun schon mehrfach gezwungen habe, die Sachen zu wiederholen, glaube auch ich mittlerweile fast an einen Hardwarefehler.

Tausch doch mal die Netzwerkkarte....

Auf meinem Sockel A von vor 9 Jahren mit ner 100mbit Intel PCI läuft das auf Anhieb, einfach strikt nach Anleitung vorgehen, dann geht das auch.

mfg
foxxx :wink:
 
verdammt nochma, das mach ich seit 6 stundn nun :d das will einfach ned...

kanns an meienr vernetzung liegen? normal nich, is ja total wayne an welchem switch was hängt...

._. grrr
 
Liste die verbaute HW doch nochmal genau auf, vielleicht findet man dann ja was ;)
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh