Prendre rendez-vous
  1. Accueil
  2. /
  3. Blog
  4. /
  5. eBPF : la révolution du kernel Linux pour networking, observabilité et sécurité

Linux
Réseau
Sécurité

eBPF : la révolution du kernel Linux pour networking, observabilité et sécurité

17 janvier 2026

14 min de lecture

Sommaire
Plan
Qu'est-ce que eBPF ?
Architecture et fonctionnement
Networking : Cilium et CNI eBPF
Observabilité : Pixie et BPFtrace
Sécurité : Falco et Tetragon
Performance et benchmarks
Cas d'usage production
Développement eBPF
Checklist adoption eBPF
Conclusion

eBPF révolutionne Linux en 2026 : networking haute performance, observabilité sans overhead et sécurité runtime. Cilium remplace kube-proxy, Falco détecte les intrusions, Pixie observe sans instrumentation. Guide complet.

Plan

  • Qu'est-ce que eBPF ?
  • Architecture et fonctionnement
  • Networking : Cilium et CNI eBPF
  • Observabilité : Pixie et BPFtrace (voir io_uring)
  • Sécurité : Falco et Tetragon
  • Performance et benchmarks
  • Cas d'usage production
  • Développement eBPF (voir kernel Linux)
  • Conclusion

Qu'est-ce que eBPF ?

Définition et révolution

eBPF (Extended Berkeley Packet Filter) = technologie kernel Linux permettant d'exécuter du code sandboxé dans le kernel sans modifier le code kernel ni charger de modules.

Révolution :

  • Avant : modules kernel (risqué, kernel panic)
  • Maintenant : programmes eBPF (safe, vérifiés, JIT compiled)

Capacités :

  • Hook n'importe quelle fonction kernel
  • Observer réseau, système, sécurité
  • Modifier comportement (filtrage, routing)
  • Performance native (pas de context switch)
Adoption 2026
  • Linux 5.15+ : eBPF mature et stable
  • Kubernetes : 64 % clusters utilisent Cilium CNI
  • Cloud providers : AWS, GCP, Azure offrent eBPF natif
  • Sécurité : industries régulées exigent eBPF runtime security
  • Observabilité : Pixie, Hubble, Tetragon standard
eBPF vs alternatives
AspecteBPFKernel modulesUserspace
SécuritéVérifié, sandboxéRisqué (kernel panic)Isolé
PerformanceNative (0 overhead)NativeContext switch
DéploiementÀ chaudReboot parfoisFacile
PortabilitéKernel 4.9+Compilation par versionUniversel
ObservabilitéCompletCompletLimité

Architecture et fonctionnement

Architecture eBPF
┌──────────────────────────────────────────┐
│         Userspace Application            │
│  ┌────────┐  ┌────────┐  ┌────────────┐ │
│  │ bpftool│  │  libbpf│  │ BPF Program│ │
│  └────────┘  └────────┘  └────────────┘ │
└──────────────────────────────────────────┘
              ↓ syscall(BPF_PROG_LOAD)
┌──────────────────────────────────────────┐
│            Linux Kernel                   │
│  ┌────────────────────────────────────┐  │
│  │       eBPF Verifier                │  │
│  │  (vérification sécurité)           │  │
│  └────────────────────────────────────┘  │
│              ↓                            │
│  ┌────────────────────────────────────┐  │
│  │       JIT Compiler                 │  │
│  │  (compilation native)              │  │
│  └────────────────────────────────────┘  │
│              ↓                            │
│  ┌────────────────────────────────────┐  │
│  │    eBPF Maps (data sharing)       │  │
│  └────────────────────────────────────┘  │
│              ↓                            │
│  ┌────────────────────────────────────┐  │
│  │    Hook Points                     │  │
│  │ • XDP (eXpress Data Path)         │  │
│  │ • TC (Traffic Control)            │  │
│  │ • Kprobes/Tracepoints             │  │
│  │ • LSM (Linux Security Modules)    │  │
│  └────────────────────────────────────┘  │
└──────────────────────────────────────────┘
Types de programmes eBPF

XDP (eXpress Data Path) :

  • Hook : réception packet (avant driver)
  • Usage : DDoS protection, load balancing
  • Performance : 24M pps par core

TC (Traffic Control) :

  • Hook : ingress/egress traffic
  • Usage : QoS, firewall, NAT
  • Performance : kernel networking

Kprobes/Tracepoints :

  • Hook : n'importe quelle fonction kernel
  • Usage : observabilité, debugging
  • Performance : négligeable overhead

LSM (Linux Security Modules) :

  • Hook : security decisions
  • Usage : runtime security, MAC
  • Performance : inline checks
eBPF Verifier

Garanties sécurité :

  • Pas de boucles infinies
  • Pas d'accès mémoire invalide
  • Pas de kernel panic possible
  • Terminaison garantie (moins de 1M instructions)
// Exemple eBPF program (simplifié)
SEC("xdp")
int xdp_drop_tcp(struct xdp_md *ctx) {
    void *data_end = (void *)(long)ctx->data_end;
    void *data = (void *)(long)ctx->data;

    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return XDP_PASS;  // Bounds check obligatoire

    if (eth->h_proto != htons(ETH_P_IP))
        return XDP_PASS;

    struct iphdr *ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end)
        return XDP_PASS;

    if (ip->protocol == IPPROTO_TCP)
        return XDP_DROP;  // Drop TCP packets

    return XDP_PASS;
}

Vérification :

# Compiler avec clang
clang -O2 -target bpf -c xdp_drop_tcp.c -o xdp_drop_tcp.o

# Charger (vérifier s'exécute automatiquement)
ip link set dev eth0 xdp obj xdp_drop_tcp.o sec xdp

Networking : Cilium et CNI eBPF

Cilium : CNI eBPF pour Kubernetes

Cilium = CNI (Container Network Interface) basé sur eBPF, remplace kube-proxy et iptables. Pour une gestion automatisée des configurations cloud, complétez avec Terraform pour l'infrastructure.

Avantages par rapport à kube-proxy/iptables :

  • Performance : 10x faster (eBPF vs iptables)
  • Scalabilité : pas de règles iptables linéaires
  • Observabilité : Hubble (flow visibility L7)
  • Sécurité : network policies L3-L7
Installation Cilium
# Kubernetes cluster sans CNI
# Créer cluster avec kubeadm --pod-network-cidr=10.0.0.0/16

# Installer Cilium CLI
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
curl -L --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-amd64.tar.gz
tar xzvf cilium-linux-amd64.tar.gz
sudo mv cilium /usr/local/bin/

# Installer Cilium dans cluster
cilium install --version 1.15.0

# Vérifier
cilium status --wait
# Cilium:         OK
# Operator:       OK
# Hubble Relay:   OK
# ClusterMesh:    disabled

# Activer Hubble (observabilité)
cilium hubble enable --ui
Configuration Cilium avancée
# cilium-values.yaml
hubble:
  enabled: true
  relay:
    enabled: true
  ui:
    enabled: true

# L7 visibility
hubble:
  metrics:
    enabled:
      - dns
      - drop
      - tcp
      - flow
      - port-distribution
      - icmp
      - http

# Replace kube-proxy
kubeProxyReplacement: "strict"

# Enable XDP acceleration
loadBalancer:
  acceleration: native
  mode: dsr

# BGP (pour bare-metal)
bgp:
  enabled: true
  announce:
    loadbalancerIP: true

# Encryption (WireGuard)
encryption:
  enabled: true
  type: wireguard

# Network policies
policyEnforcementMode: default
# Appliquer config
helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  -f cilium-values.yaml
Network Policies L7 avec Cilium
# policy-http.yaml
apiVersion: 'cilium.io/v2'
kind: CiliumNetworkPolicy
metadata:
  name: allow-api-get
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: frontend

  egress:
    - toEndpoints:
        - matchLabels:
            app: backend
      toPorts:
        - ports:
            - port: '8080'
              protocol: TCP
          rules:
            http:
              - method: 'GET'
                path: '/api/.*'
              - method: 'POST'
                path: '/api/users'

    # Allow DNS
    - toEndpoints:
        - matchLabels:
            k8s:io.kubernetes.pod.namespace: kube-system
            k8s:app: kube-dns
      toPorts:
        - ports:
            - port: '53'
              protocol: UDP
          rules:
            dns:
              - matchPattern: '*'
# Appliquer
kubectl apply -f policy-http.yaml

# Vérifier
cilium endpoint list
Hubble : observabilité réseau
# Port-forward Hubble UI
cilium hubble ui

# CLI queries
hubble observe --namespace default

# Observer flows d'un pod
hubble observe --pod frontend-abc123

# Observer drops
hubble observe --verdict DROPPED

# Observer par protocole
hubble observe --protocol http

# Metrics
hubble observe --output json | jq '.flow.l7.http.method'

Grafana dashboards Hubble :

# Exporter metrics vers Prometheus
kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/v1.15/examples/kubernetes/addons/prometheus/monitoring-example.yaml

Observabilité : Pixie et BPFtrace

Pixie : observabilité sans instrumentation

Pixie = plateforme observabilité Kubernetes utilisant eBPF pour capturer données sans modifier applications.

Fonctionnalités :

  • Auto-instrumentation (pas de code change)
  • Tracing distribué automatique
  • Métriques application (latence, errors)
  • Network flow visibility
  • Requêtes de type SQL
Installation Pixie
# Installer Pixie CLI
bash -c "$(curl -fsSL https://withpixie.ai/install.sh)"

# Authentifier
px auth login

# Déployer dans cluster
px deploy --cluster_name production

# Vérifier
px get viziers
# NAME         STATUS   VERSION
# production   HEALTHY  0.14.2
Queries Pixie
# PxL (Pixie Language) - SQL-like

# HTTP request latency par service
import px

df = px.DataFrame(table='http_events', start_time='-5m')
df = df[df.ctx['service'] == 'payment-service']
df.latency_ms = df.latency_ns / 1000000
df = df.groupby(['req_path']).agg(
    latency_p50=('latency_ms', px.quantiles(0.5)),
    latency_p99=('latency_ms', px.quantiles(0.99)),
    requests=('latency_ms', px.count)
)
px.display(df)

# Output:
# req_path         latency_p50  latency_p99  requests
# /api/payments    45.2         120.5        1234
# /api/refunds     32.1         89.3         456
# Network connections avec latency
import px

df = px.DataFrame(table='conn_stats', start_time='-5m')
df.pod = df.ctx['pod']
df.remote_addr = px.pod_id_to_pod_name(df.remote_pod_id)
df = df.groupby(['pod', 'remote_addr']).agg(
    bytes_sent=('bytes_sent', px.sum),
    bytes_recv=('bytes_recv', px.sum),
    conn_latency=('conn_latency_ns', px.mean)
)
px.display(df)
BPFtrace : dynamic tracing

BPFtrace = langage de haut niveau pour eBPF (comme dtrace/systemtap).

# Installer
apt install bpftrace

# Lister probes disponibles
bpftrace -l 'tracepoint:syscalls:*'
bpftrace -l 'kprobe:*'

# One-liners
# Tracer syscalls par processus
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'

# Latence des reads
bpftrace -e 'tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; }
             tracepoint:syscalls:sys_exit_read /@start[tid]/ {
               @latency = hist(nsecs - @start[tid]); delete(@start[tid]);
             }'

# TCP retransmissions
bpftrace -e 'tracepoint:tcp:tcp_retransmit_skb { @[kstack] = count(); }'

Script BPFtrace custom :

# tcp-latency.bt
#!/usr/bin/env bpftrace

tracepoint:tcp:tcp_probe
{
    @conn[args->saddr, args->sport, args->daddr, args->dport] = 1;
    @rtt[args->saddr, args->sport, args->daddr, args->dport] =
        args->srtt_us / 1000;
}

interval:s:5
{
    print(@rtt);
    clear(@rtt);
}

END
{
    clear(@conn);
    clear(@rtt);
}
# Exécuter
chmod +x tcp-latency.bt
./tcp-latency.bt

Sécurité : Falco et Tetragon

Falco : runtime security

Falco = détection d'intrusion runtime avec eBPF, projet CNCF graduated.

Détections :

  • Processus suspects
  • Accès à des fichiers sensibles
  • Syscalls anormaux
  • Connexions réseau non autorisées
  • Container escapes
Installation Falco
# Helm install
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

# Install avec eBPF driver (vs kernel module)
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=ebpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true
Règles Falco custom
# custom-rules.yaml
- rule: Unauthorized Process in Container
  desc: Detect process not in whitelist
  condition: >
    spawned_process and
    container and
    not proc.name in (node, npm, python3)
  output: >
    Unauthorized process started
    (user=%user.name process=%proc.name
     container=%container.name image=%container.image.repository)
  priority: WARNING
  tags: [container, process]

- rule: Read Sensitive File
  desc: Detect read of /etc/shadow
  condition: >
    open_read and
    fd.name=/etc/shadow and
    not proc.name in (sshd, sudo, passwd)
  output: >
    Sensitive file read
    (user=%user.name process=%proc.name file=%fd.name)
  priority: CRITICAL
  tags: [filesystem, security]

- rule: Reverse Shell
  desc: Detect reverse shell attempt
  condition: >
    spawned_process and
    ((proc.name in (bash, sh, zsh) and
      proc.cmdline contains "-i") or
     (proc.name in (nc, ncat, netcat) and
      proc.cmdline contains "-e"))
  output: >
    Reverse shell detected
    (user=%user.name process=%proc.name cmdline=%proc.cmdline)
  priority: CRITICAL
  tags: [shell, attack]
# Appliquer
kubectl create configmap falco-rules \
  --from-file=custom-rules.yaml \
  -n falco

# Redémarrer Falco
kubectl rollout restart daemonset falco -n falco
Tetragon : eBPF security observability

Tetragon = Cilium security observability avec enforcement policies.

# Installer Tetragon
helm repo add cilium https://helm.cilium.io
helm install tetragon cilium/tetragon -n kube-system

# Vérifier
kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout

TracingPolicy :

# tracing-policy-exec.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: monitor-exec
spec:
  kprobes:
    - call: 'sys_execve'
      syscall: true
      args:
        - index: 0
          type: 'string'
        - index: 1
          type: 'char_buf'
          sizeArgIndex: 2
      selectors:
        - matchArgs:
            - index: 0
              operator: 'Equal'
              values:
                - '/bin/bash'
                - '/usr/bin/bash'
          matchActions:
            - action: Post
              rateLimit: '1m'
# Appliquer
kubectl apply -f tracing-policy-exec.yaml

# Observer events
kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -f

Performance et benchmarks

Benchmark XDP par rapport à iptables

Setup test :

  • Server : 2x Intel Xeon, 10Gbps NIC
  • Packet generator : pktgen
  • Mesure : packets/sec, latency
# Test 1 : iptables DROP
iptables -A INPUT -p tcp --dport 80 -j DROP

# pktgen
pktgen --rate 10000000 --proto tcp --dport 80
# Result: 1.2M pps, CPU 95%

# Test 2 : XDP DROP
ip link set dev eth0 xdp obj xdp_drop.o
# Result: 24M pps, CPU 35%

Résultats :

MéthodePPS (packets/sec)CPU usageLatency
iptables1.2M95 %120 µs
XDP24M35 %8 µs
Gain20x-60 %-93 %
Benchmark Cilium par rapport à kube-proxy

Test : 1000 services Kubernetes, 10k endpoints.

# Cluster avec kube-proxy
# iptables rules: 20,000+
iptables-save | wc -l
# 23,456

# Service latency test
kubectl run test --image=curlimages/curl -- \
  sh -c "while true; do curl -w '%{time_total}\n' -s -o /dev/null http://service; done"

# Average: 2.5ms
# P99: 15ms
# Cluster avec Cilium (kube-proxy replacement)
# iptables rules: <100
iptables-save | wc -l
# 42

# Service latency test (même test)
# Average: 0.8ms
# P99: 3ms

Résultats :

Métriquekube-proxyCiliumAmélioration
Latency moy2.5ms0.8ms-68 %
Latency p9915ms3ms-80 %
iptables rules23kmoins de 100-99 %
Memory2GB512MB-75 %

Cas d'usage production

Cas 1 : DDoS protection (Cloudflare)

Problème : DDoS attacks 300M pps

Solution : XDP eBPF filter

// Simplified Cloudflare XDP
SEC("xdp")
int xdp_ddos_filter(struct xdp_md *ctx) {
    // Parse packet
    struct packet_info pkt;
    if (parse_packet(ctx, &pkt) < 0)
        return XDP_PASS;

    // Rate limit per source IP
    __u32 key = pkt.src_ip;
    __u64 *count = bpf_map_lookup_elem(&rate_limit_map, &key);

    if (count) {
        __sync_fetch_and_add(count, 1);
        if (*count > RATE_LIMIT_THRESHOLD)
            return XDP_DROP;  // Drop packet at line rate
    } else {
        __u64 init = 1;
        bpf_map_update_elem(&rate_limit_map, &key, &init, BPF_ANY);
    }

    return XDP_PASS;
}

Résultat :

  • Filtrage : 300M pps sans perte
  • Latence : moins de 10 µs par paquet
  • CPU : 40 % (vs 100 % avec iptables)
Cas 2 : Zero-trust networking (Netflix)

Problème : Microsegmentation 10,000+ services

Solution : Cilium network policies L3-L7

# Netflix-style policy
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: payment-service-policy
spec:
  endpointSelector:
    matchLabels:
      app: payment-service

  ingress:
    - fromEndpoints:
        - matchLabels:
            app: api-gateway
      toPorts:
        - ports:
            - port: '8080'
              protocol: TCP
          rules:
            http:
              - method: POST
                path: '/payment/.*'
                headers:
                  - 'X-Auth-Token: .*'

Résultat :

  • Policies : 10,000+ appliquées
  • Performance : native (eBPF)
  • Compliance : SOC2, PCI-DSS
Cas 3 : Container security (Datadog)

Problème : Détecter runtime attacks

Solution : Falco + Tetragon

Détections :

  • Container escape attempts
  • Privilege escalation
  • Crypto mining
  • Lateral movement

Résultat :

  • Détections : 1 200+ menaces/mois
  • Faux positifs : moins de 1 %
  • Temps de réponse : moins de 5s

Développement eBPF

Outils développement
# Installer dependencies
apt install clang llvm libelf-dev libbpf-dev bpftool

# Cloner libbpf
git clone https://github.com/libbpf/libbpf-bootstrap
cd libbpf-bootstrap/examples/c
Exemple : tracer syscalls
// syscall_tracer.bpf.c
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __type(key, u32);
    __type(value, u64);
    __uint(max_entries, 1024);
} syscall_count SEC(".maps");

SEC("tracepoint/raw_syscalls/sys_enter")
int trace_syscall_enter(struct trace_event_raw_sys_enter *ctx) {
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    u64 *count = bpf_map_lookup_elem(&syscall_count, &pid);

    if (count) {
        __sync_fetch_and_add(count, 1);
    } else {
        u64 init = 1;
        bpf_map_update_elem(&syscall_count, &pid, &init, BPF_ANY);
    }

    return 0;
}

char LICENSE[] SEC("license") = "GPL";
// syscall_tracer.c (userspace)
#include <stdio.h>
#include <unistd.h>
#include <bpf/libbpf.h>
#include "syscall_tracer.skel.h"

int main() {
    struct syscall_tracer_bpf *skel;

    // Load and verify BPF program
    skel = syscall_tracer_bpf__open_and_load();
    if (!skel) {
        fprintf(stderr, "Failed to load BPF program\n");
        return 1;
    }

    // Attach to tracepoint
    if (syscall_tracer_bpf__attach(skel) < 0) {
        fprintf(stderr, "Failed to attach BPF program\n");
        syscall_tracer_bpf__destroy(skel);
        return 1;
    }

    printf("Tracing syscalls... Press Ctrl-C to stop\n");

    // Poll map every second
    while (1) {
        sleep(1);

        u32 pid;
        u64 count;
        int fd = bpf_map__fd(skel->maps.syscall_count);

        while (bpf_map_get_next_key(fd, &pid, &pid) == 0) {
            bpf_map_lookup_elem(fd, &pid, &count);
            printf("PID %d: %llu syscalls\n", pid, count);
        }
    }

    syscall_tracer_bpf__destroy(skel);
    return 0;
}
# Compiler
clang -O2 -g -target bpf -c syscall_tracer.bpf.c -o syscall_tracer.bpf.o
bpftool gen skeleton syscall_tracer.bpf.o > syscall_tracer.skel.h
gcc -o syscall_tracer syscall_tracer.c -lbpf -lelf -lz

# Exécuter
sudo ./syscall_tracer

Checklist adoption eBPF

✅ Prérequis :

  • Kernel Linux ≥5.15
  • BTF (BPF Type Format) enabled
  • libbpf installé
  • bpftool disponible

✅ Networking :

  • Évaluer Cilium vs CNI actuel
  • Tester kube-proxy replacement
  • Activer Hubble observabilité
  • Configurer network policies L7
  • Benchmark performance

✅ Observabilité :

  • Installer Pixie ou alternative
  • BPFtrace pour debugging
  • Intégrer avec Prometheus
  • Dashboards Grafana
  • Alertes sur métriques eBPF

✅ Sécurité :

  • Déployer Falco runtime security
  • Configurer règles custom
  • Tetragon pour enforcement
  • Intégration SIEM
  • Incident response playbook

✅ Production :

  • Tests charge/performance
  • Rollback plan
  • Documentation équipe
  • Formation équipe ops
  • Monitoring adoption

Conclusion

eBPF révolutionne Linux en permettant observabilité, networking et sécurité haute performance sans modification kernel. L'adoption massive en 2026 (64 % Kubernetes avec Cilium) confirme que c'est devenu un standard.

Points clés :

  • eBPF = code kernel safe et rapide
  • Cilium = CNI eBPF 10x plus rapide
  • Pixie = observabilité sans instrumentation
  • Falco = runtime security essentielle
  • Performance native sans overhead

Gains typiques :

  • Networking : +20x débit (XDP)
  • Latence : -80 % (kube-proxy → Cilium)
  • Sécurité : détection runtime sans agent
  • Observabilité : 0 instrumentation du code
  • CPU : -60 % vs iptables

Actions prioritaires :

  1. Tester Cilium dans cluster dev
  2. Installer Pixie pour observabilité
  3. Déployer Falco runtime security
  4. BPFtrace pour debugging
  5. Benchmarker vs solution actuelle
Besoin d'aide sur ce sujet ?

Notre équipe d'experts est là pour vous accompagner dans vos projets d'infrastructure et d'infogérance.

Contactez-nous

Articles similaires

nftables Avancé : Sets Dynamiques, Verdict Maps, Conntrack Zones et Rate Limiting par IP
Linux
Sécurité
Réseau

nftables Avancé : Sets Dynamiques, Verdict Maps, Conntrack Zones et Rate Limiting par IP

Vous connaissez nftables, mais vous n'utilisez probablement que 10% de ses capacités. Sets dynamiques avec timeout, verdict maps pour du routing intelligent, conntrack zones pour isoler les flux, rate limiting par IP avec meters. Tout ça dans le noyau, sans script externe, sans fail2ban.

17 févr. 2026

Lire plus

Nginx avancé : Maîtriser le Reverse Proxy en production sur Linux
Linux
Réseau
Sécurité

Nginx avancé : Maîtriser le Reverse Proxy en production sur Linux

Guide complet sur Nginx comme reverse proxy en production : configuration multi-sites, SSL avec Let's Encrypt, rate limiting, load balancing, cache, logs d'accès. Tout ce qu'il faut pour servir des applications en toute sécurité.

14 févr. 2026

Lire plus

SSH Avancé : Tunnels, ProxyJump et SOCKS Proxy, SSH n'est pas juste une connexion distante
Linux
Sécurité
Réseau

SSH Avancé : Tunnels, ProxyJump et SOCKS Proxy, SSH n'est pas juste une connexion distante

Vous pensez maîtriser SSH parce que vous faites ssh user@host ? Tunnels, ProxyJump, agent, ~/.ssh/config, forwarding dynamique comme un SOCKS proxy : SSH est un réseau à l'intérieur du réseau. Tout ce qu'il faut savoir.

13 févr. 2026

Lire plus


SHPV, votre partenaire de confiance en infrastructure et infogérance informatique en France.

SHPV
Prendre rendez-vousNous contacter
Expertise
InfrastructureDatacenterInfogéranceCloudHébergementTransit IP
Légales
Conditions Générales de VenteCPS - Contrat de ServicesCPS - Hébergement CloudCPS - Microsoft 365Accord sous-traitance RGPDTarifs interventions

SHPV © 2026 - Tous droits réservés

Mentions légalesPolitiques de confidentialité
SHPV FRANCE - SAS au capital de 16 000 € - 52 Rue Romain Rolland, 71230 Saint-Vallier - SIRET n°80886287400035 - R.C.S. Chalon-sur-Saône. Par téléphone 09 72 310 818 - Email: support@shpv.fr