How to accept connections from a few IP addresses and immediately
reject anything from the same network range?

I did try to do that, but unsuccessful. inn 2.6.4.
auth "blah" {
hosts: "192.168.1.0/24, !192.168.1.5"
default: "<FAIL>"
}

--
Miner

Hi Miner,

> How to accept connections from a few IP addresses and immediately
> reject anything from the same network range?
>
> I did try to do that, but unsuccessful. inn 2.6.4.
>
> auth "blah" {
> hosts: "192.168.1.0/24, !192.168.1.5"
> default: "<FAIL>"
> }

You need at least 2 blocks:
- "auth" to authorize connections as a news reader and assign an
identity to that connection;
- "access" to parameter the access (what a given identity is allowed to do).

auth "blah" {
hosts: "192.168.1.0/24, !192.168.1.5"
default: "<FAIL>"
}

=> It assigns the identity "<FAIL>" to the users in 192.168.1.0/24 but
not 192.168.1.5.

You need an access block to say what "<FAIL>" can do.

With that logic in mind, a working readers.conf file to do that is:

auth blah {
hosts: "192.168.1.0/24, !192.168.1.5"
default: "<SUCCESS>"
}

access full {
users: "<SUCCESS>"
newsgroups: *
}

Of course, more complex cases could be done. That example gives you the
logic. The access block says what the "<SUCCESS>" identity can do.
Connections from an IP which does not match the "auth" block won't be
assigned any identity, and will be immediately rejected.

More information:
https://www.eyrie.org/~eagle/software/inn/docs/readers.conf.html

--
Julien ÉLIE

« J'aimerais qu'on me lâche les cothurnes ! » (Astérix)

Hi Miner,

>> How to accept connections from a few IP addresses and immediately
>> reject anything from the same network range?
>>
>> I did try to do that, but unsuccessful. inn 2.6.4.
>>
>> auth "blah" {
>>   hosts: "192.168.1.0/24, !192.168.1.5"
>>   default: "<FAIL>"
>> }
>
> => It assigns the identity "<FAIL>" to the users in 192.168.1.0/24 but
> not 192.168.1.5.

After further investigation, I better understand the issue you're facing.
This syntax does not work. I would tend to think this is a bug, but am
unsure. We have no examples of a "!" syntax in "hosts" lists in
readers.conf...

The code just parses each part of the list, starting from the end. So,
assuming you're connecting from 192.168.1.5, it does:

1/ Does "!192.168.1.5" matches 192.168.1.5? No, so go on trying.
2/ Does "192.168.1.0/24" matches 192.168.1.5? Yes, so the auth block
succeeds.

I would have said at step 1 that the auth block fails, but that's not
what the code does... Any opinion about that, and if it should be changed?

At least the documentation needs fixing as it says for "hosts":
"comma-separated wildmat expressions allowed, but @ is not supported".

> With that logic in mind, a working readers.conf file to do that is:
>
> auth blah {
>   hosts: "192.168.1.0/24, !192.168.1.5"
>   default: "<SUCCESS>"
> }
>
> access full {
>   users: "<SUCCESS>"
>   newsgroups: *
> }

This does not work, unfortunately (in current versions of INN 2.6.x).

Here's a working example:

auth allowed {
hosts: "192.168.1.0/24"
default: "<SUCCESS>"
}

auth disallowed {
hosts: "192.168.1.5"
default: "<FAIL>"
}

access success {
users: "<SUCCESS>"
newsgroups: "*"
}

access fail {
users: "<FAIL>"
reject_with: "Not allowed!"
}

Remember the order is important (the last matching block applies, so the
"disallowed" block should be after the "allowed" block).

The behaviour you asked for (directly rejecting the connection) can be
achieved with the reject_with parameter:

% telnet news.trigofacile.com 119
400 Permission denied: Not allowed!

I hope this answer helps you.

Thanks for this question. It permitted finding that "hole" in our
documentation, or even a bug in the source code!

--
Julien ÉLIE

« Pour aller plus vite, j'additionne toujours de bas en haut : je fais
du même coup l'addition et la preuve. » (Aurélien Scholl)

Hi all,

> hosts: "192.168.1.0/24, !192.168.1.5"
>
> After further investigation, I better understand the issue you're facing.
> This syntax does not work.  I would tend to think this is a bug, but am
> unsure.  We have no examples of a "!" syntax in "hosts" lists in
> readers.conf...
>
> The code just parses each part of the list, starting from the end.  So,
> assuming you're connecting from 192.168.1.5, it does:
>
> 1/ Does "!192.168.1.5" matches 192.168.1.5?  No, so go on trying.
> 2/ Does "192.168.1.0/24" matches 192.168.1.5?  Yes, so the auth block
> succeeds.
>
> I would have said at step 1 that the auth block fails, but that's not
> what the code does...  Any opinion about that, and if it should be changed?
>
> At least the documentation needs fixing as it says for "hosts":
> "comma-separated wildmat expressions allowed, but @ is not supported".

After all, I believe it should be fixed for INN 2.7.0. And an example
added.
I've digged a bit in the history. We lost a check during a refactoring.
The MatchHost() function in nnrpd once had near its end:

if (ret && list[iter][0] == '!')
ret = false;

The "!" syntax has not been working since INN 2.5.0 for the hosts pattern.

Many thanks to you, Miner, for your question about that use case!

For the time being, you can use the syntax with 2 blocks I suggested in
my previous message.
The expected syntax with only 1 block should work again in the next
release (INN 2.7.0 normally, as no other INN 2.6.x release is scheduled
unless a blocking issue is found on INN 2.6.5).

--
Julien ÉLIE

« Les amis de la vérité sont ceux qui la cherchent, et non ceux qui se
vantent de l'avoir trouvée. » (Condorcet)

Julien ??LIE wrote:

> Hi Miner,
>
> > > How to accept connections from a few IP addresses and
> > > immediately reject anything from the same network range?
> > >
> > > I did try to do that, but unsuccessful. inn 2.6.4.
> > >
> > > auth "blah" {
> > >   hosts: "192.168.1.0/24, !192.168.1.5"
> > >   default: "<FAIL>"
> > > }
> >
> > => It assigns the identity "<FAIL>" to the users in
> > 192.168.1.0/24 but not 192.168.1.5.
>
> The code just parses each part of the list, starting from the end. So,
> assuming you're connecting from 192.168.1.5, it does:
>
> 1/ Does "!192.168.1.5" matches 192.168.1.5? No, so go on
> trying.
> 2/ Does "192.168.1.0/24" matches 192.168.1.5? Yes, so the auth
> block succeeds.

> I would have said at step 1 that the auth block fails, but
> that's not what the code does... Any opinion about that, and
> if it should be changed?

In my example condition '"192.168.1.0/24, !192.168.1.5"' mean
reject any connection from network 192.168.1.0/24, except
192.168.1.5 host.

In other words: I need to permit connection from a few hosts and
terminate any incoming connection from others immediately.
Currently inn seem does not support selective rules.

>
> At least the documentation needs fixing as it says for "hosts":
> "comma-separated wildmat expressions allowed, but @ is not
> supported".
>
>
> > With that logic in mind, a working readers.conf file to do that is:
> >
> > auth blah {
> >   hosts: "192.168.1.0/24, !192.168.1.5"
> >   default: "<SUCCESS>"
> > }

"default:" value need to be "<FAIL>" - nobody welcome except a
few hosts.

> This does not work, unfortunately (in current versions of INN 2.6.x).
>
> Here's a working example:
>
> auth allowed {
> hosts: "192.168.1.0/24"
> default: "<SUCCESS>"
> }
>
> auth disallowed {
> hosts: "192.168.1.5"
> default: "<FAIL>"
> }
>
> access success {
> users: "<SUCCESS>"
> newsgroups: "*"
> }
>
> access fail {
> users: "<FAIL>"
> reject_with: "Not allowed!"
> }
>
> Remember the order is important (the last matching block
> applies, so the "disallowed" block should be after the
> "allowed" block).

How about?..

auth allowed {
hosts: "192.168.1.5"
default: "<SUCCESS>"
}

auth disallowed {
hosts: "192.168.1.0/24"
default: "<FAIL>"
}

access success {
users: "<SUCCESS>"
newsgroups: "*"
}

access fail {
users: "<FAIL>"
reject_with: "Not allowed!"
}

--
Miner

Hi Miner,

> In my example condition '"192.168.1.0/24, !192.168.1.5"' mean
> reject any connection from network 192.168.1.0/24, except
> 192.168.1.5 host.

Ah, OK. The "hosts" parameter behaves differently. It defines which
hosts are allowed.

> How about?..
>
> auth allowed {
> hosts: "192.168.1.5"
> default: "<SUCCESS>"
> }
>
> auth disallowed {
> hosts: "192.168.1.0/24"
> default: "<FAIL>"
> }
>
> access success {
> users: "<SUCCESS>"
> newsgroups: "*"
> }
>
> access fail {
> users: "<FAIL>"
> reject_with: "Not allowed!"
> }

As the last matching auth block applies, the "disallowed" block should
be before the "allowed" block in your example. Otherwise, 192.168.1.5
matches both blocks and therefore the second one ("disallowed") is selected.

In my previous example, I thought you wanted "everyone except for a few
hosts" so "allowed" is before "disallowed". Here, the logic is "nobody
except for a few hosts" so "disallowed" is before "allowed".

--
Julien ÉLIE

« Un petit pås pøur møi, un grånd bønd pøur l'humanité ! » (Kerøzen)

Julien ??LIE wrote:

> As the last matching auth block applies, the "disallowed" block
> should be before the "allowed" block in your example.
> Otherwise, 192.168.1.5 matches both blocks and therefore the
> second one ("disallowed") is selected.
>
> In my previous example, I thought you wanted "everyone except
> for a few hosts" so "allowed" is before "disallowed". Here,
> the logic is "nobody except for a few hosts" so "disallowed" is
> before "allowed".

It seems I got now desired behaviour. Thanks.

--
Miner