Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > ger.ct > #628653 > unrolled thread
| Started by | Matthias Hanft <mh@hanft.de> |
|---|---|
| First post | 2024-10-19 10:27 +0200 |
| Last post | 2024-10-27 11:54 +0000 |
| Articles | 20 on this page of 86 — 15 participants |
Back to article view | Back to ger.ct
Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-19 10:27 +0200
Re: Kein Routing zu www.telekom.de "Dr. Joachim Neudert" <neudert@5sl.org> - 2024-10-19 10:37 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-19 11:59 +0200
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-19 10:39 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-19 11:47 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-19 12:13 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-19 12:42 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-19 14:02 +0200
Re: Kein Routing zu www.telekom.de Joerg Walther <joerg.walther@magenta.de> - 2024-10-19 15:01 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-19 17:42 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-19 17:41 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-20 07:32 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-20 08:29 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-20 10:56 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-20 11:19 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-20 11:41 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-20 12:04 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-20 12:44 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-20 14:55 +0200
Re: Kein Routing zu www.telekom.de Michael Zink <michael@swamp.franken.de> - 2024-10-20 15:55 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-20 16:05 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-20 16:29 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-20 16:27 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-20 17:08 +0200
Re: Kein Routing zu www.telekom.de Michael Zink <michael@swamp.franken.de> - 2024-10-20 21:06 +0200
Re: Kein Routing zu www.telekom.de Hartmut Ott <hottm@arcor.de> - 2024-10-21 12:51 +0200
Re: Kein Routing zu www.telekom.de Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-21 18:41 +0200
Re: Kein Routing zu www.telekom.de Hartmut Ott <hottm@arcor.de> - 2024-10-22 15:07 +0200
Re: Kein Routing zu www.telekom.de Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-22 16:44 +0200
Re: Kein Routing zu www.telekom.de Hartmut Ott <hottm@arcor.de> - 2024-10-23 14:35 +0200
Re: Kein Routing zu www.telekom.de Jochen Kremer <jochen.news@kremerweb.de> - 2024-10-23 14:46 +0200
Re: Kein Routing zu www.telekom.de Dr. Joachim Neudert <neudert@5sl.org> - 2024-10-23 17:07 +0000
Re: Kein Routing zu www.telekom.de Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-24 12:02 +0200
Re: Kein Routing zu www.telekom.de Joerg Walther <joerg.walther@magenta.de> - 2024-10-20 16:52 +0200
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-20 15:30 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-20 16:31 +0200
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-20 11:34 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-20 11:51 +0200
Re: Kein Routing zu www.telekom.de Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-10-20 14:21 +0000
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-20 16:32 +0200
Re: Kein Routing zu www.telekom.de Michael Zink <michael@swamp.franken.de> - 2024-10-19 14:02 +0200
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-19 16:28 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-19 11:57 +0200
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-19 12:14 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-19 12:30 +0200
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-19 16:25 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-19 16:41 +0200
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-19 17:53 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-20 07:39 +0200
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-20 10:26 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-20 11:15 +0200
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-20 11:31 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-20 12:28 +0200
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-20 19:06 +0200
Re: Kein Routing zu www.telekom.de Jörg Tewes <jogi1964@gmx.net> - 2024-10-19 21:56 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-20 07:43 +0200
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-20 10:26 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-19 12:44 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-19 14:05 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-19 18:06 +0200
Re: Kein Routing zu www.telekom.de Michael Zink <michael@swamp.franken.de> - 2024-10-19 14:02 +0200
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-19 16:26 +0200
Re: Kein Routing zu www.telekom.de Michael Zink <michael@swamp.franken.de> - 2024-10-19 21:38 +0200
Re: Kein Routing zu www.telekom.de Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-19 16:41 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-19 17:45 +0200
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-19 17:54 +0200
Re: Kein Routing zu www.telekom.de Michael Zink <michael@swamp.franken.de> - 2024-10-19 21:46 +0200
Re: Kein Routing zu www.telekom.de Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-20 14:59 +0200
Re: Kein Routing zu www.telekom.de Michael Zink <michael@swamp.franken.de> - 2024-10-20 15:56 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-20 16:06 +0200
Re: Kein Routing zu www.telekom.de Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-21 09:31 +0200
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-21 11:13 +0200
Re: Kein Routing zu www.telekom.de Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2024-10-21 11:49 +0200
Re: Kein Routing zu www.telekom.de Jörg Tewes <jogi1964@gmx.net> - 2024-10-19 21:48 +0200
Re: Kein Routing zu www.telekom.de Rick Szabo <rickszabo@web.de> - 2024-10-19 20:07 +0000
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-25 18:18 +0200
Re: Kein Routing zu www.telekom.de Michael Bode <m.g.bode@web.de> - 2024-10-25 23:01 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-26 09:13 +0200
Re: Kein Routing zu www.telekom.de Marco Moock <mm+solani@dorfdsl.de> - 2024-10-26 12:08 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-26 13:02 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-26 12:20 +0200
Re: Kein Routing zu www.telekom.de Matthias Hanft <mh@hanft.de> - 2024-10-26 13:04 +0200
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-26 13:59 +0200
Re: Kein Routing zu www.telekom.de Dr. Joachim Neudert <neudert@5sl.org> - 2024-10-26 18:30 +0000
Re: Kein Routing zu www.telekom.de Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-10-27 10:52 +0100
Re: Kein Routing zu www.telekom.de Dr. Joachim Neudert <neudert@5sl.org> - 2024-10-27 11:54 +0000
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Michael Zink <michael@swamp.franken.de> |
|---|---|
| Date | 2024-10-19 14:02 +0200 |
| Message-ID | <lnhldnF2qr8U2@mid.individual.net> |
| In reply to | #628656 |
On Sat, 19 Oct 2024 11:47:11 +0200, Matthias Hanft wrote: >Google hat mir inzwischen das hier geliefert, wo es bereits diskutiert wurde >(aufm Handy konnte ich es erreichen und lesen): >https://telekomhilft.telekom.de/t5/Festnetz-Internet/Problem-mit-Telekom-de-Webseite-nicht-erreichbar/m-p/6980416 >aber eine Lösung scheints bislang auch nicht zu geben. Auch diese Seite konnte ich gerade problemlos aufrufen. Auf Wiederlesen Michael -- Das Internet darf kein GRUNDrechtsfreier Raum werden!
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mm+solani@dorfdsl.de> |
|---|---|
| Date | 2024-10-19 16:28 +0200 |
| Message-ID | <vf0fls$k69f$5@solani.org> |
| In reply to | #628666 |
Am 19.10.2024 14:02 Uhr schrieb Michael Zink: > On Sat, 19 Oct 2024 11:47:11 +0200, Matthias Hanft wrote: > > >Google hat mir inzwischen das hier geliefert, wo es bereits > >diskutiert wurde (aufm Handy konnte ich es erreichen und lesen): > >https://telekomhilft.telekom.de/t5/Festnetz-Internet/Problem-mit-Telekom-de-Webseite-nicht-erreichbar/m-p/6980416 > >aber eine Lösung scheints bislang auch nicht zu geben. > > Auch diese Seite konnte ich gerade problemlos aufrufen. Die wird auch über Amazon bereitgestellt, ergo völlig anderes Netz. 2600:9000:26e8:a600:3:5126:fb00:93a1 -- Gruß Marco Spam und Werbung bitte an 1729339330ichwillgesperrtwerden@nirvana.admins.ws
[toc] | [prev] | [next] | [standalone]
| From | Dietz Proepper <dietz.usenet@rotfl.franken.de> |
|---|---|
| Date | 2024-10-19 11:57 +0200 |
| Message-ID | <20241019115739.2f405e4e.dietz.usenet@rotfl.franken.de> |
| In reply to | #628653 |
Matthias Hanft <mh@hanft.de> wrote:
> seit ein paar Tagen (oder länger), als ich mal wieder meine
> Telekom-Rechnung runterladen wollte, ging die Seite nicht - Timeout.
Du hast nicht zufällig irgendein DefenderKasperskyNorton-Schlangenöl
o.ä. installiert?
https://www.telekom.de tut "hier" gerade einwandfrei.
> traceroute
> to www.telekom.de (80.158.67.40), 30 hops max, 60 byte packets 1 fritz7590.local (10.15.5.1) 0.493 ms 0.444 ms 0.682 ms
> 2 62.156.244.6 (62.156.244.6) 7.900 ms 8.019 ms 8.213 ms
> 3 62.156.247.226 (62.156.247.226) 8.685 ms 8.940 ms 9.377 ms
> 4 m-eb13-i.M.DE.NET.DTAG.DE (217.5.69.78) 13.432 ms 16.330 ms
> 16.302 ms 5 87.190.235.69 (87.190.235.69) 16.272 ms !X * *
Heutzutage komplett üblich - man versteht seine Technik nicht mehr und
blockt daher einfach $alles.
ICMP-Echo haben sie auch geblockt. Sind halt die Besten der Besten der
Besten, SIR!
> Liegts an mir? An der Telekom? An sonst wem? Von ein paar Kumpels aus
> (bei anderen Providern) funktioniert's. Was kann ich sonst noch tun?
> (*)
Nur um Unklarheiten auszuschließen, https://www.telekom.de
bringt bei Dir nach 10s+ einen Timeout? VOn verschiedenen Geräten, auch
über Mobilfunk?
> (*) nein, die "Störungsstelle" anrufen ist nicht wirklich eine Option,
> wenn man da bei einem indischen Studenten im First-Level-Support
> landet, der überhaupt nicht kapiert, um was es geht, und einem von
> seiner Liste runterbetet, dass man erst seinen Router neu starten
> soll und dann einen Techniker vorbeischicken will...
Meine letzten "Störungen" betrafen alle Mobilfunk. Dort waren
lustigerweise die letzten drei Mal "Einheimische" mit für 1st level
recht brauchbarer Ausbildung anzutreffen. Einmal war 2nd level nötig
("der ruft Sie innerhalt von 30min zurück".) Es hat dann 35min gedauert,
bassd.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled. - Richard P. Feynman, 1987
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mm+solani@dorfdsl.de> |
|---|---|
| Date | 2024-10-19 12:14 +0200 |
| Message-ID | <vf00pn$k69f$2@solani.org> |
| In reply to | #628657 |
Am 19.10.2024 11:57 Uhr schrieb Dietz Proepper: > Matthias Hanft <mh@hanft.de> wrote: > > seit ein paar Tagen (oder länger), als ich mal wieder meine > > Telekom-Rechnung runterladen wollte, ging die Seite nicht - > > Timeout. > > Du hast nicht zufällig irgendein DefenderKasperskyNorton-Schlangenöl > o.ä. installiert? Ich nicht und hier aus dem AS8820 gibt es das selbe Problem. > https://www.telekom.de tut "hier" gerade einwandfrei. > > > traceroute > > to www.telekom.de (80.158.67.40), 30 hops max, 60 byte packets 1 fritz7590.local (10.15.5.1) 0.493 ms 0.444 ms 0.682 ms > > 2 62.156.244.6 (62.156.244.6) 7.900 ms 8.019 ms 8.213 ms > > 3 62.156.247.226 (62.156.247.226) 8.685 ms 8.940 ms 9.377 ms > > 4 m-eb13-i.M.DE.NET.DTAG.DE (217.5.69.78) 13.432 ms 16.330 ms > > 16.302 ms 5 87.190.235.69 (87.190.235.69) 16.272 ms !X * * > > Heutzutage komplett üblich - man versteht seine Technik nicht mehr und > blockt daher einfach $alles. Hier wird ein hoher UDP-Port blockiert, was völlig normal ist bei nem Webserver. Vorbildlich ist, dass es ein ICMP-Paket als Antwort gibt (!X, siehe die traceroute-Manpage). > ICMP-Echo haben sie auch geblockt. Sind halt die Besten der Besten der > Besten, SIR! Hier bekomme ich keine Antwort, ebenso wie bei TCP 80 und 443. -- Gruß Marco Spam und Werbung bitte an 1729331859ichwillgesperrtwerden@nirvana.admins.ws
[toc] | [prev] | [next] | [standalone]
| From | Dietz Proepper <dietz.usenet@rotfl.franken.de> |
|---|---|
| Date | 2024-10-19 12:30 +0200 |
| Message-ID | <20241019123058.4de3d84d.dietz.usenet@rotfl.franken.de> |
| In reply to | #628660 |
Marco Moock <mm+solani@dorfdsl.de> wrote: > Am 19.10.2024 11:57 Uhr schrieb Dietz Proepper: > > > Matthias Hanft <mh@hanft.de> wrote: > > > traceroute > > > to www.telekom.de (80.158.67.40), 30 hops max, 60 byte packets 1 fritz7590.local (10.15.5.1) 0.493 ms 0.444 ms 0.682 ms > > > 2 62.156.244.6 (62.156.244.6) 7.900 ms 8.019 ms 8.213 ms > > > 3 62.156.247.226 (62.156.247.226) 8.685 ms 8.940 ms 9.377 ms > > > 4 m-eb13-i.M.DE.NET.DTAG.DE (217.5.69.78) 13.432 ms 16.330 ms > > > 16.302 ms 5 87.190.235.69 (87.190.235.69) 16.272 ms !X * * > > > > Heutzutage komplett üblich - man versteht seine Technik nicht mehr > > und blockt daher einfach $alles. > > Hier wird ein hoher UDP-Port blockiert, was völlig normal ist bei nem > Webserver. Ja. Heutzutage. Man versteht halt seine Technik nicht mehr. Und das aktuelle Schlangenöl vermutet dahinter einen ANGRIFF!!111 > Vorbildlich ist, dass es ein ICMP-Paket als Antwort gibt > (!X, siehe die traceroute-Manpage). Noch vorbildlicher wäre, die "interessanten" udp-Ranges für "passende" Pakete vom Filtern auszunehmen. > > ICMP-Echo haben sie auch geblockt. Sind halt die Besten der Besten > > der Besten, SIR! > > Hier bekomme ich keine Antwort, ebenso wie bei TCP 80 und 443. Hmm. Aus AS3320 habe ich offenbar keine Probleme. RIPE behauptet auch, dass AS34086 global erreichbar sei, https://stat.ripe.net/ui2013/widget/routing-status#w.resource=80.158.67.40 -- For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. - Richard P. Feynman, 1987
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mm+solani@dorfdsl.de> |
|---|---|
| Date | 2024-10-19 16:25 +0200 |
| Message-ID | <vf0fhi$k69f$3@solani.org> |
| In reply to | #628661 |
Am 19.10.2024 12:30 Uhr schrieb Dietz Proepper: > Marco Moock <mm+solani@dorfdsl.de> wrote: > > > Am 19.10.2024 11:57 Uhr schrieb Dietz Proepper: > > > > > Matthias Hanft <mh@hanft.de> wrote: > > > > traceroute > > > > to www.telekom.de (80.158.67.40), 30 hops max, 60 byte packets 1 fritz7590.local (10.15.5.1) 0.493 ms 0.444 ms 0.682 ms > > > > 2 62.156.244.6 (62.156.244.6) 7.900 ms 8.019 ms 8.213 ms > > > > 3 62.156.247.226 (62.156.247.226) 8.685 ms 8.940 ms 9.377 > > > > ms 4 m-eb13-i.M.DE.NET.DTAG.DE (217.5.69.78) 13.432 ms > > > > 16.330 ms 16.302 ms 5 87.190.235.69 (87.190.235.69) 16.272 ms > > > > !X * * > > > > > > Heutzutage komplett üblich - man versteht seine Technik nicht mehr > > > und blockt daher einfach $alles. > > > > Hier wird ein hoher UDP-Port blockiert, was völlig normal ist bei > > nem Webserver. > > Ja. Heutzutage. Man versteht halt seine Technik nicht mehr. Erkläre das bitte. Ich wüsste nicht, warum ein Webserver, der per tcp 80/443 kommuniziert, UDP-Pakete von außen annehmen sollte (es sei denn, er hat die Verbindung selbst aufgebaut). > Und das aktuelle Schlangenöl vermutet dahinter einen ANGRIFF!!111 Ist dem noch so? Ich hatte bisher mit so Software nix zu tun. > > Vorbildlich ist, dass es ein ICMP-Paket als Antwort gibt > > (!X, siehe die traceroute-Manpage). > > Noch vorbildlicher wäre, die "interessanten" udp-Ranges für "passende" > Pakete vom Filtern auszunehmen. Inwiefern sind das passende Pakete? Als passend würde ich all das bezeichnen, was der Server selbst angefordert hat. Der Rest wird halt abgelehnt. > > > ICMP-Echo haben sie auch geblockt. Sind halt die Besten der Besten > > > der Besten, SIR! > > > > Hier bekomme ich keine Antwort, ebenso wie bei TCP 80 und 443. > > Hmm. Aus AS3320 habe ich offenbar keine Probleme. RIPE behauptet auch, > dass AS34086 global erreichbar sei, > https://stat.ripe.net/ui2013/widget/routing-status#w.resource=80.158.67.40 Von mir aus (AS8820) ist die IP nicht erreichbar, weder per ICMP noch per TCP auf Port 443. Die letzte Antwort kommt von 8 m-eb13-i.M.DE.NET.DTAG.DE (217.5.69.70) 20.073 ms 19.547 ms 19.559 ms -- Gruß Marco Spam und Werbung bitte an 1729333858ichwillgesperrtwerden@nirvana.admins.ws
[toc] | [prev] | [next] | [standalone]
| From | Dietz Proepper <dietz.usenet@rotfl.franken.de> |
|---|---|
| Date | 2024-10-19 16:41 +0200 |
| Message-ID | <20241019164155.19d96f28.dietz.usenet@rotfl.franken.de> |
| In reply to | #628677 |
Marco Moock <mm+solani@dorfdsl.de> wrote: > Am 19.10.2024 12:30 Uhr schrieb Dietz Proepper: > > > Marco Moock <mm+solani@dorfdsl.de> wrote: > > > > > Am 19.10.2024 11:57 Uhr schrieb Dietz Proepper: > > > > > > > Matthias Hanft <mh@hanft.de> wrote: > > > > > traceroute > > > > > to www.telekom.de (80.158.67.40), 30 hops max, 60 byte packets 1 fritz7590.local (10.15.5.1) 0.493 ms 0.444 ms 0.682 ms > > > > > 2 62.156.244.6 (62.156.244.6) 7.900 ms 8.019 ms 8.213 ms > > > > > 3 62.156.247.226 (62.156.247.226) 8.685 ms 8.940 ms 9.377 > > > > > ms 4 m-eb13-i.M.DE.NET.DTAG.DE (217.5.69.78) 13.432 ms > > > > > 16.330 ms 16.302 ms 5 87.190.235.69 (87.190.235.69) 16.272 > > > > > ms !X * * > > > > > > > > Heutzutage komplett üblich - man versteht seine Technik nicht > > > > mehr und blockt daher einfach $alles. > > > > > > Hier wird ein hoher UDP-Port blockiert, was völlig normal ist bei > > > nem Webserver. > > > > Ja. Heutzutage. Man versteht halt seine Technik nicht mehr. > > Erkläre das bitte. Ich wüsste nicht, warum ein Webserver, der per tcp > 80/443 kommuniziert, UDP-Pakete von außen annehmen sollte (es sei > denn, er hat die Verbindung selbst aufgebaut). Udp ist verbindungslos, daher kann man da auch keine Verbindungen aufbauen. Abgesehen vom Klugscheißen, es gibt eigentlich wenig gute Gründe, hier Diagnosemöglichkeiten mutwillig zu zerstören. Wenn Dein Webserver dadurch "gefährdet" ist dann hast Du ganz andere Probleme. > > Und das aktuelle Schlangenöl vermutet dahinter einen ANGRIFF!!111 > > Ist dem noch so? > Ich hatte bisher mit so Software nix zu tun. Sei' froh. > > Noch vorbildlicher wäre, die "interessanten" udp-Ranges für > > "passende" Pakete vom Filtern auszunehmen. > > Inwiefern sind das passende Pakete? Entsprechende Portranges, Größe, TTL z.B.. > Als passend würde ich all das bezeichnen, was der Server selbst > angefordert hat. Der Rest wird halt abgelehnt. *Hüstel*. Das ist ein Webserver. Der wird recht häufig auf nicht angeforderte Sachen antworten ;-). -- For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. - Richard P. Feynman, 1987
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mm+solani@dorfdsl.de> |
|---|---|
| Date | 2024-10-19 17:53 +0200 |
| Message-ID | <vf0klv$k69f$6@solani.org> |
| In reply to | #628682 |
Am 19.10.2024 16:41 Uhr schrieb Dietz Proepper: > Marco Moock <mm+solani@dorfdsl.de> wrote: > > > Am 19.10.2024 12:30 Uhr schrieb Dietz Proepper: > > > > > Marco Moock <mm+solani@dorfdsl.de> wrote: > > > > > > > Am 19.10.2024 11:57 Uhr schrieb Dietz Proepper: > > > > > > > > > Matthias Hanft <mh@hanft.de> wrote: > > > > > > traceroute > > > > > > to www.telekom.de (80.158.67.40), 30 hops max, 60 byte packets 1 fritz7590.local (10.15.5.1) 0.493 ms 0.444 ms 0.682 ms > > > > > > 2 62.156.244.6 (62.156.244.6) 7.900 ms 8.019 ms 8.213 > > > > > > ms 3 62.156.247.226 (62.156.247.226) 8.685 ms 8.940 ms > > > > > > 9.377 ms 4 m-eb13-i.M.DE.NET.DTAG.DE (217.5.69.78) 13.432 > > > > > > ms 16.330 ms 16.302 ms 5 87.190.235.69 (87.190.235.69) > > > > > > 16.272 ms !X * * > > > > > > > > > > Heutzutage komplett üblich - man versteht seine Technik nicht > > > > > mehr und blockt daher einfach $alles. > > > > > > > > Hier wird ein hoher UDP-Port blockiert, was völlig normal ist > > > > bei nem Webserver. > > > > > > Ja. Heutzutage. Man versteht halt seine Technik nicht mehr. > > > > Erkläre das bitte. Ich wüsste nicht, warum ein Webserver, der per > > tcp 80/443 kommuniziert, UDP-Pakete von außen annehmen sollte (es > > sei denn, er hat die Verbindung selbst aufgebaut). > > Udp ist verbindungslos, daher kann man da auch keine Verbindungen > aufbauen. Abgesehen vom Klugscheißen, es gibt eigentlich wenig gute > Gründe, hier Diagnosemöglichkeiten mutwillig zu zerstören. Was spricht dagegen, hier einfach traceroute mit TCP und Port 80/443 zu nutzen? Das bildet die Situation am besten ab. ICMP wäre schon wieder problematisch im Falle von Portweiterleitungen (bei IPv4 heute leider öfter in Gebrauch) und in dem ganzen Containerumfeld (ich wollte sowas nicht haben) läuft mehr oder weniger alles mit NAT und ALGs. > Wenn Dein Webserver dadurch "gefährdet" ist dann hast Du ganz andere > Probleme. Selbstverständlich, nur ist es mehr oder weniger üblich, dass man heute alles hinter SPI-Firewalls stellt (oder gar so eine auf dem Host selbst hat) und dann nur das eingehend erlaubt, was man von außen erreichbar machen will, in diesem Fall also die TCP-Ports 80 und 443. > > > Und das aktuelle Schlangenöl vermutet dahinter einen ANGRIFF!!111 > > > > > > > Ist dem noch so? > > Ich hatte bisher mit so Software nix zu tun. > > Sei' froh. > > > > Noch vorbildlicher wäre, die "interessanten" udp-Ranges für > > > "passende" Pakete vom Filtern auszunehmen. > > > > Inwiefern sind das passende Pakete? > > Entsprechende Portranges, Größe, TTL z.B.. Sowas wird i.d.R. durch die SPI-Firewall erkannt und dann temporär geöffnet. So zumindest mache ich das unter Linux mit firewalld und nftables im Hintergrund. Alles, was nicht angefordert oder explizit erlaubt wurde, wird abgewiesen. > > Als passend würde ich all das bezeichnen, was der Server selbst > > angefordert hat. Der Rest wird halt abgelehnt. > > *Hüstel*. Das ist ein Webserver. Der wird recht häufig auf nicht > angeforderte Sachen antworten ;-). Auf den TCP-Ports 80 und 443. Auf UDP eher nicht - es sei denn man nutzt DTLS und so Zeug. -- Gruß Marco Spam und Werbung bitte an 1729348915ichwillgesperrtwerden@nirvana.admins.ws
[toc] | [prev] | [next] | [standalone]
| From | Dietz Proepper <dietz.usenet@rotfl.franken.de> |
|---|---|
| Date | 2024-10-20 07:39 +0200 |
| Message-ID | <20241020073910.21868c6f.dietz.usenet@rotfl.franken.de> |
| In reply to | #628690 |
Marco Moock <mm+solani@dorfdsl.de> wrote: > Am 19.10.2024 16:41 Uhr schrieb Dietz Proepper: > > Udp ist verbindungslos, daher kann man da auch keine Verbindungen > > aufbauen. Abgesehen vom Klugscheißen, es gibt eigentlich wenig gute > > Gründe, hier Diagnosemöglichkeiten mutwillig zu zerstören. > > Was spricht dagegen, hier einfach traceroute mit TCP und Port 80/443 > zu nutzen? Das bildet die Situation am besten ab. Was spricht dagegen, nicht FOMOSec zu betreiben? > ICMP wäre schon wieder problematisch im Falle von Portweiterleitungen > (bei IPv4 heute leider öfter in Gebrauch) und in dem ganzen > Containerumfeld (ich wollte sowas nicht haben) läuft mehr oder weniger > alles mit NAT und ALGs. Wie meinen? > > Wenn Dein Webserver dadurch "gefährdet" ist dann hast Du ganz andere > > Probleme. > > Selbstverständlich, nur ist es mehr oder weniger üblich, dass man > heute alles hinter SPI-Firewalls stellt (oder gar so eine auf dem Host > selbst hat) und dann nur das eingehend erlaubt, was man von außen > erreichbar machen will, in diesem Fall also die TCP-Ports 80 und 443. Wie geschrieben - FOMOSec in action. > > > > Und das aktuelle Schlangenöl vermutet dahinter einen > > > > ANGRIFF!!111 > > > > > > Ist dem noch so? > > > Ich hatte bisher mit so Software nix zu tun. > > > > Sei' froh. > > > > > > Noch vorbildlicher wäre, die "interessanten" udp-Ranges für > > > > "passende" Pakete vom Filtern auszunehmen. > > > > > > Inwiefern sind das passende Pakete? > > > > Entsprechende Portranges, Größe, TTL z.B.. > > Sowas wird i.d.R. durch die SPI-Firewall erkannt und dann temporär > geöffnet. So zumindest mache ich das unter Linux mit firewalld und > nftables im Hintergrund. > Alles, was nicht angefordert oder explizit erlaubt wurde, wird > abgewiesen. Das erledigt Dein Netzwerkstack für Dich. Ohne 1001 hilfreiche Daemonen. > > > Als passend würde ich all das bezeichnen, was der Server selbst > > > angefordert hat. Der Rest wird halt abgelehnt. > > > > *Hüstel*. Das ist ein Webserver. Der wird recht häufig auf nicht > > angeforderte Sachen antworten ;-). > > Auf den TCP-Ports 80 und 443. Auf UDP eher nicht - es sei denn man > nutzt DTLS und so Zeug. man QUIC. -- For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. - Richard P. Feynman, 1987
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mm+solani@dorfdsl.de> |
|---|---|
| Date | 2024-10-20 10:26 +0200 |
| Message-ID | <vf2eqs$poli$2@solani.org> |
| In reply to | #628714 |
Am 20.10.2024 07:39 Uhr schrieb Dietz Proepper: > Marco Moock <mm+solani@dorfdsl.de> wrote: > > > Am 19.10.2024 16:41 Uhr schrieb Dietz Proepper: > > > Udp ist verbindungslos, daher kann man da auch keine Verbindungen > > > aufbauen. Abgesehen vom Klugscheißen, es gibt eigentlich wenig > > > gute Gründe, hier Diagnosemöglichkeiten mutwillig zu zerstören. > > > > > > > Was spricht dagegen, hier einfach traceroute mit TCP und Port 80/443 > > zu nutzen? Das bildet die Situation am besten ab. > > Was spricht dagegen, nicht FOMOSec zu betreiben? Es gibt Geräte, die standardmäßig Serverdienste laufen haben, z.B. Windows. Klar kann man das alles ändern, aber halt nicht bei fremden Rechnern. Daher wird oft ne SPI-Firewall vornedrangestellt. Meine eigenen Rechner kann ich kontrollieren, die anderer Leute nicht. > > ICMP wäre schon wieder problematisch im Falle von > > Portweiterleitungen (bei IPv4 heute leider öfter in Gebrauch) und > > in dem ganzen Containerumfeld (ich wollte sowas nicht haben) läuft > > mehr oder weniger alles mit NAT und ALGs. > > Wie meinen? Das Konzept von IP ist eigentlich, dass ein Host eine IP hat und dass es NAT und ALGs nicht braucht. Leider wird das heute anders praktiziert. In dem ganzen Containering-Umfeld sind NAT und ALGs (die dann z.B. eingehend TLS terminieren und dann unverschlüsselt zum Server weiterschicken) leider Alltag. Da kommt man dann mit traceroute auf ICMP nur bis zum Node (so nennt sich das bei OpenShift), der das ganze zeug bereitstellt, aber nicht zum Pod (so heißt der Container), der den Serverdienst betreibt. Ist alles ein Chaos und ich bin froh, dass ich das privat nicht brauche. > > > Wenn Dein Webserver dadurch "gefährdet" ist dann hast Du ganz > > > andere Probleme. > > > > Selbstverständlich, nur ist es mehr oder weniger üblich, dass man > > heute alles hinter SPI-Firewalls stellt (oder gar so eine auf dem > > Host selbst hat) und dann nur das eingehend erlaubt, was man von > > außen erreichbar machen will, in diesem Fall also die TCP-Ports 80 > > und 443. > > Wie geschrieben - FOMOSec in action. Ist heute halt oft Standard. Ich habe auf fast allen Rechnern firewalld laufen, weil es da Dienste wie SSH gibt, die ich nur für bestimmte Adressbereiche erreichbar machen will. Klar könnte man das nun alles so konfigurieren, dass das eine Blacklist ist, aber die Whitelist ist Standard und es hat für mich keinen Mehrwert, das zu ändern. Ebenfalls unterstützen nicht alle Serverdienste ACLs auf IP-Basis. Die können auch erst nach dem TCP-Handshake greifen, sodass man damit Plagegeister schlecht fernhalten kann. Mit ICMP admin-prohib geht das besser. > > > > > Und das aktuelle Schlangenöl vermutet dahinter einen > > > > > ANGRIFF!!111 > > > > > > > > Ist dem noch so? > > > > Ich hatte bisher mit so Software nix zu tun. > > > > > > Sei' froh. > > > > > > > > Noch vorbildlicher wäre, die "interessanten" udp-Ranges für > > > > > "passende" Pakete vom Filtern auszunehmen. > > > > > > > > Inwiefern sind das passende Pakete? > > > > > > Entsprechende Portranges, Größe, TTL z.B.. > > > > Sowas wird i.d.R. durch die SPI-Firewall erkannt und dann temporär > > geöffnet. So zumindest mache ich das unter Linux mit firewalld und > > nftables im Hintergrund. > > Alles, was nicht angefordert oder explizit erlaubt wurde, wird > > abgewiesen. > > Das erledigt Dein Netzwerkstack für Dich. Ohne 1001 hilfreiche > Daemonen. Aber nur dann, wenn da kein Dienst läuft. Manchmal soll aber einer laufen, nur die ganze Welt soll den halt nicht erreichen können. Ohne Firewall wird das dann nix. -- Gruß Marco Spam und Werbung bitte an 1729402750ichwillgesperrtwerden@nirvana.admins.ws
[toc] | [prev] | [next] | [standalone]
| From | Dietz Proepper <dietz.usenet@rotfl.franken.de> |
|---|---|
| Date | 2024-10-20 11:15 +0200 |
| Message-ID | <20241020111552.7930785e.dietz.usenet@rotfl.franken.de> |
| In reply to | #628721 |
Marco Moock <mm+solani@dorfdsl.de> wrote:
> Am 20.10.2024 07:39 Uhr schrieb Dietz Proepper:
>
> > Marco Moock <mm+solani@dorfdsl.de> wrote:
> >
> > > Am 19.10.2024 16:41 Uhr schrieb Dietz Proepper:
> > > > Udp ist verbindungslos, daher kann man da auch keine
> > > > Verbindungen aufbauen. Abgesehen vom Klugscheißen, es gibt
> > > > eigentlich wenig gute Gründe, hier Diagnosemöglichkeiten
> > > > mutwillig zu zerstören.
> > >
> > > Was spricht dagegen, hier einfach traceroute mit TCP und Port
> > > 80/443 zu nutzen? Das bildet die Situation am besten ab.
> >
> > Was spricht dagegen, nicht FOMOSec zu betreiben?
>
> Es gibt Geräte, die standardmäßig Serverdienste laufen haben, z.B.
> Windows. Klar kann man das alles ändern, aber halt nicht bei fremden
> Rechnern. Daher wird oft ne SPI-Firewall vornedrangestellt.
> Meine eigenen Rechner kann ich kontrollieren, die anderer Leute nicht.
Ich hoffe mal, dass die Gilb ihr Netz und ihre Webserver selber
kontrolliert.
Achja. traceroute & tcp <-> sudo. Spätestens auf Kundenmaschinen idR.
ein Problem.
> > > ICMP wäre schon wieder problematisch im Falle von
> > > Portweiterleitungen (bei IPv4 heute leider öfter in Gebrauch) und
> > > in dem ganzen Containerumfeld (ich wollte sowas nicht haben) läuft
> > > mehr oder weniger alles mit NAT und ALGs.
> >
> > Wie meinen?
>
> Das Konzept von IP ist eigentlich, dass ein Host eine IP hat und dass
> es NAT und ALGs nicht braucht.
Long, long time ago ;-).
> Leider wird das heute anders
> praktiziert. In dem ganzen Containering-Umfeld sind NAT und ALGs (die
> dann z.B. eingehend TLS terminieren und dann unverschlüsselt zum
> Server weiterschicken) leider Alltag.
*Hüstel*. Das ist ein komplett anderes Szenario. Dass man nicht zu den
Workern kommt, sondern nur bis zum Loadbalancer/TLS-Terminator hat
komplett andere Gründe.
> Da kommt man dann mit
> traceroute auf ICMP nur bis zum Node (so nennt sich das bei
> OpenShift), der das ganze zeug bereitstellt, aber nicht zum Pod (so
> heißt der Container), der den Serverdienst betreibt.
Das macht man eigentlich schon immer so(tm). Naja, nicht ganz, aber wer
eine Horde Tomkater "öffentlich" aufstellt betreibt hoffentlich einen
honey pot ...
> Ist alles ein Chaos und ich bin froh, dass ich das privat nicht
> brauche.
Och, ein wenig docker o.ä. ist schon ganz nett. K8s wäre für "mein"
Hausnetz overkill.
> > > > Wenn Dein Webserver dadurch "gefährdet" ist dann hast Du ganz
> > > > andere Probleme.
> > >
> > > Selbstverständlich, nur ist es mehr oder weniger üblich, dass man
> > > heute alles hinter SPI-Firewalls stellt (oder gar so eine auf dem
> > > Host selbst hat) und dann nur das eingehend erlaubt, was man von
> > > außen erreichbar machen will, in diesem Fall also die TCP-Ports 80
> > > und 443.
> >
> > Wie geschrieben - FOMOSec in action.
>
> Ist heute halt oft Standard.
IBTD - das Wort, das Du meinst, schreibt man Standa(t)! (;-))
> Ich habe auf fast allen Rechnern
> firewalld laufen, weil es da Dienste wie SSH gibt, die ich nur für
> bestimmte Adressbereiche erreichbar machen will.
Wozu? Speziell bei ssh.
> Klar könnte man das
> nun alles so konfigurieren, dass das eine Blacklist ist, aber die
> Whitelist ist Standard und es hat für mich keinen Mehrwert, das zu
> ändern.
Das "Schützen" des sshd als solches dürfte ebenfalls keinen solchen
haben.
> Ebenfalls unterstützen nicht alle Serverdienste ACLs auf
> IP-Basis. Die können auch erst nach dem TCP-Handshake greifen,
Ja, so ist das Design des API.
> sodass man damit Plagegeister schlecht fernhalten kann.
Kost' ggf. ein zusätzliches Packet.
> Mit ICMP admin-prohib geht das besser.
Und macht aus DDOS-Sicht maximal dann Sinn, wenn Du z.B. am perimeter
Deines providers filtern kannst.
> > > Sowas wird i.d.R. durch die SPI-Firewall erkannt und dann temporär
> > > geöffnet. So zumindest mache ich das unter Linux mit firewalld und
> > > nftables im Hintergrund.
> > > Alles, was nicht angefordert oder explizit erlaubt wurde, wird
> > > abgewiesen.
> >
> > Das erledigt Dein Netzwerkstack für Dich. Ohne 1001 hilfreiche
> > Daemonen.
>
> Aber nur dann, wenn da kein Dienst läuft. Manchmal soll aber einer
> laufen, nur die ganze Welt soll den halt nicht erreichen können. Ohne
> Firewall wird das dann nix.
In dem Fall hast Du einen "guten Grund" und bist (natürlich)
entschuldigt. Andere (valide) Vorbringungen wären z.B. defense in
depth (der kanonische gute Grund auf den ich eigentlich gewartet hatte
;-) oder "20a alte Ranzmaschine aber muss!!111" (weniger guter Grund,
aber Not, Teufel & die Fliegen).
Die entsprechenden BSI- und Sonstwer-Empfehlungen sind (gefühlt) zu 50%
cargo cult ("wir machen das nicht weil wir verstehen was wir treiben
sondern weil GoogleFacebockAmazunAzureBlubBlubBlub das so machen!!111")
und an Stellen, wo ich's beeinflussen kann liebe ich minimalistische
Ansätze.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled. - Richard P. Feynman, 1987
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mm+solani@dorfdsl.de> |
|---|---|
| Date | 2024-10-20 11:31 +0200 |
| Message-ID | <vf2ilo$poli$4@solani.org> |
| In reply to | #628728 |
Am 20.10.2024 11:15 Uhr schrieb Dietz Proepper:
> Marco Moock <mm+solani@dorfdsl.de> wrote:
>
> > Am 20.10.2024 07:39 Uhr schrieb Dietz Proepper:
> >
> > > Marco Moock <mm+solani@dorfdsl.de> wrote:
> > >
> > > > Am 19.10.2024 16:41 Uhr schrieb Dietz Proepper:
> > > > > Udp ist verbindungslos, daher kann man da auch keine
> > > > > Verbindungen aufbauen. Abgesehen vom Klugscheißen, es gibt
> > > > > eigentlich wenig gute Gründe, hier Diagnosemöglichkeiten
> > > > > mutwillig zu zerstören.
> > > >
> > > > Was spricht dagegen, hier einfach traceroute mit TCP und Port
> > > > 80/443 zu nutzen? Das bildet die Situation am besten ab.
> > >
> > > Was spricht dagegen, nicht FOMOSec zu betreiben?
> >
> > Es gibt Geräte, die standardmäßig Serverdienste laufen haben, z.B.
> > Windows. Klar kann man das alles ändern, aber halt nicht bei fremden
> > Rechnern. Daher wird oft ne SPI-Firewall vornedrangestellt.
> > Meine eigenen Rechner kann ich kontrollieren, die anderer Leute
> > nicht.
>
> Ich hoffe mal, dass die Gilb ihr Netz und ihre Webserver selber
> kontrolliert.
> Achja. traceroute & tcp <-> sudo. Spätestens auf Kundenmaschinen idR.
> ein Problem.
>
> > > > ICMP wäre schon wieder problematisch im Falle von
> > > > Portweiterleitungen (bei IPv4 heute leider öfter in Gebrauch)
> > > > und in dem ganzen Containerumfeld (ich wollte sowas nicht
> > > > haben) läuft mehr oder weniger alles mit NAT und ALGs.
> > >
> > > Wie meinen?
> >
> > Das Konzept von IP ist eigentlich, dass ein Host eine IP hat und
> > dass es NAT und ALGs nicht braucht.
>
> Long, long time ago ;-).
Wobei man diese Zeit an Unis auch noch heute erleben kann.
> > Leider wird das heute anders
> > praktiziert. In dem ganzen Containering-Umfeld sind NAT und ALGs
> > (die dann z.B. eingehend TLS terminieren und dann unverschlüsselt
> > zum Server weiterschicken) leider Alltag.
>
> *Hüstel*. Das ist ein komplett anderes Szenario. Dass man nicht zu den
> Workern kommt, sondern nur bis zum Loadbalancer/TLS-Terminator hat
> komplett andere Gründe.
Die kommen noch dazu, aber das ist halt alles eine Art NAT oder ALG (je
nach Ebene, wo das stattfindet) und da ist die Diagnose, naja oft
nervtötend.
> > Da kommt man dann mit
> > traceroute auf ICMP nur bis zum Node (so nennt sich das bei
> > OpenShift), der das ganze zeug bereitstellt, aber nicht zum Pod (so
> > heißt der Container), der den Serverdienst betreibt.
>
> Das macht man eigentlich schon immer so(tm). Naja, nicht ganz, aber
> wer eine Horde Tomkater "öffentlich" aufstellt betreibt hoffentlich
> einen honey pot ...
Du willst nicht wissen, was alles so offen im Internet rumsteht, gerade
da, wo sich keiner drum kümmert, weil ein Hiwi das mal vor Jahren
eingerichtet hat und sich heute keiner mehr mit auskennt.
> > Ist alles ein Chaos und ich bin froh, dass ich das privat nicht
> > brauche.
>
> Och, ein wenig docker o.ä. ist schon ganz nett. K8s wäre für "mein"
> Hausnetz overkill.
Ich wollte nichtmal docker haben. Allein dessen Netzwerkgehampel ist
mir da schon zu viel für das bissl Zeug, was ich betreibe.
> > > > > Wenn Dein Webserver dadurch "gefährdet" ist dann hast Du ganz
> > > > > andere Probleme.
> > > >
> > > > Selbstverständlich, nur ist es mehr oder weniger üblich, dass
> > > > man heute alles hinter SPI-Firewalls stellt (oder gar so eine
> > > > auf dem Host selbst hat) und dann nur das eingehend erlaubt,
> > > > was man von außen erreichbar machen will, in diesem Fall also
> > > > die TCP-Ports 80 und 443.
> > >
> > > Wie geschrieben - FOMOSec in action.
> >
> > Ist heute halt oft Standard.
>
> IBTD - das Wort, das Du meinst, schreibt man Standa(t)! (;-))
>
> > Ich habe auf fast allen Rechnern
> > firewalld laufen, weil es da Dienste wie SSH gibt, die ich nur für
> > bestimmte Adressbereiche erreichbar machen will.
>
> Wozu? Speziell bei ssh.
Einerseits, weil ich dann die Bruteforce-Plagegeister los bin (man kann
den Zugang z.B. auf eine andere IPv6-Adresse legen und da erlauben) und
weil auch SSH ein Einfallstor sein kann, siehe die Backdoor und
regresshion.
> > Klar könnte man das
> > nun alles so konfigurieren, dass das eine Blacklist ist, aber die
> > Whitelist ist Standard und es hat für mich keinen Mehrwert, das zu
> > ändern.
>
> Das "Schützen" des sshd als solches dürfte ebenfalls keinen solchen
> haben.
Das Jahr 2024 hat gezeigt, dass auch ein über das Internet erreichbarer
sshd ein Problem sein kann. Daher schränke ich das wenn sinnvoll
möglich ein.
> > Ebenfalls unterstützen nicht alle Serverdienste ACLs auf
> > IP-Basis. Die können auch erst nach dem TCP-Handshake greifen,
>
> Ja, so ist das Design des API.
>
> > sodass man damit Plagegeister schlecht fernhalten kann.
>
> Kost' ggf. ein zusätzliches Packet.
Wobei die ganzen Scanner das aber als offen erkennen (Der Handshake
klappt ja) und dann weitertesten. All das kann ich halt mit so ner
FW-Regel mehr oder weniger verhindern, weil die Gegenstelle dann kein
Interesse mehr hat.
> > Aber nur dann, wenn da kein Dienst läuft. Manchmal soll aber einer
> > laufen, nur die ganze Welt soll den halt nicht erreichen können.
> > Ohne Firewall wird das dann nix.
>
> In dem Fall hast Du einen "guten Grund" und bist (natürlich)
> entschuldigt. Andere (valide) Vorbringungen wären z.B. defense in
> depth (der kanonische gute Grund auf den ich eigentlich gewartet hatte
> ;-) oder "20a alte Ranzmaschine aber muss!!111" (weniger guter Grund,
> aber Not, Teufel & die Fliegen).
Ein paar alte Netzwerkgeräte, aber die haben nur SSH-Zugänge und die
sind logischerweise per ACL auf mein eigenes Netz beschränkt.
Die Hersteller sind mir ebenfalls suspekt (Cisco und Hintertüren und
so), sowas schränke ich lieber mal ein.
> Die entsprechenden BSI- und Sonstwer-Empfehlungen sind (gefühlt) zu
> 50% cargo cult ("wir machen das nicht weil wir verstehen was wir
> treiben sondern weil GoogleFacebockAmazunAzureBlubBlubBlub das so
> machen!!111") und an Stellen, wo ich's beeinflussen kann liebe ich
> minimalistische Ansätze.
Ich ebenfalls. Das ist auch ein Grund, warum ich bei mir nie so eine
Containerumgebung haben wollte. Ist einfach zu komplex und Komplexität
wirkt sich oft negativ auf die Sicherheit aus.
Das ganze Gehampel der IT-Großkonzerne nervt mich auch - und wenn man
sich die mal anguckt, ist deren Security oft ein Grauen. Ich werfe da
nur mal MS in den Raum...
--
Gruß
Marco
Spam und Werbung bitte an
1729415752ichwillgesperrtwerden@nirvana.admins.ws
[toc] | [prev] | [next] | [standalone]
| From | Dietz Proepper <dietz.usenet@rotfl.franken.de> |
|---|---|
| Date | 2024-10-20 12:28 +0200 |
| Message-ID | <20241020122812.7ade4c42.dietz.usenet@rotfl.franken.de> |
| In reply to | #628732 |
Marco Moock <mm+solani@dorfdsl.de> wrote:
> Am 20.10.2024 11:15 Uhr schrieb Dietz Proepper:
>
> > Marco Moock <mm+solani@dorfdsl.de> wrote:
> > > Das Konzept von IP ist eigentlich, dass ein Host eine IP hat und
> > > dass es NAT und ALGs nicht braucht.
> >
> > Long, long time ago ;-).
>
> Wobei man diese Zeit an Unis auch noch heute erleben kann.
Herr Kollege! Irgendwie müssen wir doch unsere neun /8-Netze dem RIPE
verkaufen!!111
> > > Leider wird das heute anders
> > > praktiziert. In dem ganzen Containering-Umfeld sind NAT und ALGs
> > > (die dann z.B. eingehend TLS terminieren und dann unverschlüsselt
> > > zum Server weiterschicken) leider Alltag.
> >
> > *Hüstel*. Das ist ein komplett anderes Szenario. Dass man nicht zu
> > den Workern kommt, sondern nur bis zum Loadbalancer/TLS-Terminator
> > hat komplett andere Gründe.
>
> Die kommen noch dazu, aber das ist halt alles eine Art NAT oder ALG
> (je nach Ebene, wo das stattfindet) und da ist die Diagnose, naja oft
> nervtötend.
Bekannt. Glücklicherweise kann ich da inzwischen sagen "other peoples
problems" ;-).
> > > Da kommt man dann mit
> > > traceroute auf ICMP nur bis zum Node (so nennt sich das bei
> > > OpenShift), der das ganze zeug bereitstellt, aber nicht zum Pod
> > > (so heißt der Container), der den Serverdienst betreibt.
> >
> > Das macht man eigentlich schon immer so(tm). Naja, nicht ganz, aber
> > wer eine Horde Tomkater "öffentlich" aufstellt betreibt hoffentlich
> > einen honey pot ...
>
> Du willst nicht wissen, was alles so offen im Internet rumsteht,
Lieber Marco, ich /weiß/ das nur zu gut. Konntest Du schon mal eine
Woche mit einem der höherwertigen Shodan-Pläne spielen? :-}
> gerade da, wo sich keiner drum kümmert, weil ein Hiwi das mal vor
> Jahren eingerichtet hat und sich heute keiner mehr mit auskennt.
Aber freilich. Und solche Systeme in eine weitgehend abgeschottete
Umgebung zu setzen ist ja auch gar keine schlechte Idee, wie ich im
Vorposting weiter unten auch erwähnte. Nur hoffe ich mal, dass die Gilb
ihre Webpräsenz ein /bisschen/ professioneller betreibt.
> > > Ist alles ein Chaos und ich bin froh, dass ich das privat nicht
> > > brauche.
> >
> > Och, ein wenig docker o.ä. ist schon ganz nett. K8s wäre für "mein"
> > Hausnetz overkill.
>
> Ich wollte nichtmal docker haben. Allein dessen Netzwerkgehampel ist
> mir da schon zu viel für das bissl Zeug, was ich betreibe.
Och, interessant wird es doch erst dann, wenn auf dem Host 23 VLANs
terminieren und Du Container(-Gruppen) fest (d.h. ingress *und* egress)
auf bestimmte Interfaces bonden willst. Bonuspunkte, wenn das drei
Docker-Releases und fünf shittyd-Updates später auch noch tut oder man
es zumindest rechtzeitig bemerkt. *Manisches Gelächter*
> > > Ich habe auf fast allen Rechnern
> > > firewalld laufen, weil es da Dienste wie SSH gibt, die ich nur für
> > > bestimmte Adressbereiche erreichbar machen will.
> >
> > Wozu? Speziell bei ssh.
>
> Einerseits, weil ich dann die Bruteforce-Plagegeister los bin (man
> kann den Zugang z.B. auf eine andere IPv6-Adresse legen und da
> erlauben)
Dafür langt ein "hoher" Port über 32000 ebenfalls.
> und weil auch SSH ein Einfallstor sein kann, siehe die
> Backdoor und regresshion.
Ja, natürlich. Nur steht "ssh" im Ergebnis der Risikoanalyse so
auf Platz 42 oder niedriger. Zudem werden IP-Adressfilter, so man DSL
verwendet, schnell ein wenig unpraktisch.
> > Das "Schützen" des sshd als solches dürfte ebenfalls keinen solchen
> > haben.
>
> Das Jahr 2024 hat gezeigt, dass auch ein über das Internet
> erreichbarer sshd ein Problem sein kann. Daher schränke ich das wenn
> sinnvoll möglich ein.
*Hüstel* ssh hatte natürlich schon länger auch gelegentlich Probleme.
Du erinnerst Dich an den fuckup mit der Keygenerierung fast 2a lang in
Debian Ende der 00er-Jahre?
Aber das waren im Vergleich zu den apache-Bugs in der Zeit wirklich
peanuts. Wenn wir ssh mit den Bugs in den "üblichen" Webapps
vergleichen, dann sind die ssh-Bugs tatsächlich Sandkörner oder gar
schon Nanopartikel.
> > > Aber nur dann, wenn da kein Dienst läuft. Manchmal soll aber einer
> > > laufen, nur die ganze Welt soll den halt nicht erreichen können.
> > > Ohne Firewall wird das dann nix.
> >
> > In dem Fall hast Du einen "guten Grund" und bist (natürlich)
> > entschuldigt. Andere (valide) Vorbringungen wären z.B. defense in
> > depth (der kanonische gute Grund auf den ich eigentlich gewartet
> > hatte ;-) oder "20a alte Ranzmaschine aber muss!!111" (weniger
> > guter Grund, aber Not, Teufel & die Fliegen).
>
> Ein paar alte Netzwerkgeräte, aber die haben nur SSH-Zugänge und die
> sind logischerweise per ACL auf mein eigenes Netz beschränkt.
> Die Hersteller sind mir ebenfalls suspekt (Cisco und Hintertüren und
> so), sowas schränke ich lieber mal ein.
$hier betreibe ich für "Infra", d.h. Zugänge zu aktiver Netzwerktechnik
etc. ein eigenes VLAN ("Management-Netz"). Die Hetznerbox hat eine
ähnliche Aufteilung.
Der nach "außen" schauende sshd bietet im Prinzip /NUR/ relaying zum
mgmt-Netz an. Wäre beim debian- und xz-Fuckup nutzlos gewesen, bei
praktisch allem sonstigen die letzten 20a hätte sich der Angreifer
schnell totgelaufen.
> > Die entsprechenden BSI- und Sonstwer-Empfehlungen sind (gefühlt) zu
> > 50% cargo cult ("wir machen das nicht weil wir verstehen was wir
> > treiben sondern weil GoogleFacebockAmazunAzureBlubBlubBlub das so
> > machen!!111") und an Stellen, wo ich's beeinflussen kann liebe ich
> > minimalistische Ansätze.
>
> Ich ebenfalls. Das ist auch ein Grund, warum ich bei mir nie so eine
> Containerumgebung haben wollte. Ist einfach zu komplex und Komplexität
> wirkt sich oft negativ auf die Sicherheit aus.
Junger Padawan, Du sollst nicht bei sinistren Quellen wie Darth Fefe
spicken! *scnr*
> Das ganze Gehampel der IT-Großkonzerne nervt mich auch - und wenn man
> sich die mal anguckt, ist deren Security oft ein Grauen.
*Seuzf*. Zwei Bundesländer verwenden inzwischen Teams und O365.
Und die BA. Intern Teams und es gibt eine Dienstanweisung, dass über
Klientendinge /NICHT/ via Teams kommuniziert werden darf.
Man sollte die Verantwortlichen imho ganz, ganz langsam ausbluten
lassen :-\.
> Ich werfe da nur mal MS in den Raum...
OGTHROD AI´F GEB´L-EE´H YOG_SOTHOTH ´NGAH´NG AI´Y ZHRO! IEE IEE IEE!
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled. - Richard P. Feynman, 1987
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mm+solani@dorfdsl.de> |
|---|---|
| Date | 2024-10-20 19:06 +0200 |
| Message-ID | <vf3d9v$poli$8@solani.org> |
| In reply to | #628739 |
Am 20.10.2024 12:28 Uhr schrieb Dietz Proepper:
> Marco Moock <mm+solani@dorfdsl.de> wrote:
> > und weil auch SSH ein Einfallstor sein kann, siehe die
> > Backdoor und regresshion.
>
> Ja, natürlich. Nur steht "ssh" im Ergebnis der Risikoanalyse so
> auf Platz 42 oder niedriger. Zudem werden IP-Adressfilter, so man DSL
> verwendet, schnell ein wenig unpraktisch.
Ich habe feste Netze.
> > > Das "Schützen" des sshd als solches dürfte ebenfalls keinen
> > > solchen haben.
> >
> > Das Jahr 2024 hat gezeigt, dass auch ein über das Internet
> > erreichbarer sshd ein Problem sein kann. Daher schränke ich das wenn
> > sinnvoll möglich ein.
>
> *Hüstel* ssh hatte natürlich schon länger auch gelegentlich Probleme.
> Du erinnerst Dich an den fuckup mit der Keygenerierung fast 2a lang in
> Debian Ende der 00er-Jahre?
Ende der Nullerjahre war ich noch nicht im Internet.
> Aber das waren im Vergleich zu den apache-Bugs in der Zeit wirklich
> peanuts. Wenn wir ssh mit den Bugs in den "üblichen" Webapps
> vergleichen, dann sind die ssh-Bugs tatsächlich Sandkörner oder gar
> schon Nanopartikel.
Schon klar, nur ist es für mich kein großes Problem, diese Peanuts zu
entfernen. Warum sollte ich das also nicht tun?
> > > > Aber nur dann, wenn da kein Dienst läuft. Manchmal soll aber
> > > > einer laufen, nur die ganze Welt soll den halt nicht erreichen
> > > > können. Ohne Firewall wird das dann nix.
> > >
> > > In dem Fall hast Du einen "guten Grund" und bist (natürlich)
> > > entschuldigt. Andere (valide) Vorbringungen wären z.B. defense in
> > > depth (der kanonische gute Grund auf den ich eigentlich gewartet
> > > hatte ;-) oder "20a alte Ranzmaschine aber muss!!111" (weniger
> > > guter Grund, aber Not, Teufel & die Fliegen).
> >
> > Ein paar alte Netzwerkgeräte, aber die haben nur SSH-Zugänge und die
> > sind logischerweise per ACL auf mein eigenes Netz beschränkt.
> > Die Hersteller sind mir ebenfalls suspekt (Cisco und Hintertüren und
> > so), sowas schränke ich lieber mal ein.
>
> $hier betreibe ich für "Infra", d.h. Zugänge zu aktiver
> Netzwerktechnik etc. ein eigenes VLAN ("Management-Netz"). Die
> Hetznerbox hat eine ähnliche Aufteilung.
Habe ich hier auch so gemacht. Und am Router ist da die
inspect-SPI-FIrewall aktiv, damit z.B. Switche nicht per NTP aus dem
Internet erreichbar sind (bei Cisco läuft standardmäßig ein NTP-Server,
auch wenn man nur per NTP die Uhr abfragen will).
> > Ich ebenfalls. Das ist auch ein Grund, warum ich bei mir nie so eine
> > Containerumgebung haben wollte. Ist einfach zu komplex und
> > Komplexität wirkt sich oft negativ auf die Sicherheit aus.
>
> Junger Padawan, Du sollst nicht bei sinistren Quellen wie Darth Fefe
> spicken! *scnr*
Lustigerweise habe ich das erst später bei Fefe gelesen.
> > Das ganze Gehampel der IT-Großkonzerne nervt mich auch - und wenn
> > man sich die mal anguckt, ist deren Security oft ein Grauen.
>
> *Seuzf*. Zwei Bundesländer verwenden inzwischen Teams und O365.
Ist halt der heilige MS-Maaaaarktstandard.
> Und die BA. Intern Teams und es gibt eine Dienstanweisung, dass über
> Klientendinge /NICHT/ via Teams kommuniziert werden darf.
Das muss ne ganz tolle Anwendung sein....
> Man sollte die Verantwortlichen imho ganz, ganz langsam ausbluten
> lassen :-\.
Wird nicht passieren.
--
Gruß
Marco
Spam und Werbung bitte an
1729420092ichwillgesperrtwerden@nirvana.admins.ws
[toc] | [prev] | [next] | [standalone]
| From | Jörg Tewes <jogi1964@gmx.net> |
|---|---|
| Date | 2024-10-19 21:56 +0200 |
| Message-ID | <fa7390a4-21c9-4657-bd49-dad637eaf322@jtewes.my-fqdn.de> |
| In reply to | #628661 |
Dietz Proepper schrieb: >> Vorbildlich ist, dass es ein ICMP-Paket als Antwort gibt >> (!X, siehe die traceroute-Manpage). > Noch vorbildlicher wäre, die "interessanten" udp-Ranges für "passende" > Pakete vom Filtern auszunehmen. Und dann kommen die bösen Junge und machen einen UDP Flood DDOS und der Server steht. Heutzutage muß man anscheinend als großen Anbieter auf alles filtern worüber ein Angriff stattfinden könnte. -- Religionskriege sind Konflikte zwischen erwachsenen Menschen, bei denen es darum geht, wer den cooleren, imaginären Freund hat. Wenn Jesus gevierteilt worden wäre, hätten wir heute dann Mobiles über der Tür hängen?
[toc] | [prev] | [next] | [standalone]
| From | Dietz Proepper <dietz.usenet@rotfl.franken.de> |
|---|---|
| Date | 2024-10-20 07:43 +0200 |
| Message-ID | <20241020074309.7ebb3097.dietz.usenet@rotfl.franken.de> |
| In reply to | #628702 |
Jörg Tewes <jogi1964@gmx.net> wrote: > Dietz Proepper schrieb: > >> Vorbildlich ist, dass es ein ICMP-Paket als Antwort gibt > >> (!X, siehe die traceroute-Manpage). > > Noch vorbildlicher wäre, die "interessanten" udp-Ranges für > > "passende" Pakete vom Filtern auszunehmen. > > Und dann kommen die bösen Junge und machen einen UDP Flood DDOS und > der Server steht. OMG!!111 Ein UDP Flood DDOS und der Server steht ... DDOS prevention ist ein wenig die Personal Firewall der späten 90er. > Heutzutage muß man anscheinend als großen Anbieter > auf alles filtern worüber ein Angriff stattfinden könnte. Heutzutage werden Netzwerke von Leuten gemacht, die wir vor 20a nicht mal den Staubsauger hätten bedienen lassen ;-). -- For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. - Richard P. Feynman, 1987
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mm+solani@dorfdsl.de> |
|---|---|
| Date | 2024-10-20 10:26 +0200 |
| Message-ID | <vf2esj$poli$3@solani.org> |
| In reply to | #628702 |
Am 19.10.2024 21:56 Uhr schrieb Jörg Tewes: > Dietz Proepper schrieb: > >> Vorbildlich ist, dass es ein ICMP-Paket als Antwort gibt > >> (!X, siehe die traceroute-Manpage). > > Noch vorbildlicher wäre, die "interessanten" udp-Ranges für > > "passende" Pakete vom Filtern auszunehmen. > > Und dann kommen die bösen Junge und machen einen UDP Flood DDOS und > der Server steht. Heutzutage muß man anscheinend als großen Anbieter > auf alles filtern worüber ein Angriff stattfinden könnte. Ob der Server das jetzt mit ICMP port unreachable oder admin-prohibited ablehnt ist dafür egal. -- Gruß Marco Spam und Werbung bitte an 1729367774ichwillgesperrtwerden@nirvana.admins.ws
[toc] | [prev] | [next] | [standalone]
| From | Matthias Hanft <mh@hanft.de> |
|---|---|
| Date | 2024-10-19 12:44 +0200 |
| Message-ID | <1ae03417-60f4-96df-e4e1-b36b9c8ff160@hanft.de> |
| In reply to | #628657 |
Dietz Proepper schrieb: > > Du hast nicht zufällig irgendein DefenderKasperskyNorton-Schlangenöl > o.ä. installiert? Aber niemalsüberhauptnieundnimmergarnicht!!! > https://www.telekom.de tut "hier" gerade einwandfrei. Welchen Provider hast du? > Nur um Unklarheiten auszuschließen, https://www.telekom.de > bringt bei Dir nach 10s+ einen Timeout? VOn verschiedenen Geräten, Ja. > auch > über Mobilfunk? Nein, da gehts. Gruß Matthias.
[toc] | [prev] | [next] | [standalone]
| From | Dietz Proepper <dietz.usenet@rotfl.franken.de> |
|---|---|
| Date | 2024-10-19 14:05 +0200 |
| Message-ID | <20241019140549.1416f1c1.dietz.usenet@rotfl.franken.de> |
| In reply to | #628663 |
Matthias Hanft <mh@hanft.de> wrote: > Dietz Proepper schrieb: > > > > Du hast nicht zufällig irgendein DefenderKasperskyNorton-Schlangenöl > > o.ä. installiert? > > Aber niemalsüberhauptnieundnimmergarnicht!!! +1 :-) > > https://www.telekom.de tut "hier" gerade einwandfrei. > > Welchen Provider hast du? Telekom. Mit dem Standardplast, Speedport 3 oder so. > > Nur um Unklarheiten auszuschließen, https://www.telekom.de > > bringt bei Dir nach 10s+ einen Timeout? VOn verschiedenen Geräten, > > Ja. > > > auch > > über Mobilfunk? > > Nein, da gehts. Auf dem Smartphone, right? Wie geschrieben - PC/Laptop via Mobilfunk (geht auch q&d mit Smartphone-AP) anbinden & schauen. Falls ja, vllt. nochmal ganz kritisch die Flitzbox-Config durchschauen? -- For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. - Richard P. Feynman, 1987
[toc] | [prev] | [next] | [standalone]
| From | Matthias Hanft <mh@hanft.de> |
|---|---|
| Date | 2024-10-19 18:06 +0200 |
| Message-ID | <ee998bdc-f7f7-570b-813e-eaabe53aba61@hanft.de> |
| In reply to | #628668 |
Dietz Proepper schrieb: > > Auf dem Smartphone, right? Wie geschrieben - PC/Laptop via Mobilfunk > (geht auch q&d mit Smartphone-AP) anbinden & schauen. Falls ja, vllt. > nochmal ganz kritisch die Flitzbox-Config durchschauen? Aaaaalso.... ich hab jetzt mal von meinem Schreibtisch-Windows-10 über das "normale" DSL "tracert www.telekom.de" gemacht, da kommt das hier: Routenverfolgung zu www.telekom.de [80.158.67.40] über maximal 30 Hops: 1 <1 ms <1 ms <1 ms fritz7590.local [10.15.5.1] 2 12 ms 7 ms 7 ms 62.156.244.6 3 7 ms 6 ms 6 ms 62.156.247.226 4 11 ms 10 ms 9 ms m-eb13-i.M.DE.NET.DTAG.DE [217.5.69.78] 5 * * * Zeitüberschreitung der Anforderung. [usw.] Dann hab ich die 6850 in Betrieb genommen und den PC da rein gesteckt. Da funktioniert die Website und alles andere auch. Das gleiche "tracert" schaut da so aus: Routenverfolgung zu www.telekom.de [80.158.67.40] über maximal 30 Hops: 1 <1 ms <1 ms <1 ms FRITZ6850 [192.168.19.1] 2 * * * Zeitüberschreitung der Anforderung. 3 * * * Zeitüberschreitung der Anforderung. 4 * * * Zeitüberschreitung der Anforderung. 5 * * * Zeitüberschreitung der Anforderung. 6 * * * Zeitüberschreitung der Anforderung. 7 * * * Zeitüberschreitung der Anforderung. 8 18 ms 13 ms 14 ms 80.156.5.91 9 26 ms 14 ms 16 ms n-sb4-i.N.DE.NET.DTAG.DE [62.154.52.145] 10 41 ms 24 ms 19 ms m-sb1-i.M.DE.NET.DTAG.DE [62.154.2.213] 11 40 ms 18 ms 16 ms m-sb2-i.M.DE.NET.DTAG.DE [62.154.28.122] 12 25 ms 14 ms 15 ms m-eb13-i.M.DE.NET.DTAG.DE [217.5.69.78] 13 45 ms 15 ms 15 ms 87.190.235.70 14 53 ms 23 ms 22 ms 160.118.252.98 15 * * * Zeitüberschreitung der Anforderung. 16 * * * Zeitüberschreitung der Anforderung. 17 * * * Zeitüberschreitung der Anforderung. [usw.] aber das kann an DS-Lite liegen (die 6850 kriegt ja selber nur eine 10.18.80.230-Adresse). www.telekom.de geht damit jedenfalls (gleicher PC, gleicher Browser). Auch diesen Artikel schreibe ich gerade über die 6850, also das Mobilfunknetz. Aber wie gesagt, wenn www.telekom.de nicht mal von meinem virtuellen Server bei einem Hosting Provider aus erreichbar ist, hat das ja mit meinem "Home-Equipment" wohl eher wenig zu tun. Gruß "dann packe ich die 6850 jetzt wieder weg" Matthias.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | ger.ct
csiph-web