> Tech > Boite à outils System i News – Ajouter un service Internet de basculement

Boite à outils System i News – Ajouter un service Internet de basculement

Tech - Par System iNews - Publié le 23 janvier 2012
email

Toutes les réponses aux questions des administrateurs d'environnements IBM i. Au sommaire de cette édition : - Ajouter un service Internet de basculement - Utiliser des certificats sur i - Changer pour passer à SSL à partir d'Apache - Transférer du texte à partir d'un PC - Utiliser la commande INCLUDE 6.1 Ce dossier est issu de notre publication System iNews (03/11). Pour consulter les schémas et illustrations associés, rendez-vous dans le club abonnés.

Ajouter un service Internet de basculement

Q : Je suis néophyte en réseau IBM i et j’essaie de comprendre le routage Ethernet. Notre IBM i 520 a deux cartes d’interface (NIC, network interface card) : la première a une adresse IP 10.0.0.254 et ne sert que pour l’accès local. Un pare-feu est attaché au réseau 10.0.0.0 pour l’accès à Internet. La seconde NIC a un IP public de 65.xxx.xxx.xxx, pour se connecter à un pare-feu DMZ séparé pour l’accès externe à l’IBM i. Nous améliorons notre service Internet T1 existant par une ligne câble à haute vitesse supplémentaire, qui s’interconnectera au T1 à l’aide d’un Barracuda Link Balancer pour le basculement et la bande passante supplémentaire.

Pour que le Barracuda dirige les requêtes entrantes vers l’IBM i, nous devons traduire (par NAT, network address translation) l’adresse externe 65.xxx.xxx.xxx en l’IP interne 10.0.0.254. J’avais l’intention d’appliquer vary off à la seconde NIC et de la déconnecter du pare-feu DMZ, puis de connecter la première NIC directement au pare-feu 10.0.0.0. À l’heure actuelle, je vois la passerelle de *DFTROUTE prête à utiliser la passerelle du T1 précédemment connecté sur la seconde NIC. Puis-je changer la *DFTROUTE pour utiliser le pare-feu 10.0.0.0 comme sa nouvelle passerelle ? A l’intérieur de ce pare-feu, je pourrais ensuite traduire (NAT) 65.xxx.xxx.xxx en 10.0.0.254.

R : En principe, votre pare-feu NAT (celui qui est connecté à 10.0.0.0) serait votre routeur par défaut. Vous devez supprimer votre route par défaut actuelle puis en créer une nouvelle qui pointe vers la passerelle NAT. Faute d’une route par défaut accessible sur l’une des NIC actives (dont vous n’avez qu’un exemplaire dans votre nouvelle configuration), votre IBM i ne tiendra aucun compte des paquets destinés aux adresses non locales.

— Scott Klement et Mel Beckman

Utiliser des certificats sur i

Q : Nous utilisons un FTPS (FTP over SSL) client sur un serveur IBM i pour échanger des transactions avec notre banque. Nous avons obtenu le certificat SSL qu’elle exige (émis par VeriSign), l’avons installé sur un PC, exporté et copié dans un dossier IFS.

Il m’incombe maintenant de mettre FTPS en action. J’ai trouvé comment entrer dans DCM et où aller pour importer le certificat dans le store *SYSTEM, mais j’obtiens sans cesse l’erreur An error occurred during certificate validation. The issuer of the certificate may not be in the certificate store or the issuer may not be enabled. (Une erreur s’est produite pendant la validation du certificat. L’émetteur du certificat n’est peut-être pas dans le référentiel des certificats ou n’est peut-être pas validé).

Toutes les Certificate Authorities (CA) sont activées et j’ai validé toutes les CA VeriSign de la liste. Il m’a semblé voir mentionner PKCS #12 pendant mes recherches, mais cette option n’est pas disponible quand on exporte les clés à partir de IE. DER, Base-64, et PKCS #7 sont les seuls types de certificats que FTPS accepte. J’ai essayé les trois, mais j’obtiens invariablement le même message. Que fais-je de mal ?

R : Il faut probablement charger une racine manquante ou un certificat de CA intermédiaire qui est dans la chaîne des certificats. Appliquez SSL à une chaîne complète de CA approuvées (trusted) pour valider l’authenticité d’un certificat. Par exemple, je pourrais créer un certificat qui déclare que je suis Citibank. Vous pourriez vous connecter à mon site personnel, lequel vous dirait que je suis réellement Citibank et vous devriez me croire sur parole. Qu’est-ce qui prouve ma bonne foi ?

La réponse est la CA. Bien que je prétende être Citibank, je ne pourrais jamais avoir l’aval de VeriSign ou Thawte (ou de toute autre CA). Cet aval (vouching) a lieu pendant le handshake SSL, c’est-à-dire le moment où chaque côté valide les certificats de l’autre avec la CA revendiquée. Je ne peux pas vous faire croire que je suis Citibank parce que SSL prend la peine de vérifier mon certificat SSL par rapport à la CA de l’enregistrement.

Chaque système utilisant SSL possède plusieurs certificats CA. Quand vous recevez un certificat d’un autre ordinateur, la signature numérique est vérifiée cryptographiquement par rapport aux certificats CA qui sont déjà en cache dans la machine. Cela confirme ou infirme (cryptographiquement, d’une manière jugée impossible à falsifier) si mon certificat a vraiment été signé par la CA. Si les signatures d’une CA approuvée correspondent à celles qui sont revendiquées par le certificat SSL d’un serveur (tel que l’un de VeriSign), alors l’identité du serveur est confirmée.

Les certificats sont hiérarchiques. Une société comme VeriSign aura un certificat maître (ou racine) installé dans des navigateurs, des gestionnaires de certificats, et d’autres environnements SSL. Ce certificat CA racine certifie que tout ce qu’ils ont signé provient vraiment de chez eux. Cependant, comme il ne lui est pas facile de signer directement chaque certificat avec son certificat maître unique, Verisign émet des certificats intermédiaires.

Les certificats intermédiaires, du fait qu’ils sont signés par le certificat racine Verisign, jouissent du même niveau de confiance que le certificat racine. En d’autres termes, les certificats intermédiaires établissent une chaîne d’approbation ou de confiance. Le certificat client (le vôtre) est signé par l’intermédiaire. Vous pouvez encore approuver votre certificat—vous pouvez encore valider qu’il est signé par VeriSign—mais pour que l’ordinateur à distance puisse faire cette vérification, il doit télécharger à la fois votre certificat et les éventuels certificats intermédiaires. Quand il aura eu la preuve que votre certificat a été signé par l’intermédiaire et que celui-ci a été signé par la racine, il saura que les certificats sont valides.
Par conséquent, via votre Digital Certificate Manager, vous devez installer le certificat intermédiaire et le certificat client. Quant au certificat racine, s’il n’est pas en place, installez-le aussi.

— Scott Klement

Changer pour passer à SSL à partir d’Apache

Q : J’étudie la possibilité de changer notre serveur Apache pour utiliser SSL. D’où les deux questions suivantes : SSL réduira-t-il sensiblement les performances ? Une instance Apache peut-elle gérer à la fois HTTP et HTTPS pendant une période de transition ?

R : Oui, vous pouvez avoir en même temps SSL et des connexions normales avec le même serveur, et ce, de manière permanente. Il n’y a aucune raison particulière de les séparer, autre que les performances.

En premier lieu, configurez le serveur *ADMIN pour qu’il prenne en charge SSL. Ensuite, créez et installez les nouveaux certificats, y compris ceux pour d’éventuels serveurs HTTP virtuels. Les connexions initiales seront un peu plus lentes en raison du handshaking SSL, mais je n’ai pas constaté de différences majeures dans les temps de réponse (ce point pourrait varier face à des débits de transactions HTTPS très élevés).

Toutefois, vous ne pouvez pas attribuer un certificat séparé pour chaque hôte virtuel basé sur le nom. Tout simplement, parce que la partie SSL de la conversation est établie avant que le client envoie le nom au serveur dans l’en-tête HTTP. Donc, si le serveur a plus d’un nom pour la même adresse IP, il ne peut connaître le nom qui a été demandé qu’une fois que SSL a été établi, et il est donc impossible d’avoir un certificat différent pour chaque hôte virtuel.

Les hôtes virtuels basés sur l’adresse ou le port n’ont pas ce problème. Apache sait quelle adresse IP et/ou quel port a été utilisé avant que SSL soit établi, et par conséquent peut potentiellement utiliser un certificat différent pour chacun.

— Chris H. et Scott Klement

Transférer du texte à partir d’un PC

Q : J’essaie de transférer par FTP un fichier d’un PC sur l’IBM i. J’ai un tableur avec une seule colonne de données et presque 800 enregistrements. J’ai activé le transfert binaire puis je l’ai sauvegardé sous le type .txt, délimité par des tabulations. Quand je l’envoie par FTP à l’IBM i, je peux utiliser Runqry pour la virtualisation des données, mais si je copie le fichier dans un fichier physique, un message d’erreur m’indique que le fichier contient des données invalides. Est-ce que quelque chose m’échappe ?

R : Votre problème réside dans la méthode de transfert binaire. Vous voulez que l’IBM I convertisse le jeu de caractères de votre PC en un jeu intelligible par votre iSeries. Essayez donc avec ASCII.

Et oui, vous pouvez envoyer par FTP directement dans un fichier physique. Cependant, comme le jeu de caractères natifs pour les PF est EBCIC, votre fichier ne sera pas lisible par des utilitaires ou programmes IBM i natifs.

— Dan D.

Utiliser la commande INCLUDE 6.1

La commande CL (Control Language) INCLUDE est nouvelle dans l’i/OS 6.1. Elle nous permet enfin d’avoir CL CopyBooks pour des programmes OPM et ILE CL. INCLUDE est l’équivalent basique de l’instruction RPG et COBOL /COPY.

La commande INCLUDE est utilisée dans un membre source CLP ou CLLE pour indiquer le membre du code source qui sera copié (c’est-à-dire INCLUDED). Le format de la commande est INCLUDE SRCMBR(MYCOPY1) SRCFILE(*INCFILE)

Le paramètre SRCMBR indique le nom du membre source qui sera inclus (copié) à cet endroit pendant l’opération de compilation. Le paramètre SRCFILE vous permet de préciser que le membre Included réside dans le fichier source *DEFAULT (*INCFILE). Vous pouvez aussi spécifier un fichier source différent comme référentiel des membres source Included, comme dans l’exemple suivant :

INCLUDE SRCMBR(MYCOPY1) SRCFILE(MYLIB/INCLUDES)

Voici un exemple de deux membres source INCLUDE qui peuvent être utilisés pour traiter des messages standard :

Source member CPY_ERR

DCL    VAR(&MSGID)   TYPE(*CHAR) LEN(7)
DCL    VAR(&MSGF)    TYPE(*CHAR) LEN(10)
DCL    VAR(&MSGFLIB) TYPE(*CHAR) LEN(10)
DCL    VAR(&MSGDTA)  TYPE(*CHAR) LEN(512)
MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(ERROR))

Le premier membre du code source CPY_ERR, inclut les commandes DCL et la commande Global MONMSG. Les commandes DCL déclarent les variables nécessaires pour la routine de traitement d’erreur incluse dans le membre source CPY_ERR2, présenté ici.

Source Member CPY_ERR2

ERROR:      RCVMSG     MSGTYPE(*LAST) MSGDTA(&MSGDTA) MSGID(&MSGID) +
MSGF(&MSGF) SNDMSGFLIB(&MSGFLIB)
MONMSG     MSGID(CPF0000) /* Just in Case */
SNDPGMMSG  MSGID(&MSGID) MSGF(&MSGFLIB/&MSGF) +
MSGDTA(&MSGDTA) MSGTYPE(*ESCAPE)
MONMSG     MSGID(CPF0000) /* Just in Case */

Le membre source suivant est le code programme CL fini nommé TEST_ERR, en utilisant les commandes INCLUDE à l’endroit approprié :

Source member TEST_ERR

PGM
INCLUDE    SRCMBR(CPY_ERR)
CHKOBJ     OBJ(XXXX) OBJTYPE(*FILE)
RETURN     /* Normal end of Program */
INCLUDE    SRCMBR(CPY_ERR2)
ENDPGM

Le membre Source TEST_ERR se trouve dans le fichier source QCLSRC dans la bibliothèque MYLIB. Ce fichier source est le fichier source *DEFAULT utilisé quand le nom Source File n’est pas spécifié sur la commande INCLUDE. Dans ce cas, les membres source INCLUDE se trouvent aussi dans le fichier source QCLSRC, dans la bibliothèque MYLIB.

Quand le code source TEST_ERR est compilé, les éventuelles commandes INCLUDE font que le code source provenant de ces membres included est copié dans le code source d’entrée du compilateur, comme on le voit dans le listing du compilateur de la figure 1.

Vous pouvez voir que le compilateur étend la commande INCLUDE pour spécifier le nom du fichier Source, qui n’était PAS spécifié dans le code source TEST_ERR. La commande INCLUDE est remplacée par deux commentaires montrant la commande étendue et délimitant le code source INCLUDE, et le code source INCLUDE est glissé entre les commentaires.

Les compilateurs CLP et CLLE ont un nouveau paramètre INCFILE, qui indique le fichier source *DEFAULT utilisé dans l’opération de compilation. Quand *SRCFILE est spécifié, comme dans l’exemple suivant, le fichier source *DEFAULT pour les commandes INCLUDE sera le fichier source spécifié par le paramètre SRCFILE. Ici c’est MYLIB/QCLSRC.

Voici quelques exemples d’utilisation du nouveau paramètre du compilateur INCFILE (Include Source File) :

CRTCLPGM PGM(MYLIB/TEST_ERR) SRCFILE(MYLIB/QCLSRC) SRCMBR(TEST_ERR) INCFILE(*SRCFILE)

CRTBNDCL PGM(MYLIB/TEST_ERR) SRCFILE(MYLIB/QCLSRC) SRCMBR(TEST_ERR) INCFILE(*SRCFILE)

Profitez de cette nouvelle manière de créer et d’utiliser Control Language CopyBooks !

—Dan Riehl

Téléchargez cette ressource

Comment lutter contre le Phishing ?

Comment lutter contre le Phishing ?

Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.

Tech - Par System iNews - Publié le 23 janvier 2012