Eigener Dynamischen DNS

[Thorsten]

MOD: Bitte keine Themen löschen, auf die bereits geantwortet wurde. Vielen Dank!

 

[ThomasChr]

Danke fürs wieder herzaubern des Themas, Thorsten!

Noch ne Kleinigkeit die ich gerne klarstellen möchte (ich lass mich aber auch gern korrigieren, sollte ich mich irren): Bei SSL Verbindungen werden auch die GET-Parameter (und die URL) verschlüsselt übertragen. Afaik ist das einzige was man mitsniffen kann die IP-Adresse von Client/Server.

 

[Whistler]

 zone "test.domain.de" {
    type master;
    file "/var/lib/bind/test.domain.de";
    allow-update {
        localhost; };

Du verwendest den Key gar nicht.
Entweder "allow-update { key test.domain.de; }" oder keinen Key verwenden.

 

[Joe User]

@Joe: Ich finde es etwas schade, dass du trotz gegenteiliger Aussagen ungeprüft an deiner Aussage festhältst. Das entwertet die Fälle in denen du Recht hast weil man dann nicht genau weiß, ob du es jetzt tatsächlich besser weißt oder nur gerade nicht zur Selbstkorrektur fähig bist. :-S

Keine Sorge, ich bin und war schon immer fähig eigene Fehler einzugestehen und mich auch entsprechend öffentlich zu äussern. Lässt sich durchaus mehrfach (nicht nur) in diesem Forum nachlesen


So ist es dann auch in diesem Fall, denn ich habe leider nur mit $_GET['ipv4'] gespielt und dummerweise den Anfängerfehler gemacht und alle $_GET an allen Positionen über den gleichen Kamm geschert. Betriebsblind, sorry.


Ändert aber Nix an den SQL-Injections und die Code-Injection mittels $_GET['ipv4'] nach dyndns.txt.

Und es ändert auch Nix daran, dass man Variablen nicht uninitialisiert verwendet und externen Input, insbesondere wenn er mittels $_(GET|POST|SERVER|ENV|COOKIE|WHATEVER) kommt, grundsätzlich niemals direkt und/oder ungeprüft verwendet.

 

[ThomasChr]

Ich gelobe ja Besserung.
Ist halt das übliche „ich mach mal nen Prototyp“ und wenns dann läuft spielt man nicht mehr dran rum.

Ich werd also zumindest nochmal in dem Beitrag (der schon älter ist) nachtragen, dass man:
1. Keinen DB User mit mehr Rechten nehmen sollte als nötig.
2. Alle Input-Parameter validieren sollte (in dem Fall würde ich wohl mit Regexp für die IP Adressen arbeiten.
3. Passwort und Usernamen sollte man mit "===" vergleichen um eine explizite Typprüfung dabei zu haben.
4. Selbstverständlich prepared SQL-Statements verwenden sollte.

Danke für die Hinweise. Ich sehe mein Blog zwar eher als interessante Tipps für Leute die wissen was sie tun und solche Dinge selber anpassen bevor sie Produktiv gehen, trotzdem sollte offensichtlich nicht ausreichend abgesicherter Code ohne deutliche Warnung nicht im Internet rum stehen. Schließlich wollen wir alle dass das Internet sicherer wird und unsere Server nicht ständig tausende Spam-Mails und Bruteforce Logins ertragen müssen!

Zurück zum Topic: Das mit dem Key klingt wie das Problem: Hats denn geholfen?

 

[DeaD_EyE]

Von einer Sprache ist zu erwarten, dass das die grundlegenden Datentypen sicher sind. Wenn zwei Strings auf Gleichheit überprüft werden, so darf niemals der Inhalt implizit interpretiert werden, da es ja sonst unbeabsichtigt zur Ausführung von fremden Code kommen könnte. Eine Sprache, die so eine Schwäche vorzuweisen hat, ist gänzlich ungeeignet Userinput zu laden, zu verarbeiten und auszugeben.
Zum Beispiel wäre schon das Escapen bereits die Verarbeitung der Daten. Also selbst Escapen wäre unmöglich sicher zu realisieren.

Wenn die Sprache so eine Schwäche hätte, dann wäre die Auswirkungen katastrophal.
So ein Szenario will man nicht, aber schön drüber geschrieben zu haben.

Ich fand die Diskussion sehr interessant. Für die Zukunft bitte solche Behauptungen nur mit Code belegen. In der IT gilt: Show me

Ich kenne das selbst, man lässt sich schnell zu solchen Aussagen verleiten...
Egal, dann hat man wenigstens noch etwas gelernt.


@Mod: Verschiebt doch mal bitte die "Sicherheits-Diskussion" in einen anderen Thread um diesen etwas aufzuräumen. Letztendlich möchte der OP ja noch nicht einmal das Script verwenden, sondern sein Problem mit dnssec gelöst haben.

 

[Thomas22]

Subdomain auf externe IP

Ich habe ein anderes Problem.
Es funktioniert einfach nicht eine Subdomain per A-Record auf eine externe IP (44.126.15.222) umzuleiten.
Die neue IP wird einfach nicht richtig aufgelößt, auch das warten von über 30 Stunden hat nichts weiter gebracht.

Hier mal mein Zonenfile: /var/lib/bind/domain.de

$ORIGIN .
$TTL 300
domain.de 	IN	SOA	ns1.nameserver.de. root.domain.de. (
			1620
			3600
			900
			2419200
			180 )

			NS	ns1.nameserver.de.
			NS	ns2.nameserver.de.

subdomain		A	44.126.15.222

Auch ein ping auf die subdomain.domain.de erbringt nur die Server IP.
An den Apache-Direktiven dürfte es doch eigentlich nicht liegen, oder ?
Komme leider nicht weiter, könnte mir jemand helfen.

Danke.

 

[danton]

Nutzt deine Domain überhaupt deinen Server als DNS-Server oder liegt die Domain immer noch auf den DNS-Servern deine Domain-Anbieters? Da wäre es jetzt natürlich schön, die richtige Domain zu kennen...

 

[Thomas22]

@danton
Danke für die Rückmeldung.

Ich habe zwei eigene DNS, diese sind laut Dig wohl auch richtig deklariert !?

> dig ANY @111.222.13.1 domain.de

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48650
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;domain.de. IN A


;; ANSWER SECTION:
domain.de. 180 IN SOA ns1.nameserver.de. root.domain.de. 1575 3600 300 2419200 180
domain.de. 180 IN NS ns1.nameserver.de.
domain.de. 180 IN NS ns2.nameserver.de.

;; Query time: 6 msec
;; SERVER: 178.254.13.7#53(178.254.13.7)
;; WHEN: Tue Jul 10 10:59:15 CEST 2018
;; MSG SIZE rcvd: 126

Nachtrag: Siehe Postfach


.

 

[danton]

Nur auf deinem Server, der deinen Nameserver abfragt. Andere fragen aber den Nameserver deines Anbieters ab, weil desse Nameserver bei der Denic eingetragen sind (siehe hierzu auch meine PM)