Hi, ich beschäftige mich seit kurzem etwas intensiver mit Netzwerkprotokollen. In zwischen bin ich soweit das ich einen kleinen HTTP Server programmiert habe und der im lokalen Netzwerk 1A läuft. Der Client stellt seine Anfrage mit: GET / HTTP/1.1 Host: 192.168.178.25 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:37.0) Accept: text/html Accept-Language: de Accept-Encoding: gzip, deflate DNT: 1 Connection: keep-alive Bekommt darauf hin eine Antwort mit der index.htm. Alles soweit ok. Nun habe ich über eine Dynamische IP Anmeldung den kleinen Webserver an das Internet durch meinen Router angebunden. Portfreigabe im Router ist Port 80 auf die IP von dem Webserver. Nun kommt es gelegentlich dazu das von draußen Verbindungen aufgebaut werden und KEINE richtigen GET Anfragen enthalten sondern lediglich irgendwelche Zeichen zwischen 12 und 25 Byte. Diese werden nie mit dem CRLFCRLF abgeschlossen sondern die Verbindung bleibt einfach im Leerlauf bestehen. Was ist das, wie behandelt man so etwas am besten? Grüße AVRli...
AVRli ... schrieb: > Was ist das, wie behandelt man so etwas am besten? einen Timeout festlegen. bzw. 2 Timeouts. Einen Timeout bis eine gültige anfrage kommt und einen timeout wie lange zwischen 2 Bytes vergehen dürfen. Wenn der/dir Timeout zuschlagen, einfach die Verbindung beenden.
> Was ist das, wie behandelt man so etwas am besten?
Das ist die Realität im Internet. Mach dich drauf gefasst, das solche
Anfagen immer mehr werden, je länger der Server im Netz hängt.
Bei mir ist es mal so schlimm geworden, dass mein DSL Anschluss
zeitweise nicht mehr zu gebrauchen war.
Kleiner Tip: Mikrocontroller gehören nicht direkt ans Internet
Angeschlossen. Da gehört mindestens eine Firewall vorgeschaltet, die
unerwünschte und fehlerhafte Requests raus filtert und DOS Angriffe
verhindert. Für private Zwecke bieten sich auch VPN Tunnel an.
AVRli ... schrieb: > Was ist das, wie behandelt man so etwas am besten? 1. Mit Wireshark die Netzwerkpakete analysieren. 2. Ist Connection: close im reply? LG, Sebastian
Stefan Us schrieb: > Kleiner Tip: Mikrocontroller gehören nicht direkt ans Internet > Angeschlossen. Nein, Protokollimplementierungen sollten robust genug sein, dass sie den Unsinn ordentlich verwerfen.
> Was ist das, wie behandelt man so etwas am besten?
Ist das ein Webserver?
Wohl ja ....
Ein solcher Webserver beantwortet alle Zugriffe, in der Regel, mit einem
HTTP Statuscode.
Status 400 (oder 408) bietet sich in deinem Fall an.
Ulrich F. schrieb: > Wohl ja .... > Ein solcher Webserver beantwortet alle Zugriffe, in der Regel, mit einem > HTTP Statuscode. > Status 400 (oder 408) bietet sich in deinem Fall an. aber nur wenn eine sinnvoll anfrage kam, und das ist hier noch nicht der fall gewesen.
Danke für die schnellen Antworten, Vielleicht mache ich auch noch was falsch. Ich lese derzeit die Clientanfrage Zeilenweise ein bis ein CRLFCRLF kommt. Das einizige was ich mir genauer ansehe ist die GET Zeile, also welche Datei angefordert wird. Wenn nun die wirren Zeichen kommen, regiert mein Server nicht weil das CRLFCRLF fehlt. Die Verbindung besteht und nichts passiert mehr. Ein Timeout wäre noch ein Ansatz, was ich auch noch nachvollziehen könnte: ein Filter auf gültige Zeichen nur welche sind das? Ich habe versucht in den RFC's was zu finden doch die Infos sind unüberschaubar viel. Dann wäre es super den Client "verhungern" zu lassen also garnicht mehr zu antworten, nur geht das überhaupt? Das es sich eventuell um Angriffe handelt hätte ich nun nicht erwartet aber das wäre mir dann schon wichtig das die vernünftig abgehandelt werden. Eine weitere Firewall würde ich nun nicht so prima finden. Ich frage mich auch die ganze Zeit wie groß das Risiko eines µC's am Internet so ist. Grüße AVRli...
Folgendes: Jede Anfrage beginnt IMMER mit einer Anfragemethode( http://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP-Anfragemethoden ). Wenn ich mich richtig erinnere, muss ein Webserver nur GET implementieren. Wenn also die ersten drei Zeichen nicht GET sind, könnte man mit einem 501 antworten. (Wenn der Webserver mehr kann muss man natürlich auch mehr abfragen)
AVRli ... schrieb: > Ein Timeout wäre noch ein Ansatz, was ich auch noch nachvollziehen > könnte: ein Filter auf gültige Zeichen nur welche sind das? Ich habe > versucht in den RFC's was zu finden doch die Infos sind unüberschaubar > viel. und was ist wenn gar kein Zeichen kommt? Du brauchst zwingend einen Timeout. Sonst schickt dir jemand ein paar hundert Verbindungen ohne Daten und das wars dann für deinen Server.
Jay schrieb: > Wenn also die ersten drei Zeichen nicht GET sind, könnte > man mit einem 501 antworten. und wenn gar kein Zeichen kommt? Oder nur ein "G" ?
Peter II schrieb: > aber nur wenn eine sinnvoll anfrage kam, und das ist hier noch nicht der > fall gewesen. Genau deswegen, wegen den nicht sinnvoll interpretierbaren Anfragen, wurde dieses erfunden: > 400 Bad Request Die Anfrage-Nachricht war fehlerhaft aufgebaut. Teste deinen Apache, wie der reagiert... Zum Sicherheitsaspekt: Wenn über Port 80 zu dem Webserver eine Verbindung aufgebaut wurde, weiß der "Gegner" doch sowieso schon, dass da ein Server hinter steckt. Es gibt also wirklich wenig Grund, nicht angemessen zu reagieren.
Ulrich F. schrieb: > Genau deswegen, wegen den nicht sinnvoll interpretierbaren Anfragen, > wurde dieses erfunden: und wann soll er die schicken? Was ist wenn eine Verbindung ankommt und ein nur "G" drin steht?
Jay schrieb: > Wenn also die ersten drei Zeichen nicht GET sind, könnte > man mit einem 501 antworten. Ja auch nicht schlecht, wenn GET immer das erste sein muss. Peter II schrieb: > und was ist wenn gar kein Zeichen kommt? Ja hab ich übersehen, logisch dann ist die Verbindung da und nichts geht mehr... :-( Mit ws sich die Leute so befassen (Angreifer, Spinner im Netz), ist echt nicht zu fassen. Da freu ich mich über die neuen Möglichkeiten und dann so ein Quatsch. :-( Grüße AVRli...
Das sind ganz normale Portscans. Das passiert ständig. Ist nicht schlimm und bedeutet auch nicht, dass Dir irgendjemand was Böses will. Da ist halt jemand ein wenig neugierig.
Peter II schrieb: > Ulrich F. schrieb: >> Genau deswegen, wegen den nicht sinnvoll interpretierbaren Anfragen, >> wurde dieses erfunden: > > und wann soll er die schicken? Was ist wenn eine Verbindung ankommt und > ein nur "G" drin steht? Ein einzelnes G wird keinem Webserver reichen! Also einen Status 400 und Verbindung.close() Mein Vorschlag: Einen Endlichen Automaten auf den Datenstrom ansetzen. Wenn er es Interpretiert bekommt, einen positiv bestätigenden Status Code senden, und wenn der Interpreter den Request nicht versteht, einen ablehnenden Code. Ausgestattet, mit einem Timeout ist das eine runde Sache, welche den Gepflogenheiten im Webserverumfeld gerecht wird.
AVRli ... schrieb: > Dann wäre es super den Client "verhungern" zu lassen also garnicht mehr > zu antworten, nur geht das überhaupt? Klar geht das. Für die angefrühstückte HTTP-Verbindung musst du aber auf Serverseite Ressourcen belegen, um die TCP-Verbindung offen zu halten. Timeout, danach Pumpe.
Jörg Wunsch schrieb: > Klar geht das. Für die angefrühstückte HTTP-Verbindung musst du aber > auf Serverseite Ressourcen belegen, um die TCP-Verbindung offen zu > halten. Er kann einfach den Socket schließen ohne vorher shutdown() zu machen, dann bemerkt die Gegenseite nichts aber der Socket ist trotzdem weg.
Klar ist eine sauberes Frage/Antwort Spiel die feinere Art, doch wenn mich einer anpöpelt, und so sehe ich ein sinnloses "probieren" auf Port X an IP Z an, mag ich mich mit dem nicht unterhalten. Gut er weiß es kommt eine Verbindung auf Port 80 an IP X zustande nur wenn nix zurück kommt hat er sich das verdient... Oder wäre die ERROR 400 Status eine sauberere Sache für alle beteiligte im Netz weil unnötiger Traffic vermieden würde? Ich werde mal eine Nacht mit dem Timeout probieren. Mal schauen ob das geht. Ich bin noch nicht ganz darüber hinweg mit was man sich so alles auseinandersetzen muß... ;-) Ich renne doch auch nicht die Straße entlang und schauen an jedem Auto ob die Tür auf ist... Grüße AVRli...
AVRli ... schrieb: > Ich frage mich auch die ganze Zeit wie groß das Risiko eines µC's am > Internet so ist. Steuert das Teil ein AKW oder sind personenbezogende Daten drauf?
AVRli ... schrieb: > Ich lese derzeit die Clientanfrage Zeilenweise ein bis ein CRLFCRLF > kommt. Das einizige was ich mir genauer ansehe ist die GET Zeile, also > welche Datei angefordert wird. Cool, was passiert wenn ich dir überlange Zeilen schicke?
AVRli ... schrieb: > Oder wäre die ERROR 400 Status eine sauberere Sache Brauchst du nicht. Einfach dicht machen nach XX Sekunden, macht jeder andere Webserver auch so.
paele schrieb: > Steuert das Teil ein AKW oder sind personenbezogende Daten drauf? Och ich möchte einfach nicht das die eigentliche Funktion, Anbindung ans Netz, durch Spielerei ausgehebelt werden kann. paele schrieb: > Cool, was passiert wenn ich dir überlange Zeilen schicke? Mehr als 80 Zeichen pro Zeile interessieren nicht. Dann ignoriert er alles weitere bis zum CR. Jörg Wunsch schrieb: > Brauchst du nicht. Einfach dicht machen nach XX Sekunden, macht > jeder andere Webserver auch so. OK Danke, ich baue das mal ein und schaue was heute Nacht passiert. Grüße AVRli...
Jörg Wunsch schrieb: > Stefan Us schrieb: >> Kleiner Tip: Mikrocontroller gehören nicht direkt ans Internet >> Angeschlossen. > > Nein, Protokollimplementierungen sollten robust genug sein, dass sie > den Unsinn ordentlich verwerfen. Es ist selbst bei ganz großen Servern der Standardfall, daß der Server nicht direkt am Internet hängt. Warum sollte man das ausgerechnet bei einem µC anders handhaben? Ulrich F. schrieb: >> und wann soll er die schicken? Was ist wenn eine Verbindung ankommt und >> ein nur "G" drin steht? > > Ein einzelnes G wird keinem Webserver reichen! > Also einen Status 400 und Verbindung.close() Und woher weißt der Server, daß nicht kurz danach noch der Rest kommt? Das G ist ja erstmal nicht falsch, sondern nur (noch) unvollständig. > Ausgestattet, mit einem Timeout ist das eine runde Sache, welche den > Gepflogenheiten im Webserverumfeld gerecht wird. Eben, den Timeout braucht man auf jeden Fall. Jörg Wunsch schrieb: > AVRli ... schrieb: >> Dann wäre es super den Client "verhungern" zu lassen also garnicht mehr >> zu antworten, nur geht das überhaupt? > > Klar geht das. Für die angefrühstückte HTTP-Verbindung musst du aber > auf Serverseite Ressourcen belegen, um die TCP-Verbindung offen zu > halten. Warum? "Verhungern lassen" heißt für mich, daß der Server einfach stillschweigend die Verbindung bei sich löscht, aber keinerlei Pakete mehr zurückschickt.
Jörg Wunsch schrieb: > Klar geht das. Für die angefrühstückte HTTP-Verbindung musst du aber > auf Serverseite Ressourcen belegen, um die TCP-Verbindung offen zu > halten. So in etwa 65535 Sockets auf einem uC offen halten, wird schwierig. Da ja auch auf der Firewall müssen diese Verbindungen in der NAT Table gehalten werden. Das macht so manches Homeuser Gerät nicht mit. Somit kommen die anderen Geräte auch nicht mehr ins Internet. -> DOS Angriff erfolgreich. Bernd K. schrieb: > Er kann einfach den Socket schließen ohne vorher shutdown() zu machen, > dann bemerkt die Gegenseite nichts aber der Socket ist trotzdem weg. Und auch sie Firewall bemerkt davon nichts. Auswirkungen wie oben. Ergo alle Requests sauber mit einer Fehlermeldung beantworten und TCP Session mit RST beenden.
guest schrieb: > Ergo alle Requests sauber mit einer Fehlermeldung beantworten und TCP > Session mit RST beenden. Stimmt, an NAT-Router und dergleichen hab ich dabei nicht gedacht. Also shutdown() und close(). Aber für einen HTTP-Statuscode ist kein Platz wenn der HTTP-Handshake noch nicht an der Stelle war an der überhaupt der Statuscode hingehört, den würde dann eh niemand lesen oder parsen weil unerwartet und falsch plaziert. Also einfach RST und schließen, das ist Antwort genug.
Rolf Magnus schrieb: > Es ist selbst bei ganz großen Servern der Standardfall, daß der Server > nicht direkt am Internet hängt. Aber eher zur Lastverteilung. Ansonsten lässt der Firewall einen aufgebauten TCP-Stream zum Server durch. Klar könnte man nun auch noch auf dem Firewall anfangen, die HTTP-Requests zu tracken und erstmal gegenüber dem Server zurückzuhalten, aber spätestens bei HTTP/S wäre dann Schluss mit lustig, es sei denn, du willst dem Firewall auch noch die Zertifikate anvertrauen. Dann muss es doch wieder der Server sauber machen (und macht er ja auch). Für eine ordentlich aufgesetzte Kiste braucht man eigentlich keinen Firewall. Das Risiko, dass die Firewallsoftware Bugs hat, ist kaum geringer als das Risiko, dass die HTTP-Server-Software welche hat.
> Das Risiko, dass die Firewallsoftware Bugs hat, ist kaum > geringer als das Risiko, dass die HTTP-Server-Software welche hat. Erzähl das mal Leuten, die PHP und Java Webserver Anwendungen betreiben. Dir ist wohl nicht klar, dass Geschäftsanwendungen in aller Regel 100x schlampiger entwickelt werden, als so Sachen wie der Apache HTTP Server. Wenn Zeit und Geld minimiert werden, gleichzeitig aber die Anforderungen maximiert werden, kann keine Sichere Software entstehen. Und genau dieses Szenario ist in vielen Bereichen der Regelfall.
Stefan Us schrieb: >> Das Risiko, dass die Firewallsoftware Bugs hat, ist kaum >> geringer als das Risiko, dass die HTTP-Server-Software welche hat. > > Erzähl das mal Leuten, die PHP und Java Webserver Anwendungen betreiben. Ja und was hat das eine mit dem anderen zu tun?
Bernd K. schrieb: > Ja und was hat das eine mit dem anderen zu tun? Dass eine Firewall eben nicht nur aus einem simplen Paketfilter besteht, sondern eben auch in den höheren OSI Schichten agiert und entsprechend schädliche Anfragen auf die Webserver erkennen und blockieren kann.
guest schrieb: > Dass eine Firewall eben nicht nur aus einem simplen Paketfilter besteht, > sondern eben auch in den höheren OSI Schichten agiert und entsprechend > schädliche Anfragen auf die Webserver erkennen und blockieren kann. soweit die Theorie. Das dumme daran ist, das die Firewall damit genauso anfällig wird wie der Webserver weil sie die Protokolle fehlerfrei Parsen muss. Damit hat man also 2 Geräte die angreifbar sind.
Ich danke allen für ihre Beiträge, es ist wirklich ein nicht zu unterschätzendes Thema. Da freut man sich seinen kleinen ATmega am Internet zu haben und dann wird die Sache schnell kritisch... Ich habe die letzten "Anfragen" ausführlicher mit geloggt... ganz so wirr waren sie dann doch nicht! Es wurden unter anderen PUT, POST, DELETE, HEAD und CONNECT Anfragen gesendet. Einige kamen auch nur mit binären Zeichen also nicht lesbar... Der ATmega macht hier "nur" GET mehr nicht. Ich habe nun den folgenden Ansatz verfolgt. Ulrich F. schrieb: > Einen Endlichen Automaten auf den Datenstrom ansetzen. > Wenn er es Interpretiert bekommt, einen positiv bestätigenden Status > Code senden, und wenn der Interpreter den Request nicht versteht, > einen ablehnenden Code. > Ausgestattet, mit einem Timeout ist das eine runde Sache, welche den > Gepflogenheiten im Webserverumfeld gerecht wird. Positiv ist 200. Wenn ein Kommando <> GET kommt wird es ein 400. Ebenso wenn keine oder wirre Zeichen kommen und damit der Timeout zuschlägt, kommt nun auch 400. Jeweils mit abschließenden Disconnect(); vom Server. Nun lasse ich das mal am Netz laufen, die erste Nacht lief ausgezeichnet. 18 Verbindungen von irgendwelchen Schlauen wurden alle ordentlich behandelt mit dem 400 beendet. Dann lief der Server wieder. War heute morgen also sofort erreichbar. Man hat nun sicher noch nicht an alles gedacht aber auf jeden Fall bleibt eine unnötige Verbindung nun nicht mehr hängen. Grüße AVRli...
AVRli ... schrieb: > Der ATmega macht hier "nur" GET mehr nicht. HEAD ist auch verpflichtend, und sollte kein Problem sein zu implementieren. Ist ja letztlich das gleiche wie GET, nur dass eben nur die Response headers aber kein body gesendet werden. Alle anderen Methoden solltest du mit einem 501 (Not implemented) beantworten, wenn der Request an sich korrekt ist (also kein Schrott). Zumindest sagt RFC7231 das so.
Jörg Wunsch schrieb: > HEAD ist auch verpflichtend OK, danke für den Hinweis, habe ich nun mit drin, springt auch in die gleiche Ausgabe aber eben nur mit Content wenn es GET war. > ...nur die Response headers... Welche dieser Header sind eigentlich ZWINGEND erforderlich? Man kann viel schicken wenn der Tag lang ist aber was braucht man wirklich? > Alle anderen Methoden solltest du mit einem 501 (Not implemented) > beantworten, wenn der Request an sich korrekt ist OK, dann baue ich nochmal um... dann nur noch BAD REQUEST wenn der Timout zu schlägt... obwohl 501 ja auch "passen" würde, denn Quatsch in Form von X nicht Klartext Charakter ja auch "nicht implementiert ist". > Zumindest sagt RFC7231 das so. Ja mit den den RFC's ist es für mich schwer :-( das HTTP Protokoll ist ein gutes Beispiel, da sind alle Sachen mit drin die vlt ein "echter" Server braucht, da das zu filtern was hier auf dem kleinen ATMEGA nun gerade wirklich wichtig ist, fällt mir schwer. Eine schönen Wochenstart, Gruß AVRli...
AVRli ... schrieb: >> ...nur die Response headers... > > Welche dieser Header sind eigentlich ZWINGEND erforderlich? Eine geschlossene Beschreibung dafür finde ich auch nicht. Ein "Content-Type"-Header "SHOULD (be) include(d)", sofern die Antwort Inhalt enthält. "Content-Encoding" muss unter bestimmten Umständen dabei sein, nämlich dann, wenn das Encoding der Antwort nicht exakt dem des Requests entspricht. "Date" "MUST (be) include(d)", sofern der Server eine Uhr hat. Hat er keine, dann ist er verpflichtet, kein Date zu senden, darf dann aber kein "Last-Modified" oder "Expires" senden. Keine Regel ohne Ausnahme :), es darf optional ein "Expires" gesendet werden mit einem Zeitstempel, der zum Zeitpunkt der Konfiguration des Servers oder zuvor liegt, um auf diese Weise den Inhalt als dauerhaft out of date zu markieren (darf nicht gecachet werden). "Content-Length" könnte noch sinnvoll sein. Wenn es vorhanden ist, soll der Client es benutzen, sonst muss er selbst versuchen, die Länge zu ermitteln. > OK, dann baue ich nochmal um... dann nur noch BAD REQUEST wenn der > Timout zu schlägt... Wenn der Timeout zuschlägt, ohne dass du einen gültigen Request gesehen hast, kannst du einfach kommentarlos dicht machen. Macht ein Apache auch so. 501 ist nur dafür da, dass du zumindest etwas bekommen hast, was syntaktisch wie ein HTTP request aussieht.
Jörg Wunsch schrieb...
> Eine geschlossene Beschreibung dafür finde ich auch nicht.
Entschuldige die späte Antwort, war "außer Gefecht".
Danke Dir für die ausführliche Darstellung. In der Tat kann ich damit
nun was anfangen. Ich habe den kleinen Webserver nun erweitert das er
HEAD und GET Anfragen beantwortet, sinnlose Sachen ignoriert und bei
nicht gefundenen Dateien mit 404 antwortet.
Die "Angriffe" sind weniger geworden und vor allem läuft der Server nun
durch! Was ich ich noch immer frage ist ob es zufällige oder gezielte
Anfragen sind. Aber das wird so einfach nicht zu klären sein.
Manchmal ist ein Muster zu erkennen, erst sieht man das nur kurz eine
Verbindung aufgebaut wird und dann fliegt die gleiche (IP) mit einem
GET, CONNECT oder was weiß ich rein.
Der Server soll soll ja aus dem Netz erreichbar sein, doch zum anderen
keine Spielwiese werden.
Grüße AVRli...
AVRli ... schrieb: > Der Server soll soll ja aus dem Netz erreichbar sein, doch zum anderen > keine Spielwiese werden. Das erreicht man dadurch daß man so wenig wie möglich Spielzeug dort hinlegt. Und grundsäzlich überhaupt nur Spielzeug aus Stahlbeton mit solidem Fundament und ohne bewegliche Teile ;-)
Du darfst die ganzen robots der suchmaschinen nicht vergessen, die scannen auch ständig das ganze nets. Da muss slso nicht msl jemand mit bösen absichten dahinter stecken. Gruß j
jonasbiensack schrieb: > Du darfst die ganzen robots der suchmaschinen nicht vergessen, die > scannen auch ständig das ganze nets. Die schicken allerdings saubere Anfragen, nicht irgendwelchen Müll. Insbesondere fragen alle ordentlich implementierten Suchmaschinen zuerst nach einem Dokument namens "/robots.txt". Wenn man keine Suchmaschinen haben möchte, sollte man darauf diese Antwort geben:
1 | User-agent: * |
2 | Disallow: / |
Ich habe mal eine Zeit lang ein Raspberry als Server auf Port 80 laufen lassen. Nach nur wenigen Stunden waren im log sehr seltsame Anfragen. Das meiste davon verstümmelte Zeichenketten, viele nichtdarstellbare Zeichen. Sah für mich aus wie der Versuch Bugs auszunutzen oder overflows zu erzeugen. Auch gab es viele Anfragen nach diversen Konfigurationsseiten, z.b. phpMyAdmin.php oder ähnliches. Auch das sah nach dem Versuch aus, das System anzugreifen. Ich hab auch mal ein µC mit Ethernetadapter ans Netz gehanden, welcher eingehende UDP-Packete auf einem LCD darstellen sollte. Schon nach kurzer Zeit kam wieder dieser Datenmüll. Damit muss man leider rechnen.
IUnknown schrieb: > Auch das sah > nach dem Versuch aus, das System anzugreifen. Ich hab auch mal ein µC > mit Ethernetadapter ans Netz gehanden, welcher eingehende UDP-Packete > auf einem LCD darstellen sollte. Schon nach kurzer Zeit kam wieder > dieser Datenmüll. Damit muss man leider rechnen. Tja das ist so eine Sache das zu beurteilen. Ist halt die Frage was für einen Port du gewählt hast. Ist eigentlich ganz logisch, dass es da ziemlich zugeht, so ungefiltert da kommt dir ja jeder Broadcast durch. Und der haut dir wahrscheinlich alles zusammen weil dein UDP RX Buffer keine 100 Bytes groß ist ... IUnknown schrieb: > Ich habe mal eine Zeit lang ein Raspberry als Server auf Port 80 laufen > lassen. Nach nur wenigen Stunden waren im log sehr seltsame Anfragen. Naja auf Port 80 ist das doch auch nicht wirklich ein Wunder oder? Stichwort Suchmaschinen z.B ?!
Jörg Wunsch schrieb: > Wenn man keine Suchmaschinen haben möchte, sollte man > darauf diese Antwort geben: > User-agent: * > Disallow: / Danke, habe ich sofort hinzugefügt! Obwohl ich noch nicht eine Robot.txt Abfrage hatte. @ IUnknown Genau dieses Szenario hat den ATMEGA bei meiner ersten Implementierung so ziemlich durcheinander gebracht. Dank der User Antworten hier im Beitrag, besonders Ulrich F. und Jörg Wunsch ist es hier nun sehr ruhig geworden. "ms*an" schaut ab und zu noch vorbei, das lässt sich nicht vermeiden aber die sinnfreien Abfragen und Weiterleitungs Anforderungen haben zu 99% ein Ende. Die Aufhänger nach wilden Zeichen sind 100% weg. Peter schrieb: > Ist eigentlich ganz logisch, dass es da > ziemlich zugeht, so ungefiltert da kommt dir ja jeder > Broadcast durch. Und der haut dir wahrscheinlich alles > zusammen weil dein UDP RX Buffer keine 100 Bytes groß ist ... Das der Zeiger den Buffer nie verlassen sollte wo er hingehört ist doch ein Grundsatz. Das maximale was bei schlechter Portwahl passieren sollte, ist das der Server viel sinnloses Zeug macht. Ich würde nur nach Paketen suchen die ich erwarte, alles andere einfach ignorieren. Wenn alle UDP Pakete angezeigt werden sollen dann können eben nur Daten bis max. 100 Byte angezeigt werden. Peter schrieb: > Naja auf Port 80 ist das doch auch nicht wirklich ein Wunder oder? > Stichwort Suchmaschinen z.B ?! Mich hat die aggressive Art einfach überrascht und damit war es für mich doch ein Wunder. Würden sich alle an die Spielregeln halten und nicht auf der Suche nach offenen "Türen, Fenstern, Toren" in dem gefühlt "rechtsfreien Raum" sein, dann bräuchte man sich mit so einem Quatsch nicht auseinander setzen. Es sind einfach zu viele "Spezialistin" unterwegs. Ich bin froh mich mit dem Thema beschäftigt zu haben, allerdings bin ich nicht ganz so leichtfüßig mehr mit dem Netzwerk und den Portfreigaben ans Internet. Grüße AVRli...
Das ist nicht nur im Internet so. SO sind wir Menschen halt - und die von uns gebauten Maschinen. Stell mal vor den Kölner Dom ein Blockhaus auf. Es wird nicht lange dauern, bis neugierige Menschen durch die Fenster hinein schauen und ausprobieren, ob man die Türen öffnen kann.
Hallo AVRli, ich habe mal einen HTTP 1.1 Server implementiert und mich dabei an RFC2616 orientiert. Der RFC ist eigentlich ganz verständlich geschrieben. Du kannst Dir ja mal die Unit-Tests in https://github.com/TorstenRobitzki/Sioux angucken, vielleicht hilft Dir das. Aber generell musst Du jede offene Verbindung mit einem timer versehen, sowohl bei Lesen und beim Schreiben. Ich würde Verbindungen, auf denen keine gültiger HTTP request gekommen ist, auch einfach schließen (je früher, um so besser). mfg Torsten
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.