Skip to main content

​
Overview

Securing your Viction node is critical to protecting your accounts, funds, and network participation. This guide covers essential security practices for node operators.

​
Account Security

​
Private Key Management

Never share your private keys or keystore files. Anyone with access to your private key has complete control over your account and funds.
Best practices:
  1. Never expose unencrypted keys
    • Always encrypt keys with strong passphrases
    • Delete unencrypted key files immediately after import
    • Never transmit keys over insecure channels
  2. Use strong passphrases
    • Minimum 12 characters
    • Mix uppercase, lowercase, numbers, and symbols
    • Avoid dictionary words and personal information
    • Use a password manager
  3. Backup securely
    • Store backups in multiple secure locations
    • Use encrypted storage for backups
    • Keep offline/cold storage for critical accounts
    • Test backup restoration regularly

​
Keystore Encryption

Viction uses scrypt-based encryption for keystore files: Standard encryption (recommended for production): 
tomo account new
Lightweight encryption (testing only): 
tomo account new --lightkdf
Never use --lightkdf for production accounts. The reduced security makes accounts vulnerable to brute-force attacks.

​
Account Unlocking

Unlocking accounts exposes decrypted keys in memory: 
tomo --unlock <address> --password <passwordfile>
Only unlock accounts when absolutely necessary. Unlocked accounts are vulnerable if the node is compromised. Never unlock accounts on public-facing nodes.
Safer alternatives:
  • Use external signers (hardware wallets, remote signing services)
  • Unlock accounts only for specific operations, then re-lock
  • Use separate nodes for signing vs. public RPC access

​
Network Security

​
Firewall Configuration

Restrict network access to your node: Required ports:
  • 30303: P2P networking (TCP & UDP)
  • 8545: HTTP RPC (restrict to trusted IPs)
  • 8546: WebSocket RPC (restrict to trusted IPs)
  • 30301: IPC (local only)
Firewall rules example (iptables): 
# Allow P2P from anywhere
iptables -A INPUT -p tcp --dport 30303 -j ACCEPT
iptables -A INPUT -p udp --dport 30303 -j ACCEPT

# Allow RPC only from trusted IP
iptables -A INPUT -p tcp -s 192.168.1.100 --dport 8545 -j ACCEPT
iptables -A INPUT -p tcp --dport 8545 -j DROP

# Allow WebSocket only from trusted IP
iptables -A INPUT -p tcp -s 192.168.1.100 --dport 8546 -j ACCEPT
iptables -A INPUT -p tcp --dport 8546 -j DROP

​
RPC Security

Never expose RPC endpoints to the public internet without proper authentication and rate limiting. Unrestricted RPC access can lead to DoS attacks and unauthorized transactions.
Secure RPC configuration:
  1. Bind to localhost only (if local access sufficient):
tomo --rpc --rpcaddr 127.0.0.1 --rpcport 8545
  1. Restrict API modules:
tomo --rpc --rpcapi "eth,net,web3" --rpcaddr 127.0.0.1
Avoid exposing dangerous APIs:
  • admin: Node administration
  • debug: Debugging functions
  • personal: Account management
  • miner: Mining control
  1. Use CORS carefully:
tomo --rpc --rpccorsdomain "https://yourdapp.com"
  1. Virtual hosts whitelist:
tomo --rpc --rpcvhosts "yourdomain.com,localhost"

​
P2P Security

Trusted nodes only mode: 
tomo --nodiscover --maxpeers 10
Configure static/trusted nodes in <datadir>/static-nodes.json: 
[
  "enode://pubkey1@ip1:30303",
  "enode://pubkey2@ip2:30303"
]

​
Node Security

​
File System Permissions

Restrict access to node data: 
# Set proper ownership
chown -R viction:viction /path/to/datadir

# Restrict permissions
chmod 700 /path/to/datadir
chmod 600 /path/to/datadir/keystore/*
Keystore files should only be readable by the node user. Never set world-readable permissions (chmod 644 or 777) on keystore files.

​
Process Isolation

Run the node as a dedicated user (not root): 
# Create dedicated user
useradd -r -s /bin/false viction

# Run as dedicated user
su - viction -c "tomo --datadir /var/lib/viction"

​
System Updates

Keep your system and node software updated: 
# Update system packages
apt update && apt upgrade  # Debian/Ubuntu
yum update                 # RHEL/CentOS

# Update Viction node
# Download latest release and verify checksum
wget https://github.com/BuildOnViction/victionchain/releases/download/vX.X.X/tomo-linux-amd64
shasum -a 256 tomo-linux-amd64
# Compare with published checksum

​
Monitoring and Logging

​
Enable Security Logging

tomo --verbosity 3 2>&1 | tee -a /var/log/viction/node.log

​
Monitor for Suspicious Activity

Watch for:
  • Unauthorized RPC access attempts
  • Unusual transaction patterns
  • Unexpected account unlock attempts
  • Abnormal peer connections
  • High resource usage

​
Log Rotation

Configure log rotation to prevent disk exhaustion: 
# /etc/logrotate.d/viction
/var/log/viction/*.log {
    daily
    rotate 30
    compress
    delaycompress
    notifempty
    create 0640 viction viction
    sharedscripts
}

​
Disaster Recovery

​
Backup Strategy

Critical data to backup:
  1. Keystore files (<datadir>/keystore/*)
  2. Node key (<datadir>/nodekey)
  3. Configuration files
  4. Static/trusted nodes configuration
Backup script example: 
#!/bin/bash
BACKUP_DIR="/secure/backup/location"
DATE=$(date +%Y%m%d)

# Backup keystore
tar -czf "$BACKUP_DIR/keystore-$DATE.tar.gz" \
  -C ~/.ethereum keystore/

# Encrypt backup
gpg --encrypt --recipient [email protected] \
  "$BACKUP_DIR/keystore-$DATE.tar.gz"

# Remove unencrypted backup
rm "$BACKUP_DIR/keystore-$DATE.tar.gz"

​
Recovery Testing

Regularly test backup restoration: 
# Test restore on isolated system
mkdir -p /tmp/test-restore
tar -xzf keystore-backup.tar.gz -C /tmp/test-restore
tomo account list --keystore /tmp/test-restore/keystore

​
Smart Contract Security

If deploying contracts:
  1. Audit contracts before deployment
  2. Use established patterns (OpenZeppelin, etc.)
  3. Test thoroughly on testnet
  4. Implement access controls
  5. Plan for upgrades (proxy patterns)
  6. Monitor contract activity

​
Masternode Security

Additional considerations for masternode operators:
Masternode accounts require special protection as they participate in consensus. Compromise of a masternode account can affect network security and result in slashing.
Masternode best practices:
  1. Use dedicated infrastructure
    • Separate server for masternode
    • No other services on masternode server
    • Hardened operating system
  2. DDoS protection
    • Use DDoS mitigation services
    • Implement rate limiting
    • Have backup nodes ready
  3. High availability
    • Monitor uptime continuously
    • Automated failover procedures
    • Redundant network connections
  4. Key management
    • Consider hardware security modules (HSM)
    • Multi-signature setups where possible
    • Regular key rotation procedures

​
Incident Response

​
If Keys Are Compromised

  1. Immediately transfer funds to new secure account
  2. Stop the compromised node
  3. Investigate breach vector
  4. Rotate all credentials
  5. Review logs for unauthorized activity
  6. Update security measures

​
If Node Is Compromised

  1. Isolate the node from network
  2. Preserve logs and system state for analysis
  3. Check for unauthorized transactions
  4. Verify keystore integrity
  5. Rebuild from clean installation
  6. Restore from verified backups
  7. Investigate root cause

​
Security Checklist

  • Strong passphrases on all accounts
  • Keystore files backed up securely
  • Node running as non-root user
  • Firewall configured with minimal open ports
  • RPC access restricted to trusted IPs
  • Dangerous RPC APIs disabled
  • System packages up to date
  • Viction software up to date
  • Security logging enabled
  • Log rotation configured
  • Backup restoration tested
  • Monitoring and alerting active
  • Incident response plan documented

​
Resources

Build docs developers (and LLMs) love

Get started for freeTalk to us