After reading blog article by Peter M: https://blog.ipfire.org/post/firewall-configuration-recommendations-for-ipfire-users and following through successfully hardening my IPFire I’m curious how my system information finds it way thru the firewall rules to the Fireinfo profile even with default behaviour is set to block for input and forwarding traffic ?
Simply put… how does my ipfire profile actually sent back to fireinfo.ipfire.org ?
Simply put… how does my ipfire profile actually sent back to fireinfo.ipfire.org ?
there is a HTTPS webserver behind fireinfo.ipfire.org and your IPFire machine periodically (to my knowledge, once a day) connects to it and submits your profile information.
There is no way the IPFire.org infrastructure can extract those information remotely - which would be a backdoor -, and since Fireinfo profiles contain anonymous information only (your IP address is not stored, it is only used for looking up the country while processing your Fireinfo profile), we strongly ask you to keep Fireinfo enabled, as it makes development of kernel and hardware drivers much easier.
The source code of the sendprofile script, which submits your Fireinfo profile, is available here.
Otherwise this only confuse the masses Including me.
thanks for clarifying this.
Because if outgoing is not blocked, also fireinfo is not blocked and so your question makes no sense for me
This is somewhat true: If an IPFire machine is able to establish arbitrary connections to the internet, this includes Fireinfo as well. However, there is no actual need to block Fireinfo, since it can be just disabled in the GUI.
Evidence that my fireinfo profile is being updated:
I’m not a coder but have taken a quick look at the sendprofile script and I would to understand which of my Outgoing Firewall Access rules is allowing this info to flow back to IPFire servers. Perhaps my lack of coding experience fails to see the obvious.
I assume its Rule “4” - could someone please confirm this for me:
Dont worry thats what i thought from the beginning
Confirm you
One thing about the destination. All my rules that goes outside i gave here destination red (if i need everywhere internet) not any. If you have for example a rule from outside to inside you can use as source any, but here red as destination should do it also for you, its enough.
Important Edit: Not that someone the source any understand in the wrong way … it was only a example. Its always better only to use whats really needed.
Something else about your rule 4, the post about FW recommends make a geoip group with the countries (or IP’s) mirrors to avoid to use any in the destination.
I included all mirrors countries, even though sometimes fails, but I belive it is better than include countries without mirrors, because a possible intrusion communicating to anywhere via https.
yesterday it was late and as you can see i have already my posting very much edited. What i tried to say above is the following. If you want to send to all in Internet, then you should choose red and the protocol you want.
So for example your rule 1 destination RED:NTP
Rule 5 destination RED:WHOIS
I want to thank you for your posting. You are, as far as i remember, the first one who start the mission firewallrules after Peter’s blog posting on your first step alone (and not asking for pictures). I was so long waiting for someone like you
It seems for me you dont want use proxy?
One word about the mirrors IP, some server are accessible from different IP’s. Feel free and use the following list if you also want do it this way. Easier to copy and paste instead from your picture
I have updated IP addresses of several of the mirror servers.
Re setting destination on rule “1” to RED:NTP & to RED:WHOIS on rule “5”… its not allowing me to do this… error: source and destination are the same.
Have left destination on NTP & WHOIS as ANY - I’m happy with this. Since following @pmueller blog article and implementing his suggestions my setup is already much more secure.
Appreciate the feedback too… security best practice is very much a process of continuous improvement. Many small improvement over time make for safe systems. I also appreciate @pmueller adherence to strict principles and promoting these amongst IPFire users.