Toute la puissance de l'interaction avec l'API se dévoile lors de son utilisation conjointe avec du code, permettant de générer dynamiquement des requêtes API et des outils d'analyse des réponses API. Cependant, cela reste encore peu remarqué. Kit de Développement Logiciel Python (ci-après — SDK Python) pour l'API de Gestion Check Point, à tort. Il facilite considérablement la vie aux développeurs et aux passionnés d'automatisation. Python a acquis une immense popularité ces dernières années et j'ai décidé de combler ce vide et de faire un aperçu des principales possibilités . Cet article sert d'excellente complément à un autre article sur Habr. . Nous allons voir comment écrire des scripts en utilisant le SDK Python et nous nous attarderons en détail sur la nouvelle fonctionnalité de l'API de Gestion dans la version 1.6 (supportée depuis R80.40). Pour comprendre cet article, des connaissances de base sur le travail avec les API et Python sont nécessaires.
Check Point développe activement son API et à ce jour, les suivantes sont disponibles :
- — travail avec le serveur de gestion via l'API (et possibilité d'exécuter des scripts sur les passerelles gérées par le serveur de gestion)
- — travail avec les passerelles de sécurité
- — travail avec le bac à sable dans le cloud Check Point
- — utilisation de la lame de Conscience d'Identité sur les passerelles
- — travail avec le portail de gestion des passerelles SMB ()
- — interaction avec les contrôleurs IoT
- — travail avec (solution de sécurité SD-WAN)
- — travail avec
Le SDK Python prend actuellement en charge uniquement l'interaction avec l'API de Gestion et l'API Gaia. Nous examinerons les classes, méthodes et variables les plus importantes dans ce module.
Installation du module
Module cpapi s'installe rapidement et simplement depuis à l'aide de pip. Une instruction détaillée sur l'installation est disponible dans . Ce module est adapté pour fonctionner avec les versions Python 2.7 et 3.7. Dans cet article, des exemples seront présentés en utilisant Python 3.7. Cependant, le SDK Python peut être exécuté directement depuis le serveur de gestion Check Point (Smart Management), mais seule la version Python 2.7 y est supportée, donc la dernière section fournira le code pour la version 2.7. Juste après l'installation du module, je recommande de consulter les exemples dans les répertoires examples_python2 et examples_python3.
Commencer
Pour que nous puissions travailler avec les composants du module cpapi, il est nécessaire d'importer à partir du module cpapi au moins deux classes nécessaires :
APIClient et APIClientArgs
from cpapi import APIClient, APIClientArgs
Classe APIClientArgs s’occupent des paramètres de connexion au serveur API, et la classe APIClient s’occupe de l’interaction avec l’API.
Définissons les paramètres de connexion
Pour définir divers paramètres de connexion à l'API, il faut créer une instance de la classe APIClientArgs. En principe, ses paramètres sont prédéfinis et lors de l'exécution du script sur le serveur de gestion, il n'est pas nécessaire de les spécifier.
client_args = APIClientArgs()Mais lors de l'exécution sur un hébergeur tiers, il est nécessaire de spécifier au moins l'adresse IP ou le nom d’hôte du serveur API (également le serveur de gestion). Dans l'exemple ci-dessous, nous définissons le paramètre de connexion server et lui assignons l'adresse IP du serveur de gestion sous forme de chaîne.
client_args = APIClientArgs(server='192.168.47.241')Voyons tous les paramètres et leurs valeurs par défaut que l'on peut utiliser pour se connecter au serveur API :
Arguments de la méthode __init__ de la classe APIClientArgs
class APIClientArgs:
"""
Cette classe fournit des arguments pour la configuration d'APIClient.
Tous les arguments sont configurés avec leurs valeurs par défaut.
"""
# le port est défini sur None par défaut, mais il est remplacé par 443 s'il n'est pas spécifié
# valeurs possibles du contexte - web_api (par défaut) ou gaia_api
def __init__(self, port=None, fingerprint=None, sid=None, server="127.0.0.1", http_debug_level=0,
api_calls=None, debug_file="", proxy_host=None, proxy_port=8080,
api_version=None, unsafe=False, unsafe_auto_accept=False, context="web_api"):
self.port = port
# empreinte du serveur de gestion
self.fingerprint = fingerprint
# session-id.
self.sid = sid
# nom ou adresse IP du serveur de gestion
self.server = server
# niveau de débogage
self.http_debug_level = http_debug_level
# un tableau avec tous les appels API (à des fins de débogage)
self.api_calls = api_calls if api_calls else []
# nom du fichier de débogage. S'il est laissé vide, les données de débogage ne seront pas sauvegardées sur le disque.
self.debug_file = debug_file
# adresse du serveur proxy HTTP (sans "http://")
self.proxy_host = proxy_host
# port proxy HTTP
self.proxy_port = proxy_port
# version API du serveur de gestion
self.api_version = api_version
# Indique que le client ne doit pas vérifier le certificat du serveur
self.unsafe = unsafe
# Indique que le client doit accepter et sauvegarder automatiquement le certificat du serveur
self.unsafe_auto_accept = unsafe_auto_accept
# Le contexte d'utilisation du client - par défaut web_api
self.context = contextJe suppose que les arguments que l'on peut utiliser dans les instances de la classe APIClientArgs sont intuitivement clairs pour les administrateurs Check Point et ne nécessitent pas de commentaires supplémentaires.
Connectons-nous via APIClient et le gestionnaire de contexte
Classe APIClient Il est plus pratique de l'utiliser via le gestionnaire de contexte. Tout ce qui doit être transmis à une instance de la classe APIClient ce sont les paramètres de connexion définis à l'étape précédente.
with APIClient(client_args) as client:
Le gestionnaire de contexte n'effectuera pas automatiquement l'appel login sur le serveur API, mais il effectuera l'appel logout à la sortie. Si pour une raison quelconque le logout à la fin du travail avec les appels API n'est pas nécessaire, il faut commencer le travail sans utiliser le gestionnaire de contexte :
client = APIClient(clieng_args)Vérification de la connexion
Il est plus simple de vérifier si la connexion passe avec les paramètres donnés en utilisant la méthode check_fingerprint. Si la vérification du hash sha1 pour le fingerprint du certificat du serveur API échoue (la méthode retourne False), cela est généralement dû à des problèmes de connexion et nous pouvons arrêter l'exécution du programme (ou permettre à l'utilisateur de corriger les données de connexion) :
if client.check_fingerprint() is False:
print("Impossible d'obtenir le fingerprint du serveur - Vérifiez la connectivité avec le serveur.")
exit(1)
Notez que plus tard, la classe APIClient vérifiera à chaque appel API (méthodes api_call et api_query, dont nous parlerons un peu plus loin) le sha1 fingerprint du certificat sur le serveur API. En cas d'erreur lors de la vérification du sha1 fingerprint du certificat du serveur API (certificat inconnu ou modifié), la méthode check_fingerprint offrira la possibilité d'ajouter/modifier les informations à son sujet sur la machine locale de manière automatique. Cette vérification peut être complètement désactivée (mais cela ne peut être recommandé que lors de l'exécution de scripts sur le serveur API lui-même, en se connectant à 127.0.0.1), en utilisant l'argument APIClientArgs — unsafe_auto_accept voir plus de détails sur APIClientArgs précédemment dans «Définir les paramètres de connexion».
client_args = APIClientArgs(unsafe_auto_accept=True)Connexion au serveur API
Il y a APIClient trois méthodes de connexion au serveur API, et chacune d'elles mémorise la valeur sid(identifiant de session), qui est automatiquement utilisée dans chaque appel API suivant dans l'en-tête (le nom dans l'en-tête pour ce paramètre — X-chkp-sid), donc il n'est pas nécessaire de traiter ce paramètre supplémentaire.
Méthode de connexion
Option avec utilisation du login et du mot de passe (dans l'exemple, le nom d'utilisateur admin et le mot de passe 1q2w3e sont passés en tant qu'arguments positionnels) :
login = client.login('admin', '1q2w3e') Dans la méthode de connexion, des paramètres optionnels supplémentaires sont également disponibles, je vous donne leurs noms et valeurs par défaut :
continue_last_session=False, domain=None, read_only=False, payload=NoneMéthode login_with_api_key
Option utilisant une clé API (prise en charge à partir de la version de gestion R80.40 / Management API v1.6, «3TsbPJ8ZKjaJGvFyoFqHFA==» c'est la valeur de la clé API pour l'un des utilisateurs sur le serveur de gestion avec la méthode d'autorisation clé API) :
login = client.login_with_api_key('3TsbPJ8ZKjaJGvFyoFqHFA==') Dans la méthode login_with_api_key les mêmes paramètres optionnels sont disponibles que dans la méthode login.
Méthode login_as_root
Option de connexion à la machine locale avec le serveur API :
login = client.login_as_root()Pour cette méthode, seulement deux paramètres optionnels sont disponibles :
domain=None, payload=NoneEt enfin, les appels API eux-mêmes
Nous avons deux options pour faire des appels API via les méthodes. api_call et api_queryVoyons maintenant la différence entre elles.
api_call
Cette méthode est applicable pour tous les appels. Nous devons transmettre la dernière partie de l'appel API et le payload dans le corps de la requête si nécessaire. Si le payload est vide, il n'est pas nécessaire de le transmettre :
api_versions = client.api_call('show-api-versions') La sortie pour cette requête est ci-dessous :
In [23]: api_versions
Out[23]:
APIResponse({
"data": {
"current-version": "1.6",
"supported-versions": [
"1",
"1.1",
"1.2",
"1.3",
"1.4",
"1.5",
"1.6"
]
},
"res_obj": {
"data": {
"current-version": "1.6",
"supported-versions": [
"1",
"1.1",
"1.2",
"1.3",
"1.4",
"1.5",
"1.6"
]
},
"status_code": 200
},
"status_code": 200,
"success": true
})
show_host = client.api_call('show-host', {'name' : 'h_8.8.8.8'})La sortie pour cette requête est ci-dessous :
Dans [25]: show_host
Out[25]:
APIResponse({
"data": {
"color": "noir",
"comments": "",
"domain": {
"domain-type": "domaine",
"name": "Utilisateur SMC",
"uid": "41e821a0-3720-11e3-aa6e-0800200c9fde"
},
"groups": [],
"icon": "Objects/host",
"interfaces": [],
"ipv4-address": "8.8.8.8",
"meta-info": {
"creation-time": {
"iso-8601": "2020-05-01T21:49+0300",
"posix": 1588358973517
},
"creator": "admin",
"last-modifier": "admin",
"last-modify-time": {
"iso-8601": "2020-05-01T21:49+0300",
"posix": 1588358973517
},
"lock": "déverrouillé",
"validation-state": "ok"
},
"name": "h_8.8.8.8",
"nat-settings": {
"auto-rule": false
},
"read-only": false,
"tags": [],
"type": "hôte",
"uid": "c210af07-1939-49d3-a351-953a9c471d9e"
},
"res_obj": {
"data": {
"color": "noir",
"comments": "",
"domain": {
"domain-type": "domaine",
"name": "Utilisateur SMC",
"uid": "41e821a0-3720-11e3-aa6e-0800200c9fde"
},
"groups": [],
"icon": "Objects/host",
"interfaces": [],
"ipv4-address": "8.8.8.8",
"meta-info": {
"creation-time": {
"iso-8601": "2020-05-01T21:49+0300",
"posix": 1588358973517
},
"creator": "admin",
"last-modifier": "admin",
"last-modify-time": {
"iso-8601": "2020-05-01T21:49+0300",
"posix": 1588358973517
},
"lock": "déverrouillé",
"validation-state": "ok"
},
"name": "h_8.8.8.8",
"nat-settings": {
"auto-rule": false
},
"read-only": false,
"tags": [],
"type": "hôte",
"uid": "c210af07-1939-49d3-a351-953a9c471d9e"
},
"status_code": 200
},
"status_code": 200,
"success": true
})
api_query
Je précise tout de suite que cette méthode n'est applicable que pour les appels dont la sortie comprend un offset. Ce type de sortie se produit lorsqu'il contient ou peut contenir une grande quantité d'informations. Par exemple, cela peut être une requête pour obtenir la liste de tous les objets de type hôte créés sur le serveur de gestion. Pour de telles requêtes, l'API renvoie par défaut une liste de 50 objets (le limite peut être augmentée jusqu'à 500 objets dans la réponse). Et pour éviter de tirer l'information plusieurs fois en changeant le paramètre offset dans la requête API, il existe une méthode api_query qui effectue ce travail automatiquement. Exemples d'appels où cette méthode est nécessaire : show-sessions, show-hosts, show-networks, show-wildcards, show-groups, show-address-ranges, show-simple-gateways, show-simple-clusters, show-access-roles, show-trusted-clients, show-packages. En fait, dans le nom de ces appels API, nous voyons des mots au pluriel, donc ces appels seront plus faciles à traiter via api_query
show_hosts = client.api_query('show-hosts') La sortie pour cette requête est ci-dessous :
Dans [21]: show_hosts
Sortie[21]:
APIResponse({
"data": [
{
"domain": {
"domain-type": "domain",
"name": "Utilisateur SMC",
"uid": "41e821a0-3720-11e3-aa6e-0800200c9fde"
},
"ipv4-address": "192.168.47.1",
"name": "h_192.168.47.1",
"type": "host",
"uid": "5d7d7086-d70b-4995-971a-0583b15a2bfc"
},
{
"domain": {
"domain-type": "domain",
"name": "Utilisateur SMC",
"uid": "41e821a0-3720-11e3-aa6e-0800200c9fde"
},
"ipv4-address": "8.8.8.8",
"name": "h_8.8.8.8",
"type": "host",
"uid": "c210af07-1939-49d3-a351-953a9c471d9e"
}
],
"res_obj": {
"data": {
"from": 1,
"objects": [
{
"domain": {
"domain-type": "domain",
"name": "Utilisateur SMC",
"uid": "41e821a0-3720-11e3-aa6e-0800200c9fde"
},
"ipv4-address": "192.168.47.1",
"name": "h_192.168.47.1",
"type": "host",
"uid": "5d7d7086-d70b-4995-971a-0583b15a2bfc"
},
{
"domain": {
"domain-type": "domain",
"name": "Utilisateur SMC",
"uid": "41e821a0-3720-11e3-aa6e-0800200c9fde"
},
"ipv4-address": "8.8.8.8",
"name": "h_8.8.8.8",
"type": "host",
"uid": "c210af07-1939-49d3-a351-953a9c471d9e"
}
],
"to": 2,
"total": 2
},
"status_code": 200
},
"status_code": 200,
"success": true
})
Traitement des résultats des appels API
Après cela, vous pouvez utiliser les variables et méthodes de la classe APIResponse(à l’intérieur du gestionnaire de contexte ou à l’extérieur). La classe APIResponse précède 4 méthodes et 5 variables, sur les plus importantes nous nous attarderons davantage.
success
Pour commencer, il serait bon de s'assurer que l'appel API a été effectué avec succès et a renvoyé un résultat. Pour cela, il existe une méthode success:
Dans [49]: api_versions.success
Sortie[49]: True
Renvoie True si l'appel API a été réussi (Code de réponse — 200) et False si non réussi (tout autre code de réponse). Pratique à utiliser immédiatement après l'appel API, afin d'afficher différentes informations en fonction du code de réponse.
if api_ver.success:
print(api_versions.data)
else:
print(api_versions.err_message) statuscode
Renvoie le code de réponse après l'exécution de l'appel API.
Dans [62]: api_versions.status_code
Sortie[62]: 400
Codes de réponse possibles : 200,400,401,403,404,409,500,501.
set_success_status
Il peut être nécessaire de modifier la valeur du statut success. Techniquement, on peut y mettre n'importe quoi, même une simple chaîne. Mais un exemple réel pourrait être de réinitialiser ce paramètre à False dans certaines conditions associées. Ci-dessous, vous pouvez voir un exemple où il y a des tâches exécutées sur le serveur de gestion, mais nous allons considérer cette demande comme échouée (nous allons définir la variable success à False, même si l'appel API a réussi et a renvoyé le code 200).
for task in task_result.data["tasks"]:
if task["status"] == "failed" or task["status"] == "partially succeeded":
task_result.set_success_status(False)
breakresponse()
La méthode response permet de voir le dictionnaire avec le code de réponse (status_code) et le corps de la réponse (body).
In [94]: api_versions.response()
Out[94]:
{'status_code': 200,
'data': {'current-version': '1.6',
'supported-versions': ['1', '1.1', '1.2', '1.3', '1.4', '1.5', '1.6']}}
data
Permet de voir uniquement le corps de la réponse (body) sans informations superflues.
In [93]: api_versions.data
Out[93]:
{'current-version': '1.6',
'supported-versions': ['1', '1.1', '1.2', '1.3', '1.4', '1.5', '1.6']}
error_message
Cette information est disponible uniquement lorsqu'une erreur s'est produite lors du traitement de la requête API (code de réponse ne 200). Exemple de sortie
In [107]: api_versions.error_message
Out[107]: 'code: generic_err_invalid_parameter_name
message: Unrecognized parameter [1]
'
Exemples utiles
Ci-dessous, vous trouverez des exemples utilisant des appels API qui ont été ajoutés dans la version Management API 1.6.
Commençons par examiner le fonctionnement des appels add-host et add-address-range. Supposons que nous devions créer tous les adresses IP de la sous-réseau 192.168.0.0/24 en tant qu'objets de type hôte dont le dernier octet est 5, tandis que toutes les autres adresses IP doivent être enregistrées en tant qu'objets de type plage d'adresses. De plus, l'adresse de sous-réseau et l'adresse de diffusion doivent être exclues.
Ainsi, ci-dessous, vous trouverez un script qui résout cette tâche et crée 50 objets de type hôte et 51 objets de type plage d'adresses. La tâche nécessite 101 appels API (sans compter l'appel final publish). De plus, avec le module timeit, nous mesurons le temps d'exécution du script jusqu'à la publication des modifications.
Script utilisant add-host et add-address-range
import timeit
from cpapi import APIClient, APIClientArgs
start = timeit.default_timer()
first_ip = 1
last_ip = 4
client_args = APIClientArgs(server="192.168.47.240")
with APIClient(client_args) as client:
login = client.login_with_api_key('3TsbPJ8ZKjaJGvFyoFqHFA==')
for ip in range(5,255,5):
add_host = client.api_call("add-host", {"name" : f"h_192.168.0.{ip}", "ip-address": f'192.168.0.{ip}'})
while last_ip < 255:
add_range = client.api_call("add-address-range", {"name": f"r_192.168.0.{first_ip}-{last_ip}", "ip-address-first": f"192.168.0.{first_ip}", "ip-address-last": f"192.168.0.{last_ip}"})
first_ip+=5
last_ip+=5
stop = timeit.default_timer()
publish = client.api_call("publish")
print(f'Time to execute batch request: {stop - start} seconds')
Dans mon environnement de laboratoire, l'exécution de ce script prend de 30 à 50 secondes, selon la charge sur le serveur de gestion.
Voyons maintenant comment résoudre cette tâche avec un appel API. add-objects-batch, dont la prise en charge a été ajoutée dans la version API 1.6. Cet appel permet de créer plusieurs objets en une seule requête API. De plus, il peut s'agir d'objets de différents types (par exemple des hôtes, des sous-réseaux et des plages d'adresses). Ainsi, notre tâche peut être résolue dans le cadre d'un seul appel API.
Script utilisant add-objects-batch
import timeit
from cpapi import APIClient, APIClientArgs
start = timeit.default_timer()
client_args = APIClientArgs(server="192.168.47.240")
objects_list_ip = []
objects_list_range = []
for ip in range(5,255,5):
data = {"name": f'h_192.168.0.{ip}', "ip-address": f'192.168.0.{ip}'}
objects_list_ip.append(data)
first_ip = 1
last_ip = 4
while last_ip < 255:
data = {"name": f"r_192.168.0.{first_ip}-{last_ip}", "ip-address-first": f"192.168.0.{first_ip}", "ip-address-last": f"192.168.0.{last_ip}"}
objects_list_range.append(data)
first_ip+=5
last_ip+=5
data_for_batch = {
"objects" : [ {
"type" : "host",
"list" : objects_list_ip
}, {
"type" : "address-range",
"list" : objects_list_range
}]
}
with APIClient(client_args) as client:
login = client.login_with_api_key('3TsbPJ8ZKjaJGvFyoFqHFA==')
add_objects_batch = client.api_call("add-objects-batch", data_for_batch)
stop = timeit.default_timer()
publish = client.api_call("publish")
print(f'Time to execute batch request: {stop - start} seconds')
L'exécution de ce script dans mon environnement de laboratoire prend de 3 à 7 secondes, selon la charge sur le serveur de gestion. Ainsi, en moyenne, l'appel API de type batch fonctionne 10 fois plus vite pour 101 objets. Pour un plus grand nombre d'objets, la différence sera encore plus impressionnante.
Voyons maintenant comment travailler avec set-objects-batch. Grâce à cet appel API, nous pouvons modifier en masse n'importe quel paramètre. Configurons la première moitié des adresses de l'exemple précédent (jusqu'à .124 pour les hôtes, y compris les plages) avec la couleur sienna, et la seconde moitié des adresses avec la couleur khaki.
Modification de la couleur des objets créés dans l'exemple précédent.
from cpapi import APIClient, APIClientArgs
client_args = APIClientArgs(server="192.168.47.240")
objects_list_ip_first = []
objects_list_range_first = []
objects_list_ip_second = []
objects_list_range_second = []
for ip in range(5,125,5):
data = {"name": f'h_192.168.0.{ip}', "color": "sienna"}
objects_list_ip_first.append(data)
for ip in range(125,255,5):
data = {"name": f'h_192.168.0.{ip}', "color": "khaki"}
objects_list_ip_second.append(data)
first_ip = 1
last_ip = 4
while last_ip < 125:
data = {"name": f"r_192.168.0.{first_ip}-{last_ip}", "color": "sienna"}
objects_list_range_first.append(data)
first_ip+=5
last_ip+=5
while last_ip < 255:
data = {"name": f"r_192.168.0.{first_ip}-{last_ip}", "color": "khaki"}
objects_list_range_second.append(data)
first_ip+=5
last_ip+=5
data_for_batch_first = {
"objects" : [ {
"type" : "host",
"list" : objects_list_ip_first
}, {
"type" : "address-range",
"list" : objects_list_range_first
}]
}
data_for_batch_second = {
"objects" : [ {
"type" : "host",
"list" : objects_list_ip_second
}, {
"type" : "address-range",
"list" : objects_list_range_second
}]
}
with APIClient(client_args) as client:
login = client.login_with_api_key('3TsbPJ8ZKjaJGvFyoFqHFA==')
set_objects_batch_first = client.api_call("set-objects-batch", data_for_batch_first)
set_objects_batch_second = client.api_call("set-objects-batch", data_for_batch_second)
publish = client.api_call("publish")
Il est possible de supprimer de nombreux objets en un seul appel API en utilisant delete-objects-batch. Voyons maintenant un exemple de code qui supprime tous les hôtes créés précédemment via add-objects-batch.
La suppression d'objets à l'aide de delete-objects-batch
from cpapi import APIClient, APIClientArgs
client_args = APIClientArgs(server="192.168.47.240")
objects_list_ip = []
objects_list_range = []
for ip in range(5,255,5):
data = {"name": f'h_192.168.0.{ip}'}
objects_list_ip.append(data)
first_ip = 1
last_ip = 4
while last_ip < 255:
data = {"name": f"r_192.168.0.{first_ip}-{last_ip}"}
objects_list_range.append(data)
first_ip+=5
last_ip+=5
data_for_batch = {
"objects" : [ {
"type" : "host",
"list" : objects_list_ip
}, {
"type" : "address-range",
"list" : objects_list_range
}]
}
with APIClient(client_args) as client:
login = client.login_with_api_key('3TsbPJ8ZKjaJGvFyoFqHFA==')
delete_objects_batch = client.api_call("delete-objects-batch", data_for_batch)
publish = client.api_call("publish")
print(delete_objects_batch.data)
Toutes les fonctionnalités qui apparaissent dans les nouvelles versions du logiciel Check Point sont immédiatement accompagnées d'appels API. Ainsi, dans R80.40, des « fonctionnalités » telles que Revert to revision et Smart Task ont été introduites, et des appels API correspondants ont été préparés. De plus, toute la fonctionnalité lors de la transition des consoles Legacy au mode Unified Policy est également équipée de support API. Par exemple, la mise à jour tant attendue dans la version R80.40 a été le transfert de la politique d'inspection HTTPS du mode Legacy au mode Unified Policy, et cette fonctionnalité a immédiatement reçu des appels API. Voici un exemple de code qui ajoute en première position une règle à la politique d'inspection HTTPS excluant de l'inspection 3 catégories (Santé, Finances, Services gouvernementaux) qui ne peuvent être inspectées en vertu de la législation de plusieurs pays.
Ajouter une règle à la politique d'inspection HTTPS
from cpapi import APIClient, APIClientArgs
client_args = APIClientArgs(server="192.168.47.240")
data = {
"layer" : "Default Layer",
"position" : "top",
"name" : "Exigences légales",
"action": "bypass",
"site-category": ["Santé", "Gouvernement / Militaire", "Services financiers"]
}
with APIClient(client_args) as client:
login = client.login_with_api_key('3TsbPJ8ZKjaJGvFyoFqHFA==')
add_https_rule = client.api_call("add-https-rule", data)
publish = client.api_call("publish")
Exécution de scripts Python sur le serveur de gestion Check Point
Tout de même il contient des informations sur la façon d'exécuter des scripts Python directement à partir du serveur de gestion. Cela peut être pratique lorsque vous n'avez pas la possibilité de vous connecter au serveur API depuis une autre machine. J'ai enregistré une vidéo de six minutes où j'examine l'installation du module cpapi et les particularités d'exécution des scripts Python sur le serveur de gestion. En tant qu'exemple, un script est exécuté pour automatiser la configuration d'une nouvelle passerelle pour une tâche tels que l'audit réseau Vérification de sécurité. Parmi les particularités rencontrées : dans la version Python 2.7, la fonction input, n'est pas encore disponible, donc pour traiter les informations saisies par l'utilisateur, on utilise la fonction raw_input. Sinon, le code est le même que pour une exécution à partir d'autres machines, il est juste plus pratique d'utiliser la fonction login_as_root, pour ne pas avoir à saisir encore une fois votre propre nom d'utilisateur, mot de passe et adresse IP du serveur de gestion.
Script pour la configuration rapide de la vérification de sécurité
from __future__ import print_function
import getpass
import sys, os
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))
from cpapi import APIClient, APIClientArgs
def main():
with APIClient() as client:
# if client.check_fingerprint() is False:
# print("Impossible d'obtenir l'empreinte du serveur - Vérifiez la connectivité avec le serveur.")
# exit(1)
login_res = client.login_as_root()
if login_res.success is False:
print("Échec de la connexion:n{}".format(login_res.error_message))
exit(1)
gw_name = raw_input("Entrez le nom de la passerelle:")
gw_ip = raw_input("Entrez l'adresse IP de la passerelle:")
if sys.stdin.isatty():
sic = getpass.getpass("Entrez le mot de passe à usage unique pour la passerelle (SIC): ")
else:
print("Attention! Votre mot de passe s'affichera à l'écran!")
sic = raw_input("Entrez le mot de passe à usage unique pour la passerelle (SIC): ")
version = raw_input("Entrez la version de la passerelle (comme RXX.YY):")
add_gw = client.api_call("add-simple-gateway", {'name' : gw_name, 'ipv4-address' : gw_ip, 'one-time-password' : sic, 'version': version.capitalize(), 'application-control' : 'true', 'url-filtering' : 'true', 'ips' : 'true', 'anti-bot' : 'true', 'anti-virus' : 'true', 'threat-emulation' : 'true'})
if add_gw.success and add_gw.data['sic-state'] != "communicating":
print("La connexion sécurisée avec la passerelle n'a pas été établie!")
exit(1)
elif add_gw.success:
print("La passerelle a été ajoutée avec succès.")
gw_uid = add_gw.data['uid']
gw_name = add_gw.data['name']
else:
print("Échec de l'ajout de la passerelle - {}".format(add_gw.error_message))
exit(1)
change_policy = client.api_call("set-access-layer", {"name" : "Network", "applications-and-url-filtering": "true", "content-awareness": "true"})
if change_policy.success:
print("La politique a été changée avec succès")
else:
print("Échec du changement de la politique - {}".format(change_policy.error_message))
change_rule = client.api_call("set-access-rule", {"name" : "Règle de nettoyage", "layer" : "Network", "action": "Accept", "track": {"type": "Detailed Log", "accounting": "true"}})
if change_rule.success:
print("La règle de nettoyage a été changée avec succès")
else:
print("Échec du changement de la règle de nettoyage - {}".format(change_rule.error_message))
# publier le résultat
publish_res = client.api_call("publish", {})
if publish_res.success:
print("Les changements ont été publiés avec succès.")
else:
print("Échec de la publication des changements - {}".format(install_tp_policy.error_message))
install_access_policy = client.api_call("install-policy", {"policy-package" : "Standard", "access" : 'true', "threat-prevention" : 'false', "targets" : gw_uid})
if install_access_policy.success:
print("La politique d'accès a été installée")
else:
print("Échec de l'installation de la politique d'accès - {}".format(install_tp_policy.error_message))
install_tp_policy = client.api_call("install-policy", {"policy-package" : "Standard", "access" : 'false', "threat-prevention" : 'true', "targets" : gw_uid})
if install_tp_policy.success:
print("La politique de prévention des menaces a été installée")
else:
print("Échec de l'installation de la politique de prévention des menaces - {}".format(install_tp_policy.error_message))
# ajouter des mots de passe et phrases secrètes au dictionnaire
with open('additional_pass.conf') as f:
line_num = 0
for line in f:
line_num += 1
add_password_dictionary = client.api_call("run-script", {"script-name" : "Ajouter des mots de passe et des phrases secrètes", "script" : "printf "{}" >> $FWDIR/conf/additional_pass.conf".format(line), "targets" : gw_name})
if add_password_dictionary.success:
print("La ligne {} du dictionnaire de mots de passe a été ajoutée avec succès".format(line_num))
else:
print("Échec de l'ajout du dictionnaire - {}".format(add_password_dictionary.error_message))
main() Exemple de fichier avec un dictionnaire de mots de passe additional_pass.conf
{
"passwords" : ["maliciel","malveillant","infecté","Infecté"],
"phrases" : ["mot de passe","Mot de passe","Pass","pass","codigo","clé","pwd","пароль","Пароль","Ключ","ключ","шифр","Шифр"]
}
Conclusion
Cet article traite uniquement des fonctionnalités de base du travail Python SDK et du module cpapi(comme vous l'avez peut-être deviné, ce sont en fait des synonymes), et en étudiant le code de ce module, vous découvrirez encore plus de possibilités de travail avec lui. Il est possible que vous souhaitiez l'enrichir avec vos propres classes, fonctions, méthodes et variables. Vous pouvez toujours partager vos réalisations et consulter d'autres scripts pour Check Point dans la section de la communauté , qui réunit des développeurs de produits et des utilisateurs.
Bon code et merci d'avoir lu jusqu'à la fin !
Source : habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish