Visualizza post

Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.


Post - lossoth

Pagine: [1] 2
1
Server / Re: PHP + Postgresql lento
« il: 14 Ottobre 2011, 16:54:20 »
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

Codice: [Seleziona]
# 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

2
Server / PHP + Postgresql lento
« il: 14 Ottobre 2011, 12:30:08 »
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?

Non posso cambiare DB...

Gli indici sono messi bene.

Il dubbio che mi assale che abbia messo qualche impostazione tcp che non va bene per postgres (in un post precedente c' im mio sysctl.conf modificato).

Edit:
Mi sono limitato a riportare il tuo post precedente.

3
Sicurezza / Re: attacco "SYN FLOOD" con spoofed IP
« il: 14 Ottobre 2011, 10:46:11 »
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.

4
Sicurezza / Re: attacco "SYN FLOOD" con spoofed IP
« il: 12 Ottobre 2011, 16:50:50 »
Sto studiando alla grande...

Ma che ci sia una maniera di risalire all'IP effettivo che compie l'attacco? O meglio che lascio perdere e mi concentro su come difendermi...?

5
Sicurezza / Re: attacco "SYN FLOOD" con spoofed IP
« il: 12 Ottobre 2011, 12:23:50 »
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" :)

6
Sicurezza / Re: attacco "SYN FLOOD" con spoofed IP
« il: 12 Ottobre 2011, 10:08:57 »
non mi pare di vedere nulla di strano nei log apache
i server sono a noleggio, non li ho sotto mano
ho chiesto all'assistenza di verificare la scheda rete della 00 e mi hanno detto che non c' nulla di strano
presumo che i server siano collegati a interne tramite un qualche router e non ci sono collegameti tra di loro, parlano appunto via internet

7
Sicurezza / Re: attacco "SYN FLOOD" con spoofed IP
« il: 11 Ottobre 2011, 19:23:10 »
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

8
Sicurezza / Re: attacco "SYN FLOOD" con spoofed IP
« il: 11 Ottobre 2011, 19:17:28 »
Ho fatto veri test nei giorni passati per essere sicuro di escludere quanto dici.
Infatti con postgres spento sulla 00 comunque lento, cosa che prima del syn flood non succedeva.
E' colpa di sto attacco...
La cosa strana che ho fatto tutte le modifiche ai parametri tcp che ho trovato (in parte indicatemi da dankan77 nella prima risposta), ma non rieco a vedere miglioramenti

 :-[

riporto il mio sysctl.conf

Codice: [Seleziona]
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled.  See sysctl(8) and
# sysctl.conf(5) for more details.

# 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

9
Sicurezza / Re: attacco "SYN FLOOD" con spoofed IP
« il: 11 Ottobre 2011, 18:05:32 »
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?

10
Sicurezza / Re: attacco "SYN FLOOD" con spoofed IP
« il: 11 Ottobre 2011, 17:25:01 »
per alleviare i sintomi dell'attacco ho fermato tutto il php e postgres che girano sulla macchina in questione
praticamente la parte pubblica (www) funziona bene ma manca met della roba...
non so se mi sono spiegato...

11
Sicurezza / Re: attacco "SYN FLOOD" con spoofed IP
« il: 11 Ottobre 2011, 17:23:01 »
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

12
Sicurezza / Re: attacco "SYN FLOOD" con spoofed IP
« il: 11 Ottobre 2011, 15:20:33 »
per passare da "off" a "on" SELinux pu fare dei danni, c' scritto qui:
http://wiki.centos.org/HowTos/SELinux#head-867ca18a09f3103705cdb04b7d2581b69cd74c55

In questo momento non posso avere anche altre rogne:
sto syn flood da una settimana che mi distrugge...
praticamente sto rischiando il posto (non sto scherzando)

Quindi per favore, pu essere veramente ultile al mio scopo SELinux? da quello che vedo dalla documentazione no

Per adesso ho sistemato le variabili net.ipv4 secondo quanto indicato in varie guide,
ma non riscontro miglioramenti nella velocit del sito, adesso passo al tuning che mi consigliava dankan77 nella prima risposta

13
Sicurezza / Re: attacco "SYN FLOOD" con spoofed IP
« il: 11 Ottobre 2011, 12:50:03 »
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...

14
Sicurezza / Re: attacco "SYN FLOOD" con spoofed IP
« il: 11 Ottobre 2011, 12:17:59 »
scusa la domanda da ignorante: ma una volta abilitato SELinux mi si attiva netfilter?

15
Sicurezza / Re: attacco "SYN FLOOD" con spoofed IP
« il: 11 Ottobre 2011, 11:55:49 »
#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...

Pagine: [1] 2