OpenSSH : Users aan poorten binden

[Boudewijn]

Hoi


Ik ben bezig met een eigen RADIUS server en deze is gebaseerd op OpenBSD4.1
Als beveiligingsfeature had ik een volgende methodiek in gedachten:


User 'a' mag alleen op poort 'x' (let's say 1022) inloggen . User heeft wat authpf rules aan zich hangen waarna poort 22 voor SSH open gaat. Nu kan een echte user (user 'b') (met wheel als group) over 22 inloggen (eventueel kan ook 443 voor een web-interface open getrapt worden). Vereiste aan deze setup is dat ik in de SSH daemon af moet kunnen dwingen dat user 'b' niet op poort 'x' in moet kunnen loggen.

Dit kan dus niet met een Match user statement.


Weet iemand of dit wel mogelijk is, of dat dit plan naar /dev/null mag?

[Eijkb]

Als user a op poort 1022 moet inloggen, moet daarachter een ssh / telnet deamon hangen (bv. via /etc/services). Heb je 100 gebruikers, moet je dus op 100 poorten een ssh deamon hangen of iig die poorten openzetten. Lijkt me ook niet handig en maakt weinig verschil met het feit ofdat je alleen poort 22 openzet

[Boudewijn]

jij zegt nu dus feitelijk dat ik maar een tweede instance van SSH op die 2e poort moet draaien?
verschil is dat ik hiermee afdwing dat iemand zowel een certificaat heeft als username+pass

zo maar eens even gaan zoeken hoe ik dan in OpenBSD doe

[Parasietje]

Ik begrijp niet goed wat het nut is van de beveiliging. Je wilt port knocking combineren met een password-based authentication?

Mijn raad: start 1 sshd op poort 1000. Zet de shell voor 'a' op een eigengemaakt programma. Dat programma vraagt paswoord, en zet dan de firewall rules open.

Maar het blijft een beveiliging gebaseerd op twee dingen: iets wat je weet (paswoord) en iets wat je hebt (port knocking-programma, certificaat, whatever). De enige manier om het veiliger te maken, is om 'iets wat je bent' er nog bij te plakken: biometrics.

[Boudewijn]

nou ja de truc is inderdaad dat het een soort port knocking wordt, maar dan wel beveiligd en met een certificaat.


Liever geen homebrew programma: het ding moet veilig zijn en blijven. OpenSSH is redelijk gegarandeerd veilig.

[blaataaps]

openssh garandeert maar weinig hoor, je weet alleen dat er meerdere mensen naar gekeken heben, maar er zit geen garantie op (er staat niet voor niks met hele grote letters NO WARRANTY in bijna elke LICENCE-file)
Waarom laat je niet gewoon op elke poort inetd een sshd met een ander configuratiebestand aanroepen, hoewel ik het nut nogal betwijfel; "meer ingewikkeld gedoe -> veiliger" is niet per definitie waar natuurlijk, er is vast een reden dat dit nog niet gemaakt is

edit:
Trailblazer: precies mijn punt

[ Voor 14% gewijzigd door blaataaps op 24-06-2007 11:50 ]

[TrailBlazer]

dit is dus volkomen zinloos. Er is een reden dat er well known ports zijn gekozen. Stel dat ik van mijn werk naar buiten wil naar zo'n niet standaard poort dan zegt de FW mooi bekijk het maar. Kortom plan laten varen je creeert alleen maar extra problemen. Wil je het veilig hebben ga dan met een token generator werken.

@blaataaps ik heb nog nooi garanties gekregen bij software da het gegarandeerd werkt volgens mij.

[ Voor 13% gewijzigd door TrailBlazer op 24-06-2007 11:48 ]

[Boudewijn]

openssh garandeert maar weinig hoor, je weet alleen dat er meerdere mensen naar gekeken, maar er zit geen garantie op

Klopt, maar mijn homebrew progjes kijkt niemand naar OpenSSH is imo veilig genoeg.

Dat van die inetd+SSH kan ik eens gaan doen.

feit is gewoon dat ik wil afdwingen dat users een username+pass hebben, en een certificaat.
Sowieso zal pf de poort puur en alleen naar het user_ip met het certificaat open gooien.

[Boudewijn]

TrailBlazer schreef op zondag 24 juni 2007 @ 11:47:
dit is dus volkomen zinloos. Er is een reden dat er well known ports zijn gekozen. Stel dat ik van mijn werk naar buiten wil naar zo'n niet standaard poort dan zegt de FW mooi bekijk het maar. Kortom plan laten varen je creeert alleen maar extra problemen. Wil je het veilig hebben ga dan met een token generator werken.

klopt, alleen is dit een device dat je alleen intern wil kunnen benaderen, en waarvan ik weet dat er zo allerlei mensen 'geinteresseerd'naar gaan kijken.

Mogelijk komt het ook in informatica-onderwijs omgevingen te hangen, dan is een stukje extra beveiliging niet eens onhandig.

Token generator: ja heb ik voorgedragen, maari s om budgetaire redenen afgewezen.

[TrailBlazer]

Boudewijn schreef op zondag 24 juni 2007 @ 11:49:
[...]

klopt, alleen is dit een device dat je alleen intern wil kunnen benaderen, en waarvan ik weet dat er zo allerlei mensen 'geinteresseerd'naar gaan kijken.

Certificaten laten genereren die je persoonlijk via een USB stickje bij systeembeheer moet inleveren is veilig genoeg. Als ik me druk moet gaan maken om iedereen die geinteresseerd is slaap ik nooit meer.

[Boudewijn]

ja okay heb je ook wel gelijk in , maar ik wil niet weten of het nuttig is, maar of het kan