Ceci est une ancienne révision du document !
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 aprlé des comptes de s utilisateurs et comment les conserver sûrs à l'ère du RGPD (Réglèment Général de Protection des Données). Après quatre ans de pr¶tion et de débats, le RGPD a finalement été approuvé par le Parlement européen le 4 avril 2016. Il est entré en vigueur le 25 may 2018 et les organisations qui ne seraient pas conformes peuvent se voir infliger des 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 vous ne pouvez même pas sécuriser votre réseau ? La société derrière knuddels.de, un site de chat, est la première entreprise allemande a recevoir une amende ; aussi, le RGPD doit-l être pris avec 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 asoccié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.
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.
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.
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.
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.