DIVOC
DIVOC 3.5
DIVOC 3.5
  • Introduction to DIVOC
    • What DIVOC is and what it's not
    • DIVOC Docs Index
  • Platform
    • Release Notes
      • DIVOC 2.0 Release Features
      • DIVOC 3.0 Release Features
      • DIVOC 3.1 Release Features
      • DIVOC 3.5 Release Notes
    • Specification
      • API Documentation
      • Setting up DIVOC development environment
    • DIVOC's Verifiable Certificate Features 2.0
      • Creating a DIVOC Certificate
        • Overview of DIVOC’s digital certificates
        • What information is included in the DIVOC certificate?
        • DIVOC’s certificate generation service: How does it work?
        • Compliance with internationally used COVID-19 certificate schemas
      • Distributing a DIVOC Certificate
      • Updating a DIVOC Certificate
      • Revoking a DIVOC Certificate
      • Verifying a DIVOC Certificate
      • DIVOC's Native COVID-19 Certificate Specification
      • DIVOC’s EU-DCC Adapter Service
      • DIVOC’s SHC Adapter Service
      • Adding a User Type in DIVOC
      • Printing Certificates at a Facility
      • Normal QR Code Versus Signed/Verifiable QR Code
      • What Information Goes Into a QR Code?
      • WHO Master Vaccine Checklist
      • EU Master Vaccine Checklist
    • DIVOC's Verifiable Certificate Features 3.0
      • How to Configure a New Tenant?
      • How to Access the VC System and Generate Tokens
      • How to Generate Certificates
      • How to Fetch Certificates
      • How to Update Certificates
      • How to Revoke Certificates
      • How to Suspend Certificates
    • DIVOC's Verifiable Certificate Features 3.1
      • How to Verify Certificates
    • DIVOC's Verifiable Certificate Features 3.5
      • How to Create New Schemas
      • How to Manage Schemas?
    • DIVOC Architecture
    • Installation
      • Skills needed to set up DIVOC
      • Implementation Checklist
      • Setting Up DIVOC in k8 Cluster
        • How to Install DIVOC
        • How to Install DIVOC for V3.0
        • Backup & Restore: Postgres, Clickhouse, Kafka, & Redis
        • Infrastructure Recovery
        • Server Hardening
    • Verifiable Credential (VC): Production Deployment
    • Configuration
      • Configuring the Certification and Verification Component
        • Generating Signed Key Pairs
        • Configuring certificates
          • Step 1: Create a certification generation request
          • Step 2: Configure the QR code content
          • Step 3: Configure the certificate template
        • How to set up the verification portal for implementation
        • How to configure the update certificate API
        • Configuring Environment Variables in 2.0
      • Configuration Management Via ETCD
        • Adding a New Vaccine and ICD-11 Mapping
          • Adding a New Vaccine and ICD-11 Mapping Using ETCD CLI
        • PDF Template Change for Vaccine Certificates
          • PDF Template Change for Vaccine Certificates via ETCD CLI
        • EU Vaccine Configurations
          • Adding a New Vaccine and its Mapping via ETCD CLI
        • Payload Changes in the QR Code
          • Payload Changes in the QR Code via ETCD CLI
    • Performance Report
  • Products
    • Issuing COVID-19 Vaccination Certificates in India
    • Issuing COVID-19 Test Reports in India
    • Issuing COVID-19 Vaccination Certificates in Sri Lanka
    • Issuing COVID-19 Vaccination Certificates in the Philippines
    • Issuing COVID-19 Vaccination Certificates in Jamaica
      • Troubleshooting
    • Issuing COVID-19 Vaccination Certificates in Indonesia
    • Open Events
      • Past Events
      • DIVOC in the Media
  • DIVOC Demo
    • Program Setup (Via Orchestration Module)
    • Facility App
    • Issue and Verify Certificates
    • Citizen Portal
    • Feedback
    • Analytics
  • Community
    • Roadmap
    • Partner Support
      • Terms and Conditions of Using the DIVOC Site
      • Privacy Policy: Short Version for Display
      • Privacy Policy: Detailed
      • Platform Policy Guidelines
      • Privacy Policy Recommendations
      • Troubleshooting Guide
    • Source Code
    • Discussion Forum
    • Issues
    • Project Repo
Powered by GitBook
On this page
  • Check for open ports
  • Secure SSH
  1. Platform
  2. Installation
  3. Setting Up DIVOC in k8 Cluster

Server Hardening

This is the minimum list of hardening and other steps that need to be performed to secure the Linux server containing the DIVOC platform. The assumption is that the installation happens on a bare metal setup. While the concepts remain the same, the methodology might differ for commercial cloud setups.

Check for open ports

  • Identifying open connections to the internet is a critical mission.

netstat -antp

  • Once you have identified the open ports, you can stop/purge the applications which keep unnecessary ports open.

  • The only acceptable open ports are 22 and 443. Access to the other ports outside the Kubernetes network should be prohibited.

  • All ingress should be routed through the 443 port only as needed.

Secure SSH

SSH is secure, but we need to harden this service as well. If we can disable SSH, then the problem is solved. However, if we want to use it, we have to change the default configuration of SSH. Password-based authentication should be disabled and only key-based authentication should be allowed. The steps for creating sudo users with public and private keys are as follows:

  • Create a non-root sudo user

adduser <user>

  • Add the user to sudo users group

usermod -aG sudo <user>

  • Login to the machine as the user

su - <user>

  • Create SSH directory with appropriate permissions

mkdir -p $HOME/.ssh chmod 0700 $HOME/.ssh

  • Generate a key pair for the protocol, and run:

ssh-keygen -t ed25519 -C "My key for DIVOC server"

  • Share the public key created with users you expect to connect to the server

$HOME/.ssh/id_ed25519.pub

  • You can modify your SSH configuration to be more secure by performing the following changes to the configuration file:

nano /etc/ssh/sshd_config

  • Make sure that root cannot login remotely through SSH

PermitRootLogin no

  • Allow some specific users

AllowUsers [username]

  • Enable public key-based authentication and disable password-based authentication

PubkeyAuthentication yes PasswordAuthentication no

  • There are some additional options that must exist in the “sshd_config” file: MaxAuthTries 5

  • Finally, set the permissions on the sshd_config file so that only root users can change its contents:

chown root:root /etc/ssh/sshd_config

chmod 600 /etc/ssh/sshd_config

PreviousInfrastructure RecoveryNextVerifiable Credential (VC): Production Deployment

Last updated 2 years ago

All content on this page by is licensed under a .

eGov Foundation
Creative Commons Attribution 4.0 International License
Creative Commons License