Hi All,
Over the last 20 some years I have a file with about 200K worth of address that have "wrongly" tried to connect to my boxes running centos. So the file has one line per address or group of addresses like: 2.244.112.0/24
So using the OLD iptables I would run through my file build the iptables.txt file and start that with DROP for the IP address. iptables ran through the big list in no time.
I was trying to run a script to go through each line and run: firewall-cmd --zone=drop --add-source="$ipblock" --permanent but this takes a long time.
What is a "better" way or more efficient way to keep my long list of bad addresses and apply them? Thanks,
Jerry
On Tue, Feb 4, 2020 at 5:34 AM Jerry Geis jerry.geis@gmail.com wrote:
Hi All,
Over the last 20 some years I have a file with about 200K worth of address that have "wrongly" tried to connect to my boxes running centos. So the file has one line per address or group of addresses like: 2.244.112.0/24
So using the OLD iptables I would run through my file build the iptables.txt file and start that with DROP for the IP address. iptables ran through the big list in no time.
I was trying to run a script to go through each line and run: firewall-cmd --zone=drop --add-source="$ipblock" --permanent but this takes a long time.
What is a "better" way or more efficient way to keep my long list of bad addresses and apply them? Thanks,
Jerry
Hi,
If you are using CentOS 7, you can use ipset.
You can add all your IPs and IP ranges to an ipset and do operations on it.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
The same should have worked for CentOS 8 except for this,
https://bugzilla.redhat.com/show_bug.cgi?id=1774742
--- Lee
On Mon, 2020-02-03 at 19:04 -0500, Jerry Geis wrote:
Hi All,
Over the last 20 some years I have a file with about 200K worth of address that have "wrongly" tried to connect to my boxes running centos. So the file has one line per address or group of addresses like: 2.244.112.0/24
So using the OLD iptables I would run through my file build the iptables.txt file and start that with DROP for the IP address. iptables ran through the big list in no time.
I was trying to run a script to go through each line and run: firewall-cmd --zone=drop --add-source="$ipblock" --permanent but this takes a long time.
What is a "better" way or more efficient way to keep my long list of bad addresses and apply them? Thanks,
To some extent you need to ask yourself if a 20 year old blacklist is really effective these days. Lots will have changed in that time and many of the addresses will have been reassigned.
Also, a 200k lump of addresses will surely slow down the processing of incoming packets?
Perhaps it's time to rethink what you do. Can you define what addresses would "rightly" try and connect to your machine and whitelist those on a normally closed system (rather than blacklisting those on a normally open system).
If you need the system to be open, then I find Fail2Ban useful in blacklisting addresses that are being naughty.
P.
On Tue, 4 Feb 2020 at 05:37, Pete Biggs pete@biggs.org.uk wrote:
On Mon, 2020-02-03 at 19:04 -0500, Jerry Geis wrote:
Hi All,
Over the last 20 some years I have a file with about 200K worth of
address
that have "wrongly" tried to connect to my boxes running centos. So the file has one line per address or group of addresses like: 2.244.112.0/24
So using the OLD iptables I would run through my file build the iptables.txt file and start that with DROP for the IP address. iptables
ran
through the big list in no time.
I was trying to run a script to go through each line and run: firewall-cmd --zone=drop --add-source="$ipblock" --permanent but this takes a long time.
What is a "better" way or more efficient way to keep my long list of bad addresses and apply them? Thanks,
To some extent you need to ask yourself if a 20 year old blacklist is really effective these days. Lots will have changed in that time and many of the addresses will have been reassigned.
Also, a 200k lump of addresses will surely slow down the processing of incoming packets?
It will because it is a linear list that every packet has to be 'judged' against. Even if you break it down to 2 or 3 trees it will still take a while.
Any list of ip addresses is going to be outdated by a year because of how ranges are so dynamic these days. Most 'bad-guys' can jump around a couple hundred thousand or million ip addresses without much cost on their part and can get new ranges to screw around weekly.
Perhaps it's time to rethink what you do. Can you define what addresses would "rightly" try and connect to your machine and whitelist those on a normally closed system (rather than blacklisting those on a normally open system).
If you need the system to be open, then I find Fail2Ban useful in blacklisting addresses that are being naughty.
P.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Tuesday, February 4, 2020 4:13:50 PM CET Stephen John Smoogen wrote:
On Tue, 4 Feb 2020 at 05:37, Pete Biggs pete@biggs.org.uk wrote:
On Mon, 2020-02-03 at 19:04 -0500, Jerry Geis wrote:
Hi All,
Over the last 20 some years I have a file with about 200K worth of
address
that have "wrongly" tried to connect to my boxes running centos. So the file has one line per address or group of addresses like: 2.244.112.0/24
So using the OLD iptables I would run through my file build the iptables.txt file and start that with DROP for the IP address. iptables
ran
through the big list in no time.
I was trying to run a script to go through each line and run: firewall-cmd --zone=drop --add-source="$ipblock" --permanent
but this takes a long time.
What is a "better" way or more efficient way to keep my long list of bad addresses and apply them? Thanks,
To some extent you need to ask yourself if a 20 year old blacklist is really effective these days. Lots will have changed in that time and many of the addresses will have been reassigned.
Also, a 200k lump of addresses will surely slow down the processing of incoming packets?
It will because it is a linear list that every packet has to be 'judged' against. Even if you break it down to 2 or 3 trees it will still take a while.
Any list of ip addresses is going to be outdated by a year because of how ranges are so dynamic these days. Most 'bad-guys' can jump around a couple hundred thousand or million ip addresses without much cost on their part and can get new ranges to screw around weekly.
Perhaps it's time to rethink what you do. Can you define what addresses would "rightly" try and connect to your machine and whitelist those on a normally closed system (rather than blacklisting those on a normally open system).
If you need the system to be open, then I find Fail2Ban useful in blacklisting addresses that are being naughty.
Is it useful to block IP addresses at all?
Either all addresses are blocked anyway, or a particular port is open and addresses are not blocked. If you need a port open and not all addresses blocked, then block all addresses except for the ones you want to allow.
You can't prevent undesirable traffic from occupying your bandwidth anyway. Give it another 20 years and you might want to block 200 billion ipv6 addresses on top on your 200k ipv4 ones and you won't be able to tell anymore whether you live on Mars, Venus, Earth or further out. (But then, I kinda question that already all the time here.)
Once upon a time, Stephen John Smoogen smooge@gmail.com said:
It will because it is a linear list that every packet has to be 'judged' against. Even if you break it down to 2 or 3 trees it will still take a while.
Putting them in ipset would be much better performance (uses hash, so not a linear search). It also makes for a much more readable and manageable firewall config. I use ipsets for most everything these days, even where there are just a few IPs/networks involved. However...
Any list of ip addresses is going to be outdated by a year because of how ranges are so dynamic these days. Most 'bad-guys' can jump around a couple hundred thousand or million ip addresses without much cost on their part and can get new ranges to screw around weekly.
Yeah, it's going to be a useless list. If you want to protect services, then short-term blocking like fail2ban is okay - better is to just allow your "known good" sources and not try to block things bit by bit.
-
Chris Adams -
hw -
Jerry Geis -
Pete Biggs -
Stephen John Smoogen -
Thomas Stephen Lee