Arp Spoofing in Actix with Cockroachdb

Arp spoofing is a network-layer attack where an adversary sends falsified Address Resolution Protocol messages to associate their MAC address with the IP address of another host, typically the default gateway or a database server. When an Actix web service communicates with a Cockroachdb cluster, if the runtime environment is improperly segmented (for example, shared VLANs without strict layer-2 isolation), an attacker on the same broadcast domain can spoof ARP replies so that the Actix application sends database traffic to the attacker’s host instead of the intended Cockroachdb node.

In this combination, the risk is not in Actix or Cockroachdb themselves being ARP-spoofable protocols, but in the deployment topology. Actix services often maintain long-lived or pooled TCP connections to Cockroachdb; if an attacker successfully inserts themselves into the ARP cache of the Actix host, they can intercept or modify unencrypted SQL traffic. Cockroachdb by default uses TLS for connections, but if certificate validation is not enforced strictly in the Actix client, an attacker might also redirect traffic to a malicious server that terminates TLS with a self-signed certificate. Moreover, session fixation via ARP spoofing can lead to unauthorized query execution, data extraction, or transaction tampering if the application does not enforce per-session integrity checks.

Key dependency: the attack requires the attacker to be on the same local network segment or to have compromised a host that is logically adjacent to the Actix service or the Cockroachdb nodes. Therefore, hardening the runtime networking stack and ensuring strict transport security are essential to mitigate ARP spoofing in this architecture.

Remediation focuses on ensuring that all communication between Actix and Cockroachdb is authenticated, encrypted, and validated, and that runtime network assumptions are not trusted. Below are concrete code examples using the sqlx crate with Cockroachdb’s PostgreSQL wire protocol in an Actix runtime.

1. Enforce TLS with strict certificate verification

Configure the Actix database pool to require TLS server authentication and pin the server certificate or use a CA bundle that excludes unknown issuers. This prevents an attacker from presenting a forged certificate even if ARP is spoofed.

use sqlx::postgres::PgConnectOptions;
use sqlx::ConnectOptions;
use std::time::Duration;

let mut options = PgConnectOptions::new()
    .host("cockroachdb.example.com")
    .port(26257)
    .database("mydb")
    .username("appuser")
    .password("secret")
    .ssl_mode(sqlx::postgres::PgSslMode::Require)
    .connect_timeout(Duration::from_secs(5));

// Optionally, set a custom TLS connector to enforce certificate pinning
#[cfg(feature = "runtime-tokio-native-tls")]
{
    use native_tls::TlsConnector;
    use std::sync::Arc;
    let tls = TlsConnector::builder()
        .add_root_certificate(load_custom_ca())
        .build()
        .expect("failed to build TLS connector");
    options = options.tls_connector(Arc::new(tls));
}

async fn establish_pool() -> Result<sqlx::Pool<sqlx::Postgres>, sqlx::Error> {
    let pool = sqlx::postgres::PgPoolOptions::new()
        .max_connections(5)
        .connect_with(options)
        .await?;
    Ok(pool)
}

2. Use secure connection strings and avoid plaintext fallbacks

Ensure that the connection string or options never default to a non-TLS mode. In Actix, centralize configuration so that TLS is mandatory and runtime overrides cannot weaken it.

// config.rs
use serde::Deserialize;

#[derive(Deserialize, Debug)]
pub struct DbConfig {
    pub host: String,
    pub port: u16,
    pub username: String,
    pub password: String,
    pub database: String,
    pub ssl_root_cert_path: String,
}

// main.rs
use sqlx::postgres::PgConnectOptions;
use std::fs;

let cfg = load_db_config();
let cert = fs::read(cfg.ssl_root_cert_path).expect("failed to read CA cert");
let tls = rustls::ClientConfig::builder()
    .with_safe_defaults()
    .with_root_certificates(&rustls::RootCertStore::from_iter(vec![rustls::Certificate(cert)]))
    .expect("valid CA");
let tls = std::sync::Arc::new(tls);

let mut opts = PgConnectOptions::new()
    .host(&cfg.host)
    .port(cfg.port)
    .username(&cfg.username)
    .password(&cfg.password)
    .database(&cfg.database)
    .ssl_mode(sqlx::postgres::PgSslMode::Require);

// Apply custom TLS via raw descriptor (platform-specific, example simplified)
// In production, use a connector that integrates with sqlx’s TLS abstraction.

3. Validate server identity and restrict network paths

Use IP-based policies and host firewalling to reduce the attack surface. Even if ARP spoofing occurs, a tightly restricted network route limits the adversary’s ability to intercept traffic. In Kubernetes, use NetworkPolicy to isolate pods running Actix and Cockroachdb.

# Example network policy (Kubernetes) — not Rust code, but infrastructure as code
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: actix-to-cockroachdb
spec:
  podSelector:
    matchLabels:
      app: actix
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: cockroachdb
    ports:
    - protocol: TCP
      port: 26257

4. Application-level integrity checks

Design Actix handlers to verify context, such as checking TLS peer certificate details and using short-lived credentials. This ensures that even if lower-layer spoofing occurs, the transaction context remains verifiable.

use sqlx::postgres::PgRow;
use sqlx::Row;

async fn verify_transaction(pool: &sqlx::Pool<sqlx::Postgres>, tx_id: i64) -> Result<bool, sqlx::Error> {
    let row: PgRow = sqlx::query("SELECT crdb_internal.force_table_consistency($1)")
        .bind(tx_id)
        .fetch_one(pool)
        .await?;
    // additional application-level verification logic here
    Ok(true)
}