cpu 100%

[steam-roller]

Ciao a tutti!

Vi pongo il seguente problema. E' normale che l'applicazione "amule" faccia schizzare al 100% la cpu? In particolare, tramite "htop", noto che il comando -> firestarter --start-hidden occupi il 100% della cpu. In sostanza, con amule attivo, il firewall blocca molte connessioni (visibili nel tab eventi di Firestarter) e ciò provoca un consumo abnorme di cpu.

C'è la possibilità di limitare l'uso della cpu? Vorrei evitare di fondere il PC.

Grazie in anticipo.

:)

[ilsensine]

Chi è che va al 100%, amule o firestarter?

[steam-roller]

Chi è che va al 100%, amule o firestarter?

Ciao.

Tramite "htop" il comando "firestarter --start-hidden" (voce che ho inserito alla sessione di avvio al fine di far partire "firestarter" ad ogni avvio del PC) occupa il 100% della cpu; ciò si verifica nel momento in cui eseguo "amule" (2 file in download e 4 in condivisione). Se termino il "mulo" l'occupazione della cpu ritorna a livelli accettabili.

E' normale?

[ilsensine]

Direi proprio di no. La colpa non è del firewall di linux (iptables, di cui firestarter dovrebbe essere solo un frontend); non conosco questo programma e non ho idea di cosa faccia, ma evidentemente non si limita solo a configurare iptables e basta.

Fossi in te ne farei a meno.

[steam-roller]

In realtà ho scelto di installare "Firestarter" per configurare in modo semplice il firewall di linux.

Esiste la possibilità di terminare un programma automaticamente (nel mio caso il programma è "amule") nel momento in cui la cpu resta, per tempi prolungati, al 100%?

Forse chiedo troppo ma il bello di Linux è anche questo -> gestire ed utilizzare il PC secondo le proprie esigenze.

Ciao.
:)

[ilsensine]

Perché te la prendi col povero innocente quando il colpevole resta allegramente in esecuzione?
Una volta che Firestarter ha configurato iptables, può anche terminare e andare al diavolo.

[steam-roller]

Perché te la prendi col povero innocente quando il colpevole resta allegramente in esecuzione?
Una volta che Firestarter ha configurato iptables, può anche terminare e andare al diavolo.

Mi stai consigliando di eliminare dalla sessione d'avvio il comando inerente "Firestarter"? In tal modo non comprometto nulla in termini di sicurezza?
Tra i motivi per i quali ho scelto Linux sul PC desktop vi sono: sicurezza, stabilità ed affidabilità. Quindi l'aspetto firewall, per me, è molto importante.

E' anche vero che "Firestarter" è un'interfaccia grafica per il firewall di linux (iptables). Mi chiedo, quindi: "Terminando Firestarter si compromette iptables?"

Scusa la mia diffidenza ma sono alle prime armi con Linux; provengo da anni di Windows (anche se recentemente utilizzo, come notebook, un MAC) ed ho imparato che le minacce sono sempre in agguato.

:)

[W.S.]

Non conosco firestarter e il modo in cui lavora, dovrebbe comunque generare uno script che imposta le regole in iptables, tutto li. Una volta eseguito lo script non vedo perché firestarter dovrebbe rimanere in esecuzione.
Semplicemente prova a toglierlo e verifica che iptables abbia comunque tutte le regole.

[steam-roller]

Non conosco firestarter e il modo in cui lavora, dovrebbe comunque generare uno script che imposta le regole in iptables, tutto li. Una volta eseguito lo script non vedo perché firestarter dovrebbe rimanere in esecuzione.
Semplicemente prova a toglierlo e verifica che iptables abbia comunque tutte le regole.

Senza "Firestarter" come posso controllare le connessioni attive e quelle bloccate? Mi spiego meglio. Il citato programma tramite una semplice interfaccia mi permette di gestire le varie regole (inbound & outbound) ed inoltre mi consente di controllare le connessioni bloccate (sezione eventi).

Immagino che tutto ciò può essere fatto tramite terminale.

Una volta che ho creato le regole posso fare a meno di firestarter... ma come gestisco e controllo gli eventi?

[ilsensine]

Puoi approfondire come sono gestiti gli "eventi" su Firestarter?

[steam-roller]

Puoi approfondire come sono gestiti gli "eventi" su Firestarter?

Eccomi... :)

L'interfaccia di "Firestarter" presenta 3 tab: Status, Events, Policy.
In "Status" controllo le connessioni attive; nella sezione "Events" verifico le connessioni bloccate (data/ora, porta, sorgente, protocollo, servizio). Nela sezione "Policy" posso editare le regole (inbound & outbound).

E' evidente che non conoscendo un tubo di "iptables", risulta semplice gestire il firewall di sistema in questo modo.

Ciao.

[ilsensine]

Mi sorge un dubbio, ma dovrei vedere che regole che usa per capirci di più.

Puoi eseguire questo (da root):
iptables -L -n -v > rules.txt
e allegare il file che viene creato?

[steam-roller]

Mi sorge un dubbio, ma dovrei vedere che regole che usa per capirci di più.

Puoi eseguire questo (da root):
iptables -L -n -v > rules.txt
e allegare il file che viene creato?

Ecco il file e grazie per la disponibilità!

[ilsensine]

Ultima cosa...arriva nella condizione in cui Firestarter consuma il 100% di cpu; puoi raccogliermi questo dato?

ls -l /proc/<pid>/fd > descriptors.txt

dove <pid> è il pid di Firestarter, come mostrato da top o htop.

[steam-roller]

Ultima cosa...arriva nella condizione in cui Firestarter consuma il 100% di cpu; puoi raccogliermi questo dato?

ls -l /proc/<pid>/fd > descriptors.txt

dove <pid> è il pid di Firestarter, come mostrato da top o htop.

Trovi il file in allegato (generato quando "firestarter" fa schizzare la cpu al 100%).

Ciao.

[ilsensine]

Ok credo di aver capito cosa fa, logga in continuazione /proc/net/tcp e /proc/net/ip_conntrack. amule genera molte connessioni, e questo fa balzare il carico di firestarter alle stelle.

Da quello che vedo è solo un sistema di log, il primo file che ti ho chiesto sembra escludere un processamento in userspace dei pacchetti. Dettagli più precisi potrei averli solo analizzando un corposo strace.

Quello che posso dirti è questo:
- l'occupazione di processore al 100% non dovrebbe penalizzare amule più di tanto, che essendo un processo essenzialmente i/o bound riceve un bonus dal kernel. Nel dubbio alza il nice di firestarter in modo da abbassarne la priorità (non ridurrà il consumo di processore, ma eviterà che succhi risorse a programmi più importanti)
- Riducendo il numero di connessioni accettate da amule dovresti poter mitigare il problema
- Puoi effettuare un log alternativo direttamente tramite iptables, eliminando così firestarter, anche se risulterà un pò meno comodo da leggere

[steam-roller]

Ok credo di aver capito cosa fa, logga in continuazione /proc/net/tcp e /proc/net/ip_conntrack. amule genera molte connessioni, e questo fa balzare il carico di firestarter alle stelle.

Da quello che vedo è solo un sistema di log, il primo file che ti ho chiesto sembra escludere un processamento in userspace dei pacchetti. Dettagli più precisi potrei averli solo analizzando un corposo strace.

Quello che posso dirti è questo:
- l'occupazione di processore al 100% non dovrebbe penalizzare amule più di tanto, che essendo un processo essenzialmente i/o bound riceve un bonus dal kernel. Nel dubbio alza il nice di firestarter in modo da abbassarne la priorità (non ridurrà il consumo di processore, ma eviterà che succhi risorse a programmi più importanti)
- Riducendo il numero di connessioni accettate da amule dovresti poter mitigare il problema
- Puoi effettuare un log alternativo direttamente tramite iptables, eliminando così firestarter, anche se risulterà un pò meno comodo da leggere

:)
Hai centrato il problema. Con "amule" attivo, la sezione eventi di "Firestarter" evidenzia molte connessioni bloccate; di conseguenza ciò comporta che il comando "firestarter --start-hidden" consumi troppa cpu.

Come posso mettere in pratica i tuoi consigli? Cosa intendi quando affermi di provare ad alzare il nice di "Firestarter"?
Intanto ho ridotto il numero di connessioni accettate da "amule" (il valore di "Connessioni massime" l'ho settato da 500 a 300).

Ciao.

[ilsensine]

:)
Hai centrato il problema. Con "amule" attivo, la sezione eventi di "Firestarter" evidenzia molte connessioni bloccate; di conseguenza ciò comporta che il comando "firestarter --start-hidden" consumi troppa cpu.

Come posso mettere in pratica i tuoi consigli?
Le connessioni bloccate vengono lette da firestarter nel log di sistema, che puoi esaminare con dmesg o con il file /var/log/messages o /var/log/syslog anche senza l'aiuto di firestarter.
Prova ad es:
dmesg |grep Inbound (o grep Input).
Per curiosità, hai un IP pubblico? Altrimento non vedo motivo per cui il log si debba riempire con connessioni bloccate...

Cosa intendi quando affermi di provare ad alzare il nice di "Firestarter"?
ad es. renice +10 `pidof firestarter` (v. man renice)

[steam-roller]

Le connessioni bloccate vengono lette da firestarter nel log di sistema, che puoi esaminare con dmesg o con il file /var/log/messages o /var/log/syslog anche senza l'aiuto di firestarter.
Prova ad es:
dmesg |grep Inbound (o grep Input).
Per curiosità, hai un IP pubblico? Altrimento non vedo motivo per cui il log si debba riempire con connessioni bloccate...


ad es. renice +10 `pidof firestarter` (v. man renice)

Sono connesso in rete tramite Alice ADSL (contratto flat) con IP pubblico (che cambia ad ogni connessione).

Ho provato il comando "dmesg" ed in effetti posso visualizzare i log (ma risulta un pò scomodo).

Aggiungo altri elementi alla discussione. Attualmente, con "amule attivo" (sia in download che upload), nella sezione eventi di "Firestarter" non vengono più riportate le connessioni bloccate; in poche parole c'è un problema nei logs di sistema.

[ilsensine]

...o in firestarter stesso.
Parti dal presupposto che iptables non sbaglia mai.

nb se hai un IP pubblico, lo hai chiesto tu di aprire le porte 25 e 110 in ingresso?

[steam-roller]

...o in firestarter stesso.
Parti dal presupposto che iptables non sbaglia mai.

nb se hai un IP pubblico, lo hai chiesto tu di aprire le porte 25 e 110 in ingresso?

Se "iptables" è infallibile allora c'è un problema in "Firestarter". Quando evidenzia le connessioni bloccate (molte se è in esecuzione "amule") manda la cpu al 100%; invece se (in modo inspiegabile) smette di mostrare i log il carico sulla cpu ritona a livelli accettabili.

Si ho settato in ingresso le seguenti regole:
smtp -> porta 25
pop3 -> porta 110
amule tcp -> porta 4662
amule udp1 -> porta 4665
amule udp2 -> porta 4672

Ho commesso qualche errore?

[ilsensine]

No non sapevo che avevi sulla macchina un mail server.

[ilsensine]

Per curiosità, quali sono i log delle connessioni bloccate che ti interessano particolarmente? Quali sono quelli che "esplodono" quando usi amule?

[steam-roller]

No non sapevo che avevi sulla macchina un mail server.

In realtà ho installato "mail notification" -> http://www.nongnu.org/mailnotify/
che effettua un controllo periodico sulle mie caselle di posta. Tale applicazione mi avvisa (mediante popup sul pannello) la presenza di nuove mail.
Ho quindi ritenuto opportuno consentire in ingresso i servizi smtp e pop3 (porta 25 e 110). A questo punto mi chiedo se ho ho ragionato in modo corretto!

[ilsensine]

Credo ci sia una piccola incorrettezza nel tuo firewall, ora che guardo meglio. Non so se hai raccolto le rules di iptables durante l'esecuzione di amule, ma il file che hai allegato mostra un massiccio drop (e conseguente log) delle connessioni in uscita. Questo perché, credo, autorizzi in uscita solo determinate porte, bloccando di fatto il collegamento verso tutti gli utenti che usano porte di amule diverse da quelle preimpostate. In più, logghi questi eventi, caricando firestarter.

[ilsensine]

In realtà ho installato "mail notification" -> http://www.nongnu.org/mailnotify/
che effettua un controllo periodico sulle mie caselle di posta. Tale applicazione mi avvisa (mediante popup sul pannello) la presenza di nuove mail.
Ho quindi ritenuto opportuno consentire in ingresso i servizi smtp e pop3 (porta 25 e 110). A questo punto mi chiedo se ho ho ragionato in modo corretto!
Non credo, quelle porte vanno aperte se è il tuo computer ad avere il server di posta! mailnotify credo che si limiti a controllare se sui tuoi account ci sono nuovi messaggi, quindi passa solo per la 110 in uscita (come un qualsiasi client mail).

[steam-roller]

Per curiosità, quali sono i log delle connessioni bloccate che ti interessano particolarmente? Quali sono quelli che "esplodono" quando usi amule?

Nessun log in particolare (ho settato in modo da bloccare tutto in outbound tranne quello che ho specificato nella white list); in realtà ho notato due comportamenti distinti da parte di "Firestarter":
1) "Firestarter" smette di segnalare i log in tempo reale e posso visualizzarli tutti cliccando su "reload" che appunto ricarica tutte le connessioni bloccate dall'avvio del PC sino al momento in cui clicco sul pulsante "reload".
2) "Firestarter" segnala continuamente le connessioni bloccate (molte se "amule" è attivo); in tal caso la cpu va al 100%.

[ilsensine]

2) "Firestarter" segnala continuamente le connessioni bloccate (molte se "amule" è attivo); in tal caso la cpu va al 100%.
Da quello che leggo su rules.txt, non sono connessioni in ingresso ma in uscita (per quanto detto sopra).

[steam-roller]

Riporto i settaggi che ho impostato in "Firestarter" (visibili anche negli allegati):

Inbound traffic policy (vedi post #21)

Outbound traffic policy (ho selezionato restrictive by default, white list traffic):

ftp -> porta 20-21
smtp -> porta 25
http -> porta 80
pop3 -> porta 110
https -> porta 443
amule server -> porta 4242 (Donkey server)
amule tcp -> porta 4662
amule udp1 -> porta 4665
amule udp2 -> porta 4672

Ho abilitato anche il filtro ICMP.

[ilsensine]

Nel tuo caso non credo che dovresti usare limiti restrittivi per le connessioni in uscita.
Esegui questo comando e fammi sapere se cambia qualcosa:

iptables -I OUTBOUND -j ACCEPT

[steam-roller]

Nel tuo caso non credo che dovresti usare limiti restrittivi per le connessioni in uscita.
Esegui questo comando e fammi sapere se cambia qualcosa:

iptables -I OUTBOUND -j ACCEPT

Ricapitolando... in ingresso mi consigli di tenere solo le regole relative ad "amule" ed eliminare quelle che fanno riferimento ai servizi smtp e pop3; in uscita, invece, digitando il comando che mi hai indicato (iptables -I OUTBOUND -j ACCEPT) viene consentito tutto il traffico in uscita. In tal caso, le regole che ho impostato vengono ignorate?

[ilsensine]

Sì. Intanto fallo per prova, per vedere se ci abbiamo visto giusto.

[steam-roller]

Sì. Intanto fallo per prova, per vedere se ci abbiamo visto giusto.

Fatto. In ingresso sono presenti solo le 3 regole relative ad "amule".
In uscita ho digitato, tramite terminale -> sudo iptables -I OUTBOUND -j ACCEPT.
Come verifico i nuovi settaggi? In "Firestarter" noto che in outbound sono presenti le vecchie regole. E' necessario un riavvio?

[steam-roller]

Ho provato ad inviarmi una mail ed è stata prontamente segnalata da "mail notification". Quindi, i nuovi settaggi in ingresso vanno bene.

[ilsensine]

Come verifico i nuovi settaggi? In "Firestarter" noto che in outbound sono presenti le vecchie regole. E' necessario un riavvio?
Non devi riavviare, altrimenti ripristina le regole precedenti. Non hai eliminato le regole, le hai semplicemente scavalcate. E' solo per fare il test, può darsi che il grosso del tempo viene perso da firestarter in altri posti (ad es. nel riportare le numerose connessioni aperte).

[steam-roller]

Non devi riavviare, altrimenti ripristina le regole precedenti. Non hai eliminato le regole, le hai semplicemente scavalcate. E' solo per fare il test, può darsi che il grosso del tempo viene perso da firestarter in altri posti (ad es. nel riportare le numerose connessioni aperte).

OK.
Attualmente "amule" è attivo e noto (tramite Firestarter) che le connessioni bloccate sono tutte riferite al protocollo ICMP (indirizzo porta variabile). Le connessioni attive fanno riferimento non solo alle porte da me impostate in "amule" ma anche ad altre (ad es. 6462).
Il carico complessivo sulla cpu è mediamente pari al 40%.

[ilsensine]

OK.
Attualmente "amule" è attivo e noto (tramite Firestarter) che le connessioni bloccate sono tutte riferite al protocollo ICMP (indirizzo porta variabile)
L'icmp non ha la porta!
Comunque è atteso, il tuo fw blocca gli icmp in ingresso.

Le connessioni attive fanno riferimento non solo alle porte da me impostate in "amule" ma anche ad altre (ad es. 6462).
Come ti dicevo, ci sono parecchi utenti che cambiano le porte di default di emule, nella speranza di scappare a qualche packet sniffer presente sui nodi di rete
Il carico complessivo sulla cpu è mediamente pari al 40%.
Ok lascialo andare per un pò per vedere se effettivamente abbiamo migliorato la situazione.

[steam-roller]

La % di cpu impiegata varia continuamente; posso affermare che mediamente, tale %, è compresa nel range 35-45.

I programmi attivi nel momento della valutazione sono i seguenti:
firestarter
mail notification
compiz fusion
htop
firefox
amule
(sono comunque presenti altri comandi in esecuzione)

Il test è superato?

[ilsensine]

Diciamo che ci abbiamo messo una pezza, anche se mezza cpu solo per i log mi sembra oggettivamente ancora troppa (dipende quanto di quel 45% è rubato da firestarter).

[steam-roller]

Diciamo che ci abbiamo messo una pezza, anche se mezza cpu solo per i log mi sembra oggettivamente ancora troppa (dipende quanto di quel 45% è rubato da firestarter).

Il valore che ti ho indicato è puramente indicativo; come detto la % di cpu varia. Comunque, attualmente "Firestarter" impegna la cpu per il 2-3% circa.
Il rimanente carico è da attribuire a "Compiz Fusion", "amule", "firefox" etc.

In definitiva la cpu attiva è pari al 35% circa.

[ilsensine]

Ok il 2-3% è accettabile, direi che abbiamo trovato qual'era il problema.

[steam-roller]

Adesso come imposto in modo definitivo il firewall?

[ilsensine]

Intanto prova a configurare Firestarter in modo da non avere regole restrittive in uscita, può darsi che sia sufficiente.

[steam-roller]

Ho risolto i problemi di configurazione del firewall; posso utilizzare 2 possibili configurazioni relative al traffico in uscita:

1. (configurazione che utilizzo in assenza di amule)

Outbound traffic policy (restrictive by default, white list traffic)
allow service -> FTP, SMTP, HTTP, POP3, HTTPS

2. (configurazione che utilizzo in presenza di amule)

Outbound traffic policy (permissive by default, blacklist traffic)

La differenza tra i due settaggi è la seguente:
la conf. 1 blocca tutto il traffico in uscita ad eccezione delle regole inserite nella "white list"; la conf. 2, invece, comporta che qualsiasi applicazione può liberamente comunicare con l'esterno (eccetto quelle che sono inserite eventualmente nella "lista nera").

Posso anche semplificare il tutto considerando solo la configurazione 2.

Ringrazio <ilsensine> che ha dedicato il suo tempo ai miei problemi.
:)