[lug-ld] Ahnunghaber netfilter (iptables) gesucht

[Ekki Plicht (DF4OR)]

Hallo Peter,
danke für die Erläuterungen, das hilft mir. Und wie es der Zufall will -
den Abend, als ich meine Frage gepostet hatte, kam jemand vorbei der da
richtig Ahnung von hat und hat mir auch schon mal einiges gleich live am
Objekt zeigen können. Das, deine Posting und ein weiteren Posting off-list
hilft mir sehr.

Danke!

Gruß,
Ekki


Hakon Benner <hakon at halbrot.de> schrieb am Sa., 17. Feb. 2018 um 17:03 Uhr:

> Hi, ich muss gleich mal was klarstellen: Es gibt zwei Varianten, wie ich
> als Firewall auf etwas laut Policy unerlaubtes reagieren kann: Drop
> (verwerfen) oder reject (ablehnen; RST-ACK). Dabei ist drop das gleiche wie
> "nicht beantworten" und reject das, was du mit bewusst beschreibst, aber es
> ist kein bewusstes verwerfen, sondern ein bewusstes ablehnen.
>
> Für einen Scaner von außen auf einen bestimmten Service sieht drop genau
> so aus, wie wenn es den Service gar nicht gäbe und der Scanner läuft auf
> einen Timeout raus. Bei einem reject teilt man dem Scanner instantan mit,
> dass er den gescannten Service nicht erreichen darf.
>
> Das was ich oben geschrieben hab bezieht sich allerdings auf TCP. Bei UDP
> sieht es wieder etwas anders aus.
>
> In der Tabelle im folgenden Link ist das gut erklärt:
>
> https://www.secuvera.de/blog/nmap-ergebnisse-open-closed-openfiltered-eine-uebersicht/
>
> Gruß Hakon
>
> Am 17. Februar 2018 15:37:59 MEZ schrieb Peter Craciun <
> peter at fam-craciun.de>:
>
>> Hallo Ekki,
>>
>> ich beantworte mal einen Teil deiner Frage(n), dann kann jmd anderes den
>> Rest machen. ;-)
>>
>> filtered ist nicht schlimm. Bzw. das heißt, dass die die Pakete an einer
>> Stelle (in dem Fall eure FW) gedroppt (verworfen) werden. Vorher wurden
>> diese einfach nicht beantwortet. Jetzt werden sie bewusst verworfen.
>>
>> Bei den offene Ports ist immer die Frage ob man die braucht oder nicht.
>> Zu deinem Beispiel DNS: Muss nur offen sein, wenn man über den DNS auch
>> von außen etwas auflösen können soll. Grundsätzlich sind offene Ports
>> auch nicht böse, solange diese einen Zweck erfüllen und der Dienst der
>> hintendran steht ausreichend geschützt und gepatched ist.
>>
>> Zu dem scheinbar einzigen benötigten Port: 6000, der als X11
>> identifiziert wird.
>> Falls das wirklich X11 ist, habe im Hinterkopf, dass das nicht unbedingt
>> empfehlenswert ist (war), aber das ist schon sehr alt, ggf. hat sich da
>> auch einiges geändert in den letzten Jahren. Damals als ich mich mit dem
>> Thema auseinandergesetzt habe war es en vogue das über ssh zu machen,
>> dazu gib (gab es damals) auch fertige Lösungen mit Kompression und
>> anderen Dingen, die X11 (damals zumindest) nicht von Haus aus
>> mitgebracht hat.
>>
>>
>> Grüße
>>
>> Peter
>>
>> Am 14.02.2018 um 18:08 schrieb Ekki Plicht (DF4OR):
>>
>>  Tag.
>>>
>>>  Wie ihr wisst bin ich einer der gefährlichsten Menschen im Internet:
>>>  jemand mit gesundem Halbwissen :) Vor allem was Router betrifft.
>>>
>>>  Nun habe ich den zentralen Router unserer Firma in meiner Verantwortung.
>>>  Nachdem ich bei einem bestimmten Problem nicht weiterkam, hat sich heute
>>>  mal ein Supporter unseres lokalen Providers meine Konfiguration
>>>  angeguckt. Er hat erst gelacht, dann die Firewallregeln geändert, so das
>>>  es jetzt sicher sei, also kein unerlaubter Zugriff von Aussen möglich sei.
>>>
>>>  Ok, ich lerne ja gerne dazu.
>>>
>>>  Heute abend habe ich mal von zuhause aus einen Portscan auf unsere
>>>  public IP Adresse gemacht, und siehe da, etliche Ports im State
>>>  "filtered", drei sind "open", u.a. DNS (Port 53). WTF?
>>>
>>>  Oder verstehe ich da was falsch?
>>>
>>>
>>>  Hier das erste Resultat von nmap, mit den Filterregeln des Supporters.
>>>
>>>  root at grappa ~ # nmap wimo*********
>>>
>>>  Starting Nmap 7.60 ( https://nmap.org ) at 2018-02-14 17:45 CET
>>>  Nmap scan report for wimo******  (x.x.x.x)
>>>  Host is up (0.034s latency).
>>>  Not shown: 983 closed ports
>>>  PORT     STATE    SERVICE
>>>  22/tcp   filtered ssh
>>>  23/tcp   filtered telnet
>>>  53/tcp   open     domain
>>>  135/tcp  filtered msrpc
>>>  139/tcp  filtered netbios-ssn
>>>  161/tcp  filtered snmp
>>>  179/tcp  filtered bgp
>>>  445/tcp  filtered microsoft-ds
>>>  1900/tcp filtered upnp
>>>  2000/tcp open     cisco-sccp
>>>  2222/tcp filtered EtherNetIP-1
>>>  2323/tcp filtered 3d-nfsd
>>>  5998/tcp filtered ncd-diag
>>>  6001/tcp filtered X11:1
>>>  6002/tcp open     X11:2
>>>  7777/tcp filtered cbt
>>>  8291/tcp open     unknown
>>>
>>>  Nmap done: 1 IP address (1 host up) scanned in 13.41 seconds
>>>
>>>
>>>  Und hier das nmap-Resultat 'meiner' Filterregeln, die ich auch nur aus
>>>  dem Supportforum des Routerherstellers abgeschrieben habe.
>>>
>>>  root at grappa ~ # nmap wimo****
>>>
>>>  Starting Nmap 7.60 ( https://nmap.org ) at 2018-02-14 17:55 CET
>>>  Nmap scan report for wimo**** (x.x.x.x)
>>>  Host is up (0.031s latency).
>>>  Not shown: 999 filtered ports
>>>  PORT     STATE SERVICE
>>>  6002/tcp open  X11:2
>>>
>>>  Nmap done: 1 IP address (1 host up) scanned in 28.61 seconds
>>>
>>
>>>
>>>  Der Unterschied zwische den beiden Scans war nur, das ich 'seine' Regeln
>>>  disabled habe und 'meine' wieder enabled.
>>>
>>>  Sehe ich das richtig, das 'meine' Konfiguration besser greift? Oder
>>>  interpretiere ich da was falsch?
>>>
>>>  Was der offene Port 6002 da macht finde ich auch noch raus.
>>>
>>>  Ich wäre dankbar wenn sich mal jemand meldet der sich meine Filterregeln
>>>  anguckt, gerne vor Ort, gerne per Teamviewer, es darf auch Geld kosten.
>>>
>>>
>>>  Danke.
>>>  Ekki
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>>  lug-ld mailing list
>>>  lug-ld at lists.lug-ld.de
>>>  http://lists.lug-ld.de/mailman/listinfo/lug-ld
>>>
>>> ------------------------------
>>
>> lug-ld mailing list
>> lug-ld at lists.lug-ld.de
>> http://lists.lug-ld.de/mailman/listinfo/lug-ld
>>
>>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
> _______________________________________________
> lug-ld mailing list
> lug-ld at lists.lug-ld.de
> http://lists.lug-ld.de/mailman/listinfo/lug-ld
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://lists.lug-ld.de/pipermail/lug-ld/attachments/20180217/348ccbb8/attachment-0001.htm