News iSeries – Semaine 11 – 2006
Toutes les actualités de la semaine du 13 au 19 Mars 2006
Lire l'article
Régler finement Windows Firewall
par Mark Minasi - Mis en ligne le 22/02/06 - Publié en Octobre 2004
Dans l’article « Windows Firewall » (septembre 2004), je présente Windows Firewall, une fonction Windows XP SP2 (Service Pack 2), appelée ICF (Internet Connection Firewall) dans sa précédente incarnation. Dans cet article, j’approfondis la fonction et montre comment la régler finement en fonction des besoins de votre réseau.Examinons les neuf nouveaux paramètres de Stratégies de Groupe pour Windows Firewall et leurs commandes correspondantes. Vous trouverez les paramètres de Windows Firewall dans le dossier Computer Configuration\Administrative Templates\Network\Network Connections\Internet Connection Firewall. Ce dossier contient deux sous-dossiers : Domain Profile et Mobile Profile. Un ordinateur sur lequel Windows Firewall est installé choisit les paramètres de stratégie pour Domain Profile au moment où cet ordinateur est connecté à un domaine ; sinon, il choisit les paramètres pour Mobile Profile. Les deux sous-dossiers contiennent les neuf mêmes paramètres de stratégie.
J’ai montré le premier paramètre, Operational Mode, le mois dernier. Il propose trois options : Disabled qui désactive le pare-feu, Protected qui active le pare-feu, et Shielded qui active aussi le pare-feu mais isole l’ordinateur du réseau davantage que Protected ; en effet ce dernier permet d’ouvrir des ports particuliers. Pour appliquer au pare-feu le mode Disabled, Protected ou Shielded, utilisez la commande
netsh firewall ipv4 set opmode
suivie de l’un des trois termes disabled, enabled ou shield. (Les commandes de la ligne de commande décrivent souvent les options avec des termes légèrement différents de ceux des paramètres de Stratégie de Groupe.) Donc, pour lever le pont-levis et pour blinder votre NIC, vous taperiez
netsh firewall ipv4 set opmode shield
Cette commande a toute sa place dans un fichier batch. Vous pourriez ensuite créer sur votre poste un raccourci vers un fichier batch, appeler le raccourci Shield this System puis faire un double clic dessus chaque fois que votre réseau sera attaqué. Pour connaître la configuration du pare-feu, vous pouvez utiliser la commande
netsh firewall ipv4 show opmode
News iSeries – Semaine 5 – 2006
Toutes les actualités de la semaine du 30 janvier au 5 Février 2006
Lire l'article
Compilation conditionnelle en RPG
par Julian Monypenny Mis en ligne le 17/01/2006 - Publié en Mai 2005
Aimeriez-vous
• désactiver le code sans le retirer d’un programme ?
• permuter entre plusieurs versions d’une procédure pendant le développement?
• compiler les fonctions du langage pour différentes releases cibles ?
• basculer sur les traces de données pendant le test ?
• utiliser des définitions centrales des types de données et des prototypes de procédures ?
Si vous avez répondu oui à une ou plusieurs des questions ci-dessus, il vous faut la compilation conditionnelle. C’est pourquoi je l’explique ici et montre comment l’utiliser pour résoudre ces problèmes.
Les OS/400 Host Servers à la loupe
par Michael Otey - Mis en ligne le 07/12/2005 - Publié en Avril 2005
Les composants iSeries qui valident iSeries Access ainsi que beaucoup d’autres produits de connectivité tiers, sont les OS/400 Host Servers. Ils prennent en charge l’émulation 5250, le transfert de fichiers et l’accès aux files d’attente de données, ainsi que les applications Web, les applications Java et beaucoup de produits de connectivité tiers. Cet article examine dans le détail les programmes serveur OS/400 qui offrent la fonctionnalité d’arrière plan d’iSeries Access.
Un jour dans la vie d’un programmeur JAVA IFS
par Don Denoncourt, Mis en ligne le 11/04/2006 - Publié en Novembre 2005
Installer Tomcat 5.5 et créer un dispositif de déploiement à chaud, le tout dans une journée de travail
Analyse des relais Exchange
par Joseph Neubauer - Mis en ligne le 29/03/06 - Publié en Mars 2005
De plus en plus d’organisations mettent en place des stratégies qui requièrent des évaluations de la sécurité et des vulnérabilités au niveau des serveurs et systèmes avant leur déploiement sur le réseau. Nombre de ces stratégies nécessitent des outils d’audit afin de rechercher des exploitations de vulnérabilité sur les serveurs, de confirmer les versions de correctifs, de fournir des conseils de verrouillage de la sécurité, etc. Pour les serveurs Exchange Server 2003 et Exchange 2000 Server, l’une des vulnérabilités à prendre très au sérieux et la notion de « relais ouvert ».Qu’est-ce qu’un relais ouvert ? Une fonctionnalité de SMTP permet à un serveur de faire office d’intermédiaire et d’accepter des messages pour le compte de la destination finale. Ce serveur retransmet (ou relaie) ensuite les messages vers la destination en question. Dans Exchange, vous pouvez configurer les serveurs de telle sorte que certains ordinateurs et utilisateurs puissent relayer le courrier. Toutefois, lorsque des problèmes de configuration surviennent et que tout un chacun peut utiliser le système pour relayer du courrier, on parle de relais ouvert. Cette situation est dangereuse pour au moins deux raisons : premièrement, SMTP est intrinsèquement non sécurisé, ce qui permet d’usurper ou de contrefaire facilement l’identité de l’expéditeur dans un message. Récemment, la prolifération de virus tels que Bagel a montré comment la contrefaçon de l’identité de l’expéditeur peut être source de confusion et accroître la charge de travail. Un relais ouvert amplifie le problème car un message contrefait ajoute un certain niveau d’authenticité. En effet, le message semble provenir d’un serveur du domaine de l’expéditeur spécifié.
Deuxièmement, les spammeurs se servent fréquemment des relais ouverts pour propager leur charge utile. Dans ce type de situation, les ressources de votre serveur sont détournées du traitement du trafic de messagerie de votre organisation. Outre le détournement des ressources et la gêne occasionnée dans la remise des courriers, ce phénomène risque d’entraîner des pertes d’activité sur le long terme. L’utilisation de logiciels antispam et de listes noires telles que MAPS (http://www.mailabuse.com) peut aboutir au rejet de tous les courriers légitimes de votre domaine, du fait de sa réputation de relais ouvert. Un relais ouvert peut entraver la capacité commerciale de votre organisation et ternir son image de marque.
Si les relais ouverts constituent une telle menace, pourquoi faire en sorte que vos serveurs relaient le courrier ? En règle générale, vous autorisez la fonction de relais lorsqu’une application doit envoyer du courrier SMTP mais que vous n’avez pas la possibilité de déterminer le moyen de transmettre le message à sa destination. Vous configurez l’application afin de transférer le message directement à votre serveur relais, et ce dernier utilise le routage SMTP pour remettre le message à ses destinataires. Les clients POP et MAP constituent des exemples de ces types d’applications. C’est également le cas d’un formulaire de serveur Web qui envoie des configurations d’e-mail lors du téléchargement d’informations. Dans certaines situations, notamment la conception d’une application de serveur Web, vous pourriez développer l’application de telle sorte qu’elle utilise plutôt MAPI (Messaging API) au lieu de SMPT, éliminant ainsi le besoin de relais. Mais la tendance est plutôt à l’utilisation de protocoles standard (par ex., SMPT) et non à leur mise à l’écart.
Dans le cas de POP et d’IMAP, le relais est nécessaire car ces deux protocoles ne sont pas prévus pour envoyer des courriers, mais plutôt pour les récupérer des boîtes aux lettres. Pour envoyer des courriers, les protocoles POP et IMAP doivent être couplés à SMTP et le client doit être configuré avec le nom d’un serveur autorisant la fonction de relais. La prise en charge du relais pour ces applications ne signifie pas que votre serveur deviendra obligatoirement
Réactiver facilement les utilisateurs NetServer désactivés
par Chuck Lundgren, Mis en ligne le 15/O3/2006 - Publié en Septembre 2005
L’iSeries NetServer permet aux utilisateurs de PC d’associer un lecteur ou une imprimante à l’iSeries. Très utile, cette fonction pose cependant quelques difficultés aux administrateurs système, qui doivent se préoccuper de la propagation des virus PC via les shares iSeries, des pépins de connectivité et des problèmes de performances. Il est fréquent que des utilisateurs trouvent leur accès désactivé à cause de mots de passe modifiés, de mots de passe incorrects et autres. L’administrateur système doit alors intervenir pour remettre dans le jeu les utilisateurs NetServer désactivés.IBM propose quelques moyens (certains plus commodes que d’autres) pour obtenir la liste des utilisateurs NetServer désactivés. Le procédé le moins commode consiste à rechercher le message CPIB682 – le message d’alerte signalant un utilisateur NetServer désactivé. Vous utilisez la commande WRKSPLF (Work with Spooled Files) :
WRKSPLF QSYSOPR
Vous pourriez aussi utiliser la commande DSPLOG (Display Log):
DSPLOG MSGID(CPIB682)
Quand vous repérez un utilisateur NetServer désactivé dans les journaux, vous pouvez émettre la commande CHGUSRPRF (Change User Profile) :
CHGUSRPRF profile-name
où profile-name est le nom de l’utilisateur NetServer désactivé. Il n’est pas nécessaire de changer le profil parce que le simple fait d’exécuter la commande réactive l’accès à NetServer.
Pour lister les utilisateurs NetServer désactivés, iSeries Navigator propose une méthode plus commode. Dans iSeries Navigator, cliquez sur My Connections|Network |Servers|TCP/IP puis double cliquez sur le noeud iSeries NetServer. Ensuite, faites un clic droit sur iSeries NetServer et sélectionnez l’option pour les ID utilisateur désactivés, pour voir la liste des utilisateurs NetServer désactivés. Il est ensuite très facile de réactiver les utilisateurs dans cette fenêtre.
Il existe une alternative écran passif à la méthode iSeries Navigator : elle consiste à utiliser le menu NETS dans la bibliothèque QUSRTOOL. Après avoir entré GO NETS sur la ligne de commande, sélectionnez Work with NetServer Users dans le menu, pour afficher la liste de tous les utilisateurs NetServer désactivés. Pour réactiver les profils affichés, appuyez sur F7.
L’utilitaire Activate NetServer User (ActNetUsr) de cet article offre une autre méthode écran passif pour réactiver les utilisateurs NetServer. Il a pour autre avantage de montrer comment mettre en oeuvre les API QZLSOLST (Open List of Server Information) et QZLSCHSI (Changer Server Information) qui permettent d’extraire des informations serveur et de les modifier.
L’utilitaire ActNetUsr (qui n’a pas de paramètres) s’exécute dans l’ordre suivant :
- Premièrement, il utilise l’API QZLSOLST pour extraire une liste des utilisateurs NetServer désactivés.
- Pour chaque utilisateur extrait, le programme envoie le message d’interrogation suivant au job actif exécutant
ActNetUsr :
NetServer user user-name disabled.
Enable SetServer user (Y=Yes)?
- Si Y est spécifié, le programme appelle l’API QZLSCHSI pour activer l’utilisateur NetServer spécifié.
- Une fois tous les utilisateurs traités, le programme envoie un message de bonne fin :
NetServer user activation completed.
A noter que l’API QZLSOLST fournit beaucoup plus d’informations sur le serveur que cet utilitaire n’en utilise : share, configuration, session, statistiques, connexion et autres. L’API QZLSCHSI vous permet de changer beaucoup moins d’informations que l’API QZLSOLST n’en affiche. Le changement de certaines Lire l'article
Maîtriser les stratégies de groupe
par Kathy Ivens - Mis en ligne le 22/02/06 - Publié en Octobre 2004
L’administration d’un environnement Windows est une tâche ardue. Des fonctions comme les stratégies de groupe, qui permettent aux administrateurs de contrôler les clients d’un domaine (ordinateurs et utilisateurs), sont fort utiles. Mais nombreux sont les administrateurs qui n’appliquent les stratégies de sécurité qu’après que certains événements les y obligent. Exemple d’un tel événement : un utilisateur qui bouleverse complètement la configuration de l’ordinateur ou qui modifie un paramètre en entraînant des problèmes pour l’ensemble du domaine.Quand un administrateur applique des stratégies au coup par coup, il s’en suit souvent un magma de nombreuses stratégies. Un trop grand nombre de stratégies peut augmenter le temps de connexion des machines client, au grand dam des utilisateurs. Cela peut aussi entraîner des conflits de stratégie présentant une double inconvénient : certains utilisateurs ne peuvent pas effectuer correctement leur travail et d’autres peuvent effectuer, à tort, des tâches qui affectent le domaine. On établit alors à la hâte une stratégie de plus pour corriger l’erreur, ce qui ne fait qu’aggraver la situation.
On peut bien entendu établir des stratégies de manière parfaitement ordonnée. En anticipant et en faisant le nécessaire pour réduire le nombre de stratégies nécessaires, vous pouvez éviter beaucoup des pièges qui guettent les administrateurs dans l’application des stratégies.
Trucs & Astuces : La commande Netsh
Les trucs & astuces de la semaine du 30 janvier au 5 février 2006
Lire l'article
News iSeries – Semaine 2 – 2006
Toutes les actualités de la semaine du 9 au 15 Janvier 2006
Lire l'article
Les services Web peuvent-ils vous servir?
par Aaron Bartell - Mis en ligne le 07/12/2005 - Publié en Mars 2005
Vous vous demandez peut-être
« Pourquoi parle-t-on autant des
services Web dans le monde de la
technologie ? Après tout, il y a belle
lurette que nous faisons du développement
orienté service modulaire et
que nous nous connectons à
d'autres systèmes distants. Il y a tellement
de moyens différents de
communiquer avec l'iSeries (DDM,
DRDA, FTP, ODBC, JDBC, « raw sockets
»). Devons-nous vraiment nous
encombrer d'une technologie de
plus ? Pourquoi ne pas simplement
adopter l'une des méthodes de communication
existantes et continuer à
progresser ? Pourquoi les services
Web ? Pourquoi maintenant ? Pourquoi
toutes ces nouvelles technologies
et nouveaux standards déroutants
? »
Protection de l’IFS contre les virus
par Phil Coulthard, Mis en ligne le 12/04/2006 - Publié en Novembre 2005
Pendant longtemps, les utilisateurs iSeries ont fait confiance à i5/OS pour repousser les virus, les chevaux de Troie et autres vers, qui assaillent les systèmes Microsoft Windows. Et cela, en grande partie grâce à l’architecture d’authentification basée sur la capacité i5/OS. Bien que cette architecture soit très « mature » (ses origines remontent au S/38 dans les années 1970) et présente parfois quelques faiblesses (que l’IBM traite rapidement), aucun virus n’est jamais parvenu à infecter un programme ou objet natif iSeries.En i5/OS, un objet fichier ne peut pas imiter un programme exécutable et un programme ne peut pas modifier le code binaire d’un autre : une fois créé, un programme est immuable. De plus, les programmes ne peuvent accéder aux objets que par des interfaces sûres et bien définies, et pas directement par l’intermédiaire d’une adresse mémoire ou disque. En matière d’objets natifs, i5/OS rend inopérantes les techniques habituelles des auteurs de virus.
Dans ce propos, le terme vedette est l’adjectif « natif ». La robuste sécurité objet de l’iSeries ne s’étend pas jusqu’aux portions de l’IFS (integrated file system) – particulièrement les portions présentes dans les répertoires racine accessibles à distance par des postes de travail et des serveurs Windows porteurs de virus. Quand un système distant accède à l’IFS, il a le pouvoir d’infecter les fichiers IFS avec un code viral. Les systèmes non infectés qui liront ultérieurement les fichiers infectés pourront eux-mêmes être contaminés. Un virus peut ainsi se répandre dans un réseau d’entreprise en quelques minutes, causant des dégâts incalculables.
Jusqu’à la V5R3, la seule protection antivirus pour l’IFS était constituée de packages antivirus de type PC qui scrutaient la racine IFS à distance, en la traitant simplement comme un autre lecteur disque de PC. Malheureusement, pour pouvoir faire cela, le PC chargé du scanning doit posséder tous les droits objet sur l’IFS : un gros risque pour la sécurité. Le scanning proprement dit doit lire tout le contenu de l’IFS initialement, avec pour résultat de gros volumes de trafic réseau. Et, bien que les scans suivants puissent être limités aux seuls fichiers modifiés depuis le dernier scan, rien ne garantit qu’une infection ne surviendra pas et ne se répandra pas entre les scans.
Avec la V5R3, IBM fait bénéficier i5/OS de la puissance du scanning de virus natif. Moyennant de nouveaux attributs de répertoire et de fichier, valeurs système et programmes de sortie, l’iSeries fournit désormais des points de connexion pour les programmes antivirus tiers qui assurent la protection en temps réel de l’IFS, éliminant le risque d’infection entre des scans. Et comme la protection antivirus est native, elle ne gonfle pas le trafic sur le réseau. Mieux encore, les extensions antivirus i5/OS sont à la disposition de tous : développeurs antivirus commerciaux et non commerciaux. Il sera donc possible de porter un scanner antivirus open-source sur l’iSeries.
Il faut noter que la validation du scanning de virus V5R3 n’inclut pas le logiciel de scanning de virus et de réparation proprement dit. Il faut l’obtenir auprès d’un fournisseur tiers ou écrire le vôtre. Il existe un produit commercial disponible dès à présent – livré, en fait, dans le cadre de la V5R3 – qui permet de bénéficier immédiatement de la protection antivirus natif : StandGuard AV for V5R3 de Bytware. Il est fort probable que d’autres produits antivirus apparaîtront à l’avenir. Pour bien évaluer de tels produits, ou peut-être pour écrire le vôtre, vous devez comprendre les mécanismes de scan de virus de la V5R3.
Heureusement, les améliorations sont simples et vous les assimilerez rapidement. Il y a deux nouveaux attributs de fichier/répertoire, deux nouvelles valeurs système, et deux nouveaux points de sortie de programme. Quand vous
Sauvegarder et restaurer une base Exchange
par Pascal Creusot - Mis en ligne le 29/03/06 - Publié en Mars 2005
La messagerie est devenu au fil du temps un outil capital pour ne pas dire indispensable pour la vie de toutes les entreprises. De nombreux collaborateurs stockent leurs données au sein de la messagerie, et les messages échangés peuvent représenter des affaires ou des transactions pouvant atteindre des sommes importantes. Dans ce contexte, la sauvegarde et la restauration des données de la messagerie représentent donc un enjeu important pour les entreprises.
Impression
par Dan Riehl, Mis en ligne le 15/O3/2006 - Publié en Septembre 2005
PAA (Program Adoption of Authority) est une technique qui permet d’élever temporairement les autorités de certains utilisateurs pour leur permettre des actions normalement interdites par leur autorité naturelle. Par exemple, supposons que vous vouliez que les gens du help desk puissent redéfinir le mot de passe de l’utilisateur. C’est une fonction sensible pour laquelle le personnel du help desk a besoin de niveaux d’autorité supérieurs (*ALLOBJ, *SECADM, par exemple). Mais si vous octroyez ces hauts niveaux d’autorité aux profils utilisateur des servants du help desk, ils pourront en permanence toucher à vos données sensibles, une situation pour le moins dangereuse.Il faut dans ce cas un petit programme aux fonctions limitées permettant à de tels utilisateurs d’adopter la puissante autorité dont ils ont besoin pour réinitialiser le mot de passe. Dès que le programme adoptant se termine, le haut niveau d’autorité disparaît. C’est exactement ce qu’accomplit PAA.
PAA est une fonction utile que vous auriez tort d’ignorer. Tout en sachant que, dans de mauvaises mains, PAA peut servir de porte dérobée pour obtenir de hauts niveaux d’autorité sans la supervision et le contrôle appropriés.
Lors de mes évaluations des vulnérabilités sur OS/400, j’ai souvent constaté qu’un programme adoptant un haut niveau d’autorité avait été subrepticement créé sur le système et utilisé comme méthode d’infiltration d’un système de sécurité par ailleurs bien conçu. Grâce à l’un de ces programmes adoptants, un utilisateur avisé peut facilement s’octroyer l’autorité d’un utilisateur puissant, comme QSECOFR, et devenir virtuellement QSECOFR chaque fois qu’il le désire.
News iSeries – Semaine 7 – 2006
Toutes les actualités de la semaine du 13 au 19 Février 2006
Lire l'article
La programmation CGI et l’iSeries
par Bradley V. Stone Mis en ligne le 31/01/2006 - Publié en Juin 2005
Voilà plusieurs années déjà que la programmation CGI (Common Gateway Interface) se pratique sur l’iSeries. Depuis au moins la V3R2, IBM fournit des API grâce auxquelles les programmeurs peuvent créer des pages Web entièrement fonctionnelles, sans recourir à des solutions coûteuses et exigeantes en ressources.
Aujourd’hui plus que jamais, les entreprises recherchent le meilleur moyen de proposer des applications Web interactives à leurs clients et utilisateurs. Le choix est vaste, le marketing vante certains produits, et il s’en suit que la plupart des sites passent souvent à côté de la meilleure solution.
En utilisant les API déjà disponibles sur l’iSeries, directement ou par l’intermédiaire d’un utilitaire tierce partie, les programmeurs iSeries s’aperçoivent que la technologie la mieux adaptée à leur cas est précisément celle qu’IBM songe à supprimer.
Trucs & Astuces : iSeries Access for Windows
Les trucs & astuces de la semaine du 9 au 15 Janvier 2006
Lire l'article
Publication de SQL Server dans Active Directory
par Chad Miller - Mis en ligne le 07/12/2005 - Publié en Décembre 2004
Vous avez peut-être remarqué la présence de l'onglet Active Directory dans la boîte
de dialogue SQL Server Properties de la console Enterprise Manager et vous vous
être peut-être interrogé sur le rapport existant entre Active Directory (AD) et SQL
Server ainsi que sur l'avantage d'ajouter SQL Server avec ses bases de données à
AD. Les services réseau tels que les serveurs de fichiers et d'impression se servent
d'Active Directory pour publier et stocker des informations relatives aux ressources
qu'ils proposent. Celui-ci contient une liste des comptes utilisateur et un annuaire
des ressources réseau disponibles.
Conseils et astuces pour PDM et SEU
par Jef Sutherland, Mis en ligne le 05/04/2006 - Publié en Octobre 2005
Même après plusieurs années d’utilisation d’une application, celle-ci recèle peut-être des fonctions inutilisées et susceptibles de l’améliorer. J’imagine que les développeurs compétents en PDM et SEU ont trouvé la plupart de ces fonctions cachées. Si vous n’avez pas encore confié votre développement à WDSc (WebSphere Development Studio Client), le moment est peut-être venu d’explorer quelques trésors cachés de PDM et de SEU. Examinons donc quelques astuces et techniques qui réjouiront même les programmeurs les plus chevronnés.
