Support als admin toegang verlenen

[slingshot]

Omdat ik een probleem heb met mijn NAS heb ik contact gehad met synology en zij stellen voor om mijn NAS over te nemen en te kijken.
Wat vinden jullie hiervan. Ik vind het wel een beetje scary.

Dear customer,

Do you mind to let me check your system? If so, please follow the instructions below and provide the information requested, so that we can check your system from here.

Remote Access Instructions
==============================================================================
For DSM 5.0 and above:
1. Please provide the Support Identification Key in Support Center to us and enable remote access. Please remember to click "Apply" button.
2. Enable SSH service in Control Panel > Terminal & SNMP
3. Tell us your temporary password for the admin account on your Synology NAS.
Note 1: Other user accounts with admin privilege won't work.
Note 2: The temporary password should not be too simple and must contain numbers and letters.
Please also enable Auto Block in Control Panel > Security to enhance system security.
==============================================================================

We will not disclose/access any of your private data. Please offer us the remote access for troubleshooting purposes. And please also close the SSH once the problem is resolved. Thank you.

Best regards,

[Birdy]

Is heel normaal hoor, heb ik ook een aantal keren gehad.
Gewoon de instructies opvolgen en het komt goed.

[Briolet]

Als je een PC ter reparatie wegbrengt, kan de monteur ook bij alle data. Hoewel mijn laatste PC die ik wegbracht nog floppies gebruikte en geen HD had.

Het ligt er helemaal aan wat voor data op je PC staat. Als jij er b.v. data op hebt staan die onder melding datalekken valt, zul je ook geen externe bedrijven toegang tot je nas mogen geven. Er zullen daar wel weer speciale regels voor zijn.

Voor een gemiddelde gebruiker heeft Synology er helemaal geen belang bij om data van je nas te stelen. Hun goede naam is dan meer waard dan je data.

[JosF]

Onder andere daarom zijn veel van mijn shared folders encrypted. En als Synology iets moet fixen, dan unmount ik die zo lang het onderzoek loopt. Ook al geloof ik niet dat Synology in die data gaat zitten neuzen: better safe than sorry.

[Babylonia]

Zelf heb ik niet zodanig geheime informatie op mijn drives staan, dat een "Taiwanees" daar iets aan zou hebben, laat staan de Nederlandse taal begrijpt.

Bij eerdere support waar ik Synology wel eens toestemming voor heb gegeven om in het systeem te kijken, blijkt dat via de log-files die inlog minimaal is, en beperkt tot de werkzaamheden die met het opheffen van het probleem te maken hebben.
(O.a. inloggen via een Telnet sessie op root-niveau via SSL op poort 22 om in het onderliggende systeem aanpassingen aan te brengen).

[JosF]

Dat maakt me toch wel nieuwsgierig, Babylonia. Als er via Telnet wordt ingelogd, wordt dan iedere vervolgactie ook ergens gelogd? Dus bijv. het via die weg uploaden van een willekeurig bestand? (afgezien van het feit dat daarna die log nog zou kunnen worden aangepast)

[Babylonia]

Via Telnet zit nog vers in het geheugen (maand geleden).
Tenminste ik ga ervan uit (maar zou me kunnen vergissen), dat een "terminal-sessie" een telnet sessie is ??

Was overigens voor support van mijn Synology router, niet van mijn NAS. Zie bericht / draadje < HIER > en bekijk de afbeelding.
Dit naar aanleiding van een bug die ik had gevonden en besproken, en Support dat eerst op mijn eigen router heeft aangepast, enkele weken later voor iedereen beschikbaar met een nieuwe firmware update voor de router (SRM).

Bug   en   FIX  (en lees onderaan de toevoeging m.b.t. de eerdere bug).

[Pippin]

Zo`n log heeft men niets aan indien men weten wil wat er gedaan is.

Code: [Selecteer]

/var/log/bash_history.logof

Code: [Selecteer]

/var/log/ash_history.logLaat zien wat er getypt is maar ook dat kan gewist worden voordat men uitlogt.....
Kwestie van vertrouwen maar gezonde achterdocht is altijd goed....

[Briolet]

Hoeft niet als je alles naar een syslog wegschrijft op een andere nas: How To Log Your Bash History With Syslog

Ook dit kunnen ze onklaar maken, maar het in dan in elk geval gelogd dat dit gebeurd is.

Edit: Mijn mac zit op Bash 3.2, maar ik zie nu dat de nas Bash 4.3 gebruikt. Daar moet de syslog functie al standaard in zitten volgens de link.

Maar… ik verwar syslog met syslog server. Dit blijft dus nog steeds lokaal opgeslagen. 

[Briolet]

…Laat zien wat er getypt is maar ook dat kan gewist worden voordat men uitlogt.....

Toch intrigerend. Na wat zoeken vond ik allerlei methodes om het log te wissen, maar ze werken niet steeds met elke bash/ash versie.

Het commando "HISTFILE=" werkt perfect op de mac om de current sessie te wissen, voordat hij naar het log geschreven wordt bij het uitlogen. Maar de mac gebruikt een oudere versie van Bash. Met de nas werkt die methode niet meer.

Wat wel mooi werkt op de nas is het commando "HISTCONTROL=ignorespace". Vervolgens wordt elk commando dat je met een spatie begint, niet meer gelogd. Goed om te onthouden voor die situaties waar je een plaintext wachtwoord intypt omdat ik me nooit gerealiseerd had dat alles leesbaar in het log achterblijft. Default de laatste 500 regels, als ik het zo lees.

Ook verwarrend voor mij als leek, is dat ik in bash blijk te zitten als ik inlog, maar als ik via sudo -i naar root overstap, ik plots in ash lijk te zitten, gezien de error melding bij foute input. Echter, alles logt sinds maart 2016 wel naar het bash_history.log. Daarvoor naar het ash_history.log.

[JosF]

Een interessant staartje heeft deze post! Toevallig heb ik nu ook support van Synology. Daarvoor moesten ze toegang hebben tot mijn beide NASsen. Vandaar dat de suggestie om te loggen naar 'n andere NAS wellicht niet zou helpen om alle acties te kunnen volgen.
 
Vanmorgen ontving ik: "we need your permission to replace the binary code to fix the issue." Wat betekent dat?

[Birdy]

https://en.m.wikipedia.org/wiki/Binary_code

[JosF]

Ik heb 't Synology gevraagd en het blijkt om (een deel van) DSM te gaan. Ze hebben op mijn machine een aanpassing gedaan die in de eerstvolgende versie van DSM6.2 ingebouwd zal zijn. Er werd nog bij gezegd dat het in de eerstvolgende versie van DSM6.1 niet geïmplementeerd zal worden. Mijn (zeer specifieke) probleem is nu opgelost.

[Birdy]

Mijn (zeer specifieke) probleem is nu opgelost.

Ben een beetje nieuwsgierig, wat was het (zeer specifieke) probleem ?

[JosF]

Mijn NAS backupt iedere dag naar m'n andere NAS (met name via folder sync.) Enkele (niet alle) van de backup tasks waarbij een encrypted shared folder betrokken was kreeg ik in de mail: "failed". Toch stonden de nieuwe bestanden wel gewoon op de backup-NAS. Backup tasks met niet-encrypted shared folders gaven geen foutboodschap. Het is gekomen nadat ik van DSM6.1 naar DSM6.2 DSM6.0.2 naar 6.1.1 was gemigreerd. Het "specifieke" hieraan is dat ik het vermoeden heb dat encrypted shared folders en het backuppen daarvan naar een andere NAS door weinig forumleden wordt toegepast. Iets anders specifieks: De backup NAS draait nog op DSM4.2, maar ik weet niet of dat er iets mee te maken had.