Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.networking > #5018 > unrolled thread
| Started by | Mike Mocha <mocha@mailexcite.com> |
|---|---|
| First post | 2022-02-09 08:16 +0000 |
| Last post | 2022-02-15 09:16 -0800 |
| Articles | 14 on this page of 174 — 14 participants |
Back to article view | Back to comp.os.linux.networking
IPv6 Hardware Firewall Mike Mocha <mocha@mailexcite.com> - 2022-02-09 08:16 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-09 10:01 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-09 11:18 +0100
Re: IPv6 Hardware Firewall Mike Scott <usenet.16@scottsonline.org.uk.invalid> - 2022-02-09 15:17 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-09 16:39 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-09 11:16 +0100
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-09 16:54 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-09 17:57 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-10 08:27 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 10:59 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 19:14 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-10 20:39 +0100
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 20:25 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 14:45 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 22:24 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 12:49 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 20:48 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 14:46 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-10 10:08 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 11:01 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 19:15 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 12:44 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-10 21:34 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 14:01 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-11 14:22 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 11:27 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-12 10:49 +0100
Re: IPv6 Hardware Firewall Jorgen Grahn <grahn+nntp@snipabacken.se> - 2022-02-13 19:43 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-13 21:14 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-14 08:47 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 11:48 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-15 20:08 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 12:19 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-15 21:09 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 18:09 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 20:43 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 14:06 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 21:54 +0000
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-11 14:22 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-11 14:34 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 11:35 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-11 19:39 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 12:06 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-12 10:50 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-12 19:36 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-13 07:55 +0100
Re: IPv6 Hardware Firewall Bit Twister <BitTwister@mouse-potato.com> - 2022-02-13 03:59 -0600
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-13 14:02 -0800
Re: IPv6 Hardware Firewall Bit Twister <BitTwister@mouse-potato.com> - 2022-02-13 18:05 -0600
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-15 09:13 -0800
Re: IPv6 Hardware Firewall Bit Twister <BitTwister@mouse-potato.com> - 2022-02-15 11:36 -0600
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-15 20:32 -0800
Re: IPv6 Hardware Firewall "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2022-02-15 23:39 -0500
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-13 13:52 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 11:50 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-15 20:09 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 11:29 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-12 10:52 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-12 19:40 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-13 13:58 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 11:53 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-16 09:28 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-16 13:04 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 21:17 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-17 10:59 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-13 14:05 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 11:56 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-15 20:11 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 12:17 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-16 09:29 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-16 13:08 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-17 11:00 +0100
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-10 04:08 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-10 08:30 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 10:56 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-10 19:49 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 12:13 -0700
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-11 04:07 +0000
Re: IPv6 Hardware Firewall "Vincent Coen" <VBCoen@gmail.com> - 2022-02-10 21:33 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 14:48 -0700
Re: IPv6 Hardware Firewall "Vincent Coen" <VBCoen@gmail.com> - 2022-02-11 01:20 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-11 09:35 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 11:45 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-11 20:03 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 12:14 -0700
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-12 00:33 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-12 09:27 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-12 10:54 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-12 11:01 +0100
OT Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-12 12:06 -0800
Re: OT Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-12 21:39 +0100
Re: OT Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-13 13:27 -0800
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-14 02:12 +0000
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-14 02:06 +0000
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-15 09:14 -0800
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-10 10:10 +0100
Re: IPv6 Hardware Firewall Mike Mocha <mocha@mailexcite.com> - 2022-02-11 07:28 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-11 09:41 +0100
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-12 00:38 +0000
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-13 11:49 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-13 13:51 +0100
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-13 14:54 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-13 15:31 +0100
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-13 14:07 -0800
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 12:25 -0700
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 12:15 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-15 21:18 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 18:18 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 16:24 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-16 13:16 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-17 11:03 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-17 10:20 -0700
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-16 01:53 +0000
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-16 09:37 +0000
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-16 19:50 +0000
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-17 11:41 +0000
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-17 21:22 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 16:26 +0100
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-16 16:48 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 19:13 +0100
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-16 19:15 +0000
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-16 20:56 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 21:18 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-17 11:06 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-17 10:27 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-18 08:26 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-18 12:05 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-18 10:41 -0700
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-18 10:43 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-18 20:20 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-18 20:34 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-18 13:46 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-19 10:03 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-19 17:03 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-20 07:39 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-20 08:52 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-20 14:05 +0100
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-20 22:50 +0000
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-20 18:10 -0800
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-21 08:16 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-21 08:57 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-21 18:41 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-21 11:31 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-21 21:09 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-22 16:44 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-20 08:51 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-19 17:11 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-20 07:41 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-19 17:13 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-20 07:42 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-18 20:33 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-18 20:47 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-19 10:03 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-18 10:35 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-18 20:36 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-18 13:41 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-19 07:43 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-19 10:08 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-19 10:07 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-19 17:08 -0700
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-16 13:01 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 19:12 +0100
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-17 09:12 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-17 10:31 -0700
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-18 09:25 +0100
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-17 21:21 +0000
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-18 09:25 +0100
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-11 10:28 +0000
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-11 10:56 +0000
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-12 00:36 +0000
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-12 10:56 +0100
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-14 02:15 +0000
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-14 08:52 +0100
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-15 09:16 -0800
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-02-16 13:01 +0100 |
| Message-ID | <suip2k$87a$1@dont-email.me> |
| In reply to | #5121 |
On 15/02/2022 21:18, Marco Moock wrote: > Am Dienstag, 15. Februar 2022, um 12:15:00 Uhr schrieb Grant Taylor: > >> On 2/13/22 5:51 AM, Marco Moock wrote: > >>> Then they can operate an SPI firewall. Windows has one enabled by >>> default, most home routers have one enabled. >> >> I think that it's important to keep time & context in mind. Windows >> has an SPI firewall enabled by default /now/. It did not 20 years >> ago. > > I know, but the main problem already was and is still that Windows is > running server software by default. Does it matter if all security problems are from Windows? Windows is very common on desktops, laptops, and even servers. You don't have to like it, but you have to deal with it. In reality, all OS's have flaws, and many modern Linux distributions have ports open in their default installation. Then come the users, who might do any kind of misconfiguration or run software that has bugs in it. Windows has more than its fair share of security issues, historically even more so, but only a fool thinks other systems are "safe". > >>> If you have a good operating system, no server software runs on the >>> public addresses. Then there is also no problem at all without NAT >>> or an SPI fw. >> >> I will not bet my security on "good operating system" nor "no server >> software runs on the public address" /alone/. Does "belt and >> suspenders" or "layers of security" mean anything? > > I know that, but I definitely don't rely on firewalling. I disable the > cause of the security issue and I don't try to make it less vulnerable > with a FW. > Does anyone other that /you/ use the networks you set up and run? Do you have anything on the networks other than *nix machines that you have personally configured and checked? What about phones? Printers at the office? Apple TV and amart power meter on the home network? Are you /sure/ that none of these have flaws? Unless you are absolutely sure that you have full control over /all/ systems on a network, and their users, then you /do/ rely on firewalling. Of course it is a good idea to deal with causes of security issues wherever you can - belts and suspenders. But you can't fix everything on all devices on most networks, so you make a bottleneck at the firewall where you /do/ have control. (And even there, you don't tighten too much - or you find your users are evading your firewall by using mobile phones as wifi hotspots.) Perhaps you run networks dedicated solely to servers of various sorts, and you /do/ have tight control over what is run, and it's safe to have them "directly" attached to the internet. But most networks are not like that. >> Also, trusting the IP address alone is insufficient. IPs used to be >> far more dynamic than they are today. Thus you couldn't rely on them >> for identification in the vast majority of situations. > > I also don't rely on them for auth, but i use them as an additional > criteria if possible. > >>> NAT first creates a flexibility and then you see how bad it is. >>> Think about DNS with servers that have private addresses and should >>> have a host name. You then need NAT hairpinning and other nasty >>> stuff. >> >> I guess setting up an internal zone to resolve the name to the LAN IP >> is "other nasty stuff". I have that. Names for various servers resolve via the local DNS server to local IP's inside the network, or public IP's from public DNS servers. Access via the public IP's is more limited, tighter firewalls, etc. It works simply and smoothly, with everything behind NAT, and the normal users have no issues. The only person for whom it causes complications is /me/, because I have a more complicated setup and need to test things from different directions - but editing /etc/hosts is not hard. > > Yes, that is what I mean because that often creates problems. > Forst, DNS uses caching and a computer that was outside my have the > public IP in its cache (TTL not expired yet) and will not ask the name > server again when coming to the internal net. Short TTL's work fine in such cases. I have never heard of this being a problem in practice. > Then a computer doesn't need to use the specific DNS to resolve the > name. Maybe it is configured to use a specific DNS. Google Chrome and > Firefox offer DNS over HTTPS and maybe use that instead of the DNS the > computer gets via IPv6-RA/DHCP. > Computers should get their DNS via DHCP unless you have very specific reasons for picking something different. Normal users don't get to faff around with their DNS settings any more than they get to choose their own IP address. >>> The main problem of that is that Windows has enabled server >>> software like NetBIOS over IP and SMB. This is the problem and >>> NAT/SPI should now solve the biggest security problem that MS was >>> able to create? Personally, I don't care anymore about windows >>> machines because they are insecure by design. >>> >>> Then do it if you like a really bad network infrastructure. What I >>> wanna is that I can switch off IPv4 at all at my side without >>> having problems to connect to other's servers. >> >> Currently (2022) you will have better connectivity with IPv4+IPv6 >> with NAT than you will with IPv6 only. Sadly, the Internet isn't >> even close to parity between IPv4 and IPv6 from a service >> availability standpoint. > > Full ack, it is really annoying that I still need to have IPv4 > connectivity, especially when self-hosting my servers I need to access > from IPv4-only nets. > I like IPv4 - addresses are easier to remember than IPv6.
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-16 19:12 +0100 |
| Message-ID | <20220216191210.24dbafce@ryz> |
| In reply to | #5130 |
Am Mittwoch, 16. Februar 2022, um 13:01:23 Uhr schrieb David Brown: > On 15/02/2022 21:18, Marco Moock wrote: > > Am Dienstag, 15. Februar 2022, um 12:15:00 Uhr schrieb Grant Taylor: > > > >> On 2/13/22 5:51 AM, Marco Moock wrote: > > > > >>> Then they can operate an SPI firewall. Windows has one enabled by > >>> default, most home routers have one enabled. > >> > >> I think that it's important to keep time & context in mind. > >> Windows has an SPI firewall enabled by default /now/. It did not > >> 20 years ago. > > > > I know, but the main problem already was and is still that Windows > > is running server software by default. > > Does it matter if all security problems are from Windows? Windows is > very common on desktops, laptops, and even servers. You don't have to > like it, but you have to deal with it. That's what I do. I tell everybody running Windows about that and offer to configure their system that way that these services are turned off. > In reality, all OS's have flaws, and many modern Linux distributions > have ports open in their default installation. Then come the users, > who might do any kind of misconfiguration or run software that has > bugs in it. Windows has more than its fair share of security issues, > historically even more so, but only a fool thinks other systems are > "safe". I know, I mostly use Ubuntu and it has mDNS (Avahi) by default. That is the first thing I uninstall, although it only affect the link-local area. > Does anyone other that /you/ use the networks you set up and run? Do > you have anything on the networks other than *nix machines that you > have personally configured and checked? What about phones? Printers > at the office? Apple TV and amart power meter on the home network? > Are you /sure/ that none of these have flaws? My family uses the home network. They are aware that IPv6 isn't firewalled, IPv4 uses NAT so they are SPI-firewalled regardless if they want it or not. > Unless you are absolutely sure that you have full control over /all/ > systems on a network, and their users, then you /do/ rely on > firewalling. I often check the computers with nmap. For me that is enough, especially because finding IPv6 computers with EUI64 addresses outside of the local link is a very slow process unless they connect to you. > > Yes, that is what I mean because that often creates problems. > > Forst, DNS uses caching and a computer that was outside my have the > > public IP in its cache (TTL not expired yet) and will not ask the > > name server again when coming to the internal net. > > Short TTL's work fine in such cases. I have never heard of this > being a problem in practice. I already experienced it. Short TTL's are creating more DNS traffic. I see no reason for that if it is possible to avoid it. > Computers should get their DNS via DHCP unless you have very specific > reasons for picking something different. Normal users don't get to > faff around with their DNS settings any more than they get to choose > their own IP address. I experienced that many users configure their own DNS because they think it is "better" in any way. I also know locations (my school) that practises DNS spoofing. This causes people to implement DNSoTLS to go around that restriction. > I like IPv4 - addresses are easier to remember than IPv6. I know, but if you only need link-local connectivity you can give them specific link-local addresses. I do that with my router (fe80::1). If you need routable addresses you can use ULA without randomizing bit 8 to bit 48, but only do that if you are 100% sure you will never want to connect your link with anybody else's link.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-02-17 09:12 +0100 |
| Message-ID | <sul00u$vgi$1@dont-email.me> |
| In reply to | #5134 |
On 16/02/2022 19:12, Marco Moock wrote: > Am Mittwoch, 16. Februar 2022, um 13:01:23 Uhr schrieb David Brown: > >> On 15/02/2022 21:18, Marco Moock wrote: >>> Am Dienstag, 15. Februar 2022, um 12:15:00 Uhr schrieb Grant Taylor: >>> >>>> On 2/13/22 5:51 AM, Marco Moock wrote: >>> >> >>>>> Then they can operate an SPI firewall. Windows has one enabled by >>>>> default, most home routers have one enabled. >>>> >>>> I think that it's important to keep time & context in mind. >>>> Windows has an SPI firewall enabled by default /now/. It did not >>>> 20 years ago. >>> >>> I know, but the main problem already was and is still that Windows >>> is running server software by default. >> >> Does it matter if all security problems are from Windows? Windows is >> very common on desktops, laptops, and even servers. You don't have to >> like it, but you have to deal with it. > > That's what I do. > I tell everybody running Windows about that and offer to configure > their system that way that these services are turned off. While that sort of thing is a good idea (if it is practical), it's a never-ending battle. Who knows what services will be turned on again by the next Windows update? > >> In reality, all OS's have flaws, and many modern Linux distributions >> have ports open in their default installation. Then come the users, >> who might do any kind of misconfiguration or run software that has >> bugs in it. Windows has more than its fair share of security issues, >> historically even more so, but only a fool thinks other systems are >> "safe". > > I know, I mostly use Ubuntu and it has mDNS (Avahi) by default. That is > the first thing I uninstall, although it only affect the link-local > area. > Peer-to-peer services are common now. If someone installs Dropbox on their system (hardly an obscure piece of software), you have services open on the local network. I expect most people have more than they are aware of. And most users are not experts. >> Does anyone other that /you/ use the networks you set up and run? Do >> you have anything on the networks other than *nix machines that you >> have personally configured and checked? What about phones? Printers >> at the office? Apple TV and amart power meter on the home network? >> Are you /sure/ that none of these have flaws? > > My family uses the home network. They are aware that IPv6 isn't > firewalled, IPv4 uses NAT so they are SPI-firewalled regardless if they > want it or not. > You must have an unusual family! Few people other than professional network experts will know more about IPv6 than "I read about it many years ago - it was to be the new version of IPv4, but I heard nothing since". >> Unless you are absolutely sure that you have full control over /all/ >> systems on a network, and their users, then you /do/ rely on >> firewalling. > > I often check the computers with nmap. For me that is enough, > especially because finding IPv6 computers with EUI64 addresses outside > of the local link is a very slow process unless they connect to you. > >>> Yes, that is what I mean because that often creates problems. >>> Forst, DNS uses caching and a computer that was outside my have the >>> public IP in its cache (TTL not expired yet) and will not ask the >>> name server again when coming to the internal net. >> >> Short TTL's work fine in such cases. I have never heard of this >> being a problem in practice. > > I already experienced it. Short TTL's are creating more DNS traffic. I > see no reason for that if it is possible to avoid it. > DNS traffic is cheap. I mean, I appreciate the aim of avoiding obvious inefficiencies or wasted bandwidth. But put a wireshark on the traffic going to your router from a reasonable sized mixed-computer LAN, and look at what's there. The DNS traffic will be a tiny fraction of a percent by packet count, and much less than that by bytes. And if you look at the DNS traffic and the domain names referenced, a tiny fraction of those will be for names in your own domain - a user looking at one modern web page is likely to be asking for 50 or more domain names. Short TTL's are not the kind of problem they were in the days of dial-up modems. >> Computers should get their DNS via DHCP unless you have very specific >> reasons for picking something different. Normal users don't get to >> faff around with their DNS settings any more than they get to choose >> their own IP address. > > I experienced that many users configure their own DNS because they > think it is "better" in any way. I also know locations (my school) that > practises DNS spoofing. This causes people to implement DNSoTLS to go > around that restriction. > If I found someone setting up their own DNS choices on the network I run at my company, that person would be in for a serious talk. The result would be that they would never again be messing with things with potential consequences beyond their understanding - or they would be deputised as assistant IT support! >> I like IPv4 - addresses are easier to remember than IPv6. > > I know, but if you only need link-local connectivity you can give them > specific link-local addresses. I do that with my router (fe80::1). > If you need routable addresses you can use ULA without randomizing bit > 8 to bit 48, but only do that if you are 100% sure you will never > want to connect your link with anybody else's link. > It's probably time I looked more seriously at IPv6 - this thread and posts like yours have inspired me there. (Thanks for that.) It sounds that there are differences in the kind of network and users we deal with, and that leads to different experiences and different solutions.
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-17 10:31 -0700 |
| Message-ID | <sum0oo$4n4$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5144 |
On 2/17/22 1:12 AM, David Brown wrote: > It's probably time I looked more seriously at IPv6 Yes. Many would say it's past time that you look more seriously at IPv6. I was quite happy with the introduction / tutorial / training / certification that Hurricane Electric offered years ago. Purportedly they still offer the same. Learn about it and start using IPv6. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-02-18 09:25 +0100 |
| Message-ID | <sunl59$9er$1@dont-email.me> |
| In reply to | #5152 |
On 17/02/2022 18:31, Grant Taylor wrote: > On 2/17/22 1:12 AM, David Brown wrote: >> It's probably time I looked more seriously at IPv6 > > Yes. Many would say it's past time that you look more seriously at IPv6. > > I was quite happy with the introduction / tutorial / training / > certification that Hurricane Electric offered years ago. Purportedly > they still offer the same. > > Learn about it and start using IPv6. > I know a fair bit about it, but not as much as I should - and I have not used it in any significant way, which is of course the vital point. I have not yet seen any need of it or seen how it might be better for anything I have needed to do on networks. However, it is of course best to get the practice in /before/ I start needing it!
[toc] | [prev] | [next] | [standalone]
| From | meff <email@example.com> |
|---|---|
| Date | 2022-02-17 21:21 +0000 |
| Message-ID | <sume93$mpo$1@dont-email.me> |
| In reply to | #5144 |
On 2022-02-17, David Brown <david.brown@hesbynett.no> wrote: > It's probably time I looked more seriously at IPv6 - this thread and > posts like yours have inspired me there. (Thanks for that.) It sounds > that there are differences in the kind of network and users we deal > with, and that leads to different experiences and different solutions. I enjoyed sending [Hello IPv6](https://metebalci.com/blog/hello-ipv6/) as a good introduction to some friends.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-02-18 09:25 +0100 |
| Message-ID | <sunl6f$9er$2@dont-email.me> |
| In reply to | #5153 |
On 17/02/2022 22:21, meff wrote: > On 2022-02-17, David Brown <david.brown@hesbynett.no> wrote: >> It's probably time I looked more seriously at IPv6 - this thread and >> posts like yours have inspired me there. (Thanks for that.) It sounds >> that there are differences in the kind of network and users we deal >> with, and that leads to different experiences and different solutions. > > I enjoyed sending [Hello IPv6](https://metebalci.com/blog/hello-ipv6/) > as a good introduction to some friends. > Thanks. I will start there.
[toc] | [prev] | [next] | [standalone]
| From | meff <email@example.com> |
|---|---|
| Date | 2022-02-11 10:28 +0000 |
| Message-ID | <su5dnu$jqr$1@dont-email.me> |
| In reply to | #5055 |
On 2022-02-11, Mike Mocha <mocha@mailexcite.com> wrote: > That is the primary question I was trying to ask. For example, on one of > my daily use Linux machines I have many different services running, and > as soon as I open the IPv6 firewall on my ISPs router, it means that all > of those services are open to the world! I don't want that! I can setup > iptables on this box, but what about all the other IPv6 devices on my > network? Random IoT devices, webcams, game consoles or whatever, I have > no idea what services they are running, and I'm worried that if someone > could get on one of those devices then they could eventually make their > way into my Linux box. You'll want to setup a Stateful (SPI) Firewall. Here's [1] some example steps on how from the Arch wiki, but should be pretty generalizable to other distros. [1]: https://wiki.archlinux.org/title/simple_stateful_firewall
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2022-02-11 10:56 +0000 |
| Message-ID | <slrnt0cg8i.5ru.dan@djph.net> |
| In reply to | #5055 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Mike Mocha wrote: > Thanks for all the responses! Something that still is not making sense > to me, if for example we have a home network that contains many different > IPv6 devices connected, how do we control what ports get exposed on each > device? Your edge firewall. The rule would be constructed as 1. Destination IP -> host:addr::what:ever 2. Destination Port(s) -> Port(s) > as soon as I open the IPv6 firewall on my ISPs router, it means that all > of those services are open to the world! I don't want that! [...] If the screen you're using only allows "open everything", that sounds more like a DMZ configuration panel than something for setting firewall ACLs. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIGQREACgkQbWVw5Uzn KGANCBAAoyabrtdDxMBt90HNeaZYjTPeA4rhub8/xVmPXpi355a+OEadenxUL1Ct LXB+GJxIEcmdq8dqU7HohUED8VzARo4XTLV7HAugQhado3IxtgTGF11E8JX+ixTN NHO9VhAYaqwvcFhaZq/zQzDFzdSCgR7Wyv73/ODBw9H/S+CqfWUOYCrNmfidSjs+ oVKSCpCU+wrIgp0yTspF9CIGXF+Ng3fY6ObnA8QmrtnNeiF6uTMki+6VOp+9nxM5 HFly2pdERjwWekU8i72WqKkpEyUCfPS9gO/Kc7BG3OvXSdLWAzbxfS1xAHrJbSaP sP8YxmBPHxGxzu0uB0T9WIhB2t8XF00Zb2/2kOlI3jroCpPzfF0OIHdgG84PsheK 6NY6lSZrZsJJlp1djHQOldmCA/7HSBso3VVo2tWL72Ci10mulE1QGSQd2/71AQQi ElJ5P5OWntp0dToglPEgejhGt19r/Xj0qRAfQi5OwxBZQNfZrAOKkSecKIgyRp1Q Iuw9y/ezoXgDhjMcNSBwsJ/0WwEzebXZ+Qel4OKv3oY7FKIZUzmNRnXoBaa3kPy5 LTsJ1yg5w3s6sWqXFPvcjCweS2yJTfYJLoeg+n2jAxhEE1xfGrhdPy7Y2KbT4wSC PKnl5mJLMd2Fnh/QrbWH8QNIk4VJNvCewl2Yu5fjXU2vzBeJG2w= =9fck -----END PGP SIGNATURE----- -- |_|O|_| Github: https://github.com/dpurgert |_|_|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860 |O|O|O|
[toc] | [prev] | [next] | [standalone]
| From | Roger Blake <rogblake@iname.invalid> |
|---|---|
| Date | 2022-02-12 00:36 +0000 |
| Message-ID | <20220211193503@news.eternal-september.org> |
| In reply to | #5030 |
On 2022-02-10, Marc Haber <mh+usenetspam1118@zugschl.us> wrote: > And you're soooooo proud of that, aren't you? Yes, as a matter of fact I am. I've been working with what is now known as IPV4 for nearly 40 years and have no desire to learn a new protocol. It's not likely that IPV4 will be going away in my lifetime. -- ------------------------------------------------------------------------------ 18 Reasons I won't be vaccinated -- https://tinyurl.com/ebty2dx3 Covid vaccines: experimental biology -- https://tinyurl.com/57mncfm5 The fraud of "Climate Change" -- https://RealClimateScience.com There is no "climate crisis" -- https://climatedepot.com Don't talk to cops! -- https://DontTalkToCops.com ------------------------------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-12 10:56 +0100 |
| Message-ID | <su807j$83ug$1@news1.tnib.de> |
| In reply to | #5072 |
Roger Blake <rogblake@iname.invalid> wrote: >On 2022-02-10, Marc Haber <mh+usenetspam1118@zugschl.us> wrote: >> And you're soooooo proud of that, aren't you? > >Yes, as a matter of fact I am. I've been working with what is now known as >IPV4 for nearly 40 years and have no desire to learn a new protocol. It's >not likely that IPV4 will be going away in my lifetime. > >-- >------------------------------------------------------------------------------ > 18 Reasons I won't be vaccinated -- https://tinyurl.com/ebty2dx3 > Covid vaccines: experimental biology -- https://tinyurl.com/57mncfm5 > The fraud of "Climate Change" -- https://RealClimateScience.com > There is no "climate crisis" -- https://climatedepot.com >------------------------------------------------------------------------------ Quoting the signature for a reason. I am not surprised. End of discussion for me. -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Roger Blake <rogblake@iname.invalid> |
|---|---|
| Date | 2022-02-14 02:15 +0000 |
| Message-ID | <20220213211345@news.eternal-september.org> |
| In reply to | #5079 |
On 2022-02-12, Marc Haber <mh+usenetspam1118@zugschl.us> wrote: > Quoting the signature for a reason. I am not surprised. > End of discussion for me. In other words you cannot support your position(s). I am not surprised. -- ------------------------------------------------------------------------------ 18 Reasons I won't be vaccinated -- https://tinyurl.com/ebty2dx3 Covid vaccines: experimental biology -- https://tinyurl.com/57mncfm5 The fraud of "Climate Change" -- https://RealClimateScience.com There is no "climate crisis" -- https://climatedepot.com Don't talk to cops! -- https://DontTalkToCops.com ------------------------------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-14 08:52 +0100 |
| Message-ID | <sud1ni$h750$1@news1.tnib.de> |
| In reply to | #5102 |
Roger Blake <rogblake@iname.invalid> wrote: >On 2022-02-12, Marc Haber <mh+usenetspam1118@zugschl.us> wrote: >> Quoting the signature for a reason. I am not surprised. >> End of discussion for me. > >In other words you cannot support your position(s). I don't want to. I have more important things to do than to argue with idiots. -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | jrg <jeff.g.group@att.net> |
|---|---|
| Date | 2022-02-15 09:16 -0800 |
| Message-ID | <sugn5l$1ev9$1@gioia.aioe.org> |
| In reply to | #5104 |
On 2/13/22 23:52, Marc Haber wrote: > Roger Blake <rogblake@iname.invalid> wrote: >> On 2022-02-12, Marc Haber <mh+usenetspam1118@zugschl.us> wrote: >>> Quoting the signature for a reason. I am not surprised. >>> End of discussion for me. >> >> In other words you cannot support your position(s). > > I don't want to. I have more important things to do than to argue with > idiots. > +1
[toc] | [prev] | [standalone]
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
Back to top | Article view | comp.os.linux.networking
csiph-web