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.
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?
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.
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.
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.
