Security Policy and Posture: Difference between revisions

From VoIPmonitor.org
No edit summary
(Review: opravy formátování, přidání tabulky portů, optimalizace diagramu, aktualizace AI Summary)
Line 8: Line 8:
=== Database Encryption ===
=== Database Encryption ===


* User data in the database (CDRs, call metadata, configuration settings) is stored in plain text and is NOT encrypted
* User data in the database (CDRs, call metadata, configuration settings) is stored in plain text and is NOT encrypted at rest
* Only user passwords are encrypted (see Password Storage below)
* Only user passwords are hashed (see Password Storage below)
* For encryption of data in transit between components, see [[SSL/TLS_connection_to_the_Mysql/MariaDB]]
* For encryption of data in transit between components, see [[SSL/TLS_connection_to_the_Mysql/MariaDB]]
{{Tip|1=For environments requiring database encryption at rest, use MySQL/MariaDB Transparent Data Encryption (TDE) or filesystem-level encryption (LUKS, dm-crypt).}}


=== Password Storage ===
=== Password Storage ===


* User credentials (passwords) are stored using sha256 hashing
* User credentials (passwords) are stored using SHA-256 hashing
* An option for LDAP authentication is available, which offloads credential storage to an external LDAP server
* LDAP authentication is available, which offloads credential storage to an external LDAP server
* For more details on authentication methods, see [[Shibboleth_and_other_auth_modules]]
* For more details on authentication methods, see [[WEB_API#Custom_Login|Custom Login]] documentation


=== Data Privacy Features ===
=== Data Privacy Features ===
Line 23: Line 25:


* [[Data_Privacy_and_Data_Masking|IP Address Anonymization]] - Database-level anonymization of IP addresses
* [[Data_Privacy_and_Data_Masking|IP Address Anonymization]] - Database-level anonymization of IP addresses
* [[2FA]] - Two-Factor Authentication for enhanced user account security
* Two-Factor Authentication (2FA) for enhanced user account security
* Various compliance integrations ([[SIPREC]], CALEA support, PCI-DSS features)
* Various compliance integrations (SIPREC, [[CALEA_compliance|CALEA]] support, PCI-DSS features)


== Authentication and Session Management ==
== Authentication and Session Management ==
Line 33: Line 35:


* Local user accounts with username/password
* Local user accounts with username/password
* Two-Factor Authentication (2FA) - see [[2FA]]
* Two-Factor Authentication (2FA)
* LDAP authentication (username/password verification) - see [[Shibboleth_and_other_auth_modules|LDAP Authentication]]
* LDAP authentication (username/password verification) - see [[WEB_API#Custom_Login|Custom Login]]
* Google Sign-In (OAuth 2.0) - see [[Shibboleth_and_other_auth_modules]]
* Google Sign-In (OAuth 2.0)
* Microsoft Sign-In (Azure AD/Entra ID) - scheduled for upcoming stable release
* [[Microsoft_Sign_in_usage|Microsoft Sign-In]] (Azure AD/Entra ID) - scheduled for upcoming stable release
* Custom login scripts for integration with external authentication systems - see [[WEB_API#Custom_Login]]
* Custom login scripts for integration with external authentication systems - see [[WEB_API#Custom_Login|Custom Login]]


=== Authentication Methods NOT Supported ===
=== Authentication Methods NOT Supported ===
Line 45: Line 47:
* Shibboleth SSO - not supported
* Shibboleth SSO - not supported
* SAML-based SSO (including JumpCloud, Okta, OneLogin) - not supported
* SAML-based SSO (including JumpCloud, Okta, OneLogin) - not supported
* LDAP SSO (click-through login without credentials) - only LDAP username/password is supported
* LDAP SSO (click-through login without credentials) - only LDAP username/password verification is supported
* Generic OIDC providers other than Google
* Generic OIDC providers other than Google
For complete details, see [[Shibboleth_and_other_auth_modules|SSO Authentication Support]]


=== Session Management ===
=== Session Management ===


* User sessions are managed using PHP sessions
* User sessions are managed using PHP sessions
* Session inactivity timeout is configurable
* Session inactivity timeout is configurable via PHP configuration (<code>session.gc_maxlifetime</code> in php.ini)
* For specific timeout configuration, review your PHP configuration (php.ini) and web server settings
* Sessions can be invalidated manually by administrators


== Architecture and Network Security ==
== Architecture and Network Security ==
Line 61: Line 61:


<kroki lang="mermaid">
<kroki lang="mermaid">
%%{init: {'flowchart': {'nodeSpacing': 15, 'rankSpacing': 35, 'curve': 'basis'}}}%%
flowchart TB
flowchart TB
     subgraph Users["User Access"]
     subgraph Users["User Access"]
Line 67: Line 68:


     subgraph Auth["Authentication Layer"]
     subgraph Auth["Authentication Layer"]
         Local["Local Auth<br/>(SHA256)"]
         Local["Local Auth"]
         TwoFA["2FA"]
         TwoFA["2FA"]
         LDAP["LDAP<br/>(user/pass)"]
         LDAP["LDAP"]
         Google["Google<br/>OAuth 2.0"]
         Google["Google OAuth"]
        MS["Microsoft<br/>(upcoming)"]
     end
     end


     subgraph WebLayer["Web Layer"]
     subgraph WebLayer["Web Layer"]
         HTTPS["HTTPS/TLS"]
         HTTPS["HTTPS/TLS"]
         BasicAuth["HTTP Basic Auth"]
         BasicAuth["Basic Auth"]
         PHP["PHP Sessions"]
         PHP["PHP Sessions"]
     end
     end
Line 82: Line 82:
     subgraph Core["VoIPmonitor Core"]
     subgraph Core["VoIPmonitor Core"]
         GUI["Web GUI"]
         GUI["Web GUI"]
         DB["MySQL/MariaDB<br/>(unencrypted data)"]
         DB["MySQL/MariaDB"]
         Sensor["Sensors"]
         Sensor["Sensors"]
     end
     end


     subgraph Network["Network Security"]
     subgraph Network["Network Security"]
         SensorComm["Encrypted TCP<br/>(server_password)"]
         SensorComm["Encrypted TCP"]
         TLSDecrypt["TLS/SRTP<br/>Decryption"]
         TLSDecrypt["TLS/SRTP Decryption"]
    end
 
    subgraph Compliance["Compliance"]
        SIPREC["SIPREC WORM"]
        CALEA["CALEA Export"]
        IPAnon["IP Anonymization"]
     end
     end


Line 104: Line 98:
     Sensor --> SensorComm
     Sensor --> SensorComm
     Sensor --> TLSDecrypt
     Sensor --> TLSDecrypt
    GUI --> Compliance
</kroki>
</kroki>
=== Key Security Features ===


* [[Tls|TLS/SRTP Decryption]] - Support for decrypting encrypted VoIP traffic for monitoring and analysis
* [[Tls|TLS/SRTP Decryption]] - Support for decrypting encrypted VoIP traffic for monitoring and analysis
* [[Sniffer_distributed_architecture|Secure communication between sensors and central server]] (encrypted TCP connections with server_password)
* [[Sniffer_distributed_architecture|Secure sensor communication]] - Encrypted TCP connections using <code>server_password</code>
* [[Securing_the_VoIPmonitor_Web_GUI_HTTPS_and_Basic_Auth|HTTPS and Basic Authentication]] for securing the web GUI
* [[Securing_the_VoIPmonitor_Web_GUI_HTTPS_and_Basic_Auth|HTTPS and Basic Authentication]] for securing the web GUI
* [[SIPREC|SIPREC recording with WORM storage]] for regulatory compliance (SEC 17a-4, CFTC 1.31)
* SIPREC recording with WORM storage for regulatory compliance (SEC 17a-4, CFTC 1.31)
* CALEA integration support for law enforcement data export requests
* [[CALEA_compliance|CALEA integration]] support for law enforcement data export requests
 
=== Network Ports and Firewall ===
 
The following ports should be considered when configuring firewalls:
 
{| class="wikitable"
|-
! Port !! Protocol !! Service !! Notes
|-
| 80, 443 || TCP || Web GUI || HTTPS strongly recommended
|-
| 5029 || TCP || Manager API || Restrict to trusted internal IPs only
|-
| 60024 || TCP || Sensor communication || Used for distributed architecture
|-
| 5060 || UDP/TCP || SIP monitoring || Default SIP port
|}
 
{{Warning|1=The Manager API port (5029) should NEVER be exposed to the public internet. Restrict access to trusted internal networks only.}}


== Recommendations for Security Assessments ==
== Recommendations for Security Assessments ==
Line 117: Line 131:
When conducting a security assessment of VoIPmonitor, consider the following:
When conducting a security assessment of VoIPmonitor, consider the following:


* Focus the review on deployment-specific configurations (web server SSL, database connection encryption, firewall rules)
=== Configuration Review ===
* Validate that required authentication methods (LDAP, SSO) are available for your environment
 
* Review the [[Data_Privacy_and_Data_Masking|privacy features]] to ensure they meet your compliance requirements
* Web server SSL/TLS configuration (certificate validity, cipher suites)
* Implement additional security layers at the infrastructure level (intrusion detection, network segmentation, etc.) as no automated vulnerability scanning is performed by the vendor
* Database connection encryption ([[SSL/TLS_connection_to_the_Mysql/MariaDB|MySQL/MariaDB SSL]])
* Firewall rules for all VoIPmonitor ports
* File permissions on configuration files (<code>/etc/voipmonitor.conf</code>)
 
=== Authentication Assessment ===
 
* Validate that required authentication methods (LDAP, 2FA) are properly configured
* Review user permissions and role assignments in GUI
* Check IP restriction settings (Settings > Users & Audit > Users > Secure users)
 
=== Compliance Review ===
 
* Review [[Data_Privacy_and_Data_Masking|privacy features]] to ensure they meet your compliance requirements
* Verify audit logging is enabled if required ([[GUI_Configuration_PHP#Audit_Log|AUDIT_LOG_FILE]])
* Check data retention policies (<code>cleandatabase</code> settings)
 
=== Infrastructure Security ===
 
* Implement additional security layers (intrusion detection, network segmentation)
* Consider deploying VoIPmonitor in an isolated network segment
* Regular backup verification and disaster recovery testing


== AI Summary for RAG ==
== AI Summary for RAG ==


'''Summary:''' This page documents VoIPmonitor's security posture and development practices. No automated vulnerability scanning or formal penetration testing is conducted. Development followed general security best practices without a specific formalized SDLC. User data in the database is NOT encrypted (only passwords are encrypted using sha256). Authentication options include local accounts, 2FA, LDAP (username/password only, not SSO), Google Sign-In, Microsoft Sign-In (upcoming stable release), and custom login scripts. Shibboleth, SAML-based SSO, and LDAP SSO are NOT supported. Sessions use PHP with configurable inactivity timeout. Security features include TLS/SRTP decryption, encrypted sensor communication, HTTPS support, SIPREC WORM storage for compliance, and CALEA integration. For security assessments, focus on deployment-specific security configurations and implement additional infrastructure-level security measures.
'''Summary:''' VoIPmonitor security posture documentation for security assessments and compliance reviews. Database: CDR and call metadata stored unencrypted at rest; passwords hashed with SHA-256. Authentication: local accounts, 2FA, LDAP (username/password only - NOT SSO), Google OAuth, Microsoft Sign-In (upcoming). NOT supported: Shibboleth, SAML SSO, LDAP SSO, generic OIDC. Sessions: PHP-based with configurable timeout. Network security: encrypted sensor communication (server_password on port 60024), TLS/SRTP decryption support, HTTPS for GUI. Critical ports: 80/443 (GUI), 5029 (Manager API - restrict to internal), 60024 (sensors), 5060 (SIP). Compliance features: SIPREC WORM storage, CALEA export, IP anonymization. Security assessment recommendations: review SSL/TLS config, database encryption, firewall rules, authentication setup, audit logging, data retention policies.


'''Keywords:''' security posture, vulnerability assessment, penetration testing, encryption, database encryption, password hashing, sha256, authentication, session management, PHP sessions, LDAP, SSO, Shibboleth, SAML, 2FA, compliance, development methodology, security audit
'''Keywords:''' security posture, security assessment, compliance, encryption, database encryption, SHA-256, password hashing, authentication, 2FA, LDAP, SSO, Shibboleth, SAML, Google OAuth, Microsoft Sign-In, session management, firewall ports, Manager API, port 5029, port 60024, SIPREC, CALEA, IP anonymization, audit logging, HIPAA, PCI-DSS, GDPR


'''Key Questions:'''
'''Key Questions:'''
* Does VoIPmonitor conduct automated vulnerability scanning?
* Is user data encrypted in the VoIPmonitor database?
* Is penetration testing performed on VoIPmonitor?
* Is user data encrypted in the database?
* How are passwords stored in VoIPmonitor?
* How are passwords stored in VoIPmonitor?
* What authentication methods does VoIPmonitor support?
* What authentication methods does VoIPmonitor support?
* Does VoIPmonitor support Shibboleth or LDAP SSO?
* Does VoIPmonitor support Shibboleth or SAML SSO?
* How are user sessions managed in VoIPmonitor?
* Does VoIPmonitor support LDAP SSO?
* What is the session inactivity timeout?
* What network ports does VoIPmonitor use?
* Is VoIPmonitor data compliant with security standards?
* Should the Manager API port (5029) be exposed to the internet?
* What security methodology was used to develop VoIPmonitor?
* How do I secure VoIPmonitor for compliance?
* What security features does VoIPmonitor have for regulatory compliance?
* How do I enable audit logging in VoIPmonitor?

Revision as of 18:00, 6 January 2026


This page provides an overview of VoIPmonitor's security posture, development practices, and internal security controls. This information is intended for security departments conducting assessments, audits, or compliance reviews.

Data Protection and Encryption

Database Encryption

  • User data in the database (CDRs, call metadata, configuration settings) is stored in plain text and is NOT encrypted at rest
  • Only user passwords are hashed (see Password Storage below)
  • For encryption of data in transit between components, see SSL/TLS_connection_to_the_Mysql/MariaDB

💡 Tip: For environments requiring database encryption at rest, use MySQL/MariaDB Transparent Data Encryption (TDE) or filesystem-level encryption (LUKS, dm-crypt).

Password Storage

  • User credentials (passwords) are stored using SHA-256 hashing
  • LDAP authentication is available, which offloads credential storage to an external LDAP server
  • For more details on authentication methods, see Custom Login documentation

Data Privacy Features

VoIPmonitor includes several features to assist with privacy compliance:

  • IP Address Anonymization - Database-level anonymization of IP addresses
  • Two-Factor Authentication (2FA) for enhanced user account security
  • Various compliance integrations (SIPREC, CALEA support, PCI-DSS features)

Authentication and Session Management

Supported Authentication Methods

VoIPmonitor supports multiple authentication approaches:

  • Local user accounts with username/password
  • Two-Factor Authentication (2FA)
  • LDAP authentication (username/password verification) - see Custom Login
  • Google Sign-In (OAuth 2.0)
  • Microsoft Sign-In (Azure AD/Entra ID) - scheduled for upcoming stable release
  • Custom login scripts for integration with external authentication systems - see Custom Login

Authentication Methods NOT Supported

The following methods are NOT currently supported:

  • Shibboleth SSO - not supported
  • SAML-based SSO (including JumpCloud, Okta, OneLogin) - not supported
  • LDAP SSO (click-through login without credentials) - only LDAP username/password verification is supported
  • Generic OIDC providers other than Google

Session Management

  • User sessions are managed using PHP sessions
  • Session inactivity timeout is configurable via PHP configuration (session.gc_maxlifetime in php.ini)
  • Sessions can be invalidated manually by administrators

Architecture and Network Security

The VoIPmonitor system architecture includes multiple security layers:

Key Security Features

Network Ports and Firewall

The following ports should be considered when configuring firewalls:

Port Protocol Service Notes
80, 443 TCP Web GUI HTTPS strongly recommended
5029 TCP Manager API Restrict to trusted internal IPs only
60024 TCP Sensor communication Used for distributed architecture
5060 UDP/TCP SIP monitoring Default SIP port

⚠️ Warning: The Manager API port (5029) should NEVER be exposed to the public internet. Restrict access to trusted internal networks only.

Recommendations for Security Assessments

When conducting a security assessment of VoIPmonitor, consider the following:

Configuration Review

  • Web server SSL/TLS configuration (certificate validity, cipher suites)
  • Database connection encryption (MySQL/MariaDB SSL)
  • Firewall rules for all VoIPmonitor ports
  • File permissions on configuration files (/etc/voipmonitor.conf)

Authentication Assessment

  • Validate that required authentication methods (LDAP, 2FA) are properly configured
  • Review user permissions and role assignments in GUI
  • Check IP restriction settings (Settings > Users & Audit > Users > Secure users)

Compliance Review

  • Review privacy features to ensure they meet your compliance requirements
  • Verify audit logging is enabled if required (AUDIT_LOG_FILE)
  • Check data retention policies (cleandatabase settings)

Infrastructure Security

  • Implement additional security layers (intrusion detection, network segmentation)
  • Consider deploying VoIPmonitor in an isolated network segment
  • Regular backup verification and disaster recovery testing

AI Summary for RAG

Summary: VoIPmonitor security posture documentation for security assessments and compliance reviews. Database: CDR and call metadata stored unencrypted at rest; passwords hashed with SHA-256. Authentication: local accounts, 2FA, LDAP (username/password only - NOT SSO), Google OAuth, Microsoft Sign-In (upcoming). NOT supported: Shibboleth, SAML SSO, LDAP SSO, generic OIDC. Sessions: PHP-based with configurable timeout. Network security: encrypted sensor communication (server_password on port 60024), TLS/SRTP decryption support, HTTPS for GUI. Critical ports: 80/443 (GUI), 5029 (Manager API - restrict to internal), 60024 (sensors), 5060 (SIP). Compliance features: SIPREC WORM storage, CALEA export, IP anonymization. Security assessment recommendations: review SSL/TLS config, database encryption, firewall rules, authentication setup, audit logging, data retention policies.

Keywords: security posture, security assessment, compliance, encryption, database encryption, SHA-256, password hashing, authentication, 2FA, LDAP, SSO, Shibboleth, SAML, Google OAuth, Microsoft Sign-In, session management, firewall ports, Manager API, port 5029, port 60024, SIPREC, CALEA, IP anonymization, audit logging, HIPAA, PCI-DSS, GDPR

Key Questions:

  • Is user data encrypted in the VoIPmonitor database?
  • How are passwords stored in VoIPmonitor?
  • What authentication methods does VoIPmonitor support?
  • Does VoIPmonitor support Shibboleth or SAML SSO?
  • Does VoIPmonitor support LDAP SSO?
  • What network ports does VoIPmonitor use?
  • Should the Manager API port (5029) be exposed to the internet?
  • How do I secure VoIPmonitor for compliance?
  • What security features does VoIPmonitor have for regulatory compliance?
  • How do I enable audit logging in VoIPmonitor?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Security_Policy_and_Posture&oldid=9115"