The client has scanned the server and found that the version of Apache Tomcat has to be 9.0.40 or higher. I thought it would make sense to go to 9.0.56 because that is the latest. What version of Tomcat do both Brekeke 3.10.6.4 and 3.10.6.5 run? Thank you! Do you have any reasons to use a Tomcat at ...

Hi ajlindy, Have you looked at the following wiki topic "How to update web server (Apache Tomcat)" ? https://docs.brekeke.com/sip/update-web-server OK, so I ran into several issues tonight. 1. I made a backup of webapps folder 2. I deleted Brekeke 3. I installed Tomcat 9.0.56 on its own 4. I ...

Log4j packages we are using in our product are not affected by the vulnerability called CVE-2021-44228. There are two Log4j packages in the product. - Log4j bundled in the GUI part (Tomcat). It is not affected because it is the customized Log4j (not default). Please refer to https://bishopfox.com ...

Log4j packages we are using in our product are not affected by the vulnerability called CVE-2021-44228. There are two Log4j packages in the product. - Log4j bundled in the GUI part (Tomcat). It is not affected because it is the customized Log4j (not default). Please refer to https://bishopfox.com ...

Niloc wrote:Hi ajlindy,

Have you looked at the following wiki topic "How to update web server (Apache Tomcat)" ?

https://docs.brekeke.com/sip/update-web-server

Does Brekeke SIP Proxy fall prey to the Log4J vulnerability?

Hi ajlindy, Have you looked at the following wiki topic "How to update web server (Apache Tomcat)" ? https://docs.brekeke.com/sip/update-web-server Yes I have, and I plan on doing those steps - was just curious if there were any other Gotchas that maybe the guide wouldn't be talking about that ...

1. Brekeke Product Name and Version: SIP Server 3.X 2. Java version: 3. OS type and the version: Windows 2019 64-bit 4. UA (phone), gateway or other hardware/software involved: 5. Your problem: Our security settings have really locked us down and when we try to install Brekeke SIP Proxy on a Windows ...

1. Brekeke Product Name and Version: Advanced Edition 3.10.6.4 2. Java version: Current, but unknown 3. OS type and the version: Windows 2016 64-bit 4. UA (phone), gateway or other hardware/software involved: 5. Your problem: I'm going to have to upgrade from the current version of Brekeke I have ...

1. Brekeke Product Name and Version: 3.7.5.0/466 2. Java version: 1.8.0_171 3. OS type and the version: Windows Server 2008 4. UA (phone), gateway or other hardware/software involved: 5. Your problem: We have a client who's vendor changed the SIP trunk we have been dealing with. Before, we just had ...

So, some more information and then a question. One, we have an A Team and B Team. Both have a literal Front and Back NIC available, and only the A Front and B Front are plugged in. The Automatic Metrics were set for the Private connection NIC, so I changed it to 5. It was also set for Automatic for ...

Thank you, I will dive in!

Laurie wrote:The "route" command on the OS will help you.

https://docs.microsoft.com/en-us/window ... ute_ws2008
https://www.computerhope.com/routehlp.htm

1. Brekeke Product Name and Version: 3.x 2. Java version: 8.1 3. OS type and the version: Win Server 2k16 4. UA (phone), gateway or other hardware/software involved: N/A 5. Your problem: We have servers with two NIC cards. Each NIC has two ports. We team the ports together so we have A team and B ...

That's beautiful. I think that's what we need, Niloc.

Thank you! I'll take it back to the client and see what they think.

For me, 35 seconds was an arbitrary number so that if we didn't get anything from the first IP we wouldn't sit there forever.

However, I can set it to that timer (1 day) and in doing so what actually would cause it to try to use IP2 or IP3 if IP1 was actually broken? How could we be able to tell?

1. Brekeke Product Name and Version: 3.5.5.7 2. Java version: unknown 3. OS type and the version: Windows 2012 R2 4. UA (phone), gateway or other hardware/software involved: Cisco Cube 5. Your problem: Matching Patterns $request = ^INVITE To = sip:(.+)@ $addr = <list of IP addresses> Deploy Patterns ...

Good day! putting that rule in the Preliminary Dial Plan rule worked like a charm! We blocked the scanner, finally! Now I have a different angle on this same thing. We noticed that there is a Filtering Policy tab in the same general vicinity of "Blocked IP Address" In the Filtering Policy is the ...

Hello! Sorry to take so long to get back this. I wanted to let you know we did a WireShark capture where our live filter was to check for ip.addr == 10.22.38.223 So the whole thing captures a lot more but we could see exactly when (or if) the scanning server hit our contact platform where Brekeke ...

OK, so I put this rule first and the Qualsys Scanner still found the same vulnerability.

So at this point we are ready to call this a False Positive.

Is there anything Brekeke can provide to show that despite all our attempts it still doesn't block / stop the Invite?

AWESOME, THANK YOU!!

If this doesn't work, by the way, I'm convinced literally nothing will.

Awesome, thank you!

1. Brekeke Product Name and Version: 3.9.4.3/517-1 2. Java version: 1.8.0_231 3. OS type and the version: Windows 2012 R2 64-bit 4. UA (phone), gateway or other hardware/software involved: None 5. Your problem: [Deploy Patterns] $b2bua = true To = sip:%1@<ip address one> $session = failover sip:%1 ...

So you all will love this. In Configuration, under SIP, I enabled REGISTER, INVITE, and then all the "auth" stuff I could find. All of it was turned on. I then REMOVED all the "$auth = false" stuff on each of my individual dial plan rules. The scanner STILL tripped a positive on the vulnerability ...

OK, so I have been through it with our client and I just want to be absolutely 100000% sure of what I tell you and what has not worked. This is the actual invite (as much as was given to me) that is still tripping the security violation: SIP/2.0 100 Trying Via: SIP/2.0/udp 10.22.38.223:5060;branch ...

It turns out the client was looking at the wrong scan.
The rule that included Via = ^IPtoBlock did not work.

So back to the drawing board.

So that worked like a charm! We blocked the scanner from tripping. Which is dandy but what we really want to do is ensure that ONLY two specific IPs will not need authorization and EVERYTHING else will. So while your rule did block the scanner, I'm hoping something like this would block EVERYTHING ...