nftables buggy?

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
Antworten
pepre
Beiträge: 83
Registriert: 30.06.2013 12:10:25

nftables buggy?

Beitrag von pepre » 23.03.2018 07:41:12

Hallo und guten Tag!

Nutzt hier jemand nftables?

Code: Alles auswählen

Mär 23 07:10:43 zaphod kernel: RSP: 002b:00007ffcac230fc8 EFLAGS: 00000246
Mär 23 07:10:43 zaphod kernel: INFO: task kworker/u32:9:286 blocked for more than 120 seconds.
Mär 23 07:10:43 zaphod kernel:       Tainted: G           O    4.14.0-0.bpo.3-amd64 #1 Debian 4.14.13-1~bpo9+1
Mär 23 07:10:43 zaphod kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mär 23 07:10:43 zaphod kernel: kworker/u32:9   D    0   286      2 0x80000000
Mär 23 07:10:43 zaphod kernel: Workqueue: netns cleanup_net
Mär 23 07:10:43 zaphod kernel: Call Trace:
Mär 23 07:10:43 zaphod kernel:  ? __schedule+0x3c8/0x850
Mär 23 07:10:43 zaphod kernel:  ? __schedule+0x3d0/0x850
Mär 23 07:10:43 zaphod kernel:  schedule+0x32/0x80
Mär 23 07:10:43 zaphod kernel:  schedule_preempt_disabled+0xa/0x10
Mär 23 07:10:43 zaphod kernel:  __mutex_lock.isra.1+0x2c6/0x4f0
Mär 23 07:10:43 zaphod kernel:  ? nft_unregister_afinfo+0x47/0x340 [nf_tables]
Mär 23 07:10:43 zaphod kernel:  nft_unregister_afinfo+0x47/0x340 [nf_tables]
Mär 23 07:10:43 zaphod kernel:  ? pcpu_free_area+0x261/0x2e0
Mär 23 07:10:43 zaphod kernel:  nf_tables_inet_exit_net+0x15/0x30 [nf_tables_inet]
Mär 23 07:10:43 zaphod kernel:  ops_exit_list.isra.6+0x33/0x60
Mär 23 07:10:43 zaphod kernel:  cleanup_net+0x1fe/0x300
Mär 23 07:10:43 zaphod kernel:  process_one_work+0x181/0x370
Mär 23 07:10:43 zaphod kernel:  worker_thread+0x4d/0x3c0
Mär 23 07:10:43 zaphod kernel:  kthread+0xfc/0x130
Mär 23 07:10:43 zaphod kernel:  ? process_one_work+0x370/0x370
Mär 23 07:10:43 zaphod kernel:  ? kthread_create_on_node+0x70/0x70
Mär 23 07:10:43 zaphod kernel:  ret_from_fork+0x1f/0x30
und

Code: Alles auswählen

Mär 23 07:06:42 zaphod kernel: INFO: task modprobe:1466 blocked for more than 120 seconds.
Mär 23 07:06:42 zaphod kernel:       Tainted: G           O    4.14.0-0.bpo.3-amd64 #1 Debian 4.14.13-1~bpo9+1
Mär 23 07:06:42 zaphod kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mär 23 07:06:42 zaphod kernel: modprobe        D    0  1466    284 0x80000000
Mär 23 07:06:42 zaphod kernel: Call Trace:
Mär 23 07:06:42 zaphod kernel:  ? __schedule+0x3c8/0x850
Mär 23 07:06:42 zaphod kernel:  schedule+0x32/0x80
Mär 23 07:06:42 zaphod kernel:  schedule_preempt_disabled+0xa/0x10
Mär 23 07:06:42 zaphod kernel:  __mutex_lock.isra.1+0x2c6/0x4f0
Mär 23 07:06:42 zaphod kernel:  ? __kmem_cache_alias+0x1a/0x30
Mär 23 07:06:42 zaphod kernel:  ? register_pernet_subsys+0x15/0x40
Mär 23 07:06:42 zaphod kernel:  register_pernet_subsys+0x15/0x40
Mär 23 07:06:42 zaphod kernel:  ? 0xffffffffc0e20000
Mär 23 07:06:42 zaphod kernel:  nf_ct_frag6_init+0x76/0xa0 [nf_defrag_ipv6]
Mär 23 07:06:42 zaphod kernel:  nf_defrag_init+0x6/0x1000 [nf_defrag_ipv6]
Mär 23 07:06:42 zaphod kernel:  ? 0xffffffffc0e20000
Mär 23 07:06:42 zaphod kernel:  do_one_initcall+0x4e/0x190
Mär 23 07:06:42 zaphod kernel:  ? __vunmap+0x71/0xb0
Mär 23 07:06:42 zaphod kernel:  do_init_module+0x5b/0x1f8
Mär 23 07:06:42 zaphod kernel:  load_module+0x25aa/0x2ce0
Mär 23 07:06:42 zaphod kernel:  ? SYSC_finit_module+0xd2/0x100
Mär 23 07:06:42 zaphod kernel:  SYSC_finit_module+0xd2/0x100
Mär 23 07:06:42 zaphod kernel:  system_call_fast_compare_end+0xc/0x6f
Mär 23 07:06:42 zaphod kernel: RIP: 0033:0x7f613a7181e9
Mär 23 07:08:43 zaphod kernel: RSP: 002b:00007ffcac230fc8 EFLAGS: 00000246
Immer und immer wieder im Log. Nachdem ich

Code: Alles auswählen

systemctl disable nftables
gemacht hatte, sind diese Meldungen nicht mehr aufgetaucht. Mit iptables gab's das nicht.

System: Stretch mit Kernel 4.14.0-0.bpo.3, AMD Ryzen 7 1700, und

Code: Alles auswählen

# lspci | grep -i eth
05:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
09:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
Ich dachte: bevor ich damit die LKML behellige frage ich lieber hier mal nach...

pepre
Beiträge: 83
Registriert: 30.06.2013 12:10:25

Re: nftables buggy?

Beitrag von pepre » 27.03.2018 07:27:57

Guten Morgen!

Dann gehe ich mal davon aus, dass niemand hier
  • die Fehlermeldungen bekommt
  • bzw nftables benutzt
Da das bereits bei modprobe passiert werde ich das als Bug betrachten.

TomL

Re: nftables buggy?

Beitrag von TomL » 27.03.2018 09:18:55

Ich hab's unter stretch genutzt.... und ich fand das richtig klasse. Mir kam das tatsächlich insgesamt als Verbesserung zu den iptables vor. Diese Logeinträge gab es bei mir jedoch nicht. Allerdings hatte ich ein mir unlösbares Problem mit den privacy extensions. Nach Ablauf der prefered lifetime war ipv6 'weg'. Das war reproduzierbar mit Aktivierung der Filter. Bei gleichem Filter mit Iptables besteht das Problem nicht. Deswegen bin ich auch erst mal wieder zurückgewechselt.

pepre
Beiträge: 83
Registriert: 30.06.2013 12:10:25

Re: nftables buggy?

Beitrag von pepre » 02.02.2019 20:11:39

Also, mit buster scheint es jetzt zu funktionieren :-)

Aber: weiß jemand, wie man mit nftables das recent-Zeug umsetzt? ZB:

Code: Alles auswählen

iptables -A ssh -m recent --name ssh --set
iptables -A ssh -m recent --name ssh --update --seconds 120 --hitcount 3 -j DROP
Ich finde nix dazu, oder verstehe es nicht ;-)

Und iptables-translate versagt völlig idF.

ReturnToSender
Beiträge: 123
Registriert: 23.10.2018 18:06:09

Re: nftables buggy?

Beitrag von ReturnToSender » 02.02.2019 21:07:47

pepre hat geschrieben: ↑ zum Beitrag ↑
02.02.2019 20:11:39
Also, mit buster scheint es jetzt zu funktionieren
Die sind nicht buggy, das funktioniert auch unter Stretch.
Aber: weiß jemand, wie man mit nftables das recent-Zeug umsetzt?
Ich finde nix dazu, oder verstehe es nicht
Unter welchen Bedingungen braucht man das überhaupt? Machen Limit-Rate und Burst nicht genau das gleiche?

pepre
Beiträge: 83
Registriert: 30.06.2013 12:10:25

Re: nftables buggy?

Beitrag von pepre » 02.02.2019 23:50:41

ReturnToSender hat geschrieben: ↑ zum Beitrag ↑
02.02.2019 21:07:47
Die sind nicht buggy, das funktioniert auch unter Stretch.
Bei mir gibt's unter Stretch Probleme, s.o. Kann aber auch an der HW liegen...
Unter welchen Bedingungen braucht man das überhaupt?
Gegen bestimmte Arten von Attacken wirkt das sehr gut, und viel schneller und sparsamer als fail2ban und allsowas.
Machen Limit-Rate und Burst nicht genau das gleiche?
Nein. Limit matched wohl nur auf alle Verbindungen, welche die definierten Kriterien erfüllen. Greift das Limit werden alle Verbindungen gedropped, obwohl bloß ein Bösewicht das Limit überschritten hat.

Außer man kann nft anweisen pro IP-Adresse (und ggf zusätzlichen Filtern) einen Counter auszuwerten. Da hab ich aber nix gefunden. Deshalb frage ich ja :-)

ReturnToSender
Beiträge: 123
Registriert: 23.10.2018 18:06:09

Re: nftables buggy?

Beitrag von ReturnToSender » 03.02.2019 17:48:10

Ich glaube, ich habe jetzt die Theorie des Problems verstanden... ich kapiere nur noch nicht so recht die praktische Relevanz.
pepre hat geschrieben: ↑ zum Beitrag ↑
02.02.2019 23:50:41
Machen Limit-Rate und Burst nicht genau das gleiche?
Nein. Limit matched wohl nur auf alle Verbindungen, welche die definierten Kriterien erfüllen. Greift das Limit werden alle Verbindungen gedropped, obwohl bloß ein Bösewicht das Limit überschritten hat.
Meiner Meinung nach betrifft das nicht alle Verbindungen, sondern nur NEU initiierte Verbindungen... diese Unterschiede kann ja imho der Conntrack-State regeln. Bestehende Verbindungen sind also davon nicht betroffen. Im Endeffekt bedeutet das, dass z.B. auch nur ein tatsächliches Syn-Flag-Flooding und das durchgehende Ignorieren von TCP-Reset beim Verbindungsversuch für die Dauer der Attacke neue Verbindungen blockieren würde. An der Stelle wäre dann statt Drop vielleicht auch TCP-Reset die bessere Alternative. Ich gehe ja davon aus, dass das in der Regel irgendwelche Automaten sind, die einen Connect-Versuch starten und sofort davon ablassen, wenn das nicht geht. Alles andere wäre ja sinnlos oder allenfalls vorsätzliches menschlich durchgeführtes Attackieren... aber das glaube ich eher nicht. Wenn man bei so etwas das Ziel wäre, also durch Menschen gezielt attackiert, hat man imho noch ganz andere Probleme.

Was ich oben mit praktischen Bezug meine, das ist die Frage: wie hoch kann die tatsächliche Anzahl von erlaubten neuen Verbindungsversuchen bezogen auf einen einzigen Moment sein, damit sich dieses vorübergehenden Blocken eines Ports auch wirklich negativ auf den Regelbetrieb für erlaubte Neu-Verbindungen auswirken könnte? Dabei ist das Verhältnis von z.B. Syn-Flood-Attacken zu regulären Neu-Verbindungen relevant. Im Regelfall wird man das doch gar nicht bemerken. Aber vielleicht denke ich auch nur in zu kleinem Maßstab.... was Du aber erklären könntest.
Außer man kann nft anweisen pro IP-Adresse (und ggf zusätzlichen Filtern) einen Counter auszuwerten. Da hab ich aber nix gefunden.
Wie soll das gehen? Die attackierende IP-Adresse ist ja vorher nicht bekannt.... die kann ja alles und nichts von nirgendwo und überall sein, heute so, morgen so. Das ist ja genau das, was in gewisserweise fail2ban tut, temporär blacklisten, nur eben nicht im Moment der Attacke, sondern nachgeschaltet. Aber wenn der Paketfilter sowas selber könnte, wäre fail2ban ja seit jeher unnütz.

pepre
Beiträge: 83
Registriert: 30.06.2013 12:10:25

Re: nftables buggy?

Beitrag von pepre » 03.02.2019 21:16:59

ReturnToSender hat geschrieben: ↑ zum Beitrag ↑
03.02.2019 17:48:10
[...] Aber wenn der Paketfilter sowas selber könnte, wäre fail2ban ja seit jeher unnütz.
Sozusagen :-D

fail2ban kann komplex auswerten (mit zB mit regulären Ausdrücken auf viele Logfiles).

Das tut man mit recent nicht, es ist eher im Bereich zwischen limit und fail2ban angesiedelt. Mit limit blockt man sehr viele, sehr schnelle Angriffe, dabei gehen aber auch die normalen Anfragen über den Jordan, es ist eine Notfallmaßnahme.

Das kann man mit recent vermeiden: es blockt nur die eine IP, die sich daneben benimmt. Aber man hat für die Filterregeln eben auch nur die bescheidene Auswahl von Netfilter an Kriterien für ein simples "Treffer pro Zeitfenster".

Ich kann nicht mit limit alle neuen Anfragen verwerfen, nur weil eine IP angreift.

ReturnToSender
Beiträge: 123
Registriert: 23.10.2018 18:06:09

Re: nftables buggy?

Beitrag von ReturnToSender » 03.02.2019 21:53:00

Ja, ich hatte die Funktion schon verstanden... alldieweil mir noch eine Betrachtung der praktischen Relevanz fehlt. Ich halte Lösungen, die sich mehr oder weniger mit theoretischen Problemen befassen, für meine Umgebung nicht zwingend für notwendig. Dazu waren ja die obigen Fragen, die mir im Kopf rumgingen.

Aber egal... soweit ich das verstanden habe, war recent unter iptables ein eigenes Kernel-Modul. Das ist mit den nftables anscheinend nicht mehr notwendig. Such mal nach "nftables hashlimits", darüber findest Du "Meters" und Flow-Tables. Ich denke, damit wirst Du das lösen können. Ich werde mir das morgen rein aus Neugier auch mal ansehen.

Wenn Du vorher eine funktionierende Lösung findest, wärs toll, wenn Du das hier posten würdest... ich würde das gerne mal eine Zeitlang auf den Prüfstand stellen. Wenns bei mir läuft, poste ich das natürlich auch. Vielleicht können wir uns dabei gegenseitig helfen.

pepre
Beiträge: 83
Registriert: 30.06.2013 12:10:25

Re: nftables buggy?

Beitrag von pepre » 04.02.2019 16:18:04

Code: Alles auswählen

tcp dport ssh counter packets 8 bytes 480
tcp dport ssh meter ssh-meter size 65535 { ip saddr timeout 10m limit rate over 3/minute}  counter packets 0 bytes 0 drop

Code: Alles auswählen

# nft list meter inet filter ssh-meter
table inet filter {
        meter ssh-meter {
                type ipv4_addr
                size 65535
                flags timeout
                elements = { 192.168.100.42 expires 9m10s156ms : limit rate over 3/minute }
        }
}
Hm :roll:

Die erste Regel sollte ja eigentlich nur zählen, und sonst nix, oder?!

Und dann sollte die zweite Regel greifen, und die "over"-Pakete droppen. Nix passiert aber...

Und ja, ich war schnell genug um in einer Minute mehr ssh connects zu machen... ;-)

Edith: das timeout funktioniert schon mal...

ReturnToSender
Beiträge: 123
Registriert: 23.10.2018 18:06:09

Re: nftables buggy?

Beitrag von ReturnToSender » 05.02.2019 11:12:33

Bei dem Beispiel sehe ich mehrere Probleme.... :roll:

Zum einen wäre der Aufbau imho falsch. Meiner Meinung nach müsste zuerst eine Regel stehen, die den erlaubten Traffic beschreibt. Und dann eine zweite, welche die Meter-Tabelle füllt und schließlich eine dritte, die Pakete mit SADDR aus der Meter-Tabelle drop't. Nur gibts dabei leider das Problem, dass "Meter" gar nicht für solche Absichten konzipiert ist. Man kann anscheinend nicht im Nachgang auf den Inhalt der Tabelle zugreifen. Ich habe das zuvor also leider falsch verstanden. Meter ist einfach nur ein Speed-Limiter, der Pakete fallen lässt, wenn Rate-Limits überschritten werden. Fallen lassen ist aber zumindest von der Intention her was anderes als Drop. Das Problem ist, es besteht hinterher keine Möglichkeit, auf den Content der Tabelle zuzugreifen, um darüber sowas wie ein temporäres Blacklisting durchzuführen.

Wie bin ich überhaupt darauf gekommen? Ich hatte mir vor längerem mal diese URL als Lesezeichen gesichert, aber nicht weiter verfolgt, weil ich darin für mich keine praktische Relevanz gesehen habe. Ich nutze ja auch kein fail2ban. In dem Link wird zunächst auf flow-tables hingewiesen, aber im weiteren Verlauf (From: James) auch auf eine tatsächlich funktionierende Lösung. Das heisst, da gibts ein Beispiel, welches tatsächlich temporär IPs blockt... den timeout kann man selber vorgeben. Ich habs getestet, es funktioniert wie gewünscht. Die Schlüsselworte lauten name-sets und elements.... damit geht das .... und das sogar wirklich einfach.

pepre
Beiträge: 83
Registriert: 30.06.2013 12:10:25

Re: nftables buggy?

Beitrag von pepre » 05.02.2019 18:02:21

Nein. Kuckst du (https://wiki.nftables.org/wiki-nftables ... php/Meters):
In this example we create a rule to match new ssh (port 22) connections, which uses a meter named ssh-meter to limit the traffic rate to 10 packets per second for each source IP address.
Gilt also für einzelne Addressen. Sehr schön.
Meiner Meinung nach müsste zuerst eine Regel stehen, die den erlaubten Traffic beschreibt.
Wenn ich den immer so genau bestimmen könnte, dann könnte ich den Rest ja schlicht droppen.

Wenn ich mich zB per SSH einloggen möchte, von irgendwoher, dann brauche ich eine Regel, die das erlaubt. Aber: ein Scriptkiddie bewirft mich mit zB 5 Versuchen in 10 Minuten. Jetzt gibt es aber 20 von diesen Blagen. Ergebnis: das auth.log ist voll mit dem Müll. Das kann ich aber mit recent bzw meter auf ein erträgliches Maß minimieren. Das ist quasi ein fail2ban auf Kernelebene, also sehr schnell und auch noch für schnellere Angriffe geeignet.

ReturnToSender
Beiträge: 123
Registriert: 23.10.2018 18:06:09

Re: nftables buggy?

Beitrag von ReturnToSender » 05.02.2019 18:22:39

pepre hat geschrieben: ↑ zum Beitrag ↑
05.02.2019 18:02:21
Gilt also für einzelne Addressen. Sehr schön.
Ich kenne die zitierte Seite natürlich, aber das ist nicht das, was Du willst. Wie ich sagte, das ist NUR ein Speed-Limiter. Ein Eintrag in dieser Tabelle bedeutet nicht, dass der Absender nicht weiter senden kann und das keine Pakete durchkommen... er kann ununterbrochen senden und alle Pakete kommen an, er darf nur nie das Limit überschreiten. Und wenn er das Limit überschreitet, werden Pakete einfach nur fallengelassen, aber der Absender wird nicht gebannt.
Meiner Meinung nach müsste zuerst eine Regel stehen, die den erlaubten Traffic beschreibt.
Wenn ich den immer so genau bestimmen könnte, dann könnte ich den Rest ja schlicht droppen.
Äh, das ist doch aber nicht wirklich kompliziert.... es ist doch bekannt, was man selber braucht.
Wenn ich mich zB per SSH einloggen möchte, von irgendwoher, dann brauche ich eine Regel, die das erlaubt. Aber: ein Scriptkiddie bewirft mich mit zB 5 Versuchen in 10 Minuten.
Ja, ich kenne auch dieses Problem. Das kannst Du aber schon ohne Paketfilter fast auf Null reduzieren, und zwar wenn der öffentliche Port irgendwas oberhalb von 50000 ist und dieser Port dann auf Port 22 des SSH-Servers weitergeleitet wird. Damit fällt das SSH-Grundrauschen des Webs fast völlig zusammen. Und das zweite ist, für den armseligen Rest und was eben genau Deinen Anspruch des temporären Banns tatsächlich erfüllt, sind Named Sets. Das entspricht ziemlich gut der früheren recent-Funktionalität..... nur eben deutlich eleganter. Im Grundegenommen ist damit fail2ban völlig überflüssig, man braucht diese umständlichen regexen für diverse Logs nicht mehr, man killt die unerwünschten Packets gleich am Eingang und packt sie temporär in einen Sack und vergisst sie.... und fertig. Ich würde hierbei sowieso nicht den SSH-Port regulieren, sondern noch früher anfangen, beim SYN-Flag.

pepre
Beiträge: 83
Registriert: 30.06.2013 12:10:25

Re: nftables buggy?

Beitrag von pepre » 05.02.2019 21:17:21

Ah!

Code: Alles auswählen

SET STATEMENT

The set statement is used to dynamically add or update elements in a set from the packet path.
The set setname must already exist in the given table. Furhermore, any set that will be dynamically
updated from the nftables ruleset must specify both a maximum set size (to prevent memory exhaustion)
and a timeout (so that number of entries in set will not grow indefinitely). The set statement can be used
to e.g. create dynamic blacklists.

{add | update} @setname { expression [timeout timeout] [comment string] }

    Example for simple blacklist

    # declare a set, bound to table "filter", in family "ip".  
    # Timeout and size are mandatory because we will add elements from packet path.
    nft add set ip filter blackhole "{ type ipv4_addr; flags timeout; size 65536; }"

    # whitelist internal interface.
    nft add rule ip filter input meta iifname "internal" accept

    # drop packets coming from blacklisted ip addresses.
    nft add rule ip filter input ip saddr @blackhole counter drop

    # add source ip addresses to the backlist if more than 10 tcp connection requests occured per second and ip address.
    # entries will timeout after one minute, after which they might be re-added if limit condition persists.
    nft add rule ip filter input tcp flags syn tcp dport ssh meter flood { ip saddr timeout 10s limit rate over 10/second} add @blackhole { ip saddr timeout 1m } drop

    # inspect state of the rate limit meter:
    nft list meter ip filter flood

    # inspect content of blackhole:
    nft list set ip filter blackhole

    # manually add two addresses to the set:
    nft add element filter blackhole { 10.2.3.4, 10.23.1.42 }
Quelle: https://www.netfilter.org/projects/nfta ... npage.html (Das Gute liegt so nah!)

Interessante Kombination :-)

ReturnToSender
Beiträge: 123
Registriert: 23.10.2018 18:06:09

Re: nftables buggy?

Beitrag von ReturnToSender » 06.02.2019 15:57:19

Es ist einigermaßen kompliziert, dazu eine allgemeingültige Aussage zu treffen, die schließlich auch wasserdicht ist. Ich kann zum folgenden Statement nur soviel sagen, dass ich das so definitiv nicht einsetzen würde:

Code: Alles auswählen

nft add rule ip filter input tcp flags syn tcp dport ssh meter flood { ip saddr timeout 10s limit rate over 10/second} add @blackhole { ip saddr timeout 1m } drop
Das ist für mich so ein typischer Fall, wo etwas nur deshalb gemacht wird, weils möglich ist.... aber nicht alles, was möglich ist, ist auch wirklich sinnvoll. Aber vielleicht ist es ja auch nur ein Anschauungsbeispiel, ohne sinnvollen praxisbezogenen Hintergrund. :roll: Es wird eine Tabelle eingerichtet und ständig mit laufenden Timer pro IP aktualisiert, die maximal pro IP nur einen Initialwert erhalten kann und danach für diese IP-Eintrag einfach sinnlos abläuft. Womit sie natürlich ihrer eigentlichen Bestimmung nicht mehr nachkommen kann. Das liegt daran, dass mit dem wichtigeren Eintrag zuvor

Code: Alles auswählen

nft add rule ip filter input ip saddr @blackhole counter drop
verhindert wird, dass überhaupt noch ein Paket bis zur Meter-Regel durchkommt. Und die Blackhole-Elemente haben darüber hinaus auch noch eigene Timer. Also kann man sich das auch komplett sparen. Das ließe sich imho wesentlich effektiver und mit geringerer Prozess-Belastung einfach mit Limit-Rate umsetzen.

Aber unberücksichtigt davon, funktionieren würde das wohl. Diese Entscheidung musst Du jedoch selber treffen... mir würde das so jedenfalls nicht genügen.

Antworten