Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
127.0.0.1 on firehol_level4 #143
I found a curious thing happen with att.com, the firewall I use was blocking it and saying it was coming from the level4 block list. It turns out that 127.0.0.1 (localhost) is in the level4 block list for some reason.
Can you take that off the list? I don't think it's supposed to be on the list.
Could you please explain how you use it?
I understand that you could use any of these strategies:
The last resort could be to use
iprange blacklist --exclude-next whitelist >accepted_blacklist
However I strongly suggest to follow both 1 and 2. If you need help achieving this, post here and I'll help you.
You're not understanding what I'm saying I guess.
if you look at the list: https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level4.netset
...and do a cntrl + find > then type in: 127.0.0.1
I don't believe that localhost address should be in the list as "localhost" or "127.0.0.1" is clearly in the list.
Am I wrong?
ok. I think I perfectly understood you already. So, let me show you.
Check what else firehol_level4 includes:
# iprange firehol_level4.netset --common bogons.netset 10.1.0.250 10.24.0.165 10.33.0.102 10.107.0.186 10.240.0.10 10.255.255.200 127.0.0.1 172.16.0.101 192.168.0.1 192.168.0.7 192.168.1.1 192.168.1.8 192.168.1.31 192.168.2.4 192.168.3.100 192.168.30.94 192.168.33.201 192.168.51.2 192.168.52.28 192.168.65.8 192.168.100.73 192.168.151.0 192.168.224.1 18.104.22.168
All these are private IPs, unroutable to the internet. Shall I remove them?
Since they are listed on firehol_level4 someone got an attack from these IPs. He was receiving packets from the internet with source IP, one of these IPs.
These IPs should not be a problem for you, if your firewall was blacklisting IPs the right way.
Apparently you are blocking all traffic from/to firehol_level4 without checking anything else. This is the problem. You should only block firehol_level4 on your internet interface. This way the IP 127.0.0.1 should have been blocked only if it was found on the internet interface, and you should want this to happen.
Is it more clear now?
I would think the private blocks wouldn't be on a public block list and
If someone has been attacked from a bogon I'd think that was their problem
I'd suggest you filter out bogons on the general level lists because those
On Mon, Jun 6, 2016 at 3:00 PM, Costa Tsaousis email@example.com
Thanks! However, it is more complex than that. firehol_level1 for example, includes bogons by design. I intentionally added it for blocking all the IPs that should never appear on your internet interface.
firehol_level4 should be used on top of level3, level2 and level1. Each additional level (starting from level1) filters out more IPs with the risk of more false positives.
firehol_level4 is a very risky IP list. As its description says it may include a large number of false positives.
I have designed these levels so that under normal conditions you should only use level1. If you face an attack, you include level2 (attacks of the last 48 hours). If it is not effective include level3 (attacks of the last 30 days). If, even all these are not effective, then include level4. With level4, you risk blacklisting some of your legit users but it may help you to stop the attack.
Of course you are not forced to use these. Just combine the ones you need yourself (and even exclude IP lists you don't want included). I have provided all the tools for this, so you can do it. Of course if you believe you have combined a list that can be useful to others too, just give me the rules and I'll add them to
No problem - I can filter them out on my side.
On Tue, Jun 7, 2016 at 12:59 PM, Costa Tsaousis firstname.lastname@example.org
I have run into a similar problem with localhost's IP address(es). Ktsaou's solution -- to subject only internet interfaces to internet blacklisting -- seems very correct but it adds complexity to the maintenance of various workstations and servers. The extra complexity comes from the fact that interface names differ with hardware/driver combinations, and they are subject to considerable variation and change.
My current solution is to use firehol_level1, but to omit enabling the "fullbogons" ipset. I don't see any convenient way to use fullbogons, even though I would like to, since it includes 127.0.0.0/16 and there's no convenient way to exclude it.
We use firehol. (As we have for many years.) The relevant lines in our firehol.conf are:
ipv4 ipset create firehol_level1 hash:net ipv4 ipset addfile firehol_level1 /etc/firehol/ipsets/firehol_level1.netset blacklist4 full ipset:firehol_level1
If there's a way to exclude only 127.0.0.0/16 from the full firehol_level1 while using update-ipsets, we would like to know how to do it.
ok, then it is easy:
Here is what it does:
As you can see, it first matches the ipset and then it excudes the private IPs (src in input, dst on output).
And you can also whitelist interfaces like this:
I see there is bug in firehol. We should be able to say this (which is more efficient compared to the above):
but the parsing of
added a commit
May 25, 2017
fixed it. Will merge in a while.
After it is merged, you can also use:
which produces this: