fatto tutto il tuning e riavviato
non ci sono meglioramenti

la cosa strana è che le query fatte nel sito sono troppo lente mentre quelle via psql sono una scheggia

quindi mi sa che il problema non è delle prestazioni di postrgres in se...

non vorrei fossero le modifiche fatte a tcp, soprattutto i timeout...
riporto sysctl.conf

# Controls IP packet forwarding
net.ipv4.ip_forward = 0

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 1

# Controls whether core dumps will append the PID to the core filename
# Useful for debugging multi-threaded applications
kernel.core_uses_pid = 1

# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1

# Controls the maximum size of a message, in bytes
kernel.msgmnb = 65536

# Controls the default maxmimum size of a mesage queue
kernel.msgmax = 65536

# Controls the maximum shared segment size, in bytes
kernel.shmmax = 68719476736

# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296

#custom: 20111007: prevent syn flood:
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 1
net.core.wmem_max = 12582912
net.core.rmem_max = 12582912
net.ipv4.tcp_rmem = 10240 87380 12582912
net.ipv4.tcp_wmem = 10240 87380 12582912
net.ipv4.tcp_no_metrics_save = 1
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.netfilter.ip_conntrack_max = 131072
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 208000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 80
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 20
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 40
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 20


Ciao, rieccomi ancora con altri problemi.
 
Da quando ho riacceso tutto ho dei problemi con postges: alcune volte ha dei rallentamenti improvvisi e le query fatte dall'interfaccia web sono troppo lente.
Postgres gira sulla stessa macchina sotto attacco e viene lanciato dal php sempre sulla stessa macchina per eseguire delle query da visualizzare nella parte pubblica web.
Ieri ho fatto un po' di tuning di postgresql.conf alzando i seguenti valori da -> a:
- max_connections 200->400
- shared_buffers 32Mb->64Mb
- effective_cache_size 128Mb -> 4096Mb
(il server ha 8Gb RAM)

C'è una cosa strana che non capisto:
analizzando i log delle query fatte da php via apache queste sono nell'ordine dei 5 secondi! mentre la stessa query lanciata con explain analyze in psql sul medesimo db (via shell) da un tempo nell'ordine dei 0.05 millisecondi!
Quindi non è il db in se ad andare piano, ma è quando una query viene lanciata da php.

Qualche idea?

PS:
riguardo la documentazione e gli schemi della mia applicazione: non posso girarvi pari pari la documentazione ufficiale (già parlato con i capi...), dovrei riscriverla ad hoc e non ho tempo...
Però per questo problema possiamo supporre di avere a che fare con un unico server sotto attacco dove gira Apache, php e postgres.

E' un po' presto per cantare vittoria ma MI SEMBRA DI AVERE RISOLTO
o meglio, di avare limitato in maniera accettabile i rallentamenti dovuti al syn flood.
Questo grazie alle ultime modifiche ai parametri tcp (vedi post di ieri)
Ho riavviato tutta l'applicazione al 100% e sembra reggano sia attività di frontend che backend.
Ci sono dei rallentamenti ma da un'ora sembra reggere... vediamo nel pomeriggio che ho il picco di utenze

RINGRAZIO IMMENSAMENTE TUTTI PER L'AIUTO E LA PAZIENZA
come avrete notato non sono un sistemista scaltro: principalmente programmo, solo che avendo da gestire una webapp distribuita su 10 server e NON essendoci un sistemista vero e proprio, mi devo arrangiare. Fino adesso non ero mai sceso a livello tcp me l'ero sempre cavata con cose a "più alto livello". Purtroppo l'attacco è avvenuto alla macchina principale del sistema e guarda caso in questi giorni il mio capo (che ne capisce più di me a livello sistemistico) è in giro per il mondo e non mi può aiutare.

COMUNQUE Il discorso non è chiuso perchè voglio capire meglio alcune cose e propagare le modifiche agli altri server.
Soprattutto: è veramente impossibile risalire all'autore dell'attacco se questo usa IP cammuffati, o c'è qualche trucchetto alla "film americano"?

@LoneyWolf
- Il supporto tecnico dei server mi ha assicurato che l'hardware è ok
- Ho già messo una cosa molto simile in iptables anche per la porta 22
- Certo che riavvio sysctl e iptables [fin li ci arrivo ]
- ListenBackLog = 10000

@dankan77
- lo schema architetturale della mia webapp è abbastanza complesso: 10 server come dicevo prima. Posso certo fornirlo ma penso che per la questione del syn flood facciamo prima a simulare che sia su una macchina unica e pari. Ho già fatto tutti i test con "prova del 9" per assicurarmi che non sia il mio sistema stesso che mi causa questo overload di syn requests. Della cosa ne sono abbastanza sicuro: quello è il mio pane php quotidiano...
- fino adesso per lavorare sui syn ho usato netstat e vari grep per evdenziare gli ip...
ma immagino che tu intenda qualcosa di più strutturato... puoi darmi qualche indicazione ulteriore magari che valori monitorare e se c'è qualche tool?
- non so cosa sia un "SAR", indago...
- sempre pronto a crescere, cosa intendi per "approccio più di di tipo enterprise fac-simile"

altra precisazione:
la 01 non è lenta, cioè la parte del sito generata dalla 01 è ok
il problema è appunto sulla parte servita dalla 00
quindi per il problemna possimo escludere la 01, il "proxy", php e postrgres della 00 in quanto adesso sono spenti
adesso apache della 00 non fa altro che servire delle immagini, il "RewriteRule" che punta alla 01 è veloce
alcune immagini impiegano più di tre secondi a caricarsi, mentre prima del syn flood era tutto nell'ordine dei millisecs
il problema è prima di apache, netstat mostra un casino di SYN_RECV che non riesco a diminuire neanche abbassando il timeout ip_conntrack_tcp_timeout_syn_recv a 1

per semplicita chiamiamo:
00 - server principale che fa da proxy
01 - l'altro server

a regime la 00 deve soddisfare alcune richieste www (dipendenti da particolare url api inviati da ajax): queste vengono deliverate dalla 00 stessa tramite php e il suo db postgres e sono quelle che ho bloccato adesso e che mi fanno andare il sito "a metà"

tutto ciè che non è "api" viene reindirizzato alla 01

il "proxy" nella 00 viene fatto con le regole mod rewrite di httpd.conf

i log di postgres sulla 01 non hanno nulla di strano, perchè dovrebbero?

php, anche se adesso il php che gira nella macchina è fermo
la macchina sotto attacco fa da proxy verso un'altra dove gira effettivamente php e postgres che servono al funzionamento minimo.
Adesso che è sotto attacco apache è soggetto al 50% del lavoro standard: praticamente fa solo il proxy verso l'altro server e delivera delle immagini piccole

che trippone! ho trovato il parametro che cercavo! è:
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv

Posso tornare a considerare i tuning che mi suggerivi.
Non abiulito SELinux in quanto non posso rischiare di corrompere il filesystem...

Grazie per la pazienza, spero di riuscire a limitare sto attacco...

#set enforce 1 ->
setenforce: SELinux is disabled

cambio /etc/selinux/config mettendo
SELINUX=enforcing ?
(adesso è "disabled")

qui http://www.centos.org/docs/5/html/5.2/Deployment_Guide/sec-sel-enable-disable.html
dice che bisogna riavviare il sistema poi...