Core 155 ALG removal: how to see if it's used at all?

In Core 155 the ALGs will be removed. In the Blog you write that this might affect VOIP and other services. Is there a possibility to see in Core 154 if any ALGs are being used at all? I am using VOIP in several ways (Skype, Fritzbox, Microsip) but I don’t have a deep understanding what is necessary for them to work. So it would be a great help if there is a possibility in the GUI to see if ALG is used so I can have an idea if I need to change anything. Unfortunately I don’t have a test-machine available yet.

1 Like

I’m also interested in this. Would like to know if FTPES will still work (FTP is mentioned in the blog post, but since this is encrypted (but only after the connection has been established), I am not sure).

edit: Don’t have a QA firewall to test this.

1 Like

Hi,
Remove of ALGs is unacceptable at such short notice.
Many of us have sites with SIP or VPN that require an ALG or two enabled.
Rather than remove, have the defaults as set to disabled.
If the IPFire team wish to alienate their user base, they’re going the right way about it.

On a similar topic, how about a “Popularity Contest” vote section on this forum, so that we may submit feature requests and then have a vote the most popular ones, say monthly.
I don’t want to have to join the developer mailing list, yet another account to maintain.
This forum is your community, so this would be the place to suggest/ask end users about new features.
Thanks

2 Likes

Firewall > Firewall Options menu, to see which ALG enabled.

2 Likes

Hi,

Remove of ALGs is unacceptable at such short notice.

I absolutely disagree: Core Update 155 won’t reach testing within this week, and unless @ms decides to work in time lapse, I would not expect a testing version to be released in two weeks either.

Usually, we keep a release in testing for about two weeks - which means that you have got at least four weeks from today to evaluate whether you rely on ALGs or not. That is plenty of time.

You can simulate an installation of Core Update 155 by disabling all ALGs and rebooting your IPFire machine. Even if you do not have a testing environment (that phrase was more meant to users running IPFire in an enterprise), you could try that on a Sunday night, and see if your VoIP equipment works fine afterwards.

(Apparently, I should have mentioned that in the blog post… :expressionless: )

Many of us have sites with SIP or VPN that require an ALG or two enabled.

VPN has nothing to do with ALGs.

Rather than remove, have the defaults as set to disabled.

This isn’t helping, as existing installations will remain vulnerable.

To stress the impact of NAT Slipstreaming once more: Any vulnerable browser in your network puts any other device at risk of being directly contacted by attackers arbitrarily, just by visiting a malicious website.

This requires immediate attention - and there is no other technical answer to this vulnerability in scope of IPFire.

If the IPFire team wish to alienate their user base, they’re going the right way about it.

Well, we are developing an operating system for security purposes here. If some of our users rather wish to sit within an insecure network, a 50$ proprietary CPE device probably matches their expectations better than IPFire does.

Best regards,
Peter Müller

8 Likes

Excuse my ignorance,

What if you put the VOIP server on a different NAT / VLAN. so you don’t expose your other devices? Would that require ALG enabled?

I disabled ALG already a little while ago. Because I saw that there are already plenty of tutorials how to do the attack.
could be a major issue for your good night sleep.

I am voting for ALG removal if that means I can avoid my TCP/UDP services being exposed.

2 Likes

None of the proprietary protocols will be affected.

Only the protocols listed will be affected, and for VoIP the only ones are H.323 and SIP.

I would suspect that nobody uses H.323 any more. SIP is a lot more common. You can check if you are having any active connections with this command:

grep helper= /proc/net/nf_conntrack

This will list all connections. If there is no output (which will be the case for 99% of users), then you are not using the helpers and you should disable them all immediately.

Any encrypted connection will not be affected by the ALGs because they snoop on the control connection which is not possible for encrypted connections. So no worries here either.

Okay, let’s talk a little bit about this opinion. It isn’t in our opinion. We are building a secure firewall here and we have found no other technical option - because there isn’t one. We actually recommend to disable the ALG helpers IMMEDIATELY.

We are giving you a lot of time to prepare for this and we have sent an announcement in advance to give you the time to prepare for it. You should use that time to identify any problems if you think that you will have some instead of complaining to it. If you are considering using another firewall I can recommend reading the articles from the researchers. They list all affected firewalls which are all that have an ALG.

No, this is not an option. It is the same as opening all ports to all devices. You do not need a firewall for that.

I am not here to make everyone happy. I am here to secure my network.

Absolutely not. You are demonstrating very well why this is a really bad idea.

We have spent many hours talking to each other about this specific security vulnerability. We have had calls, we read through tons and tons of literature, research papers and code to find out how the attack works and what can be done to mitigate it.

It is great that you have your opinion, but without doing your research first, it does not matter to me. If you have the time to spend, please go ahead. If you find a better solution, I am happy to hear it.

Many researchers and our time couldn’t find anything better than removing this ancient and generally vulnerable technology.

Thank you very much for valuing our time so much by pretending it is just another opinion.

This is a support forum. You can talk about whatever you want here, but development work is being carried out on the development lists and the bug tracker.

Let’s say your SIP server is on the ORANGE network and your phone is on the GREEN one. In that case you do not have NAT and you won’t need the ALG. You only need it when you are hosting a server behind IPFire and have clients on the Internet, or when you are using devices that have a broken SIP stack.

6 Likes

Meant PPTP, not VPN, my error.

1 Like

This just came up in my news today.
Food for thought incase anyone had missed it.

Google Chrome to block port 554 to stop NAT Slipstreaming attacks

3 Likes

Blockquote Firewall > Firewall Options menu, to see which ALG enabled.

Thank you for helping us protect our networks. I appreciate the additional information presented here by all.

I do think it would have been helpful to have had the steps mention above of checking/turning off ALG services in the current core version.

2 Likes

As a quick test, I disabled all ALGs in Firewall > Firewall Options menu and then bounce my VOIP adapter to see if the phone still worked. All is good so far :sunglasses:

[edit] I have not yet rebooted ipfire – pending next quiescent user break

A reboot is required to activate the changes.

1 Like

Okay, did the reboot – all is still good :smiley:

Thank you for your feedback and showing the others that this change isn’t as bad as it sounds.

2 Likes

Thanks for the help. Sorry, I’m not a pro so I just repeat: I log in as root, type “grep helper= /proc/net/nf_conntrack” and hit enter, right? On the screen nothing happens, And this while a SIP call is established.

That means I’m OK, right? Or will the output of the grep command be written in a file and not shown on the screen?

The reason I’m asking is that since I turned off all ALG, we had several calls that were cut-off after around 15 minutes. Now I’m not sure if it’s due to the ALG turned off or if it is just coincidence.

All users of IPFire are invited and have the possibility to participate in development!
That’s how open source community development works.
If you want a product with features just tailored to your needs and a guarantee for functioning, you have to pay for it.
BTW, then you should not use Linux based products at all.
My 2c

Bernhard

1 Like

That means that you have no connections open that are using the helper. You can disable them all without any problems.

That sounds like SIP Session Timers. I would recommend to check the manual of your VoIP system.

As far as I understand, you should do the check ( grep helper= /proc/net/nf_conntrack ) while your SIP call and with setting ‘ALG for SIP = on’.
If your SIP call needs the ALG, it should be listed.
If no ALG is used grep returns with no output.

You do not necessarily have a call going, because the SIP connection is always there when the phone is registered to the provider/PBX.

1 Like

Thanks a lot! I had ALG for SIP =on, called my mobile phone and then did the grep command. There was no output at all. The same with no call.
Thanks Bernhard Bitsch and Michael Tremer a lot for your help and explanation!