Hacker News new | past | comments | ask | show | jobs | submit login
Analyzing the attacks on my website (dev.to)
104 points by JeremyMorgan on Feb 8, 2020 | hide | past | favorite | 59 comments



That's so interesting. I built literally the exact same thing the other weekend.

I took all of the data and fed it into a database, then built a web interface so I could see the data better.

It's looking like this:

https://i.imgur.com/8G9GAUp.png

Lots more activity from France than I would have expected compared to other countries. Also lots more people using Amazon's infrastructure to scan the internet than I would have imagined.

Other than that it's about what you'd expect.

So far I don't find this to be overly practical because with the amount of IP addresses in the filter, the firewall takes forever to reload. (firewalld)


You can use ipset to block them. It's hash based and efficient.

http://ipset.netfilter.org/

http://mikhailian.mova.org/node/194


>Lots more activity from France than I would have expected compared to other countries

My guess would be the all the cheap server providers there eg. ovh, online.net/scaleway,


Awesome, that really looks nice! I'm hoping to build some sort of auto-generated HTML page on my site just for fun. Yours looks great.


Funny, because the first thing I thought was how frustrating it was to read. The %s are not sorted by size in the pie chart, and they're not labelled other than by colour, so you can't read the % for each country.

The attempts per hour seems to cover more than 24 hours, but the dates aren't labelled. An aggregate chart bucketed by hour of day would be more interesting, since the actual rate is quite low and has a lot of variance - at this zoom level, it's basically noise.

I agree it looks pretty, though I'd take a table with some bar chart columns.


The charts are interactive, you can hover each slice to get names and percentages, or each name to find it on the chart.

I found it wasn't really worth doing more with the chart, since its purpose was really just comparing the largest offenders.

Regarding the time frames, the buttons in the top right allow choosing the time frame. today, yesterday, 48 hours, week, month, year.

I also slapped this together in half a day.. there is plenty of room for improvement, and more charts and options could easily be added.

I didn't take this very far because this was not my goal, it was just a quick idea to allow me to block others from being able to query my server while still allowing me access from anywhere in the world. The visualizations were just for fun.


I made just this for my pet project https://rankfirst.me/ipban.html I'm using ipban and ipgeo.


Mmmm... I'm a bit surprised by France: 3rd country but... first french town is 29th (Lyon, only the 3rd city of the country) and no french subdivision in the top 40 ?????

Maybe some cross-checking would be welcomed, because it doesn't seem really consistent. Any explaination ?


probably because of ovh

but be warned that such attribution attempts are utterly useless in the end.


Hey, Would you mind to share the code? Would really appreciate it!


I can give you the basics.

Parse your log files. If condition met, insert a line into your database.

Add extra details with a reverse DNS lookup, and IP location check.

I'm using: https://www.geoplugin.com/ at the moment, but feel like there are probably better alternatives.

I then move the data to another log file with a similar name and date so it doesn't get parsed twice, but I keep the data.

Then just make a page to pull the data out of the database.

This is probably what you are looking for:

https://developers.google.com/chart/interactive/docs/gallery

Just do a loop and feed the values into the chart data.


So, a couple of random people are trying standard passwords. That should be a complete non-issue, if your system is correctly configured. Now you want to stop the users and your response is to block "their" IP completely. Which turned the non-issue into self-made denial of service "attack". As those ips are not bound to users and "they" will potentially come from the whole ip space script-kiddies can come from.


Another useful classification is to get the ASN and CIDR block the attacks are coming from, allowing broader blocks or rate-limiting from high-noise / high-attack network space.

The Routeviews project (https://www.routeviews.org/) provides a reverse-lookup which returns ASN and CIDR for a given IP. For example:

    $ host -t txt 240.230.216.209.asn.routeviews.org
    240.230.216.209.asn.routeviews.org descriptive text "21581" "209.216.230.0" "24"
That's the ASN (AS21581 -- M5HOSTING / M5 Computer Security) and CIDR block (209.216.230.0/24) for news.ycombinator.com, a/k/a 209.216.230.240.

What I've frequently found is that hostile traffic is fairly highly concentrated among bad-actor space, often datacentres with little reason to be generating end-user traffic or HTTP requests. Though that includes a surprisingly large quantity of web crawlers (few of which belong to any organisations you've heard of).


And for those individuals (or organisations) making heavy use of the resource, the zonefiles are downloadable, for local query capabilities / reduced latency.


You may have accidentally reinvented https://en.wikipedia.org/wiki/Fail2ban :)


That wasn't really the point of the article, I'm showing how to gather data on where they came from. Blocking is completely optional, and not for everyone.


fail2ban is saving my bacon right now.


From what? Generally fail2ban only exposes unnecessary attack surface while providing zero benefit.


How does fail2ban expose attack surface?


It's code running on partially attacker-controlled inputs. It several times had vulnerabilities that allowed an attacker to trigger blocks for arbitrary IPs.


I remember there's a privEsc on old versions of fail2ban.


Do you remember roughly when the privEsc was?

https://www.cvedetails.com/vulnerability-list/vendor_id-5567...


Sketchy parsers operating on untrusted, unstructured log data.

fail2ban is worse than useless.


Brute force attempts in servers are pretty old news. If you're running a public facing ssh server, it will be found and it will be tried. My solution is to disable passwords and put the server on a non-standard port (yeah, users could try to crash sshd and steal its port, but then my ssh client will complain about a key mismatch; if my servers actually had other users I'd probably consider using iptables to forward all incoming traffic on port 12345 to 22 instead, and drop other non-forwarded traffic on 22).

If you don't trust your users to have strong passwords and are forced to allow passwords, use fail2ban.

Edit: With the prominent pluralsight ads this link feels like an ad overall.


Interesting - I use Wordfence on my wordpress sites. Gives me output like this for past 30 days.

IP Country Block Count 185.81.157.109 France 81 39.100.156.143 China 77 188.163.104.67 Ukraine 32 54.176.188.51 United States 31

Whats interesting is that some are coming from other compromised WordPress sites, which are for dental offices, medical offices, etc. A lot are from tor exit nodes. Its amazing that many don't realize their servers have been compromised and used for nefarious purposes.


I would bet that these attacks are coming through Tor, and the country distribution is just the distribution of Tor exit nodes.


I wondered about that same thing. Obviously the "where the attacks came from" portion will never be 100% accurate.


If you are interested, Tor keeps a list of exit nodes you could compare against. I'd be curious to see how many are exit nodes.

https://check.torproject.org/exit-addresses


... or just some servers compromised by a malware, used as a proxy


I disable password authentication for ssh, so I tend to rarely look at these extremely commonplace attempts.

Obviously best thing is to also lock ssh access down to a jump host or two, but that’s not always feasible.


Or Just use fail2ban + moving your services to a non-standard higher port without even "dealing" with an attack in the first place.


I generally don't "deal" with them anyway, these are failed attempts. I put the "block" in there in case readers were wondering how to block the IPs if they want to.


> But I want to see how many attacks from each continent. So I call on my old friend awk for that

I don't understand what awk is accomplishing here. To get the count, just use uniq -c which you are doing (tip, you can also do a sort -rn after that)

the awk command looks like a noop to me, if you've only got the continents in the file


Nice. I actually built something very similar a few years ago. Instead of using Maxmind to check the IP to find the country of origin and some other information, I used Shodan.io.

Nice dashboard tho, that's a good idea. I made my data into an html map that you could save.

https://github.com/JLDevOps/Authr


That is pretty awesome! Thank you for sharing.


Using ipsets (hash table type thing) is much more efficient then iptables rules, especially if you use entire ip blocks


I used to work for an Australian h/w and s/w company that manufactures in South Korea. Our office was attacked within 10 minutes of going online from ip addresses allocated to China.

Thanks to OpenNMS, nfsen and nfsight. Great programs.


Blindly blocking IP addresses seems like a bad idea; how many are DHCP'ed residential addresses with a short lease?


Isn’t this the concept of the fail2ban software used on almost every linux server?


With a essential difference, the ban is time limited.


fail2ban is typically set to block IPs for a limited amount of time only (and not really used on "almost every" linux server)


I have some personal services that I frankly don't expect or want many outsiders, and it's extremely unlikely they'd come from China so I just blacklist a chunk of IPs.


Does anyone do short leases anymore? My cablemodem is technically assigned by DHCP, but it hasn't changed in years.


Widely varies in provider. I’ve had providers who, for a business customer no less, had incredibly short-lived DHCP leases. Presumably to help motivate the business customer to pay them for a Static IP.


Yes, DSL and mobile broadband.


Use fail2ban :]


Anyone can think of a particular reason as to why his website is being targeted by the Chinese?


It's not targeted and has nothing to do with the box running a web server. These brute force login attempts starts only minutes after you put a new server with SSH exposed online.

Using default passwords and usernames like: admin, support, user, user2, student2, gitlab, git, postgres, cisco, root, ts3user, deploy, vagrant, jenkins, ftptest, 224, 130, dbadmin, sinusbot, mc, daniel, weblogic, guest, redmine, teamspeak, etc.

Checked a random box, lastb | wc -l shows 38k attempts since Feb 1.


Why wouldn’t it be? These scripts attack every site, all day every day. Not a minute goes by without someone (or some bot) attempting some sort of attack on my website.


I don't think my site is being "targeted" more than any other in my ip range. This is all automated stuff that gets dumped off anyway.


But why would these attacks be in your logs to begin with? Who leaves authentication open to the internet at all? I'm more concerned about the failure to minimize attack surface. This is security 101.


Because I need to log in from the internet?


What's the point of a shell host if I can't log in to it?


SSH doesn't have to be exposed to the Internet, use VPN.


Doesn’t that just move the problem?


Well, no. As evidenced SSH is a very exposed surface that is commonly brute-force attacked. A VPN is less exposed, less commonly attacked, it offers much more control of authorization (clients, devices, 2fa) and monitoring. And, now your server might not even need a public IP. It is with good reason companies have used this method as standard practice for decades for remote access.

Besides, for many use-cases, SSH is not the only service you need to access remotely.


VPN, or any other network segmentation does, indeed, just shift the attack surface, and often creates a false sense of security behind a network perimeter.

Google, for example, proposes a different school of thought – zero trust network, and strong contextual authentication of each individual request.

Precisely because you need to expose more services to more users, you need to be extremely conscious about treating singular network ingress point as a primary security gateway.

Check out https://beyondcorp.com, it’s a very interesting concept.


... or Splunk


maybe you should simple add whitelist nftables ssh port 22 you ips




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: