Domanda da ignorante, hald-runner (se è questo il processo) può essere il demone di HAL (Hardware Abstraction Layer)?
[quote=Cupo]Ti restituisce qualcosa
$ rpm -q -f /usr/bin/hald-runner?[/quote]
@ andreamal
Era proprio quello che ero curioso di appurare 
Anche perché non vorrei dire una fesseria ma mi sembra che HAL sia deprecato da diverso tempo su Fedora
Se è lui https://fedoraproject.org/wiki/Features/HalRemoval c’è una paginetta (relativa a F16 per cui l’idea che sia deprecato non è campata in aria) dal titolo “Features/HalRemoval”.
rpm -q -f /usr/bin/hald-runner
il file /usr/bin/hald-runner non è posseduto da alcun pacchettorpm -q gcc make
gcc-4.8.3-7.fc20.x86_64
make-3.82-19.fc20.x86_64ss -l -n - t
Error: an inet prefix is expected rather than "-".
Cannot parse dst/src address.tac /var/log/secureposto solo le ultime righe
Feb 22 03:07:17 bina sshd[14270]: Received disconnect from 183.3.202.106: 11: [preauth]
Feb 22 03:07:17 bina sshd[14270]: Failed password for root from 183.3.202.106 port 17902 ssh2
Feb 22 03:07:14 bina sshd[14270]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Feb 22 03:07:14 bina sshd[14270]: Failed password for root from 183.3.202.106 port 17902 ssh2
Feb 22 03:07:12 bina sshd[14270]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Feb 22 03:07:11 bina sshd[14270]: Failed password for root from 183.3.202.106 port 17902 ssh2
Feb 22 03:07:09 bina sshd[14270]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Feb 22 03:07:09 bina sshd[14270]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.3.202.106 user=root
Feb 22 03:07:06 bina sshd[14208]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.3.202.106 user=root
Feb 22 03:07:06 bina sshd[14208]: Received disconnect from 183.3.202.106: 11: [preauth]
Feb 22 03:07:06 bina sshd[14208]: Failed password for root from 183.3.202.106 port 25251 ssh2
Feb 22 03:07:04 bina sshd[14208]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Feb 22 03:07:03 bina sshd[14208]: Failed password for root from 183.3.202.106 port 25251 ssh2cat /etc/password
cat: /etc/password: File o directory non esistentecat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
avahi-autoipd:x:170:170:Avahi IPv4LL Stack:/var/lib/avahi-autoipd:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
polkitd:x:999:999:User for polkitd:/:/sbin/nologin
abrt:x:173:173::/etc/abrt:/sbin/nologin
usbmuxd:x:113:113:usbmuxd user:/:/sbin/nologin
colord:x:998:998:User for colord:/var/lib/colord:/sbin/nologin
geoclue:x:997:997:User for geoclue:/var/lib/geoclue:/sbin/nologin
rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
qemu:x:107:107:qemu user:/:/sbin/nologin
rtkit:x:172:172:RealtimeKit:/proc:/sbin/nologin
radvd:x:75:75:radvd user:/:/sbin/nologin
tss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:/dev/null:/sbin/nologin
unbound:x:996:995:Unbound DNS resolver:/etc/unbound:/sbin/nologin
openvpn:x:995:994:OpenVPN:/etc/openvpn:/sbin/nologin
saslauth:x:994:76:"Saslauthd user":/run/saslauthd:/sbin/nologin
avahi:x:70:70:Avahi mDNS/DNS-SD Stack:/var/run/avahi-daemon:/sbin/nologin
pulse:x:993:992:PulseAudio System Daemon:/var/run/pulse:/sbin/nologin
gdm:x:42:42::/var/lib/gdm:/sbin/nologin
gnome-initial-setup:x:992:990::/run/gnome-initial-setup/:/sbin/nologin
nm-openconnect:x:991:989:NetworkManager user for OpenConnect:/:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
chrony:x:990:988::/var/lib/chrony:/sbin/nologin
tcpdump:x:72:72::/:/sbin/nologin
s.tardioli:x:1000:1000:s.tardioli:/home/s.tardioli:/bin/bash
alias:x:1001:1001::/var/qmail/alias:/bin/bash
qmaild:x:1002:1001::/var/qmail:/bin/bash
qmaill:x:1003:1001::/var/qmail:/bin/bash
qmailp:x:1004:1001::/var/qmail:/bin/bash
qmailq:x:1005:1002::/var/qmail:/bin/bash
qmailr:x:1006:1002::/var/qmail:/bin/bash
qmails:x:1007:1002::/var/qmail:/bin/bash
m.siciliani:x:1008:1008::/home/m.siciliani:/bin/bash
cris:x:1009:1009::/home/cris:/bin/bash
apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin
snort:x:1010:1010:Snort:/var/log/snort:/bin/false
mysql:x:27:27:MariaDB Server:/var/lib/mysql:/sbin/nologinsestatus
SELinux status: disabledss -l -n - t
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 1 141.250.121.168:8837 *:*
LISTEN 0 50 *:139 *:*
LISTEN 0 20 *:110 *:*
LISTEN 0 128 *:111 *:*
LISTEN 0 1 141.250.121.168:44368 *:*
LISTEN 0 32 *:21 *:*
LISTEN 0 128 *:22 *:*
LISTEN 0 128 127.0.0.1:631 *:*
LISTEN 0 1 141.250.121.168:32376 *:*
LISTEN 0 1 141.250.121.168:47704 *:*
LISTEN 0 20 *:25 *:*
LISTEN 0 50 *:445 *:*
LISTEN 0 128 *:35456 *:*
LISTEN 0 50 :::139 :::*
LISTEN 0 128 :::111 :::*
LISTEN 0 128 :::80 :::*
LISTEN 0 128 :::57904 :::*
LISTEN 0 128 :::22 :::*
LISTEN 0 128 ::1:631 :::*
LISTEN 0 50 :::445 :::* Ok, se il problema è che la macchina è compromessa, due sono le cose:
- prima la puliamo per vedere se si riesce (scopo puramente didattico) e poi facciamo l’upgrade a fedora 23;
- ce ne freghiamo della pulizia e facciamo direttamente l’upgrade a fedora 23
ho dato questo comando
pkill halded il computer ha smesso di trasmettere.
Dove può essere la partenza del demone hald?
Gli output che hai gentilmente postato non sono confortanti, almeno dal mio punto di vista.
Ti espongo la mia teoria e cerco con ordine di suffragarla sulla base degli output che hai fornito.
Io temo che quella macchina Fedora che funge da gateway per quella lan sia compromessa e vada al più presto disconnessa dalla rete e ripreparata in toto.
La mia teoria è che sia stata vittima di un qualche attacco brute-force dall’esterno, sia stata carpita la password dell’utente root, e forse trasferito un qualche sorgente compilato in quel binario sospetto che giustamente hai rilevato tu.
Cosa mi porta a penssare questo?
-
Quel binario non proviene da nessun pacchetto ufficiale o di terze parti, quindi è stato quasi sicuramente compilato o trasferito come binario statico in /usr/bin
-
Sul tuo sistema sono installati gli strumenti minimi indispensabili per compilare del codice (gcc & make)
-
All’interno del file /var/log/secure sono rintracciabili entry Failed password for root from 183.3.202.106 port 17902 ssh2
Poco rassicurante leggere tentativi di connessione ssh da macchine remote
Azzardo anche l’ipotesi che il demone sshd di quel gateway sia configuarato per consentire direttamente l’accesso come utente root, una verifica di
# cat /etc/ssh/sshd_config | grep Root
PermitRootLogin yes
potrebbe avvalorare la mia idea
-
SELinux è/è stato disabilitato. Risulta preclusa ogni minima possibilità di confinamento dei processi che avrebbe potuto mitigare la criticità
-
L’output di ss evidenzia in ascolto diverse porte “alte” (es. 32376; 47704; 44368) oltre a diverse altre riconducibili al protocollo NetBIOS tipico delle reti Windows.
Su questa macchina sono attivi anche i demoni di Samba, Ftp, mail server?
In conclusione la superficie di attacco è piuttosto estesa, la mia opinione assolutamente personale è che quella macchina non si possa condiderare affidabile e vada quantomeno isolata.
Poi sarebbe sicuramente interessante approfondire ulteriormente la natura di quel binario che hai rilevato e capire da dove arriva e cosa fa
[quote=sergio59]Ok, se il problema è che la macchina è compromessa, due sono le cose:
- prima la puliamo per vedere se si riesce (scopo puramente didattico) e poi facciamo l’upgrade a fedora 23;
- ce ne freghiamo della pulizia e facciamo direttamente l’upgrade a fedora 23[/quote]
Non me ne volere, ma io proprio non upgraderei una macchina in quello stato partendo dalla medesima configurazione.
La preparerei da zero, adottando ovviamente nuove password robuste, non attivando servizi non necessari, mettendo in sicurezza quelli che invece servono ma soprattutto, configurando le catene di Netfilter con default target (comportamento predefinito) impostato a DROP e solo in seconda battuta definendo delle regole puntuali in ACCEPT.
Questo per tutte le catene della tabella filter (INPUT; OUTPUT; FORWARD).
E’ davvero pericoloso configurare un gateway che instradi completamente qualsiasi tipo di traffico da Internet ad una rete locale e viceversa, credimi, ne ho viste di tutti i colori nel corso di vite precedenti… 
Ok, grazie per i consigli.
Ora ripreparo la macchina con fedora 23.
No, non è permesso SSH con root.
Grazie a tutti
Metto risolto.
Ok, valuta la possibilità di adottare la release Server, dovrebbe offrire un set di pacchetti e servizi più “minimale” che ti permette di disporre comunque di una macchina completamente operativa.
Anche le future operazioni di upgrade di release per mezzo di *dnf system-upgrade * dovrebbero risultare più rapide e lineari.
Se poi hai bisogno di una mano con la configurazione di Netfilter chiedi pure
In bocca al lupo!