NSS

Notifications de bureau (Web Push)

DnC — 2020-12-11T08:31:20Z

Sur certaines configuration de système et de navigateur, la page d'accueil et les pages AutoPanel génèrent des Notifications de bureau (Web Push).

Notification de bureau [1]

Une notification de bureau est générée par la page d'accueil et les pages Autopanel à chaque alerte de niveau 6 et 7.

La présentation des notifications varie selon les plateformes. Voici par exemple comment une notification apparait sur Windows 7 :

Conditions pour le fonctionnement des notifications de bureau

Pour que les notifications de bureau fonctionnent, il est nécessaire que la page d'accueil ou une page autopanel soit ouverte dans un onglet de navigateur. Il n'est pas nécessaire que cet onglet soit actif ni qu'il soit visible, et la fenêtre du navigateur peut être réduite dans la barre des tâches (voir le cas particulier de la page Autopanel:fullscreen).

Les Notifications de bureau sont une fonctionnalité nouvelle que tous les navigateurs ne prennent pas encore en charge.

Afficher la page de synthèse
Au clic sur la notification, la page à l'origine de l'alerte est redirigé vers la page de synthèse de la tâche concernée.

Cas particulier : page Autopanel:full screen

Par défaut, la page Autopanel:full screen ne génère pas de notification lorsqu'elle est visible. En effet, cette page est destinée à être affichée en hauteur comme un panneau de synthèse visible de façon permanente. Il ne parait pas opportun de la rediriger.

Toutefois, ce comportement peut être configuré à la rubrique Gérer l'application -> Gérer les notifications -> Notification de bureau (Web Push) : Toujours activer les notifications de bureau émanant de la page AutoPanel:fullscreen.

[1] Les dénominations "Notification Web", "Web Push", "Push Notification", "Web Push Notification" sont également usitée.

Règles de surveillance HTTP

DnC — 2020-11-27T08:30:00Z

NSS permet d'émettre régulièrement une requête HTTP, attend une réponse et l'interprète en appliquant des règles. Si une situation d'erreur est détectée, NSS génère une alerte.

Les règles de surveillance HTTP offertes par NSS Lite vous permettent de vérifier non seulement qu'un site web fonctionne et n'a pas été détourné, mais aussi de contrôler la réponse de tout dispositif HTTP : DNS, Proxy, Web service etc.

NSS Lite permet notamment de tester une réponse au format JSON ou les valeurs data-xxx de HTML5.

Requête HTTP

NSS Lite accepte une requête HTTP limitée aux composants scheme, host, path, query et fragment.

Une requête HTTP est inscrite dans le champ "Requête" de la tâche sous le format :

///[][?][#]

Exemples :

https://buy.dnc.global/-Nos-produits-.html
 https://www.ossec.dnc.global/web/spip.php?article1

Champ "Règles" vide

La réponse attendue par NSS à la suite d'une requête HTTP figure dans le champ "Règles" de la tâche. Ce champ est facultatif.

Lorsque le champ "Règles" n'est pas renseigné, NSS prend en compte le code HTTP retourné dans l'en-tête de la réponse, sans considération de la charge utile de la réponse :

– Lorsque le code HTTP de la réponse est 500 ou plus (erreur du serveur), un événement est créé avec un niveau égal à 6 ( Alerte ).

– Lorsque le code HTTP de la réponse est 400 ou plus et inférieur à 500 (erreur du client web), un événement est créé avec un niveau égal à 5 ( Critique ).

– Lorsque le code HTTP de la réponse est 300 ou plus et inférieur à 400 (redirection), NSS tente de suivre la redirection. En cas de succès, le code HTTP est 200.

– Lorsque le process s'est terminé sans erreur (code HTTP < 400), NSS applique un jeu de règles standard (voir plus loin).

Champ "Règles" non vide

Analyse de la réponse

Une réponse HTTP comprend une "entête" (response header) et une "charge utile" (response payload) aussi désigné par "corps" (body) de la réponse.

NSS traite d'abord la réponse HTTP comme indiqué ci-dessus. Lorsque le process s'est terminé sans erreur (code HTTP < 400), NSS traite la réponse en appliquant les règles indiquées dans le champ "Règles" de la tâche.

Si le test échoue, un événement est créé avec un niveau égal à 4, ou le niveau indiqué dans la définition de la tâche.

Il y a deux types de règles : les "règles générales" qui ne tiennent pas compte de la charge utile de la réponse, et celles qui s'appliquent à cette charge utile.

Règles générales

– TIME< nombre de ms : Vérifie que le serveur retourne la réponse dans un délai inférieur à la valeur indiquée en ms.

– MEAN< nombre de ms : Vérifie que le serveur retourne la réponse dans un délai moyen inférieur à la valeur indiquée en ms.

– SAME LOCATION : Contrôle que l'URL de la réponse est identique à la requête (il n'y a pas eu de redirection).

– SRCIP=nnn.nnn.nnn.nnn : Contrôle que l'hôte de la réponse réelle a bien pour IPv4 l'adresse indiquée (IP source). Permet notamment de vérifier qu'une redirection ne sort pas de la machine ciblée par la requête.

– SAME HOST : contrôle que le domaine de la réponse est identique à celui de la requête. Permet notamment de vérifier qu'une redirection ne sort pas du domaine initial.

– HTTP=nnn : le code HTTP de la réponse doit avoir la valeur indiquée.

Règles d'analyse de la charge utile de la réponse

– NULL : le corps de la réponse doit avoir une longueur nulle.

Notes :

NSS Lite ne charge pas plus que 20 000 octets du corps de la réponse. Il faut en tenir compte pour les règles qui suivent.
Attention : si l'affichage correct de la page requiert que l'utilisateur soit connecté, ou que des choix antérieurs aient été faits par l'utilisateur, il est possible que les données attendues ne figurent pas dans la réponse. Une solution peut être de préciser certains paramètres dans la requête.

– LENGTH>nombre entier : le corps de la réponse doit avoir une longueur supérieure ou égale à la valeur indiquée. Bien noter qu'il s'agit de la réponse HTML, et non de la section body de la page HTML.

– STRING=chaîne de caractères : le corps de la réponse doit être égal à la chaîne indiquée.

– CONTAINS chaîne de caractères : le corps de la réponse doit contenir la chaîne indiquée.

Notes :

Dans le cas d'un site Web dont le contenu est complété après le chargement initial de la page (par un script ou au moyen d'un Web Socket), NSS ne prendra en compte que le contenu initial qui peut être incomplet voire vide.

– MATCH chaîne de caractères : cette règle permet de vérifier la présence d'une chaîne quelconque dans la réponse. La chaîne de caractère peut être une expression régulière, il est donc possible d'effectuer n'importe quelle vérification dans la réponse.

– JSON tableau['a']['b']...=value, JSON tableau['a']['b']...>value : La réponse doit être un tableau associatif au format JSON. La règle teste la valeur de l'élément tableau ['a']['b']...
Le nombre de dimensions de l'index (profondeur de récursion) est limité à 10.
Contrairement aux autres règles, les noms du tableau et des index sont sensibles à la casse.

– DATA-XXX=value, DATA-XXX>value : La réponse doit contenir l'attribut HTML5 data-xxx. NSS compare la valeur de l'attribut à la valeur indiquée dans la règle. Notez que si la réponse comporte plusieurs data-xxx, seule la première occurrence sera testée.

Inversion de la règle

On peut faire précéder les règles d'analyse de la charge utile par NOT pour tester la condition inverse (c'est souvent plus intéressant), sont ainsi valides les règles : NOT NULL, NOT HTTP=, NOT LENGTH=, NOT STRING=, NOT CONTAINS etc..
Cependant, MATCH ne peut être inversée.

Exemples de règles

SRCIP= 52.128.11.2 Vérifie que la réponse provient bien de l'IP indiquée.

CONTAINS vérifie que le document retourné comporte bien un corps (sans préjuger de son contenu).

LENGTH>10000 vérifie que la réponse a une longueur > 10000. Permet de détecter une erreur de génération de la page si son contenu (header compris) est normalement supérieur à la valeur indiquée.

NOT CONTAINS tep stop La réponse ne doit pas contenir la chaîne 'tep stop' (qui est une erreur fatale retournée par osCommerce).

NOT JSON Valeurs['temperature']['sortie']>55 La réponse doit être un tableau JSON 'Valeurs' dont l'élément ['temperature']['sortie'] doit être inférieur ou égal à 55.

DATA-price>50 Le prix indiqué dans le champ data-price doit être supérieur à 50.

Combinaison de plusieurs règles pour une même tâche

Plusieurs règles peuvent être indiquées dans le champ "Règles" à raison d'une par ligne.
Elles sont combinées avec l'opérateur logique AND, c'est à dire que la tâche est en erreur si une des règles est vérifiée.

Le nombre de règles n'est limité que par la longueur totale du champ "Règles", limité à 1024 caractères.

Voici un exemple de surveillance des DNS d'un domaine [1], dans lequel les règles sont appliquées à la réponse d'un site de test de DNS tel que testdns.fr :

CONTAINS ns102.ovh.net
 CONTAINS dns102.ovh.net
 CONTAINS 51.178.18.44

Cet autre exemple montre comment vérifier qu'une page est non-vide, n'affiche pas une erreur MySQL, n'a pas été détournée, n'a pas été rejettée par un firewall et comment suivre le temps de réponse :

SRCIP=NNN.NNN;NNN;NNN
 LENGTH>10000:6
 CONTAINS LeTitreDeLaPageParExemple:6
 NOT CONTAINS MySQL error
 NOT CONTAINS forbidden
 TIME<1000:2
 TIME<3000:3
 TIME<10000:4

Bien noter que des règles telles que 'NOT CONTAINS MySQL error' ou 'NOT CONTAINS forbidden', ne sont pas universelles : elles dépendent de l'application ou du firewall.

Jeu de règles standard appliqué par défaut

Quand la champ règles est vide, NSS applique le jeu de règles standard (ne nécessitant pas le chargement du corps de la réponse) suivant :

TIME<2000:2
 TIME<5000:3"
 TIME<10000:4

Temps de réponse

Si aucune règle n'a généré d'erreur ( dont les règles TIME et MEAN décrites précédemment ), NSS applique une règle implicite qui compare le temps de réponse par rapport au temps de réponse moyen constaté pour la tâche. Une alerte est générée avec un niveau égal à 2 ( Notice ), ou le niveau indiqué dans la définition de la tâche, si le temps de réponse excède 4 fois le délai moyen.

Pour plus de détails sur ce sujet, voyez : Surveillance du temps de réponse.

Niveau d'alerte

Définition

NSS classe les événements selon leur gravité en 8 niveaux, décrits dans le tableau suivant :

Niveau	Sévérité	Elévation
7	Urgence : le système est inutilisable	NA
6	Alerte : une action doit être entreprise immédiatement	7 si nombre dépasse 5
5	Condition critique	6 si nombre dépasse 5
4	Erreur	5 si nombre dépasse 60
3	Attention	NA
2	Information significative	3 si nombre dépasse 60
1	Information	NA
0	Information de débogage	NA

Attribution du niveau d'alerte

En cas d'erreur, NSS attribue par défaut un niveau d'alerte de 4.

Ce niveau d'alerte peut être modifié pour une tâche donnée en entrant une valeur différente dans le champ "Niveau de l'erreur" du formulaire de création/édition de la tâche. Ainsi défini, le niveau d'erreur s'applique quelle que soit la règle en erreur.
Il est possible de définir un niveau d'erreur particulier pour la règle en la faisant suivre de ':N' où N est le niveau désiré, comme dans l'exemple suivant :
LENGTH>10000:6

Bien entendu, les niveaux d'erreur définis doivent l'être en cohérence avec le "Niveau d'alerte minimum pour l'envoi" défini pour les notifications (voir plus loin).

Compactage des événements

Lorsque des événements identiques se succèdent, NSS ne génère pas une alerte à chaque fois, mais comptabilise le nombre de répétition. Une seule ligne apparaît dans la table Alertes.
Comme indiqué dans la colonne "Elévation", le niveau d'alerte est levé d'une unité quand la même erreur se répète.
Ainsi, la table Alertes reste synthétique, et la cadence des notifications raisonnable.

Notification

Le formulaire Gérer les notifications permet de définir les adresses de destination et le niveau minimal déclenchant une notification.

Par défaut, le niveau d'alerte est 5 (envoyer "conditions critiques" et au-dessus).
On peut modifier ce niveau dans le champ "Niveau d'alerte minimum pour l'envoi", en indiquant un chiffre de 0 (envoyer toutes les alertes) à 7 (envoyer seulement "système inutilisable").

NSS émet un message de notification au début d'une série d'alerte et en cas d'élévation du niveau.

[1] Il est bien plus efficace de surveiller les DNS à l'aide d'une requête dns ://. Voyez : Règles de surveillance DNS.

HTTP monitoring rules

DnC — 2020-11-26T08:30:00Z

NSS allows to regularly send an HTTP request, waits for a response and interprets it by applying rules. If an error situation is detected, NSS generates an alert.

The HTTP monitoring rules offered by NSS Lite allow you to not only verify that a website is functioning and has not been hijacked, but also to monitor the response of any HTTP device: DNS, Proxy, Web service etc.

NSS Lite allows in particular to test a response in JSON format or the data-xxx values of HTML5.

HTTP request

NSS Lite accepts an HTTP request limited to the scheme, host, path, query and fragment components.

An HTTP request is entered in the "Request" field of the task in the format:

/// [] [? ] [# ]

Examples:

https://buy.dnc.global/-Nos-produits-.html
 https://www.ossec.dnc.global/web/spip.php?article1

"Rules" field empty

The response expected by NSS following an HTTP request appears in the "Rules" field of the task. This field is optional.

When the "Rules" field is not filled in, NSS takes into account the HTTP code returned in the header of the response, regardless of the payload of the response:

– When the HTTP response code is 500 or more (server error), an event is created with a level equal to 6 (Alert).

– When the HTTP code of the response is 400 or more and less than 500 (web client error), an event is created with a level equal to 5 (Critical).

– When the HTTP code of the response is 300 or more and less than 400 (redirect), NSS tries to follow the redirect. If successful, the HTTP code is 200.

– When the process has ended without error (HTTP code <400), NSS applies a set of standard rules.

"Rules" field not empty

Analysis of the response

An HTTP response includes a "response header" and a "response payload" also referred to as the "body" of the response.

NSS first processes the HTTP response as described above. When the process has finished without error (HTTP code <400), NSS processes the response by applying the rules indicated in the "Rules" field of the task.

If the test fails, an event is created with a level equal to 4, or the level specified in the task definition.

There are two types of rules: "general rules" which do not take into account the payload of the response, and those which apply to that payload.

General rules

– TIME< number of ms: Checks that the server returns the response within a time less than the value indicated in ms.

– MEAN< number of ms: Checks that the server returns the response within an average delay less than the value indicated in ms.

– SAME LOCATION: Check that the URL of the response is identical to the request (there was no redirection).

– SRCIP = nnn.nnn.nnn.nnn: Check that the host of the real response has the indicated address for IPv4 (source IP). In particular, it is possible to check that a redirection does not leave the machine targeted by the request.

– SAME HOST: checks that the domain of the response is identical to that of the request. In particular, it is possible to check that a redirection does not leave the initial domain.

– HTTP = nnn: the HTTP code of the response must have the value indicated.

Response payload analysis rules

– NULL: the body of the response must have zero length.

Note: NSS Lite does not load more than 20,000 bytes from the response body. This must be taken into account for the following rules.

– LENGTH> integer: the body of the response must have a length greater than or equal to the specified value. Note that this is the HTML response, not the section of the HTML page.

– STRING = character string: the body of the response must be equal to the specified string.

– CONTAINS character string: the body of the response must contain the specified string.

– MATCH character string: this rule allows you to check the presence of any string in the response. The string can be a regular expression, so it is possible to perform any check in the response.

– JSON array ['a'] ['b'] ... = value, JSON array ['a'] ['b'] ...> value: The response must be a associative array in JSON format. The rule tests the value of the array element ['a'] ['b'] ...
The number of index dimensions (recursion depth) is limited to 10.
Unlike other rules, the names of the array and indexes are case sensitive.

– DATA-XXX = value, DATA-XXX> value: The response must contain the HTML5 data-xxx attribute. NSS compares the value of the attribute to the value specified in the rule. Note that if the response has multiple data-xxxs, only the first occurrence will be tested.

Rule inversion

We can precede the payload analysis rules with NOT to test the reverse condition (it is often more interesting), the rules are thus valid: NOT NULL, NOT HTTP =, NOT LENGTH =, NOT STRING =, NOT CONTAINS etc ..
However, MATCH cannot be reversed.

Examples of rules

SRCIP = 52.128.11.2 Checks that the response comes from the indicated IP.

CONTAINS checks that the returned document contains a body (without prejudging its content).

LENGTH> 10000 checks that the response has a length> 10000. Used to detect a page generation error if its content (including header) is normally greater than the value indicated.

NOT CONTAINS tep stop The response must not contain the string 'tep stop' (which is a fatal error returned by osCommerce).

NOT JSON Values ['temperature'] ['output']> 55 The response must be a JSON array 'Values' whose element ['temperature'] ['output' ] must be less than or equal to 55.

DATA-price> 50 The price indicated in the data-price field must be greater than 50.

Combination of several rules for the same task

Several rules can be indicated in the "Rules" field, one per line.
They are combined with the logical operator AND, ie the task is in error if one of the rules is verified.

The number of rules is limited only by the total length of the "Rules" field, limited to 1024 characters.

Here is an example of DNS monitoring for a domain [1], In which the rules are applied to the response from a DNS test site such as testdns.fr:

CONTAINS ns102.ovh.net
 CONTAINS dns102.ovh.net
 CONTAINS 51.178.18.44

This other example shows how to verify that a page is non-empty, doesn't show a MySQL error, hasn't been hijacked, and how to track response time:

SRCIP = NNN.NNN; NNN; NNN
 LENGTH> 10,000: 6
 CONTAINS TheTitleOfThePageByExample: 6
 NOT CONTAINS MySQL error
 NOT CONTAINS forbidden
 TIME <1000: 2
 TIME <3000: 3
 TIME <10000: 4

Please note that rules such as "NOT CONTAINS MySQL error" or "NOT CONTAINS forbidden" are not universal: they depend on the application or the firewall.

Standard rule set applied by default

When the rules field is empty, NSS applies the following standard rule set (not requiring the loading of the response body):

TIME <2000: 2
 TIME <5000: 3 "
 TIME <10000: 4

Response time

If no rule has generated an error (including the TIME and MEAN rules described above), NSS compares the response time against the average response time observed for the task. An alert is generated with a level equal to 2 (Notice), or the level indicated in the definition of the task, if the response time exceeds 4 times the average time.

For more details on this topic, see: Surveillance du temps de réponse.

Alert level

Definition

NSS classifies events according to their severity into 8 levels, described in the following table:

Level	Severity	Elevation
7	Emergency: the system cannot be used	NA
6	Alert: action must be taken immediately	7 if number exceeds 5
5	Critical condition	6 if number exceeds 5
4	Error	5 if number exceeds 60
3	Attention	NA
2	Significant information	3 if number exceeds 60
1	Information	NA
0	Debug Info	NA

Alert level assignment

In the event of an error, NSS assigns an alert level of 4 by default.

This alert level can be modified for a given task by entering a different value in the "Error level" field of the task creation / edition form.

Thus defined, the level of error applies regardless of the rule in error. It is possible to define a particular level of error for the rule by following it with ': N' where N is the desired level, as in the following example:
LENGTH> 10000: 6

Of course, the defined error levels must be consistent with the "Minimum alert level for sending" defined for notifications (see below).

Compaction of events

When identical events follow one another, NSS does not generate an alert each time, but counts the number of repetitions. Only one line appears in the Alerts table.
As indicated in the "Elevation" column, the alert level is raised by one when the same error is repeated.
Thus, the Alerts table remains synthetic, and the rate of notifications reasonable.

Notification

The Manage notifications form allows you to define the destination addresses and the minimum level triggering a notification.

By default, the alert level is 5 (send "critical conditions" and above).
This level can be modified in the "Minimum alert level for sending" field, indicating a number from 0 (send all alerts) to 7 (send only "unusable system").

NSS issues a notification message at the start of an alert series and when the level rises.

[1] It is much more efficient to monitor DNS using a dns: // query. See: Règles de surveillance DNS.

DNS monitoring rules

DnC — 2020-10-27T11:12:25Z

NSS allows you to regularly send a DNS query, waits for a response and interprets it by applying rules. If an error situation is detected, NSS generates an alert.

The DNS watch rules offered by NSS Lite allow you to verify all aspects of the DNS configuration of the domain in question, in addition to checking response time.

Requête DNS

A DNS request is entered in the "Request" field of the task in the format:

dns: [//[:] /] [? ]

where :

– server: (optional) URL of a particular DNS server.
– domain (required): the domain of the record in the DNS zone.
– type: (optional, A) the type of record in the DNS zone of the domain: A, AAAA, CNAME, MX, NS, SOA, SPF, TXT. If this parameter is not understood, an error will be generated.

examples:

dns:buy.dnc.global
 dns:dnc.global?NS
 dns://dns102.ovh.net/buy.dnc.global
 dns:degoy.com?A
 dns:degoy.com?AAAA
 dns://dns200.anycast.me/degoy.com?AAAA
 dns:degoy.com?MX
 dns://ns-219-a.gandi.net/www.spip.net
 dns://1.1.1.1/dnc.global /* Cloudflare resolver */
 dns://8.8.8.8/dnc.global /* Google resolver */
 dns://213.186.33.99/dnc.global?AAAA /* OVH resolver France*/
 dns://5.196.123.133/dnc.global?AAAA /* OVH resolver, Spain */
 dns://193.252.10.2/dnc.global /* Orange, Aubervilliers, France */

Reply

NSS issues the DNS query as a Unix / Linux DIG of the following form:
dig [] [@ server [: port]]

If the request is successful, the response parsed by NSS is the literal form returned by DIG.
Here is for example the response to the request dns: degoy.com? MX (translated into dig MX degoy.com):

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.7 <<>> MX degoy.com
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36151
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;degoy.com. IN MX
 
 ;; ANSWER SECTION:
 degoy.com. 600 IN MX 5 mx1.mail.ovh.net.
 degoy.com. 600 IN MX 100 mx3.mail.ovh.net.
 degoy.com. 600 IN MX 1 mx0.mail.ovh.net.
 degoy.com. 600 IN MX 200 mail.rollernet.us.
 degoy.com. 600 IN MX 200 mail2.rollernet.us.
 degoy.com. 600 IN MX 50 mx2.mail.ovh.net.
 
 ;; Query time: 11 msec
 ;; SERVER: 213.186.33.99#53(213.186.33.99)
 ;; WHEN: Tue Sep 1 17:22:07 2020
 ;; MSG SIZE rcvd: 174

If this fails, NSS will log an error.

Implicit and Default Rules

The response expected by NSS following a DNS request appears in the "Rules" field of the task. This field is optional. Whether or not it is entered, implicit rules apply:

status: NOERROR : NSS vérifie que la réponse du DNS comporte "status: NOERROR". Dans le cas contraire, une alerte de niveau 5 au moins est générée.

Response Time: NSS always monitors the response time against the average time observed for the task.
An alert is generated with a level equal to 2, or the level indicated in the task definition, if the response time exceeds 4 times the average time.

For more details on this topic, see: Surveillance du temps de réponse.

Default rules: moreover, if the rule field is not filled in, NSS applies the following rules, assuming an expected response within a period of less than 50 ms:

TIME<50:3
 TIME<100:4
 TIME<500:5

These rules already allow effective monitoring without having to assign rules to the task. So the simple query:

dns://ns-219-a.gandi.net/www.spip.net

allows you to monitor the resolution of the domain name www.spip.net by one of its authoritative DNS servers.

Rules applicable to the DNS request

– TIME< number of ms: Checks that the server returns the response within a time period less than the value indicated in ms.

– MEAN< number of ms: Checks that the server returns the response within an average delay less than the value indicated in ms.

– IPV4= NNN.NNN.NNN.NNN : the most essential rule, allowing to verify that the domain name indicated in the DNS request is resolved and equal to the indicated IPv4 address.

– QUERY TIME< number of ms: DNS server response time.

Note: The TIME and MEAN rules take into account the total response time of the request, including transmission times, whether the DNS is responding or not), while QUERY TIME covers the time shown in the DNS response.

– CONTAINS character string: this rule allows you to check for the presence of a string in the raw response.

– MATCH character string: this rule allows you to check for the presence of any string in the raw response. The string can be a standard regular expression, so it is possible to perform any check in the response. However, the use of the ARRAY rule will most often be preferable.

– ARRAY [index] = character string: Checks that the character string is found in the value of the array at index A. Note that this is an inclusion and not an equality , the rule behaving like CONTAINS. The index can be multidimensional.

– ARRAY [index]> number: Checks that the value of the array at index A is greater than the number indicated. The index can be multidimensional.

Learn more about the ARRAY rule ...

The ARRAY ... rule completes the rule set to test any information returned by the DNS query.

How NSS translates the responses

To make a request, NSS calls on DIG and then breaks down the response into an associative array. The rules relate to the elements of this array.
Usually, you won't have to worry about this table. However, the formulation of an ARRAY rule supposes to know the structure of this table well.

Here's how NSS internally translates the previous query into an array:

: array =
RAW: string = " ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> www.spip.net\n;; global options: +cmd\n;; Got answer:\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 594\n;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3\n\n;; OPT PSEUDOSECTION:\n; EDNS: version: 0, flags:; udp: 4096\n; COOKIE: f182cd5130c105c8056d4eed5f50bf97a6b668e584c7b2e7 (good)\n;; QUESTION SECTION:\n;www.spip.net.\t\t\tIN\tA\n\n;; ANSWER SECTION:\nwww.spip.net.\t\t1979\tIN\tA\t151.80.20.125\n\n;; AUTHORITY SECTION:\nspip.net.\t\t34795\tIN\tNS\tns-145-c.gandi.net.\nspip.net.\t\t34795\tIN\tNS\tns-77-b.gandi.net.\nspip.net.\t\t34795\tIN\tNS\tns-219-a.gandi.net.\n\n;; ADDITIONAL SECTION:\nns-219-a.gandi.net.\t34795\tIN\tA\t173.246.100.220\nns-219-a.gandi.net.\t34795\tIN\tAAAA\t2001:4b98:aaaa::dc\n\n;; Query time: 0 msec\n;; SERVER: 127.0.0.1#53(127.0.0.1)\n;; WHEN: Thu Sep 03 10:04:07 UTC 2020\n;; MSG SIZE rcvd: 203\n"
; <<>> DIG 9.11.5-P4-5.1+DEB10U2-DEBIAN <<>> WWW.SPIP.NET: string = ""
GLOBAL OPTIONS: string = " +cmd "
GOT ANSWER: string = " "
HEADER: array =
opcode: string = " QUERY"
status: string = " NOERROR"
id: string = " 594 "
flags: string = " qr rd ra"
QUERY: string = " 1"
ANSWER: string = " 1"
AUTHORITY: string = " 3"
ADDITIONAL: string = " 3 "
OPT PSEUDOSECTION: string = " ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: f182cd5130c105c8056d4eed5f50bf97a6b668e584c7b2e7 (good) "
QUESTION SECTION: string = "www.spip.net. IN A "
QUERY TIME: string = " 0 msec "
SERVER: string = " 127.0.0.1#53(127.0.0.1) "
WHEN: string= "Thu Sep 03 10:04:07 UTC 2020"
MSG SIZE RCVD: string = " 203 "
ANSWER SECTION: array =
0: array =
host: string = "www.spip.net"
class: string = "IN"
ttl: long = 1974
type: string = "A"
ip: string = "151.80.20.125"
AUTHORITY SECTION: array =
0: array =
host: string = "spip.net"
class: string = "IN"
ttl: long = 34790
type: string = "NS"
target: string = "ns-145-c.gandi.net"
1: array =
host: string = "spip.net"
class: string = "IN"
ttl: long = 34790
type: string = "NS"
target: string = "ns-77-b.gandi.net"
2: array =
host: string = "spip.net"
class: string = "IN"
ttl: long = 34790
type: string = "NS"
target: string = "ns-219-a.gandi.net"
3: array =
host: string = "spip.net"
class: string = "IN"
ttl: long = 34790
type: string = "NS"
target: string = "ns-77-b.gandi.net"
4: array =
host: string = "spip.net"
class: string = "IN"
ttl: long = 34790
type: string = "NS"
target: string = "ns-145-c.gandi.net"
5: array =
host: string = "spip.net"
class: string = "IN"
ttl: long = 34790
type: string = "NS"
target: string = "ns-219-a.gandi.net"
ADDITIONAL SECTION: array =
0: array =
host: string = "ns-219-a.gandi.net"
class: string = "IN"
ttl: long = 34790
type: string = "A"
ip: string = "173.246.100.220"
1: array =
host: string = "ns-219-a.gandi.net"
class: string = "IN"
ttl: long = 34790
type: string = "AAAA"
ipv6: string = "2001:4b98:aaaa::dc"
2: array =
host: string = "ns-219-a.gandi.net"
class: string = "IN"
ttl: long = 34790
type: string = "A"
ip: string = "173.246.100.220"
3: array =
host: string = "ns-219-a.gandi.net"
class: string = "IN"
ttl: long = 34790
type: string = "AAAA"
ipv6: string = "2001:4b98:aaaa::dc"
IPV4: string = "151.80.20.125"

Download

Examples of ARRAY rules

ARRAY[HEADER][AUTHORITY]= 2 /*verify that there are two authoritative servers */
 ARRAY[HEADER][ADDITIONAL]> 0 /* check that there is at least one additional server */
 ARRAY[RAW]=EDNS /* check EDNS support*/
 ARRAY[AUTHORITY SECTION][0][target]=ns-145-c.gandi.net

The last example shows a difficulty: if there are several authoritative servers, what is the rank of the one whose presence we want to check? The '*' sign in the ARRAY [] = rule is used to test all indexes:

ARRAY[AUTHORITY SECTION][*][target]=ns-145-c.gandi.net

Inversion, combination, alert level

The inversion of the rules by NOT is possible for the TIME, MEAN and CONTAINS rules.

The combination of the rules and the definition of the alert level are done in the same way as in the case ofHTTP monitoring rules.

Which DNS server is responding?

A DNS query specifies the server to query by providing the @ parameter as in the following examples:

dns: //ns-219-a.géat/www.spip.net
 dns: // 2001: 4b98: aaaa :: dc / www.spip.net

If the request does not specify the server, the local NSS resolver at address 127.0.0.1 will respond. While this is appropriate in some cases, it is not the best way to ensure that a domain's DNS is working properly, as the resolver will not recursion until the SOA has expired.

Furthermore, when the local resolver responds, it does so in Query time: 0 msec. It is not very interesting to know!

Which DNS server should I query?

To ensure the proper functioning of the DNS, you must contact a domain authoritative nameserver. In the previous example, we queried one of the three authority servers for the domain www.spip.net.

You can find out the list of authority servers for the domain by issuing the following command in command mode:

dig www.spip.net
 
 that returns:
 
 ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> www.spip.net
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3800
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 4096
 ; COOKIE: 798ddf1f8a880829b2ae2fae5f4f590bd9ae0131be4067c2 (good)
 ;; QUESTION SECTION:
 ;www.spip.net. IN A
 
 ;; ANSWER SECTION:
 www.spip.net. 1427 IN A 151.80.20.125
 
 ;; AUTHORITY SECTION:
 spip.net. 126583 IN NS ns-219-a.gandi.net.
 spip.net. 126583 IN NS ns-77-b.gandi.net.
 spip.net. 126583 IN NS ns-145-c.gandi.net.
 
 ;; ADDITIONAL SECTION:
 ns-77-b.gandi.net. 590 IN A 213.167.230.78
 ns-145-c.gandi.net. 545 IN A 217.70.187.146
 ns-219-a.gandi.net. 126583 IN A 173.246.100.220
 ns-77-b.gandi.net. 590 IN AAAA 2001:4b98:aaab::4e
 ns-145-c.gandi.net. 545 IN AAAA 2604:3400:aaac::92
 ns-219-a.gandi.net. 126583 IN AAAA 2001:4b98:aaaa::dc
 
 ;; Query time: 0 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Wed Sep 02 08:34:19 UTC 2020
 ;; MSG SIZE rcvd: 291


A good query would therefore be:
dns://ns-219-a.gandi.net/www.spip.net
Public resolvers are also interesting, for example:
dns://1.1.1.1/www.spip.net /* Cloudflare resolver */
 dns://8.8.8.8/www.spip.net /* Google resolver */
Note about HTTP codes
...



Manage: View / edit tasks
DnC — 2020-10-27T09:07:20Z
See the list of tasks
Go to Manage : View / edit tasks:
The table has 5 columns:
– No: a number assigned to the task by the system, cannot be changed.
– Status: an icon representing the status of the task:
 blank: "en cours de rédaction" (editing in progress): the task is not executed, it is kept in memory.
 green: "publié en ligne" (published online): the task is being executed,
 black: "à la poubelle" (to the dustbin): the task will be destroyed by the system.
– Date: the date of creation of the task, not modifiable.
– A column containing two links:
 View / edit: displays the presentation and / or edit form of the task,
 Delete: Delete the task immediately. Unlike the status "in the trash", this action causes the erasure of all data relating to the task.
Change the status of a task
Place the mouse over the status icon and select the desired status:
Only tasks with "publié en ligne" (published online) status are taken into account for the limitation of the maximum number of tasks authorized by the subscription.

You can therefore set aside a task by assigning it the status "in progress". You can thus create an unlimited number of tasks.
Edit a task
When you click on the "View / edit" link, the task editing form appears (it is identical to the creation form):
Title: A title of your choice. Write a short, meaningful title. The title is mandatory and can be changed at any time.
Request: the request sent. As a first approach, consider that it is the address of a site or a hypertext page on the Internet (a URL). You must specify the URL scheme (http://, https://). You can specify a full URL, with path and request.

Examples of valid URLs:

https://oa.dnc.global/

https://oa.dnc.global/web/-OpenID-Connect-6-.html

https://buy.dnc.global/Network-Soft-Scanning-NSS-19.html?lang=de
Rules: Response expected. See: Règles de surveillance HTTP.

By default, NSS applies a standard rule set. So you can leave this field blank, in most cases this is enough to ensure that a website is working.
Error level: When the error level is not defined by the rule, defines the level of the generated error. Value from 0 to 7, default = 4. The level of the error conditions the transmission of a notification in the event of a task error. See: Manage notifications.

Note that the error level can be defined rule by rule, the level assigned to the task then being the default value.
Status of the task:

Select the status "published online" to activate the task.


AutoPanel : Self-refreshing panels
DnC — 2020-09-24T08:36:26Z
NSS offers three summary panels whose data are periodically refreshed automatically.

In addition to these panels showing information about all the tasks, there is a summary page for observing a given task.
		Access panels
The panels are accessed by the "Boxes", "Fullscreen" and "Lines" buttons present in the Home page and at the head of the monitoring pages:
Auto refresh
Automatic refresh takes two forms:

– The background color of boxes and graphs is updated every minute to reflect the status of the alert (priority). This does not update the data, and in particular, not the graphics.

– The entire page is updated every 10 minutes. This updates the data and graphics.
Warning: due to the computation load induced by the automatic refresh, the intervals indicated and the availability of the various functionalities described in this page are subject to limitations depending on the subscriptions and / or the use made of them.
AutoPanel Boxes
AutoPanel Lines
AutoPanel Fullscreen
This panel is designed to be displayed permanently and to be visible from a distance, for example on a separate screen clearly visible in an open space [1].
Click on the task title to access the summary page:
Summary for a task
This is the most useful panel for tracking the progress of a task reporting errors.

It allows you to see the details of the last two alerts (1), the response time graph, and to navigate to the other views (2) et (3).
		
		
[1] The panel is first opened over the entire surface of the browser window. Press the F11 key to switch to full screen mode.



AutoPanel : Panneaux à rafraîchissement automatique
DnC — 2020-09-23T08:47:13Z
NSS offre trois panneaux de synthèse dont les données sont rafraîchies périodiquement de façon automatique. 

En plus de ces panneaux présentant des informations de toutes les tâches, il existe une page de synthèse permettant de suivre une tâche donnée.
		Accéder aux panneaux
On accède aux panneaux par les boutons "Boxes", "Fullscreen" et "Lines" présents dans la page de sommaire et en tête des pages de suivi :
Rafraîchissement automatique
Le rafraîchissement automatique prend deux formes :

– La couleur de fond des boîtes et des graphes est mise à jour toutes les minutes pour répercuter l'état de l'alerte (priorité). Ceci ne met pas à jour les données, et en particulier, pas les graphiques.

– La page entière est remise à jour toutes les 10 minutes. Ceci met à jour les données et les graphiques. Cette deuxième forme est limité aux seuls onglets actifs (ayant le focus).
Avertissement : du fait de la charge de calcul induite par le rafraîchissement automatique, les périodicité indiquées et la disponibilité des différentes fonctionnalités décrites dans cette page sont sujettes à limitations selon les abonnements et/ou l'usage qui en est fait.
AutoPanel Boxes
AutoPanel Lines
AutoPanel Fullscreen
Ce panneau est conçu pour être affiché de façon permanente et être visible de loin, par exemple sur un écran séparé bien visible dans un espace ouvert [1].
Cliquez sur le titre de la tâche pour accéder à la page de synthèse.
Synthèse pour une tâche
C'est le panneau le plus utile pour suivre l'évolution d'une une tâche rapportant des erreurs. 

Il permet de voir le détail des deux dernières alertes (1), le graphe des temps de réponse, et de naviguer vers les autres vues (2) et (3).
Notification de bureau (Web Push)
Sur certaines configuration de système et de navigateur, les pages AutoPanel génèrent des Notifications de bureau (Web Push).
		
		
[1] Le panneau est d'abord ouvert sur toute la surface de la fenêtre du navigateur. Actionnez la touche F11 pour passer en mode plein écran.



Règles de surveillance DNS
DnC — 2020-09-03T13:54:37Z
NSS permet d'émettre régulièrement une requête DNS, attend une réponse et l'interprète en appliquant des règles. Si une situation d'erreur est détectée, NSS génère une alerte.
Les règles de surveillance DNS offertes par NSS Lite vous permettent de vérifier tous les aspects de la configuration DNS du domaine considéré, en plus de la vérification du temps de réponse.
		Requête DNS
Une requête DNS est inscrite dans le champ "Requête" de la tâche sous le format :
dns:[//[:]/][?]
où :
– server : (facultatif) URL d'un serveur DNS particulier.

– domain (obligatoire) : le domaine de l'enregistrement dans la zone DNS.

– type : (facultatif, A) le type d'enregistrement dans la zone DNS du domaine : A, AAAA, CNAME, MX, NS, SOA, SPF, TXT. Si ce paramètre n'est pas compris, une erreur sera générée.
exemples :
dns:buy.dnc.global
 dns:dnc.global?NS
 dns://dns102.ovh.net/buy.dnc.global
 dns:degoy.com?A
 dns:degoy.com?AAAA
 dns://dns200.anycast.me/degoy.com?AAAA
 dns:degoy.com?MX
 dns://ns-219-a.gandi.net/www.spip.net
 dns://1.1.1.1/dnc.global /* Cloudflare resolver */
 dns://8.8.8.8/dnc.global /* Google resolver */
 dns://213.186.33.99/dnc.global?AAAA /* OVH resolver France*/
 dns://5.196.123.133/dnc.global?AAAA /* OVH resolver, Spain */
 dns://193.252.10.2/dnc.global /* Orange, Aubervilliers, France */
NSS émet la requête DNS sous la forme d'une commande Unix/Linux DIG de la forme suivante :

dig [ ][@server[:port] ] 
Par exemple la réponse à la requête dns:degoy.com?MX sera traduite en :
 dig MX degoy.com.
Dans la plupart des cas, il vous suffira d'inscrire une requête DNS dans le champ "Requête" de la tâche comme indiqué ci-dessus. Ne lisez la suite que si vous souhaitez analyser la réponse du DNS au-delà des règles par défaut.
Réponse
Si la requête réussit, NSS analyse la réponse retournée par DIG. 

Voici par exemple la réponse à la requête dns:degoy.com ?MX (traduite en dig MX degoy.com) :
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.7 <<>> MX degoy.com
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36151
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;degoy.com. IN MX
 
 ;; ANSWER SECTION:
 degoy.com. 600 IN MX 5 mx1.mail.ovh.net.
 degoy.com. 600 IN MX 100 mx3.mail.ovh.net.
 degoy.com. 600 IN MX 1 mx0.mail.ovh.net.
 degoy.com. 600 IN MX 200 mail.rollernet.us.
 degoy.com. 600 IN MX 200 mail2.rollernet.us.
 degoy.com. 600 IN MX 50 mx2.mail.ovh.net.
 
 ;; Query time: 11 msec
 ;; SERVER: 213.186.33.99#53(213.186.33.99)
 ;; WHEN: Tue Sep 1 17:22:07 2020
 ;; MSG SIZE rcvd: 174
En cas d'échec, NSS enregistrera une erreur.
Règles implicites et par défaut
La réponse attendue par NSS à la suite d'une requête DNS figure dans le champ "Règles" de la tâche. Ce champ est facultatif. Qu'il soit renseigné ou non, des règles implicites s'appliquent :
status : NOERROR : NSS vérifie que la réponse du DNS comporte "status : NOERROR". Dans le cas contraire, une alerte de niveau 5 au moins est générée.
Temps de réponse : NSS surveille toujours le temps de réponse par rapport au délai moyen constaté pour la tâche. 

Une alerte est générée avec un niveau égal à 2, ou le niveau indiqué dans la définition de la tâche, si le temps de réponse excède 4 fois le délai moyen.
Pour plus de détails sur ce sujet, voyez : Surveillance du temps de réponse.
Règles par défaut : de plus, si le champ règle n'est pas renseigné, NSS applique les règles suivantes, supposant une réponse attendue dans un délai inférieur à 50 ms :
TIME<50:3
 TIME<100:4
 TIME<500:5
Ces règles permettent déjà d'effectuer une surveillance efficace sans avoir à attribuer des règles à la tâche. Ainsi la simple requête :
dns://ns-219-a.gandi.net/www.spip.net
permet de surveiller la résolution du nom de domaine www.spip.net par un de ses serveurs DNS faisant autorité.
Règles applicables à la requête DNS


– TIME< nombre de ms : Vérifie que le serveur retourne la réponse dans un délai inférieur à la valeur indiquée en ms.
– MEAN< nombre de ms : Vérifie que le serveur retourne la réponse dans un délai moyen inférieur à la valeur indiquée en ms.
– IPV4= NNN.NNN.NNN.NNN : la règle la plus essentielle, permettant de vérifier que le nom de domaine indiqué dans la requête DNS est résolu et égal à l'adresse IPv4 indiquée.
– QUERY TIME< nombre de ms : temps de réponse du serveur DNS.
Note : les règles TIME et MEAN prennent en compte le temps de réponse total de la requête, y compris les temps de transmission, que le DNS réponde ou non) alors que QUERY TIME porte sur le temps figurant dans la réponse du DNS.
– CONTAINS chaîne de caractères : cette règle permet de vérifier la présence d'une chaîne dans la réponse brute.
– MATCH chaîne de caractères : cette règle permet de vérifier la présence d'une chaîne quelconque dans la réponse brute. La chaîne de caractère peut être une expression régulière standard, il est donc possible d'effectuer n'importe quelle vérification dans la réponse. Cependant, l'utilisation de la règle ARRAY sera le plus souvent préférable.
– ARRAY[index]= chaîne de caractères : Vérifie que la chaîne de caractères se trouve dans la valeur du tableau à l'indice A. Notons qu'il s'agit d'une inclusion et non d'une égalité, la règle se comportant comme CONTAINS. L'index peut être multidimensionnel.
– ARRAY[index]> nombre : Vérifie que la valeur du tableau à l'indice A est supérieure au nombre indiqué. L'index peut être multidimensionnel.
En savoir plus sur la règle ARRAY...
La règle ARRAY... complète le jeu de règles pour tester n'importe quelle information retournée par la requête DNS.
Comment NSS traduit les réponses
Pour effectuer une requête, NSS fait appel à DIG puis décompose la réponse dans un tableau associatif. Les règles portent sur les éléments de ce tableau. 

En règle générale, vous n'aurez pas à vous occuper de ce tableau. Cependant, la formulation d'une règle ARRAY suppose de bien connaître la structure de ce tableau.
Voici comment, en interne, NSS traduit en tableau la requête précédente :
: array = 
 RAW: string = " ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> www.spip.net\n;; global options: +cmd\n;; Got answer:\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 594\n;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3\n\n;; OPT PSEUDOSECTION:\n; EDNS: version: 0, flags:; udp: 4096\n; COOKIE: f182cd5130c105c8056d4eed5f50bf97a6b668e584c7b2e7 (good)\n;; QUESTION SECTION:\n;www.spip.net.\t\t\tIN\tA\n\n;; ANSWER SECTION:\nwww.spip.net.\t\t1979\tIN\tA\t151.80.20.125\n\n;; AUTHORITY SECTION:\nspip.net.\t\t34795\tIN\tNS\tns-145-c.gandi.net.\nspip.net.\t\t34795\tIN\tNS\tns-77-b.gandi.net.\nspip.net.\t\t34795\tIN\tNS\tns-219-a.gandi.net.\n\n;; ADDITIONAL SECTION:\nns-219-a.gandi.net.\t34795\tIN\tA\t173.246.100.220\nns-219-a.gandi.net.\t34795\tIN\tAAAA\t2001:4b98:aaaa::dc\n\n;; Query time: 0 msec\n;; SERVER: 127.0.0.1#53(127.0.0.1)\n;; WHEN: Thu Sep 03 10:04:07 UTC 2020\n;; MSG SIZE rcvd: 203\n"
 ; <<>> DIG 9.11.5-P4-5.1+DEB10U2-DEBIAN <<>> WWW.SPIP.NET: string = ""
 GLOBAL OPTIONS: string = " +cmd "
 GOT ANSWER: string = " "
 HEADER: array = 
 opcode: string = " QUERY"
 status: string = " NOERROR"
 id: string = " 594 "
 flags: string = " qr rd ra"
 QUERY: string = " 1"
 ANSWER: string = " 1"
 AUTHORITY: string = " 3"
 ADDITIONAL: string = " 3 "
 OPT PSEUDOSECTION: string = " ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: f182cd5130c105c8056d4eed5f50bf97a6b668e584c7b2e7 (good) "
 QUESTION SECTION: string = "www.spip.net. IN A "
 QUERY TIME: string = " 0 msec "
 SERVER: string = " 127.0.0.1#53(127.0.0.1) "
 WHEN: string= "Thu Sep 03 10:04:07 UTC 2020"
 MSG SIZE RCVD: string = " 203 "
 ANSWER SECTION: array = 
 0: array = 
 host: string = "www.spip.net"
 class: string = "IN"
 ttl: long = 1974
 type: string = "A"
 ip: string = "151.80.20.125"
 AUTHORITY SECTION: array = 
 0: array = 
 host: string = "spip.net"
 class: string = "IN"
 ttl: long = 34790
 type: string = "NS"
 target: string = "ns-145-c.gandi.net"
 1: array = 
 host: string = "spip.net"
 class: string = "IN"
 ttl: long = 34790
 type: string = "NS"
 target: string = "ns-77-b.gandi.net"
 2: array = 
 host: string = "spip.net"
 class: string = "IN"
 ttl: long = 34790
 type: string = "NS"
 target: string = "ns-219-a.gandi.net"
 3: array = 
 host: string = "spip.net"
 class: string = "IN"
 ttl: long = 34790
 type: string = "NS"
 target: string = "ns-77-b.gandi.net"
 4: array = 
 host: string = "spip.net"
 class: string = "IN"
 ttl: long = 34790
 type: string = "NS"
 target: string = "ns-145-c.gandi.net"
 5: array = 
 host: string = "spip.net"
 class: string = "IN"
 ttl: long = 34790
 type: string = "NS"
 target: string = "ns-219-a.gandi.net"
 ADDITIONAL SECTION: array = 
 0: array = 
 host: string = "ns-219-a.gandi.net"
 class: string = "IN"
 ttl: long = 34790
 type: string = "A"
 ip: string = "173.246.100.220"
 1: array = 
 host: string = "ns-219-a.gandi.net"
 class: string = "IN"
 ttl: long = 34790
 type: string = "AAAA"
 ipv6: string = "2001:4b98:aaaa::dc"
 2: array = 
 host: string = "ns-219-a.gandi.net"
 class: string = "IN"
 ttl: long = 34790
 type: string = "A"
 ip: string = "173.246.100.220"
 3: array = 
 host: string = "ns-219-a.gandi.net"
 class: string = "IN"
 ttl: long = 34790
 type: string = "AAAA"
 ipv6: string = "2001:4b98:aaaa::dc"
 IPV4: string = "151.80.20.125" 
Télécharger
Exemples de règles ARRAY 
ARRAY[HEADER][AUTHORITY]= 2 /* vérifier qu'il y a deux serveurs faisant autorité */
 ARRAY[HEADER][ADDITIONAL]> 0 /* vérifier qu'il y a au moins un serveur additionnel */
 ARRAY[RAW]=EDNS /* vérifie la prise en charge d'EDNS */
 ARRAY[AUTHORITY SECTION][0][target]=ns-145-c.gandi.net
Le dernier exemple montre une difficulté : s'il y a plusieurs serveurs faisant autorité, quel est le rang de celui dont on veut vérifier la présence ? Le signe '*' dans la règle ARRAY[]= permet de tester tous les index :
ARRAY[AUTHORITY SECTION][*][target]=ns-145-c.gandi.net
Inversion, combinaison, niveau d'alerte
L'inversion des règles par NOT est possible pour les règles TIME, MEAN et CONTAINS.
La combinaison des règles et la définition du niveau d'alerte se font de la même manière que dans le cas des Règles de surveillance HTTP.
Quel serveur DNS répond ?
Une requête DNS précise le serveur à interroger en fournissant le paramètre @ comme dans les exemples suivants :
dns://ns-219-a.gandi.net/www.spip.net
 dns://2001:4b98:aaaa::dc/www.spip.net
Si la requête ne précise pas le serveur, ce sera le resolver local de NSS à l'adresse 127.0.0.1 qui répondra. Bien que ce soit approprié dans certains cas, ce n'est pas la meilleure façon de s'assurer du bon fonctionnement des DNS d'un domaine, car le resolver n'effectuera pas de récursion avant que le SOA ait expiré.
De plus, quand le résolver local répond, il le fait en Query time : 0 msec. Ce n'est pas très intéressant à savoir !
Quel serveur DNS faut-il interroger ?
Pour vous assurer du bon fonctionnement des DNS, il faut s'adresser à un serveur autorité du domaine (domain authoritative nameserver). Dans l'exemple précédent, nous avons interrogé un des trois serveurs autorité pour le domaine www.spip.net.
On peut connaître la liste des serveurs autorité pour le domaine en émettant la commande suivante en mode de commande :
dig www.spip.net
 
 qui retourne :
 
 ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> www.spip.net
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3800
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 4096
 ; COOKIE: 798ddf1f8a880829b2ae2fae5f4f590bd9ae0131be4067c2 (good)
 ;; QUESTION SECTION:
 ;www.spip.net. IN A
 
 ;; ANSWER SECTION:
 www.spip.net. 1427 IN A 151.80.20.125
 
 ;; AUTHORITY SECTION:
 spip.net. 126583 IN NS ns-219-a.gandi.net.
 spip.net. 126583 IN NS ns-77-b.gandi.net.
 spip.net. 126583 IN NS ns-145-c.gandi.net.
 
 ;; ADDITIONAL SECTION:
 ns-77-b.gandi.net. 590 IN A 213.167.230.78
 ns-145-c.gandi.net. 545 IN A 217.70.187.146
 ns-219-a.gandi.net. 126583 IN A 173.246.100.220
 ns-77-b.gandi.net. 590 IN AAAA 2001:4b98:aaab::4e
 ns-145-c.gandi.net. 545 IN AAAA 2604:3400:aaac::92
 ns-219-a.gandi.net. 126583 IN AAAA 2001:4b98:aaaa::dc
 
 ;; Query time: 0 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Wed Sep 02 08:34:19 UTC 2020
 ;; MSG SIZE rcvd: 291

Une bonne requête serait donc :
dns://ns-219-a.gandi.net/www.spip.net
Les resolvers publics sont également intéressants, par exemple :
dns://1.1.1.1/www.spip.net /* Cloudflare resolver */
 dns://8.8.8.8/www.spip.net /* Google resolver */
Alerte
...
Note à propos des codes HTTP
...



Schnellstart
DnC — 2020-07-16T19:38:49Z
Erstellen Sie schnell eine erste Überwachungsaufgabe in drei einfachen Schritten.
		1. Abonnement erwerben
Um NNS Lite zu abonnieren, besuchen Sie die i-Tego SaaS-Site auf der Seite: Network Soft Scanning (NSS) .
Alles geschieht wie auf einer klassischen Verkaufsseite: Wählen Sie ein Produkt aus, geben Sie eine Bestellung auf und zahlen Sie online.

Es wird eine Zeit kommen, in der Sie sich identifizieren müssen. Wenn Sie noch kein Konto bei i-Tego SaaS haben, müssen Sie Ihr Konto erstellen.
Sobald die Erfassung abgeschlossen ist, kann die Anwendung sofort auf dieser Site verwendet werden, wobei die Kennungen (Login und Passwort) beim Erstellen Ihres Kontos aufgezeichnet werden.
2. Konfigurieren Sie eine Aufgabe
Sobald das Abonnement validiert wurde, gehen Sie zum Abschnitt Verwalten und klicken Sie auf: Aufgabe erstellen.

Das folgende Formular wird angezeigt.
Für eine einfache Überwachung müssen Sie nur einen Titel und eine URL eingeben:
Ihre erste Überwachung funktioniert, wie Sie auf der Startseite sehen können.
3. Benachrichtigung konfigurieren
Sie möchten jetzt im Falle einer Fehlfunktion eine Nachricht erhalten. Gehen Sie zur Seite Benachrichtigungen verwalten.
Sie müssen lediglich die E-Mail-Adresse, an die Nachrichten gesendet werden sollen, in das Feld "Empfänger von E-Mail-Benachrichtigungen" eingeben. Es können mehrere Adressen angegeben werden.
Lassen Sie zunächst die anderen Felder leer oder behalten Sie die Standardwerte bei.
Und dann ?
– Siehe den Alarmverlauf auf der Seite Warnungen,

– Neue Aufgaben erstellen wenn Ihr Abonnement dies zulässt,

– Sehen Sie sich die Liste Ihrer Aufgaben an und ändern Sie sie.

– Gehen Sie zu Ihrem Konto bei i-Tego SaaS und folgen Sie den Produkten, die Sie abonniert haben.
Informationen zu Anmeldeinformationen
Für den Zugriff auf alle Anwendungen und das i-Tego SaaS-System selbst verwenden Sie nur einen Satz von Kennungen: die Anmeldung und das Kennwort, die Sie beim Erstellen Ihres Kontos gespeichert haben.
Der Login kann nicht geändert werden.

Passwort vergessen ? Gehen Sie hier.
Gut gemacht! hatte alles getan, um Ihre Website effektiv zu überwachen. Guter Rat: Lassen Sie den Rest der Dokumentation für später.


Caractéristiques et Limitations
DnC — 2020-07-13T07:14:14Z
Périodicité
Lorsque NSS Lite doit télécharger le corps de la réponse (body) pour analyser les réponses attendues, la période de répétition des requêtes est de 10 minutes. 

Lorsque les requêtes n'ont besoin que de l'en-tête de la réponse (header) la période de répétition est une minute.
Requête HTTP
La requête est limitée aux arguments scheme (http ou https), host, path, query et fragment comme dans :

scheme://host/path?query#fragment

Les arguments scheme et host sont obligatoires.

Les arguments path, query et fragment sont facultatifs.
Exemple d'URL HTTP valide :

https://oa.dnc.global/web/-Decouvrir-.html#saasetoidcunmariagereussigraceaoauthsd
L'URL doit être libellé en ASCII, les noms de domaine internationalisés (contenant des caractères non ASCII) échoueront.
NSS Pro permet d'utiliser des URLs plus étendues.
Méthode HTTP de la requête
NSS Lite émet une requête HTTP avec la méthode GET si le corps de la réponse est nécessaire. Sinon, la méthode est HEAD.
Dans l'état actuel du développement, NSS ne traite pas les méthodes POST, PUT, DELETE, TRACE et CONNECT.
Limitation du téléchargement
Lorsque le corps de la réponse est nécessaire, NSS Lite ne télécharge que les 20 000 premiers caractères. Il s'agit de la longueur avant décompression, la longueur des données obtenues peut être significativement plus importante.
Il faut tenir compte de cette limitation pour les règles nécessitant le corps de la réponse, tels que CONTAINS.
Il faut noter que la présence d'un fragment dans l'URL ne change rien au fait que les données sont chargées à partir du début de la page. La présence de l'ancre du fragment et de texte à la suite n'est donc pas garantie.
Analyse de la réponse
Si la réponse est une liste ou un tableau JSON (le type Mime de la réponse est "application/json"), NSS Lite décode le tableau dont le contenu peut être analysé avec les règles JSON_xxx.
Dans tous les autres cas, NSS Lite analyse le corps de la réponse comme une simple chaîne.
Le codage attendu est UTF-8.