confermo in toto...
io ho raspbian wheezy (come da guida di walter)
nel log ho una marea di accessi
ma nessun Accepted password che non è l'indirizzo della mia rete

la cosa impressionante è che il giorno 25 ci sono 20940 righe (dalle 6:30 alle 23:47)
il giorno 26 solamente 2000
gli indirizzi ip da cui partono sono 4-5 e provengono dalla cina e georgia...

la password di accesso è abbastanza solita (maiuscola, minuscola, e numeri) ora la cambio inserendo almeno un campo speciale.

ciao

Ma come fanno ad accedere?
Avete aperta la porta 22?

Per ridurre gli attacchi dall'esterno è meglio cambiare le porte di default a cui rispondono ssh e apache (io l'ho fatto direttamente da router), poi per la massima sicurezza impostare l'autenticazione ssh solo tramite chiave, in genere gli attaccanti quando vedono che l'accesso tramite password è disabilitato desistono. Comunque già cambiare le porte aiuta molto, in due anni il mio raspberry non è mai stato attaccato.

@thx
Sì, ho accesso tramite ssh dall'esterno per poter intervenire quando sono in ufficio

Ciao a tutti , confermo ,anc'io sono stato vittima di attacchi informatici rilevati dal mio gestore della rete che mi scrive :
"da quel che possiamo vedere c'è qualcosa di installato abusivamente da terzi nel vostro sistema. Non serve chiudere adesso le porte: chi è entrato ha già preso il pieno controllo del sistema e apre, chiude e lancia da remoto quello che gli pare.
Viene fatto girare da remoto uno script sofisticato installato nel vostro sistema che causa un attacco D.o.S. (invio di pochi pacchetti udp opportumente modificati in modo tale da mandare in tilt i computer remoti fino a farli colassare). E' un attacco molto grave. Per questo motivo deve risolverlo velocemente bonficando o spegnendo il computer che lo genera."
Chiaramente se la porta 22 rimane aperta come lo era la mia , l'attacco riesce quasi sicuramente.
Rimosso la scheda istallata un'altra che era già fatta da tempo e riavviato.
Attendo dal gestore eventuali sviluppi.

molto interessante sapere di essere vulnerabile così facilmente ma volevo chiedere a voi esperti:
Oct 26 22:09:01 raspberrypi CRON[14847]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 26 22:09:01 raspberrypi CRON[14848]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 26 22:09:01 raspberrypi CRON[14846]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 26 22:09:01 raspberrypi CRON[14844]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 26 22:09:01 raspberrypi CRON[14845]: pam_unix(cron:session): session opened for user root by (uid=0)

questo CRON non farebbe pensare a qualcosa che è in crontab? addirittura a me esegue 5 ( cinque) registrazioni al secondo ovvero oggi 10360 registrazioni
che posso fare per evitare tutto ciò e allungare così la vita della mia micro SD ?
mi date qualche consiglio ?

forse ho capito dove sta il problema, raspbian jessie non utilizza più la cartella /etc/systemd/system per far partire 123solar.service
mentre stavo aggiornando da wheezy a jessie mi è comparso questo messaggio:
in questa cartella si installa il service di metern, ed in questa: /etc/systemd/system/default.target.wants il service di 123solar
se cercava di eliminarle vuol dire che non le usa più, di conseguenza senza service non parte il boot di 123solar e metern.

Io ho risolto con le modifiche in rosso al file /etc/pam.d/common-session-noninteractive

cat /etc/pam.d/common-session-noninteractive

Poi riavvia cron con service cron restart o con /etc/init.d/cron restart.

Fammi sapere se risolve,
/drk.

Quindi sono log inutili?

idem per me.....solo che io la uso la porta 22 poichè accedo da telefono per prelevare/consultare documenti
io per mio scrupolo peronale avevo cambiato la password a pi (e mi sa che ho fatto bene :-) ed infatti non ho notato nessun accepter password che non sia un ip mio....
però in effetti le connessione che provano sono moltissime e tutte con ip cinesi...
come si fa a cambiare la porta ssh del rasp e metterla su una diversa dalla 22 ?
grazie

Dipende.

Nessun log di sicurezza è inutile, ma queste entry derivano, con un sistema pulito, da lanci di task di crontab (es. storicizzazione logs, manutenzione automatica di alcuni servizi, ecc...). Se i file crontab sono "sicuri" e l'host è considerato ragionevolmente al sicuro, allora possiamo anche eliminare queste entry dal log di accesso. Eliminare entry ridondanti peraltro facilita la ricerca dei veri problemi in mezzo a troppe righe di log che sono solo rumore di fondo.

In generale, se il sistema può essere soggetto ad intrusioni (ad es. se è collegato ad Internet o è su una rete che ha un WiFi, se la password è di default o banale, ecc...) meglio stare all'erta su tutto. E' noto che nulla è mai sicuro al 100%, ma se l'obiettivo è limitare il log ridondante di operazioni schedulate, ad esempio per risparmiare vita della SD, c'è una soluzione.
Ad ognuno di noi spetta stabilire, per il nostro fidato raspi, il limite fra paranoia e ragionevole tranquillità (che è sempre rischio calcolato) nelle sue configurazioni.

Enjoy,
/drk

a me da ancora questo, cosa ho sbagliato
Oct 28 17:51:01 raspberrypi CRON[7743]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 28 17:51:01 raspberrypi CRON[7744]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 28 17:51:01 raspberrypi CRON[7746]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 28 17:51:01 raspberrypi CRON[7745]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 28 17:51:01 raspberrypi CRON[7742]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 28 17:51:01 raspberrypi CRON[7745]: pam_unix(cron:session): session closed for user root
Oct 28 17:51:01 raspberrypi CRON[7743]: pam_unix(cron:session): session closed for user root
Oct 28 17:51:01 raspberrypi CRON[7746]: pam_unix(cron:session): session closed for user root
Oct 28 17:51:01 raspberrypi CRON[7744]: pam_unix(cron:session): session closed for user root
Oct 28 17:51:01 raspberrypi CRON[7742]: pam_unix(cron:session): session closed for user root
Oct 28 17:52:01 raspberrypi CRON[8719]: pam_unix(cron:session): session opened for user root by (uid=0)

e questo è il file modificato
# /etc/pam.d/common-session-noninteractive - session-related modules
# common to all non-interactive services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of all non-interactive sessions.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.


# here are the per-package modules (the "Primary" block)
session [default=1] pam_permit.so
# here's the fallback if no module succeeds
session requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required pam_permit.so
# suppress auth.log entries
session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid
session [success=1 default=ignore] pam_succeed_if.so service in sudo quiet uid = 0


# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
# end of pam-auth-update config

scusa Drake

forse dico una stxxxxta..

con il ramlog abbiamo spostato un pò di log sulla memoria volatile, possiamo spostarci anche questi di log???

grazie

Se avete usato ramlog avete spostato tutta la cartella log, quindi anche questo file.

Per sicurezza, prova a riavviare.

Inviato dal mio Nexus 5 utilizzando Tapatalk

fatto il reboot ma non cambia nulla

Cosa contiene il tuo file: /etc/pam.d/cron ?

eccolo
# The PAM configuration file for the cron daemon


@include common-auth


# Read environment variables from pam_env's default files, /etc/environment
# and /etc/security/pam_env.conf.
session required pam_env.so


# In addition, read system locale information
session required pam_env.so envfile=/etc/default/locale


@include common-account
@include common-session-noninteractive


# Sets up user limits, please define limits for cron tasks
# through /etc/security/limits.conf
session required pam_limits.so

Finalmente ho risolto il problema dell'avvio di 123solar al boot.
Il problema è dovuto all'avvio anticipato di 123solar.service rispetto a "systemd" e quindi va in errore.

Per ovviare al problema bisogna modificare il 123solar.service aggiungendo un ritardo all'esecuzione di boot123s.php con la riga
ExecStart=/bin/sleep 10

Il file 123solar.service diventa questo:
Vi faccio notare, poichè ci sono incappato anch'io, che in altre versione di Raspbian diversa dalla Jessie il comando sleep può essere in qualche altra cartella come ad esempio /usr/bin/sleep eventualmente fate un ricerca con

Senza l'aggiunta del ritardo sia 123solar.service che rc.local vengono caricati prima di tutti i servizi di systemd
Per controllare la sequenza cronologica di avvio usate il comando :

Quel ritardo nella prima versione di 123solar.service c'era , mi ricordo che lo duplicai , perche' avevo e ho sempre bisogno di far partire un mio script per aggiornare la data dove non ho rete.... vedo che pero' adesso l'autore se ne e' 'dimenticato'.....

Ciao ragazzi, per chi carica dati su PVoutput, avete anche voi problemi con il sito?, ovvero non è raggiungibile?

Si Walter, purtroppo è così da un po' di giorni anche per me

Fino ad ieri era tutto a posto, oggi si è bloccato alle 11,15 poi una registrazione alle 22,10 e poi morto di nuovo

Certo che se si blocca PVOutput sarà un vero disastro a meno che jeanmarc non provveda ad implementare le registrazioni su MeterN,anche a me ieri si è bloccato alle 11,15 ma ha ripreso alle 18,30 mi sembra ( ora non posso controllare perché è fermo di nuovo)

Dolam non ti sembra strano che metern si sia bloccato ieri alle 11,15? ora della mia ultima registrazione su pvoutput?
Io ieri sono impazzito, 123solar non leggeva gli inverter, li leggeva per qualche minuto e poi si fermava lo script aurora,
se lanciavo il comando manualmente da terminale leggeva perfettamente,
ho rimesso un altra sd card con un vecchio backup, ho cambiato il convertitore USB, sempre lo stesso problema.
questa mattina alla ripartenza di nuovo lo stesso problema con 123solar, alle 7,45 sembra essersi ripreso, non si ferma più,
ho controllato su pvoutput ed è proprio a quell'ora che risultano le prime registrazioni,
ora mi viene il dubbio che 123solar si ferma perchè non trova il server pvoutput e qualche funzione lo mette in un ciclo infinito di tentativi di invio e si dimentica che deve far girare lo script aurora, se risuccede provo a disabilitare l'invio su pvoutput.
A qualcun altro è successa la stessa cosa?

Ho registrato anch'io il blocco di pvoutput ieri alle 11.15, ma solo per quanto riguarda la produzione. I consumi sono stati correttamente registrati tutta la giornata di ieri. Io però non ho rilevato nessun problema con 123solar (v. 1.6.5.8) ha correttamente registrato i dati anche quando pvoutput non registrava.

Nel mio caso, ieri è stata la giornata peggiore per le registrazioni dati sul sito pvoutput:
11,30, blocco;
21,15 ripresa;
22,25 nuovo blocco, oggi blocco fino alle ore 10,40, mentre 123solar e metern, hanno registrato i dati correttamente, le versioni installate (1.6.7.3 per 123solar - 0,78 per metern).

ho riscontrato anch'io il problema di ieri, stamattina sembra sia ripartito ma dalla stessa ora in cui si è interrotta la comunicazione (più o meno le 11,15-11,20)
Io ho metern 0.7.8 e 123solar 1.6.7.3, che hanno registrato i dati normalmante in locale, ho il log attivo e vi allego il file di oggi così chi ne capisce più di me può vedere se c'è qualcosa che non va.

Flane anche io ho la ver. 1.6.5.8 con due inverter, il problema più che altro me lo dava sul secondo inverter, staccando il secondo aurora ripartiva, infatti in primis pensavo ad un guasto inverter, poi però lanciando aurora manualmente leggeva, inoltre se era l'inverter il convertitore doveva continuare a lampeggiare, invece i led rimanevano spenti, 123solar rimaneva in attesa non so di cosa e non faceva girare aurora. Ora sta funzionando tutto regolarmente e non ho toccato niente, l'unica cosa che pvoutput ha ricominciato a funzionare. Appena ho un po di tempo do uno sguardo al codice per capire il funzionamento della parte pvoutput con multinverter.

confermo blocco
123solar ha registrato regolarmente


ora sembra funzionare tutto...

chissà qualche aggiornamento!!!!
ciao

Nel log 123solar.err ho questo:
28967 è l'ID del secondo inverter su pvoutput.
il primo inverter ha ID 28965 e non ho trovato niente nel log che faccia riferimento a questo.