Aug 22, 2015

2816

RB 333 PPPoE Client an Glasfaser "produziert" massig Upload

Hallo,

ich habe hier einen Glasfaseranschluß vom hiesigen Anbieter (Copaco Paraguay). Daran hängt der Modemwandler (nicht von mir konfigurierbar) und von da geht ein Kabel auf ether 1 eines Routerboards RB 333. Es läuft mit aktueller Software (ROS 6.29.1) und der PPPoE Client macht die Einwahl. Angeschlossen ist ein weiteres ether und zwei Wlans. Die Bandbreite ist 5Mb (Download = Upload).

Das Ganze funktioniert ein paar Tage ohne Probleme, dann tritt plötzlich das Phänomen auf, daß ich auf dem ether 1 und dem PPPoE Client einen Dauer-Upload von teilweise bis zu 7 Mb beobachte. Dabei ist weder auf dem anderen ether's noch auf den Wlans dieser erhöhte Traffic zu sehen. Der bleibt auch bestehen, wenn ich alle anderen Interface deaktiviere. Es sieht aus, als "produziere" das Bord diesen Upload.
Deaktiviere ich kurz das ether 1 oder den PPPoE Clienten, ist der Upload danach weg, das Bord connected sich wieder, hat eine andere IP als Local Address bekommen und alles läuft wieder zwei, drei Tage.

Den Modemwandler habe ich schon mal getauscht - gleiches Verhalten. Der Anbieter sagt mir am Telefon, daß der Traffic von mir kommt, er könne da nichts machen.

Kann mir jemand einen guten Rat geben, was ich tun kann? Ist es möglich, daß das Bord "spinnt", also wirklich einen solchen Upload produziert? Ich glaube das nicht, aber ich muß dem Anbieter nachweisen, daß meine Technik in Ordnung ist und das ist hier im Land der unbegrenzten Unmöglichkeiten schwierig.

Viele Grüße

Torsten

Please also mark the comments that contributed to the solution of the article

Content-Key: 280912

Url: https://administrator.de/contentid/280912

Printed on: April 26, 2024 at 09:04 o'clock

27 Comments

Latest comment

Kann mir jemand einen guten Rat geben, was ich tun kann?

Mit einem kleinen Switch und WireShark nach der Ursache suchen!

Ist es möglich, daß das Bord "spinnt", also wirklich einen solchen Upload produziert?

Möglich ist alles und das ist auch ein original RB und kein Fake oder eine gecrackte
RouterOS Version, alles original?

Ich glaube das nicht, aber ich muß dem Anbieter nachweisen, daß meine Technik in Ordnung
ist und das ist hier im Land der unbegrenzten Unmöglichkeiten schwierig.

Also ein kleiner Switch dazwischen und dann mittels WireShark sniffen was wer an wen sendet
sollte da auch bei Euch möglich sein. So ein kleiner Switch kostet nur um die ~30 €;
- Netgear GS105Ev2 ~25 €
- Netgear GS108Ev2 ~40 €
- Netgear GS108Tv2 ~70 €

Damit kann man dann schnell heraus finden wer was an wen und warum sendet.
Dein WLAN ist auch verschlüsselt?
Dein WLAN ist nicht offen?
Dein WLAN ist durch den usermanager abgesichert?
Dein WLAN wird nicht von jemandem mit benutzt? (Eltern, Geschwister,....)

Gruß
Dobby

MOin,

Un dDu biste Dir sicher, daß da nicht gerade ein "Angriff" läuft? Denn wenn die Adresse IP-Adresse sich ändert und dann Ruhe ist, wäre das ein Hinweis. daß entweder ein Angriff läuft, oder jemand sich zu iner IP-Adresse zu verbinden versucht, die Du geerbt hast.

hast Du eine quasistatische IP-Adresse oder wird die regelmäßig druchrotiert?

lks

Zitat von @108012:
Also ein dummer switch dazwischen und dann mittels WireShark sniffen was wer an wen sendet

Ein unmanaged Switch wäre dafür aber untauglich! Es müsste schon ein Hub oder ein managed Switch mit Mirror-Funktion sein.

Hallo Torsten,
für mich hört sich das an, als ob Dein RB für DDoS-Angriffe mißbraucht wird.
Im schlimmsten Fall steht der Router bereits unter der vollständigen Kontrolle eines Dritten und arbeitet manipulierten Code ab. Dann müsste er nach eingehender Analyse und Beweissicherung komplett platt gemacht und mit einem neuen RouterOS-Image bespielt werden.
Wahrscheinlicher ist es jedoch, dass der Router aufgrund eines Konfigurationsfehlers für sog. Verstärkungsangriffe genutzt wird. Am gebräuchlichsten hierfür wäre DNS. Siehe https://de.wikipedia.org/wiki/DNS_Amplification_Attack.
http://www.ceilers-news.de/serendipity/333-DDoS-durch-DNS-Amplification ...
Ebenfalls für solche Zwecke beliebt ist NTP: http://www.heise.de/security/meldung/Kommt-Zeit-kommt-DDoS-Angriff-2087 ...
Aufgrund der Komplexität der RouterOS-Konfiguration können sich solche Fehler schnell einschleichen. Ein Mikrotik ist nun mal nix für den durchschnittlichen Heimanwender (die oftmals leichtfertigen Empfehlungen hier sehe ich daher mit großer Sorge).
http://forum.mikrotik.com/viewtopic.php?t=71395
https://www.reddit.com/r/mikrotik/comments/2092e7/be_careful_your_router ...
Wie sehen Deine Firewall-Regeln der Input-Chain aus?

Gruß
Steffen

Zitat von @sk:

Ein Mikrotik ist nun mal nix für den durchschnittlichen Heimanwender (die oftmals leichtfertigen Empfehlungen hier sehe ich daher mit großer Sorge).

Hier sind doch lauter Admins unterwegs und da sollte man doch annehmen, daß diese Ihre Hausaufgaben machen, oder nicht?

lks

PS: Wenn man den Kindern fritzbüxen empfiehlt hilft das denen doch auch meist nciht weiter. Und bei einer Cisco für mehrere hudnert Euro hätten die heimanwnder dasselbe Problem.

Hier sind doch lauter Admins unterwegs und da sollte man doch annehmen, daß diese Ihre
Hausaufgaben machen, oder nicht?

Klar ist zu Hause jeder 14 jährige der Admin des Heimnetzes.

PS: Wenn man den Kindern fritzbüxen empfiehlt hilft das denen doch auch meist nciht weiter.
Und bei einer Cisco für mehrere hudnert Euro hätten die heimanwnder dasselbe Problem.

Eine AVm FB und ein SG200-xx doer SG300-xx lassen sich aber für solche Fälle die ...sk...
angesprochen hat nicht missbrauchen.

Gruß
Dobby

Zitat von @sk:

> Zitat von @108012:
> Also ein dummer switch dazwischen und dann mittels WireShark sniffen was wer an wen sendet

Ein unmanaged Switch wäre dafür aber untauglich! Es müsste schon ein Hub oder ein managed Switch mit
Mirror-Funktion sein.

Alle drei Switche stellen einen Mirrored Port zur Verfügung. War wohl schlecht formuliert.

Gruß
Dobby

Das klingt so, als wenn das Routerboard offene UDP-Dienste (DNS, SSDP, NTP, RIBv1...) auf WAN-Seite zur Verfügung stellt und die für Amplification-Angriffe missbraucht werden. Prüfe mal, welche Dienste auf deiner IP aus dem Internet erreichbar sind und deaktiviere sie resp. binde sie ausschließlich an die LAN-Seite.
Im Zweifel könntest du auch - wenn die Möglichkeit besteht - dich zwischen Modem und Routerboard klemmen und mit Wireshark mal reinhören, was da so passiert.

Hallo an Alle und danke für Eure rege Anteilnahme. Bevor ich das abarbeite, ein paar Antworten:

Dobby:

und das ist auch ein original RB und kein Fake oder eine gecrackte
RouterOS Version, alles original?

Ja, alles orginal, gekauft und bezahlt.

Dein WLAN ist auch verschlüsselt?
Dein WLAN ist nicht offen?
Dein WLAN ist durch den usermanager abgesichert?
Dein WLAN wird nicht von jemandem mit benutzt? (Eltern, Geschwister,....)

Wlan ist verschlüsselt, nicht offen, Hotspot und Userman laufen, Wlan wird natürlich benutzt, aber wenn ich es deaktiviere, also niemend es benutzen kann, ist der Upload (und nur Upload, kein Download) dennoch da.

Iks:

Un dDu biste Dir sicher, daß da nicht gerade ein "Angriff" läuft? Denn wenn die Adresse IP-Adresse sich ändert und dann Ruhe ist, wäre das ein Hinweis. daß entweder > ein Angriff läuft, oder jemand sich zu iner IP-Adresse zu verbinden versucht, die Du geerbt hast.

hast Du eine quasistatische IP-Adresse oder wird die regelmäßig druchrotiert?

Sicher bin ich nicht, das will ich ja gerade rausfinden. Stutzig macht mich eben, daß ich alle Interface deaktiviere, damit intern also jeden Traffic unterbinde, der Upload aber dennoch da ist.
Die IP-Adresse ist solange konstant, wie die PPPoE-Verbindung besteht.

Steffen:

Ein Mikrotik ist nun mal nix für den durchschnittlichen Heimanwender

Ich bin zwar weit weg davon, mich Experte zu nennen, aber ich arbeite seit 7 Jahren mit Mikrotiks und denke schon, daß ich nicht ganz anfängermäßig da rangehe. Das bedeutet aber nicht, daß ich schon alles weiß. Ich bin Elektroniker und was die Software und die Netzwerktechnik betrifft, Quereinsteiger. Deshalb suche ich ja Hilfe in einem Expertenforum.

Wie sehen Deine Firewall-Regeln der Input-Chain aus?

So (+ die dynamischen Rules, die der Hotspot generiert):

/ip firewall filter
add action=passthrough chain=unused-hs-chain comment=\
"place hotspot rules here" disabled=yes
add chain=input comment="Accept established connections" connection-state=\
established
add chain=input comment="Accept related connections" connection-state=related
add chain=forward connection-state=related
add action=drop chain=input comment="Drop invalid connections" \
connection-state=invalid
add action=drop chain=forward connection-state=invalid
add chain=input comment="Accept SSH for secure shell" dst-port=22 protocol=\
tcp
add chain=input comment="Accept Winbox access" dst-port=8291 protocol=tcp
add chain=input comment="Accept DNS Querry" dst-port=53 protocol=udp
add chain=input comment="Allow limited pings" limit=50/5s,2 protocol=icmp
add action=drop chain=input comment="Drop excess pings" protocol=icmp
add chain=input comment="From our LAN" in-interface=wlan1 src-address=\
10.99.1.0/24
add action=drop chain=input comment="Drop everything else"

LordGurke:

welche Dienste auf deiner IP aus dem Internet erreichbar sind

Meinst Du die Service? Nur www und die winbox:

/ip service> print
Flags: X - disabled, I - invalid

NAME PORT ADDRESS CERTIFICATE

0 X telnet 23
1 X ftp 21
2 www 80
3 X ssh 22
4 X www-ssl 443 none
5 X api 8728
6 winbox 8291
7 X api-ssl 8729 none

Mit Wireshark werde ich probieren, was zu finden, sobald der Upload wieder auftritt. Im Moment läuft es seit gestern. Einen GS108T habe ich, mal sehen, wie ich mit dem Drahthai klarkomme. Ich habe zwar damit schon rumprobiert, ist aber nicht so ganz leicht zu bedienen, jedenfalls für mich.

Viele Grüße

Torsten

Zitat von @tomue58:
> add chain=input comment="Accept DNS Querry" dst-port=53 protocol=udp

Da ist schon dein Problem: Dein DNS-Server steht offen und wird für DNS-Amplification missbraucht.
Ändere die Regel mal so ab, dass der DNS-Server nur Verbindungen von deinem internen Netz akzeptiert.
Und bei der Gelegenheit: DNS gibt es auch über TCP und wird für größere Antworten (z.B. DNSSEC) zwingend benötigt, daher solltest du auch das TCP-Protokoll für DNS ebenfalls für dein LAN freigeben.

Hallo Torsten,

und zusätzlich zu den Punkten von LordGurke, hätte ich mal eine Frage.
Wenn man SPI/NAT macht am WAN Interface dann kann eigentlich nichts
von draußen nach drinnen rein, aber auch rein gar nichts.

Wieso ist der Router denn dann aber von außen erreichbar?

Gruß
Dobby

Das NAT ist die Barriere zwischen dem WAN-Interface des Routers und dem LAN dahinter.
In diesem Fall wird ein Dienst benutzt, der direkt vom Router selbst auf der öffentlichen IP auf dem WAN-Interface offen steht - also direkt aus dem Internet erreichbar ist und noch vor der NAT-Barriere sitzt.

Hallo,

LordGurke: Das ist natürlich wahr. Dann werde ich das mal ändern. Entspräche [url=http://forum.mikrotik.com/viewtopic.php?t=69677]das hier[/url] einem vollständigen Schutz und läßt gleichzeitig zu, daß interne Nutzer nach Wunsch auch externe DNS-Server nutzen können?

Dobby:

Wieso ist der Router denn dann aber von außen erreichbar?

Weil ich auch von Unterwegs Zugriff zu dem Netz dahinter brauche.

Viele Grüße

Torsten

Ups - da ist was schief gegangen. Na gut, der Link ist da...

also direkt aus dem Internet erreichbar ist und noch vor der NAT-Barriere sitzt.

Danke für die Erklärung, also hat @..sk.. doch recht behalten!

Weil ich auch von Unterwegs Zugriff zu dem Netz dahinter brauche.

Und Du machst das seit sieben Jahren so? Ich habe "nur" eine AVM FB
die ist nicht so der richtige "Bringer" hinsichtlich der Funktionen, Optionen
und gebotenen Dienste, aber die macht SPI/NAT und kann IPSec VPN!

Da geht von außen nichts rein!

Gruß
Dobby

Hallo Dobby,

wie ich schon schrieb - ich bin kein Experte und bin froh, wenn ich etwas verstanden habe und zum Laufen bringe. Klar ist sicher manches besser lösbar, wenn man mehr Kenntnisse hat. Mein Mikrotikwissen ist "learning by doing" aus dem Internet, Netzwerke waren zur Zeit meines Studiums noch in den Anfängen bzw. (im Osten, wo ich herkomme) noch gar nicht bekannt.
Aber nochmal die Frage: Die Firewall- und Nat- Regeln von hier: http://forum.mikrotik.com/viewtopic.php?t=69677] sind gut so? Ich kann es auch ausprobieren, aber wenn ein Erfahrener mir sagt "Ja" oder "mach' es so", dann hilft das schneller.

Danke übrigens für die Hilfe!

Viele Grüße

Torsten

Zitat von @tomue58:
Aber nochmal die Frage: Die Firewall- und Nat- Regeln von hier: http://forum.mikrotik.com/viewtopic.php?t=69677] sind gut so? Ich
kann es auch ausprobieren, aber wenn ein Erfahrener mir sagt "Ja" oder "mach' es so", dann hilft das schneller.

Bitte nicht einfach irgendwelche Regeln abtippen, ohne sie inhaltlich zu verstehen! Bei den dort vorgeschlagenen Regeln handelt es sich um explizites Verweigern. Dein Regelwerk ist - zumindest in Hinblick auf die Input-Chain - richtiger Weise so aufgebaut, dass alles verweigert wird, was nicht explizit erlaubt ist. Der Fehler in Deiner Konfiguration ist lediglich, dass die Erlauben-Regeln zu weit gefasst sind. Schränke diese einfach auf die Source-IPs und die Interfaces des internen Netzes ein!

Gruß
sk

Hallo sk,

danke für die Hilfe. Vvielleicht habe ich es ja noch nicht richtig verstanden. Wenn ich die "Erlauben-Regeln" verwende, muß ich die vier möglichen src-adressen für beide Protokolle (LordGurke) angeben:

add chain=input comment="Accept DNS Querry our LAN" src-address=10.99.1.0/24 dst-port=53 protocol=udp
add chain=input comment="Accept DNS Querry our LAN" src-address=10.99.1.0/24 dst-port=53 protocol=tcp
add chain=input comment="Accept DNS Querry our LAN" src-address=10.7.37.0/27 dst-port=53 protocol=udp
add chain=input comment="Accept DNS Querry our LAN" src-address=10.7.37.0/27 dst-port=53 protocol=tcp
add chain=input comment="Accept DNS Querry our LAN" src-address=10.7.7.0/28 dst-port=53 protocol=udp
add chain=input comment="Accept DNS Querry our LAN" src-address=10.7.7.0/28 dst-port=53 protocol=tcp
add chain=input comment="Accept DNS Querry our LAN" src-address=10.8.7.0/29 dst-port=53 protocol=udp
add chain=input comment="Accept DNS Querry our LAN" src-address=10.8.7.0/29 dst-port=53 protocol=tcp

Dabei bin ich mir noch unsicher, ob dann vom LAN kommende "DNS-Server-Wünsche" funktionieren.
Wenn ich die sechs Zeilen aus dem Link nehme, habe ich doch den gleichen Effekt bezüglich des Erlaubens, weniger Zeilen zu konfigurieren und die DNS-Server-Wünsche sollten auch klappen. Oder sehe ich da noch was falsch?

Viele Grüße

Torsten

Das NAT arbeitet stateful, das heißt dass Antwortpakete auf DNS-Anfragen vom LAN immer durchgelassen werden.
Die Regeln könnte man vereinfachen, indem man schlicht einfach alle DNS-Queries auf dem LAN-Interface erlaubt werden, statt über die IP zu filtern.

Du solltest aber generell mal alle Input-Regeln überarbeiten und entweder auf Interface oder Source-IP beschränken — weil du momentan einen Haufen Dienste ins Internet stellst, die man eigentlich nicht im Internet haben will

SSH und Telnet werden schon sehr massiv angegriffen...

Zitat von @tomue58:
Wenn ich die "Erlauben-Regeln" verwende, muß ich die vier möglichen src-adressen
für beide Protokolle (LordGurke) angeben...

Das kann man auch anders aufbauen. Eine der mächtigsten Möglichkeiten von RouterOS ist es beispielsweise, Bedingungen negativ zu formulieren. Man könnte also sagen: Erlaube DNS zum Router - es sei denn, der Traffic kommt vom WAN-Interface.

Zitat von @tomue58:
Dabei bin ich mir noch unsicher, ob dann vom LAN kommende "DNS-Server-Wünsche" funktionieren.

Wenn Deine internen Hosts nicht den Router als DNS-Forwarder verwenden, sondern externe DNS-Server direkt ansprechen, dann benötigst Du die o.g. Input-Chain-Regeln ohnehin nicht! Dafür greift die Forward-Chain!

Gruß
sk

Hallo,

um die Frage weiter Richtung gelöst zu bringen:

LordGurke schrieb:

Ändere die Regel mal so ab, dass der DNS-Server nur Verbindungen von deinem internen Netz akzeptiert.
Und bei der Gelegenheit: DNS gibt es auch über TCP und wird für größere Antworten (z.B. DNSSEC) zwingend benötigt,
daher solltest du auch das TCP-Protokoll für DNS ebenfalls für dein LAN freigeben.

sk schrieb:

Das kann man auch anders aufbauen. Eine der mächtigsten Möglichkeiten von RouterOS ist es beispielsweise,
Bedingungen negativ zu formulieren. Man könnte also sagen: Erlaube DNS zum Router - es sei denn, der Traffic kommt
vom WAN-Interface.

Dann reichen diese beiden Regeln dafür aus, richtig verstanden (ether 1 ist der Port zum WAN)?

;;; Accept DNS Querry
chain=input action=accept protocol=tcp in-interface=!ether1 dst-port=80,443
chain=input action=accept protocol=udp in-interface=!ether1 dst-port=53

Und meine weitere Frage - Dobby schrieb:

Wenn man SPI/NAT macht am WAN Interface dann kann eigentlich nichts
von draußen nach drinnen rein, aber auch rein gar nichts.

Würde das etwa diesen Regeln entsprechen? Ich habe nicht viel finden können zu dem Thema.

;;; Connection Tracking Regeln
add chain=conntrack connection-sate=invalid action=drop
add chain=conntrack connection-state=established action=accept
add chain=conntrack connection-state=related action=accept
add chain=conntrack action=return
;;; Prüfen
add chain=forward action=jump to-chain=conntrack
;;; Erlauben
add chain=forward out-interf=ether1 action=accept
;;; Blocken
add chain=forward action=drop

Saludos

Torsten

Zitat von @tomue58:
Dann reichen diese beiden Regeln dafür aus, richtig verstanden (ether 1 ist der Port zum WAN)?

> ;;; Accept DNS Querry
> chain=input action=accept protocol=tcp in-interface=!ether1 dst-port=80,443
> chain=input action=accept protocol=udp in-interface=!ether1 dst-port=53

Jain. Da ich schon lange nichts mehr mit Mikrotik gemacht habe, bin ich mir nicht sicher, ob ether1 hier auch das PPPoE-Interface erfasst. Ich vermute, dass dies nicht so ist, denn die öffentliche IP liegt bei Dir ja am PPPoE-Client an - nicht am ether1-Interface. Das müsstest Du also mal testen...

Zitat von @tomue58:
Und meine weitere Frage - Dobby schrieb:
> Wenn man SPI/NAT macht am WAN Interface dann kann eigentlich nichts
> von draußen nach drinnen rein, aber auch rein gar nichts.

Ich wollte mich eigentlich nicht zu diesem Kommentar äußern, aber er ist exemplarisch für das, was hier und in anderen Foren häufig passiert: Mit dem Brustton der Überzeugung reden einige mit, denen das Hintergrundwissen im konkreten Einzelfall zu fehlen scheint. Für einen Fragesteller ist dies nicht immer sofort zu erkennen. Auch Dobby (ohne ihm zu nahe treten zu wollen - er schreibt ansonsten sehr viel hilfreiches) empfiehlt hier ja gelegentlich Mikrotik, weil es andere ebenfalls tun, offenkundig jedoch ohne selbst in der Mikrotik-Konfiguration erfahren zu sein.
NAT allein ist kein Sicherheitsfeature und hat bestenfalls mittelbare Schutzwirkung. Auf keinen Fall schützt es jedoch den Router selbst vor Zugriff von außen. Dafür bedarf es immer des Abschaltens/Nichtbindens von Diensten auf dem WAN-Interface und/oder der Implementierung von Filterregeln. Auch auf einer Fritzbox ist dies so - nur ist diese weitgehend vorkonfiguriert und der User wird von diesen Einstellungen fern gehalten. Bei Mikrotik muss man sich hingegen um alles - wirklich alles - selber kümmern. Und dafür muss man eben erstmal verstehen, was da überhaupt passiert. Anders ausgedrückt: Fritzbox ist für DAUs und Miktorik für Profis. Ein Mikrotik in Händen eines DAUs kann eine Gefahr sein.

Zitat von @tomue58:
Würde das etwa diesen Regeln entsprechen? Ich habe nicht viel finden können zu dem Thema.
> ;;; Connection Tracking Regeln
> add chain=conntrack connection-sate=invalid action=drop
> add chain=conntrack connection-state=established action=accept
> add chain=conntrack connection-state=related action=accept
> add chain=conntrack action=return
> ;;; Prüfen
> add chain=forward action=jump to-chain=conntrack
> ;;; Erlauben
> add chain=forward out-interf=ether1 action=accept
> ;;; Blocken
> add chain=forward action=drop

Ohne jetzt in die Tiefe gehen zu wollen: Das Connection-Tracking sorgt dafür, dass sich der Router den Status einer Verbindung merkt und man mit diesen Informationen u.a. im Firewallregelwerk weiterarbeiten kann. So ist es möglich, dass das Firewallregelwerk bestimmten Traffic abhängig vom Verbindungsstatus dynamisch zulässt oder verwirft. Ohne dies wäre es nur ein statischer Paketfilter, welcher deutlich komplizierter und dennoch weniger leistungsfähig wäre. Bei einem statischen Filter würde es bspw. nicht genügen, nur den ausgehenden Traffic LAN nach WAN zuzulassen - man müsste ebenso den dazugehörigen Antworttraffic WAN nach LAN in entsprechende Regeln "gießen", was nicht nur kompliziert sein kann, sondern zumeist auch das Sicherheitsniveau deutlich herabsetzen würde.
Das obige Codeschnipsel zeigt, wie man auf einem Miktorik im Firewallregelwerk den Connection-Status auswerten und verarbeiten kann, so dass die Firewall sich "stateful" verhält. Der Code scheint aber nicht aus Deinem Regelwerk zu stammen, denn anders als in Deinem vorherigen Posting sind diese Regeln hier zur Vermeidung von Regelredundanzen in eine eigene Chain ausgelagert worden.

Gruß
sk

Hallo sk,

danke für die Antwort. Ich fange mal hinten an: Diese Zeilen zu dem SPI/NAT habe ich nicht konfiguriert. Ich habe mich nur mit dem Vorschlag oder der Empfehlung von Dobby befasst, um zu verstehen, was er meint. Dazu ist im Netz nicht all zuviel zu finden. Das ist also mehr zum lernen gedacht und ich wollte wissen, ob das im Prinzip so gemeint ist. Vielleicht hat ja jemand einen guten Link, um mich mal in Ruhe damit befassen zu können.

Zu dem DNS Querry:

die öffentliche IP liegt bei Dir ja am PPPoE-Client an - nicht am ether1-Interface. Das müsstest Du also mal testen...

Schlag mich, aber wie kann ich das testen? Ich habe die beiden Zeilen seit gestern aktiviert, die andere deaktiviert und warte nun, ob der Upload wieder auftritt. Oder geht das auch anders? Der PPPoE-Client erfordert doch beim anlegen die Angabe eines Interfaces.
Eine andere Frage dazu habe ich noch: Muß ich die Ports überhaupt extra angeben oder reicht das Protokoll?

Viele Grüße

Torsten

Hallo Torsten,

Zitat von @tomue58:
Diese Zeilen zu dem SPI/NAT habe ich nicht konfiguriert. Ich habe mich nur mit dem Vorschlag oder
der Empfehlung von Dobby befasst, um zu verstehen, was er meint. Dazu ist im Netz nicht all zuviel zu
finden. Das ist also mehr zum lernen gedacht und ich wollte wissen, ob das im Prinzip so gemeint ist.
Vielleicht hat ja jemand einen guten Link, um mich mal in Ruhe damit befassen zu können.

SPI und NAT haben eigentlich nicht unmittelbar miteinander zu tun. Die Vermengung der Begriffe zeigt, dass Unklarheit über die Funktionsweise besteht.
SPI bedeutet "Stateful Packet Inspection". Hier zwei Links, die die Funktionsweise verdeutlichen sollten:
http://www.it-administrator.de/lexikon/stateful_packet_inspection.html
https://de.wikipedia.org/wiki/Stateful_Packet_Inspection
Dafür hast Du diese Dir vielleicht (noch) ominös vorkommenden Regeln mit "related", "established" usw. in Deinem Firewallregelwerk von irgendwo abgetippt...

NAT bedeutet schlicht "Network Address Translation" - also Adressübersetzung.
Siehe https://de.wikipedia.org/wiki/Network_Address_Translation
http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT

Wie gesagt: das eine hat mit dem anderen nicht zwingend etwas zu tun. Was SPI und NAT - von einem konfigurationsabhängigen inhaltlichen Zusammenspiel abgesehen - jedoch eint ist, dass es auf den meisten (aber nicht allen) Systemen eine gemeinsame/kombinierte Session- und NAT-Table gibt. Mein MTCNA ist zwar gefühlt schon eine Ewigkeit abgelaufen, aber ich meine mich zu erinnern, dass dies bei Mikrotik auch so gewesen ist. Deshalb benötigt man bei Mikrotik - wenn ich mich recht entsinne - zumindest für alle NAT-Formen, die über ein stumpfes 1:1 hinaus gehen, ein aktiviertes Connection Tracking.

Zitat von @tomue58:
Schlag mich, aber wie kann ich das testen? Ich habe die beiden Zeilen seit gestern aktiviert, die andere deaktiviert und warte
nun, ob der Upload wieder auftritt. Oder geht das auch anders? Der PPPoE-Client erfordert doch beim anlegen die Angabe eines
Interfaces.

Z.B. mittels eines Port-Scans wie diesem: https://www.heise.de/security/dienste/portscan/test/go.shtml?scanart=1

Zitat von @tomue58:
Eine andere Frage dazu habe ich noch: Muß ich die Ports überhaupt extra angeben oder reicht das Protokoll?

Die Frage ist mir nicht ganz klar. Bitte anhand eines Beispiels verdeutlichen.

Gruß
Steffen

SPI = netfilter
NAT = Network Address Translation

SPI in Mikrotik RouterOS:

/ip firewall filter 
add chain=spi connection-state=established action=acc 
add chain=spi connection-state=related action=acc 
add chain=spi connection-state=invalid action=drop 
add chain=spi action=return

Danach bindet man den Chain einfach als erstes in die anderen Chains ein:

add chain=input action=jump to-chain=spi 
add chain=forward action=jump to-chain=spi

Gruß
Dobby

Hallo Steffen, hallo Dobby,

danke für Eure Antworten. Zu SPI und Nat werde ich mich mal in Ruhe einlesen. Danke für die Tipps und die Links.

Port-Scan habe ich gemacht - der sagt mir, es ist alles dicht, also entweder gefiltert oder geschlossen. Das Einzige, was noch offen war, war Port 80, den habe ich jetzt auch zugemacht.

bin ich mir nicht sicher, ob ether1 hier auch das PPPoE-Interface erfasst. Ich vermute, dass dies nicht so ist,
denn die öffentliche IP liegt bei Dir ja am PPPoE-Client an - nicht am ether1-Interface. Das müsstest Du also mal testen...

Da also alles "grün" ist, dürften sich Deine Bedenken hier erledigt haben.

Die Frage zu den Portangaben ist: Müssen die Config-Zeilen so lauten:

chain=input action=accept protocol=tcp in-interface=!ether1 dst-port=80,443
chain=input action=accept protocol=udp in-interface=!ether1 dst-port=53

oder was ist, wenn ich die Angabe dst-port=80,443 und dst-port=53 am Ende der Zeile weglasse?
Die Protokolle können doch auch andere Ports als die angegebenen verwenden und die sind dann ja nicht erfaßt.

Viele Grüße

Torsten

Zitat von @tomue58:
Die Frage zu den Portangaben ist: Müssen die Config-Zeilen so lauten:

chain=input action=accept protocol=tcp in-interface=!ether1 dst-port=80,443
chain=input action=accept protocol=udp in-interface=!ether1 dst-port=53

oder was ist, wenn ich die Angabe dst-port=80,443 und dst-port=53 am Ende der Zeile weglasse?
Die Protokolle können doch auch andere Ports als die angegebenen verwenden und die sind dann ja nicht erfaßt.

Weglassen bedeutet "any". Also "any tcp" und "any udp".
Ob das gewünscht ist oder nicht, ist eine rein inhaltliche Frage, die Du entscheiden musst!
Wenn Du es ohnehin so weit aufmachst, würde es auch genügen, nur den Zugriff vom WAN zum Router zu blocken und den Zugriff vom LAN zum Router gar nicht einzuschränken.

Gruß
sk

Nach Euren vielen (berechtigten) Bedenken habe ich nun doch auf dem PPPoE-Router alles dicht gemacht und baue mir für die Erreichbarkeit eine Tunnellösung.

Danke an Euch alle für die Hilfe.

Viele Grüße

Torsten

German solved Question MikroTik Other systems