The IDS MC uses SSH for pushing configuration.
I don't think that you can configure to use telnet or any other protocol.
The IDS MC ships with it's own ssh client so the user does not have to install a separate ssh client.
IDS MC will use the ssh client to connect to the ssh server on the sensor. (all sensor's supported by IDS MC have ssh servers running) And push the new configuration through this SSH connection.
The only other protocol used by IDS MC to communicate with the sensor is HTTPS (TLS/SSL).
For upgrades to 4.0 sensors it will connect to the sensor on an SSH connection and then issue the upgrade comnmand on the sensor which forces the sensor to connect BACK to the HTTPS port of the IDS MC. The sensor is the HTTPS client and the IDS MC is the HTTPS server. The sensor pulls back the update and installs it.
So only SSH and HTTPS are supported.
SSH connections from the IDS MC to the sensor must be allowed through any firewalls.
HTTPS connections from the sensor back to the IDS MC must be allowed through any firewalls.
As for how many active SSH connections. IDS MC will only open a connection when it needs to push a configuration change. It does not maintain connection after the configuration change has been completed. If I remember correctly IDS MC was configured to update up to 5 sensors simultaneously. If more than 5 are scheduled for reconfiguration then the reconfiguration starts on 5 sensors. As one sensor configuration completes, the next scheduled sensor reconfiguration starts until all sensors have been reconfigured.
So only 5 SSH connections are being done by the IDS MC at a time and are only open during reconfiguration.
Security Monitor (SecMon) on the other hand uses postoffice for communicating with version 3.x sensors, and either HTTP or HTTPS (TLS/SSL) for communicating
with version 4.x sensors.
Postoffice was a proprietary protocol built on top of UDP. This was replaced with HTTP(S) in version 4.x for sending alarms.
Postoffice does not have any built in encryption. To encrypt postoffice communications the user can use IPSEC. IPSEC was included in older 3.x sensors for this purpose. However, SecMon does not ship with IPSEC. So the user would need to configure a special IPSEC tunnel using another device (like a router) or separate IPSEC software on the SecMon machine to encrypt the traffic.
SecMon establishes a UDP port 45000 connection to each sensor it is configured to receive alarms from and will try to continuously keep open the connection so alarms are received as soon as possible.
So if SecMon is monitoring 25 version 3.x sensors then 25 postoffice UDP port 45000 connections are constantly maintained.
Firewalls should be configured to allow UDP port 45000 between the devices.
For version 4.x sensors, however, SecMon will establish either an HTTP or HTTPS (TLS/SSL) connection to the sensor (I beleive this configrable on a per sensor basis).
SecMon ships with HTTP(S) client software, and the version 4.x sensors are always running a web server.
By default the 4.x sensor web server is configured to only use HTTPS (TLS/SSL), so if you want to run unencrypted you need to disable TLS/SSL on the sensor's web server and then configure SecMon to use unencrypted HTTP connections.
Once the HTTP(S) connection is established, SecMon will constantly send queries asking for new alarms, and the sensor will send back any alarms that have been generated.
SecMon will attempt to maintain this connection for each sensor it is monitoring. So if SecMon is monitoring 25 sensors then it will constantly have 25 HTTPS connections.
Firewalls should be configured to all SecMon to connect to the web server on the sensor (typically HTTPS port 443).
Marco
