Fanvil possible firmware issue, non-standard port

Dashrender

I'm setting up a new service with Fanvil X5U phones.

My new service prefers to use a non standard port for SIP for a bit of security through obscurity and it helps keep the logs a bit more quiet.

That said, the Fanvils have a problem where they are seemingly randomly rebooting and separately they are timing out connecting to the PBX.

This has happened over two different firewalls, and multiple locations.

Investigating the logs have shown that the phones are still making occasional inquires on port 5060 - which should never happen!

Dashrender

Current potential solution is to move back to port 5060 to see if things will stabilize.

JaredBusch

@Dashrender said in Fanvil possible firmware issue, non-standard port:

and it helps keep the logs a bit more quiet.

What logs the fail2ban? who cares? That is the point of it after all. Make the bans permanent and it will not be a huge issue.

scottalanmiller

@JaredBusch said in Fanvil possible firmware issue, non-standard port:

@Dashrender said in Fanvil possible firmware issue, non-standard port:

and it helps keep the logs a bit more quiet.

What logs the fail2ban? who cares? That is the point of it after all. Make the bans permanent and it will not be a huge issue.

We've seen that kill fail2ban so that it ties up so many CPU cycles that performance drops.

JaredBusch

@scottalanmiller said in Fanvil possible firmware issue, non-standard port:

@JaredBusch said in Fanvil possible firmware issue, non-standard port:

@Dashrender said in Fanvil possible firmware issue, non-standard port:

and it helps keep the logs a bit more quiet.

What logs the fail2ban? who cares? That is the point of it after all. Make the bans permanent and it will not be a huge issue.

We've seen that kill fail2ban so that it ties up so many CPU cycles that performance drops.

Not once ypou make the fail2ban setting make them permanent. then it is simply iptables dropping it.

scottalanmiller

@JaredBusch said in Fanvil possible firmware issue, non-standard port:

@scottalanmiller said in Fanvil possible firmware issue, non-standard port:

@JaredBusch said in Fanvil possible firmware issue, non-standard port:

@Dashrender said in Fanvil possible firmware issue, non-standard port:

and it helps keep the logs a bit more quiet.

What logs the fail2ban? who cares? That is the point of it after all. Make the bans permanent and it will not be a huge issue.

We've seen that kill fail2ban so that it ties up so many CPU cycles that performance drops.

Not once ypou make the fail2ban setting make them permanent. then it is simply iptables dropping it.

Maybe I'm missing something, going from really long to perm changes the processing? Does it switch how it is recorded?

JaredBusch

@scottalanmiller said in Fanvil possible firmware issue, non-standard port:

@JaredBusch said in Fanvil possible firmware issue, non-standard port:

@scottalanmiller said in Fanvil possible firmware issue, non-standard port:

@JaredBusch said in Fanvil possible firmware issue, non-standard port:

@Dashrender said in Fanvil possible firmware issue, non-standard port:

and it helps keep the logs a bit more quiet.

What logs the fail2ban? who cares? That is the point of it after all. Make the bans permanent and it will not be a huge issue.

We've seen that kill fail2ban so that it ties up so many CPU cycles that performance drops.

Not once ypou make the fail2ban setting make them permanent. then it is simply iptables dropping it.

Maybe I'm missing something, going from really long to perm changes the processing? Does it switch how it is recorded?

Maybe you are just being intentionally stupid today.. I don't know.

But it is 100% impossible for fail2ban to use CPU if nothing ever gets to fail2ban because it was blocked by iptables.

With VitalPBX, by default, things hit is 3 times before fail2ban blocks it (adds it to iptbales). So it would be impossible for a generic attack of any kind kill the CPU. It would have to be a dedicated DDoS. While those can certainly happen, changing the port would not fix it. Those are focused attacks and the attacker will know the port you have SIP on.

scottalanmiller

@JaredBusch said in Fanvil possible firmware issue, non-standard port:

@scottalanmiller said in Fanvil possible firmware issue, non-standard port:

@JaredBusch said in Fanvil possible firmware issue, non-standard port:

@scottalanmiller said in Fanvil possible firmware issue, non-standard port:

@JaredBusch said in Fanvil possible firmware issue, non-standard port:

@Dashrender said in Fanvil possible firmware issue, non-standard port:

and it helps keep the logs a bit more quiet.

What logs the fail2ban? who cares? That is the point of it after all. Make the bans permanent and it will not be a huge issue.

We've seen that kill fail2ban so that it ties up so many CPU cycles that performance drops.

Not once ypou make the fail2ban setting make them permanent. then it is simply iptables dropping it.

Maybe I'm missing something, going from really long to perm changes the processing? Does it switch how it is recorded?

Maybe you are just being intentionally stupid today.. I don't know.

But it is 100% impossible for fail2ban to use CPU if nothing ever gets to fail2ban because it was blocked by iptables.

With VitalPBX, by default, things hit is 3 times before fail2ban blocks it (adds it to iptbales). So it would be impossible for a generic attack of any kind kill the CPU. It would have to be a dedicated DDoS. While those can certainly happen, changing the port would not fix it. Those are focused attacks and the attacker will know the port you have SIP on.

The issue that we have, and I thought that I explained, is that after fail2ban puts things into iptables (because they were blocked), the list in iptables gets so long that it eats all of the CPU.

You were saying that if it was PERMANENTALY banned by fail2ban, it would bypass the CPU load of looking it up in iptables, but it's the same list whether it is temp banned or perm banned. So moving something to perm would not fix the problem of needing to process that super long list.

JaredBusch

You clearly stated fail2ban actions not iptables actions. They are not the same thing.

@scottalanmiller said in Fanvil possible firmware issue, non-standard port:

We've seen that kill fail2ban so that it ties up so many CPU cycles that performance drops.

That said, managing iptbales would be the admin's job. Monitoring the bans and jsut blocking entire CIDR would be a normal need.

Preemptive IP blacklisting is also a normal, intelligent thing to do. By geo, common known CIDR, etc.

There is zero reason to leave any PBX system, for a typical American SMB, open to the entire planet by default.