-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
127.0.0.1 on firehol_level4 #143
Comments
Hm... right now 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? Thanks. |
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
238.209.5.182 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 Thanks! On Mon, Jun 6, 2016 at 3:00 PM, Costa Tsaousis notifications@github.com
Rafael |
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. Thanks, Rafael On Tue, Jun 7, 2016 at 12:59 PM, Costa Tsaousis notifications@github.com
Rafael |
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. |
hm... which firewall do you use? how do you apply the blocklist? |
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). |
Instead of using
So, allow the blacklist to match private IPs you know you don't use. |
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 |
fixed it. Will merge in a while. After it is merged, you can also use:
which produces this:
|
merged it. |
This is excellent! Many thanks. |
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.
Thanks.
The text was updated successfully, but these errors were encountered: