Guten Morgen, auf einer embedded Anwendung möchte ich anhand der IP-Adresse von ankommenden Datenpaketen erkennen, ob diese aus dem externen Netz (Internet) oder dem internen Netzwerk stammen und je nachdem annehmen oder verwerfen. Mir stehen folgende Parameter zur Verfügung: - Hostname der eigenen Anwendung - IP der egienen Anwendung - Port der eigenen Anwendung - Subnetzmaske der eigenen Anwendung - Standardgateway der eigenen Anwendung Folgende Informationen kann ich vom Socket über die ankommenden Datenpakete auslesen: - IP Adresse - Port Je nachdem wie meine Anwendung parametriert wird, dürfen Datenpakete aus dem externen Netz (Internet) angenomen werden oder auch nicht. Das interne Netzerk (lokales Netzwerk) soll immer funktionieren. Mir ist im Moment noch nicht ganz klar, wie ich anhand der IP Adressen feststellen kann, welche Datenpakete ich annehmen darf und welche nicht. Zuerst habe ich mir überlegt ganz einfach den ersten Adressblock der IP Adresse zu vergleichen. Beispiel: Meine Anwendung hat die IP 172.xxx.xxx.xxx dann nehme ich Datenpakete nur an, wenn diese ebenfalls aus dem Bereich 172.xxx.xxx.xxx stammen. Das funktioniert aber nicht wirklich, weil dann Datenpakete mit der IP 140.xxx.xxx.xxx ebenfalls nicht angenommen werden, obwohl 140.xxx.xxx.xxx auch zum internen Netzwerk gehört. Ich denke, dass ich kann hier einen Vergleich mit der Sunbetzmaske anwenden kann aber ich weiß noch nicht genau wie das funktioniert. Könnt ihr mir hierbei weiterhelfen? Über ein kleines Beispiel mit einer IP wäre ich dankbar.
Es gibt nur 3 Adressbereiche, die konfliktfrei intern genutzt werden dürfen: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
Grüß Dich! Hast du schon einmal von Netzklassen gehört (https://de.wikipedia.org/wiki/Netzklasse - jaja, Wikipedia ist uncool ich weiß). Ich denke die könnten dir weiter helfen. Private IP: https://de.wikipedia.org/wiki/Private_IP-Adresse Beste Grüße, David
Hallo, vielen Dank für die Hinweise, das habe ich mir bereits durchgelesen. Da ich hier ein internes Netzwerk im Adressbereich 172.xxx.xxx.xxx und ein zweites im Bereich 140.xxx.xxx.xxx habe, bin ich mir nicht ganz sicher. Empfehlt ihr mir dann einen Abgleich des Netzwerkes mit der Subnetzmaske?
Hallo, wenn du fürs Erste wissen willst ob das Paket aus deinem lokalen Netzwerk stammt sollte die Netzmaske reichen. Wobei ich gerade etwas verwirrt bin warum du ein internes Netzwerk mit IP 140.xxx.xxx.xxx hast?! Beste Grüße, David
iptables kann das. quickndirty musst selbst mal schaun aber so ähnlich könnte das aussehen. [code] #!/bin/sh IPT="/sbin/iptables" $IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -A INPUT -p tcp --dport 22 -m state --state NEW -s 172.0.0.0/8 -j ACCEPT $IPT -I OUTPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT $IPT -A OUTPUT -p udp --dport 53 -m state --state NEW -j ACCEPT [code]
David S. schrieb: > Hallo, > > wenn du fürs Erste wissen willst ob das Paket aus deinem lokalen > Netzwerk stammt sollte die Netzmaske reichen. > > Wobei ich gerade etwas verwirrt bin warum du ein internes Netzwerk mit > IP 140.xxx.xxx.xxx hast?! > > Beste Grüße, > David Das weiß ich auch nicht genau, mit der IT habe ich nichts zu tun aber intern kann man ja machen was man möchte, solange nichts nach außen geht?! Auf meiner embedded-C Anwendung hilft mir das nicht weiter. Trotzdem vielen Dank für den Hinweis Hackfleisch.
etk55257 schrieb: > Das weiß ich auch nicht genau, mit der IT habe ich nichts zu tun aber > intern kann man ja machen was man möchte, solange nichts nach außen > geht?! Genau. Intern darfst du alles machen, vor allem, wenn du nicht genau weißt, was du da eigentlich machst ;) Wenns da eine IT gibt, klingt das nach Firmennetzwerk, und dann wird das bestimmt lustig. Viel Erfolg. Oliver P.S. was ist für dich "intern", und was nicht?
Hallo, nun gut, wenn man nicht nach außen angebunden ist kann man wohl machen was man will. Beste Grüße, David
1. Standartgateway mit Subnetzmaske verUNDen 2. Absenderadresse mit Subnetzmaske verUNDen 3. Ergebnisse vergleichen 4. Wenn gleich => Absender kommt aus internem Netz
etk55257 schrieb: > ein zweites im Bereich 140.xxx.xxx.xxx habe, bin ich mir nicht ganz > sicher. Unschön, weshalb? Beim 140ern Adressbereich liegt zwar offenbar der grössere Teil beim US Militär, mit dem ihr vielleicht nicht so oft kommuniziert. Aber auch andere Netze finden sich dort.
Bist Du an einer Uni, Hochschule oder Forschungseinrichtung? Da könnte es schon sein, das die Rechner "externe" IP-Adresse aus dem I-Net haben, einfach, weil das Ihr Adressbereich ist, den Sie haben...
Hallo, nochmals vielen Dank für die Antworten. Ich werde die IP-Adressen mit der Subnetzmaske verunden und dementsprechend die Datenpakete akzeptieren oder verwerfen. Das mit dem lokalen 140.xxx Netzwerk ist ein unüblicher Sonderfall und wird dann erstmal nicht berücksichtigt. Die Anwendung muss dann so eingestellt werden, dass Datenpakete von externen IP Adresse akzeptiert werden. Dann funktioniert auch eine Kommunikation vom 140.xxx Netz ins 172.xxx Netz. Vielen Dank.
Stefan P. schrieb: > 1. Standartgateway mit Subnetzmaske verUNDen > 2. Absenderadresse mit Subnetzmaske verUNDen Anstelle des Standar_D_gateways sollte man die eigene Adresse verwenden.
etk55257 schrieb: > Das weiß ich auch nicht genau, mit der IT habe ich nichts zu tun aber > intern kann man ja machen was man möchte, solange nichts nach außen > geht?! Nö. Auch intern gibt es schnell eine Abmahnung wenn man was macht wovon IT nix weiss. In größeren Netzwerken gibt es IDS (Intrusion Detection). Übrigens muss Dir IT auch sagen können wie man externe Addressen erkennt. Ich habe öfters Netzwerke gesehen wo die Middlebox (Firewall) öffentliche Zugriffe nach intern NAT-et, also wo man intern nur die nicht-öffentliche IP der Firewall sieht.
etk55257 schrieb: > Da ich hier ein internes Netzwerk im Adressbereich 172.xxx.xxx.xxx und > ein zweites im Bereich 140.xxx.xxx.xxx habe, bin ich mir nicht ganz > sicher. Vermutung: Die Firma/Institut hat einen registrierten Adressbereich bei 140.zzz.xxx.xxx. Dieser ist mittlerweile hinter eine Firewall versteck, die nach aussen nur noch eine (andere) Adresse hat. Der Bereich 172.xxx.xxx.xxx ist ein zusätzliches internes Netz (z.B VLAN)
A. K. schrieb: > Es gibt nur 3 Adressbereiche, die konfliktfrei intern genutzt werden > dürfen: > 10.0.0.0/8 > 172.16.0.0/12 > 192.168.0.0/16 169.254/16 gehört auch in diese Aufzählung. Und wo bleibt die Aufzählung f. IPv6? (aufwachen: wir haben 2017!!!)
>Vermutung
Da vermute ich mal: Bei den typischen Fritz-Box Heimnetzen kann man die
lokalen Adressen mit hilfe des DHCP bestimmen. Eigenen IP und eigene
Subnetzmaske.
Bei Firmennetzen muss man die Admins fragen.
Vielleicht haben die Admins eines dieser unzähligen IOT Protokolle
aufgesetzt, mit denen du die erlaubten Clients abfragen kannst.
Dirk B. schrieb: > Vermutung: > Die Firma/Institut hat einen registrierten Adressbereich bei > 140.zzz.xxx.xxx. > Dieser ist mittlerweile hinter eine Firewall versteck, die nach aussen > nur noch eine (andere) Adresse hat. Nö. Die Firma hat eine registrierten Adressbereich, und nutzt den ganz normal für ihre Rechner. Das da Firewalls zum Rest des Netzes dazwischen sind, ändert nichts daran. Oliver
Local Area Notwork schrieb: > 169.254/16 gehört auch in diese Aufzählung. Nein, Apipa-Adressen kann man nicht konfliktfrei benutzen, die sind dafür gedacht automagisch verteilt zu werden. Und der Anteil der Leute, die privat IPv&-Adressen benutzen, dürfte noch im unteren Promille-Bereich liegen.
Local Area Notwork schrieb: > Und wo bleibt die Aufzählung f. IPv6? (aufwachen: wir haben 2017!!!) fe80::/10 Allerdings hat es bei IPv6 durchaus Sinn, für alles, externen und internen Traffic, reale, zugewiesene Adressen zu benutzen. etk55257 schrieb: > Je nachdem wie meine Anwendung parametriert wird, dürfen Datenpakete aus > dem externen Netz (Internet) angenomen werden oder auch nicht. Ein Sicherheitskonzept irgendeiner Art ist sowas allerdings nicht. Schließlich lassen sich Absenderadressen beliebig faken.
:
Bearbeitet durch Moderator
Horst schrieb: > Und der Anteil der Leute, die privat IPv&-Adressen benutzen, dürfte noch > im unteren Promille-Bereich liegen. die Meisten wissen gar nicht das sie es benutzten. Jeder neue Anschluss läuft schon unter Ipv6.
Beitrag #5011233 wurde vom Autor gelöscht.
Jörg W. schrieb: > > etk55257 schrieb: >> Je nachdem wie meine Anwendung parametriert wird, dürfen Datenpakete aus >> dem externen Netz (Internet) angenomen werden oder auch nicht. > > Ein Sicherheitskonzept irgendeiner Art ist sowas allerdings nicht. > Schließlich lassen sich Absenderadressen beliebig faken. Das stimmt. Ist auch nur als eine Art Filter gedacht um vorab schon aussortieren zu können. Weitere Sicherheitsmechanismen sind genügend vorhanden aber eine Vorabauswahl spaar Systemressourcen.
Jörg W. schrieb: > Ein Sicherheitskonzept irgendeiner Art ist sowas allerdings nicht. > Schließlich lassen sich Absenderadressen beliebig faken. bei UDP eventuell, bei TCP wird es schwer den Absender zu faken. (Zumindest wenn man selber nicht in der Netzt ist) Von der Seite sehe ich das schon als Sicherheit, wenn Geräte (IoT) erst einmal nur aus dem Lokalen netzt erreichbar sind, bis jemand ein neue Passwort vergeben hat.
Peter II schrieb: > bei TCP wird es schwer den Absender zu faken Ach was. Schau dir mal die Angriffe an, die man seinerzeit gegen rsh (remote shell) gefahren hat. Die hatten auch als einzige „Authentisierung“ die IP-Adresse des Gegenübers benutzt.
Jörg W. schrieb: > Ach was. Schau dir mal die Angriffe an, die man seinerzeit gegen > rsh (remote shell) gefahren hat. Die hatten auch als einzige > „Authentisierung“ die IP-Adresse des Gegenübers benutzt. dann muss man aber die TCP-Sequenznummer erraten, da wurden die System in letzte zeit aber immer Zufälliger. (nicht wie früher einfach aufsteigend).
etk55257 schrieb: > Hallo, > > vielen Dank für die Hinweise, das habe ich mir bereits durchgelesen. > Da ich hier ein internes Netzwerk im Adressbereich 172.xxx.xxx.xxx und > ein zweites im Bereich 140.xxx.xxx.xxx habe, bin ich mir nicht ganz > sicher. Wer hat denn das eingerichtet? 140.0.0.0 ist ein öffentliches Netz eines indonesischen Providers, 140.{1..50}.0.0 hingegen gehören dem us-amerikanischen Verteidigungsministerium...
Karl Käfer schrieb: > Wer hat denn das eingerichtet? 140.0.0.0 ist ein öffentliches Netz eines > indonesischen Providers, 140.{1..50}.0.0 hingegen gehören dem > us-amerikanischen Verteidigungsministerium... Es gibt aber noch einige mehr … mindestens eins davon auch in DE.
Horst schrieb: > Local Area Notwork schrieb: >> 169.254/16 gehört auch in diese Aufzählung. > > Nein, Apipa-Adressen kann man nicht konfliktfrei benutzen, die sind > dafür gedacht automagisch verteilt zu werden. Ich kenne die Spielregeln diese Automagie: ich musste sie schon mal implementieren (Konflikte entstehen selten UND lassen sich lösen) - Du bist frei deine Finger davon zu lassen. NB: Netzwerkprotokolle mit automatischer Adresszuteilung (und Konfliktlösung und service advertising ) habe ich schon vor über 25J schätzen gelernt. Als ich rund 5J danach zu IP stiess, suchte ich lange bis nach und nach die Bestandteile von Zeroconf zusammentrafen.
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.