I am working on a firewall rule to automatically update the above list of known Log4j exploiters IP list.
It is just a little bit above my expertise and I was wondering if there are already attempts that go in the same direction?
In your second link he writes like this:
That result is actually the same as my findings when logging wan port scanners plus USA and China.
So what do that tell us? Well only that all these ip addresses are spoofed server halls mostly in Europe.
So you can block the whole of Europe. But then internet collapses and the bad guys are still there in some other server hall. So then the next best solution is to disconnect your router from internet and go outside.
You will never get a complete blocking list ether as in your first link since they just get new server halls and new IP list ranges.
When I first read about Log4J it only had about 20 spoofed domains. How many 1000 do you have in your list.
And Log4J isn’t the only problem, and since it has been discovered a lot of other meltdowns has been presented each day.
Are this tactic are supposed to be meaningful you need to go to the source and delete it. Blocking a never ending growing list of addresses are a reactive responce.
4 Likes
if there is flooding then you put sandbags around your house, if you are jesus then you stop the flood. I am not jesus.
However, the exploit can be patched.
If you have exposure, that's probably the best way forward.
3 Likes
I am not jesus but as a human I am lazy and generally don’t like to work more than I have to.
To make never ending block list means you are fighting them symmetrically at their terms and you will loose because sooner or later you have lost your internet freedom because your firewall is using all your cpu power to evaluate your huge block list. And you are sitting all day finding new ip addresses to block.
Let the bad guys do the work instead…
If you patch the system you can look at Netflix and the bad guys have to come up with a completely new attack vector. And then we meet again in a couple of weeks for round two or three or four...
Flooding…one way is sandbags (how high?), another way is to call jesus. The third option is to evaluate the ground to begin with and don't build on predicted flood areas/low ground/outer corners of rivers.
Can you clarify—are you building this list to block access outbound to said IPs on your list? Or are you building a list to block these IPs inbound to your firewall?
You could block every country in the world except your own, and still you'd eventually run into an attacker using a VPS/cloud instance in your country to attack you.
This is a CVE with a rating of 10. Patch it yesterday, or learn how to farm.
5 Likes
@huramentzefix The reason for my questions here were really to dig into your intent with this data.
If you are already running a properly configured firewall that is set up to drop (not reject) any inbound packets that are not "related" or "established" (read: "invalid" packets) as they pertain to stateful outbound connections established at the firewall, then you're already protected from any of the IPs you could possibly be adding to your list.
Conversely, if you're trying to prevent outbound connections to the IPs on your list, that's a different scenario. Though I would argue, as have others, that you're chasing a forever moving target. You would be better off just connecting to websites you really know and trust.... or just go outside as @flygarn12 said.
I have never understood the point of the massive geo-ip type blocklists from an inbound blocking perspective. A properly configured firewall doesn't need to give two hoots if an IP is in Europe, Africa, or Mars. If you didn't ask for it (again, stateful firewall 101), then the firewall should drop it. I consider a list like you're proposing along those same lines if you're talking about inbound blocking.
But that's just my $0.02.
1 Like
thank you @all for your help and explainations, specially @_FailSafe .
I am not an administrator that is tying to protect a network, I am just experimenting and learning.
I thought it might be useful to have the firewall blocking these IP's inbound and outbound and auto update from that list that someone else is working on.
But thanks to you guys I have learned that this is not necesarry.
I will scrap the idea then and further look into my firewall configuration.
1 Like
From my IT Security days: "You can't clean up the Internet. The only option is to control your vulnerability to it."
Block lists don't scale, require infinite maintenance, and cost a lot. Correcting the vulnerability fits the very old principle when programming for the Internet: "Make what you send be as closely adherent to standards as possible, and expect noise inbound."
1 Like
With a list like that (found mine at crowdsec) we can buy time:
grep -o '\d\d*\.\d\d*\.\d\d*\.\d\d*' downloaded.list > log4jBlock.list
while read line; do iptables -I FORWARD -s "${line%*}" -j DROP; done < log4jBlock.list
with a small investment.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.