FlorianHeigl/ipset_script.sh

## ipset_script.sh


setup_ipset() {
  # this only needs to be run once
  if ! type ipset 2>/dev/null ; then
  ipset create log4j_attackers nethash
  iptables -I INPUT -m set --match-set log4j_attackers src -j DROP
  iptables -I OUTPUT -m set --match-set log4j_attackers dst -j DROP
}

get_list() {
# this needs to run periodically, it will get the newest attacker host list off github.

  set -e
  set -o pipefail
  wget -Olog4j.txt.unsort https://raw.githubusercontent.com/CriticalPathSecurity/Public-Intelligence-Feeds/master/log4j.txt
  strings log4j.txt.unsort | sort -u > log4j.txt.u > log4j.txt

  # safeguards here
  # list not tiny?
  # list only contains ip format entries
}

load_list() {
# load the list, without intelligene
while read ip ; do
  ipset add log4j_attackers $ip
done < log4j.txt
}

main() {
    setup_ipset
    get_list  &&
    load_list
}

main

## log4shell.md

      
    Raw
  

              log4shell.md
            
          
    log4j / log4shell

An overview of tools, information, helpful stuff and distractions.
Mostly still untested.
blocking

Linux: block using ipsets

an ipset collects a list of ips/networks into a named object which can be accessed at runtime by iptables.
(similar to how it's done in BSD's pf firewall)
Pro


Very linux-native method, no non-kernel dependencies except the frontend utility, thus working anywhere with a kernel from the last ~7 years.
Simple, easy to maintain
no reloads or similar needed

Con

The settings made this way are not persistent across reboots.
You'll need to reload the ipset and rules, whenever the system is restarted
You should also periodically update it as new hostile hosts are detected on the internet.
Howto

Install the ipset command to manage ipsets that will later be referenced from iptables
# apt install ipset

fetch the blocklist from github
wget -O log4j.txt.u https://raw.githubusercontent.com/CriticalPathSecurity/Public-Intelligence-Feeds/master/log4j.txt
sort -u log4j.txt.u > log4j.txt

create an ipset and load the blocklist contents into it
# ipset create log4j_attackers nethash
# while read ip ; do ipset add log4j_attackers $ip ; done < log4j.txt 

insert a DROP rule in the INPUT and OUPTUT changes of iptables.
# iptables -I INPUT -m set --match-set log4j_attackers src -j DROP
# iptables -I OUTPUT -m set --match-set log4j_attackers dst -j DROP

verify the ipset contents match up with the input
# wc -l log4j.txt
891
# ipset list log4j_attackers | wc -l
890

Fail2ban: inject block table entries

set <JAIL> banip <IP> ... <IP>           manually Ban  for 
i.e.:
# fail2ban-client set \
zimbra-webmail banip 45.155.205.233

You could also create a new jail that directly reads in a file with the iplist, but generally fail2ban is made to read log files that are appended. I don't know if it would go perfectly well, but the approach in general would be very pretty / useful.
If you go that route, just don't forget to do a multiport ban, not just a single service.
JunOS: block using dynamic lists

A dynamic list is a list of network addresses (not address book entries that can be used in policy. The OS can be easily configured to periodically refresh them.
Pro


Simple method that uses JunOS builtins
Will produce proper log events

Con


Seems to not be supported on very old OS.

Howto

I foun one on reddit Loading Custom dynamic lists from your own
It didn't work on a SRX running very outdated JunOS 12, and my JunOS 21 NFX is offline due to a move at the moment. Yet, the method looks fine.
It should be possible to point this right at the GitHub URL of CriticalPathSecurity's log4j.txt feed.
Notably, the example used a .gz file format.
Further docs

JunOS documentation: show security dynamic-address
pfSense: block using pfBlocker

On pfSense the generally best choice is using pfBlockerNG, for purposes of blocking log4j attackers it can handle all the automatic updates by itself.
Pro


Automatic
Interoperable with other blocklists
quick to set up if already using pfBlockerNG

Con


pfBlockerNG is not a very stable package
Firewall event viewing is not a strong point of pfSense
pfblockerNG ad-hoc setup is involved process
differenes between -dev and non-dev versions

Howto

We're on pfSense 2.5.2-RELEASE (most recent)
The pfblocker package is also current:

In pfblocker, you need the "IPv4" menu item to add an IP-based blocklist.
(of course there could also be attacks via v6 but i've not yet seen any recorded)

As you can see in this menu, I've added an entry for log4j to allow individually tracking hits on these rules.
Here are all the settings from this rule

Zimbra

https://forums.zimbra.org/viewtopic.php?f=15&t=70240&start=20
Testing

A callback tester
https://log4shell.huntress.com/
A good log pattern to look for

This will apparently allow to not just look at log files showing http requests, but also allow you to see if jndi did a connect.
Check your #log4shell #log4j instance for this log line: ”Starting JndiManager http://org.apache.logging.log4j.core.net.JndiManager”
That line means someone triggered jndi and you need to make an investigation.
source
Finding vulnerable instances

A log4j search tool (also in java) that can look inside WAR files and similar.
This should be the right thing if you want to search all your infra.
https://twitter.com/myfear/status/1470129332274225159
A simpler starting point is to look for the log4j.properties config file.
Patching

A hot-patch solution for running JVMs
(actually, two of them)
https://twitter.com/karianna/status/1470066728004632580
Overviews

https://mogwailabs.de/en/blog/2021/12/vulnerability-notes-log4shell/
https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/
vuln list
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592?s=09
log4j v1

laut devs nicht affected und unsupported.
realitaet ist evtl. nicht ganz so.
apache/logging-log4j2#608 (comment) <- affected, wenn irgendwas enabled ist, risk much lower. damit bleibt meine empfehlung unveraendert, zimbra soll sagen ob zimbra in der jew. Version davon betroffen ist.
apache/logging-log4j2#608 (comment)
hardening options

there's not a lot to do, so far. I've especially looked at the mailserver cases, where you have a lot of outgoing and incoming (legitimate) communications. There's also simpler cases where you can at least restrict the communications.
Measures in general
disrupting execution

simpler attacks will download code, but also often work with helper scripts that are first stored to world-writeable directories and then executed.
The most basic thing is to make your run-time /tmp directories non-executable.
This is still needed, even though it's become a bit less simple over the last years.
An entry as the following can be made to disallow running things downloaded to /tmp
tmpfs                   /tmp                    tmpfs   size=512m,noexec,nodev,nosuid,mode=1777      0 0

Sprinkle as needed, meaning, also consider doing the same for /dev/shm and also look at /var/tmp. The latter can be potentially a bit more troublesome, just like /run.
I can't do anything about that, but at least /dev/shm should also be fine.
More efficient measures can include not having this as a world-writeable directory in the first place, by setting a mode like 1770 and only allowing certain groups to write there.
(that will at least stop anon users like webservers)
Purpose-build HTTP replies

gzip bombing

Sending back a large compressed file to anyone who tries to detect/exploit this.
(Will also reply to security companies scanning...)
nginx

https://twitter.com/shipilev/status/1469417410214125569
https://gist.github.com/shipilev/92e709a868f3d328b6636e1bfc21cf09
Apache:

https://twitter.com/KainsRache/status/1470170919658311684/photo/1
Blocking Requests for jndi URLs

will not work against many obfuscated urls, but is still the most basic measure you could apply
nginx

if ($http_user_agent ~* (jndi) ) {
   return 403;
}
location ~* jndi {
   return 403;
}

outgoing rules

if your application's purpose allows, you can easily restrict what kind of outbound communication it can have.
please note that for a normal web server behind a load balancer you DO NOT NEED a DNS or default gateway to be configured for it to simply answer http requests.

if you don't have a db backend, the strongest thing to do is to use selinux to remove the can_network_connect priviledge. That should(!) kill all attempts of outbound connections.
if you have some hosts you connect to, you can use iptables to allow only connecting to those (along with the ports needed. this is basically host based firewall stuff, allowing only communication that you actually want)
dns can maybe still be a troublesome thing, i don't know how jndi does DNS.
if you want to restrict a single application to only what it's supposed to be able to do, you can use iptables, too. It can have rules per-user, so if you deny something for your confluece user's uid, it'll affect all processes running with that user id.
updates

if you're the application owner, simply go and update log4j2 to the current version that has the security fix and redeploy/restart.
if you're in a less privileged position there is not so much that you can do.
you still need to make sure that you have the most recent JDK version for it, in hope of having some secondary security effects, i.e. per default network lookups can be disabled.
Jokes

finally some little jokes since this whole thing is so utterly depressing.

No one.
Absolutely no one.
Me on Monday morning:
So, Java nice weekend?
(@ravici)

as a pen tester my recommendation is GET THE FUCK OFF THE INTERNET AND RUN UNDER A DESK THIS SHIT IS EVERYWHERE
(@_hpy3ri0n)


	setup_ipset() {
	# this only needs to be run once
	if ! type ipset 2>/dev/null ; then
	ipset create log4j_attackers nethash
	iptables -I INPUT -m set --match-set log4j_attackers src -j DROP
	iptables -I OUTPUT -m set --match-set log4j_attackers dst -j DROP
	}

	get_list() {
	# this needs to run periodically, it will get the newest attacker host list off github.

	set -e
	set -o pipefail
	wget -Olog4j.txt.unsort https://raw.githubusercontent.com/CriticalPathSecurity/Public-Intelligence-Feeds/master/log4j.txt
	strings log4j.txt.unsort \| sort -u > log4j.txt.u > log4j.txt

	# safeguards here
	# list not tiny?
	# list only contains ip format entries
	}

	load_list() {
	# load the list, without intelligene
	while read ip ; do
	ipset add log4j_attackers $ip
	done < log4j.txt
	}

	main() {
	setup_ipset
	get_list &&
	load_list
	}

	main