[HN Gopher] Visualizing malicious IP addresses
___________________________________________________________________
Visualizing malicious IP addresses
Author : Bromeo
Score : 140 points
Date : 2024-04-25 23:32 UTC (23 hours ago)
(HTM) web link (romeov.github.io)
(TXT) w3m dump (romeov.github.io)
| wsintra2022 wrote:
| Interesting, if it's an issue you could try port knocking to
| prevent the constant attempts
| IAmGraydon wrote:
| Anyone who has run an SSH server on the default port knows that
| you'll get hundreds or thousands of login attempts per day.
| Changing the port to something less obvious and running
| fail2ban is enough to mitigate most of it. They're just looking
| for low hanging fruit.
| PhilipRoman wrote:
| Changing the default port - yeah, works wonders for reducing
| noise. But I don't understand why people run fail2ban. Nobody
| is going to be brute forcing a ssh login, all it does is add
| another moving part very close to a security boundary for
| very little gain.
| gnabgib wrote:
| Have you recently run a server? It takes a week-month
| before your ssh port is published on
| shodan/binaryedge/censys/criminalIP and other dodgy
| scanners.. and then you can expect constant attention, and
| yes.. 14691 attempted logins for every username possible
| (even though password login is turned off) from the same IP
| (usually a VPN, tor exit, or "crowdsourced VPN")
| tetris11 wrote:
| Yes they do. I had a colleague who opened up his machine to
| another using the logon "remote" and let them set the
| password.
|
| It was cracked the next day. It turns out having 12345678
| is probably a bad password.
| KomoD wrote:
| > Nobody is going to be brute forcing a ssh login
|
| Uh what? Yes people do...
| chx wrote:
| I just run sslh...
| mcoliver wrote:
| Fun. You could also try putting the data into Google's data
| studio (now looker) to visualize them in an interactive map you
| can publish. Add things like size of dot corresponding to number
| of attempts, add reverse DNS/whois info to the info bubble, etc.
| Wonder how much came from residential vs business ip space.
|
| https://lookerstudio.google.com
| noah_buddy wrote:
| If he published that, people will try and make the new
| leaderboard.
| mianos wrote:
| I always wondered how the IPs like this 180.101.88.232 from this
| block:
|
| ISP ChinaNet Jiangsu Province Network Domain Name
| chinatelecom.com.cn
|
| Continue to be the source of thousands of ssh password login
| attempts for years and years on end.
|
| It's not a big deal, I use a tarpit on all ssh with 2FA on the
| one I use, but it seems ridiculous that some participants of the
| internet don't give a shit about the rest of the world.
| dools wrote:
| Some participants in the world don't give a shit about the rest
| of the world
| Gathering6678 wrote:
| Or, it could mean there are a lot more devices in some places,
| and a lot of them may be vulnerable to becoming / are a part of
| botnets?
| userbinator wrote:
| Those probably belong to a CGNAT with many machines behind it.
| mianos wrote:
| Yes, I assumed it is an exit point of the great firewall or
| something like that, but they do so much packet inspection,
| they could easily block them. It's not like it's hard to see
| them.
| kube-system wrote:
| The Great Firewall is about blocking Chinese citizens from
| accessing content the party doesn't find palatable. Being a
| good neighbor to the rest of the world is out of scope for
| that project.
| lithiumii wrote:
| If it's an ISP, maybe it's their crappy modems now part of a
| botnet.
| jkrejcha wrote:
| >180.101.88.232
|
| Amusingly I recognize those IPs by that specific prefix as
| well, basically that entire /24 (at the very least) appears to
| be an absolutely _massive_ source of the SSH login attempts.
|
| Small world, I guess
| dotancohen wrote:
| > I use a tarpit on all ssh
|
| I would love to hear more about your approach, if that's not
| sensitive. My Gmail username is the same as my HN username if
| you prefer. Thank you!
| mianos wrote:
| I run an N100 with LXD so I have a container running one of
| the many ssh tar pits and point 22 and a bunch other ports to
| it. It simulates an ssh login that very slowly sends ssh
| banner lines in the connection protocol, endlessly, until
| they disconnect.
|
| It commonly thought that they do nothing, but they seem to
| keep TCP connections open for quite a long time. A assume a
| hand written scanning client could detect and mitigate the
| delay but it's going to hold open the sessions on the
| firewall exit on the other side. If there are enough of these
| maybe someone might do something.
|
| Makes me smile when I look at the logs, that's enough for me.
|
| It's been covered quite a bit here on HN.
| dotancohen wrote:
| Thanks. Yes, I have heard of such an approach, I did not
| know that it is called a tarpit. I just googled the idea
| and found Endlessh, I'll try it. Thank you.
| iforgotpassword wrote:
| It's not illegal to try to log in to an ssh server. Or many.
| Apart from that I think the map from the article is mostly
| matching the number of internet-connected devices per
| country/region. So I think you can replace "some" by "almost
| all" in your statement. I mean, find a vulnerable iot device,
| use it for scanning/botnet.
| chgs wrote:
| In what country? I suspect that given the intentions it would
| be a breach of the U.K. computer misuse act for example.
| Holding the perpetrator to the law is another matter of
| course.
| iforgotpassword wrote:
| > given the intentions
|
| Exactly. If I just nilly willy connect to your server, try
| a password and it works and I immediately disconnect, will
| that get me in trouble in the UK? That would be worrying.
| chx wrote:
| 1. _mens rea_ probably applies
|
| 2. But if you make a stab at shoplifting and you are
| successful and give back the item, did you break the law?
|
| I am not a lawyer I am just asking.
| jeroenhd wrote:
| It is where I live. If I know your username and password,
| using those credentials knowing you didn't intend to share
| them would be a crime.
|
| Of course, the probability of someone getting arrested for
| logging into your SSH server is as close to 0 as you can
| possibly get, but that doesn't make it legal.
| bongodongobob wrote:
| Yes it is, in the same way you can't just walk into someone's
| house if the door is unlocked. They might not press charges
| but they certainly could.
| alephxyz wrote:
| You may want to familiarize yourself with the Computer Fraud
| and Abuse Act
| ayewo wrote:
| That IP block (180.101.88.0/24) also makes a showing at the top
| of the stats [1] for https://brute.fail/
|
| Previous HN discussion for brute.fail [2].
|
| 1: https://brute.fail/top.txt
|
| 2: https://news.ycombinator.com/item?id=36169954
| wiradikusuma wrote:
| Holy moly! That explains why I frequently get captcha when using
| residential internet in Jakarta. I don't see those captcha when
| accessing from e.g. Kuala Lumpur or Singapore.
|
| Is the information in the article actionable? E.g. can I complain
| to someone with authority?
| Moru wrote:
| No, it's just a map of all hacked IoT devices in the world,
| it's not where the actual hacker is.
| unraveller wrote:
| If you're lucky enough to have a big ISP with a single big block
| of IP addresses that never changes you can disallow all other
| ranges on your VPS admin ports and only have to worry about
| VPNing through that ISP.
|
| I guess you could block the main country offenders but you'd have
| to pay an API to keep up with the IP allocations to be sure.
| abound wrote:
| Or alternatively, block port 22 entirely on your firewall and
| use something like Tailscale to access the machine.
|
| Of course, now your attack surface includes Tailscale, which
| has had it's own vulns in the past, but I think blocking all
| public traffic ends up being much stronger than any weaknesses
| Tailscale may introduce.
| kimixa wrote:
| Isn't that just the same thing in different clothes? Just a
| different protocol offering the same features of
| authentication and encryption - often using exactly the same
| primitives?
|
| Is it "Security through obscurity" assuming fewer people are
| attacking vpn protocols that than ssh? And I'm not sure
| that's even true
| walterbell wrote:
| Plus a centralized identity provider, which is a plus or
| minus depending on your threat model,
| https://tailscale.com/kb/1013/sso-providers
| yau8edq12i wrote:
| Introducing obscurity to the process doesn't make it
| insecure. Criticism of "security through obscurity" is that
| security shouldn't _rely_ on obscurity. The system should
| remain secure even if the attacker knows every detail of
| your system. Here the point of the "obscurity" (if you can
| call it that) is to avoid blowing up your logs and wasting
| compute cycles and energy on attempts that will fail
| anyway.
| miyuru wrote:
| I just use IPv6 and only allow my ISPs single /32 block. Its
| neat that IPv6 has cleaned the mess of IPv4 having different IP
| blocks all over.
|
| My prefix is dynamic, If it was static it would be more secure.
|
| And also I have fail2ban for good measure.
| jeroenhd wrote:
| Another advantage of IPv6, if implemented well by the hosting
| provider (i.e. they assign you a /64 or larger), is that you
| can pick a random IP address from a pool of billions to host
| your SSH server on. There's a tiny chance of accidentally
| conflicting with another service if you're provisioning your
| addressing using SLAAC, but that chance is low enough that
| I'm willing to risk it. Scanning the entire IPv6 internet
| isn't very feasible for automated tools because of how large
| the IP space is.
|
| This approach does require some client side hacking, though
| either in the form of SSH config, or in the form of a split
| horizon DNS so you can easily access your server, but that's
| no different from alternatives such as port knocking or
| simply altering the SSH port.
| mo_42 wrote:
| It's not so hard to use Tor for that. I wonder how the Tor exit
| nodes are distributed across the globe and see how that
| correlates or not.
| bauruine wrote:
| I don't have exactly what you want but you would be very
| disappointed by the result anyway. Tor isn't as nefarious as
| people tend to believe.
| [bauruine@tp:projects/misc]$ python check_ip_tor.py
| /tmp/malicious_ips.txt Got a total of 6303 malicious IPs
| Of which 15 are Tor relays
|
| Edit: Small addendum here are the worst 5 ASNs.
| 1607 TENCENT-NET-AP-CN 738 DIGITALOCEAN-ASN 483
| KIXS-AS-KR 205 GOOGLE-CLOUD-PLATFORM 115 OVH
| viraptor wrote:
| Stats from my service: ~92% of fake / auto user registrations
| comes from tor exits. (Or would, without blocking)
| ies7 wrote:
| > Interesting! We can see the most locations in India, Indonesia,
| and China as well as a significant number in the US and Europe.
|
| Are these because the bad guys are in there or just because of
| the population size?
|
| China, India, US, and Indonesia are the top four of the most
| populous country and also 4 countries with most internet users.
|
| Even the size of 10% of Indonesian internet users are almost the
| entire Taiwan population.
| tomschlick wrote:
| > Are these because the bad guys are in there or just because
| of the population size?
|
| Yes
| Gigachad wrote:
| I doubt most of these scans come from the attackers network.
| This is probably just a map of where the poorly secured CCTV
| cameras and IoT washing machines are.
| denton-scratch wrote:
| I was surpriswed at the sharp concentration of addresses in the
| Netherlands. It looks as if it's a matter of national
| boundaries - thee's no concentration in Germany or Belgium.
|
| That could be a couple of "relaxed" ISPs, I suppose. I doubt
| it's a question of different national legislation.
| dfex wrote:
| > Upon closer inspection of Asia, we can notice a significant
| number of addresses located in South Kora, (and possibly North
| Korea?), as well as in Taiwan.
|
| > I was surpised to see that the distribution of attacks is
| extremely uneven with most of it concentrated in parts of Asia,
| Europe, and the US, and (almost) none from South America, Middle
| East, and Russia.
|
| Aside from the casual stereotyping of bad actors here, the
| article completely neglects the fact that just because the attack
| is sourced from a certain IP/geolocation doesn't mean that the
| attacker resides in that location.
|
| What you most likely have is a listed of pwned PCs with fast
| internet connections being used in botnets.
| bradley13 wrote:
| Not seeing how this is stereotyping. He is just presenting his
| results. Whether those results stem from direct attacks or
| botnets? He doesn't even speculate.
|
| When I ran public servers a few years ago, I saw similar
| results. Since the company had no customers in Asia, we IP-
| blocked the entire continent.
| out-of-ideas wrote:
| the distribution looks spot on for what it used to look back
| in late 2000's as well from my collection of memories (minus
| south america, russia)
| supriyo-biswas wrote:
| I found the information about the attackers' quite interesting,
| because it also seems to disagree with Cloudflare data and my
| personal experience[1] which shows the US to be the largest
| originator of attacks.
|
| [1] https://radar.cloudflare.com/
| wolfendin wrote:
| That's perfectly consistent with sources of bad actor data I
| have access to and compile myself.
| micw wrote:
| "Failed publickey" - does this make sense? What is the chance to
| brute-force a private key that way?
| magnat wrote:
| If you haven't updated your Debian in a while, 1 in 30000
| apparently:
| https://www.hezmatt.org/~mpalmer/blog/2024/04/09/how-i-tripp...
| apstls wrote:
| It could be key spraying, maybe targeting a particular
| organization with distributed infrastructure for which the
| attacker already has some keys, but more likely groups blasting
| default keys (i.e. for some crappy IoT devices that included
| them in the firmware etc) for a nice & quick botnet.
| iforgotpassword wrote:
| 1. Scrape GitHub et al for accidentally committed private keys,
| maybe even get the appropriate username.
|
| 2. Run botnet that tries all these keys on the entire Internet.
|
| 3. Profit!
| ykonstant wrote:
| Why is GitHub not(?) hosting a flock of repos* with fake
| private keys/username pairs to annoy/deter those people?
|
| *Flock because of the Cloud? What is the appropriate noun for
| many repos?
| micw wrote:
| Very good points in the comments, thank you a lot!
| imp0cat wrote:
| Wouldn't it be better and faster to use a local geoip database
| for the IP lookup instead of doing a network call for each?
| keepamovin wrote:
| This was cool. The makings of an adhoc DIY cyber intelligence
| dashboard.
|
| I guess the distribution could reflect places with lower income
| levels looking to get free compute? (for whatever purposes). A
| lot are coming out of places where relative cost of compute
| compared to income, may be too high, alternately there may not
| have access to accepted payment methods?
|
| For the servers coming from the US and developed East Asia it
| could be already cyber companies doing scanning to find clients,
| or already compromised servers?
| chriscjcj wrote:
| It's been a couple decades since I adminned servers and
| firewalls. In my experience, in the early 2000's, Russian IPs
| were extremely common. I was surprised that OP didn't see even
| one. Can anyone conjecture on what might account for the apparent
| change?
| efnx wrote:
| The Russians are probably tunnelling through another connection
| or are steering a botnet.
| johanbcn wrote:
| > Can anyone conjecture on what might account for the apparent
| change?
|
| Many companies that do not have business in countries known for
| their abundance of bad actors will block their IP ranges right
| away.
|
| Nowadays hackers worth their salt will make use of botnets and
| VPNs located at more "friendly" countries.
| reincoder wrote:
| You can use IPinfo's IP map (https://ipinfo.io/tools/map) or IP
| summary tool (https://ipinfo.io/tools/summarize-ips).
|
| Both of these services support sending IP addresses via an API
| endpoint and can handle up to 500k IP addresses. You can also
| share the report via URL.
| ayewo wrote:
| Thanks for the tip. I'm also working on a similar analysis
| where I need to geolocate a bunch of IP addresses at once.
| reincoder wrote:
| Feel free to check out the IPinfo CLI:
| https://github.com/ipinfo/cli
|
| I highly recommend the following commands: -
| grepip: extract IP addresses from text. - summarize:
| The command summarizes the IP addresses and provides output
| in text. It is different than the summary tool I mentioned.
| - bulk: Bulk/batch enrich IP address. Output can be CSV or
| JSON.
|
| If you need any help or want me to take a look at those IP
| addresses (or ASNs and organizations), please create a post
| on the IPinfo community. I can share the code and
| instructions with you.
| ludovicianul wrote:
| A few years ago I've built a more simple visualization similar to
| this one with the attacks on the host the application was already
| deployed: https://github.com/ludovicianul/geolog. China was
| mostly leading, but there were many from US and Europe.
| tonymet wrote:
| why is ssh open to the internet to begin with?
|
| ufw is the first thing I install, even on a "private" network and
| here's why.
|
| I recently installed a router with IPv4 and IPV6. I later found
| out that IPv6 was globally addressed with no firewall.
|
| Always run ufw and begin by shutting off everything to the
| internet, then only open up what you need.
| Msurrow wrote:
| Perhaps because the VPS is hosted somewhere remote and (s)he
| needs to ssh into it. Why ask questions in such an arrogant
| manner to begin with.
| darkwater wrote:
| Well, if you want to connect to your home LAN from your phone
| anywhere in the world you either need SSH or some VPN port
| opened either. Alternatively you can use some SaaS server where
| everything initiate the connection against the remote SaaS
| endpoint, but if you want to stay 100% local you need to open a
| port.
|
| For ssh changing the port to something else usually takes out
| 99% of bots.
| globular-toast wrote:
| Erm, because he wanted to use SSH?
|
| Using firewall rules on the hosts is like a fake firewall.
| Stuff on the hosts can override those rules. Like docker. After
| all, the host is actually receiving the traffic.
|
| A router isn't a firewall. Lesson learnt: don't assume any
| "router" device is also a firewall. Last I heard about half of
| ISP issued routers don't run any kind of stateful firewall for
| IPv6. The only reason they do for IPv4 is NAT.
| ykonstant wrote:
| Hey, a question: I also use ufw because I don't understand
| firewall rules properly. Is there a benefit for me, a desktop
| user who would like to set up a tiny home network and
| _possibly_ setup an SSH server to connect from afar, to delve
| into iptables /nftables instead? I tried once, but couldn't
| understand how the rules work.
|
| Also, if there is a ground-up explanation of firewall rules,
| their uses and misuses, and illustrative examples, I'd love if
| people could share.
| jeroenhd wrote:
| > I later found out that IPv6 was globally addressed with no
| firewall.
|
| Crazy! What brand router was this? I've never seen an IPv6
| capable router configured to permit all traffic by default.
| BenjiWiebe wrote:
| Me neither, and I've even checked an old ISP-provided router.
| tetris11 wrote:
| I'd recommend grepping "(Failed|Invalid)" to capture more IPs
| mtekman wrote:
| I use the same pattern for my iptables banner.
|
| It's essentially a manual firewall for when I disable ufw if
| it's being too aggressive:
|
| https://gitlab.com/mtekman/iptables-autobanner
| midnight_shaman wrote:
| I always install fail2ban on publicly exposed machines,
| especially if ssh is enabled. It won't block new malicious IPs
| but at least it will stop bruteforce attacks coming from each IP
| Joel_Mckay wrote:
| Sure, but most people have had do the walk of shame to a local
| coffee shop when someone inevitably trips the ban on your own
| network.
|
| A proper firewall port-knock set interleaved with 5 day ban
| tripwire port rules is effective at mitigating distributed
| brute-forcing. However, a ssh route whitelist rule set with SSL
| or iodine tunnel traffic priority is probably more important
| (when someone saturates the bandwidth trying to starve your
| session off the server).
|
| Have a great day =)
| mr_mitm wrote:
| Port knocking is one of those things that sound like a good
| idea, but there are many possible footguns. And why is it
| that there is no one consensus (or "blessed") implementation?
|
| The implementation by Moxie seems interesting, but needless
| to say that Python 2 is an instant no-go:
| https://github.com/moxie0/knockknock
|
| It hasn't been updated in 12 years, so why is it that there
| seems almost no real interest in a solid port knocking
| implementation?
| teddyh wrote:
| Because port knocking is fundamentally a stupid idea:
| <https://news.ycombinator.com/item?id=39898061>
| mr_mitm wrote:
| Two of your three points don't apply to Moxie's and some
| other implementations, for example Singe Packet
| Authentication. You can have sufficient bits, and it
| doesn't have to be cleartext. Maybe it's technically not
| port knocking anymore, but it's the same idea.
|
| And it's not about adding more bits to your
| authentication, it's about vulnerabilities that can be
| exploited without authentication, like the recent xz
| backdoor debacle. Port knocking would defend against
| that, longer keys would not.
|
| This has all been pointed out to you in the thread you
| linked.
| Joel_Mckay wrote:
| If your hobby firewall rule-set compiler is perl based than
| custom trigger rules are rather trivial.
|
| For a random example, most of these ports will just bind to
| the default web-server (mitigates loopback attacks etc.):
|
| 2021 //tripwire 5 day ban, delay 30s
|
| 2022 //SSL tunnel for SSH port on VM, with client source-
| port range restriction.
|
| 2023 //tripwire 5 day ban
|
| 2024 //tripwire 5 day ban, delay 130s
|
| 2025 //tripwire 5 day ban
|
| 2026 //trigger 1: enable trigger 2 for specific IP, 5
| second delay to open
|
| 2027 //tripwire 5 day ban
|
| 2028 //trigger 2: enable trigger 3 for specific IP, 4
| second delay to open
|
| 2029 //tripwire 5 day ban, delay 19s
|
| 2030 //tripwire 5 day ban
|
| 2031 //trigger 3: close trigger 2, enable SSL tunnel port
| for specific IP in 1 second
|
| 2032 //tripwire 5 day ban
|
| 2033 //close all ports for this client IP, and reset
| trigger states in 1 second
|
| 2034 //tripwire 5 day ban
|
| I think the lack of popularity comes from the ease of
| locking oneself out (initially manual starting a firewall
| during configuration without rule caching is wise), and
| lack of client-side automated handshaking scripts on
| non-*nix systems.
|
| Someone should put together a little tutorial given many
| people seem to have lost this simple skill-set. Most people
| tend to ignore fail2ban integration options like banning
| game cheats.
|
| Have a wonderful day, =)
| AndroTux wrote:
| > Sure, but most people have had do the walk of shame to a
| local coffee shop when someone inevitably trips the ban on
| your own network.
|
| VPN, other server, mobile hotspot... No need to leave the
| house.
| Joel_Mckay wrote:
| In theory, remember some firewall policies ban most Tor,
| Proxy and cloud providers. There is always a way. ;)
| opentokix wrote:
| This is literally built in, in most modern logging systems with
| visualization.
| voidUpdate wrote:
| So this made me realise where I could find the SSH log file, and
| I spent a little while panicking at just how many attempts I've
| been getting on my webserver, and locking things down just a
| little harder out of paranoia
| jeroenhd wrote:
| If you use a good password (meaning a unique, randomly
| generated one), or disable password login and use private keys
| only, your chances of getting hacked by any of these are
| abysmally small.
|
| There are reasons to lock down your SSH port (fear of
| exploitation of the SSH software, like in the xz backdoor
| scenario) but I generally wouldn't worry too much about all the
| failed login attempts in your SSH log, as long as you're using
| secure enough login credentials.
| denton-scratch wrote:
| People have been having this experience for ages. The first
| time you look at access/security logs for an internet-connected
| server, your jaw hits the floor, you get very curious about who
| all those bad people are, and you start worrying whether you're
| doing enough to keep them out.
| ajsnigrutin wrote:
| > Finding the location of each attacker.
|
| ...of the attacking IP address, not attacker...
|
| If I, living in a small EU country, wanted to "hack" my neighbour
| across the street, I sure as hell wouldn't use my home IP
| address, tied to my account at my ISP, which has my name and
| address.
|
| I'd probably try to find an "IP" (VM, vpn, or whatever) in a
| country that's not really friendly about giving "ip address data"
| to our authorities.
|
| On the other hand, I wouldn't use a chinese IP in china, if I
| lived there and wanted to hack my neighbour over there.
| 3abiton wrote:
| I have been doing similar, albeit less complex analysis, of
| incoming malicious, and it's always surprising the amount of
| relentless attacks. Any good practices to maintain a secure
| online server?
| zaik wrote:
| No root login, no password login, public key only. This should
| make ~100% of ssh attacks futile. If you don't want to see many
| failed login attempts in your logs, listening on a completely
| random 5 digit port and has worked well for me. You can specify
| the port in ~/.ssh/config so you don't have to type it every
| time you log in.
| brazzy wrote:
| As others have pointed out, the location of the IP address does
| not necessarily correspond with the location of the attackers.
|
| Specifically, in Germany, the central-ish culster of dots is in
| the Frankfurt area, which is also the location of DE-CIX, one of
| the world's largest internet exchange points, and of roughtly 1/3
| of all datacenters in Germany.
|
| So I think rather than comparing the IP locations with population
| density, it would be even more interesting to compare them with
| the location of internet infrastructure. This is of course
| correlated, and probably harder to find as an open dataset.
___________________________________________________________________
(page generated 2024-04-26 23:02 UTC)