XTQ/Blog

Sfaturi pentru hosterii la început de drum, cu comenzi Linux pentru fiecare

, 12 min de citit · Read in English

Pe r/programare a apărut un băiat care tocmai și-a pornit o firmă mică de hosting și a cerut păreri sincere. M-am uitat pe site și am găsit exact greșelile pe care le văd la aproape toți cei care încep. Nu dau nume, nu e despre el. E despre tiparul ăsta, pentru că se repetă.

Fac hosting de ceva vreme și am făcut și eu o parte din greșelile de mai jos. Așa că lista e scrisă din experiență, nu din teorie, și la fiecare punct ai și comenzile cu care verifici și repari.

1. Nu pune DNS-ul pe același server cu site-ul

Cea mai des întâlnită greșeală: ns1 și ns2 arată spre același IP, adică exact serverul pe care stau site-urile.

De ce e grav: când pică serverul, nu pică doar site-urile. Pică și DNS-ul. Clienții tăi rămân fără site, dar și fără mail, pentru că serverele care încearcă să le trimită mail nu mai găsesc înregistrarea MX și, după o vreme, mailurile se întorc cu bounce. Două nameservere pe același IP nu înseamnă redundanță, înseamnă același punct de eșec scris de două ori.

Verifică:

dig +short NS domeniultau.ro
dig +short ns1.domeniultau.ro A
dig +short ns2.domeniultau.ro A

Dacă cele două IP-uri sunt identice, sau măcar în aceeași rețea /24 de la același furnizor, ai o problemă.

Ce faci:

  • Minim: al doilea nameserver pe un VPS separat, la alt furnizor, ca secondary care primește zonele prin transfer (AXFR/IXFR).
  • Mai simplu: folosește un DNS administrat pentru zonele tale, de exemplu Cloudflare, deSEC sau Hurricane Electric (gratuit), și lasă serverul doar pentru web și mail.
  • cPanel/WHM are DNS cluster nativ: poți lega un al doilea server DNS ca membru al clusterului, iar zonele se sincronizează singure.

Exemplu de secondary cu BIND pe un VPS separat (/etc/bind/named.conf.local):

zone "domeniultau.ro" {
    type secondary;
    primaries { IP_SERVER_PRINCIPAL; };
    file "/var/cache/bind/domeniultau.ro.db";
};

Iar pe serverul principal permite transferul doar către secondary (allow-transfer { IP_SECONDARY; };) și trimite notify la fiecare modificare.

2. Nu vinde protecție DDoS pe care n-o ai

„Protecție DDoS la nivel de datacenter" sună bine pe o pagină de prețuri. În realitate, la majoritatea furnizorilor mari de servere, asta e filtrarea de bază pe care o primește orice client, gratuit. Te apără de un flood volumetric simplu, nu de un atac țintit pe aplicație (layer 7), cum ar fi mii de cereri HTTP pe secundă către pagina de login.

Și clienții verifică. Nu toți, dar cei care contează da. Durează zece secunde să afli unde stă de fapt un site:

dig +short domeniultau.ro A
whois IP | grep -iE "netname|descr|origin|country"

Sau pe bgp.tools și check-host.net, unde vezi și ASN-ul, și din ce țări răspunde serverul.

Dacă serverele tale sunt la un furnizor de servere dedicate din Germania, spune asta clar pe site. E perfect ok. Nu e ok să lași impresia că ai o infrastructură anti-DDoS proprie când ai protecția standard a datacenterului.

Pe termen lung, dacă vrei să vinzi protecție reală:

  • Ia-ți un ASN propriu (prin RIPE, direct sau printr-un LIR).
  • Închiriază un /24 de IPv4 (IPXO și alte platforme de leasing) sau cumpără unul.
  • Fă-ți upstream la un furnizor serios pe anti-DDoS, care îți anunță prefixul și filtrează înainte să ajungă traficul la tine.
  • Pentru layer 7 ai nevoie de un reverse proxy care știe să distingă un om de un bot, nu doar de un firewall.

Un mic ajutor aici: xTQ Web, web serverul și reverse proxy-ul meu. E mai ușor de configurat decât nginx sau Caddy, are HTTPS automat și protecție la flood-uri din prima, și poate sta fără probleme în fața unui nginx (sau Apache, LiteSpeed) pe care îl ai deja. Un site întreg e o linie:

bind 0.0.0.0:80
https 0.0.0.0:443
site exemplu.ro www.exemplu.ro { proxy 127.0.0.1:8080 }

Se instalează cu curl -fsSL https://xtq.ro/web/install.sh | sh, iar documentația completă e pe xtq.ro/web/docs. E gratuit pentru uz personal și necomercial. Pentru o firmă de hosting, adică uz comercial, e nevoie de licență, scrie-mi și găsim o variantă.

Are și suport pentru agenți AI: există un ghid scris special pentru ei, așa că îi poți spune lui Claude, ChatGPT sau Gemini „instalează xTQ Web pe serverul meu și pune site-ul în spatele lui" și știe exact ce are de făcut, fără să strice nimic. Proprietarul nu trebuie să fie tehnic.

Până atunci, poți face destul de mult chiar pe server.

Kernel, împotriva floodurilor SYN și a conexiunilor lăsate pe jumătate (/etc/sysctl.d/99-hosting.conf):

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_synack_retries = 2
net.core.somaxconn = 4096
net.ipv4.conf.all.rp_filter = 1

Aplică cu sysctl --system.

Limitare de rată la nivel de web server, de exemplu în nginx:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;

server {
    location / {
        limit_req zone=perip burst=40 nodelay;
        limit_conn conn 30;
    }
    location = /wp-login.php {
        limit_req zone=perip burst=5;
    }
}

Pe LiteSpeed/OpenLiteSpeed există echivalentul în setările de „Per Client Throttling", iar pe cPanel cu CloudLinux ai deja limite de resurse per cont (LVE), care nu lasă un singur client să doboare tot serverul.

Banare automată pentru cine încearcă parole sau scanează (fail2ban, /etc/fail2ban/jail.local):

[sshd]
enabled = true
maxretry = 5
bantime = 1h

[nginx-limit-req]
enabled = true
logpath = /var/log/nginx/error.log
maxretry = 10
bantime = 1h

Sau CrowdSec, care face același lucru dar împarte listele de IP-uri rele între toți cei care îl folosesc.

3. Mailul: reputația IP-ului contează mai mult decât SPF-ul

Dacă promiți clienților că mailurile lor nu ajung în spam, asta e partea pe care trebuie s-o faci cel mai bine. SPF, DKIM și DMARC sunt obligatorii, dar nu sunt suficiente: dacă IP-ul de pe care trimiți are reputație slabă, mailurile ajung în spam oricât de corect ar fi semnate. Multe range-uri de la furnizori de servere ieftine au exact problema asta.

Verifică tot ce contează:

# PTR (reverse DNS): trebuie să existe și să se potrivească cu numele din HELO
dig +short -x IP_SERVER_MAIL

# SPF, DKIM, DMARC
dig +short TXT domeniultau.ro | grep spf
dig +short TXT default._domainkey.domeniultau.ro
dig +short TXT _dmarc.domeniultau.ro

# IP-ul e pe vreo listă neagră?
for bl in zen.spamhaus.org bl.spamcop.net b.barracudacentral.org; do
  r=$(echo IP_SERVER_MAIL | awk -F. '{print $4"."$3"."$2"."$1}')
  echo "$bl: $(dig +short $r.$bl)"
done

Un rezultat gol la ultima comandă înseamnă că nu ești listat. Notă: Spamhaus nu răspunde la interogări venite prin resolverele publice mari (Google, Cloudflare), așa că rulează testul de pe server, cu resolverul lui.

DMARC de pornire, care doar raportează fără să blocheze nimic:

_dmarc.domeniultau.ro.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

După ce rapoartele arată curat câteva săptămâni, treci la p=quarantine, apoi la p=reject.

Ce faci dacă IP-ul are reputație slabă: trimite prin un relay cu reputație bună (un serviciu SMTP dedicat) sau cere furnizorului IP-uri curate. Și testează real, nu doar cu dig: trimite un mail la mail-tester.com și uită-te la scor.

4. VPS-uri: folosește Proxmox, nu reinventa roata

Dacă vinzi VPS-uri, nu le face de mână cu virsh și scripturi lipite cu bandă adezivă. Proxmox VE e gratuit, open source, rulează KVM, și îți dă din prima tot ce îți trebuie ca hoster: șabloane, clonare în câteva secunde, limite per VM, firewall per VM, snapshot-uri, backup, cluster cu mai multe noduri și un API pe care îl poți lega de panoul de facturare. Noi îl folosim în producție.

Instalează-l pe un server dedicat cu ISO-ul oficial, sau peste un Debian curat, și folosește ZFS pentru discuri (mirror sau RAIDZ): ai snapshot-uri ieftine, compresie și verificarea integrității datelor din oficiu.

Un șablon cu cloud-init, o singură dată

Ideea: faci un VM șablon dintr-o imagine cloud oficială, iar fiecare VPS nou e o clonă a lui, configurată automat la prima pornire (utilizator, cheie SSH, IP).

cd /var/lib/vz/template/iso
wget https://cloud.debian.org/images/cloud/trixie/latest/debian-13-genericcloud-amd64.qcow2

qm create 9000 --name debian13-tpl --memory 2048 --cores 2 \
  --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-single --agent enabled=1 \
  --serial0 socket --vga serial0
qm disk import 9000 debian-13-genericcloud-amd64.qcow2 local-zfs
qm set 9000 --scsi0 local-zfs:vm-9000-disk-0,discard=on,iothread=1 \
  --ide2 local-zfs:cloudinit --boot order=scsi0
qm template 9000

Un VPS nou pentru un client, în câteva secunde

qm clone 9000 101 --name client-101 --full
qm set 101 --cores 2 --memory 4096 \
  --ciuser root --sshkeys /root/client-101.pub \
  --ipconfig0 ip=203.0.113.10/24,gw=203.0.113.1 \
  --nameserver 1.1.1.1
qm resize 101 scsi0 40G
qm start 101

Limite, ca un client să nu-i încurce pe ceilalți

# lățime de bandă pe placa de rețea (MB/s, 12.5 = aprox. 100 Mbit/s)
qm set 101 --net0 virtio,bridge=vmbr0,rate=12.5

# limite de citire/scriere pe disc
qm set 101 --scsi0 local-zfs:vm-101-disk-0,discard=on,iothread=1,mbps_rd=200,mbps_wr=150,iops_rd=4000,iops_wr=2000

# cât CPU poate folosi, ca să nu monopolizeze nodul
qm set 101 --cpulimit 2 --cpuunits 100

Firewall per VM și anti-spoofing: obligatoriu

Asta e partea pe care începătorii o sar și apoi se miră de ce au fost raportați pentru abuz. Fără filtrare, un client poate să-și pună în VPS un IP care nu e al lui sau să trimită pachete cu adresa sursă falsificată, iar reclamațiile vin pe numele tău.

Pornește firewall-ul la nivel de datacenter (din interfață sau în /etc/pve/firewall/cluster.fw), apoi pentru fiecare VM (/etc/pve/firewall/101.fw):

[OPTIONS]
enable: 1
ipfilter: 1
macfilter: 1
policy_in: ACCEPT

[IPSET ipfilter-net0]
203.0.113.10

Cu ipfilter: 1, VM-ul poate trimite trafic doar de pe IP-urile din setul lui. Pune și firewall=1 pe placa de rețea a VM-ului (--net0 virtio,bridge=vmbr0,firewall=1), altfel regulile nu se aplică.

Backup cu Proxmox Backup Server

Proxmox Backup Server (tot gratuit) face backup incremental cu deduplicare: după primul backup complet, următoarele trimit doar blocurile schimbate, deci poți face backup zilnic la sute de VPS-uri fără să-ți umpli storage-ul. Pune-l pe alt server, în altă locație.

# după ce ai adăugat PBS ca storage numit "pbs"
vzdump 101 --storage pbs --mode snapshot

# sau programat, pentru toate VM-urile, din Datacenter > Backup

Și restaurează ocazional un VM de test din backup, ca să știi că merge.

Automatizare

Tot ce ai văzut mai sus se poate face prin API-ul Proxmox (pvesh sau HTTP), deci poți lega crearea VPS-urilor de facturare: clientul plătește, VPS-ul se creează singur. Există module gata făcute pentru WHMCS și alte panouri, sau îți scrii propriul tău flux.

pvesh get /nodes/$(hostname)/qemu --output-format json

5. Prețuri corecte, nu prețuri care mizează pe neștiință

Mulți oameni cred că un preț mare înseamnă calitate. Știu și eu că nu toată lumea se pricepe să verifice cu check-host sau bgp.tools unde stă de fapt serverul. Dar nu exploata categoria asta.

Un VPS revândut de la un furnizor ieftin, la de două ori prețul, cu pagina plină de „premium" și „enterprise", nu e o afacere, e o capcană. Clientul află mai devreme sau mai târziu, iar în hosting reputația e tot ce ai. La fel cu domeniile: dacă un .com costă la tine mult peste prețul obișnuit al registrarilor, oamenii o să compare.

Fă-ți prețul din costul real plus marja ta plus munca ta, și spune clar ce primește clientul pentru diferență: suport rapid în română, migrare gratuită, backup testat. Asta se vinde singur.

6. Backup: nu contează că îl faci, contează că îl poți restaura

„Backup zilnic" pe pagina de prețuri și „depinde de plan" în FAQ e genul de contradicție pe care un client o găsește exact în ziua în care are nevoie de backup. Alege o politică și scrie aceeași peste tot.

Pentru serverele de hosting web (fără Proxmox Backup Server), backup-ul trebuie să fie în afara serverului, criptat și testat. Exemplu cu restic, către un storage separat:

export RESTIC_REPOSITORY="sftp:[email protected]:/backups/server1"
export RESTIC_PASSWORD_FILE=/root/.restic-pass

restic init                                   # o singură dată
restic backup /home /etc /var/lib/mysql-dumps --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check                                  # verifică integritatea

Pentru baze de date, nu copia fișierele cât rulează MySQL. Fă dump înainte:

mysqldump --all-databases --single-transaction --routines --events | gzip > /var/lib/mysql-dumps/all-$(date +%F).sql.gz

Și o dată pe lună, restaurează ceva pe un server de test. Un backup pe care nu l-ai restaurat niciodată e o speranță, nu un backup:

restic restore latest --target /tmp/restore-test --include /home/client1

Pe cPanel, JetBackup face asta pentru tine, dar regula rămâne: destinația să fie în altă locație, și testul de restaurare să existe.

7. Actualizări, firewall și SSH, pe orice server

Lucrurile de bază pe care le-aș face pe orice server nou, înainte de primul client:

# actualizări automate de securitate (Debian/Ubuntu)
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

SSH doar cu chei, fără root cu parolă (/etc/ssh/sshd_config.d/hardening.conf):

PasswordAuthentication no
PermitRootLogin prohibit-password
MaxAuthTries 3

Firewall cu nftables, totul închis în afară de ce folosești:

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
    tcp dport { 22, 80, 443 } accept
    tcp dport { 25, 465, 587, 993, 995 } accept   # doar dacă ai mail pe server
  }
}

Pe cPanel folosește firewall-ul pe care îl gestionează panoul, iar pe nodurile Proxmox firewall-ul Proxmox, nu două firewall-uri care se bat între ele.

8. Monitorizare și pagină de status

Clienții tăi nu ar trebui să afle de la vizitatorii lor că le-a picat site-ul. Tu trebuie să afli primul.

  • Monitorizare externă (din altă rețea decât serverul): Uptime Kuma pe un VPS separat e gratuit și simplu.
  • Alertă pe telefon, nu doar pe mail.
  • Pagină publică de status. Pare că recunoști că ai probleme, dar în practică crește încrederea: oamenii văd că știi ce se întâmplă.

Uptime Kuma, pe un server separat:

docker run -d --restart=unless-stopped -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

Și pune în ea nu doar „răspunde site-ul", ci și DNS-ul (fiecare nameserver separat), portul 25 pentru mail și expirarea certificatelor SSL.

9. Site-ul tău e primul lucru pe care clientul îl verifică

Mici lucruri care scad încrederea mai mult decât crezi:

  • „Suport 24/7" lângă „răspuns în 1-2 zile lucrătoare". Alege ce poți ține de fapt și scrie asta.
  • Imagini lipsă sau text de șablon rămas pe pagină.
  • Nicio recenzie, niciun client numit. Cere-le primilor clienți mulțumiți câteva rânduri.
  • Firma, CUI-ul, adresa, link-urile ANPC și politicile clare. Aici, sincer, mulți hosteri mici o fac mai bine decât cei mari. Păstrează-le.

Pe scurt

  1. DNS separat de web, pe alt furnizor.
  2. Spune exact ce protecție ai și unde sunt serverele.
  3. Mail: PTR, SPF, DKIM, DMARC și un IP cu reputație bună.
  4. VPS-uri pe Proxmox, cu șabloane, limite, anti-spoofing și Proxmox Backup Server.
  5. Prețuri cinstite. Clientul o să compare.
  6. Backup în altă parte, testat lunar.
  7. Actualizări automate, SSH cu chei, firewall închis implicit.
  8. Monitorizare din afară și pagină de status.
  9. Un site care spune același lucru peste tot.

Niciunul nu e greu. Toate împreună fac diferența dintre un hoster pe care clienții îl recomandă și unul de care fug după primul incident.

Dacă aveți nevoie de protecție layer 7 pentru site-urile voastre sau pentru clienții voștri, scrieți-mi la [email protected] și discutăm cu drag.

Publicat pe xtq.ro pe 8 noiembrie 2026. © 2026 xTQ. Toate drepturile rezervate. Republicarea este permisă doar cu mențiunea drepturilor de autor și a sursei, xtq.ro.