|
|
 | synce htpasswd fil fra /etc/passwd filen ?
Fra : Jacob d'Andrade |
Dato : 07-02-06 17:03 |
|
Hej Ng
Er det muligt at finde et program der kan synkronisere passwords'ne i disse
to filer, således at når /etc/passwd passwordet bliver ændret at så
htpasswordet også bliver ændret... Ikke den anden vej rundt. ??
Dette er istedet for at bruge det apache modul der giver adgang til
etc/passwd.
Mvh Jacob
| |
 Jacob d'Andrade (08-02-2006)
| Kommentar
Fra : Jacob d'Andrade |
Dato : 08-02-06 08:53 |
|
Hej igen
Jeg har selv fundet løsningen, dog kun til RedHat hvor jeg er sikker på det
virker...
I RedHat er der nogle programmer der kan skifte password databasen fra
/etc/shadow til /etc/passwd
/usr/sbin/pwconv Konvetere adgangskoderne til shadow filen
/usr/sbin/pwunconv Konvetere adgangskoderne til etc/passwd filen
Det er selvfølgelig uklogt at beholde sine passwords i /etc/passwd da filen
skal være readable af everybody, derfor tænker jeg på at lave noget script
der konvetere databasen frem og tilbage en gang i døgnet og med noget grep,
hiver jeg brugernes passwords ud og gemmer i deres egne .htpasswd filer, og
derefter kører passwordene tilbage i /etc/shadow filen
Jacob
"Jacob d'Andrade" <jacob@removethezub.dk> skrev i en meddelelse
news:dsagc6$3r9$1@daniella.thezub.dk...
> Hej Ng
>
> Er det muligt at finde et program der kan synkronisere passwords'ne i
> disse to filer, således at når /etc/passwd passwordet bliver ændret at så
> htpasswordet også bliver ændret... Ikke den anden vej rundt. ??
>
> Dette er istedet for at bruge det apache modul der giver adgang til
> etc/passwd.
>
> Mvh Jacob
>
| |
Kent Friis (08-02-2006)
| Kommentar
Fra : Kent Friis |
Dato : 08-02-06 17:21 |
|
Den Wed, 8 Feb 2006 08:53:29 +0100 skrev Jacob d'Andrade:
> Hej igen
>
> Jeg har selv fundet løsningen, dog kun til RedHat hvor jeg er sikker på det
> virker...
>
> I RedHat er der nogle programmer der kan skifte password databasen fra
> /etc/shadow til /etc/passwd
>
> /usr/sbin/pwconv Konvetere adgangskoderne til shadow filen
> /usr/sbin/pwunconv Konvetere adgangskoderne til etc/passwd filen
>
> Det er selvfølgelig uklogt at beholde sine passwords i /etc/passwd da filen
> skal være readable af everybody,
Krypterer dit system ikke passwords'ne?
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
 Thorbjørn Ravn Ander~ (08-02-2006)
| Kommentar
Fra : Thorbjørn Ravn Ander~ |
Dato : 08-02-06 18:49 |
|
Kent Friis <nospam@nospam.invalid> writes:
> > Det er selvfølgelig uklogt at beholde sine passwords i /etc/passwd da filen
> > skal være readable af everybody,
>
> Krypterer dit system ikke passwords'ne?
Kan læses af alle, og herefter brydes.
Da jeg studerede, afværgede systemadministratoren et indbrud efter at
en passwordfil blev snuppet (kan ikke huske hvordan) fordi han havde
mere CPU-kraft at knække passwords med.
Der var mange brugere, så at skifte dem alle var ikke lige første
valg.
--
Thorbjørn Ravn Andersen
| |
Kent Friis (08-02-2006)
| Kommentar
Fra : Kent Friis |
Dato : 08-02-06 19:23 |
|
Den 08 Feb 2006 18:48:37 +0100 skrev Thorbjørn Ravn Andersen:
> Kent Friis <nospam@nospam.invalid> writes:
>
>> > Det er selvfølgelig uklogt at beholde sine passwords i /etc/passwd da filen
>> > skal være readable af everybody,
>>
>> Krypterer dit system ikke passwords'ne?
>
> Kan læses af alle, og herefter brydes.
Kender du en måde at bryde 3DES (eller nyere krypteringer - hvad bruger
distro'erne egentlig nutildags)?
Bruteforce virker naturligvis altid, men for det første behøver man
ikke nogen password-fil for det, og for det andet tager det alt for
lang tid.
Dictinary-attacks behøver man heller ikke den krypterede for at udføre.
> Da jeg studerede, afværgede systemadministratoren et indbrud efter at
> en passwordfil blev snuppet (kan ikke huske hvordan) fordi han havde
> mere CPU-kraft at knække passwords med.
>
> Der var mange brugere, så at skifte dem alle var ikke lige første
> valg.
Hvis det er muligt at bryde krypteringen, er det nødvendigt at skifte
dem alle.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Thorbjørn Ravn Ander~ (08-02-2006)
| Kommentar
Fra : Thorbjørn Ravn Ander~ |
Dato : 08-02-06 20:45 |
|
Kent Friis <nospam@nospam.invalid> writes:
> > Kan læses af alle, og herefter brydes.
>
> Kender du en måde at bryde 3DES (eller nyere krypteringer - hvad bruger
> distro'erne egentlig nutildags)?
Undersøg dét og meld tilbage.
Især i heterogene miljøer er man undertiden nødt til laveste
fællesnævner.
>
> Bruteforce virker naturligvis altid, men for det første behøver man
> ikke nogen password-fil for det, og for det andet tager det alt for
> lang tid.
>
> Dictinary-attacks behøver man heller ikke den krypterede for at
> udføre.
Hvordan vil du ellers kontrollere om det er rigtigt?
> Hvis det er muligt at bryde krypteringen, er det nødvendigt at skifte
> dem alle.
Nogen er nemmere at bryde end andre...
--
Thorbjørn Ravn Andersen
| |
Kent Friis (08-02-2006)
| Kommentar
Fra : Kent Friis |
Dato : 08-02-06 21:42 |
|
Den 08 Feb 2006 20:45:08 +0100 skrev Thorbjørn Ravn Andersen:
> Kent Friis <nospam@nospam.invalid> writes:
>
>> > Kan læses af alle, og herefter brydes.
>>
>> Kender du en måde at bryde 3DES (eller nyere krypteringer - hvad bruger
>> distro'erne egentlig nutildags)?
>
> Undersøg dét og meld tilbage.
Desværre, jeg har kun en oldgammel SuSE 7.0, og den bliver *ikke*
opgraderet (kan ikke fordrage de nye SuSE'er).
> Især i heterogene miljøer er man undertiden nødt til laveste
> fællesnævner.
Det er mange år siden jeg har hørt nogen der brugte mindre end 3DES.
>> Bruteforce virker naturligvis altid, men for det første behøver man
>> ikke nogen password-fil for det, og for det andet tager det alt for
>> lang tid.
>>
>> Dictinary-attacks behøver man heller ikke den krypterede for at
>> udføre.
>
> Hvordan vil du ellers kontrollere om det er rigtigt?
Det kan systemet klare for mig. Det kræver naturligvis at man gør
det på det system man vil angribe, (ellers skal man via netværket,
og der kan godt være nogen services der begrænser hastigheden
(ssh gør vist, jeg tror ikke telnet gør)). Men et job der arbejder
mellem klokken 02:00 og 06:00 er der ikke den store risiko for at
admin opdager.
>> Hvis det er muligt at bryde krypteringen, er det nødvendigt at skifte
>> dem alle.
>
> Nogen er nemmere at bryde end andre...
Så er vi ovre i held. Det tager *lang* tid at brute-force et password.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Thorbjørn Ravn Ander~ (08-02-2006)
| Kommentar
Fra : Thorbjørn Ravn Ander~ |
Dato : 08-02-06 22:00 |
|
Kent Friis <nospam@nospam.invalid> writes:
> > Hvordan vil du ellers kontrollere om det er rigtigt?
>
> Det kan systemet klare for mig. Det kræver naturligvis at man gør
> det på det system man vil angribe, (ellers skal man via netværket,
Åhja. Hvis vi nu går ud fra at du ikke har login på maskinen, men
nblot et krypteret password.
> og der kan godt være nogen services der begrænser hastigheden
> (ssh gør vist, jeg tror ikke telnet gør)). Men et job der arbejder
> mellem klokken 02:00 og 06:00 er der ikke den store risiko for at
> admin opdager.
Det kommer dæleme an på hvem admin'en er.
Havde jeg været fuldtidsadmin på en sådan installation (uafhængigt af
antal maskiner) havde der definitivt ligget en "God morgen, du skal
lige kigge på det her" i min indboks næste gang jeg kiggede.
Jeg har også kendt fuldtidsadminer der havde det med at prikke folk på
skulderen og spørge hvad de havde gang i, efter at have opdaget dem.
Det var rigtigt, rigtigt effektivt.
> >> Hvis det er muligt at bryde krypteringen, er det nødvendigt at skifte
> >> dem alle.
> >
> > Nogen er nemmere at bryde end andre...
>
> Så er vi ovre i held. Det tager *lang* tid at brute-force et password.
Kunsten er at tage de gode gæt først.
Læs eventuelt om Alec Muffets erfaringer hermed.
--
Thorbjørn Ravn Andersen
| |
Kent Friis (08-02-2006)
| Kommentar
Fra : Kent Friis |
Dato : 08-02-06 22:14 |
|
Den 08 Feb 2006 21:59:54 +0100 skrev Thorbjørn Ravn Andersen:
> Kent Friis <nospam@nospam.invalid> writes:
>
>> > Hvordan vil du ellers kontrollere om det er rigtigt?
>>
>> Det kan systemet klare for mig. Det kræver naturligvis at man gør
>> det på det system man vil angribe, (ellers skal man via netværket,
>
> Åhja. Hvis vi nu går ud fra at du ikke har login på maskinen, men
> nblot et krypteret password.
I den situation er det irrelevant om passwordet ligger i passwd
eller shadow. Det kan man alligevel ikke se uden adgang til maskinen.
>> og der kan godt være nogen services der begrænser hastigheden
>> (ssh gør vist, jeg tror ikke telnet gør)). Men et job der arbejder
>> mellem klokken 02:00 og 06:00 er der ikke den store risiko for at
>> admin opdager.
>
> Det kommer dæleme an på hvem admin'en er.
Det undersøger man self. først. Går han først i seng klokken
06:00, gør man det selvfølgelig imellem 7:00-11:00 
Derudover kan man naturligvis forklæde programmet som noget der
allerede bruger masser af CPU-tid. Fx havde jeg engang et program
til at beregne primtal, det kunne sagtens bruge 100% CPU i flere
timer (for et par mia. primtal). At forklæde den som et seti@home-
program (naturligvis med korrekt nice), kan også være effektivt.
>> >> Hvis det er muligt at bryde krypteringen, er det nødvendigt at skifte
>> >> dem alle.
>> >
>> > Nogen er nemmere at bryde end andre...
>>
>> Så er vi ovre i held. Det tager *lang* tid at brute-force et password.
>
> Kunsten er at tage de gode gæt først.
Ah, fætter Højben metoden...
Hmm, mon ikke det er "h7g3fx4a"?
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Hans Joergensen (08-02-2006)
| Kommentar
Fra : Hans Joergensen |
Dato : 08-02-06 22:37 |
|
Kent Friis wrote:
> Hmm, mon ikke det er "h7g3fx4a"?
Man starter bare med en god ordbog.. der er stort set altid
gevinst.
// Hans
--
Jeg beskyttes IKKE af den gratis SPAMFighter til privatbrugere, der
har spammet usenet i over 6000 indlæg.
| |
Kent Friis (08-02-2006)
| Kommentar
Fra : Kent Friis |
Dato : 08-02-06 22:40 |
|
Den 08 Feb 2006 21:36:52 GMT skrev Hans Joergensen:
> Kent Friis wrote:
>> Hmm, mon ikke det er "h7g3fx4a"?
>
> Man starter bare med en god ordbog.. der er stort set altid
> gevinst.
Ikke hvor brugerne har lært at vælge ordentlige passwords. Og
heller ikke der hvor de ikke får noget valg (gjorde vi fx ikke
på datamatiker, vi fik udleveret et stykke papir med en række
tal og bogstaver).
Men uanset, så er vi ovre i dictinary-attacks, som vi allerede
har diskuteret en gang. Bare den manuelle udgave. Og hvis man gætter
rigtigt første gang, kan jeg da slet ikke se hvordan shadow-filen
skulle forhindre det.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Hans Joergensen (08-02-2006)
| Kommentar
Fra : Hans Joergensen |
Dato : 08-02-06 21:04 |
|
Kent Friis wrote:
> Bruteforce virker naturligvis altid, men for det første behøver man
> ikke nogen password-fil for det, og for det andet tager det alt for
> lang tid.
Det går _VÆSENTLIGT_ hurtigere når man har password og shadowfil
Hvis man ikke har dem er fremgangsmetoden at angribe en service man
så skal vente på.
// Hans
--
Jeg beskyttes IKKE af den gratis SPAMFighter til privatbrugere, der
har spammet usenet i over 6000 indlæg.
| |
Kent Friis (08-02-2006)
| Kommentar
Fra : Kent Friis |
Dato : 08-02-06 21:46 |
|
Den 08 Feb 2006 20:03:57 GMT skrev Hans Joergensen:
> Kent Friis wrote:
>> Bruteforce virker naturligvis altid, men for det første behøver man
>> ikke nogen password-fil for det, og for det andet tager det alt for
>> lang tid.
>
> Det går _VÆSENTLIGT_ hurtigere når man har password og shadowfil
>
> Hvis man ikke har dem er fremgangsmetoden at angribe en service man
> så skal vente på.
Hvis "servicen" er skrevet af en programmør der er lige så dygtig som
ham der har lavet bruteforce-programmet, bør den kunne checke et
password lige så hurtigt[1]. Der kan så være indbygget bevidste
forsinkelser, men så er må man sørge for at benytte en der ikke
har disse forsinkelser, eller omgå dem på anden vis (fx ved at
checke parralelt).
Mvh
Kent
[1] Der er vist noget med at der kan optimeres noget på DES, hvis
man ved at det kun er en bit der ændrer sig ad gangen.
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Leif Neland (09-02-2006)
| Kommentar
Fra : Leif Neland |
Dato : 09-02-06 08:57 |
|
Kent Friis wrote:
> Den 08 Feb 2006 20:03:57 GMT skrev Hans Joergensen:
>> Kent Friis wrote:
>>> Bruteforce virker naturligvis altid, men for det første behøver man
>>> ikke nogen password-fil for det, og for det andet tager det alt for
>>> lang tid.
>>
>> Det går _VÆSENTLIGT_ hurtigere når man har password og shadowfil
>>
>> Hvis man ikke har dem er fremgangsmetoden at angribe en service man
>> så skal vente på.
>
> Hvis "servicen" er skrevet af en programmør der er lige så dygtig som
> ham der har lavet bruteforce-programmet, bør den kunne checke et
> password lige så hurtigt[1]. Der kan så være indbygget bevidste
> forsinkelser, men så er må man sørge for at benytte en der ikke
> har disse forsinkelser, eller omgå dem på anden vis (fx ved at
> checke parralelt).
>
Der er mere risikabelt at "ruske i døren" en milliard million gange, end at
sidde med det krypterede password derhjemme, og bruge sin egen (eller
zombier's) maskinkraft til at knække det, og så først snige sig ind, når man
har det.
Alle de indbrudsforsøg burde vise sig i en log, så admin'en blev opmærksom
på det.
Men, problemet med at benytte de samme /etc/password til .htaccess er, at
webserveren oftest ikke har noget delay eller shutdown efter (formange)
forkerte passwords.
Det er mere almindelig på ssh.
Ftp afbryder også efter et par gange.
Jeg enablede lige min telnetd, og der kunne jeg taste lige så mange forkerte
login/passwords så hurtigt jeg kunne, uden af den lukkede ned. Nu er den
disablet igen
Leif
| |
Kent Friis (09-02-2006)
| Kommentar
Fra : Kent Friis |
Dato : 09-02-06 17:23 |
|
Den Thu, 9 Feb 2006 08:57:04 +0100 skrev Leif Neland:
> Kent Friis wrote:
>> Den 08 Feb 2006 20:03:57 GMT skrev Hans Joergensen:
>>> Kent Friis wrote:
>>>> Bruteforce virker naturligvis altid, men for det første behøver man
>>>> ikke nogen password-fil for det, og for det andet tager det alt for
>>>> lang tid.
>>>
>>> Det går _VÆSENTLIGT_ hurtigere når man har password og shadowfil
>>>
>>> Hvis man ikke har dem er fremgangsmetoden at angribe en service man
>>> så skal vente på.
>>
>> Hvis "servicen" er skrevet af en programmør der er lige så dygtig som
>> ham der har lavet bruteforce-programmet, bør den kunne checke et
>> password lige så hurtigt[1]. Der kan så være indbygget bevidste
>> forsinkelser, men så er må man sørge for at benytte en der ikke
>> har disse forsinkelser, eller omgå dem på anden vis (fx ved at
>> checke parralelt).
>>
>
> Der er mere risikabelt at "ruske i døren" en milliard million gange, end at
> sidde med det krypterede password derhjemme, og bruge sin egen (eller
> zombier's) maskinkraft til at knække det, og så først snige sig ind, når man
> har det.
>
> Alle de indbrudsforsøg burde vise sig i en log, så admin'en blev opmærksom
> på det.
>
> Men, problemet med at benytte de samme /etc/password til .htaccess er, at
> webserveren oftest ikke har noget delay eller shutdown efter (formange)
> forkerte passwords.
> Det er mere almindelig på ssh.
> Ftp afbryder også efter et par gange.
> Jeg enablede lige min telnetd, og der kunne jeg taste lige så mange forkerte
> login/passwords så hurtigt jeg kunne, uden af den lukkede ned. Nu er den
> disablet igen
Nu du er igang, så prøv /sbin/unix_chkpwd (er en del af PAM systemet).
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
| |
Jacob d'Andrade (18-02-2006)
| Kommentar
Fra : Jacob d'Andrade |
Dato : 18-02-06 12:43 |
|
"Kent Friis" <nospam@nospam.invalid> skrev i en meddelelse
news:43ea1a80$0$15783$14726298@news.sunsite.dk...
> Den Wed, 8 Feb 2006 08:53:29 +0100 skrev Jacob d'Andrade:
>> Hej igen
>>
>> Jeg har selv fundet løsningen, dog kun til RedHat hvor jeg er sikker på
>> det
>> virker...
>>
>> I RedHat er der nogle programmer der kan skifte password databasen fra
>> /etc/shadow til /etc/passwd
>>
>> /usr/sbin/pwconv Konvetere adgangskoderne til shadow filen
>> /usr/sbin/pwunconv Konvetere adgangskoderne til etc/passwd filen
>>
>> Det er selvfølgelig uklogt at beholde sine passwords i /etc/passwd da
>> filen
>> skal være readable af everybody,
>
> Krypterer dit system ikke passwords'ne?
Jo, men de to programmer der er i redhat må lave krypteringen om, for når
passworde'ne er i /etc/passwd, har de samme format som htpasswd programmet
laver, jeg kører selvfølgelig dem tilbage i shadow filen lige efter...
jacob
| |
Klaus Ellegaard (09-02-2006)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 09-02-06 09:09 |
|
"Jacob d'Andrade" <jacob@removethezub.dk> writes:
>Er det muligt at finde et program der kan synkronisere passwords'ne i disse
>to filer, således at når /etc/passwd passwordet bliver ændret at så
>htpasswordet også bliver ændret... Ikke den anden vej rundt. ??
Hvad med http://pam.sourceforge.net/mod_auth_pam/ ?
Det løser også udfordringen, Leif Neland omtaler mht. logging og
konsekvens af mange forkerte password-forsøg.
Mvh.
Klaus.
| |
|
|