Question re Fireinfo

Hi,

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 ?

Cheers,

Hi, I think you should too block outgoing traffic, it mean traffic originated from the IPFire system.

Cheers.

Hi,

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.

Thanks, and best regards,
Peter Müller

Hi,

yes, this was one of the main intention behind that post. Thanks for mentioning it. :slight_smile:

Thanks, and best regards,
Peter Müller

I suggest to rename it to the correct terms.

to

firewall behaviour is set to block for forward and outgoing.

Otherwise this only confuse the masses :wink: Including me.

Because if outgoing is not blocked, also fireinfo is not blocked and so your question makes no sense for me :wink:

@pmueller Peter, what do you think?

Hi,

Otherwise this only confuse the masses :wink: Including me.

thanks for clarifying this. :slight_smile:

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.

Thanks, and best regards,
Peter Müller

I also want clarify something :wink:

Noone have ever spoken that he wants block fireinfo :wink:

As i said this text confuse the masses :stuck_out_tongue_winking_eye:

Thanks @pmueller and @tulpenknicker and @fiodor for taking time to respond.

I admit I did confuse my question by not mentioning that I have all OUTGOING traffic blocked by default - apologies for this.

I remain curious how fireinfo travels back to ipfire servers.

So to be clear this is what I have:

Default behaviour:

Outgoing Firewall rules:

Evidence that my fireinfo profile is being updated:
2020-09-20_8-03-52

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:

Note: I’m more than happy to send my profile back to ipfire servers - just trying to understand the process.

Thanks again guys.

Dont worry thats what i thought from the beginning :wink:

Confirm you :wink:

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.

1 Like

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.

Cheers

Thanks @tulpenknicker - I agree with your suggestion to limit use of ANY where possible.

Issue I have is easily setting up a Firewall Group with IPFire mirror addresses from here: https://mirrors.ipfire.org/

Do I create a Location Group based on country -or- a Host Group based on IP addresses?

Perhaps there should be a Preset Host Group for IPFire assets.

How do you have your destination setup on outgoing HTTPS traffic from Firewall?

R

Thanks @fiodor

I tried the Location Group approach (with about 6 countries as a test) and the PAKFire refresh could not find a mirror.

I wonder if all countries in the mirror list need to be included for this Location approach to work?

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.

Thanks again @tulpenknicker and @fiodor - you both motivated me to setup OUTGOING firewall properly.

First, I created a Hosts Group called IPFire Mirrors
2020-09-20_11-29-08

Then amended Outgoing Firewall Access Rule 4 accordingly:
2020-09-20_11-31-45

Then re-ran a test of Pakfire refresh - all good!
2020-09-20_11-33-51

Re outgoing NTP traffic - I am leaving as destination ANY - the NTP server list is far to extensive to include all.

And finally I have tightened the outgoing ICMP rule to AU (Australian) IP addresses only - this where I am based.
2020-09-20_11-49-33

Hope this does the trick and always open to comments and ideas for further improvements.

Cheers,

2 Likes

Hello Robert,

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 :wink:

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 :wink:

Mirrorlist IPFire



mirror.aarnet.edu.au        202.158.214.106

mirror.easyname.at          77.244.244.134

mirror.datacenter.by        178.124.134.106

mirror.csclub.uwaterloo.ca  129.97.134.71

muug.ca                     208.81.1.244

mirrors.dotsrc.org          130.225.254.116

mirror.cedia.org.ec         201.159.221.67

mirror.espoch.edu.ec        45.184.102.116

mirror.uta.edu.ec           192.188.46.165

ftp.fau.de                  131.188.12.211

ftp.gwdg.de                 134.76.12.6

ipfire.earl-net.com         188.68.48.191

ipfire-mirror.eissler.pro   5.9.11.78

mirror1.ipfire.org          81.3.27.38

mirror7.ipfire.org          176.9.88.124

ftp.cc.uoc.gr               147.52.159.12

quantum-mirror.hu           195.38.126.147      78.131.56.189

ftp.yz.yamagata-u.ac.jp     133.24.248.16       133.24.248.17       133.24.248.18       133.24.248.19

mirror.marwan.ma            196.200.160.70

ftp.nluug.nl                145.220.21.40

mirrors.up.pt               193.137.29.15

ftp.acc.umu.se              194.71.11.173       194.71.11.165

ipfire.infania.net          194.132.225.213

firemirror.scp-systems.ch   188.165.232.76      149.202.12.120

mirror.onesystems.ch        109.164.249.218

www.mirrorservice.org       212.219.56.184

mirror.clarkson.edu         128.153.145.19
1 Like

Thanks again @tulpenknicker.

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.

Cheers,

1 Like

If you do it correct this works 100%

  • Source Firewall RED
  • Destination Standard networks RED

If you choose Destination Standard networks RED its in the sense of sending data to internet any but its not to any Zones what we dont need here :wink:

1 Like

Your suggestion worked.

Thanks for your support and persistence. Greatly appreciated.

Re your earlier question about why I’m not going out via a proxy… that’s next on the to-do list.

Cheers,

1 Like