[{"content":"In my articles on the Sanca vulnerability scanner and automated email sending , I describe situations where I was faced with a problem for which I came up with a solution.\nBut if you listen carefully, you\u0026rsquo;ll realise that within our clients\u0026rsquo; environments there are numerous pain points just waiting for us to address them. Here are two anecdotes that enabled me to provide (almost unwittingly) clients with solutions they didn\u0026rsquo;t even realise they needed.\nGenerate a 200-row Excel file on a monthly basis I\u0026rsquo;d been working for a major client for a few days when a manager asked me to list all the domain names registered in Azure Active Directory (AAD) in an Excel file, along with additional details such as whether a domain name is associated with an IP address, whether there is a web server, and so on.\nAn Excel file with around 200 rows and several columns – gathering all that information one by one takes time. I don\u0026rsquo;t know whether he was doing it manually or asking someone else to do it, but it seemed to be a chore for him.\nI didn\u0026rsquo;t want to spend days building an Excel file only to be asked for it again the following month, so I automated the task straight away.\nI spent half an hour writing a script in Fish; it carried out all the checks and generated the complete Excel file. The following month, when I sent him the Excel file five minutes after he\u0026rsquo;d asked for it, he asked me if I\u0026rsquo;d automated the generation of the file. I told him I had and showed him where to find the script, which I\u0026rsquo;d shared with the company.\nAfter a while, he stopped asking me for the Excel file, and during a conversation I learnt that he was using the script himself.\nSurprised, I asked him if he\u0026rsquo;d had any trouble using it, and he replied that it had been very straightforward, that he\u0026rsquo;d read the README file provided with the script and had followed the instructions.\nI always comment on and document my projects, but for a manager to manage to use my script entirely on his own, on an operating system different from mine, on his own computer, was a real victory.\nInstead of making them dependent on me and on a script I would have kept secret, I resolved a point of friction and enabled someone to be independent in their work. Some might say that I\u0026rsquo;ll lose my assignments if I allow my clients to be independent, but I see things differently.\nEveryone hates service providers who lock their clients in; I, on the other hand, prefer my clients to stay with me because they want to, because they know I\u0026rsquo;m on their team.\nGenerating a monthly export of vulnerabilities by region As explained in my articles on Sanca and automating email sending via AHK , I have been involved in vulnerability management. I automated everything I could on my end in order to handle as many vulnerabilities as possible.\nOne day, whilst chatting to someone responsible for overseeing the remediation of vulnerabilities across several countries, she explained to me that she would copy the data we sent in emails and paste it into an Excel file for tracking, which she would then supplement with further data. The ticketing system couldn\u0026rsquo;t provide her with all the data she needed, so she had to manage her own spreadsheet. I must admit I\u0026rsquo;d never thought of that.\nWhat struck me was that the data she needed was already in my own spreadsheet. Why not let her benefit from it?\nWith my manager\u0026rsquo;s approval, I spent about twenty minutes writing a PHP script to take my Excel file, filter it to include only the vulnerabilities relevant to her, tidy up a few bits of data to make it a proper export, and I sent it to her. For me it was simple, nothing complicated, I was just doing her a favour, but for her it made a difference.\nShe no longer needed to copy and paste data from emails or fill in missing details; everything was there. She could focus on tasks where she added value.\nOver time, we improved the export; for example, I extracted data from the ticket management system via the API to supplement the export, making it truly comprehensive. This Excel export, which I generated in a matter of seconds using a script that did the work for me, was useful to this manager.\nIt enabled her to track her current vulnerabilities, to find out when a vulnerability had been reported or the date of the last email exchange on the subject, but also to monitor progress in dealing with vulnerabilities. Managers are often adept at using Excel, so it was easy for her to see the number of vulnerabilities resolved by country and by month, to create a clear chart showing the trend, or even to identify the countries that take the longest to fix their vulnerabilities. This export was a genuinely useful working tool.\nI hadn\u0026rsquo;t been explicitly asked to produce this export; my job was to process and report vulnerabilities. But if the teams responsible for these vulnerabilities didn\u0026rsquo;t have the tools to do their job properly, what was the point? Initially, I just wrote this script to help one person, because it seemed a shame to let a motivated colleague, even from another team, waste their time, and it was inconceivable to me to do it manually. I like people who try to do their job properly.\nShe liked the export so much that she asked me for it every month; luckily, it only took me a few seconds to generate it. It was so handy that, even though it wasn\u0026rsquo;t originally part of my remit, I started providing these exports to all the relevant managers.\nThanks to these exports, the managers were able to do their jobs more effectively, and our team collaborated much better with them. Logically, my manager should have been commended by his superiors for this collaboration. I was partly responsible for that, and I hadn\u0026rsquo;t even done it on purpose.\nMuch later, when another team took over the management of vulnerabilities, the manager who had originally organised the export was very disappointed to learn that the new team would no longer be providing her with this export. I\u0026rsquo;d got her used to a bit of luxury. New team, new methods.\nThe key is to listen As techies, once we have the ability to automate something, it becomes unthinkable to do it manually. That said, we mustn\u0026rsquo;t forget to listen to the business teams, who are often left to their own devices with Excel as their only tool. I\u0026rsquo;m used to automating my own tasks, but by automating other people\u0026rsquo;s tasks, I\u0026rsquo;m taking a weight off their shoulders, and I\u0026rsquo;m always impressed by just how much it means to them.\nWhen faced with this sort of situation – particularly the anecdote about the export of vulnerabilities – there are at least two types of people:\nThose who say we need artificial intelligence (AI) because it solves all our problems. And those who say the solution is to develop a massive, bespoke tool that does exactly the job, which will be available in three years\u0026rsquo; time if we\u0026rsquo;re lucky and will cost 3 million euros. To those who advocate for AI in every context, I would say that it is merely a tool, not a magic wand. There are situations where AI offers genuine added value, and many others where effective automation is more than enough.\nNot to mention that AI comes with its own set of constraints: costs are unpredictable, sending sensitive data to a company, often a foreign one, is risky, and a business rarely has the hardware to run AI on a server using Ollama.\nAnd to those who would like to overhaul the entire system in order to achieve a perfect solution, I would say that they are partly right. But long-term planning is as important as it is difficult; businesses evolve, teams change, and the perfect solution may become obsolete even before its development is complete.\nI belong to a third category of people: I try to do my job and help others do theirs. I didn\u0026rsquo;t have the power to reform the company, but I did have the opportunity to provide immediate, tailor-made solutions. Thanks to this, together with the people involved, we were able to eliminate pain points, improve processes and enhance collaboration between teams, all in less than an hour.\nWould you like to audit your processes to find out what to automate?\nLet\u0026rsquo;s talk about it and find some solutions ","permalink":"https://www.abosec.fr/en/blog/created-tools-noone-asked/","summary":"I\u0026rsquo;ll share two anecdotes about times when I listened to my clients\u0026rsquo; requests and read between the lines. I came up with solutions that the client didn\u0026rsquo;t even realise they needed.","title":"I've created tools that nobody had asked me to make"},{"content":"I recently explained how I came to develop Sanca , a vulnerability scanner written in Rust. After updating the dependencies, Sanca started crashing. Not just a crash, but a SIGSEGV (segmentation violation, also known as a segmentation fault), a memory error that caused it to be terminated by the operating system. Rust is supposed to prevent this sort of error.\nThe problem only occurred on OpenBSD, not on Linux. OpenBSD has stricter security rules regarding memory (for example, W^X), so that makes sense.\nI use Sanca every day on OpenBSD, so I had to fix this.\nLooking for the cause The image above shows the error that occurred when I ran Sanca, it\u0026rsquo;s not exactly detailed.\nFortunately, OpenBSD saves the state of the memory at the time of the crash in a .core file, allowing us to analyse the memory, the registers, and everything else needed to identify which part of the code is causing the programme to crash.\nI opened sanca_software.core in gdb (GNU Debugger), which quickly put me on the right track.\nAs soon as I opened it, GDB told me there was a problem with aws-lc-sys, the Rust wrapper around the aws-lc library, written in C. After doing some research, I discovered that aws-lc was a cryptographic library based on BoringSSL, a fork of OpenSSL. The problem therefore seemed to be related to SSL/TLS, but I wanted to be sure of the root cause.\nSanca does not depend directly on this library, so I used the cargo tree -i aws-lc-sys command to find out which of Sanca\u0026rsquo;s dependencies aws-lc-sys was using. It turned out to be reqwest.\nSanca uses a library called \u0026ldquo;reqwest\u0026rdquo; to send HTTP requests to Web servers; reqwest uses \u0026ldquo;rustls\u0026rdquo; to handle the TLS protocol, and rustls uses \u0026ldquo;aws-lc-rs\u0026rdquo;, which is a wrapper around \u0026ldquo;aws-lc-sys\u0026rdquo;, to handle the cryptographic aspects.\nResearch and implementation of the solution Having identified the source of the problem, I needed a solution.\nWhilst researching rustls, I noticed that the library offered several cryptography ‘providers\u0026rsquo;; aws-lc was the new default provider, whilst the old one was ring. However, it was still possible to install rustls with ring instead of aws-lc, thanks to a feature in Rust / Cargo called feature flags. It remained to be seen whether reqwest was flexible enough to let me choose the rustls provider.\nFortunately, yes. Thanks again to feature flags, I was able to install reqwest whilst specifying that it should not install any providers for rustls, and at the same time I installed and initialised rustls myself using ring as the provider. This time it worked; I was able to compile and use Sanca without any problems.\nI could have left it at that, but it bothered me to simply remove aws-lc from Sanca when it was the default choice for rustls – there must have been a reason for it.\nI\u0026rsquo;ve decided to use feature flags in Sanca as well, to allow users to choose between aws-lc and ring. Currently, there are two ways to compile Sanca:\ncargo build --release to compile using aws-lc, which is likely to suit most FreeBSD, Linux, macOS and Windows users. Or\ncargo build --release --no-default-features --features ring-provider to compile Sanca with ring, which is more suitable for OpenBSD users at the moment.\nI have noted the difference in the README file, so that each user can choose the method that suits them best.\nWhat I\u0026rsquo;ve learnt Modern software development relies heavily on external libraries, regardless of the language. Whilst JavaScript with npm is the prime example of supply chain attacks, where compromises of external libraries affect the projects that use them, Rust with Cargo is not immune to such issues either.\nThis isn\u0026rsquo;t an attack; it\u0026rsquo;s simply a bug. But a bug in a dependency affects the projects that use it. You need to know how to debug and find suitable solutions that work today without hindering the project tomorrow. The aws-lc library supports \u0026ldquo;post-quantum\u0026rdquo; algorithms, which is not yet the case with ring, so it was important not to make any decisions that would block progress.\nIn Rust, you often find dependencies on libraries written in C. This also applies to other languages such as Python or PHP, but Rust makes a strong promise: that memory accesses are safe. This is not its only advantage, but it is a very important distinguishing feature.\nThe problem is that today many important programmes are written in C or C++, whether they are cryptographic libraries such as LibreSSL, OpenSSL or BoringSSL, or operating systems such as OpenBSD, Linux, macOS or Windows. C is a great language; it runs on all architectures and compiles very quickly, but its memory accesses are not safe. Even today, a huge number of vulnerabilities are linked to memory management.\nAs long as Rust relies on libraries written in C, which is not likely to change any time soon, given that C is ubiquitous, we will continue to face memory issues. A cryptographic library written entirely in Rust is currently under development, but it will be several years before it is as comprehensive and thoroughly audited as OpenSSL or aws-lc.\nA dependent library that crashes is yet another vulnerability in your supply chain.\nIf you want to audit your own tools or migrate to a stack you have greater control over, let\u0026rsquo;s discuss it .\n","permalink":"https://www.abosec.fr/en/blog/sanca-dependency-sigsegv-error/","summary":"Sanca, my vulnerability scanner written in Rust, was crashing due to a memory error. I identified the cause and fixed the problem.","title":"When a Rust dependency crashes on OpenBSD: debugging a memory error"},{"content":"As I explained in my article on the vulnerability scanner Sanca , whilst carrying out a vulnerability management project, I improved the detection process, thereby increasing my productivity. I was dealing with far more vulnerabilities, which meant sending far more emails to notify those affected.\nThe context I was managing vulnerabilities across a very large number of servers. We used an EASM to monitor them, but it produced results that were so unreliable that I took some time off to develop Sanca. Thanks to this scanner, I was able to detect more vulnerabilities and no longer wasted time on false positives and duplicates.\nAs I was dealing with more vulnerabilities, I was creating more tickets. Once the vulnerabilities had been assessed, creating a ticket was just a repetitive manual task, so I automated it. By automating everything that could be automated upstream, we were hitting a bottleneck at the final stage: sending the emails.\nWe wanted to do things properly, so we had an email template in which we would insert the recipient\u0026rsquo;s name, the server concerned, details of the vulnerability and how to fix it. Everything needed for a non-technical manager to understand and pass on to their technical team, who would then have enough information to resolve the issue. When we didn\u0026rsquo;t hear back, we\u0026rsquo;d send follow-up emails; we also had a template for that.\nI had reached a point where I was spending five hours every week sending emails in Outlook to inform the relevant people about the vulnerabilities I had discovered.\nEvery two weeks I would send reminders, but the more vulnerabilities I had in the pipeline, the more reminders I had to send, and the more time it took. I had reached a point where I was spending four days sending out all my reminders.\nIt had become unbearable.\nThe process I used to call these repetitive tasks \u0026ldquo;robot work\u0026rdquo;. Imagine doing that for 5 hours:\nOpen Excel with the details of each vulnerability. Open Outlook to send the emails. Create a new message. Copy the template and paste it into Outlook. Copy the recipient\u0026rsquo;s first name from Excel and paste it into the correct place in the template. Copy the description of the vulnerability from Excel and paste it into the correct place in the template. Repeat this process for all the necessary details. Check the email before sending to ensure nothing has been omitted. Click \u0026ldquo;Send\u0026rdquo;. Fill in the \u0026ldquo;Date sent\u0026rdquo; column in the Excel file. Update the status of the ticket associated with the vulnerability. Repeat from step 3 for the next vulnerability. It brings to mind the film Modern Times with Charlie Chaplin, when he works in the factory performing the same action over and over again, to the point where he even does it outside of work.\nBeing a freelance cybersecurity consultant shouldn\u0026rsquo;t feel like working on an assembly line. It didn\u0026rsquo;t seem to bother my colleagues, who were diligently carrying out the tasks they\u0026rsquo;d been asked to do, but it frustrated me a little more with every email.\nThe client was paying for the services of a freelance cybersecurity consultant, at the rate of a freelance cybersecurity consultant, to carry out freelance cybersecurity work. As well as hating these repetitive tasks, I felt a bit guilty about spending so much time on tasks to which I was adding no value, even if this was a consequence of my own productivity.\nSo I decided to automate the sending of emails.\nThe solution, automation There was a reason why I hadn\u0026rsquo;t automated it sooner: the emails had to be sent from Outlook. No SMTP server to call from a Python script, no Thunderbird, no alternatives.\nI initially considered PowerAutomate, a \u0026ldquo;no-code\u0026rdquo; tool from Microsoft designed for automation, but it didn\u0026rsquo;t work properly and wasn\u0026rsquo;t selected.\nAs sending sensitive data via email is an irreversible action, I needed a reliable tool; I couldn\u0026rsquo;t afford to send an email to the wrong person or include the wrong information in the message.\nSo I looked for another solution, and that\u0026rsquo;s when I discovered AutoHotKey (AHK) , a small programming language designed specifically to automate Windows. It allows you to create keyboard shortcuts and interact with Excel, Outlook and other office software – it was exactly what I needed. And it didn\u0026rsquo;t matter that I\u0026rsquo;d never developed in AHK before.\nAfter developing a script using AHK, the process of sending emails looked like this:\nOpen Excel with the details of each vulnerability. Open Outlook to send the emails. Run the AHK script. The script would scan through the Excel file, where 1 row = 1 vulnerability; for each row, it would create a new email based on the template, insert the data where necessary, and send the message. It would then fill in the \u0026ldquo;Date sent\u0026rdquo; column in Excel and call the ticketing system\u0026rsquo;s API to change the ticket\u0026rsquo;s status.\nIt followed the original process to the letter, there was no question of compromising on quality, but it worked much faster than me and didn\u0026rsquo;t make any repetitive errors. No need for artificial intelligence (AI); a good, bespoke automation system does the job very well.\nI\u0026rsquo;d gone from spending 5 hours a week on this to just 2 minutes – it was a huge relief. I did the same for the follow-up emails, and saved even more time. Now I could focus on detection, advising the teams responsible for fixing the vulnerabilities, and testing to validate the fixes.\nLimitations of AHK and reimplementation in Python The AHK script was a brilliant tool that I shared with the client and my colleagues, but it was a bit of a makeshift solution. There was no graphical interface; it was designed to perform a specific task but wasn\u0026rsquo;t very flexible and was difficult to adapt.\nA few months ago, I was thinking back on this project and how useful it had been, so I decided to develop a programme to control Outlook – a neater version of my AHK script.\nIt has a graphical user interface: you select the Excel file to use for sending emails, configure a few settings, and it controls Outlook to send the messages as if I were sending them myself. And as I was on a roll, I even made sure it was available in several languages (French and English) and that it had two themes (light and dark).\nUsing Outlook is handy when you\u0026rsquo;re stuck in a strict Microsoft environment without SMTP access. As the Python programme is cleaner and better structured, I\u0026rsquo;ll soon be adding the option to send emails via an SMTP server, without Outlook. This will have the advantage of working on all operating systems (such as Linux, macOS and OpenBSD), so I won\u0026rsquo;t need to launch a Windows virtual machine (VM) to use it.\nWhat I learnt from it Even more so than whilst developing Sanca, I realised just how much my value as a service provider lay in providing solutions, and not just in \u0026ldquo;doing cybersecurity\u0026rdquo;. When a client hires a freelancer, they want someone who can get the job done quickly and well, working independently whilst also being able to work as part of a team. Someone who doesn\u0026rsquo;t just complain about problems, but who comes up with solutions.\nI grumbled, a lot, but I came up with solutions to my problems. That year we achieved 150 per cent of our EASM targets; I\u0026rsquo;m convinced that automation played a part in that.\nAre your teams wasting time on repetitive tasks?\nLet\u0026rsquo;s talk about what we can automate .\n","permalink":"https://www.abosec.fr/en/blog/automated-email-sending/","summary":"I used to waste 5 hours a week sending emails manually from Outlook. I\u0026rsquo;ve automated the process, and it now takes just 2 minutes.","title":"How I replaced 5 hours of copy-and-paste with 2 minutes of automation"},{"content":" If you just want to access the demo (where the CVE list is disabled), you can find it at sanca.io .\nIf you\u0026rsquo;re looking for the source code, it\u0026rsquo;s on GitHub .\nLarge organisations often use EASM (External Attack Surface Management) platforms to monitor their servers and websites for vulnerabilities.\nThe ideal scenario is as follows:\nEvery vulnerability identified by the platform is genuine, unique and clearly explained. The EASM automatically logs the vulnerabilities in the company\u0026rsquo;s ticketing system. Thanks to a comprehensive and up-to-date inventory of the company\u0026rsquo;s assets, each ticket is assigned to the right person, who can then manage and document the steps involved in rectifying it. Now let\u0026rsquo;s turn to reality.\nFalse positives, lack of evidence and duplicates When working through the scan results provided by an EASM, you soon realise that the results are not actionable and that you need to go through each supposed vulnerability to check not only whether it is genuine, but also whether it has been reported multiple times.\nAmong the cases that crop up frequently are:\nA Windows vulnerability identified on a Linux server. A vulnerable version of Apache httpd reported several times (version \u0026lt; 2.4.60, version \u0026lt; 2.4.58, version 2.4.57, because the installed version is 2.4.54). An unmaintained version of jQuery detected in the middle of a minified JavaScript file, with absolutely no information on how it was identified. With results like these, it is impossible to publish vulnerabilities directly in the ticketing system, as this would overwhelm the team with false positives and vulnerabilities that have already been dealt with.\nWe therefore need analysts to redo the EASM\u0026rsquo;s work: identifying genuine vulnerabilities, removing duplicates, and creating tickets with clear descriptions and remediation advice.\nWhat a waste of time to have to redo the work of a tool we\u0026rsquo;re paying for.\nMy decision: to develop my solution I\u0026rsquo;d had enough of wasting my time; I wanted reliable tools so I could focus on the tasks where I add value.\nSpending 10 minutes sifting through a 900-line minified JavaScript file to identify a possible version of jQuery shouldn\u0026rsquo;t be my job.\nI eventually took two weeks\u0026rsquo; holiday in August to design a programme capable of identifying OpenSSH, jQuery, WordPress and PHP. I had a few key criteria that I was keen to adhere to:\nEvery detection had to be accompanied by proof. I wanted to spend more time using it than debugging it. It had to be lightweight and fast. I chose to develop Sanca in Rust.\nWhy Rust I wanted something lightweight, so no Chromium or Puppeteer, which use up 2 GB of RAM.\nIt needed to be reliable and easy to maintain, so developing a programme in JavaScript or Python was out of the question.\nThe Rust language has the advantage of being rigorous; it allows you to detect many bugs during development rather than at runtime, so you can be relatively sure that it works. It was the ideal candidate, so that\u0026rsquo;s what I chose.\nToday I have 15,000 lines of Rust code, including unit tests, and a robust architecture that allows me to scale the programme easily.\nHow Sanca works Sanca supports two types of scan: TCP and HTTP. The TCP scan identifies technologies such as OpenSSH, whilst the HTTP scan identifies web servers, CMSs, as well as JavaScript technologies. This latter category is the most time-consuming to identify manually.\nBoth scans use regular expressions.\nThe TCP scan is simple: it retrieves a programme\u0026rsquo;s banner and analyses it to identify what it is.\nThe HTTP scan is slightly more complex: it downloads the URL provided and can, if necessary, extract the URLs of JavaScript files contained within the HTML to download them as well. Depending on the technologies you are trying to identify, it can also add specific URLs, for example for Tomcat or phpMyAdmin. Downloads are carried out in parallel to save time. It then searches each file for the technologies you are trying to identify.\nRegardless of the scan type, it can use the identified programmes and versions to call the NVD (NIST) API and retrieve the corresponding CVEs. The CVEs are cached to avoid having to call the API every time.\nHere is an example:\n./sanca --vuln-source nvd --vuln-cache files -s http -u https://www.my.website Sanca software v1.6.1 - https://www.sanca.io ----------https://www.my.website---------- [Tomcat/9.0.117] Tomcat 9.0.117 has been identified by looking at its signature \u0026#34;Apache Tomcat/9.0.117\u0026#34; at this page: https://www.my.website/..;/..;/ | CVE: CVE-2026-41284, CVE-2026-41293, CVE-2026-42498, CVE-2026-43512, CVE-2026-43513, CVE-2026-43514, CVE-2026-43515, CVE-2026-50229, CVE-2026-53404, CVE-2026-53434, CVE-2026-55276, CVE-2026-55955, CVE-2026-55956, CVE-2026-59083, CVE-2026-59084, CVE-2026-66299 [Bootstrap/4.3.1] Bootstrap 4.3.1 has been identified because we found \u0026#34;Bootstrap v4.3.1\u0026#34; at this url: https://www.my.website/typo3temp/assets/compressed/merged-94ed12fb452ac918e98829275c23e618-8239108882700156f9f4733844759929.js [jQuery/3.7.1] jQuery 3.7.1 has been identified because we found \u0026#34;jQuery v3.7.1\u0026#34; at this url: https://www.my.website/typo3temp/assets/compressed/merged-8cdece27f7e9695aabf1c8da17ed0932-3c08673a12d49a49782ee3191cd951f8.js [phpMyAdmin/5.2.3] phpMyAdmin 5.2.3 has been identified because we found \u0026#34;5.2.3 (2025-10-07)\u0026#34; at this url: https://www.my.website/phpmyadmin/ChangeLog [Highcharts/11.4.8] Highcharts 11.4.8 has been identified because we found \u0026#34;Highcharts[...]\u0026#34;,n.version=\u0026#34;11.4.8\u0026#34;\u0026#34; at this url: https://www.my.website/main-LCYC8A7P.js We can see that Sanca has added the URL https://www.my.website/..;/..;/ , and found Tomcat.\nThe scan takes just a few seconds to run, and we get a list of the technologies detected. For each one, you can see at a glance where and how it was identified. You can then focus on the rest of the work.\nThe drawback is that the CVE database isn\u0026rsquo;t always accurate, but it would be very straightforward to implement another source.\nWhat Sanca detects Sanca detects 80 different technologies. I won\u0026rsquo;t provide an exhaustive list, but we can list various types:\nTCP technologies, such as OpenSSH, MySQL and ProFTPD. HTTP technologies, such as Tomcat, Nginx and PHP. And JavaScript technologies, such as Highcharts, jQuery and Bootstrap. I haven\u0026rsquo;t implemented a scan for UDP technologies such as bind9, but thanks to a clean architecture, it wouldn\u0026rsquo;t be very complicated to add. Perhaps I\u0026rsquo;ll get round to it one day when I need it.\nIntegration into production The example above shows the text output, which is handy for manual use, but it is possible to take it a step further by exporting to JSON or CSV.\nThis allows you to use another programme to bridge the gap between the scan results and the ticketing system.\nExemple de scan HTTP Here is an HTTP scan result exported as JSON.\n{ \u0026#34;findings\u0026#34;: [ { \u0026#34;evidence\u0026#34;: \u0026#34;Apache Tomcat/9.0.117\u0026#34;, \u0026#34;evidence_text\u0026#34;: \u0026#34;Tomcat 9.0.117 has been identified by looking at its signature \\\u0026#34;Apache Tomcat/9.0.117\\\u0026#34; at this page: https://www.my.website/..;/..;/\u0026#34;, \u0026#34;technology\u0026#34;: \u0026#34;Tomcat\u0026#34;, \u0026#34;url_of_finding\u0026#34;: \u0026#34;https://www.my.website/..;/..;/\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;9.0.117\u0026#34;, \u0026#34;vulnerabilities\u0026#34;: [ { \u0026#34;base_score\u0026#34;: 7.5, \u0026#34;cve_id\u0026#34;: \u0026#34;CVE-2026-41284\u0026#34;, \u0026#34;cvss_version\u0026#34;: \u0026#34;3.1\u0026#34; } ] } ], \u0026#34;ip_hostname\u0026#34;: \u0026#34;www.my.website\u0026#34;, \u0026#34;port\u0026#34;: 443, \u0026#34;url\u0026#34;: \u0026#34;https://www.my.website/auth/login\u0026#34; } All the important information is provided here; for each identified technology, you will find:\nThe raw evidence. The text-based evidence, which is clearer for humans. The name of the identified technology and its version. The list of CVEs associated with this version, along with the CVSS score. The FQDN and port that were scanned. The URL used by Sanca to carry out its scan. Example of a TCP scan And here is the result of a TCP scan.\n{ \u0026#34;findings\u0026#34;: [ { \u0026#34;evidence\u0026#34;: \u0026#34;SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.18\u0026#34;, \u0026#34;evidence_text\u0026#34;: \u0026#34;The operating system Ubuntu 24.04 has been identified using the banner presented by OpenSSH: SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.18\u0026#34;, \u0026#34;technology\u0026#34;: \u0026#34;Ubuntu\u0026#34;, \u0026#34;url_of_finding\u0026#34;: null, \u0026#34;version\u0026#34;: \u0026#34;24.04\u0026#34;, \u0026#34;vulnerabilities\u0026#34;: [] }, { \u0026#34;evidence\u0026#34;: \u0026#34;SSH-2.0-OpenSSH_9.6p[...] Ubuntu-3ubuntu13.18\u0026#34;, \u0026#34;evidence_text\u0026#34;: \u0026#34;OpenSSH 9.6p1 has been identified because we found \\\u0026#34;SSH-2.0-OpenSSH_9.6p[...] Ubuntu-3ubuntu13.18\\\u0026#34; in its banner\u0026#34;, \u0026#34;technology\u0026#34;: \u0026#34;OpenSSH\u0026#34;, \u0026#34;url_of_finding\u0026#34;: null, \u0026#34;version\u0026#34;: \u0026#34;9.6p1\u0026#34;, \u0026#34;vulnerabilities\u0026#34;: [ { \u0026#34;base_score\u0026#34;: 9.3, \u0026#34;cve_id\u0026#34;: \u0026#34;CVE-2008-3844\u0026#34;, \u0026#34;cvss_version\u0026#34;: \u0026#34;2\u0026#34; } ] } ], \u0026#34;ip_hostname\u0026#34;: \u0026#34;www.my.website\u0026#34;, \u0026#34;port\u0026#34;: 22, \u0026#34;url\u0026#34;: \u0026#34;\u0026#34; } This time, Sanca scanned port 22, on which OpenSSH is listening. Two important points here:\nThe JSON structure is the same regardless of the type of scan, which makes it easier for another programme to process. By analysing the OpenSSH banner, Sanca deduced the operating system installed and its version. With this simple scanner and a Python script that communicates with the ticketing system\u0026rsquo;s API, managing your organisation\u0026rsquo;s vulnerabilities becomes simpler and faster.\nWhat I\u0026rsquo;ve learnt This project was quite technical: cybersecurity, knowledge of technologies, Rust development, unit testing, clean architecture.\nHowever, I realised that my value to this client did not stem from my technical skills, even though they were important. My real value lay in my ability to find solutions to the problems I encountered, and to work better and faster.\nOthers just as competent as me could have carried on processing the results from the EASM platform without complaining. I, on the other hand, improved the process; I made it more reliable and much faster.\nThat year, we achieved 150 per cent of our targets for EASM vulnerabilities; this is probably no coincidence.\nAre your teams wasting time on repetitive security tasks? Find out more about my automation and audit services .\n","permalink":"https://www.abosec.fr/en/blog/sanca-vulnerability-scanner/","summary":"Frustrated by the quality of the results provided by an EASM, I developed Sanca, an open-source vulnerability scanner that provides evidence for everything it claims.","title":"How I developed Sanca, my vulnerability scanner"},{"content":"If you\u0026rsquo;ve read my article introducing Linux and OpenBSD , you\u0026rsquo;ll know that BSDs are complete operating systems, whereas Linux is merely a kernel.\nThis means that when you install FreeBSD, the kernel and the userland have been developed together. This ensures a certain degree of stability, there is little chance that the system will stop working after a simple update.\nConversely, when you install a Linux distribution, most of the components have been developed separately. The kernel was developed on one side, the init system on another, and the userland yet another. Putting it all together is quite a feat, and even the slightest mishandled update can cause the whole structure to collapse.\nThe Ubuntu case Ubuntu is one of the best-known Linux distributions. Unlike so-called rolling release distributions, Ubuntu releases new versions regularly and locks down the versions of the installed software. For example, when Ubuntu 24.04 was released in April 2024, Apache httpd 2.4.58 was available.\nTo ensure system stability, Ubuntu does not incorporate new versions of Apache every time they are released; instead, it retains version 2.4.58 and applies bug and security fixes for the duration of the Ubuntu release\u0026rsquo;s lifecycle.\nUbuntu makes one notable exception: the kernel. Problems arise when Ubuntu decides to install a new version of the kernel.\nThe kernel update that causes the system to crash For example in 2026 Canonical, the company behind Ubuntu, decided to upgrade the Linux kernel from version 6.x to version 7.x in Ubuntu 24.04. The problem is that the system is fragile, and when certain components are incompatible, it does not roll back the update. Users who had VirtualBox installed found their systems crashing after this update, because VirtualBox installs its own kernel module, and this was not yet compatible with version 7.x of the kernel. As a result, the update would crash, except that the new kernel was already installed. Upon restarting, the user would encounter a \u0026ldquo;Kernel Panic\u0026rdquo; error and would have no choice but to boot back into the old kernel, uninstall VirtualBox whilst waiting for its module to become compatible, and then complete the update.\nTo avoid this, you would need to use the GA (General Availability) kernel instead of the HWE (Hardware Enablement) kernel, but this is not the default setting.\nUsing Qemu / KVM instead of VirtualBox avoids the dependency on a module.\nOtherwise, Debian, the parent distribution of Ubuntu, retains the same kernel version throughout the entire lifecycle of that release.\nThe FreeBSD case FreeBSD, like OpenBSD and NetBSD, works slightly differently. There is a distinction between the base system on the one hand, and third-party packages on the other. The kernel is part of the base system, whereas Apache httpd or Firefox are part of the packages.\nThis makes all the difference, because you don\u0026rsquo;t risk crashing the whole system when you think you\u0026rsquo;re just updating a piece of software. On the one hand, you use freebsd-update to update the system (kernel + userland); on the other, you use pkg upgrade to update third-party packages. This ensures you don\u0026rsquo;t accidentally update the system, but the flip side is that it\u0026rsquo;s easier to forget to update it.\nUpdating the system via packages As stated in the FreeBSD documentation , it is now possible to install the system in two ways:\nUsing Distribution Sets, i.e. the traditional method described above. Via packages, which allows the system to be updated at the same time as third-party software. This will become the default option from FreeBSD 16.0 onwards. Having experienced Ubuntu and kernel panics caused by a kernel upgrade, it gives you pause for thought. What\u0026rsquo;s the point? Will we face the same risks of instability as with certain Linux distributions?\nThe difference It is important to bear in mind that the entire FreeBSD system is developed by the same team, so you can be sure that everything works consistently, this is the most reassuring aspect. Whether the system is updated via freebsd-update or pkg upgrade makes little difference to an administrator who regularly updates their system; only the way in which the updates are delivered changes, whilst their content and frequency remain the same.\nThe only real difference is that you can no longer separate system updates, which may sometimes require a reboot, from package updates, which never do. But this isn\u0026rsquo;t a problem, just a change in habit.\nAn important point to note: only updates will be applied via pkg, not upgrades. In other words, there is no risk of accidentally upgrading from FreeBSD 15.x to 16.x.\nAnd if you choose to install via the Distribution Sets, it is likely that this option will continue to be supported for many years to come.\nTired of unpredictable updates and service interruptions? I can take care of the full maintenance of your servers : audits, hardening, updates, monitoring, and responsive support.\n","permalink":"https://www.abosec.fr/en/blog/freebsd-install-installation-type/","summary":"FreeBSD has always installed the system using Distribution Sets, just like other BSDs. It now offers the option to install the system using packages. Let\u0026rsquo;s see what this changes.","title":"FreeBSD offers two types of installation: what is the difference?"},{"content":"Fail2ban is an intrusion prevention system (IPS), it analyses the logs of programmes such as SSH, Web or mail servers and configures the firewall to block IP addresses exhibiting inappropriate behaviour. Its strength lies in its flexibility.\nIn this article, I introduce Fail2ban and its benefits, but I do not explain how to install it. If you wish to install it on OpenBSD, I have written an article detailing how to do so.\nHow does it work? In Fail2ban, there are three interesting components:\nActions. An action allows you to choose what to do when undesirable behaviour is detected. For example, there is an action for iptables, the firewall used on Linux, and another for pf, the OpenBSD firewall. You simply choose the action that suits your system. Filters. A filter is a detection mechanism based on regular expressions. If an IP address is detected by a filter in the logs, it can be blocked. The jail.local configuration file. In this file, you specify which filters to enable, and for each filter, how many times it must detect something before the IP address associated with the logs is blocked, and for how long. A few examples On OpenBSD, the pf command is used to manage the firewall.\nBlock login attempts to OpenSSH Let\u0026rsquo;s imagine I have an OpenSSH server exposed to the internet so I can connect remotely. Looking at the logs, I quickly realise that there are numerous unsuccessful connection attempts coming from all over the world.\nIf I\u0026rsquo;ve set things up correctly, password-based login is disabled, as is logging in as root (the administrator). Furthermore, OpenSSH now includes security features that limit the number of attempts to prevent brute-force attacks (repeated attempts until the password is found).\nDespite all this, it clutters up the logs, and since the IP addresses behind these connection attempts are unwelcome, I prefer to block them. With Fail2ban, it’s very simple:\n# jail.local configuration file [sshd] bantime = 1d bantime.increment = true enabled = true filter = sshd_openbsd findtime = 1h logpath = /var/log/authlog maxretry = 10 The configuration snippet above enables the filter that analyses OpenSSH logs on OpenBSD. If 10 connection attempts are received within 1 hour from the same IP address, that IP address is blocked for 1 day.\nOnce unblocked, if it makes a further 10 attempts within one hour, it will be blocked for 2 days. The next time, for 4 days, and so on.\nLimiting misuse of the contact form There\u0026rsquo;s a contact form on this website. Like everyone else, I hate CAPTCHAs, so I\u0026rsquo;ve decided not to subject my visitors to them. That said, it’s important to protect myself against bots and clever clogs who might try to spam me, so I\u0026rsquo;ve set up my own Fail2ban filter.\n# jail.local configuration file [httpd-abosec-send-contact] bantime = 10d bantime.increment = true enabled = true filter = httpd_forwarded_abosec_contact findtime = 1h logpath = /var/www/logs/access.log maxretry = 10 If the form is submitted 10 times in one hour, the IP address is blocked for 10 days and will no longer be able to access the website at all. If the same IP address attempts to submit the form again once the block has been lifted, it will be blocked for 20 days, and so on. This does not in any way prevent a legitimate visitor who wishes to contact me from doing so, however, it does prevent me from being inundated with emails.\nDo you want to secure your servers but don\u0026rsquo;t have the time to set it all up? Find out more about my OpenBSD security and managed hosting services .\n","permalink":"https://www.abosec.fr/en/blog/fail2ban/","summary":"Fail2ban is one of the security measures I use on my servers to block abuse. In this article, I\u0026rsquo;ll show you what you can do with it.","title":"How to protect your server with Fail2ban"},{"content":"I recently reinstalled OpenBSD on my laptop to start with a clean slate (I\u0026rsquo;ve written an article for anyone who\u0026rsquo;s interested). My setup was perfect: an encrypted drive, black backgrounds and dark themes everywhere in Xenocara (OpenBSD\u0026rsquo;s fork of X), Xenodm, Qt and GTK, i3 as the window manager with all the right keyboard shortcuts, great. After a period of inactivity, my computer locked itself (for security reasons), and I had to type my password twice to unlock the system.\nI was so pleased with my setup, and this tiny bug was spoiling my enjoyment. It was a pebble in my shoe that annoyed me every time the screen locked automatically, I had to sort this problem out.\nSource of the problem Automatic locking works as follows:\nxidle, a program included with Xenocara, receives a message from the X server when there is inactivity and runs a program. In my case, it runs i3lock. i3lock, the lock screen program included with i3, locks the screen until the user enters their password. The command looks like this:\nxidle -timeout 60 -program \u0026#39;/usr/local/bin/i3lock -c 000000\u0026#39; At first, I thought the problem was on my end. I checked to see if xidle was running twice, once in my X configuration and once in i3. I read the xidle documentation in case I\u0026rsquo;d missed something, but I hadn\u0026rsquo;t. On Reddit , someone had the exact same problem, but none of the replies provided a solution. I switched to debug mode.\nI opened a second terminal after the screen locked automatically, and I checked the running processes, i3lock was running twice.\nI launched i3lock manually from my terminal: OK.\nI ran xidle manually: NOK.\nSo the problem was with xidle; i3lock was not to blame. All that was left for me to do was to figure out what xidle was doing wrong. I created a small script that writes the time to a file, and I modified the command so that xidle would call that script, and that\u0026rsquo;s when I figured it out.\nAfter 60 seconds, when xidle called the script, the date was written to the file. And it was written a second time whenever I moved my cursor or pressed a key on my keyboard. There was no doubt about it: it was a bug in xidle.\nThat meant that xidle launched i3lock once after the timeout, and a second time when I started typing my password. That explains why I had to type my password twice.\nI could have simply decided to use an alternative to xidle, such as xss-lock. In fact, that\u0026rsquo;s probably what the people who discussed the problem on Reddit three years ago did. But I didn\u0026rsquo;t.\nInvestigation I downloaded the Xenocara code and looked into how xidle worked.\nAs I continued my research online, I also discovered that FreeBSD had encountered the same problem \u0026hellip; and had fixed it.\nI looked at the patch, which was very simple, and saw that it was fully compatible with Xenocara. I tested it on my computer, and it fixed the problem. It was time to fork Xenocara and submit a patch.\nFork and submit the patch I forked the Xenocara GitHub repository and applied the patch to keep a record of it. Then I followed the same procedure as for my doas patch : I exported the patch to a file and sent an email to the mailing list.\nWhy contribute? You could say I\u0026rsquo;m nitpicking, I could have used a different program and saved time, so why did I take the time to understand and fix the problem?\nBecause I don’t just sell OpenBSD services; I use it every day.\nIt was a minor bug, but it makes my day-to-day life easier and gives me the satisfaction of a job well done. And it\u0026rsquo;s so rewarding to be able to solve problems on your own. That\u0026rsquo;s part of what it means to be an OpenBSD administrator.\nIf you need an expert to audit, migrate, or maintain your servers, check out my services or contact me .\n","permalink":"https://www.abosec.fr/en/blog/openbsd-fix-bug-in-xidle/","summary":"I\u0026rsquo;ve fixed a minor bug in xidle. This bug was getting in my way; I could have used an alternative, but I preferred to fix it.","title":"When a minor bug prompted me to contribute to Xenocara"},{"content":"Linux and macOS users are familiar with sudo, a programme that allows you to run a command as another user, usually root (the administrator). Although sudo can be installed on OpenBSD, doas is used instead, as it is part of the system.\nWhy I wanted to contribute to doas When configuring doas via the /etc/doas.conf file, you can use the \u0026ldquo;persist\u0026rdquo; directive, which means you don\u0026rsquo;t have to re-enter your password for 5 minutes. This way, if you have several commands to enter, you don\u0026rsquo;t have to re-enter your password each time.\nHowever, this 5-minutes timeout cannot be configured; it is a decision made by the OpenBSD team. And this is precisely an issue that comes up from time to time (such as here or there ), as some people would like to be able to choose how long the password is not requested again. Generally, these people would prefer a longer time, such as 15 minutes. Personally, I would prefer a shorter time, so that the password is remembered just long enough to type 2-3 commands, and then forgotten.\nThat\u0026rsquo;s why I decided to delve into the doas code and submit a patch to the OpenBSD team.\nMy doas patch If you simply want to access the patch, it is available on Github .\nThe goal To help you understand the change I have proposed, here is how doas is currently configured ( doas.conf(5) ):\n# /etc/doas.conf # Members of the \u0026#34;wheel\u0026#34; group are authorised to use doas; their password # is stored for 5 minutes using \u0026#34;persist\u0026#34; permit persist :wheel # Newline required after a rule Note: in my article about doas on OpenBSD Desktop , I mentioned that it was required to add a newline (\\n) after each rule so that it is taken into account. Now that I\u0026rsquo;ve studied the parser, as well as knowing it, I understand why.\nThe patch I have developed adds an optional parameter to persist, allowing you to choose how many seconds the password is stored for:\n# /etc/doas.conf permit persist 60 :wheel # Newline required after a rule For 60 seconds, the user is not prompted to re-enter their password; this timeframe is shorter than the current 5 minutes. If the timeframe is not specified in the configuration, the default 5-minutes timeframe is used, meaning that this change is backwards-compatible: it adds a new feature without breaking the existing functionality.\nHow I did it If you are thinking of contributing to OpenBSD, you might find this method of interest.\nOpenBSD uses CVS, but I prefer Git, so I cloned the repository from GitHub: git clone https://github.com/openbsd/src. As stated in the documentation , I have executed the following commands in the Git repository: git config diff.noprefix true and git config diff.renames false. This was useful when generating the diff file. which doas told me that the doas programme is located in the directory /usr/bin, so I\u0026rsquo;ve navigated to the correct folder in the repository : cd usr.bin/doas/. Once in the correct folder, I looked through the various files: doas.1 and doas.conf.5 are man pages, which can be viewed using man doas and man doas.conf. Makefile is the file that make uses to compile doas. make obj creates a subfolder called obj/, after which make compiles doas. env.c contains C code for managing the environment. doas.h and doas.c contain C code, the main() function is located in doas.c and is a good starting point for understanding how the programme works. parser.y is a rather special file, used by yacc . It defines the grammar used by the configuration file doas.conf; to add a configuration option, you need to edit this file. To do this, you\u0026rsquo;ll need to familiarise yourself with yacc, as it\u0026rsquo;s not just C code. After studying the documentation and the code, and making my changes, I generated a diff from the usr.bin/doas directory using the command git diff --relative . \u0026gt; doas-persist-timeout.patch. Finally, after reading the instructions , I sent an email to the mailing list with my patch. The response from the OpenBSD team A few hours after sending my message, I received a reply from Theo, the founder of OpenBSD, he didn\u0026rsquo;t like the idea of making the timeout configurable, and he put forward some good arguments. The 5-minutes timeout was chosen because it is neither too long to cause problems nor too short to be a nuisance, it keeps doas simple, without complicating configuration management.\nA snub? Not at all. Of course I would have liked the patch to be accepted, but the explanation for the rejection makes sense, is consistent, and above all I learnt a great deal by digging into the code. And besides, I still have my patch, nothing stops me from using it even though it was rejected.\nUnderstand the OpenBSD philosophy OpenBSD is a system designed to be simple, having fewer features reduces the attack surface and the number of bugs.\nSecurity is at the heart of everything: every feature added is considered from the perspective of security, risk and the complexity it introduces. A telling example is Bluetooth, which is deliberately not supported by OpenBSD.\nIn line with this focus on security is a commitment to writing correct code, and this is achieved through code reviews. Every patch is reviewed by other developers to identify any issues.\nAdvises to contribute Here are a few tips if you’d like to contribute to OpenBSD:\nRead the documentation. This applies to users too. OpenBSD has excellent documentation: man 1 doas for the doas command, man 5 doas.conf to understand the doas.conf file, as well as man 2 pledge to find out more about the pledge system call, or man 3 getopt to access the documentation for the C function getopt. Communicate via the mailing lists . There are several of them, some for general discussion, others for submitting patches. Accept rejection. Whether on OpenBSD or another open-source project, developers are under no obligation to accept your proposals. That doesn\u0026rsquo;t necessarily mean they\u0026rsquo;re bad, though. Conclusion Contributing to OpenBSD is challenging, but rewarding. Even if the patch is rejected, the learning experience is invaluable, and getting as far as submitting the patch is a victory in itself.\nNeed an OpenBSD expert who knows the system inside out? Let\u0026rsquo;s discuss your project .\n","permalink":"https://www.abosec.fr/en/blog/openbsd-doas-persist-timeout-refused/","summary":"I proposed a change to doas. Although it was rejected by Theo, this experience illustrates the project\u0026rsquo;s philosophy of simplicity and how to contribute to OpenBSD.","title":"doas patch rejected: OpenBSD's philosophy of simplicity"},{"content":"This article focuses on httpd, the Web server. If you\u0026rsquo;re looking for a more comprehensive article that also covers relayd, the reverse proxy, you\u0026rsquo;ll find it on my other blog, OpenBSD Desktop .\nOpenBSD httpd Just to be clear, we are talking here about OpenBSD httpd, not to be confused with Apache httpd, which is generally referred to as Apache. The latter can be installed via pkg, the package manager.\nOpenBSD httpd is a Web server developed by the team behind OpenBSD. For an operating system used primarily on servers, including a Web server is both logical and practical. If required, it can be paired with relayd, the reverse proxy / load balancer included with OpenBSD, which I will cover in a separate article.\nNote: doas is the OpenBSD equivalent of sudo, so when a command is preceded by doas, it is executed as an administrator.\nPHP installation Since we want to run a website written in PHP, let\u0026rsquo;s start by installing it. Simply run:\ndoas pkg_add php and to select the PHP version if several are available. It is also possible to install extensions, for example:\ndoas pkg_add php-pdo_mysql and to enable them:\ndoas ln -s /etc/php-8.5.sample/pdo_mysql.ini /etc/php-8.5/pdo_mysql.ini To check that PHP is installed correctly, type php -v.\nThe Web server uses PHP FPM, which is installed alongside PHP; all you need to do is enable and start the service:\ndoas rcctl enable php85_fpm \u0026amp;\u0026amp; doas rcctl start php85_fpm That\u0026rsquo;s it for PHP; let\u0026rsquo;s move on to httpd.\nStarting the httpd server Before you begin, you should be aware that httpd and PHP FPM are chrooted into /var/www/, which means they cannot see the rest of the system. When they attempt to access the root directory, /, they actually see the contents of /var/www/. This is a security measure: if an attacker exploits a vulnerability in your application (or in httpd) and manages to execute commands, they will not have access to all the files on the server; they will be restricted to /var/www/. You do not need to do anything to enable this; it is already in place by default.\nSince we\u0026rsquo;re going to be using it, let\u0026rsquo;s start the httpd service:\ndoas rcctl enable httpd Let\u0026rsquo;s move on to the configuration, which is located at /etc/httpd.conf.\nFirst, we\u0026rsquo;ll configure it for HTTP, so that we can generate a TLS certificate later.\ntypes { include \u0026#34;/usr/share/misc/mime.types\u0026#34; } # Here we are configuring for HTTP only # We are configuring phpmyadmin.abosec.fr; the DNS configuration must have been # set up beforehand server \u0026#34;phpmyadmin.abosec.fr\u0026#34; { # Listen on the Internet, port 80 listen on egress port 80 # The root is /var/www/htdocs/phpmyadmin/ # Keep in mind that httpd is chrooted in /var/www/ root \u0026#34;/htdocs/phpmyadmin\u0026#34; # To generate Let\u0026#39;s Encrypt (LE) certificates, acme-client generates # files, stored in /var/www/acme/, which are then accessed by # the LE infrastructure. The block below simply states that any URL # resembling http://phpmyadmin.abosec.fr/.well-known/acme-challenge/\u0026lt;file\u0026gt; # looks for \u0026lt;file\u0026gt; in the /var/www/acme directory, referred to as /acme # because httpd is chrooted into /var/www/. location \u0026#34;/.well-known/acme-challenge/*\u0026#34; { root \u0026#34;/acme\u0026#34; request strip 2 } } We (re)start httpd with\ndoas rcctl -d restart httpd We are ready to generate the TLS certificate.\nGenerating the TLS certificate Note: It is important to check that the /var/www/acme/ directory is readable by httpd. Simply create a file called /var/www/acme/test.txt containing \u0026rsquo;test\u0026rsquo; and access the URL \u0026lsquo; http://phpmyadmin.abosec.fr/.well-known/acme-challenge/test.txt' . If you cannot see \u0026ldquo;test\u0026rdquo;, adjust the folder permissions.\nNext, configure acme-client in the /etc/acme-client.conf file. acme-client allows you to generate and regenerate certificates using the ACME protocol. On Linux, certbot is often used for this purpose.\n# We define a certificate authority, in this case Let\u0026#39;s Encrypt authority letsencrypt { api url \u0026#34;https://acme-v02.api.letsencrypt.org/directory\u0026#34; account key \u0026#34;/etc/acme/letsencrypt-privkey.pem\u0026#34; } # Here we define the Let\u0026#39;s Encrypt test server # This may be useful for checking that our installation is working before # moving to production authority letsencrypt-staging { api url \u0026#34;https://acme-staging-v02.api.letsencrypt.org/directory\u0026#34; account key \u0026#34;/etc/acme/letsencrypt-staging-privkey.pem\u0026#34; } domain phpmyadmin.abosec.fr { # When you want to include several domains in a certificate, # for example the www subdomain, you use \u0026#39;alternative names\u0026#39; #alternative names { www.phpmyadmin.abosec.fr } domain key \u0026#34;/etc/ssl/private/phpmyadmin.abosec.fr.key\u0026#34; domain full chain certificate \u0026#34;/etc/ssl/phpmyadmin.abosec.fr.fullchain.pem\u0026#34; # We choose the certification authority to use sign with letsencrypt } Once configured, simply run\ndoas acme-client phpmyadmin.abosec.fr We can then run it as a cron job to renew the certificate automatically.\nIf everything went well, we can amend the httpd configuration to run over HTTPS.\nhttpd configuration Back in /etc/httpd.conf, we adjust the configuration so that the site redirects from HTTP to HTTPS.\n# Here we configure it for HTTPS only # This is the main site server \u0026#34;phpmyadmin.abosec.fr\u0026#34; { listen on egress port 443 # The keys are loaded when the server boots, before the chroot is applied tls { certificate \u0026#34;/etc/ssl/phpmyadmin.abosec.fr.fullchain.pem\u0026#34; key \u0026#34;/etc/ssl/private/phpmyadmin.abosec.fr.key\u0026#34; } root \u0026#34;/htdocs/phpmyadmin\u0026#34; location \u0026#34;*.php\u0026#34; { # Optional: basic authentication to prevent bots from scanning phpMyAdmin #authenticate with \u0026#34;/auth-files/phpmyadmin\u0026#34; # Everything ending with .php is handled by PHP fastcgi socket \u0026#34;/run/php-fpm.sock\u0026#34; } # ACME is now handled via HTTPS location \u0026#34;/.well-known/acme-challenge/*\u0026#34; { root \u0026#34;/acme\u0026#34; request strip 2 } } # He we configure it for HTTP only server \u0026#34;phpmyadmin.abosec.fr\u0026#34; { listen on egress port 80 root \u0026#34;/htdocs/phpmyadmin\u0026#34; # We redirect to the requested page, on HTTPS block return 301 \u0026#34;https://phpmyadmin.abosec.fr$REQUEST_URI\u0026#34;\t} We restart again httpd with\ndoas rcctl -d restart httpd And there we go, the Web app is now available.\nReady to put your server into production? Find out how I can migrate and host your OpenBSD infrastructure , or let\u0026rsquo;s discuss it directly .\n","permalink":"https://www.abosec.fr/en/blog/openbsd-httpd/","summary":"OpenBSD comes with a Web server called httpd. In this article, I\u0026rsquo;ll show you how to run a website using httpd, PHP and TLS.","title":"httpd, the Web server included with OpenBSD"},{"content":"We\u0026rsquo;ll start off gently with this article, which aims to clarify a few terms. It\u0026rsquo;s not very technical, then, but it\u0026rsquo;s important to understand what we\u0026rsquo;ll be discussing in the next few articles.\nLinux If there\u0026rsquo;s one misnomer we all use, it\u0026rsquo;s saying that Linux is an operating system. When we list the most widely used operating systems, we actually talk about Linux, macOS and Windows.\nIn fact, Linux is an operating system kernel, a part of the system, but not the complete system. It is largely based on Unix, a proprietary operating system developed by AT\u0026amp;T in the late 1960s. To put it simply, one could say that an operating system is divided into two main parts:\nThe kernel, which is responsible for running the hardware (the screen, the graphics card, etc.) and exposing APIs to userland. Its code is executed with the highest privileges; for example, it can access all of the memory. Userland, which comprises all the programmes and libraries that are not part of the kernel. Here, privileges are more restricted; for example, one programme cannot access the memory of another. Linux is therefore a kernel, and without a userland it is of little use. To create a complete operating system, it is combined with a userland, such as GNU or BusyBox; this is why purists say they use a GNU/Linux distribution, rather than simply Linux.\nA Linux distribution is, quite simply, an operating system that uses Linux. Anyone with the necessary skills can create their own distribution, including their preferred software (such as OpenRC instead of systemd, for example), so there are many distributions . Some are designed for computers, others are better suited to servers, and others still are specifically designed for connected devices, routers, etc.\nSome well-known distributions are:\nDebian, Ubuntu, Linux Mint, Fedora, Void Linux, Pop!_OS, Manjaro, Arch Linux, Red Hat Enterprise Linux, which use GNU as their userland. Alpine Linux, OpenWRT, Android, which use BusyBox as their userland. Some distributions are based on others; for example, Linux Mint is a fork of Ubuntu, which is a fork of Debian. Each distribution makes its own choices, for example regarding the package manager. Some distributions use apt, whilst others prefer dnf, pacman, etc.\nYou therefore need to choose a distribution suited to your needs (laptop, server, router), which regularly applies security patches for all third-party software included in the system, and which does not break software compatibility with every update. If PHP is unexpectedly updated from version 8.0 to 8.4, the Web applications hosted on the server could stop working.\nOpenBSD OpenBSD is much simpler than Linux; for a start, it is a full-fledged operating system, not just a kernel. This means there is no need to choose a package manager, here we use pkg. OpenBSD uses traditional init, a lightweight alternative to systemd, thereby avoiding the complexity of a centralised daemon.\nBSD stands for Berkeley Software Distribution. In the late 1970s, the University of Berkeley developed BSD, an operating system derived from Unix. The short version is that BSD was forked, giving rise to several operating systems, including NetBSD and FreeBSD . These two systems were themselves forked, giving rise to OpenBSD and macOS.\nAlthough BSDs attract less attention than Linux distributions, they are nevertheless valued for their reliability, robustness and permissive licences: Netflix uses FreeBSD on its servers, and PlayStation uses it on its games consoles.\nEach BSD has its own priorities, much like Linux distributions. NetBSD makes it a point of honour to run everywhere, on all processors, even the most obscure ones. It has, in fact, been ported to a toaster . FreeBSD is primarily interested in \u0026ldquo;traditional\u0026rdquo; processors such as those found on modern computers or servers, and focuses on performance. OpenBSD has one thing in mind: security. All BSDs take security seriously, but OpenBSD is truly proactive on the subject.\nOpenBSD is therefore an operating system that values simplicity, well-written documentation, and security. It is particularly well-suited to servers, and as it is a complete system, it is consistent throughout, particularly in the syntax of its configuration. The system comes with a built-in firewall (pf), a Web server (httpd) and a load balancer (relayd), and as these are part of the system, they all utilise the security mechanisms it provides (chroot, pledge, unveil, etc). I will go into more detail about these mechanisms in another article.\nThe OpenBSD team also develops OpenSSH , which is so essential that it is also installed on most Linux distributions.\nCurious to find out how I migrate servers? Check out my migration service .\nIf you\u0026rsquo;re interested in OpenBSD, I also have a blog dedicated to this operating system: openbsd-desktop.rocks ","permalink":"https://www.abosec.fr/en/blog/openbsd-linux/","summary":"We talk about Linux and OpenBSD, distributions and GNU, but we rarely explain what they actually are. Here, I\u0026rsquo;ll introduce you to these operating systems and the terms associated with them.","title":"OpenBSD, Linux, what is the difference?"},{"content":"Your OVH server is in good hands Are you an OVH customer whose server requires special attention? Whether it\u0026rsquo;s a security audit, hardening, migration, or routine maintenance, I\u0026rsquo;m here to help.\nWhy choose Abosec ? I know your environment I don\u0026rsquo;t need to familiarize myself with your infrastructure. I\u0026rsquo;m familiar with OVH\u0026rsquo;s dedicated servers, VPS, and Kimsufi. I know how to configure the firewall, how to secure SSH, and how to enable TLS correctly.\nGenuine technical expertise 10 years in software development and cybersecurity, 3 years working with OpenBSD in production. I don\u0026rsquo;t sell generic packages; I deliver concrete solutions.\nMy offerings for OVH customers Server Security Audit From 800€ excl. tax | 1-2 days\nComprehensive analysis of your exposed OVH infrastructure: open ports, versions, SSH configurations, firewalls, TLS, and backups.\nDelivered: PDF report with priority risks and a corrective action plan.\n→ Find out more Linux hardening From 1000€ excl. tax | 1-3 days\nIs your Linux server (Ubuntu, Debian) not secure by default? I will configure:\nFirewall (iptables/nftables or pf) Hardened SSH (keys, 2FA, algorithms) Monitoring and alerts (logging) Intrusion Prevention System (fail2ban) Delivered : documentation of modifications.\n→ Find out more Migration to OpenBSD From 1500€ excl. tax | 3-7 days\nAre your Linux servers a risk you can no longer control? Migrating to OpenBSD drastically reduces your attack surface.\nI provide:\nApplication compatibility analysis Data and configuration migration Configuration of firewall, Web server, reverse proxy, TLS Rollback plan if necessary Guarantee : 3 months of post-migration support included.\n→ Find out more Managed OpenBSD Hosting From 500€ excl. tax / month | Commitment 12 months\nTired of managing your infrastructure? I provide OpenBSD servers that are configured, monitored, and backed up. You can focus on your core business.\nSolo Plan: 3 sites, 1 server (€500/month) Pro Plan: 10 sites, 3 servers (€1,200/month) Enterprise Plan: unlimited, HA, SLA (€2,000/month) → View hosting packages Ongoing Maintenance \u0026amp; Support From 500€ excl. tax / month\nDo you already have a server? I\u0026rsquo;ll take care of it: security updates, troubleshooting, and monthly reports.\nPackage Services SLA Monthly pricing Essential 1 day / month 48h From 500€ excl. tax Standard 2 days / month 24h From 900€ excl. tax Premium 5 days / month 4h From 2200€ excl. tax → Find out more How I Work Contact — You explain your needs to me (30 minutes, no obligation) Assessment — I analyze your current situation Proposal — You receive a clear quote with scope and timelines Execution — Project work with weekly updates Delivery — Code/configuration, documentation, and post-delivery support Ready to secure your OVH infrastructure? Contact me now for a free 30-minute consultation.\nGuaranteed response within 24 hours. No sales pitch—just an honest technical discussion.\n","permalink":"https://www.abosec.fr/en/partners/ovh/","summary":"\u003ch1 id=\"your-ovh-server-is-in-good-hands\"\u003eYour OVH server is in good hands\u003c/h1\u003e\n\u003cp\u003eAre you an OVH customer whose server requires special attention?\nWhether it\u0026rsquo;s a security audit, hardening, migration, or routine maintenance,\nI\u0026rsquo;m here to help.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"why-choose-abosec-\"\u003eWhy choose Abosec ?\u003c/h2\u003e\n\u003ch3 id=\"i-know-your-environment\"\u003eI know your environment\u003c/h3\u003e\n\u003cp\u003eI don\u0026rsquo;t need to familiarize myself with your infrastructure. I\u0026rsquo;m familiar with\n\u003cstrong\u003eOVH\u0026rsquo;s dedicated servers, VPS, and Kimsufi\u003c/strong\u003e. I know how to configure\nthe firewall, how to secure SSH, and how to enable TLS correctly.\u003c/p\u003e","title":"Expert Partner – OVH Customers"}]