DNS Webinterface +- Sponsor-Board.de (https://www.sponsor-board.de) +-- Forum: Webmaster (/forumdisplay.php?fid=44) +--- Forum: Projekt vorstellen (/forumdisplay.php?fid=36) +--- Thema: DNS Webinterface (/showthread.php?tid=39728) |
DNS Webinterface - DebianDEV - 12.06.2013 12:03 Hallo liebe Leser, ich würde euch gerne eine Projekt vorstellen, welches derzeit von mir programmiert wird. Wie bereits in der Überschrift erwähnt, handelt es sich hierbei um ein DNS Webinterface, welches folgende Aufgaben erledigen soll. Das Webinterface ist primär in 3 Benutzerstrukturen eingeteilt. Zum einen die Administrative Ebene, die Reseller Ebene und die Endkundenebene. Administrative Ebene:
Im Detail: * - Das bedeutet, dass die administrative Ebene Administratoren, Reseller und Benutzer anlegen, editieren und löschen kann. Hinzu kommt, dass sich jede Benutzerstruktur in die untergeordnete Benutzerstruktur einloggen kann (Administrator -> Reseller und Reseller -> Endkunde). Dies spart Zeit im Support des jeweiligen hilfebedürftigen Kunden. ** - Das Verwalten der Nameserver bedeutet, dass aus dem Interface heraus die Nameserver teilweise gesteuert werden können. Funktionen wie der Neustart einiger Dienste und des kompletten Servers soll hier realisiert werden können, sodass sich der Administrator nicht bei jeder kleinigkeit per SSH auf den Server einloggen muss. *** - Im Supportticketsystem können Supporttickets der Reseller an den Administrator gelesen und bearbeitet werden - Supporttickets von Kunden können via. "Anhang"-Funktion vom Reseller an den Administrator weitergesendet werden. Reseller Ebene
* - Im Supportticketsystem können Supporttickets der Endkunden des jeweiligen Resellers gelesen und bearbeitet werden - Supporttickets von Kunden können via. "Anhang"-Funktion vom Reseller an den Administrator weitergesendet werden. Endkunden Ebene
* - Das anlegen von Zonen beinhaltet ebenfalls das anlegen diverser Records (A, AAAA, MX, TXT uvm.) und natürlich auch das editieren dieser. Das löschen von Zonen (Domains) ist ebenso möglich. Technischer Background Die Technik, die hinter dem Webinterface arbeitet ist relativ simpel. Das Nameserver Webinterface kann auf einer beliebigen Linux Server oder Windows Server Distributionbetrieben werden und benötigt lediglich einen Webserver (z.B. Apache2 oder IIS) welches das "mod_rewrite" und "php5.X" Modul anbietet. Zudem benötigt man einen MySQL Server. Die Mindestsystemanforderungen betragen hierdurch in etwa 500 MHZ CPU Geschwindigkeit in Zusammenarbeit mit 512MB RAM und einer 5GB großen Festplatte. Mit dem Traffic sollte man auch nicht geizig sein. Aufgrund dessen, dass die Synchronisation via. Datenbankreplikation geschieht, wäre es sinnvoll 100GB - 300GB Traffic für das Webinterface einzuplanen. Ein virtuelles System ist hier dennoch vollkommend ausreichend. Als Nameserver sollte man, sofern man keine 5000 Domains von Anfang an hat, einen virtuellen Server nutzen. Das spart Kosten und wäre hier auch ausreichend. Ein virtueller CPU Core mit 512MB (Primärer Nameserver) beziehungsweise 256MB (sekundärer und tertiärer Nameserver) Ram sind ausreichend und sollten bis zu 5000 Zonen (Domains), je nach intensität der Records, aushalten. (Der primäre Nameserver sollte etwas mehr Ram besitzen, da hier die meißten Anfragen gesartet werden). Auch hier sind ca. 100GB - 300GB Traffic von nöten. Die Nameserver werden mit den Diensten PowerDNS, MySQL, SSH und der ACL betrieben. Optional kann man hier die Skripte zur Steuerung der Nameserver aus dem Webinterface heraus installieren - dies geschieht über ein Installationsskript, welches ich ebenfalls auf Bashbasis programmiert habe. Screenshots Screenshots sollten irrelevant sein, da Demodaten beiligen. Screenshots können jedoch auf Anfrage versendet werden. Verbesserungen, Anregung und sinvolle Ideen Sofern eurerseits Verbesserungen, Anregung und oder sinvolle Ideen eingebracht werden könnten, dann würde ich es sehr begrüßen, wenn ihr diese einbringt. [IDEEN] - API - API zu verschiedenen Domainregistrarstellen / Domainrobots - API zu div. Webinterfaces (WHCMS .. Teklab) für Rechnungsanbindung Sonstiges Derzeit geplant sind folgende Lizenzschemen:
++ Feedbacks erwünscht ([email protected]) ++ Resellerzugang: URL: [Link: Registrierung erforderlich] User: res1.test Passwort: testtest ++ Feedbacks erwünscht ([email protected]) ++ PS: Die Leistungsoptimierung des Interfaces wird noch vorgenommen! Herzlichste Grüße CreativeDEV [EDIT] Die Replikation der Datenbank ist nicht mehr ganz korrekt. Derzeit wird die Master / Slave Methode von PowerDNS benutzt. Dies rentiert sich aufgrund des verminderten Traffics (gut 27% weniger Traffic am Tag) RE: DNS Webinterface - netCiX - 12.06.2013 12:44 SQL-Injection ist problemlos möglich... Sehr unsicher.. RE: DNS Webinterface - DebianDEV - 12.06.2013 12:54 Da kannst du dir sicher sein, das wird in 5 Minuten nicht mehr möglich sein. Derzeit entwickle ich gleichzeit unter dieser Domain - da schleichen sich hier und da kleine unstimmigkeiten ein - in der Regel wird jeder Post durch ein Escape gejagt. LG RE: DNS Webinterface - netCiX - 12.06.2013 13:11 Nur escapen reicht aber heute nicht mehr! ;-) Werde nachher nochmal vorbei schauen und hoffen, dass es gefixt wurde. RE: DNS Webinterface - DebianDEV - 12.06.2013 13:17 Warum sollte das escapen von delimitern nicht ausreichen? -> Hier kommt es sehr stark drauf an, wie Programmiert wurde. Ich bin fest davon überzeugt, dass bei dem Projekt ein Escape ausreicht. Gerne lasse ich mich eines besseren belehren - dies bitte per PN oder Mail inkl. etwaiger Screens. Dankeschön =) RE: DNS Webinterface - alcazar - 12.06.2013 19:38 Werde es später ma ankucken. Aber im Bereich DB und Programmierung ist es immer am besten wenn man Stored Procedures oder Prepared Statements (also vorkompilierte Abfragen) verwendet und die Benutzereingaben als Parameter anhängt. Dadurch lassen sich Injections gut verhindern, kann aber leider nicht sagen ob und wie man das bei Scriptsprachen einsetzen kann. Bei echten Programmiersprachen bzw. DB-Sprachen geht das. RE: DNS Webinterface - DebianDEV - 13.06.2013 09:55 Hallo alcazar, Prepared Statements und Stored Procedures habe ich mir gerade einmal zu gemüte geführt. Den Einwand finde ich richtig gut und bei richtiger Anwendung kann ich mir hierdurch wohl einige Zeilen Code sparen. Danke für den Tipp @RedDust: Habe das gerade selber getestet und habe bemerkt was du meinst. Ich bin mir nur noch nicht 100% sicher ob es im umsetzbaren Bereich liegt. Ich bin mir durchaus bewusst, dass dies ein Punkt der Usability ist, nur wenn Javascript heruasgenommen wird, dann funktionieren eine Hand voll Funktionen und Features nicht mehr. Die Frage die sich hier stellt ist, baue ich einige Funktionen aus und nehme in Kauf das 10 von 100 000 000 Benutzer das Interface nicht benutzen kann oder lasse ich es drin uns schreibe es im Bereich "Voraussetzungen Endkundenbereich" mit hinein. Einiges kann man sicherlich auch in CSS3 Umsetzen, aber bei Datentabellen wird es schon schwerer. Vielleicht auch einmal eine Frage an die Allgemeinheit - wie sollte das Ganze am besten umgesetzt werden? Javascript inkludiert lassen oder lieber heruasnehmen und Alternativen inplementieren? RE: DNS Webinterface - master bratack - 13.06.2013 15:05 Das Interface ist löchrig wie schweizer Käse. Die Nutzereingaben werden nicht auf XSS untersucht - d.h. an einigen stellen persistente XSS möglich. "1 Interface (1 Server) = 449,99€" Du glaubst doch nicht wirklich, das jemand so viel Geld für n löchriges kleines Interface ausgibt, oder? RE: DNS Webinterface - NicoWDB - 13.06.2013 15:37 Das Design ist soweit ich sehe nicht selbst gemacht und von [Link: Registrierung erforderlich] Erstellt.Was für mich schon der Grund ist keine 450 Euro dafür zu zahlen. LG Nico RE: DNS Webinterface - DebianDEV - 13.06.2013 15:41 Hallo master bratack, zunächst danke ich auch dir für deinen Beitrag auch wenn du das wiederholst, was Vorredner bereits erwähnt haben. Nun gut - zunächst möchte ich XSS auflösen, damit dies jeder versteht. Beim XSS spricht man vom “Cross-Site-Scripting” was wiederrum unter anderem die MySQL Injektion beinhaltet. Das dies glücklicherweise ein Betatest ist, ist ja noch genug Zeit vorhanden, eben solche "Löcher", wie du sie so schön nennst, zu stopfen. Ich arbeite bereits lokal an einer weiterentwickelten Version, die eben diese "Löcher" stopf. Unter anderen mit validen Textfeldern die verhindern sollen, Eingaben zu tätigen, die dort schlichtweg nicht hineingehören. master bratack schrieb: "1 Interface (1 Server) = 449,99€" Du glaubst doch nicht wirklich, dass jemand so viel Geld für n löchriges kleines Interface ausgibt, oder?
master bratack schrieb: ... kleines Interface ...
|