Full Circle Magazine FR

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
**So, last time I talked about user accounts and how to keep them secure in the age of the General Data Protection Regulation (GDPR). After four years of preparation and debate, the GDPR was finally approved by the EU Parliament on 14 April 2016. It was enforced on 25 May 2018, and organisations that are not compliant could now face heavy fines.

GDPR is supposed to be about consumer trust. How can your customers - and I use the word customers in a very broad sense - trust you, if you can not even secure your network? The company behind knuddels.de, a chat site, is Germany's first to be fined, so the GDPR is to be taken seriously. Let us move to the N in P.A.N.S. (or S.N.A.P) which is networking, ie. networks and network services. This is our second last pillar of the security acronym for physical, account, network and system security.**

Bon. La dernière fois, j'ai parlé des comptes des utilisateurs et comment les garder sécurisés à l'ère du RGPD (Règlement Général de Protection des Données). Après quatre ans de préparation et de débats, le RGPD a enfin été approuvé par le Parlement européen le 4 avril 2016. Il est entré en vigueur le 25 mai 2018 et les organisations qui ne seraient pas conformes peuvent se voir infliger de lourdes amendes.

Le RGPD est supposé donner confiance aux clients. Comment vos clients - et j'utilise le mot client dans un sens très large - peuvent-ils vous faire confiance, si vous ne pouvez même pas sécuriser votre réseau ? La société derrière knuddels.de, un site de tchat, est la première entreprise allemande a recevoir une amende ; aussi, le RGPD doit-il être pris au sérieux. Passons au N de P.N.A.S. (ou S.N.A.P.) qui est la gestion du réseau, c'est-à-dire le réseau et les services associés. C'est l'avant-dernier pilier de l'acronyme pour Physical (partie matérielle), Account (compte), Network (réseau) et System security (sécurité du réseau).

**Network services are usually running all the time, so you do not see anything really, but you do have logs to refer to. Check your logs, be proactive rather than reactive. Knuddels.de did not even know until all their data showed up on pastebin! When discussing networks and network services, I include both outward facing servers and internal networks. It is a good idea to treat them both as insecure, even if your internal network does not connect anywhere outside the company. Check it regularly. Internet capable and internet connected devices are more prolific than you think.

It is a good idea to have a user for each of your network services. The reasoning behind this is that if that particular service gets exploited, it does not open your entire network. One has but to look on services such as metasploit to see the number of exploits for things such as SQL databases. Thus, if your database uses a root password, you will be owned. This is why you do not want your services or applications advertising themselves.**

Les services de réseau tournent en général en permanence ; aussi, vous ne voyez pas grand chose, mais vous pouvez vous référer à des logs (enregistrements d'activité). Vérifiez ces logs, soyez pro-actif plutôt que réactif. Knuddels.de ne savait rien avant que ses données soient dévoilées sur pastebin ! Quand je parle des réseaux et des services de réseaux, j'inclus à la fois les serveurs tournés vers l'extérieur et les réseaux internes. C'est une bonne idée de considérer les deux comme non-sûrs, même si votre réseau interne n'est pas du tout connecté avec l'extérieur de l'entreprise. Vérifiez-le régulièrement. Les dispositifs pouvant se connecter à Internet et ceux qui le sont réellement sont plus prolifiques que vous ne le pensez.

C'est une bonne idée d'avoir un utilisateur pour chacun de vos services de réseau. La raison sous-jacente est que, si un service particulier vient à être exploité, ça ne doit pas ouvrir l'ensemble du réseau. Regardez seulement sur des services tels que matasploit pour voir le nombre des intrusions dans des choses comme les bases de données SQL. Par conséquent, si votre base de données utilise un mot de passe de root, vous vous ferez avoir. C'est pourquoi vous ne voulez pas que vos services et applications se rendent elles-mêmes visibles à un assaillant.

**Software versions are the best giveaway to an attacker to now go look up exploits against your servers. I want to say, the same applies to networks as user accounts, least privilege. If you do not need a service, uninstall it, and if it only gets used sometimes, stop it when not in use. These days, systemd is replacing the old scripts, so if you are not familiar with it, now is the time to read up on how to use systemctl. Systemctl makes it easy to stop or disable a service, with just those words as commands.

For any business, you do not want any unsecured services. This goes for manually installed services too. Any service you install manually, *you* are responsible for the updates and patches. As always, you want the smallest attack surface, should your server get targeted. By that statement, I mean bind your services to only the needed interfaces and addresses. Should your service not need external communication, bind it to the local host (127.0.0.1). I hear you say, but we are behind a firewall. A firewall is only as strong as its weakest rule. Iptables is rule based, so if you configured iptables and you use ipv6, you already have a hole. (Btw, if you use ipv6 - ip6tables needs to be used.) Then again,if you have an office of 20 people, why use ipv6 internally? Disable things you do not need.**

Les versions des logiciels sont le meilleur vecteur pour qu'un attaquant puissent chercher des exploits à l'encontre de vos serveurs. Je veux parler - et ça s'applique aussi aux réseaux comme aux comptes des utilisateurs -, des privilèges les plus réduits. Si vous n'avez pas besoin d'un service, désinstallez-le et, si vous ne l'utilisez que quelques fois, arrêtez-le entre deux usages. À l'heure actuelle, systemd remplace les vieux scripts ; aussi, si vous n'êtes pas à l'aise avec lui, c'est le moment de tout lire sur l'usage de systemctl. Systemctl rend facile l'arrêt ou la désactivation d'un service, avec juste ce mots-là comme commande.

Quelle que soit l'activité professionnelle, vous ne voulez pas de services non-sécurisés. Ceci s'applique aussi aux services installés manuellement. *Vous* êtes responsable des mises à jour et des correctifs. Comme toujours, vous voudriez la plus petite surface d'attaque, si votre serveur devenait une cible. Par cette affirmation, j'entends seulement que vous ne liiez vos serveurs qu'aux interfaces et adresses indispensables. Si votre service n'a pas besoin de communications extérieures, liez-le à un hôte local (127.0.0.1). Je vous entends déjà dire « mais nous sommes derrière un pare-feu ». Un pare-feu n'est pas plus solide que la plus faible de ses règles. Iptables est basé sur des règles ; aussi, si vous configurez iptables et que vous utilisez ipv6, vous avez déjà un trou. (Au fait, si vous utilisez ipv6, vous devez utiliser ip6tables.) D'ailleurs, si vous avez un bureau avec 20 personnes, pourquoi utiliser ipv6 en interne ? Désactivez tout ce que vous n'utilisez pas.

**Also, if you have a standalone firewall, do not rely on it exclusively. Still use local firewall rules, even if they are a pain to set up. This will add another layer of protection. We cannot say we will not get hacked, but you want to be the most difficult target to start with, and be able to prove that you did everything in your power to prevent getting hacked. I do not only include servers here, but your local offices too. Your server may be in the cloud, but it takes only one person to copy the database or make a spreadsheet with passwords, and the game is lost. Also let's be realistic; the production database may be on a secured server, but an old copy is probably floating about which the web developers play with that may have real data, and accounting prints out customer lists / payments to spreadsheets for control purposes.

Best practice suggests having your network 'pen tested' regularly. This can be a costly option, but a necessary evil. Penetration testers will usually give you paperwork after the test, store that for as long as possible to have an audit trail should you need to prove your commitment to network security. When you watch someone playing chess, you always see things they do not, even if you are just a beginner. The same goes for networks, a fresh pair of eyes may identify something you have missed, so do not just write off penetration testing.**

Et aussi, si vous avez pare-feu autonome, ne comptez pas exclusivement dessus. Là encore, utilisez des règles de pare-feu locales, même si elle sont pénibles à paramétrer. Ça ajoutera une autre couche de protection. Nous ne pouvons pas dire que nous ne serons pas piratés, mais vous voulez être une cible bien trop difficile pour commencer par elle, et être capable de prouver que vous avez tout fait qui était en votre pouvoir pour éviter d'être piraté. Je ne dois pas seulement inclure les serveurs ici, mais vos bureaux locaux aussi. Votre serveur peut être dans le nuage, mais il suffit d'une seule personne qui copie la base de données ou qui met les mots de passe dans un tableur pour que tout soit perdu.

Les bonnes pratiques suggèrent de tester en vrai votre réseau régulièrement. C'est peut-être une option coûteuse, mais un mal nécessaire. Les testeurs de pénétration fournissent en général un compte rendu papier après le test ; stockez-le aussi longtemps que vous pouvez risquer un audit au cas où vous devriez prouver votre engagement dans la sécurité de votre réseau. Quand vous regardez quelqu'un jouant aux échecs, vous voyez toujours des choses qu'il ne voit pas, même si vous êtes un débutant. C'est la même chose pour les réseaux, une paire d'yeux nouvelle peut identifier quelque chose que vous avez loupé ; aussi, ne supprimez pas les tests de pénétration.

**Network security is not only about external networks. Make sure your office network is not only secured, but that your routers, switches and wireless access points are patched up-to-date with the latest firmware. (This goes for printers and other network attached devices too). Be aware of what is connected to your network. I cannot stress this enough. Rogue access points can be an 'in' where no hacking is required. Should you have guest internet access or staff internet access, make sure these networks do not interact with your data network. 

I had a client who had SIP telephony installed, and, although the SIP router had no internet access via their connection, it was connected to the switch, and with an open WiFi. It took many calls to the supplier, who would not do anything about it as, according to them, nobody can get internet access via their equipment. Routers route, so anyone connecting to their WiFi would be routed directly to the next router, and, as it was internal, it got routed to the internet. The WiFi was not used and should have been turned off. When someone comes to work on your network, make sure they comply to *your* rules. This is why I am also not a big fan of bundling jobs together to save on salaries. When your systems administrator is also your network administrator is also your programmer, is also your project manager, is also your web developer, the important checks and balances get left in the dust. Even in very small organisations, one IT person can get overwhelmed very quickly. I am talking to CEOs here, just because your daughter’s 13-year-old friend can "fix" your home computer, does not mean IT professionals do nothing all day long, and just because you have not been hacked in the last seven years does not guarantee tomorrow will be the same.**

La sécurité du réseau ne concerne pas que les réseaux externes. Assurez-vous que votre réseau d'entreprise est non seulement sécurisé, mais que vos routeurs, commutateurs et points d'accès sans fil ont reçu les mises à jour et correctifs avec le plus récent firmware. (Ça vaut aussi pour les imprimantes et les autres dispositifs reliés au réseau.) Soyez conscient de qui se connecte à votre réseau. Je ne le soulignerai jamais assez. Des points d'accès isolés peuvent être une porte d'entrée où il n'y a pas besoin de piratage. Si vous avez des accès internet pour invités ou des accès internet pour le personnel, assurez-vous que ces réseaux n'interagissent pas avec vos réseaux de données.

J'avais un client qui a installé le téléphone sur IP, et, bien que le serveur téléphonique n'avait aucun accès à Internet par ses connexions, il y était relié par le commutateur et avec un WiFi ouvert. De nombreux appels au fournisseur furent nécessaires, celui-ci ne voulant rien faire car, d'après lui, personne ne peut avoir un accès à Internet par cet équipement. Les routeurs routent, donc toute personne qui se connecte au WiFi pourrait se connecter au routeur suivant, et, comme c'est en interne, obtenir un lien vers Internet. Le WiFi n'était pas utilisé et aurait dû être éteint. Quand quelqu'un vient travailler sur votre réseau, assurez-vous qu'il applique *vos* règles. C'est aussi pourquoi je ne suis pas un grand fan des emplois multi-fonctions juste pour économiser sur les salaires. Quand votre administrateur système est aussi votre administrateur réseau qui est aussi votre programmeur, qui est aussi votre responsable de projet, qui est aussi votre développeur Web, les freins et contrepoids importants sont laissés pour compte. Même dans les petites organisations, un employé de l'informatique peut être très rapidement submergé. Je parle ici aux PDG : bien que l'ami de votre fille de 13 ans soit capable de remettre en marche votre ordinateur dommestique, ça ne signifie pas que les professionnels de l'informatique ne font rien de leurs journées, et le fait que vous n'avez pas été piraté dans les sept dernières années ne garantit pas que ce sera pareil demain.

**The most successful hacks are those where the target is unaware that their networks have been compromised.

If you have customers, you have personal data and you need to protect it to the best of your abilities.

The last thing I want to touch upon concerning network services is wrappers. The nice thing about TCP wrappers is that they provide centralised control. You can check your services to see if they are wrapped with the 'ldd' command. This will list their shared object dependencies. If you see libwrap in the mix, you know it is a wrapped service. Wrapped services do not need restarts, they can change on-the-fly. Keep an eye on your host access files. Allow is always processed before Deny, so put a watch on the /etc/hosts.allow file.

Lastly, if you do not do business with certain countries, block them, again reducing your attack surface. It's no use allowing say, Vietnam access if you are a local delivery fish-n-chips shop with info on all your customers for your local delivery routes in Lisbon. This is an example, and I am not picking on Vietnam in any way. I am purely trying to illustrate that local businesses – if you have a web server or not – that do not do business outside of their town or country, should reduce their risk level. This goes for emails too, drop emails from country prefixes you do not deal with, and the emails from Nigerian Princes should decrease accordingly. We may joke here, but phishing scams are still one of - if not the - most successful attacks today.**

Les piratages les plus réussis sont ceux où la cible ne s'aperçoit pas que ses réseaux ont été compromis.

Si vous avez des clients, vous avez des données personnelles et vous devez les protéger au mieux de vos possibilités.

Une dernière chose que je veux aborder à propos des services de réseau sont les « TCP wrappers » (emballeurs TCP). Le bon côté des TCP wrappers, c'est qu'ils fournissent un contrôle centralisé. Vous pouvez vérifier vos services pour voir s'ils sont « wrappés » avec la commande « ldd ». Cela vous listera leurs dépendances sur les objets partagés. Si au milieu de tout ça, vous voyez libwrap, vous savez que c'est un service « wrappé ». Les services wrappés n'ont pas besoin de redémarrage ; ils peuvent être modifiés à la volée. Gardez un œil sur les fichiers d'accès à vos hôtes. Allow (autoriser) est toujours traité avant Deny (dénier) ; aussi, jetez un œil sur le fichier /etc/hosts.allow.

Enfin, si vous ne faites pas d'affaires avec certains pays, bloquez-les, réduisant encore votre surface d'attaque. Ça ne sert à rien d'autoriser, disons, l'accès au Vietnam si vous êtes un commerçant de fish-n-chips livrant localement avec des informations sur tous vos clients pour vos trajets locaux de livraison dans Lisbonne. C'est un exemple et je ne veux en aucune manière taper sur le Vietnam. Je veux juste essayer d'illustrer le cas des activités professionnelles locales - que vous ayez un serveur Web ou non - qui ne font pas d'affaires hors de leur ville ou de leur pays et réduisent ainsi le niveau du risque. Ceci vaut aussi pour les mails ; laissez tomber les mails avec les préfixes de pays avec lesquels vous ne commercez pas et les mails venant de Nigerian Princes devraient diminuer d'autant. Nous pourrions en rire, mais les « phishing scams » (mails pourris de hameçonnage) sont l'une des attaques les plus performantes actuellement.