Also: The current (r4973) pdf doc says this about the Server parameter in the Windows agent conf: "Comma-delimited list of IP addresses of ZABBIX servers. Connections from other IP addresses will be rejected.", but isn't this parameter also used for the address the agent connects to in active mode?

The ServerPort parameter is not mentioned.

Actually, I think a better approach is to permit multiple "Server=" entries, and expand their syntax to include "W.X.Y.Z/M", where W, X, Y, Z are the octets of IP address, M is a netmask (either 255.255.255.0 or just 24 for a class C), and P is the port number. If the netmask isn't 0 (0.0.0.0), then active checks should send a broadcast packet to the address specified.

Since 'ServerActive' is now available for active checks in 2.0.x we can easily get away with using network/mask combinations in the 'Server' parameter.

I propose that in the future the 'Server' parameter will accept a combination of comma separated network addresses. If a /x is missing, a value of /32 is assumed (host address). This would be inline with the syntax that is used in the frontend for Network Discovery.

So, for example:

Server=192.168.1.0/24, 127.0.0.1

will allow all hosts in 192.168.1.0 netmask 255.255.255.0 and the localhost.

Permitting all hosts to query the agent could then be achieved by using:

Server=0.0.0.0/0

The /-syntax is also used in IPv6 so this shouldn't cause any troubles there either.

Btw, I'm NOT in favour of broadcasting active agent requests. These should still just be host addresses IMO. (using hostnames instead of IP addresses might solve some issues there)

Connected to ZBXNEXT-687

But Raymond Kuiper, if you keep it locked into ip address only you would be forced to keep it updated in all of your zabbix agents.

In my case, its a little bit of a problem, since its 2k hosts, and growing. If i could allow only a network range, it would be optimal.

Its not trivial to keep it updated in every single server that runs zabbix_agentd. We use three zabbix environments; development, staging and production. All of them have 20 proxies, each. Six months ago we had 10 (x3). Every time we add a proxy we need to update all zabbix_agent conf file, and its some hard work that we could save if it would allow cidr ranges (see ZBXNEXT-687).

Usually large corporations have network slices/vlans dedicated for each task, like monitoring. This allow a great number of people to benefit from this, and simplify their deployment and reduce resistance on its implementation.

I completely agree on being able to use CIDR notation in the server fields of the agent/proxy config file for passive checks.

However, due to the way active checks work, using CIDR there would mean the agent needs to go looking for the responding server(s) in that segment. This will lead to all kinds of problems. (which server will we use?, how can we scan the subnets fast enough?, how do we keep network scanning traffic to a minimum?, etc.)

Instead, in a large environment such as you have mentioned it is better to deploy a CM tool (like SaltStack, Puppet, Chef, Ansible, etc.) to manage the configuration files centrally. This would probably benefit you in other ways then just your Zabbix deployment as well.

I just meant that possibility for the Server parameter, not the ServerActive. I know that the ServerActive allows multiple IPs but, at least for me, this is not an issue. Each agent reports active items to only one server (or the config file is managed by some tool, most cases puppet, when needed).

My proposal is to the Server parameter only, as this is the "blacklist" parameter (it does not accept connections from NOT listed hosts). In most tools out there that do filtering this is possible, since its just a bit too complicated to list everything.

The optimal scenario would be to be able to specify a list of network ranges that the Server parameter would allow connections to come from, not just the ips listed.

Note that we would still be able to list uniq hosts, either not informing any range or using /32 as cidr.

Eg:
Today:
Server=10.0.1.1,10.0.1.2,10.0.1.3,10.0.1.4,10.0.1.5,10.0.1.6,10.0.1.7,10.0.2.2,10.0.2.3

Proposal:
Server=10.0.1.0/29,10.0.2.0/30

Eventually, one might want to do 0.0.0.0/0 to allow every possible ipv4 host..

Other idea would be to allow ranges like the network discovery do, using 10.0.1.1-10.0.1.7, 10.0.2.2-10.0.2.3... (mixed with CIDR)

Proposing to fix this in ZBX-4089 (spec in draft version).

PSK and certificate authentication, making Server optional, is proposed in ZBXNEXT-3016.

I'm running Zabbix Server and all my Zabbix Agents inside a Kubernetes cluster using Open vSwitch overlay network.
https://github.com/mingfang/docker-zabbix.git
https://github.com/mingfang/docker-zabbix-agent.git

Due the this problem with the Server= setting, I'm only able to use active items because the agents will always reject connections from the server.

Can you get an option to disable Server checking?
I'm aware and comfortable with the security concerns.

Yes, currently we are planning to implement this in ZBX-4089.

Is there any progress on this?
Is there any workarounds?

I'm trying to run lots of tests on the Zabbix agent in Docker containers. It's impractical to predefine IPs and a Server= ACL in the agent configuration file when running multiple transient instances of test configurations.

If I could configure the agent to Server=* in dev/test, that would be absolutely ideal!

Server=* is dirty. CIDR format 0.0.0.0/0 will be better. BTW: you should to be able to use DNS name instead of IP in the Docker world.

I agree CIDR is better.

In my Docker test world, the agent instance is long running while test suites are invoked on demand. So the hostname of the on-demand containers can't be linked into /etc/hosts in advance. I'm getting around it in the meantime by using docker exec to run the tests in the agent container, but I'd prefer the test scripts to run in discrete containers.

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-12

(1) [GPS] In new function subnet_match() there is a conditional:

        if ((af == AF_INET && prefix_size > IPV4_MAX_CIDR_PREFIX) || prefix_size > IPV6_MAX_CIDR_PREFIX)
                return FAIL;

When af is AF_INET and prefix_size is not over IPV4_MAX_CIDR_PREFIX limit, prefix_size will be additionally checked against IPV6_MAX_CIDR_PREFIX. Nothing critical but still the logic is bit wrong.

vso RESOLVED in r63133

<dimir> CLOSED

(2) [G] If we set something like Server=10.0.0.0/abc it will treat it silently as 10.0.0.0/0. It is suggested to use is_uint_n_range() or similar function instead of atoi().

vso RESOLVED in r63137

<dimir> CLOSED

(3) [D] This functionality also affects "Allowed hosts" of trapper items. So this has to be additionally documented in

https://www.zabbix.com/documentation/3.4/manual/config/items/itemtypes/trapper

And let's document (9).

vso RESOLVED in r64931,64932
https://www.zabbix.com/documentation/3.4/manual/appendix/config/zabbix_agentd
https://www.zabbix.com/documentation/3.4/manual/appendix/config/zabbix_agentd_win
https://www.zabbix.com/documentation/3.4/manual/config/items/itemtypes/trapper

glebs.ivanovskis From trapper item docs:

List of comma delimited IP addresses, optionally in CIDR notation, or hostnames of Zabbix servers.

REOPENED

vso RESOLVED
https://www.zabbix.com/documentation/3.4/manual/config/items/itemtypes/trapper

<dimir> I don't get this part:

Note that hostnames must resolve hostname→IP address and IP address→hostname.

REOPENED

vso It is from original specification on https://www.zabbix.com/documentation/3.4/manual/appendix/config/zabbix_agentd?rev=1475047606
I just made it uniform across the pages.
I think the idea is to say that it's hostname and not host

<dimir> To me it doesn't make sense. This phrase was added in 2005:

------------------------------------------------------------------------
r2241 | james_wells | 2005-11-02 05:41:33 +0200 (Wed, 02 Nov 2005) | 22 lines

+++ misc/conf/zabbix_agentd.conf        (revision 2241)
+# Note that hostnames must resolve hostname->IP address and
+# IP address->hostname.

and removed later by asaveljevs in 2010:

r14179 | asaveljevs | 2010-08-30 15:36:19 +0300 (Mon, 30 Aug 2010) | 3 lines

+++ misc/conf/zabbix_agentd.win.conf    (revision 14179)
-#      Note that hostnames must resolve hostname->IP address and IP address->hostname.

+++ misc/conf/zabbix_agentd.conf        (revision 14179)
-#      Note that hostnames must resolve hostname->IP address and IP address->hostname.

So it doesn't exist anywhere in our configs in SVN but still exists in online docs. I suggest to remove this misleading sentence from everywhere in the docs (it's time, 11 years passed):

• online versions of configs
• "Allow hosts" in frontend

vso Yes I agree, RESOLVED in
https://www.zabbix.com/documentation/3.4/manual/appendix/config/zabbix_agentd
https://www.zabbix.com/documentation/3.4/manual/appendix/config/zabbix_agentd_win
https://www.zabbix.com/documentation/3.4/manual/config/items/itemtypes/trapper

vso REOPENED probably best to remove from all versions.

vso RESOLVED
https://www.zabbix.com/documentation/3.2/manual/appendix/config/zabbix_agentd
https://www.zabbix.com/documentation/3.2/manual/appendix/config/zabbix_agentd_win

https://www.zabbix.com/documentation/3.0/manual/appendix/config/zabbix_agentd
https://www.zabbix.com/documentation/3.0/manual/appendix/config/zabbix_agentd_win

https://www.zabbix.com/documentation/2.4/manual/appendix/config/zabbix_agentd
https://www.zabbix.com/documentation/2.4/manual/appendix/config/zabbix_agentd_win

https://www.zabbix.com/documentation/2.2/manual/appendix/config/zabbix_agentd
https://www.zabbix.com/documentation/2.2/manual/appendix/config/zabbix_agentd_win

https://www.zabbix.com/documentation/2.0/manual/appendix/config/zabbix_agentd
https://www.zabbix.com/documentation/2.0/manual/appendix/config/zabbix_agentd_win

<dimir> Perfect, thanks a lot!

CLOSED

(4) [G] It is suggested to validate Server option of agent configuration file on start up.

vso RESOLVED in r63139

<dimir> Good. But the following Server entries still get passed:

1000.1000.1000.1000
300.300.300.300/24

REOPENED

vso RESOLVED in r63384, note that we validate only if CIDR is added, otherwise DNS is assumed.

<dimir> According to RFC a dns name cannot contain colon, but the following entry is still accepted:

1111:1111:1111:1111:1111:1111:1111:1111:1111:1111:1111

REOPENED

vso Are you sure that the scope of this task is DNS and IP validation and not only CIDR validation ?

<dimir> From my point of view, what's the use of introducing IP validation if it's not complete. But please consult with sasha if we really need to do that.

vso RESOLVED in r63424

<dimir> CLOSED

For the record, with 12 entries in Server parameter, including 3 dns names (LAN hosts) it takes 0.003 seconds to process all 12. It means that at this point we probably do not need to optimize parsing the entries at every connection.

(5) [F] As now CIDR format will be supported also in Allowed hosts of a Trapper item in frontend this field should be validated.

Suggestion to check (has some examples in comments):

http://php.net/manual/en/function.ip2long.php

gunarspujats CLOSED

(6) [G] IPv4-compatible/mapped addresses do not match when used with mask (::192.168.3.0/120 vs 192.168.3.29):

• Zabbix agent is started with Server=::192.168.3.0/120
• incoming connection from 192.168.3.29
• subnet_match() returns FAIL

Same thing with IPv4-mapped: Server=::ffff:192.168.3.0/120.

vso RESOLVED in r63132

<dimir> CLOSED

(7) [D] It should be discussed if we need to mention somewhere that IPv4-compatible IPv6 addresses are deprecated according to RFC:

   2.5.5.1.  IPv4-Compatible IPv6 Address
...
   The "IPv4-Compatible IPv6 address" is now deprecated because the
   current IPv6 transition mechanisms no longer use these addresses.
   New or updated implementations are not required to support this
   address type.

https://tools.ietf.org/html/rfc4291#section-2.5.5

Here is the snipped from IANA:

[3]	
::ffff:0:0/96 reserved for IPv4-mapped Address [RFC4291]. 
Reserved by protocol. For authoritative registration, see [IANA registry iana-ipv6-special-registry].
[4]	
0000::/96 deprecated by [RFC4291]. Formerly defined as the "IPv4-compatible IPv6 address" prefix.

http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

<dimir> We currently support CIDR in 3 places:

• Server= in agentd.conf on *NIX
• Server= in agentd.conf on Windows
• Allowed hosts in trapper items

So if we decide to document that "IPv4-Compatible IPv6 addresses" are deprecated it would make sense to do it in single place. Appendix? martins-v?

martins-v If we can keep it short, like within a sentence and link from the sentence to more info from an outside source, then I would add it in the three places. If we want it any longer, then an appendix.

<dimir> Added "deprecated" IPv6 addresses to:

• https://www.zabbix.com/documentation/3.4/manual/config/items/itemtypes/trapper
• https://www.zabbix.com/documentation/3.4/manual/appendix/config/zabbix_agentd
• https://www.zabbix.com/documentation/3.4/manual/appendix/config/zabbix_agentd_win

RESOLVED

vso Looks good, CLOSED.

(8) [GPS] It seems it should be enough to specify only one prefix_size for zbx_ip_cmp(). Doesn't matter if address family (IPv4/IPv6) is the same or differs it should be enough to use one.
vso RESOLVED in r63135

<dimir> CLOSED

(9) [GPS] Currently any IPv6 address allows IPv4 addresses to connect but not vise versa. Is it correct behavior?

vso this is because CIDR for IPv4 is only 32 bits the rest must be IPv4 compatible or mapped address. We cannot apply 32 bits CIDR to whole Ipv6 of size 128. So 0.0.0.0/0 is same as ::0.0.0.0/96 where CIDR is only applied to IPv4 part the rest must match.
When you use Ipv6 CIDR of 128 you can mask whole Ipv6 address including compatible/mapped part and IPv4 part.

<dimir> Let's document it. CLOSED

(10) [GPS] Host names seem to be broken:

• Zabbix is compiled --enable-ipv6
• Zabbix agent has Server=dimir
• $ host dimir
  dimir.zabbix.lan has address 192.168.3.29
  dimir.zabbix.lan has IPv6 address 12fc::29
• Zabbix server connects from 192.168.3.29
• connection is rejected

vso RESOLVED in r63367

<dimir> CLOSED

should (9) be documented, maybe ?

<dimir> Agree!

could (10) be the same as ZBX-2568 ?
vso Task you mentioned is about initiating connection from Server, this task is about accepting connection by agent, so it's not related.

(11) The following comment in comms.c tells the host name cannot start with a digit however a function isalnum() is used to check the first character.

        /* the first character must be an alpha character */
        if (0 == isalnum(hostname[0]))
                goto out;

Also when referencing the first character of a string we prefer to use *hostname.

vso RESOLVED in r63456

<dimir> CLOSED

(12) The following valid IPv6 address is not validated: 1:2:3:4:5:6:7::.

vso RESOLVED in r63472

<dimir> Same for ::2:3:4:5:6:7:8.

REOPENED

vso RESOLVED in r63499 reverted fix, won't fix as this is expected behavior according to RFC1884

<dimir> CLOSED

Also please check my commits suggesting some improvements.
vso Consider this scenario:
User quickly wants to accept all IP addresses so he changes:
Server=FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
to
Server=FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF/0

Expected:
Both ipv4 and ipv6 can connect

Actual:
ipv4 cannot connect because Server parameter does not have ipv4 compatible IP address.
To allow both ipv4 and ipv6 user must know that compatible ipv6 address must be used even if CIDR is 0.

Is it expected ?

<dimir> Nope. This was a regression fixed it.

TODO: Frontend and docs:

• (3) [D]
• (5) [F]
• (7) [D]

(13) [G] unused code:

src/libs/zbxcomms/comms.c:1865

if (NULL == ip_list)
        return FAIL;

vso RESOLVED in r64787

<dimir> CLOSED

(14) [G] zbx_validate_ip_list() must be rewritten without using insecure function strtok()

vso RESOLVED in r64787

<dimir> CLOSED

(15) [G] this error message is not correct

invalid entry in "Server" configuration parameter: invalid CIDR notation "127.0.0.1/33434"

vso RESOLVED in r64787

<dimir> CLOSED

(16) [G] colons variable is checked twice

src/libs/zbxcommon/misc.c:1865

if (2 <= colons && colons <= 6 && 2 > dbl_colons && last_colon < p)
        res = is_ip4(last_colon + 1);   /* past last column is ipv4 mapped address */

vso RESOLVED in r64799

<dimir> CLOSED

(17) DNS ending with a period shall be allowed.
vso RESOLVED in 64839

<dimir> According to

https://www.ietf.org/rfc/rfc1034.txt (3.1)

That is correct. CLOSED

Frontend is ready for testing.

[F] Frontend tested

Server tested.

Available in pre-3.3.0 (trunk) r64975.

Agent configuration pages for UNIX and Windows were updated by developer (vso).