Hello there,
Containerized applications, secret vaults, and deployment scripts — all of these improve the cybersecurity of your web application or service listening to http ports (80/443).
Let me show you a basic example of why and how it’s important to develop the habit of using these tools to avoid potential pitfalls, such as those that recently affected Andrew Tate’s money-making machine:
Check out this Nginx log from one of my servers, which shows an example of a bot scanning to discover vulnerabilities. Notice the lines with .env
. Another popular example is looking for the .git
directory or any other misconfigured or exposed data that could provide intruders with information about your web server:
nginx-1 | 63.135.161.75 - - [19/Nov/2024:22:51:10 +0000] "GET /www/.env HTTP/1.1" 404 555 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36"
nginx-1 | 2024/11/19 22:51:10 [error] 22#22: *35 open() "/etc/nginx/html/www/.env" failed (2: No such file or directory), client: 63.135.161.75, server: api.foodintake.space, request: "GET /www/.env HTTP/1.1", host: "<host-ip>"
nginx-1 | 2024/11/19 22:51:10 [info] 22#22: *35 client 63.135.161.75 closed keepalive connection
nginx-1 | 63.135.161.50 - - [19/Nov/2024:22:51:10 +0000] "GET /sites/all/libraries/mailchimp/.env HTTP/1.1" 404 555 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36"
nginx-1 | 2024/11/19 22:51:10 [error] 22#22: *36 open() "/etc/nginx/html/sites/all/libraries/mailchimp/.env" failed (2: No such file or directory), client: 63.135.161.50, server: api.foodintake.space, request: "GET /sites/all/libraries/mailchimp/.env HTTP/1.1", host: "<host-ip>"
nginx-1 | 2024/11/19 22:51:11 [info] 22#22: *36 client 63.135.161.50 closed keepalive connection
nginx-1 | 104.234.53.219 - - [19/Nov/2024:22:51:11 +0000] "GET /database/.env HTTP/1.1" 404 555 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36"
nginx-1 | 2024/11/19 22:51:11 [error] 22#22: *37 open() "/etc/nginx/html/database/.env" failed (2: No such file or directory), client: 104.234.53.219, server: api.foodintake.space, request: "GET /database/.env HTTP/1.1", host: "<host-ip>"
nginx-1 | 2024/11/19 22:51:11 [info] 22#22: *37 client 104.234.53.219 closed keepalive connection
nginx-1 | 63.135.161.58 - - [19/Nov/2024:22:51:11 +0000] "GET /public/.env HTTP/1.1" 404 555 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36"
nginx-1 | 2024/11/19 22:51:11 [error] 22#22: *38 open() "/etc/nginx/html/public/.env" failed (2: No such file or directory), client: 63.135.161.58, server: api.foodintake.space, request: "GET /public/.env HTTP/1.1", host: "<host-ip>"
Some of the Tools Used by Script Kiddies Link to heading
There are a lot of tools out there for making such network scans, one of the most sophisticated universal tool is NMAP scanner which has such option among various others:
Nmap Scripting Engine (NSE), provides pre-written scripts to probe specific vulnerabilities or configurations.
• Examples:
• http-enum
: Detects common files and directories (like .env).
• http-config-backup
: Searches for configuration files or backups.
• http-headers
: Checks HTTP headers for security misconfigurations.
• http-vuln-cve2017-5638
(specific to Apache Struts)
nmap --script http-enum <target>
Another tool is dirbuster, which essentially performs one main task: brute-forcing server directories using predefined lists of lookup paths.
Dirbusting tools send a series of HTTP requests to a target server using predefined or custom wordlists.
For this to work, the server must have an HTTP(S) service running and responding to requests.
I know, I know… we all want to deliver and ship software quickly, and start reaping the rewards of our hard work as soon as possible. But what are the easiest and quickest ways to deal with such parasites?
You may ask how to prevent myself from such mistakes? Link to heading
The easiest but not very reliable way is to limit access to sensitive directories and files using Nginx configuration (the same applies to HTTP if you don’t redirect your traffic to HTTPS).
server {
listen 443;
server_name your_domain_or_ip;
# Block access to .env files
location ~* \.env$ {
deny all;
return 404;
}
# Block access to .git folders
location ~ /\.git {
deny all;
return 404;
}
}
Another approach is to use deployment scripts to distribute a web application onto server machines instead of cloning the entire repository, or to containerize it using a virtualization and isolated environment handler like Docker
(more about this in upcoming articles). Additionally, using secret vaults instead of environment variables enhances security, whether the application is containerized or not.
More sophisticated, enterprise-grade platforms or orchestration systems like Kubernetes
or Docker Swarm
simplify the integration and management of such vaults and secrets. As a Certified Kubernetes Administrator (CKA)
, I’ll share more about them in future posts.
Sanity checks Link to heading
At the end I want to show you one brilliant FREE cyber security tool for scanning your web app on vunerabilities. This is something which should be treated as washing hands before eating:
Find more in their official presentation What is ZAP?
Cloudflare Link to heading
Another approach is to block such harmful bot activities which might eats up your resources dedicated for a real users is by using edge server WAF rules or rate limitting
Though you may challenge such failed requests with captcha or dynamic analysis be careful not to harm overall user experience with excessive or too strict rules.
Cloudflare for 20$ has managed rules protection which is constantly updated and makes your website adaptable to changed attacks and methods, see here for more details in their blog and changes of rules updates
Blocklists and ip bouncers Link to heading
Another interesting solution are ip blocklists provided by companies like malware url which is constantly updating. And this is one of the problems of the blocklists as yesterday harmfuls ips may be legit customers today. So the better option is some dynamic adaptive tools like Cloudflare managed rules or Crowdsec.
Crowdsec is an open-source, lightweight software, detecting peers with aggressive behaviors to prevent them from accessing your systems. Its user-friendly design and assistance offer a low technical barrier of entry and nevertheless a high security gain. Bouncers block request from ips which are in theirs blocklists, the lists are constantly updated and changed to avoid blockings of non-harmful requests from legit customers.