Automatisch inloggen met ssh

omdat het kan

heb je wel keys gegenereerd?
en deze in authorized_keys gecat?

woensdag 2 mei 2007 21:37

Acties:

Gertjan

mmmm, beer...

Boudewijn schreef op woensdag 02 mei 2007 @ 21:08:
heb je wel keys gegenereerd?
en deze in authorized_keys gecat?

En dat moet iemand die net met Linux begonnen is snappen?

Netvista: dit is vrij makkelijk te vinden op Google, met een simpele zoekopdracht zonder moeilijke woorden:
http://www.google.nl/sear...&btnG=Google+zoeken&meta=
. De eerst hit geeft je eigenlijk direct het goede antwoord, zij het wat beknopt...

[ Voor 7% gewijzigd door Gertjan op 02-05-2007 21:38 ]

woensdag 2 mei 2007 22:15

Acties:

woensdag 2 mei 2007 22:56

Topicstarter

Bedankt voor de tips GertJan en Boudewijn. Ik heb inderdaad de keys gegenereerd en gecat n aar authorized_keys2 op de server. Maar hij blijft vragen om een password. Kan het niet zijn dat er wat in de sshd_conf file veranderd moet worden?

EDIT:

Probleem opgelost..

. het probleem was dat er in de sshd_conf stond :

AuthorizedKeysFile .ssh/authorized_keys

Dit moet dus AuthorizedKeysFile .ssh/authorized_keys2 zijn.

[ Voor 30% gewijzigd door netvista op 02-05-2007 22:24 ]

Acties:

omdat het kan

nou het moet eigenlijk authorized_keys zijn. waar je die 2 vandaan haalt.. ssh-2 mischien?

@Gertjan: Iemand die dat niet snapt moet niet met SSH enzo spelen vind ik. SSH is veilig, mits (!) goed beheerd. En ja op GoT verwacht ik een beetje eigen inzet.

woensdag 2 mei 2007 23:20

Acties:

donderdag 3 mei 2007 12:28

Topicstarter

Boudewijn schreef op woensdag 02 mei 2007 @ 22:56:
nou het moet eigenlijk authorized_keys zijn. waar je die 2 vandaan haalt.. ssh-2 mischien?

@Gertjan: Iemand die dat niet snapt moet niet met SSH enzo spelen vind ik. SSH is veilig, mits (!) goed beheerd. En ja op GoT verwacht ik een beetje eigen inzet.

ja ..inderdaad van SSH2 ja....en dat staat in na genoeg elke howto zo. De keys had ik overigens al gegenereerd en in authorized_keys2 gecat (zoals beschreven in de diverse howto's) voordat ik op GOT om advies vroeg. het enige wat er dus nog ontbrak was het 2-tje.

Maar Boudewijn, als ik (of iemand) SSH niet onmiddelijk begrijp moet ik er maar niet mee " spelen?" Hoe word ik dan geacht het ooit te leren?

@ Gertjan, bedankt voor het aandragen van wat beter google keywords.

Acties:

Verwijderd

Boudewijn schreef op woensdag 02 mei 2007 @ 22:56:
nou het moet eigenlijk authorized_keys zijn. waar je die 2 vandaan haalt.. ssh-2 mischien?

Dat kwam uit de tijd dat je nog aparte key paren had voor ssh protocol 1 en 2. Tegenwoordig is het allemaal geintegreerd in ~/.ssh/authorized_keys. Tevens moet je ssh protocol 1 niet meer gebruiken omdat dit vulnerable is voor MITM attacks.

@Gertjan: Iemand die dat niet snapt moet niet met SSH enzo spelen vind ik. SSH is veilig, mits (!) goed beheerd. En ja op GoT verwacht ik een beetje eigen inzet.

Jaja meneer de expert, en waarop baseer je dat dan? Dat iemand passwordless keys gebruikt? En waarom is dat gevaarlijk in een RFC1918 netwerk waarbij je eerst langs een nat device heenmoet? Op het moment dat je dit wilt misbruiken moet je alreeds op het netwerk zijn (zij het fysiek, zij het via een backdoor), maargoed, dan heb je serieuzere problemen dan dat iemand je ssh key te pakken heeft (je bent dan namelijk al gepwnd). Wat voor alternatief stel je voor? Telnet? Serieel? VNC? Ik vind dat je iets langer moet nadenken over de opmerkingen die je maakt voordat je zoiets post Boudewijn.

donderdag 3 mei 2007 13:15

Acties:

omdat het kan

PermitRootLogin staat niet op no bijvoorbeeld. Vind ik wel een puntje

dan is de stap om als root 'gepwnd' te worden weer wat kleiner.
achter een nat-device is het vrij veilig ja.

meneer de expert

[ Voor 36% gewijzigd door Boudewijn op 03-05-2007 13:16 ]

donderdag 3 mei 2007 13:19

Acties:

Cyphax

Moderator LNX

Als het gaat om een bak die direct aan het internet komt te hangen zou ik zeker ook wel zeggen "zorg eerst dat je echt weet wat je aan het doen bent", maar in geval van een PC in hetzelfde netwerk ergens thuis kan er niet zo heel gek veel misgaan.

Je moet het toch leren, en als je de tijd ervoor hebt is dit een prima methode.

Saved by the buoyancy of citrus

donderdag 3 mei 2007 13:37

Acties:

Verwijderd

Kom op Boudewijn... Iemand moet het toch leren.

Alsof jij niet vunerable bent voor bv. bruteforce attacks op je niet secure imap server die voor de hele wereld open staat.

Edit: typo

[ Voor 4% gewijzigd door Verwijderd op 03-05-2007 13:43 ]

donderdag 3 mei 2007 13:49

Acties:

Verwijderd

Dus. Security is meer dan alleen maar wat settings in een configuratie file. In dit geval is het een nutteloze discussie. 1 omdat dit helemaal niet de vraag is van de TS; 2 omdat het totaal niet relevalt is voor dit topic; 3 de kans dat iemand zoveel moeite doet om een thuis machine te attacken nihil is en 4 zelfs al zou die persoon/script dit doen zit de ssh daemon netjes verstopt achter een nat device (en ik ga ervanuit dat gezien de kennis van de TS (no offence) dat deze niet een portforward op poort 22 heeft staan).

donderdag 3 mei 2007 13:59

Acties:

omdat het kan

okay daar hebben jullie gelijk in.

* Boudewijn is weer stil

donderdag 3 mei 2007 14:12

Acties:

garp

Verwijderd schreef op donderdag 03 mei 2007 @ 13:37:
Kom op Boudewijn... Iemand moet het toch leren.

Alsof jij niet vunerable bent voor bv. bruteforce attacks op je niet secure imap server die voor de hele wereld open staat.

Edit: typo

Oh en Boudewijn: bel ff die gasten van nedlinux.com waar je je dns van afneemt dat hun ns1 en ns3 zowel autoritative zijn voor domeinen als recursive lookups toestaan. Niet erg handig ivm cache poisoning attacks.

donderdag 3 mei 2007 14:46

Acties:

omdat het kan

dank je voor de tip, heb net een ticket ingekickt

donderdag 3 mei 2007 19:41

Acties:

Pim.

Aut viam inveniam, aut faciam

En weer ontopic ???

"The trouble with quotes from the Internet is that you can never know if they are genuine." - Elvis Presley | Niet met me eens ? DM ME

donderdag 3 mei 2007 19:48

Acties:

donderdag 3 mei 2007 19:53

Topicstarter

Interessante discussie dit...

Maar goed, om nog even terug te komen op de specifieke situatie van deze "linux n00b".Ik gebruik ssh inderdaad puur op mijn eigen lannetje. Dit zijn uiteraard geen produktiesystemen. En ja, #PermitRootLogin staat inderdaad op yes omdat ik voor het gemak op beide systemen ingelogt ben als root. Aangezien ik de enige gebruiker ben van deze systemen, lijkt me dat geen probleem.

Verder heb ik port forwarding voor poort 22 inderdaad niet geactiveerd op de router omdat ik niet geinteresseerd ben om 1 van de systemen van buitenaf te bereiken.

Hopelijk verklaart dit dat ik de security op een laag pitje heb staan, aangezien alles lokaal is

Acties:

donderdag 3 mei 2007 20:24

netvista schreef op donderdag 03 mei 2007 @ 19:48:
omdat ik voor het gemak op beide systemen ingelogt ben als root. Aangezien ik de enige gebruiker ben van deze systemen, lijkt me dat geen probleem.

Kijk eens naar sudo zou ik zeggen

Acties:

donderdag 3 mei 2007 20:29

Topicstarter

robbert schreef op donderdag 03 mei 2007 @ 19:53:
[...]

Kijk eens naar sudo zou ik zeggen

Bedankt voor de suggestie, maar in mijn situatie zie ik er geen enkel voordeel in......

Acties:

donderdag 3 mei 2007 20:32

netvista schreef op donderdag 03 mei 2007 @ 20:24:
[...]

Bedankt voor de suggestie, maar in mijn situatie zie ik er geen enkel voordeel in......

Als die 2 systemen enkel server zijn achter je NAT zal het inderdaad wel mee vallen qua veiligheid. Maar er bijvoorbeeld op webbrowsen als root zou ik niet zo graag doen.

Daarnaast zie ik er ook geen enkel nadeel van in om sudo te gebruiken.

[ Voor 9% gewijzigd door robbert op 03-05-2007 20:30 ]

Acties:

donderdag 3 mei 2007 20:38

Topicstarter

1 van de systemen is een laptop en word inderdaad ook gebruikt om te web browsen. Op zich heb je dus wel een punt. Ik zal me eens in sudo gaan verdiepen.

[ Voor 12% gewijzigd door netvista op 03-05-2007 20:32 ]

Acties:

Fallen from grace

Boudewijn schreef op donderdag 03 mei 2007 @ 13:15:
PermitRootLogin staat niet op no bijvoorbeeld. Vind ik wel een puntje

Is volgens mij nog steeds standaard zo als je op bijvoorbeeld Debian Etch het sshd package installeert.

Wie trösten wir uns, die Mörder aller Mörder?

vrijdag 4 mei 2007 02:00

Acties:

omdat het kan

klopt maar mijns inziens is dat wel vrij onveilig. als in: stel dat je met passwords werkt... nu hoef je alleen op root te bruteforcen. Root is er altijd.

Als je met een losse user+wheel werkt moet je die username weten (en dat is lastig...) en ook nog eens 2 passwords bruteforcen.

Vind ik wel een verschil

vrijdag 4 mei 2007 09:46

Acties:

TheFirepit

Vuurbal

Om nog even op de discussie in te haken de volgende vraag:

Wat is de meeste veilige sshd configuratie die er is als je server ook van buitenaf bereikbaar is?

It's nice to be important, but it's more important to be nice.

vrijdag 4 mei 2007 09:56

Acties:

Cyphax

Moderator LNX

* Cyphax denkt aan de volgende dingen:
- Per IP regelen wie er wel en niet in mag verbinden (niet zozeer SSH zelf dan)
- Root-logins uitschakelen uiteraard
- Maximaal aantal pogingen voor je wachtwoord op 1 zetten
- SSH op een andere poort dan 22 draaien

[ Voor 7% gewijzigd door Cyphax op 04-05-2007 09:57 ]

Saved by the buoyancy of citrus

vrijdag 4 mei 2007 10:13

Acties:

Verwijderd

Boudewijn schreef op vrijdag 04 mei 2007 @ 02:00:
klopt maar mijns inziens is dat wel vrij onveilig. als in: stel dat je met passwords werkt... nu hoef je alleen op root te bruteforcen. Root is er altijd.

En doe je dat dan ook monitoren en daarop reageren? Anders heeft dit alsnog geen nut...

Als je met een losse user+wheel werkt moet je die username weten (en dat is lastig...) en ook nog eens 2 passwords bruteforcen.

Euh, local-root exploit? Hoef je maar 1 password te hacken.

Overigens, als je je software up to date houd en je doet monitoren op brute-force's, dan is er alsnog weinig aan de hand als je PermitRootLogin op yes hebt staan. Tevens is de kans dat dit gebeurt (met moderne software) nihil, om de redenen die ik eerder aangegeven heb. Je zou je imho meer druk moeten maken over web-based attacks, aangezien de overgrote bulk van gehackde linux machine's hierdoor ten prooi vallen....

* Cyphax denkt aan de volgende dingen:
[...]

* zowel op firewall als op tcpwrappers niveau op ip basis toegang verlenen
* AllowUser/AllowGroup in sshd_config
* alleen pub/priv key authentication gebruiken (hoef je je ook niet meer om brute-force's druk te maken

)
* Ssh op een niet-standaard poort draaien
* UsePrivilegeSeparation aanzetten
* Alleen protocol 2 accepteren
* en natuurlijk Banner instellen met een hele mooie rechtsgeldige /etc/issue

vrijdag 4 mei 2007 10:21

Acties:

Fallen from grace

Boudewijn schreef op vrijdag 04 mei 2007 @ 02:00:
klopt maar mijns inziens is dat wel vrij onveilig. als in: stel dat je met passwords werkt... nu hoef je alleen op root te bruteforcen. Root is er altijd.

Als je met een losse user+wheel werkt moet je die username weten (en dat is lastig...) en ook nog eens 2 passwords bruteforcen.

Vind ik wel een verschil

Met goede wachtwoorden is dat verschil academisch.

Wie trösten wir uns, die Mörder aller Mörder?

vrijdag 4 mei 2007 10:29

Acties:

marko77

Cyphax schreef op vrijdag 04 mei 2007 @ 09:56:
* Cyphax denkt aan de volgende dingen:
- Per IP regelen wie er wel en niet in mag verbinden (niet zozeer SSH zelf dan)
- Root-logins uitschakelen uiteraard
- Maximaal aantal pogingen voor je wachtwoord op 1 zetten
- SSH op een andere poort dan 22 draaien

plus: een user aanmaken met een 'rare' username, en alleen die toegang geven om in te loggen

Mijn rig

vrijdag 4 mei 2007 18:02

Acties:

Topicstarter

Cyphax schreef op vrijdag 04 mei 2007 @ 09:56:

- Maximaal aantal pogingen voor je wachtwoord op 1 zetten

Als linux beginner zijnde heb ik ook nog een suggestie

Helemaal geen logins toestaan op basis van password authentication, maar alleen op basis van keys....

vrijdag 4 mei 2007 21:03

Acties:

zaterdag 5 mei 2007 09:57

Fallen from grace

netvista schreef op vrijdag 04 mei 2007 @ 18:02:
Helemaal geen logins toestaan op basis van password authentication, maar alleen op basis van keys....

En als iemand je computer jat, of op 1 computer inbreekt, kan hij vervolgens overal bij. Dan is een wachtwoord dat alleen in je hoofd zit nog net iets veiliger. Voor root wachtwoorden: minimaal 14 tekens, minimaal 1 cijfer, 1 hoofdletter en 1 ander teken en geen bestaande woorden in het wachtwoord.

Bijvoorbeeld het programma pwgen genereert prima wachtwoorden die niet gebruteforced zullen worden.

Wie trösten wir uns, die Mörder aller Mörder?

Acties:

Verwijderd

Confusion schreef op vrijdag 04 mei 2007 @ 21:03:
[...]
Bijvoorbeeld het programma pwgen genereert prima wachtwoorden die niet gebruteforced zullen worden.

Wedden dat die wel gebruteforced kunnen worden

De kans dat ze iets nuttigs vinden is daarintegen vrij klein en dat hoor je mbv monitoring al opgepikt cq geblokked te hebben voordat ze iets nuttigs kunnen

zaterdag 5 mei 2007 10:01

Acties:

zaterdag 5 mei 2007 21:02

Confusion schreef op vrijdag 04 mei 2007 @ 21:03:
En als iemand je computer jat, of op 1 computer inbreekt, kan hij vervolgens overal bij.

Je kan toch een passphrase op zo'n key zetten? Wat betekend dat die key waardeloos is zonder die passphrase. Als je dan enkel logins op basis van zo'n key toestaat heb je dus zowel de key als de bijbehorende passphrase nodig.

Acties:

zaterdag 5 mei 2007 21:20

Fallen from grace

Verwijderd schreef op zaterdag 05 mei 2007 @ 09:57:
[..] en dat hoor je mbv monitoring al opgepikt cq geblokked te hebben voordat ze iets nuttigs kunnen

Tjah, ik moet zeggen dat ik daar (nog) geen maatregelen voor heb getroffen. Als iemand het nu echt heel hard probeert, dan loopt het hooguit uit op een DoS (tenzij de ssh daemon of snort of andere geinstalleerde programma's toevallig actie ondernemen op basis van een stukje default config dat ik nog niet goed bekeken heb). Dat zie ik dan wel weer.

robbert schreef op zaterdag 05 mei 2007 @ 10:01:
Je kan toch een passphrase op zo'n key zetten? Wat betekend dat die key waardeloos is zonder die passphrase. Als je dan enkel logins op basis van zo'n key toestaat heb je dus zowel de key als de bijbehorende passphrase nodig.

Als je dat doet, dan moet je telkens als je de key wilt gebruiken het wachtwoord invoeren. Dat schiet weer niet op

.

Wie trösten wir uns, die Mörder aller Mörder?

Acties:

zaterdag 5 mei 2007 21:40

Confusion schreef op zaterdag 05 mei 2007 @ 21:02:
Als je dat doet, dan moet je telkens als je de key wilt gebruiken het wachtwoord invoeren. Dat schiet weer niet op .

Daar hebben ze weer ssh-agent voor. Dan hoef je slecht 1maal je passphrase in te typen. Of je kan libpam-ssh gebruiken, dan hoef je zelf nooit die passphrase in te typen.

Acties:

omdat het kan

Confusion schreef op zaterdag 05 mei 2007 @ 21:02:
[...]

Als je dat doet, dan moet je telkens als je de key wilt gebruiken het wachtwoord invoeren. Dat schiet weer niet op .

Daar heb je dan weer een keychain voor.
http://gentoo-wiki.com/HOWTO_ssh-agent_the_easy_way
http://www.gentoo.org/doc/nl/keychain-guide.xml

Het idee is als volgt:

de eerste keer dat je inlogt (of na een bepaald interval sinds vorige keer dat je passphrase hebt getypt) onthoudt key-agent het voor je. Daarna hoeft het dus niet meer (of tot je interval verstreken is).

Erg makkelijk.

zaterdag 5 mei 2007 23:33

Acties:

Fallen from grace

Call me paranoid, maar belangrijke wachtwoorden ga ik dus niet door een applicatie in memory laten houden, met alle kans dat het een keer in de swap partititie of in /tmp terecht komt. M'n GoT login laat ik ook niet door Iceweasel cachen.

Wie trösten wir uns, die Mörder aller Mörder?

zondag 6 mei 2007 00:05

Acties:

Confusion schreef op zaterdag 05 mei 2007 @ 23:33:
Call me paranoid, maar belangrijke wachtwoorden ga ik dus niet door een applicatie in memory laten houden, met alle kans dat het een keer in de swap partititie of in /var terecht komt. M'n GoT login laat ik ook niet door Iceweasel cachen.

Ik mag aannemen dat die niet het wachtwoord plain in zijn geheugen bewaard. Hij zal dan wel de ontsleutelde key in z'n geheugen bewaren ofzo.

zondag 6 mei 2007 00:13

Acties:

omdat het kan

robbert schreef op zondag 06 mei 2007 @ 00:05:
[...]

Ik mag aannemen dat die niet het wachtwoord plain in zijn geheugen bewaard. Hij zal dan wel de ontsleutelde key in z'n geheugen bewaren ofzo.

daar kun je inderdaad wel vanuit gaan.
sowieso is het natuurlijk zo dat je dat wel moet doen op een box die niet van buiten kan worden benaderd en die ook het pand niet verlaat (zoals een laptop).

ook kun je bijvoorbeeld de key maar 5 minuten laten onthouden

zondag 6 mei 2007 00:26

Acties:

Boudewijn schreef op zondag 06 mei 2007 @ 00:13:
sowieso is het natuurlijk zo dat je dat wel moet doen op een box die niet van buiten kan worden benaderd en die ook het pand niet verlaat (zoals een laptop).

Wat is het probleem precies met een laptop? Op het moment dat ik dat ik hem niet gebruik (suspend en) lock ik hem. Veel plezier om er dan nog iets mee voor elkaar te krijgen indien iemand hem jat. Ze kunnen hem wel rebooten (en met een live cd gaan kloten), maar dan is de key sowieso waardeloos zonder mijn passphrase.

Of ben ik lang niet zo paranoia en zie ik een hoop rampscenario's over het oog.

[ Voor 7% gewijzigd door robbert op 06-05-2007 00:43 ]

zondag 6 mei 2007 10:52

Acties:

Fallen from grace

robbert schreef op zondag 06 mei 2007 @ 00:05:
Hij zal dan wel de ontsleutelde key in z'n geheugen bewaren ofzo.

Dat is niet minder erg

.

Wie trösten wir uns, die Mörder aller Mörder?

zondag 6 mei 2007 11:36

Acties:

Verwijderd

Zzzz.
* zet enkel ssh protocol 2 op
* geen root login op afstand toelaten
* gebruik sudo
* zet ssh op een andere poort dan 22 (security through obscurity, ja dat weet ik)
* gebruik een DSA/RSA key IN COMBINATIE MET een sterk paswoord (liever nog een echte "pass phrase")

Dan ben je al redelijk safe

zondag 6 mei 2007 18:57

Acties:

omdat het kan

* gebruik sudo

waarom zou dat veiliger zijn?
een nette su met goede /etc/pam.d/su doet ook veel.

[ Voor 3% gewijzigd door Boudewijn op 06-05-2007 18:57 ]

zondag 6 mei 2007 21:30

Acties:

Boudewijn schreef op zondag 06 mei 2007 @ 18:57:
[...]

waarom zou dat veiliger zijn?
een nette su met goede /etc/pam.d/su doet ook veel.

Het grote voordeel van sudo tegenover su is als je met meerdere beheerders werkt. Met su moet het root account enabled zijn en om root je worden heb je het root wachtwoord nodig, met sudo heb je niet het root wachtwoord nodig om root te worden. Dus niet alle beheerders hoeven dat root wachtwoord te weten.

Of vergeet ik iets?

zondag 6 mei 2007 21:53

Acties:

omdat het kan

ja.

als 1 user zijn gewone password 'compromiset' dan kan een snodaard root worden?
met su heb je 2 passwords nodig .

ik geloof btw dat deze discussie al 10.000x is gevoerd.

zondag 6 mei 2007 22:12

Acties:

Verwijderd

* alleen pub/priv key authentication gebruiken (hoef je je ook niet meer om brute-force's druk te maken )

En mocht dit niet mogelijk zijn kan je OPIE one time passwords gebruiken, of een ander one time password mechanisme. Dit is effectief tegen brute forcen, en ook tegen keyloggers op de host vanwaar je inlogt.

maandag 7 mei 2007 10:47

Acties:

DJ Buzzz

robbert schreef op zondag 06 mei 2007 @ 21:30:
[...]

Het grote voordeel van sudo tegenover su is als je met meerdere beheerders werkt. Met su moet het root account enabled zijn en om root je worden heb je het root wachtwoord nodig, met sudo heb je niet het root wachtwoord nodig om root te worden. Dus niet alle beheerders hoeven dat root wachtwoord te weten.

Of vergeet ik iets?

Bij meerdere beheerders die toch toegang als root nodig hebben, zou ik kiezen voor een public / private key auth voor root waarbij elke beheerder een eigen passphrase op de private key zet. Zo heb je niet een probleem als 1 van de wachtwoorden gecompromized wordt. Verder hoef je niet overal sudo voor te zetten, ik word zelf anders altijd gek als ik veel beheertaken moet doen

.

Ook kun je natuurlijk iedereen z'n eigen key laten gebruiken, ligt ook een beetje aan met hoeveel mensen je werkt en wie dan weer de keys beheert e.d. Verder het root password laten auto generaten en ergens veilig opslaan, mocht er iets mis zijn en je wilt via een serial console o.i.d. erbij kunnen.

[ Voor 15% gewijzigd door DJ Buzzz op 07-05-2007 10:52 ]

maandag 7 mei 2007 11:31

Acties:

omdat het kan

DJ Buzzz schreef op maandag 07 mei 2007 @ 10:47:
[...]

Bij meerdere beheerders die toch toegang als root nodig hebben, zou ik kiezen voor een public / private key auth voor root waarbij elke beheerder een eigen passphrase op de private key zet. Zo heb je niet een probleem als 1 van de wachtwoorden gecompromized wordt. Verder hoef je niet overal sudo voor te zetten, ik word zelf anders altijd gek als ik veel beheertaken moet doen .

je bent niet de enige. het eerste wat ik op een ubuntu doos doe is sudo su.
jaja ranzig, maar ik heb ook zelf nergens een ubuntu doos die iets serieus-achtigs doet (momenteel paar deb, aantal gentoo en paar freebsd)

maandag 7 mei 2007 14:02

Acties:

DJ Buzzz schreef op maandag 07 mei 2007 @ 10:47:
Verder hoef je niet overal sudo voor te zetten, ik word zelf anders altijd gek als ik veel beheertaken moet doen .

sudo -s

is je vriend

maandag 7 mei 2007 14:38

Acties:

DJ Buzzz

robbert schreef op maandag 07 mei 2007 @ 14:02:
[...]
sudo -s
is je vriend

Weet ik, maar dan is het hele nut van sudo gebruiken ook weg en kun je net zo goed gewoon een password op je root user zetten

. Ik gebruik trouwens wel gewoon sudo op m'n desktop machine, aangezien het aantal beheertaken daarop per dag op 1 hand te tellen is. Daarvoor vind ik het prima geschikt, maar als ik gewoon zonder problemen bij elke system wide config moet, services moet restarten of wat dan ook, dan kies ik voor een public / private key root login (tussen lokale machines onderling, niet direct vanaf internet toegankelijk natuurlijk).

maandag 7 mei 2007 14:38

Acties:

Ivo

Confusion schreef op zaterdag 05 mei 2007 @ 23:33:
Call me paranoid, maar belangrijke wachtwoorden ga ik dus niet door een applicatie in memory laten houden, met alle kans dat het een keer in de swap partititie of in /tmp terecht komt. M'n GoT login laat ik ook niet door Iceweasel cachen.

Heb je er al eens aan gedacht om je swap-partitie te versleutelen met een een-sessie-sleutel? OpenBSD doet dit standaard. In Debian Etch kun je dit in de installer configureren en met iets meer moeite achteraf. Als iemand hier meer over wil weten dan kan ik wel wat referenties geven.

maandag 7 mei 2007 14:39

Acties:

sam.vimes

Cyphax schreef op vrijdag 04 mei 2007 @ 09:56:
- Per IP regelen wie er wel en niet in mag verbinden (niet zozeer SSH zelf dan)
- Root-logins uitschakelen uiteraard
- Maximaal aantal pogingen voor je wachtwoord op 1 zetten
- SSH op een andere poort dan 22 draaien

IgnoreRhosts op yes
AllowUsers specificeren

zie man sshd_config.

maandag 7 mei 2007 15:25

Acties:

DJ Buzzz schreef op maandag 07 mei 2007 @ 14:38:
[...]

Weet ik, maar dan is het hele nut van sudo gebruiken ook weg en kun je net zo goed gewoon een password op je root user zetten . Ik gebruik trouwens wel gewoon sudo op m'n desktop machine, aangezien het aantal beheertaken daarop per dag op 1 hand te tellen is. Daarvoor vind ik het prima geschikt, maar als ik gewoon zonder problemen bij elke system wide config moet, services moet restarten of wat dan ook, dan kies ik voor een public / private key root login (tussen lokale machines onderling, niet direct vanaf internet toegankelijk natuurlijk).

Nee niet echt. Het nut van sudo is als je meerdere beheerders hebt. Al deze beheerders kunnen met hun eigen wachtwoord nu root worden. Als je een wachtwoord op het root account zet moet iedere beheerder dat wachtwoord weten.

maandag 7 mei 2007 15:26

Acties:

omdat het kan

dan is sudo inderdaad vrij makkelijk ja,

maandag 7 mei 2007 15:29

Acties:

DJ Buzzz

robbert schreef op maandag 07 mei 2007 @ 15:25:
[...]

Nee niet echt. Het nut van sudo is als je meerdere beheerders hebt. Al deze beheerders kunnen met hun eigen wachtwoord nu root worden. Als je een wachtwoord op het root account zet moet iedere beheerder dat wachtwoord weten.

Dat weet ik, maar daarom ook mijn suggestie in een eerder bericht dat ik dan voor public / private keys zou gaan

. Zo is niet 1 password het enige dat staat tussen een attacker en root access. Je kunt b.v. aparte keys voor user login en root login gebruiken met verschillende pass-phrases. Bij goed gebruikt van een agent levert dit in praktijk geen overbodige last op, maar biedt het toch een erg veilige oplossing.

maandag 7 mei 2007 15:39

Acties:

TheFirepit

Vuurbal

Thuis heb ik een setupje zo staan:

Vanuit de server naar naar buiten toe staat poort 80 open voor http verkeer en poort 22 voor ssh verkeer. Als je vanaf 'buiten' komt dan moet je op poort 443 ssh'en om de server te bereiken, de router zet het dan om naar poort 22. Root mag niet inloggen en heeft ook geen wachtwoord. Op de doos zelf kan je root worden door middel van 'sudo -i'.

Is dit een beetje een veilige setup?

It's nice to be important, but it's more important to be nice.

maandag 7 mei 2007 16:22

Acties:

Verwijderd

Boudewijn schreef op zondag 06 mei 2007 @ 21:53:
[...]
ik geloof btw dat deze discussie al 10.000x is gevoerd.

Waarom ga je m dan nog aan

Kwam net overigens wel dit document tegen, waarin vertelt wordt hoe je met PF (de beste packetfilter die er is

) jezelf kunt beschermen tegen brute-force's.

EngelF schreef op maandag 07 mei 2007 @ 15:39:
[...]
Is dit een beetje een veilige setup?

Zie ook de eerdere opmerkingen in dit topic. Zolang jij je software up-to-date houd is er niets aan de hand met je ssh setup (zelfs al zou je deze draaien op poort 22 waarbij je de hele wereld toegang verleent). Eg, jouw configuratie is dus veiliger dan "normaal" en dus goed. Nogmaals, zolang je niet iets hebt wat een attacker wilt hoef je je alleen te beschermen tegen brute-force attempts op poort 22...

[ Voor 39% gewijzigd door Verwijderd op 07-05-2007 17:07 ]

maandag 7 mei 2007 19:53

Acties:

omdat het kan

Verwijderd schreef op maandag 07 mei 2007 @ 16:22:
[...]

Waarom ga je m dan nog aan

Had niks beters te doen

Verwijderd schreef op maandag 07 mei 2007 @ 16:22:
Kwam net overigens wel dit document tegen, waarin vertelt wordt hoe je met PF (de beste packetfilter die er is ) jezelf kunt beschermen tegen brute-force's.

En waarom vind jij (!) pf het beste? Ik draai het hier nu ook en het is prima, maar ik vind je argumentatie een ietwat schamel.

dinsdag 8 mei 2007 10:34

Acties:

Verwijderd

Boudewijn schreef op maandag 07 mei 2007 @ 19:53:
[...]
En waarom vind jij (!) pf het beste? Ik draai het hier nu ook en het is prima, maar ik vind je argumentatie een ietwat schamel.

* Configuratie is duidelijk en wordt geschreven in "plain english" ipv bv iptables code
* Het heeft table support met expiration mogelijkheden
* Macro's bevatten modifiers (eg, $myif = fxp0; $myif:network zal adhv je netmask automatisch naar het juiste netwerk expanden; $myif zal adhv de context of het ip of de interface bevatten)
* Het kan de hoeveelheid hosts achter een nat setup verbergen (omdat dat rete handig kan zijn)
* pf-anchors voor gemakkelijke scripting van rules
* Mogelijkheid om netwerk verkeer te "normaliseren"
* Ingebouwde queueing
* Ingebouwde rate-limiting met eventuele automatische overloading naar tabellen
* Eenvoudige statetable manipulatie
* Ingebouwde ruleset optimalisatie
* Mogelijkheden om verkeer te loadbalancen over meerdere achterliggende hosts
* Fail-over cq clustered firewall setups icm gesyncde statetables
* Packet tagging en policy based routing
* Zeer uitgebreide documentatie, referenties en examples.
* Zet een nono achter een pf en een iptables ruleset en kijk welke hij/zij als eerste snapt

En zo zijn er nog een heleboel andere dingen die ik nu vergeet. Allemaal dingen die PF maken tot wat het is, en waar een heleboel andere packetfilter bouwers nog wat van kunnen leren =)

dinsdag 8 mei 2007 10:57

Acties:

Verwijderd

Zover ik weet is het zo'n beetje algemeen bekend dat pf de beste packetfilter is in de unix/linux wereld. Daar bestaan tientallen artikels en vergelijkende documenten over.

dinsdag 8 mei 2007 11:00

Acties:

Verwijderd

Verwijderd schreef op dinsdag 08 mei 2007 @ 10:57:
Zover ik weet is het zo'n beetje algemeen bekend dat pf de beste packetfilter is in de unix/linux wereld.

Jamaar, da's niet genoeg argumentatie voor Boudewijn, jeweettog

dinsdag 8 mei 2007 13:06

Acties: