Beiträge von master_d

Zitat von Sebbo

Dann bringt TeamSpeak den Fix aber auch erst in einem Jahr raus.

Um hier nochmals eine Anmerkung einzuwerfen, es muss ja nicht unbedingt ein "fertiges Programm" sein, sondern es würden auch technische Informationen ausreichen, welche die Lücke beschreiben.

Dann wären zum einen die "Scriptkiddies" erst einmal außen vor, bis eine andere Gruppierung "ein Tool für die Masse" in das Internet wirft.
Damit wäre Teamspeak noch immer unter Druck, hätte aber auch nach der Veröffentlichung noch ein wenig "Spielraum".

Wenn ich jetzt einmal aus meiner bescheidenen Sichtweise überlegen soll, was mir so als "machbar" in den Sinn kommt, wäre ich zu folgender Regelung bereit:

Zitat

r4p3.net erklärt sich bereit, die Exploits direkt an Teamspeak zu schicken, jedoch nach 30 Tagen (Zeitpunkt potentiell verhandelbar, lieber kürzer) den Exploit veröffentlichen zu dürfen.

Das wäre so ungefähr das "höchste" der Gefühle des Entgegenkommens. Wenn die Developer bei Teamspeak ihren Job nicht machen wollen, dann sollen sie es auch spüren. Auch wenn dies manchmal nur auf die "harte Tour" funktioniert.

Leute die ein Leben haben, fangen auf jeden Fall mal mit "lesbaren Antworten" an. Ebenso erkennt man an der Rechtschreibung durchaus einen gewissen Bezug zum Alter der Person. Und auch wenn du diese Aussage wieder nach /dev/null schieben möchtest, tu dies von mir aus.

Was die Konfiguration von Teamspeak3 angeht, so wird alles über das sog. Query-Interface abgehandelt. Standardmäßig erreichbar unter Port 10011, und als Telnet-Interface ausgelegt. Egal auf welchem System.
Und es sind "alle" Funktionen nutzbar, nur das erstellen weiterer Instanzen kann aufgrund der fehlenden Lizenz nur virtuell erfolgen (Parameter zum entsprechenden Befehl beachten).

@TBServer Bitte beherzige die letzte Aussage in deinem Post ebenfalls selbst. Überdenke deine Aussagen hier, und lerne etwas daraus.
Konstruktive Kritik VS Bashing!!

Aber nun zum Problem. Eine NPL-Lizenz bezieht sich auf eine statische IP, und wird auch gegen diese IP validiert. Es sind durchaus Änderungen der IP möglich, jedoch müssen diese im Accounting-System von Teamspeak nachgepflegt werden, welches ein Support-Ticket erfordert.
Es ist daher zu empfehlen, den TS3-Server auf einem System zu betreiben, welches über eine statische IP verfügt.
Ansonsten, wenn es sich erst einmal um ein Test-System handelt, könnte das ganze mit mehreren VM's gelöst werden, welche jeweils eine TS3-Instanz mit max. 32 Slots beinhalten. Dazu muss aber dann für jede Instanz eine entsprechende Port-Weiterleitung generiert werden (Voice-Port[UDP] und Filetransfer[TCP]).
Solltest du das Problem mit VM's lösen wollen, wären durchaus linux-basierte Systeme zu empfehlen, um den GUI-Overhead zu vermeiden. Windows gibt's ja leider nicht Console-only

Klingt durchaus sinnvoll, aber ist etwas schwer zu lesen, daher versuche ich das ganze mal zusammen zu fassen.

1. Teamspeak3 deinstallieren, und den Ordner %APPDATA%\TS3Client\" kopieren und danach löschen. (Wobei das deinstallieren nur eine zusätzliche Sicherheit darstellt)
2. Teamspeak3 starten (ggf. neu installieren) und neu konfigurieren.
3. Die Funktionen mit verschiedenen Servern testen, um sicher zu sein, dass es nicht am Server liegt.
4. ggf. die gesicherte Konfiguration in den uner 1. genannten Ordner kopieren, !!Aber vorher die funktionierende Konfiguration ebenfalls sichern!!, um nochmals die vorhandene Konfiguration zu testen (Natürlich bei geschlossenem TS3-Client)

Danach einfach die möglichst funktionierende Konfiguration benutzen. Ansonsten nochmals hier melden, dann muss man sich das Problem mal Remote anschauen.

Dann wäre eine Lizenz nötig, um zum einen mehr Slots zur Verfügung zu haben, und auch die Möglichkeit mehrerer Server zu haben. Ansosten geht nur je. 1 Server mit max. 32 Slots pro System.

Einreichten eines Service-Records, der auf deine DynDNS-Adresse gerichtet ist, sollte dein Problem lösen können.

Einfach mal hier im Forum nach "SRV Record" suchen. Wenn dann noch Probleme auftauchen sollten, kann dir auf jeden Fall geholfen werden. Da ich leider gerade ebenfalls unterwegs bin, steht eine direkte Hilfe leider nicht zur Verfügung. Dies könnte aber durchaus am Wochenende erledigt werden.

Wenn ich auch mal meinen Senf dazu gebe, dann fallen mir 2 Sachen auf.

1. Der genannte Code steht nicht explizit unter einer Lizenz, daher ist aus meiner "Laiensicht" kein Problem (rechtlich) erkennbar, warum man den Code nicht "unverändert" und mit Copyright-Notifications auf den Urheber verkaufen können sollte.

2. Natürlich ist es eine Schweinerei, solche Gebarden an den Tag zu legen. Wenn man solche Codes verwendet, dann sollte man wenigstens den "richtigen" Weg einschlagen. Im Rahmen meiner Tätigkeit als IT-Berater verwende ich gerne OpenSource-Software, so dass ich dort natürlich auch mit den Codes von anderen arbeite. Dabei bestehe ich jedoch darauf, mein Geld mit dem Service, also der Einrichtung und Betreuung der Systeme zu verdienen, und nicht einfach die Werke anderer "zu verkaufen".

Dies soll jedoch nur meine Meinung sein, und kann leider nicht für einen Sinneswandel bei anderen Personen sorgen.

Eine kleine Anmerkung zu @Sebbo und seinem SSH-Vorschlag.

Es wäre auch möglich, per SSH eine Port-Weiterleitung einzurichten, und dann Lokal mit Telnet zu arbeiten, aber ja, es ist immer Telnet nötig.

@Sebbo Hier ein kleiner Hinweis. Neuere Versionen von Debian benutzen bereits Systemd, hier erkenntlich durch den Symlink.

Ich gehe daher davon aus, dass hier Systemd-Networkd zum Einsatz kommt, und daher der Symlink zu einer generierten Datei von Systemd erkennbar ist.

Daher bitte die Konfiguration des Networkdaemons von Systemd prüfen und darlegen, um dieses Problem nachvollziehbar zu machen.

Letzte Änderung rückgängig machen, damit die normalen wieder Admins ziehen können.

Danach einfach dem AFK-Channel eine needed_move_power geben, die höher ist , als die move_power von normalen und Admins.
Ist ein klein wenig komisch vom Gedanken her, einem Kanal Rechte zu geben, aber das ist der Weg.

Wie ja bereits in einem anderen Thread angekündigt, werde ich mein eigenes Projekt wieder aus der Versenkung holen, welches nicht nur die hier genannten Funktionen bietet, sondern allgemein als Blockliste für Spam, Angriffe, etc. verwendet werden könnte.

Dann kann man entweder die Inhalte zusammenlegen, oder über eine Schnittstelle beider Systeme nachdenken. Ansonsten bin ich natürlich ebenfalls bereit, im Rahmen meiner Kenntnisse Unterstützung zu leisten.

Danke für die Info.

Als Anregung für weitere "Verlegungen". Einfach bei dem alten System einen Hinweis hinterlassen, oder sogar einen "Wartungsmodus" aktivieren, um den Nutzer über den Umzug zu informieren. Ansonsten "verschwinden" manchmal gern ein paar Posts.

Bei einem kurzen Test gerade konnte ich mich mit dem Server verbinden.
Besteht dieses Problem nur bei diesem einen Server, oder bei mehreren?

Wie kommst du da auf /15 oder /16.

Wenn ich mir das anschaue, wäre das eher /28
Der Bereich 192.168.0.192 - 192.168.0.207 wird durch 192.168.0.192/28 beschrieben, um hier mal ein konkretes Beispiel zu nennen.

/15 wäre eher 192.168.0.0 - 192.169.255.255
/16 wäre dann 192.168.0.0 - 192.168.255.255

Dazu bitte einmal die CIDR-Notation genauer betrachten, um die Definition besser verstehen zu können
Classless Inter-Domain Routing – Wikipedia

Dann will ich die Gesamtidee mal etwas genauer darlegen.

Das Projekt war als Blacklist-System geplant, welches vordergründig auf Websites ausgelegt war. Es sollten mehrere Merkmale unterstützt werden, die als Prüfmerkmale verwendbar sind.
Im Bereich Websites wären das:
1. die IP-Adresse
2. die Browser-Useragents
3. (unter Vorbehalt) die Referrer

Aufgrund dessen, dass bei dem Projekt, wo ich damals mitgearbeitet habe, gewisse Probleme aufgekommen sind, und unter anderem der Wunsch war, nicht alle Sperrmerkmale, sondern nur gewisse Merkmale einzusetzen, hätte das System vollkommen umgearbeitet worden.
Ebenfalls wurde überlegt, die Last auf mehrere Systeme zu verteilen, so dass die Datenbasis von mehreren Stellen abgefragt werden konnte.

Daraus entstanden war eine Idee bei mir, das ganze in der Form eine Remote Blacklist zu implementieren, wobei die Einträge jeweils mit einer TTL ausgeliefert werden, um gewisse Caching-Mechanismen nutzen zu können. Dabei war dann die Möglichkeit, die Datenbasis natürlich auch an anderer Stelle einsetzen zu können.
Aufgrund der Möglichkeiten, die entsprechenden Daten möglichst genau zu kategorisieren, kann man natürlich nur gewisse Teile des Datensatzes benutzen.
Einziges Problem daran wäre der Start, da das ganze auf User-Meldungen beruht, und somit zum Start die Datenbasis entsprechend klein ist. Somit müsste man bereits zum Start eine gewisse Nutzerbasis haben, um wenigstens einen Datenbestand zu generieren, der bereits gewisse Sicherheit bietet.

Ok, ich muss mich doch nochmal mit meinen Blacklist-Projekt beschäftigen.

Ich hatte früher mal mit einem Projekt experimentiert, dass einer RBL durchaus ähnlich ist, und genau solche Fälle abdecken könnte. Blocklisten mit entsprechender Kategorisierung, bei der der Nutzer die entsprechenden Kategorien wählen kann. Vielleicht war die Idee doch nicht so schlecht, wie sie mir damals vorgekommen ist.

Jo, wäre möglich.

In diesem Fall muss man sich den Bereich der "Grant-Rechte" anschauen. Diese beinhalten die Möglichkeit, Abstufungen im Bereich der Rechtevergabe realisieren zu können. Die entsprechenden Rechte müssen also über eine Grant-Power verfügen, die hoch genug für den Admin ist, bzw. die Grant-Power der Admin-Gruppe muss entsprechend hoch genug sein, damit dieser die Rechte vergeben, bzw. ändern darf.

In diesem Beispiel müssten also die entsprechenden Rechte mit einer etwas niedrigeren Grant-Power versehen werden, die geändert werden dürfen, und dann die entsprechende Grant-Power bei der Admin-Gruppe vergeben werden. Dann können noch immer alle Rechte durch den Server-Admin angepasst werden, ein Admin kann aber nur bestimmte Einstellungen ändern.

OK, theoretisieren wir einmal etwas.
Es gäbe verschiedene Möglichkeiten, dieses zu realisieren.

Eine Möglichkeit wäre ein Reverse-DNS-Check, da Server zumeist entweder eine generische Adresse zurück liefern, die auf ein Server-System schließen lassen, bzw. ggf. sogar eine normale Domain als Reverse-Eintrag zurück geben, da auf den Systemen Services einen entsprechenden Eintrag benötigen.
In diesem Fall kann man zwar nicht 100%ig davon ausgehen, dass es ein Server ist, die Chance ist aber groß.

Des weiteren könnte man über die Whois-Datenbank abfragen, wem die entsprechenden Adressen gehören, und sich daraus eine entsprechende Datenbank generieren. Sollte der Adressbereich also einen Hoster gehören, so ist hier ebenfalls die Chance groß, dass es ein Server sein kann.

Leute, echt mal. Von solchen Aussagen sollte man sich nicht verrückt machen lassen. Es gibt gute Einsatzzwecke für eine Firewall auf dem System selbst, auch wenn manch einer behaupten mag, dass dem nicht so ist.

Die Sicherheit von Services kann durch eine Firewall verbessert werden. Wenn ein Dienst von sich aus keine Unterstützung für einen "Slow-Mode", o.ä. bietet, kann man diesen mit einer Firewall nachrüsten. Sicherheitslücken in den Services selbst sind leider nicht so einfach abzusichern, aber das ist auch nicht der Sinn einer Firewall.

Um es einmal aus meiner Sicht zu sagen, benötige ich eine Firewall für die folgenden Funktionen:
1. logisches trennen von Netzwerken
2. sperren von Zugriffen auf Services von bestimmten Netzwerken, falls es die Software selbst nicht unterstützt
3. temporäre Sperrungen, bzw. implementieren eines "Slow-Modes", um gewisse Angriffsarten zu erschweren.

Im Optimalfall sollte man allerdings die Firewall auf einem anderen System betreiben als den Service selbst. Bei kleineren Hostern, bzw. privaten Entusiasten ist dies leider in den seltensten Fällen möglich. Daher ist es zwar nicht optimal, aber noch immer ein legitimer Teil eines Sicherheitskonzepts, Paketfilter auf den Applikationsservern zu implementieren.
Allerdings ist es nur ein Teil, und kann nicht als alleiniges Sicherheitsmerkmal eingesetzt werden.