Django URL's security

There is something I see when analyzing the logs of my Django application. Do these things indicate that someone is looking for a vulnerability?

Not Found: /index.asp
Not Found: /index.asp
Not Found: /index.asp
Not Found: /index.asp
Not Found: /FXhV
Not Found: /FXhV
Not Found: /YtJF
Not Found: /YtJF
Not Found: /aab8
Not Found: /aab8
Not Found: /jquery-3.3.1.slim.min.js
Not Found: /jquery-3.3.1.slim.min.js
Not Found: /aab9
Not Found: /aab9
Not Found: /jquery-3.3.2.slim.min.js
Not Found: /jquery-3.3.2.slim.min.js
Not Found: /jquery-3.3.2.slim.min.js
Not Found: /jquery-3.3.2.slim.min.js
Not Found: /jquery-3.3.2.slim.min.js
Not Found: /jquery-3.3.2.slim.min.js
Not Found: /jquery-3.3.2.slim.min.js

How does Django handle these situations?

Yes, and if that’s all you’re seeing, consider yourself lucky.

Django handles them just fine. It returns a 404.

But it’s not someone specifically looking for your site. They’re bots, searching the internet, looking for any host that responds. And there are thousands of them running at any given point in time. (Tens of thousands? Millions? Who knows?)

I run a very low-usage personal hobby website. There’s probably about 100 or so different periodic visitors.

Even with running fail2ban, probably 90% of all individual requests are scripts testing for known vulnerabilities. There are even 2 complete class-B subnets that I have blocked at the firewall.

So is there anything extra I need to do? fail2ban is not a installed. I’ll start with that first

I only have ufw, which I use extra because the app serves a limited number of users in a limited way

I didn’t make any extra settings even on Nginx. I only have cerbot settings for Https as an extra

You don’t need to do anything. Like I said, Django handles the 404 quite well by itself. (Warning - tuning fail2ban to trap these types of scans can be a time-consuming operation. It is not configured to look for the most common attacks out-of-the-box - and those scans are constantly changing.)

But I do a number of different things to reduce the number of bad requests being passed through to Django. Probably the most significant one is that I don’t run applications off the root url. Everything runs off of a sub url. That allows me to configure nginx to send a 404 (or some other response) to virtually all the undesirable requests.

I go well beyond the effort of what my site would justify because staying on top of these types of things is part of my job. I need to know what sort of attacks and attempted exploits are being seen in the wild to be able to advise my employer and our clients.

Very little of what I do would be considered necessary for probably 80% of all websites.

(I also use ufw. The ufw block from allows you to specify subnets and not just individual addresses.)

Is what you are saying like a user accessing the site is redirected to the /login page for the login process?

After the login process, it already redirects to other url addresses

What I’m saying is that there wouldn’t be a url “/login”. It’s going to be something like “/this-app/login”. Other urls are going to be “/this-app/profile/” or “/this-app/display/” or even “/this-app/home/”

Only those urls that start with “/this-app” get forwarded to Django. (We use FORCE_SCRIPT_NAME for this along with the corresponding settings for uwsgi.)

Actually, this turned out to be a beneficial side effect. We originally started doing this to make it easier to deploy multiple Django projects under the same nginx instance. It wasn’t until later we realized this also reduces the amount of traffic being handled by Django by scanners.

1 Like

Sir, the more questions I ask you, the more I want to learn.

Thank you very much for your attention