Spätestens hiermit hast du auch mich vollkommen abgehängt. Rein technisch ist eine Weiterleitung sehr wohl realisierbar, sogar mit Authentifizierung des Downloads.
Ich klink mich aus reinem Spaß an der Freude mal ein :
Soweit klar wird hast du irgendein File das auf irgendeinem Host liegt und willst zählen wie oft es von diesem Host geladen wird … wie wäre es dann mit einem One-Klick-Hoster der genau das für dich bereits macht ?
Anstatt Geld für die Hardware und vor allem den Strom rauszuwerfen und ziemlich konfuse Fragen zu stellen die selbst nach mehrfachem Nachfragen nicht viel klarer werden nimm dir entweder vorhandene Lösungen, oder wenns echt selbst sein muss irgendeinen Free-Hoster und schreib n kleines Proxy-Script in PHP : File wird angefordert > Counter in DB updaten > File streamen oder ne 302.
Auch finde ich die Idee recht daneben : “Meine Anwendung soll zählen wie oft sie geladen wird und dies einem Server mitteilen.”
Ich seh da leider mindestens 2 Probleme :
- Damit das überhaupt funzt muss dein Code auch ausgeführt werden > der reine Download kann hier schon mal nicht gezählt werden.
- Dein Code muss selbst klarkommen das wenn er das erste mal ausgeführt wurde sich dies merkt und nicht bei jedem Run ne Meldung an der Server gibt.
Ich glaube dir ist da schon ein Fehler in der Konzept-Planung deines “Download-Counters” unterlaufen … scnr
So sehe ich das auch, ein eigener Server ist mit sehr viel arbeit verbunden, mindestens hundert Seiten gute Literatur musst/müsstest du dafür lesen.
Zu Hause kommen dann noch mal ‚sensible‘ Daten ins Spiel im Worst case.
Also nur der Server weiß etwas, wenn du etwas runterlädst. Es gilt:
begonnener/angeforderter Downloads <= # erster Programmstarts
(wenn alles ‚normal‘ ist).
Solche Aufgabenstellungen sind predestiniert für PHP, und, ich will nicht lügen, es gibt Webhoster, die auch PHP (mit Funktionsumfang) anbieten. …
Nimm, wie Sen. sagt, einen File hoster - sicher, schnell, verfügbar, weitere Statistiken uvm. grüne energie. nachwachsen nachhaltig planet-gesund.
scnr 
Oh man, dumm von mir, >= muss dahin, ein Download wird häufiger angefordert als das Programm gestartet 1st Time. Aber beides lässt sich zählen heutzutage.
@CB
Naja, ist ja erstmal ziemlich egal ob die Anzahl der Downloads die der 1st-Time-Runs übersteigt oder umgekehrt, selbst beide Ergebnisse zusammen ergeben meist falsche Werte.
Warum ? Nun, ich denke da im ersten Moment erstmal an den Unterschied “Download-Anfrage” und “wirklich komplett runtergeladen”. Alleine zwischen diesen beiden States gibt es schon weitere die bei falscher Behandlung das Ergebnis verfälschen.
Weiter kommt mir Caching in den Sinn : Wenn die Infrastruktur zwischen Host und Client gut implementiert ist dürfte es nur sehr selten vom gleichen Client an den Server überhaupt eine Anfrage kommen ob das File in seinem Cache noch aktuell ist. Alle weiteren Anfragen sollte vom ISP und ggf vorhandenen Loadbalancer-Proxies übernommen werden. Ggf auch so dass der Browser erst gar keinen Request rausschickt (kann man glaub ich auch machen). Und nur wenn halt alle Instanzen feststellen : Timestamp abgelaufen > File wurde geändert - erst dann sollte wirklich ein Download-Request vom Client zum Host gelangen. Ergo : Alles was auf dem Weg zum Server schon abgefangen werden kann verfälscht das Download-Ergebnis.
Vielleicht könnte man noch in die Richtung 1st-Time-Run ausschlagen : Was passiert wenn ich zwar das Binary sichere, aber nach einem re-install keine Config mehr habe die Auskunft darüber gibt ob es wirklich ein 1st-Time-Run ist oder lediglich bloß das Fehler der Config ? Schon alleine aus diesem Grund würde zumindest für mich die Idee “Client soll dem Server sagen wie oft er geladen/ausgeführt wurde” so schnell wieder zerplatzen wie … weis gar nicht : wie kommt man überhaupt auf sowas ?
Einen wichtigen Punkt hast du aber angesprochen den sich TO noch mal zu Herzen nehmen sollte : Vorsicht mit privaten Daten im öffentlichen Netz !
@TO
Du sagst du hast Hardware die bei dir daheim im LAN läuft, vermutlich via Port-Forwarding oder DMZ. Ist dir denn auch die Gefahr bewusst dass ohne weitere Maßnahmen dieser lokal laufende Rechner recht einfach auf die privaten Daten deiner anderen System zugreifen kann ? Scheint mir nicht so.
Für einen halbwegs vernünftigen Aufbau sollte man mindestens 2 NAT-Router nutzen : der erste zieht den “Server” in eine DMZ und somit sämtliche Anfragen aus dem Netz auf diesen. Der zweite Router verhindert nun das der “Server” aus seiner DMZ so einfach ohne weiteres auf das eigentlich Heimnetz zugreifen kann. Umgekehrt (also aus dem geschützten inneren LAN auf die DMZ-Maschine zugreifen) geht jedoch weiterhin recht einfach.
Sehr viel sicherer wäre es natürlich wenn du für deinen Homeserver einen zweiten, vom privat-Anschluss unabhängigen, zusätzlichen Netzzugang hättest. So steht die Kiste zwar bei dir rum und verbraucht auch deinen Strom, aber man braucht keine Angst haben dass sich findige Hacker durch Ausnutzen von Sicherheitsbugs Zugriff auf den persönlichen Rechner verschaffen. Auch wenn dass im Umkehrschluss bedeutet dass man selbst nur noch “von außen” auf die Daten zugreifen kann.
Alles in allem recht schwieriges Thema für eine solche simple Aufgabe. Und nein : das war jetzt ganz sicher keine Ermutigung dass du dir bei nem Billig-Hoster ne Root-Maschine holen sollst. Denn die dürfte, mangels Fachwissen, sicherlich innerhalb von 24h oder weniger zumindest als SPAM-Relay und ggf Datentonne / Proxy missbraucht werden.
Ich weiß selber, dass ein angefragter/begonnener/kompletter Download etwas Anderes ist.
“Apache 4 Friends”, wenn man das selber machen möchte. Nat + Nat – da wird es kompliziert.
Was meinst du mit Relay? Einige Perlen sind dabei, das stimmt. Nimm die Sicherheit nicht auf die leichte Schulter.
Meine Empfehlung: Etwas wie einen Websitehoster nehmen, UUID in Java verwenden, dafür sind die da.
Klar, ist the Number of 1st Runs dann eventuell höher, aber das nimmst du dann einfach in Kauf für die grobe granulare schemahafte Skizze.
Also locker bleiben, noch ist noch nichts vorbei, afai©k/afaics.
Schönen Abend bei dir.
Was ich mit Relay meine ? Ist einfach erklärt : frag mal Google nach “open SMTP relay”.
Kurz : was machst du als erstes wenn du eine vermeintlich herrenlose Linux-Maschine im Netz findest ? Richtig : erstmal gucken was man so alles knacken kann.
Bei vielen dürfte man mit etwas spoofing schon mal den SMTP austricksen können - und schon man ein Spam-Relay ohne viel Mühe.
Entweder macht man sich dann die Mühe ne Lücke im MTA zu finden (leider meist recht einfach), oder man rückt gleich ne Nummer härter mit SSH und root an. Warum ? Weil doch leider zu viele Anfänger die simpelsten Sicherheitsregeln missachten.
Hier mal so meine kleine Liste was man machen sollte:
1.) alle Dienste die man nicht braucht abschalten
2.) Firewall/iptables (vorläufig) auf alles außer SSH blocken
3.) SSH absichern (Port ändern, root-Login abschalten, von Password-based auf Key-based umstellen, fail2ban)
4.) von den Diensten die dann von public erreichbar sind für sorgen das keine privaten Daten abgreifbar sind sowie Absicherung das nur authorisierte User was machen dürfen (siehe SMTP)
Ist ähnlich einfach wie damals zu Zeiten des TeamSpeak2 - man sucht sich aus der Liste einen beliebigen (meist französischen (warum ? keine ahnung - es war einfach populär und hat am einfachsten funktioniert)) Server und guckt ob ein Admin on ist. Wenn ja : Name als Passwort nehmen und versuchen am WebPanel anzumelden. Danach neuen SA anlegen und den Rest löschen. Zum Schluss drauf joinen und an alles und jeden einfach einen perma-Ban verteilen.
Bei vielen konnte man es dann sogar noch auf die Spitze treiben und sich als sog. super-Admin (SSA) mit den gleichen Login-Daten anmelden. So hatte man nicht nur einen TS2-Server, sondern gleich eine ganze Server-Instanz und konnte nach belieben an die Freunde was weiter verteilen. Geholfen hat in so einem full-takeover nur direktes Eingreifen über SSH vom Server-Admin.
Mit dem heutigen TS3 funkt das so leider nicht mehr. Schade eigentlich.
So, die beschrieben Punkte hab ich alle durchgeführt, aber ein open relay SMTP/MTA ‚hacken‘, kann ich nicht - aber ich hab mir vor einiger Zeit mal die Logs angeschaut - mit Erorrs und das ist das, was ich mit ‚einige Perlen‘ als E-MailAdressen meinte ==> <==.
Wie dem auch sei, das ist ein so ‚langes‘ Kapitel, dass MTA erst mal komplett deaktiviert ist. Logs unauffällig, keine neue super Benutzer usw.
(Dann muss man sich aber auch sorgen machen)
Trotzdem, im Netz steht, man könnte 1,5 Std. investieren, und ihn doch öffnen.
Hoffentlich nicht.
Jedenfalls, ein free Website hoster würde doch für den TO reichen.
[ot][quote=Sen-Mithrarin]Bei vielen dürfte man mit etwas spoofing schon mal den SMTP austricksen können - und schon man ein Spam-Relay ohne viel Mühe.[/quote]
Was willst du bitte spoofen, um den MTA „auszutricksen“?
Open Relays gehören übrigens weitestgehend der Vergangenheit an. Und die schlecht konfigurierten Server lassen sich dank Banlists nicht sehr lange missbrauchen.
An welche MTAs denkst du dabei?
Überflüssig, wenn du dein 1.) befolgt hast…
Port ändern ist kein Sicherheitsfeature, sondern erzeugt nur eine Scheinsicherheit…
Das ist illegal…[/ot]
Zum Spoof : normalerweise sollte ein SMTP-Server darauf achten dass ausgehende Mails nur von authorisierten Usern akzeptiert werden. Leider gibt es aber (immer noch) recht viele, ich sag mal “einfach gestrickte”, Server-Images, gerade im Umfeld von VPS und KVM, in denen zur Einfachheit und Bequemlichkeit solche Sicherheitsfeatures geschwächt oder komplett abgeschaltet sind. Meist bleibt noch ein Stück Logik vorhanden welches erfordert dass zumindest der Absender stimmen muss. Und basierend auf Unix ist es bei einigen dann so dass es zumindest einige hardcoded “User” gibt die immer als gültig akzeptiert werden da diese normalerweise eigentlich nur vom localhost (also der Maschine selbst) genutzt werden.
Schiebt man also einem solch geschwächten SMTP eine entsprechend manipulierte Mail unter wird diese als “normale” Mail verarbeitet, so dass man von einem System was jetzt nicht gerade ein Open-Relay ist doch weiterhin Spam rausschicken kann, und das sogar teilweise ohne auffällige Logs.
Lücken in MTA : jetzt nicht unbedingt direkt in postfix und sendmail selbst, aber in meist damit gekoppelten Systemen wie SpamAssasin, die man dazu bringen kann den “Text” der Mail als “Code” auszuführen, der dann mit den Rechte des Spam-Filters oder ggf. Mail-Servers (kommt drauf an ob als Chain oder getrennte Prozesse) läuft. Und von dort ist es dann “nur noch” eine privileg escalation entfernt.
- vs 2. - es gibt Dienste die “überlebenswichtig” sind damit ein OS läuft, die kann man halt leider nicht einfach abschalten. Und solche Dienste (unter Unix weniger, aber unter Windows sehr “beliebt”) laufen meist nicht nur mit erweiterten oder gar System-Rechten, sondern haben meist auch noch offene Ports über die man ohne Absicherung auch wieder Code einschleusen kann. Wie gesagt : ist unter Unix eher weniger das Problem, aber auf ner Windows-Kiste (und sei es auch eine “Server”-Version) ist doch ne ganze Menge offen was man nicht abschalten kann ohne dass das System selbst dadurch zusammenbricht.
Port-Änderung SSH : ist richtig - ist jetzt kein richtiger Sicherheitsgewinn, lässt aber viele Script-Kiddies schon mal dran verzweifeln sich nicht an TCP/22 connecten zu können. Also brauchts einen Port-Scanner. Und dabei gleich die nächste Lücke : wenn jemand einfach mal so über eine Ports rennen kann ohne dass dies irgendwelche Konsequenzen hat bin ich von einem Angriff nicht weit entfernt. Also soll halt nur darauf zugegriffen werden können dessen Ports bekannt sind. Sowas lässt sich dann mit einfach Tools erkennen und nach 5-10 Ports blockieren. Es ist also schon mal deutlich aufwändiger einen laufenden Dienst zu finden den man möglicherweise Angreifen kann wenn man bei der Suche danach behindert, oder besser gleich komplett dauerhaft gehindert wird. Extra noch über mehrere Proxies gehen oder sich mehrere IPs zu besorgen nur um den SSH-Port zu finden dürfte zwar für viele Hacker kein Problem sein, aber dennoch so zeitaufwändig dass es sich für viele eher lohnen dürfte nach einem nächste Ziel zu suchen welches nicht so abgesichert ist. Ich spekuliere also darauf den Aufwand eine Angriffsmöglichkeit so zu erhöhen dass diese in keinem sinnvollen Verhältnis mehr zum eigentlich Nutzen steht (bzw. zur Schwierigkeit die Lücke dann auszunutzen).
Gleiches gilt übrigens für sehr viele Bereich der Kryptographie : es geht nicht darum die Daten selbst extrem zu sichern, sondern meist darum den Aufwand diese zu knacken extrem zu erhöhen.
Bzgl. des letzten Punktes : ich bin kein Rechtsexperte, und kann mir trotzdem vorstellen das es gewisse Strafen nach sich ziehen KANN, aber da beim Beschrieben keine Softwarefehler missbraucht wurden (bzw. bewusst versucht wurde in das System ohne gültige Zugangsdaten einzudringen) sondern lediglich die “Unfähigkeit” mancher “höher gestellter User” dazu führte sich “aus bekannter Gewohnheit” diese korrekt abzuleiten dürfte es schwierig werden vom simplen “tja, dumm gelaufen” in die strafrechtliche Verfolgung zu springen.
Ist reine Bequemlichkeit - natürlich ist gegen einen einfachen Portscan erst mal kein Kraut gewachsen, die Änderung des SSH-Ports bringt eigentlich gar nichts.
Ich mach das trotzdem immer als erstes, weil dann die Logfiles nicht ganz so deprimierend sind. Es einfach besser, wenn im Log nur „relevante“ Logins sind anstatt tausender gescheiterter Versuche über ssh.
Wäre gut, wenn das bei euch so aussehen würde:
PORT STATE SERVICE
21/tcp closed ftp
22/tcp closed ssh
23/tcp closed telnet
25/tcp closed smtp
80/tcp closed http
110/tcp closed pop3
143/tcp closed imap
179/tcp closed bgp
443/tcp closed https
465/tcp closed smtps
993/tcp closed imaps
995/tcp closed pop3s
1433/tcp closed ms-sql-s
1720/tcp closed H.323/Q.931
1723/tcp closed pptp
3306/tcp closed mysql
3389/tcp closed ms-wbt-server
5060/tcp closed sip
5900/tcp closed vnc
8000/tcp closed http-alt
8080/tcp closed http-proxy
8443/tcp closed https-alt
udp ist natürlich auch ein Problem.
Ansonsten wirklich Wikipedia.
@Bleiglanz
Doch : in dem man beim 5 Port sämtliche Anfragen von dieser IP schlicht komplett ins Leere (/dev/null) laufen lässt … somit verhindert man schon ziemlich gut einen Port-Scan da der “Angreifer” dann einfach gar keine Antwort mehr bekommt.
@CB
Hmm, “sollte” ist gut, aber praktisch nicht umsetzbar, weil:
TCP/25 - SMTP - wenn man Mails von anderen MTAs empfangen will muss man leider SMTP auf diesem Standard-Port laufen lassen, da führt leider kein Weg dran vorbei (es sei es gibt neuerdings die Möglichkeit via DNS-Auflösung einem fremden MTA einen abweichenden Port mitzuteilen).
TCP/80 - HTTP - klar, kann man ändern, und mit DNS und einem passenden Resolver auch wirklich umsetzen dass ein Browser bei “byte-welt.de” dann auch wirklich an “http://forum.byte-welt.net:XXX” connected - ist aber, da man nicht sicher stellen kann dass auch wirklich von jedem unterstützt, eher eine proof-of-concept-mäßige Ausnahme
TCP/443 - siehe vorherigen Punkt
alle anderen Ports kann man schon ändern (z.B. Mail-Ports - lassen sich eigentlich in jedem Mail-Client anpassen), einige von dir genannten kenn ich gar nicht und bei anderen wie 3306 denk ich mir : wer sowas open lässt hat entweder Gründe dafür oder ist einfach nur unfähig.
Man kann den smtp-Port mit iptables schließen, so als wäre da gar kein Dienst, ist aber nicht ganz so einfach - was dann zur Folge hat, dass zwar Mails verschickt werden können (an die eigene E-Mail), aber keine empfangen. 
Es gibt online Tools, die eventuelle Server auf Schwachstellen überprüfen können.
Alles sehr vage, i know.
Das war ja meine Aussage: willst du Mails empfangen muss TCP/25 offen sein mit einem passenden Dienst dahinter.