Onderwerp: Configuratie check script in cron

Ik ben niet goed in scripting, maar zou het volgende willen doen.
Een scriptje maken, wat:
a.) controleert of de SSH daemon draait, zo niet, dan starten.

Zoiets?

Code:

#!/bin/bash
SERVICE=sshd
result=$(ps ax|grep -v grep|grep $SERVICE)
echo ${#result}
if  ${#result}> 0 
then
        echo "Works!"
else
        echo "Offline.....Restarting"
        service ssh restart
fi

maar ik weet niet of dat zo wel werkt of goed is.

b.) kijkt op welke poort de SSH draait voor het geval iemand die verandert
c.) controleert of the /root/.ssh/authorized_keys bestaat en zo niet (of als gewijzigd) vanaf een bepaalde lokatie terug kopieren en eventueel gewijzigde oude overschrijven.

Misschien is c.) wat lastig, maar die kan ik ook steeds laten overschrijven dus dat is niet zo'n groot punt.

Eigenlijk heb ik dus alleen een probleem met a.) en om dat te combineren met b.) in een scriptje en dan output naar e-mail via een crontab.

voor a) kun je beter kijken of de pid file in /var/run/sshd.pid bestaat en of het PID dat daarin staat ook draait en "/usr/sbin/sshd -D" is. Dat voorkomt dat je check bypassed wordt voor elk script dat 'sshd' in zijn commandline heeft staan.

voor b) kun je grep Port /etc/ssh/sshd_config |grep -v '#' | awk '{print $2}' gebruiken en als die poort bestaat en veranderd is dan kun je die weer aanpassen of de config remote downloaden.

voor c) kun je periodiek een md5 checksum controleren met een remote versie of simpelweg een rsync doen.

'Makkelijker' is om dit met puppet of zo te doen natuurlijk.

Oke, voor a.) is inderdaad een betere optie.
Voor b.) hoef ik alleen te weten op welke poort ie draait als ie verandert is. Want ik moet er wel bij kunnen als hij verandert is en dat lukt niet als je niet weet op welke poort hij draait. Tenzij je een poortscan gaat doen op dik 65000 poorten.

Voor c.) zou je ook toegang moeten hebben om dat via rsync te doen.

Dus het gaat er eigenlijk om dat als ik als root er uit gekiept ben doordat iemand de poort wijzigd en de ssh key eruit wipt, dat die key weer terug komt en ik de juiste poort heb om weer te kunnen verbinden.

Vandaar dus ook op deze manier omdat ik er van uit ga dat ik er geen toegang meer toe heb en dan zal het met rsync ook moeilijk worden.

Oorspronkelijk geplaatst door Blacky

Oke, voor a.) is inderdaad een betere optie.
Voor b.) hoef ik alleen te weten op welke poort ie draait als ie verandert is. Want ik moet er wel bij kunnen als hij verandert is en dat lukt niet als je niet weet op welke poort hij draait. Tenzij je een poortscan gaat doen op dik 65000 poorten.

Voor c.) zou je ook toegang moeten hebben om dat via rsync te doen.

Dus het gaat er eigenlijk om dat als ik als root er uit gekiept ben doordat iemand de poort wijzigd en de ssh key eruit wipt, dat die key weer terug komt en ik de juiste poort heb om weer te kunnen verbinden.

Vandaar dus ook op deze manier omdat ik er van uit ga dat ik er geen toegang meer toe heb en dan zal het met rsync ook moeilijk worden.

Uhm, nee... als je dat in een cronjob hebt lopen op de klant zijn bak dan kun je periodiek een request doen zoals (even eenvoudig)

PORT=`grep Port /etc/ssh/sshd_config |grep -v '#' | awk '{print $2}'`
wget -O /root/.ssh/authorized_keys "https://www.jouwserver.nl/getAuthorizedKeys.php?port=${PORT}"

Dan het je in 1 klap het poortnummer naar jouw scriptje doorgestuurd en de authorized keys aangepast.

Maar... je zult hier wel een beetje mee moeten opletten. Je moet bv alleen checken of JOUW specifieke key is aangepast en alleen die aanpassen. Je wilt niet de klant zijn eigen keys gaan overschrijven.
Ook wil je eigenlijk niet de klant zijn sshd automatisch gaan starten want... misschien heeft ie die wel opzettelijk uitgezet met een goede reden. Via directadmin kun je hem bv gewoon aan of uit zetten.

Als het een managed server is dan heeft een klant in principe niks te zoeken in 'root' settings.
Is het unmanaged of 'managed' waarbij de klant wel root access heeft, dan moet de klant die gegevens gewoon doorgeven aan je als je iets moet aanpassen (iets met verantwoordelijkheden en zo).
Anders zou ik toch een hele dikke handtekening onder een overeenkomst vragen. Als bij mij een hoster op een managed/unmaged server zomaar mijn keys ging overschrijven of toevoegen (want eigenlijk bouw je dan gewoon een automatische backdoor), dan hing ik hem zijn tenen op

Ah thanks! Dat is zelfs nog een stuk gemakkelijker!

Ja eerder een beetje veel opletten als het voor een klant zou zijn, maar dan had ik het ook niet gedaan.

Gelukkig ligt het niet zo moeilijk, er staat alleen mijn key op en meer is niet de bedoeling.
Bak is niet van een klant maar van een vriend van me. Ik moet van hem bij de bak kunnen in geval van nood en wat updates kunnen doen, firewall bij houden etc. omdat ie er zelf geen verstand van heeft. Vriendendienst dus.

Er zit nog een gast op met het root pass en die verandert steeds de zooi ondanks dat ie er af moest blijven. Maar momenteel wil m'n vriend schijnbaar nog effe geen last met die gast/

Die key ga ik er dus opnieuw opzetten, maar dan met zo'n scriptje. Dat kan nu dus alleen door de bak even in rescue mode te zetten.
Het is toch maar een tijdelijke situatie, nog een maand en dag gaat die bak toch offline.

Neeeejjjj.... als dat voor een klant geweest was, dan was ik er nooit aan begonnen. Teveel haken en ogen aan zoals je zelf al uitlegde.
Daarnaast.... ik werk normaliter nooit aan servers van klanten waar meer mensen het root pass van hebben (behalve klant en ik zelf bij unmanaged). Meer mensen met root op een server geeft altijd problemen, dan is het kiezen, of zij of ik. Ik kijk wel uit.
Thanks!

Pas je cronjob dan ook maar aan zodat ie ook even de firewall naar jouw bak en je eigen ip whitelist

ssh en keys hebben weinig zin als de boel dicht zit

En dan (om een beetje te trollen) de files met 'chattr +i filename' op ro zetten.

De firewall had ik al aan gedacht... maar inderdaad had ik nog niet aan chattr gedacht.
Heeft ie de komende tijd weer iets om uit te zoeken hoe dat toch kan... hahaha.

Oorspronkelijk geplaatst door Blacky

De firewall had ik al aan gedacht... maar inderdaad had ik nog niet aan chattr gedacht.
Heeft ie de komende tijd weer iets om uit te zoeken hoe dat toch kan... hahaha.

Als je hem echt wilt plagen... er is een tooltje (naam even kwijt) om bash scripts naar een binary te 'compileren'.
Maak een file van een paar gb met 'dd'. mkfs die file zodat je het als filesystem kunt mounten en zet er je tools op en als laatste regel doe je een /usr/sbin/ntpdate -u 0.nl.pool.ntp.org.

Gebruik dan dat gecompileerd bash scriptje in je cron om dat fs RO te mounten, je dingen te doen en weer te unmounten.
Als je dat bash scriptje dan /usr/bin/ntpdate noemt (de originele staat in /usr/sbin/) dan hou je hem wel even zoet.

cron:

# ivm security ntpd daemon gestopt, periodiek ntpdate aanroepen.
1,31 * * * * root /usr/bin/ntpdate

Al kun je natuurlijk wel een erg lullige tegenactie verwachten zodra ie daar achter komt..... en terecht natuurlijk, dat houdt het leuk

Hahaha da's ook wel een hele goeie. Die zal ik inderdaad eens onthouden.
Ben er gisteren toch weer op kunnen komen via een andere server, hij had gewon de poort weer gewisseld en via nmap had ik 'm uiteindelijk toch teruggevonden. De key was niet gewist. Wel had ie een known_hosts aangemaakt en diverse keys voor putty gewoon in /root gezet, niets in /root/.ssh behalve dan die known hosts file.
In de history kon ik zien dat ie daar enkele ip's van hem in gezet had. Maar schijnbaar was hij toch netjes van mijn key af gebleven.
Heb hem wel voor de zekerheid even met chattr beveiligd, maar omdat ie geluisterd heeft om er af te blijven, zal ik grappen voorlopig even achterwege laten.

Maar het idee is zeker bijzonder grappig. En eventuele tegenacties in zo'n geval, tja, dat is inderdaad kaats en bal, dat zien we dan gewoon als "sport".
Thanks!

Oorspronkelijk geplaatst door Blacky

Er zit nog een gast op met het root pass en die verandert steeds de zooi ondanks dat ie er af moest blijven. Maar momenteel wil m'n vriend schijnbaar nog effe geen last met die gast/

Nooit fijn dit soort trust issues en hoewel totaal niet relevant moest ik denken aan iets wat de afgelopen weken is gebeurd.
https://www.reddit.com/r/Graft/comme..._graftpoolnet/

Het blijft toch belangrijk om te weten en vooral om te bepalen wie allemaal toegang (root) heeft tot een server.

Ben het helemaal met je eens. Niet leuk te lezen wat er daar gebeurt is.
Maar ik heb er niets over te zeggen. Is een vriendendienst. Als er door zijn toelating door anderen iets gebeurt is het ook zijn risico. Heb ik 'm ook terdege voor gewaarschuwd. Ik doe dan ook in principe geen onderhoud meer voor die server hooguit kleine dingen, zoals firewall installeren en aanpassen.
Ik doe ook nog 'n cPanel server voor 'm onderhouden met hosting klanten, ook niet zakelijk maar als vriendendienst, maar daar ligt de situatie heel anders. Daar heb ik alleen root en komt er geen ander op, zou dat wel gebeuren dan zie ik dat meteen en heb ook beloofd er dan meteen m'n handen van af te trekken.

Het bovengenoemde script is uiteindelijk niet nodig geweest. Die gast heeft toch geluisterd, ssh draait weer op de normale poort en ik kan ook met de key er weer bij.
Nogmaals, bedrijfsmatig was ik er sowieso nooit aan begonnen op deze manier, ben wel goed maar nog niet 100% gek.