Port 5060 open on Incoming Firewall Access

Security Firewall Rules
1

Hello,

Port 5060 is open from the outside without being redirected …
It does not appear in any WebGui rule or in the config file. How can we remove this rule ?

Thank you :wink:

1 Like
2

Hi,

people seem to bump into this behaviour a lot these days (see also this thread). At the time of writing, we are still unaware of a bug in IPFire, the incidents known and clarified so far were caused by user misconfigurations.

Please give us more details:

  1. Which protocol? TCP? UDP?
  2. Please post the output of iptables -L -n -v here (feel free to redact any public IP addresses, if necessary).
  3. Did you made any changes to your IPFire machine, which you did not through the web interface? Especially editing firewall.local? If so, which were they?

Thanks, and best regards,
Peter Müller

1 Like
3

Hello,

Thank you for your response on this subject.

  1. This is port 5060 / tcp (seen using an nmap from the outside).
  2. No reference to port 5060 in the output of the iptable command.
  3. And there is no reference to this port in the config and firewall.local files

This rule cannot be found in the system.

Thanks :wink:

4

Hi,

would you please post the output of that command anyway?

Does this implicate you made changes to firewall.local? If so, please post the files’ content here.

EDIT: In order to see how packets to port 5060 are processed exactly, could you please execute

iptables -t raw -j TRACE -p tcp --dport 5060 -I PREROUTING

on your IPFire, then connect to port 5060 on IPFires’ RED interface from the internet, and post the trace log lines here? For the latter,

grep "kernel: TRACE:" /var/log/messages

should be sufficient.

Thanks, and best regards,
Peter Müller

3 Likes
5

Hi, I’m not the Original Poster of this thread, but I tried on my ipfire and the port 5060 is correctly blocked (I can see it in the logs), so no problems here. :wink:

6

Hello
We discovered this by running an nmap command on our public IP address from the outside. Not from the logs.

Thank you :wink:

7

It would be nice, if you can repeat your nmap scan with Peter’s suggestions.
The output could enlighten the case. To repeat the fact found, isn’t very helpful.

1 Like
8

Hi, of course I tried from an outside connection to check if the port was open. This is the result from nmap:

PORT     STATE    SERVICE
5060/tcp filtered sip

So, as you can see, the port is not open, and from my ipfire logs resulted the related DROP_INPUT packet. No problems here. :wink:

1 Like
9

Hi,

folks, this is not how support works here.

I have asked for detailed information in this post, and if you want us to diagnose and eventually solve your problem, I expect to get those information provided by you. As of now, you haven’t.

So, one last time: @looping81, would you please run the commands previously mentioned and post their outputs here?!

Thanks, and best regards,
Peter Müller

3 Likes
10

@boss With us, the port is not in filtered state but open state

@pmueller I will not put the result of “iptables -L -n -v” command on this forum for obvious security reasons. All I can say is that an “iptables -L -n -v | grep 5060” returns no results.

All the rules on our IpFire have been configured by the webgui

Thanks :wink:

11

In an SSH session to ipfire, you can try with a:

netstat -l -n -t

to check all listening TCP ports on your ipfire system. If there is no 5060, then it’s likely you have another device (a modem?) on top of ipfire with that port open.

12

This isn’t standard! My system blocks/filters port 5060 on red.

Without these informations we cannot help.
If you have security concerns, just send your logs to Peter per PM.
BTW: Your system seems not to have the standard security of IPFire, see your problem.

1 Like
13

Hi,

then send me these outputs (and especially the TRACE lines) via DM.

I am neither willing nor able to help you without having these information.

Thanks, and best regards,
Peter Müller

1 Like
14

@boss Yes, you’re right. After a test on RED interface with nmap command in a machine between router and IpFire, port 5060 is well in filtered state on IpFire. All seems to be OK

Thanks all for the help :wink:

15

@looping81 I’m glad to have been of help, but personally I would be worried of that open port on your router, unless that’s the intended behavior. :wink:

1 Like
16

@boss I don’t know if this is the expected behavior. We will check with our provider to see what is happening. Anyway, we don’t have access to these routers

Thanks again :wink:

17

Glad to hear that your IPFire system behaves as expected.
And also to hear that isn’t your WAN access device, but that function is done by a ‘router’ ( ISP owned ?).

This information is essential for assistance by the community. And once more, if you use a device for internet access not controled by you, why can’t you send the relevant logs because of ‘security reasons’?

1 Like
18

@bbitsch Because we work in the public sector and in addition to providing us with the internet, this provider also connects us to various government bodies. The IpFire rules concern a lot of links between these partners that we cannot reveal.
It is also for this reason that we do not have full access to routers.

19

Could you describe your installation in short, nevertheless?
This would help us much for a support. Alternatively your provider could do full support, internet access and connection to your LAN through IPFire.
‘Standard installations’ consist of a device for WAN access ( modem / router ) and IPFire as internet gateway for the local networks.
With this RED either gets the public IP of the access or gets a private IP of the access routers LAN. In the latter case your public IP doesn’t identify your IPFire system but the router, so port tests on the public IP don’t test IPFire’s RED interface.

2 Likes