Main problem with IPFire and other firewall distros

[anon22191203]

To me, all the firewall distros are selling a scam by providing a false sense of security. As it is, at default settings, a firewall will allow outbound connection from the LAN and allow incoming traffic on that connection. This is a major security risk which makes firewall distros a scam.

Firewall distros give an illusion of mitigating this risk by IPS and IDS but they are based on community rules, which may themselves be compromised and more importantly are not broad enough to cover all the possible malware behaviour. So why should anyone use a firewall distro? Almost all the latest operating systems block uninitiated incoming connections by default and the same function is performed by routers, firewall distros just seem to be adding overhead over these.

I think a good firewall distro will allow a user to block and allow incoming and outgoing connections as when they are happening at the connections view. And allow creating rules based on application as well.

[xperimental (Terry)]

@anon22191203

To me, all the firewall distros are selling a scam by providing a false sense of security. As it is, at default settings, a firewall will allow outbound connection from the LAN and allow incoming traffic on that connection. This is a major security risk which makes firewall distros a scam.

If you don’t speak russian it’s not the languages fault

@anon22191203

Firewall distros give an illusion of mitigating this risk by IPS and IDS but they are based on community rules, which may themselves be compromised and more importantly are not broad enough to cover all the possible malware behaviour. So why should anyone use a firewall distro? Almost all the latest operating systems block uninitiated incoming connections by default and the same function is performed by routers, firewall distros just seem to be adding overhead over these.

No. To seperate end user systems from network security.

@anon22191203

I think a good firewall distro will allow a user to block and allow incoming and outgoing connections as when they are happening at the connections view. And allow creating rules based on application as well.

You want to allow or disallow incoming and outgoing connections all day? Your go!
I can use any port for any application, no matter if it’s standardised for any use.

[anon22191203]

If you don’t speak russian it’s not the languages fault

If I’m not speaking Russian, it’s the Russians fault. They didn’t create proper language lessons. Are you saying there is a way to achieve it in IPFire?

@xperimental

No. To seperate end user systems from network security.

How’s that possible? If the firewall admin panel has to be accessed from another system connected to one of it’s interface?

@xperimental

You want to allow or disallow incoming and outgoing connections all day? Your go!
I can use any port for any application, no matter if it’s standardised for any use.

Yes, I wish to have that ability as well as create clever rules based on IP addresses and applications.
And a malware can also use any port for any thing, even HTTP and HTTPS. A regular 1080p movie on HTTPS from Netflix will take about 6GB, that’s a lot of bandwidth which a malware can use for anything.

[pmueller (Peter Müller)]

Hi,

To me, all the firewall distros are selling a scam by providing a false sense of security. As it is, at default settings, a firewall will allow outbound connection from the LAN and allow incoming traffic on that connection. This is a major security risk which makes firewall distros a scam.

personally, I am not happy with that default setting, either. However, there might be scenarios where you need to allow outgoing traffic at first (think about users trying to read the documentation without having internet access after they installed IPFire), and besides of that, we cannot release users from the burden of thinking themselves.

You are absolutely free to configure IPFire not to allow any connections at all, except for those you have explicitly allowed. For less sophisticated users, this would probably a step too far in first place.

Firewall distros give an illusion of mitigating this risk by IPS and IDS but they are based on community rules, which may themselves be compromised and more importantly are not broad enough to cover all the possible malware behaviour. So why should anyone use a firewall distro? Almost all the latest operating systems block uninitiated incoming connections by default and the same function is performed by routers, firewall distros just seem to be adding overhead over these.

Well, if this is your opinion, you are free to stop using IPFire (or any other firewall distribution) altogether. Malware protection is a broad and complex topic indeed, and there is no technical solution providing total security. A “firewall” is actually a packet filter in most cases, which means it works on OSI layers 3 and 4, so if your malware is encapsulated at layer 7, it won’t detect it by design.

I think a good firewall distro will allow a user to block and allow incoming and outgoing connections as when they are happening at the connections view.

Nobody will have a look at that table unless it is too late. Think about connections happening at night or outside business hours - those will go unnoticed unless they were blocked by a generic firewall rule configured before.

And allow creating rules based on application as well.

This is impossible as a firewall do not have that information. Again, we work on layer 3/4 here, where we don’t have any idea which application is emitting certain traffic, we only see IP addresses and port numbers.

And a malware can also use any port for any thing, even HTTP and HTTPS. A regular 1080p movie on HTTPS from Netflix will take about 6GB, that’s a lot of bandwidth which a malware can use for anything.

It certainly is. However, malware tends to be very small (< 1 MByte) and fits perfectly into traffic patterns generated by visiting web sites - JavaScript based browser exploits come to mind. One reason why researchers detected Stuxnet was its pure size - about an ordinary MP3 file. The amount of network traffic generated by a end-user client, however, is rarely - if ever - an indicator of malware activities.

I am sorry to say so, but your post indicates a lack of understanding regarding most basic network (security) techniques.

Thanks, and best regards,
Peter Müller

[anon22191203]

@pmueller

personally, I am not happy with that default setting, either. However, there might be scenarios where you need to allow outgoing traffic at first (think about users trying to read the documentation without having internet access after they installed IPFire), and besides of that, we cannot release users from the burden of thinking themselves.

You are absolutely free to configure IPFire not to allow any connections at all, except for those you have explicitly allowed. For less sophisticated users, this would probably a step too far in first place.

I didn’t know about this feature until I saw a thread asking a question related to it. Even I do not know how to allow connections if I set the firewall’s default policy to blocked.

@pmueller

Well, if this is your opinion, you are free to stop using IPFire (or any other firewall distribution) altogether. Malware protection is a broad and complex topic indeed, and there is no technical solution providing total security. A “firewall” is actually a packet filter in most cases, which means it works on OSI layers 3 and 4, so if your malware is encapsulated at layer 7, it won’t detect it by design.

If that is my opinion, I’m also free to ask for improvement in software and documentation. I’m aware that firewalls cannot detect malware going in and out of the network. I at least can block suspicious connections with firewall. Firewalls should be built around the objective of making it easy for users to find and block suspicious connections. This is not how it is in any of the firewall distros. What exactly prevents IPFire from providing an option to allow or block or create a rule at the connections view?

@pmueller

Nobody will have a look at that table unless it is too late. Think about connections happening at night or outside business hours - those will go unnoticed unless they were blocked by a generic firewall rule configured before.

You recently wrote a blog on your website about security, in which you said, users shouldn’t even trust the software vendors. If we accept this as a reasonable suspicion, the malware could already be inside, inbuilt in the OS and has free access to any website with the default firewall policy. By the time, I look at the connections view, the malware could have already connected and sent and received data and it is difficult to find which connection it is.

@pmueller

It certainly is. However, malware tends to be very small (< 1 MByte) and fits perfectly into traffic patterns generated by visiting web sites - JavaScript based browser exploits come to mind. One reason why researchers detected Stuxnet was its pure size - about an ordinary MP3 file. The amount of network traffic generated by a end-user client, however, is rarely - if ever - an indicator of malware activities.

I am sorry to say so, but your post indicates a lack of understanding regarding most basic network (security) techniques.

Thanks, and best regards,
Peter Müller

You say my post indicates lack of understanding regarding most basic network security techniques. What would you suggest I read to improve it?

And don’t you agree that with default firewall policy anything on the LAN side can access the Internet and anything on that connection will be allowed. If there is a malware on the LAN which entered through undisclosed means, it will have a free access. Doesn’t this pose a security risk?

Doesn’t allowing firewall’s admin panel to be accessed by a device connected to the firewall’s interface defeat the purpose of network security?

[anon33261557]

You complain about

@anon22191203

default settings, a firewall will allow outbound connection from the LAN

and you are overstrained with

@anon22191203

I do not know how to allow connections if I set the firewall’s default policy to blocked.

Sorry, you can’t be taken seriously.

[pmueller (Peter Müller)]

Hi,

I didn’t know about this feature until I saw a thread asking a question related to it. Even I do not know how to allow connections if I set the firewall’s default policy to blocked.

all right, so for the reference, the firewall default policy documentation is located here. If you set it to “DROP”, you will have to create firewall rules according to the reference documentation allowing desired traffic.

For your IPFire machine itself, this is:

• NTP traffic (destination port 123/UDP) for time synchronisation
• DNS traffic (destination ports and IP addresses depend on your configuration)
• Whois traffic if you take advantage of ipinfo.cgi (destination port 43/TCP, AFAIK it only uses the ARIN servers at the moment)
• HTTPS traffic for checking for and downloading updates to the IPFire mirror servers
• ICMP traffic of type 8 (echo-request, i. e. ping) to your gateway

No offense, but I doubt firewall newbies would be happy with configuring them before getting anything behind their IPFire machines to work. We cannot introduce default rules either, as they depend on your network environment.

If that is my opinion, I’m also free to ask for improvement in software and documentation. I’m aware that firewalls cannot detect malware going in and out of the network. I at least can block suspicious connections with firewall. Firewalls should be built around the objective of making it easy for users to find and block suspicious connections. This is not how it is in any of the firewall distros. What exactly prevents IPFire from providing an option to allow or block or create a rule at the connections view?

If you are able to identify “suspicious connection” based on their layer 3/4 source and destination, why don’t you create a matching firewall rule in the first place, so you do not need to keep watching the connection table?

Technically, there are number of ways to make existing connections terminate, one uglier than the other, and none of them would be RFC compliant to my knowledge. Except for some cases, IP is about end-to-end communication, not end-to-firewall-to-end one. We should not tamper with that.

If your adversaries are somewhat advanced, they will try to look their C&C connections innocent, such as talking TLS to port 443/TCP to an IP address in a well-known data center. It is not easy to find those connections, and one definition of “suspicious” never fits all users. Again, we cannot release users from the burden of thinking and knowing their networks.

You recently wrote a blog on your website about security, in which you said, users shouldn’t even trust the software vendors. If we accept this as a reasonable suspicion, the malware could already be inside, inbuilt in the OS and has free access to any website with the default firewall policy. By the time, I look at the connections view, the malware could have already connected and sent and received data and it is difficult to find which connection it is.

First, it was not my website, but that of the IPFire project instead. Second, it is reasonable to assume things are compromised already. Since they might be able to open up connections before you notice them looking at the connection tracking CGI, this is exactly the reason why we do not even think about implementing on-the-fly connection termination. Please think about what connections are normal and desired, define firewall rules allowing those, and drop the rest.

You say my post indicates lack of understanding regarding most basic network security techniques. What would you suggest I read to improve it?

Perhaps a book on TCP/IP networks and network security (in that order)?

And don’t you agree that with default firewall policy anything on the LAN side can access the Internet and anything on that connection will be allowed. If there is a malware on the LAN which entered through undisclosed means, it will have a free access. Doesn’t this pose a security risk?

It does. Because of the thoughts expressed above and in previous posts, I unfortunately do not see a reasonable alternative to that default policy. Besides, if a user is introducing an IPFire machine to his/her/its network, it’s default behaviour matches that of ordinary end-user ISP routers available - looking at outgoing connections, they will or will not keep working as they did before.

Doesn’t allowing firewall’s admin panel to be accessed by a device connected to the firewall’s interface defeat the purpose of network security?

This is why we require the admin to authenticate, and introduced the Guardian add-on to detect brute-force attempts and drop all traffic from the offending IPs. Make sure you monitor that list, as it might indicate internal clients being compromised.

As I wrote at blog.ipfire.org the other day, we expect our users (in spe) to read the documentation and come with basic network knowledge. You do not have to be an expert to run IPFire, which is a good thing, but will have to gain additional knowledge if you lacked it before. This thread so far illustrates that very clearly.

Thanks, and best regards,
Peter Müller

[ms (Michael Tremer)]

@anon22191203

To me, all the firewall distros are selling a scam by providing a false sense of security. As it is, at default settings, a firewall will allow outbound connection from the LAN and allow incoming traffic on that connection. This is a major security risk which makes firewall distros a scam.

Oooh what a bold statement.

I disagree. I even refuse to accept this as an opinion, because you are calling IPFire a “scam”. It isn’t that. You misunderstood what IPFire is and what it does. It is absolutely NOT this product that you “just buy and then you are secure.” This is what I am seeing in every commercial competitor’s marketing campaign. They could never admit that their solution is not providing “100%” of whatever it claims to provide.

We have been doing the opposite here. Peter just wrote a longish article last week and the blog is full of opinion pieces, calls for people to think and evaluate their own setup. We try to educate people and the wiki provides a lot of background information, which sadly is very often ignored by some users.

You will have to read through all of that. There is, again, not the one article or book that you read or talk that you watch and suddenly your network is secure. It is a process full of assessing what could go wrong and what could be done about it.

Naturally computer networks are the most secure when they do not exist. But we cannot really live without them. So there is a trade-off and that is a decision that will never be the same for two IPFire users.

We have people using IPFire in governments, hospitals, social care places, human rights organisations, but also data centers hosting cat videos and at home. There is never one configuration that is right for everyone and therefore we sometimes do not have the right defaults for you.

But compared to other things out there, IPFire’s web UI is incredibly intuitive and easy - although maybe not the prettiest one out there. But that isn’t what I care about.

@anon22191203

You recently wrote a blog on your website about security, in which you said, users shouldn’t even trust the software vendors.

Absolutely correct. Do not trust us. Of course you can, because we can prove to you that we have no backdoors and that we do not cut corners when we implement something.

This decision is up to everyone and depends again on what is important to you.

There is nobody who can make those decisions for you.

[anon22191203]

@pmueller

all right, so for the reference, the firewall default policy documentation is located here. If you set it to “DROP”, you will have to create firewall rules according to the reference documentation allowing desired traffic.

For your IPFire machine itself, this is:

• NTP traffic (destination port 123/UDP) for time synchronisation
• DNS traffic (destination ports and IP addresses depend on your configuration)
• Whois traffic if you take advantage of ipinfo.cgi (destination port 43/TCP, AFAIK it only uses the ARIN servers at the moment)
• HTTPS traffic for checking for and downloading updates to the IPFire mirror servers
• ICMP traffic of type 8 (echo-request, i. e. ping ) to your gateway

No offense, but I doubt firewall newbies would be happy with configuring them before getting anything behind their IPFire machines to work. We cannot introduce default rules either, as they depend on your network environment.

Thanks for this information. I knew about some protocols but not about other protocols. I agree with you, newbies and even experienced users will not like the default block all policy. If there was a midway between block all or allow all, it would be better, I don’t think it will be so easy to find such a midway.

@pmueller

If you are able to identify “suspicious connection” based on their layer 3/4 source and destination, why don’t you create a matching firewall rule in the first place, so you do not need to keep watching the connection table?

Technically, there are number of ways to make existing connections terminate, one uglier than the other, and none of them would be RFC compliant to my knowledge. Except for some cases, IP is about end-to-end communication, not end-to-firewall-to-end one. We should not tamper with that.

If your adversaries are somewhat advanced, they will try to look their C&C connections innocent, such as talking TLS to port 443/TCP to an IP address in a well-known data center. It is not easy to find those connections, and one definition of “suspicious” never fits all users. Again, we cannot release users from the burden of thinking and knowing their networks.

No I’m not able to identify suspicious connections just by looking at IP addresses, that is exactly what I think a firewall should simplify. I don’t know how. And you are correct, advanced attackers can use a data-center from Amazon, Google or other well known cloud service providers, it will be difficult to stop them.

@pmueller

First, it was not my website, but that of the IPFire project instead. Second, it is reasonable to assume things are compromised already. Since they might be able to open up connections before you notice them looking at the connection tracking CGI, this is exactly the reason why we do not even think about implementing on-the-fly connection termination. Please think about what connections are normal and desired, define firewall rules allowing those, and drop the rest.

Yes it is reasonable to assume the LAN is already compromised, which brings me to problem with default allow all policy. So if I turn on a system and look at the connections view in IPFire, I’ll see all active connections, if I think something is suspicious and there is option to block or allow or create a rule there, I can immediately block it there, if I have to create a rule for it by going to a different page after finding it in the connections view, by the time I create a rule and apply it, a lot could have been transferred.

@pmueller

This is why we require the admin to authenticate, and introduced the Guardian add-on to detect brute-force attempts and drop all traffic from the offending IPs. Make sure you monitor that list, as it might indicate internal clients being compromised.

As I wrote at blog.ipfire.org the other day , we expect our users (in spe) to read the documentation and come with basic network knowledge. You do not have to be an expert to run IPFire, which is a good thing, but will have to gain additional knowledge if you lacked it before. This thread so far illustrates that very clearly.

The Guardian add-on will protect against brute-force attacks however the admin password can be used on a compromised system and it’ll defeat the security because the malware will know the password and can do anything. It might even spoof it’s IP address and MAC address to make itself appear as an admin device.

I admit openly that I lack necessary knowledge about TCP/IP and IPFire however I do not see how filling in that knowledge make me implement rules which will make the network more secure. What you suggested at top seems to be a reasonable alternative.

[anon22191203]

@ms

Oooh what a bold statement.

I disagree. I even refuse to accept this as an opinion, because you are calling IPFire a “scam”. It isn’t that. You misunderstood what IPFire is and what it does. It is absolutely NOT this product that you “just buy and then you are secure.” This is what I am seeing in every commercial competitor’s marketing campaign. They could never admit that their solution is not providing “100%” of whatever it claims to provide.

I’d like to think of it as a fact not an opinion. I came to firewall distros from using firewalls on Windows OS, those firewalls provided features like making rules for applications, viewing all active connections, blocking selected connections and blocking everything. Rules on those software were application based rather than IP or port based, but one could create sophisticated rules involving IP and ports too. And I didn’t have to study any manual to create or manage those firewall software. The problem with these software is that it ran inside an OS, which itself could be compromised, and the malware can hide it’s processes and connections from the firewall. That’s why I chose firewall distro. I don’t think I have any misunderstanding about the role of firewall distros including IPFire, I think firewalls provide the ability to view connections and block which a user doesn’t want or is suspicious of.

@ms

We have been doing the opposite here. Peter just wrote a longish article last week and the blog is full of opinion pieces, calls for people to think and evaluate their own setup. We try to educate people and the wiki provides a lot of background information, which sadly is very often ignored by some users.

You will have to read through all of that. There is, again, not the one article or book that you read or talk that you watch and suddenly your network is secure. It is a process full of assessing what could go wrong and what could be done about it.

Naturally computer networks are the most secure when they do not exist. But we cannot really live without them. So there is a trade-off and that is a decision that will never be the same for two IPFire users.

We have people using IPFire in governments, hospitals, social care places, human rights organisations, but also data centers hosting cat videos and at home. There is never one configuration that is right for everyone and therefore we sometimes do not have the right defaults for you.

But compared to other things out there, IPFire’s web UI is incredibly intuitive and easy - although maybe not the prettiest one out there. But that isn’t what I care about.

I have to agree with the bolded part of your comment, IPFire’s UI is the most intuitive interface I saw in all the firewall distros, pfSense doesn’t have it, OPNSense doesn’t have it. There are really very intuitive and helpful features in IPFire which are not found in other firewall distros. Like the connections view for example, pfSense and OPNSense both have this feature tucked away under unintuitive menus, even then their implementation of it is bland, they don’t show country flags of the IP addresses, and they don’t allow the user to research the IP address from the connections view, which the IPFire does. However IPFire could improve even further by implement more features.

@ms

Absolutely correct. Do not trust us. Of course you can, because we can prove to you that we have no backdoors and that we do not cut corners when we implement something.

This decision is up to everyone and depends again on what is important to you.

There is nobody who can make those decisions for you.

IPFire uses Linux kernel, so it shares all the security issues of the Linux kernel. It isn’t just the question of backdoors, does IPFire provide management of the firewall which is secure.

[luani (Leo Hofmann)]

@anon22191203

I think firewalls provide the ability to view connections and block which a user doesn’t want or is suspicious of.

I disagree. This is what the software firewalls on windows want you to believe. Their entire user interface is built around this experience - big scary notifications about suspicious activity make you think you always have to be one step ahead and manually inspect every connection.

But once the traffic leaves your computer, there is no reliable way to identify the application that initiated the transfer. IPFire (or any firewall distro, for that matter) isn’t something that you just plug between your ISP’s router and your computer, magically making you network secure.

[anon22191203]

@luani

I disagree. This is what the software firewalls on windows want you to believe. Their entire user interface is built around this experience - big scary notifications about suspicious activity make you think you always have to be one step ahead and manually inspect every connection.

Software firewalls in Windows OS allow creation of broad rules which apply to the entire traffic going in and out of the system. Even then they provide view of all the active connections sorted by the application which is using a particular and to what IP it is connected to with the option to terminate any or all connections. That in fact is the very definition of a firewall, to allow or disallow connections based on IP addresses, ports or any other user preference.

@luani

But once the traffic leaves your computer, there is no reliable way to identify the application that initiated the transfer.

I understand this part, Mr. Peter Mueller explained it in detail earlier. TCP/IP protocol is old, perhaps someone can suggest RFC to modify it to make packets conforming to these protocols carry the application name with a hash.

@luani

IPFire (or any firewall distro, for that matter) isn’t something that you just plug between your ISP’s router and your computer, magically making you network secure.

I always knew that installing a firewall doesn’t make my system or network magically secure, I don’t know if this is a misunderstanding or putting words in my mouth. It’s just that firewall distros seem to lack certain functionalities which are necessary in firewalls. Some of them are implemented in such a way that a user has to invest significant amount of time and energy to learn them, or even find where they are.

Firewall distros are where Windows was before the Mac OS System 1.0 was released.

[trymes (Tom Rymes)]

You. I am accusing you of trolling. Intentionally or not, you’re trolling here - and to be clear, I am using the traditional definition of that term, not the more modern one. Posting an inflammatory and accusatory question without knowing anything about the subject, and without being able to posit an informed and workable solution is only going to result in a mess.

You have made clear that you don’t even know how to create a firewall rule to allow traffic through the firewall. This means that your original accusation is uninformed, as you clearly don’t know much about the subject.

If your original and follow up posts had stated “I’m new to network security, but my understanding is that the default settings are insecure for these reasons. Am I misinformed?”, then a reasonable discussion could have ensued. Unfortunately, your post and your replies are written, intentionally or not, in such a way that reasonable discussion will not follow. Learn about a subject before accusing others of not practicing it well.

[bbitsch (Bernhard Bitsch)]

I hope, I will not be punished for feeding the troll.

Just some thoughts about this thread and your opinion:

• If you know how to define rules, you should know what a stateful firewall based on iptables is.
• You are mixing firewalls on own devices with software firewalls embedded into the OS of the end user device. Only when running in the same system, a program can know and manage traffic of other applications.
• In IPFire you can manage your system on the console ( monitor/keyboard or serial ‘terminal’ ). You do not need to use the web interface. But if you use it, you should use it as the main UI. The structure of IPFire demands this!
• The default policy is thus, that most systems are satisfied with it. IMHO, it is necessary to do a first setup of the system. If you know another way, just discuss it here or in the developper channels.

BTW: It is not true, that each device can connect and transfer data through IPFire. Devices must be granted access by somewhat network management. On GREEN ( and ORANGE ) this is done by allowing wired connection. On BLUE this is the so called ‘Access to blue’ functionality, identifying devices by their WLAN MAC address.

[anon22191203]

@bbitsch

I hope, I will not be punished for feeding the troll.

I’m not the troll here, you are, Tom Rymes is and makers of firewall distros are.

@bbitsch

Just some thoughts about this thread and your opinion :

• If you know how to define rules, you should know what a stateful firewall based on iptables is.

I know how to define rules and what a stateful firewall is.

@bbitsch

You are mixing firewalls on own devices with software firewalls embedded into the OS of the end user device. Only when running in the same system, a program can know and manage traffic of other applications.

I thought features which I was used to in firewall applications would be present in firewall distros too as well as more advanced versions of those. According to Peter some of them cannot be possible because firewall distros don’t have access to other layers of OSI model. Which I understand however there are still other things which can be there but are not found.

@bbitsch

In IPFire you can manage your system on the console ( monitor/keyboard or serial ‘terminal’ ). You do not need to use the web interface. But if you use it, you should use it as the main UI. The structure of IPFire demands this!

By console do you command line interface? Do you have any idea how difficult it is? Firewall makers can also provide the administration on gui on the system on which the firewall is installed rather than make users access the UI through web interface which is only possible when there is another device to access it from.

@bbitsch

The default policy is thus, that most systems are satisfied with it. IMHO, it is necessary to do a first setup of the system. If you know another way, just discuss it here or in the developper channels.

I do not know of another way, I suggested someone make a RFC and TCP/IP protocols implement a new feature which requires application name and a hash on the packets. That seems to be the best way, until something like that happens. I cannot think of anything else.

[luani (Leo Hofmann)]

@anon22191203

I understand this part, Mr. Peter Mueller explained it in detail earlier.

Then why do you keep comparing IPFire to a windows software firewall? These are two different approaches and can never offer the same features.

@anon22191203

I don’t know if this is a misunderstanding or putting words in my mouth

Honestly, both. There is a reason why hardware firewalls have to rely on packet inspection, pattern detection and complex rule sets to detect suspicious traffic.
You seem to expect certain features to exist or to be implemented, but you lack the experience to know what could actually be done. Instead you accuse the firewalls of being a scam and insecure because they don’t (can’t) offer the fancy user interface you expected. So in my opionion, you are expecting the firewall distro to (magically?) do something that is not possible.

If I am wrong here, you are welcome to share documents/RFCs on how to do it.

[anon22191203]

@luani

Then why do you keep comparing IPFire to a windows software firewall? These are two different approaches and can never offer the same features.

I brought up firewall application to clarify a point. It was only in that post and a one other post that I compared them, after I didn’t compare them any more. I understand the limitations of the firewall distro because they cannot access all the layers of OSI model.

@luani

Honestly, both. There is a reason why hardware firewalls have to rely on packet inspection, pattern detection and complex rule sets to detect suspicious traffic.
You seem to expect certain features to exist or to be implemented, but you lack the experience to know what could actually be done. Instead you accuse the firewalls of being a scam and insecure because they don’t (can’t) offer the fancy user interface you expected. So in my opionion, you are expecting the firewall distro to (magically?) do something that is not possible.

If I am wrong here, you are welcome to share documents/RFCs on how to do it.

At least be honest and don’t twist my words and misrepresent what I said. I’m not asking for a fancy user interface, I’m just asking for features which are possible but are not implemented. Like the ability to allow, block or create firewall rules from the connections view. Is that so difficult to implement?

I think people here are more knowledgeable than me to create an RFC to ask for a new feature, like requiring application name and a hash on the packets conforming to TCP/IP protocol.

[luani (Leo Hofmann)]

@anon22191203

Firewall makers can also provide the administration on gui on the system on which the firewall is installed

They could, but most user would never use this feature. Most firewalls are running “headless” in a data center. Furthermore, some systems have no graphics hardware at all.

I do agree that access to the configuration is a sensitive area and must be carefully considered.
But this is a completely different subject than the one you started with.

@anon22191203

I’m just asking for features which are possible but are not implemented

Then you should start all over again. In the beginning you don’t ask for a new feature. Instead you claim that IPFire is a scam and basically compromised out of the box. So you shouldn’t be surprised if there’s trouble.

[trymes (Tom Rymes)]

Here’s the long and the short of it:

1. You don’t have the skill to create a system that works the way you want it to (neither do I, FWIW).
2. This means that you must rely on others who do.
3. You will either need to pay those people to develop something for you, or:
4. You will need to convince someone doing it for free (like the IPFire developers) that they should do it the way you think they should. (HINT: Insulting them and calling their ethics into question isn’t a good first step)
5. Based on this thread, you lack the interpersonal communication skills to achieve #4, so I will suggest that you either:
6. Start over and learn how to constructively engage in the community surrounding a free software project, or:
7. Buy a commercial solution that meets your needs.

Your mileage may vary.