Marc Haber <[email protected]> writes:
Those consultants are paid to find things. Hence, they find things. Or
they make things up. The persons who hire them don't care as long as
there is a report.
A common approach to security is block or disable everything you don’t >need, and leave only the things you do need enabled.
Richard Kettlewell <[email protected]d> wrote:
A common approach to security is block or disable everything you don’t >>need, and leave only the things you do need enabled.
Then the discussion moves to what is needed. From an operations point of view, I NEED debugging.
pf's tables - a list of ip addresses you treat within the rules as a
group, and change on the fly as desired. (pfctl -t inboundblock -T
add 1.2.3.0/24; pfctl -t inboundblock -T show). If something similar
is available, I certainly couldn't find it.
For someone trying to get to grips with this, how does it help to
have a plethora of alternatives, a mound of interfaces, and - let's
face it - an awful lot of poor documentation around.
On Wed, 06 Aug 2025 17:11:28 +0200, Marc Haber wrote:
Richard Kettlewell <[email protected]d> wrote:
A common approach to security is block or disable everything you don’t >>>need, and leave only the things you do need enabled.
Then the discussion moves to what is needed. From an operations point of
view, I NEED debugging.
No reason to make those interfaces public, though.
Lawrence D'Oliveiro <[email protected]d> wrote:
On Wed, 06 Aug 2025 17:11:28 +0200, Marc Haber wrote:
Then the discussion moves to what is needed. From an operations point
of view, I NEED debugging.
No reason to make those interfaces public, though.
Yes, that's a different point of view. My different point of view is not
to take security measures that don't increase security but instead make regular life harder. If a box provides a service to the public, the
public already knows it's there, and IP header analysis can also be done
by accessing the service the machine is there to provide.
Let's agree to disagree here.
I don't trust my router, provided by the ISP.
Ok. It has sets. But (a) unless you know what they're called, you're not going to find them; and (b) that man page is singularly opaque and if
you already know the answer it's a handy reminder of syntax.
Where's the (any) guide that shows how everything fits together, with,
horror of horrors, a useful example setup intended for someone with zero knowledge of linux firewall config?
On 11/08/2025 23:02, Lawrence D'Oliveiro wrote:
I don’t know. I’m just able to read documentation. I thought that was a >> skill that was so commonplace among folks who work with computers for a
living that you could take it for granted, but apparently not.
The horror is manuals written by the code-writer. They describe in
intimate detail each and every function; but not how it all hooks up. In
this case, I'd not even seen the nft man page, because I'd been
searching for the wrong terms, hadn't got there because I'd got drowned
in a morass of ipfilter and similar stuff, now apparently out-of-date;
and gave it up as a bad job.
On 11/08/2025 23:02, Lawrence D'Oliveiro wrote:
I don’t know. I’m just able to read documentation. I thought that was a >> skill that was so commonplace among folks who work with computers for a
living that you could take it for granted, but apparently not.
The horror is manuals written by the code-writer. They describe in
intimate detail each and every function; but not how it all hooks up. In
this case, I'd not even seen the nft man page, because I'd been
searching for the wrong terms, hadn't got there because I'd got drowned
in a morass of ipfilter and similar stuff, now apparently out-of-date;
and gave it up as a bad job.
What's wrong with a couple of clear examples, plus the detail to expand
on them?
In this case, I'd not even seen the nft man page, because I'd been
searching for the wrong terms, hadn't got there because I'd got
drowned in a morass of ipfilter and similar stuff, now apparently out-of-date; and gave it up as a bad job.
What's wrong with a couple of clear examples, plus the detail to expand
on them?
Life is too short to read the whole manual cover to cover.
On 13/08/2025 00:07, Lawrence D'Oliveiro wrote:
I have the feeling you didn’t even bother doing a web search ...
Well, you'd better distrust your feelings then. Web searches are
fine if you know relevant keywords.
(I'd given up on chatgpt ages ago, when it made Noddy mistakes on
trivial code examples. Looks like things have improved since then.)
What's wrong with a couple of clear examples, plus the detail to expand+1
on them?
It still does make noddy mistakes.
On 2025-08-07 01:56, Lawrence D'Oliveiro wrote:
On Wed, 6 Aug 2025 12:46:30 +0200, Carlos E.R. wrote:
I don't trust my router, provided by the ISP.
I bought my own. I could even run my own routing stack on a Linux box.
The configuration needed by the ISP on the router is not documented ...
On 2025-08-20 03:01, Lawrence D’Oliveiro wrote:
On Tue, 19 Aug 2025 12:35:53 +0200, Carlos E.R. wrote:
What's wrong with a couple of clear examples, plus the detail to+1
expand on them?
There’s a whole website devoted to that, as I mentioned elsewhere.
Not good enough, it should be inside the manuals.
On Wed, 20 Aug 2025 01:01:32 -0000 (UTC)
Lawrence D’Oliveiro <[email protected]d> wrote:
What's wrong with a couple of clear examples, plus the detail to+1
expand on them?
There’s a whole website devoted to that, as I mentioned elsewhere.
That's a fine thing to have in *addition* to proper man pages ...
Routers were never juts routers either, they were routers plus switches
plus modems plus wireless bridges...
Optical Network Terminator. That's better than NTE at least
Oh well, its all grist to the ArtStudent™ mill where names and ideas are far more important that the reality of what they refer to.
Routers were never juts routers either, they were routers plus switches
plus modems plus wireless bridges...
I do not want reference documentation.
Oh, searching the man for "movflags" or "faststart" fails. So ask the
AI. They are in the man page for the MP3 muxer, it says. Oh, right, I
forgot that.
pf allows, for example
pfctl -t inboundblock -T replace -f /etc/firewall/inboundblock
which is an atomic operation.
To be fair, the online wiki does give the answer. Which raises the
issue, again, of documentation standards. When important matters are
absent from at least some key docs, then what?
On Fri, 29 Aug 2025 00:56:54 -0000 (UTC)
Lawrence D’Oliveiro <[email protected]d> wrote:
Weren’t you one of those complaining that bare reference material
wasn’t enough? That you wanted tutorial examples and how-tos and
all that? Then when I mention that it all that is available, you
now find a new reason to complain?
Again, when important information for *core networking tools* is
only found on the Web, it hardly takes a great sage to discern the
problem.
Oh - the problem in hand. No doubt it's easy when you know: single
interface, allow all lan traffic, block wan inbound to port 22,
redirect wan inbound on port 12345 to 22 and pass. Block wan inbound otherwise. If anyone has a config snippet to do this, I'd be very
grateful.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 33:50:50 |
| Calls: | 12,109 |
| Files: | 15,006 |
| Messages: | 6,518,330 |