hallo dozi,
>"... Keine Echo-Antwort auf Hirn, Gerät ist anscheind inaktiv..."
also probleme mit ping und inaktivem gerät hab ich nicht. wenn kein gerät vorliegt, erübrigt sich die pingerei...
die kritik ist nur ironisch formuliert, wir wollen ja auch was zum lachen haben- trotz deiner unangenehmen situation.
nichtsdestotrotz bleibt sie inhaltlich voll aufrecht. die zyxel'sche firewall verstößt gegen 2 elementare grundprinzipien zur konfiguration von firewalls, die da lauten:
1. einfachheiteine firewall sollte innerhalb einer vorgegebenen sicherheitspolitik möglichst einfach formuliert werden.
die gründe sind klar:
- jede regel enthält einen matcher, und der router muß für jedes paket nachrechnen, ob ein match vorliegt.
mit zunehmender regelanzahl steigt der beschäftigungsgrad und resourcenbedarf des router.
- das konfigurationsrisiko steigt mit zunehmender komplexität der firewall:
fängt schon bei banalen tippfehlern an und hört bei logischen fehlern auf.
- reaktionszeit bei problemen:
sollte klar sein- eine firewall mit hausnummer 10 regeln ist schneller gesichtet und korrigiert als eine mit 50.
schau dir z.b. mal die 2. regel der input chain an:
der counter steht auf 3768. der router hat also 3768x erfolgreich proto=tcp festgestellt und diese 3768 pakete in die subchain VOIP_INPUT geschickt, wo aber auf udp geprüft wird, d.h. der akkumulierte vergleich kann nie positiv ausfallen (quanteneffekte laß ma jetzt ausnahmsweise mal außen vor
). bedeutet somit weiter, daß 2x3768 = 7536x ins leere gerechnet wurde.
du wirst mir jetzt möglicherweise haarscharf sagen:"heast, oida, moch da net ins hemd. mia redn über 3768 packerl. is des net wuascht?" nö, die 3768 sind ca. 50% der input packerl, und wenn ein router wegen einer verkonfigurierten firewall völlig unnötig für 50% der packerl ins leere rechnet, dann is das überhaupt nimmer wuascht.
ähnlich verhält es sich btw. mit der regel 3, und am krassesten ist die forward chain. die könnte bei einem genatteten zugang leer bleiben. d.h. der rechenaufwand, der durch die forward chain verursacht wird, is zu 100% für die fisch.
2. die reihung der regeln ist bei sicherheitstechnischer äquivalenz nach fallender trefferwahrscheinlichkeit vorzunehmenliest sich jetzt vielleicht im ersten moment etwas kompliziert, is aber ganz einfach. es geht hier um effizienz.
das prinzip lautet: je früher ein hit desto geringer der rechenaufwand. dabei darf natürlich das vorgegebene sicherheitskonzept nicht aufgeweicht werden.
zur illustration wieder eine regel aus deiner zyxel firewall:
es geht um die erste regel der subchain FW_GENERAL_INPUT:
- Code: Alles auswählen
1 1487 200K ACCEPT all -- !br+ * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
diese regel steht relativ zur input chain inkl. jumps an 37. stelle (wenn ich mich nicht verzählt hab), und auf dieser regel liegen immerhin 1487 hits. d.h. es waren insgesamt (37-1) x 1487 = 36 x 1487 = 53532 erfolglose tests notwendig, um auf dieses erfolgreiche accept zu kommen. stünde diese regel an erster stelle, dann wären (1-1) x 1487 = 0 x 1487 = 0 erfolglose tests notwendig, um zum selben resultat zu kommen. und das ganze bitte, *ohne beim sicherheitskonzept nachzulassen*, alles andre wär ja witzlos.
daß es auch anders geht, wird einem sehr eindrucksvoll z.b. von den mikrotik/routeros entwicklern vor augen geführt.
(kleine nebenbemerkung , falls dir "mikrotik/routeros" kein begriff ist: das sind sehr nette geräte, die zu meinen lieblingsspielzeugen gehören).
das default setup schaut ca. so aus (hab grad auf einem gerät mit der r5.23 nachgeschaut):
1. ethport1 ist wan, heißt ether1-gateway und wird mit dhcp konfiguriert. alle andren ports sind lan.
2. die firewall im iptables jargon:
- Code: Alles auswählen
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -m conntrack --cstate ESTABLISHED -j ACCEPT
iptables -A INPUT -m conntrack --cstate RELATED -j ACCEPT
iptables -A INPUT -i ether1-gateway -j DROP
iptables -t nat -A POSTROUTING -o ether1-gateway -j MASQUERADE
forward und output chain sowie die mangle table sind leer
insgesamt also inkl. masquerading 5 regeln, und diese firewall ist sicher und effizient. durch ihre einfachheit sieht man auf einen blick, daß da nix anbrennen kann. da brauchts keine tulpen, portscans, logs und wwi.
>"...Also willst mir sagen das mein Firewall des ZsXEL Router für denn A***h ist und ein reines Sicherheitsrisiko..."
das sicherheitsrisiko kann man ohne kenntnis der mangle table gar nicht genau abschätzen, weil die input chain über firewall marker (ich nenn die dinger ab jetzt fwmark[s] und komm dann weiter unten noch auf die details zurück) gesteuert wird, die in der prerouting oder input chain der mangle table gesetzt werden. genaugenommen gehts um diese doppelt gemoppelte sequenz (sehr sinnvoll btw.) der chain FW_GENERAL_INPUT:
- Code: Alles auswählen
...
7 0 0 ACCEPT !esp -- !br+ * 0.0.0.0/0 0.0.0.0/0 MARK match 0x10000000/0x10000000
8 0 0 ACCEPT !ah -- !br+ * 0.0.0.0/0 0.0.0.0/0 MARK match 0x10000000/0x10000000
...
...
11 0 0 ACCEPT !esp -- !br+ * 0.0.0.0/0 0.0.0.0/0 MARK match 0x10000000/0x10000000
12 0 0 ACCEPT !ah -- !br+ * 0.0.0.0/0 0.0.0.0/0 MARK match 0x10000000/0x10000000
wirklich schlagend für deine tulpen (=aktive tcp- und udp-dienste deines zyx) ist die regel 7, die andren 3 regeln sind für die fisch. und im hinblick auf deine tulpen sieht die situation aktuell so aus:
aktive tcp-dienste: tcp/21, 22, 23, 53, 80, 263, 443, 5916, 30005, 44401
wanseitig sicher offen: tcp/30005 (deine recherchen)
wanseitig gefiltert: tcp/21, 22, 23, 80, 443 (sieht man an den stats der chain SERVICE_CONTROL)
wanseitig unklarer status: tcp/263, 5916, 44401
aktive udp-dienste: udp/53, 67, 69, 263, 5098, 5099, 5100, 8011, 8012, 38000, 38032, 42000, 42032, 43000, 50000, 50032
wanseitig unklarer status: alle aktiven dienste
d.h. du mußt in der mangle table nachschauen, ob bzw. welche dienste mit wanseitig unklarem status mit fwmarks aus der menge 0x10000000/0x10000000 markiert werden.
falls dir die rumwühlerei in der mangle table zu nervig is, kannst du die ungefilterten ports auch mit einem portscanner *von außen* eruieren, wobei du bei udp a bizzi aufpassen mußt, weil open und filtered bei udp nicht unterscheidbar sind. der udp-scan rennt so ab:
1. du setzt vor dem enddropper der input chain eine logging-regel:
- Code: Alles auswählen
iptables -I INPUT 9 -i ppp1.1 -p udp -j LOG --log-prefix "IN-UDP-FILTERED"
2. udp-scan für
udp/53, 67, 69, 263, 5098, 5099, 5100, 8011, 8012, 38000, 38032, 42000, 42032, 43000, 50000, 50032
durchführen.
3. jene ports, die im output von
- Code: Alles auswählen
grep "IN-UDP-FILTERED" /var/log/messages
aufscheinen, sind filtered, jene, die nicht aufscheinen, sind open.
details zu den fwmarks:
fwmarks sind einfach numerierte etiketten, die man in der mangle table nach irgendwelchen kriterien an die packerl nageln kann, um sie dann in der filter oder nat table zur steuerung der firewall oder mit iproute2 zur formulierung von komplexeren routing policies zu verwenden. um irgendwelche fwmark-basierte filterkriterien überhaupt formulieren zu können, muß man die fwmarks als menge charakterisieren. und diese charakterisierung erfolgt in form eines kürzels, das das format
zielwert/mask
hat. dieses format schaut im ersten moment vielleicht a bißl esoterisch aus, is aber völlig unspannend. kennst du von der charakterisierung von ip-netzen. wenn ich z.b. von 10.0.0.0/26 rede, dann weißt du sofort, daß ich die menge
{10.0.0.0, 10.0.0.1,...10.0.0.63} meine. und genau so verhält es sich mit den fwmarks:
ein fwmark-basiertes filterkriterium ist genau dann wahr, wenn
fwmark-von-paket AND mask = zielwert
gilt.dazu ein kleines beispiel:
du willst aus irgendwelchen gründen 3 regeln in die chain my_chain einfügen, die folgendes leisten sollen:
- regel1 soll zutreffen für fwmarks <= 3 und dann target1 ausführen.
- regel2 soll zutreffen für alle ungeraden fwmarks mit 4 <= fwmark <= 15 und dann target2 ausführen.
- regel3 soll zutreffen für alle geraden fwmarks mit 4 <= fwmark <= 15 und dann target3 ausführen.
um dieses regelwerk zu setzen, verwendest du genau das kürzel von oben:
- Code: Alles auswählen
iptables -A my_chain -j target1 -m mark --mark 0x0/0xc
iptables -A my_chain -j target2 -m mark --mark 0x1/0x1
iptables -A my_chain -j target3 -m mark --mark 0x0/0x1
so, und jetzt schau ma, was passiert:
1. ein paket mit fwmark=1 kommt rein:
fwmark AND mask = 1 AND 0xc = 0001 AND 1100 = 0000 = 0x0 = zielwert1 => true => jump to target1.
2. ein paket mit fwmark=2 kommt rein:
fwmark AND mask = 2 AND 0xc = 0010 AND 1100 = 0000 = 0x0 = zielwert1 => true => jump to target1.
3. ein paket mit fwmark=3 kommt rein:
fwmark AND mask = 3 AND 0xc = 0011 AND 1100 = 0000 = 0x0 = zielwert1 => true => jump to target1.
4. ein paket mit fwmark=4 kommt rein:
fwmark AND mask = 4 AND 0xc = 0100 AND 1100 = 0100 = 0x4 != zielwert1 => false => go to rule2
- rule2
fwmark AND mask = 4 AND 0x1 = 0100 AND 0001 = 0000 = 0x0 != zielwert2 => false => go to rule3
- rule3
fwmark AND mask = 4 AND 0x1 = 0100 AND 0001 = 0000 = 0x0 = zielwert3 => true => jump to target3
5. ein paket mit fwmark=5 kommt rein:
fwmark AND mask = 5 AND 0xc = 0101 AND 1100 = 0100 = 0x4 != zielwert1 => false => go to rule2
- rule2
fwmark AND mask = 5 AND 0x1 = 0101 AND 0001 = 0001 = 0x1 = zielwert2 => true => jump to target2
...
... usw.
alles klaro in der birno?
>"...Soll ich das Teil jetzt mit Benzin übergießen und anzünden oder wie soll ich das verstehen! Hey anzünden das wäre dann mal wortwörtlich gemeinte (Fire)wall..."
jaaa, die idee kann was. ein router, der net brennt, is sowieso urfad...
doch spaß beiseite. ich denke, du wirst ein mehrphasenprogramm fahren müssen:
1. rausfinden, obs außer dem tcp/30005 noch andre offene ports gibt -> s. o.
2. alle offenen ports schließen, egal ob sich diese einstellungen jetzt sichern lassen oder nicht.
3. feature request bei zyxel: lokale einstellungen, die auf der shell vorgenommen wurden, sollen gesichert werden können.
potentielle kandidaten sind dateien unter /data, die dann beim start ausgeführt werden müssen, oder nvram-variablen nach dem schema von openwrt, dd-wrt, tomato...
lg
zid
Die M4tr1x-Trilogie 
ich bin so ein D**p ich kann ewig drin sein 
nur echo && bash eingeben und abgeht es halt busybox und env dann die auflistung ls -l alles prima, dann hab ich jetzt auch denn Supervisor Daten auch schon. Nur sagen die richtige befehl damit ich die änderung die ich in IPTables vornehmen würklich gespeichert werden und auch bei reboot, ein/ausschaltung oder stromausfall dann auch klappt und die einstellung behält! 
er hat sich doch aus der busybox nach ne minute gehaut dachte ohne idle einstellung muss das gehen 
obwohl da iptables läuft und einige verzeichnisse gibt! Angeblich muss man denn irgendwie implentieren bzw. installieren denn iptables-save und iptables-restore. Wie geht das denn! Hab aber auch irgendwo gelesen das gewisse router von zyxel und durch denn kernel oder so nicht geht und dann eher die Konfigdatei also direkt die datei editieren muss und abspeichern weis nicht wo die datei von iptables ist und wie die heißt und ob es mit .sh oder .conf oder was auch immer heißt und wie man das dann anders abspeicher! 
