For the SSH issues, I highly recommend making sure the VCS-E is behind a firewall that filers unwanted SSH connections.
For the SIP messages, the vast majority of people attempting to access your system via SIP will do so via the UDP protocol. For this reason, I would recommend disabling SIP UDP.
However, this will not block all of the unwanted calls. The best thing to do would be to write a CPL blocking calls that you do not want to allow in. The important thing to keep in mind when using CPL to reject calls is that the authentication flag on incoming messages is very important. Unless you have a neighbor/Traversal zone that shares an IP address with the incoming calls, the calls will be seen as coming in on the default zone.
Assuming that these calls are coming in on the default zone (they almost always are)...
If the default zone is set to do not check credentials, the messages will come in as unauthenticated.
If the default zone is set to treat as authenticated, the messages will come in as authenticated.
If the default zone is set to check credentials, the VCS will demand a username/password for these messages before processing them.
My guess is that your VCS is currently set to check credentials on the default zone, which would explain all of the 407 messages. If the other side never responds with proper credentials, the VCS will never process the message and you probably have nothing to worry about.
If however, the messages are being processed by the VCS, the messages will first go through any applicable transforms. After a transform is either applied or not, the VCS will check the request against a SIP route. If the message does not match a SIP route pattern, then the message will be checked against CPL.
The CPL is the point where the VCS can determine to reject or proxy messages. If CPL is enabled (VCS configuration > Call Policy > Configuration), then the VCS will enable the CPL check. For a beginning user, using a local CPL is highly recommended.
Once Local CPL is enabled, you can edit the rules specified in the CPL Wizard
(VCS configuration > Call Policy > Rules) to either reject or proxy certain messages based on the authenticated source and destination.
This is where the authentication flag becomes important. The VCS will only match a specific source address if the request is authenticated. If the request is not authenticated, the VCS will consider the source to be blank. This only applies to the source. The destination is always the actually request URI in the sip header.
So, if for instance, I wanted to block all unauthenticated calls that started with a 9, I would write a CPL with a blank source and a destination of "9.*"
If I wanted to block authenticated calls from sources that come from the cisco.com domain to any destination, I would write a CPL with a source of ".*@cisco\.com" and a destination of ".*"
".*" in regex means anything, but it is important to remember that ".*" in the source means any authenticated source. A ".*" in the source will not match any unauthenticated caller.
Finally, even with these security systems in place, you will still see people attempting to connect to your box on sip. You should see all calls that you want to reject rejected with a 403 forbidden message. If you do not see 403's, then make your security is properly configured (A 407 or 401 would also effectively stop the VCS from processing the message).
As this is a public internet facing box, people will attempt to send you messages. The only way around this would be to deploy a firewall to block ranges of addresses. It is the same with any public internet facing servers.
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...
If you have 2 ISR routers, one acting as Failover, do we need to have both the same number of SRST licenses on the 2 routers?
No. You will only need the SRST licenses on the primary router. Because this feature...