Wanneer SSH meer problemen veroorzaakt dan het oplost
SSH is een zeer populaire security tool bij systeembeheerders en security professionals. De software maakt het mogelijk om op een versleutelde manier in te loggen op een client, en op afstand via een shell commando's op de andere machine uit te voeren. Omdat SSH met encryptie werkt is het voor afluisteraars zo goed als onmogelijk om wachtwoorden of commando's te achterhalen, ook al wordt de (internet)verbinding afgetapt. Verder authenticeert het de server waardoor de kans op een "man-in-the-middle" aanval afneemt.
Het is echter de vraag hoe verstandig het is om SSH te gebruiken. Gebruikers kunnen de tool zeer eenvoudig misbruiken en ook systeembeheeders schieten vaak met SSH enorme gaten in hun eigen beveiliging. Daarnaast behoort SSH volgens het SANS Instituut tot een van de meest aangevallen services op het internet. Dit artikel beschrijft waarom mensen SSH implementeren, wordt er naar port forwarding gekeken en met wat voor soort aanvallen men te maken kan krijgen.
Tuurlijk kan SSH risico's met zich meebrengen, maar in welke
situatie is dat? Ik kan er in dit artikel niks over vinden.
Erger nog: Er staat in dit artikel eerst te lezen dat het
Secure is, en de "man in the middle" niet mee kan luisteren.
Prima toch? Wat is daar mis mee?
Dan is SSH toch zeer Secure zou ik zeggen.
Tuurlijk is het mogelijk om met Brute Force Attacks een SSH
connectie te "kraken", maar ik als Sys-Admin, heb dat zo door.
En BTW: Ik zorg er altijd voor, dat alleen "trustet" IP's in
kunnen loggen.
Daarvoor heeft men in Linux een File genaamd: host.deny.
Dus wat is het probleem dan eigenlijk met SSH?
Ik zie m niet hoor.....
Sorry hoor, maar dit is voor mij een Broodje Aap verhaal.
Tuurlijk kan SSH risico's met zich meebrengen, maar in welke
situatie is dat? Ik kan er in dit artikel niks over vinden.
Erger nog: Er staat in dit artikel eerst te lezen dat het
Secure is, en de "man in the middle" niet mee kan luisteren.
Prima toch? Wat is daar mis mee?
Dan is SSH toch zeer Secure zou ik zeggen.
Tuurlijk is het mogelijk om met Brute Force Attacks een SSH
connectie te "kraken", maar ik als Sys-Admin, heb dat zo door.
En BTW: Ik zorg er altijd voor, dat alleen "trustet" IP's in
kunnen loggen.
Daarvoor heeft men in Linux een File genaamd: host.deny.
Dus wat is het probleem dan eigenlijk met SSH?
Ik zie m niet hoor.....
(logich).
want dan kan men port forworden en dan bij servecis komen
die niet voor het internet bedoelt zijn en dus mischien
vijligheids lekken kunnen hebben
Hierdoor kunnen gebruikers bijvoorbeeld inloggen met SSH op hun server
thuis. Daarna met een tunnel vanaf hun werkplek kunnen ze bijvoorbeeld
met remote desktop bij hun PC. RDP gaat dan via de SSH tunnel. Dit is
echt heel eenvoudig te doen. met PUTTY en open SSH.
Als de Firewall van het bedrijf wel SSH toelaat, maar RDP specifiek
verbied, kun je via een SSH tunnel er toch bij. En zie hier misbruik van een
legaal protocol (SSH) voor het transporteren van RDP.
Dan is waar dit artikel op doelt. SSH toelaten van binnen naar buiten kan
dus meer risico met zich meebrengen.
geregeld aan de poort van de server.
Feit is wel dat je de SSH toegang best goed kunt regelen,
geen toegang middels user/pw challenge, IP restrictie en
toegang enkel middels keyfile (key file met een deftig pw
beveiligd). Zoals altijd is het dus de admin vd machine die
bepaald hoe veilig de geboden toegang is.
Challenge/Brute Force attacks kun je relatief makkelijk
ondervangen mbv Fail2Ban of dergelijke scripts die een
client blokken bij meer dan X mislukte pogingen waarmee je
challenges afbreekt (en je logs kleiner houdt).
IP's die voortdurend terugkeren voor een nieuwe poging kun
je permanent blokkeren middels hosts.deny
Zoals wel vaker is veilig dan wel onveilig een zeer relatief
begrip en t artikel is wat dat betreft redelijk vaag .
Pantagruel
Je kunt met SSH tunnels heel eenvoudig een VPN-tunnel opzetten.
Hierdoor kunnen gebruikers bijvoorbeeld inloggen met SSH op
hun server
thuis. Daarna met een tunnel vanaf hun werkplek kunnen ze
bijvoorbeeld
met remote desktop bij hun PC. RDP gaat dan via de SSH
tunnel. Dit is
echt heel eenvoudig te doen. met PUTTY en open SSH.
Als de Firewall van het bedrijf wel SSH toelaat, maar RDP
specifiek
verbied, kun je via een SSH tunnel er toch bij. En zie hier
misbruik van een
legaal protocol (SSH) voor het transporteren van RDP.
Dan is waar dit artikel op doelt. SSH toelaten van binnen
naar buiten kan
dus meer risico met zich meebrengen.
Nou enorm. Sorry hoor, maar een beetje securityexpert
monitort zijn netwerk, laat ssh niet zomaar overal naar toe
en creert een mooie lagenstructuur (liever nog een mooie
cirkelstructuur) waar de workstations bijna niks mogen. Elk
protocol dat naar buiten doorgelaten wordt is een
securityrisico, en om nou SSH eruit te lichten zoals in dit
stukje gedaan wordt is gewoon dikke bs.
pas bij de SSH-service kunnen.
De prutsers die ssh op poort 22 laten draaien, nog met
alleen wachtwoorden inloggen, gewone gebruikers toestaan op
ssh en dan ook nog hun servertje niet bijwerken tel ik even
niet mee.
RDP specifiek verbied, kun je via een SSH tunnel er toch
bij. En zie hier misbruik van een legaal protocol (SSH) voor
het transporteren van RDP.
Browser restricties (bepaalde geblokkerde sites
bijvoorbeeld)? File up/download restricties (executables
bijvoorbeeld)? IRC? IM? Streaming audio/video? Etc. etc.
etc. etc. Allemaal vrij eenvoudig te tunnelen over SSH.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
