---

Jeg vil gerne via en skjult side på min apache have mulighed for at køre
et program - som root. Har rodet lidt med cgi-bin scripts, men kan ikke
få apache til at afvikle det - får en Internal Server Error. Forsøger
jeg mig via et perl script går det lidt bedre, men jeg kan ikke finde ud
af perl kommandoen for at afvikle mit program. Jeg antager desuden der
skal skal være

S_ISUID 04000 set user ID on execution

sat på filen ? Er det rigtigt- og er der andet ?

PS Ved godt at det sikkerhedsmæssigt ikke er godt, men tanken er at min
sshd normalt ikke er kørende, men jeg via en skjult side kan starte den
op. Jeg er bare træt af at halvdelen af min syslog er dårlige forsøg på
at komme ind.

Jørn

---

Den Sun, 16 Apr 2006 10:42:21 +0200 skrev Jørn Hundebøll:
> Jeg vil gerne via en skjult side på min apache have mulighed for at køre
> et program - som root. Har rodet lidt med cgi-bin scripts, men kan ikke
> få apache til at afvikle det - får en Internal Server Error. Forsøger
> jeg mig via et perl script går det lidt bedre, men jeg kan ikke finde ud
> af perl kommandoen for at afvikle mit program. Jeg antager desuden der
> skal skal være
>
> S_ISUID 04000 set user ID on execution
>
> sat på filen ? Er det rigtigt- og er der andet ?
>
> PS Ved godt at det sikkerhedsmæssigt ikke er godt, men tanken er at min
> sshd normalt ikke er kørende, men jeg via en skjult side kan starte den
> op. Jeg er bare træt af at halvdelen af min syslog er dårlige forsøg på
> at komme ind.

For at starte sshd skal man normalt være root. Dvs. du skal have
din webserver til at køre ting som root - hvor mange sekunder tror
du der går før nogen finder din "skjulte" side, og er inde som root?

Det er nok nemmere bare at fjerne root-passwordet, og sætte ssh til
at tillade at man logger ind uden password. Så ser du heller ikke alle
de forsøg, de stopper lige så snart folk opdager hvor nemt det er at
komme ind.

I stedet for at åbne jordens største sikkerhedshul i webserveren, ville
jeg nok overveje en af følgende løsninger:

1. Begræns adgangen til ssh til ip-numre du logger ind fra, enten via
hosts.deny og hosts.allow, eller iptables.

2. Er det helt umuligt (fordi du ikke ved på forhånd hvornår du logger
ind fra kina), så sæt en LIMIT-regel op i iptables, og begræns den til
fx tre forsøg i minuttet.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Den Sun, 16 Apr 2006 10:42:21 +0200 skrev Jørn Hundebøll:
>
>>Jeg vil gerne via en skjult side på min apache have mulighed for at køre
>>et program - som root. Har rodet lidt med cgi-bin scripts, men kan ikke
>>få apache til at afvikle det - får en Internal Server Error. Forsøger
>>jeg mig via et perl script går det lidt bedre, men jeg kan ikke finde ud
>>af perl kommandoen for at afvikle mit program. Jeg antager desuden der
>>skal skal være
>>
>>S_ISUID 04000 set user ID on execution
>>
>>sat på filen ? Er det rigtigt- og er der andet ?
>>
>>PS Ved godt at det sikkerhedsmæssigt ikke er godt, men tanken er at min
>>sshd normalt ikke er kørende, men jeg via en skjult side kan starte den
>>op. Jeg er bare træt af at halvdelen af min syslog er dårlige forsøg på
>>at komme ind.
>
>
> For at starte sshd skal man normalt være root. Dvs. du skal have
> din webserver til at køre ting som root - hvor mange sekunder tror
> du der går før nogen finder din "skjulte" side, og er inde som root?

Ja, men ved at sætte en "set user ID on execution" på sshd kan jeg undgå
apache skal køre som root.

>
> Det er nok nemmere bare at fjerne root-passwordet, og sætte ssh til
> at tillade at man logger ind uden password. Så ser du heller ikke alle
> de forsøg, de stopper lige så snart folk opdager hvor nemt det er at
> komme ind.

Rolig nu.

>
> I stedet for at åbne jordens største sikkerhedshul i webserveren, ville
> jeg nok overveje en af følgende løsninger:
>
> 1. Begræns adgangen til ssh til ip-numre du logger ind fra, enten via
> hosts.deny og hosts.allow, eller iptables.

Det ændre stadig ikke på antallet af logs i syslog, og jeg har desuden
allerede fjernet muligheden for at logge ind som root via ssh.

>
> 2. Er det helt umuligt (fordi du ikke ved på forhånd hvornår du logger
> ind fra kina), så sæt en LIMIT-regel op i iptables, og begræns den til
> fx tre forsøg i minuttet.

Jeg har ikke iptables kørende.

Jørn

---

Den Sun, 16 Apr 2006 11:06:43 +0200 skrev Jørn Hundebøll:
> Kent Friis wrote:
>> Den Sun, 16 Apr 2006 10:42:21 +0200 skrev Jørn Hundebøll:
>>
>>
>> I stedet for at åbne jordens største sikkerhedshul i webserveren, ville
>> jeg nok overveje en af følgende løsninger:
>>
>> 1. Begræns adgangen til ssh til ip-numre du logger ind fra, enten via
>> hosts.deny og hosts.allow, eller iptables.
>
> Det ændre stadig ikke på antallet af logs i syslog,

Hvorfor skulle det ikke ændre antallet af logs at du begrænser hvem
der kan lave de forsøg der giver logs'ene?

> og jeg har desuden
> allerede fjernet muligheden for at logge ind som root via ssh.
>
>>
>> 2. Er det helt umuligt (fordi du ikke ved på forhånd hvornår du logger
>> ind fra kina), så sæt en LIMIT-regel op i iptables, og begræns den til
>> fx tre forsøg i minuttet.
>
> Jeg har ikke iptables kørende.

iptables er en kommando der sætter nogen regler op i kernen.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

>>>2. Er det helt umuligt (fordi du ikke ved på forhånd hvornår du logger
>>>ind fra kina), så sæt en LIMIT-regel op i iptables, og begræns den til
>>>fx tre forsøg i minuttet.
>>

>
>
> iptables er en kommando der sætter nogen regler op i kernen.
>

Hvis du har kommandoen til at begrænse antal login forsøg til 3 per
minut vil jeg gerne starte med at prøve det først - det lyder som en nem
og sikker løsning.

Jørn

---

Den Sun, 16 Apr 2006 11:25:02 +0200 skrev Jørn Hundebøll:
>
>>>>2. Er det helt umuligt (fordi du ikke ved på forhånd hvornår du logger
>>>>ind fra kina), så sæt en LIMIT-regel op i iptables, og begræns den til
>>>>fx tre forsøg i minuttet.
>>>
>
>>
>>
>> iptables er en kommando der sætter nogen regler op i kernen.
>>
>
> Hvis du har kommandoen til at begrænse antal login forsøg til 3 per
> minut vil jeg gerne starte med at prøve det først - det lyder som en nem
> og sikker løsning.

Det må være noget i retning af:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit ! --limit 3/minute -j DROP

Forklaring:

-A INPUT: Add (tilføj) en input regel.
-p tcp: protocol = TCP
--dport 22: destination port = ssh

-m state: Brug modul: statefull inspection
--state NEW: Kun nye forbindelser.

-m limit: Brug modul: limit
!: Not (undtagen)
--limit 3/minute: 3 pakker per minut.
-j DROP: Smid dem væk.

Altså, smid alt undtagen de første tre nye connections per minut væk.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Den Sun, 16 Apr 2006 11:25:02 +0200 skrev Jørn Hundebøll:
>
>>>>>2. Er det helt umuligt (fordi du ikke ved på forhånd hvornår du logger
>>>>>ind fra kina), så sæt en LIMIT-regel op i iptables, og begræns den til
>>>>>fx tre forsøg i minuttet.
>>>>
>>>
>>>iptables er en kommando der sætter nogen regler op i kernen.
>>>
>>
>>Hvis du har kommandoen til at begrænse antal login forsøg til 3 per
>>minut vil jeg gerne starte med at prøve det først - det lyder som en nem
>>og sikker løsning.
>
>
> Det må være noget i retning af:
>
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit ! --limit 3/minute -j DROP
>

Øhh, synes ikke lige det virker - nu er det slet ikke muligt at få ssh
adgang til maskinen. Hvordan "resetter" man en iptables kommando, og kan
der være en fejl i linien herover ?

Jørn

---

Den Sun, 16 Apr 2006 11:46:00 +0200 skrev Jørn Hundebøll:
> Kent Friis wrote:
>> Den Sun, 16 Apr 2006 11:25:02 +0200 skrev Jørn Hundebøll:
>>
>>>>>>2. Er det helt umuligt (fordi du ikke ved på forhånd hvornår du logger
>>>>>>ind fra kina), så sæt en LIMIT-regel op i iptables, og begræns den til
>>>>>>fx tre forsøg i minuttet.
>>>>>
>>>>
>>>>iptables er en kommando der sætter nogen regler op i kernen.
>>>>
>>>
>>>Hvis du har kommandoen til at begrænse antal login forsøg til 3 per
>>>minut vil jeg gerne starte med at prøve det først - det lyder som en nem
>>>og sikker løsning.
>>
>>
>> Det må være noget i retning af:
>>
>> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit ! --limit 3/minute -j DROP
>>
>
> Øhh, synes ikke lige det virker - nu er det slet ikke muligt at få ssh
> adgang til maskinen. Hvordan "resetter" man en iptables kommando, og kan
> der være en fejl i linien herover ?

Skift -A (add) ud med -D (delete).

Alternativt kan man bruge -D 1, for at slette regel nummer 1, men hvis
man tager hele linien igen med -D, kan den selv finde den rigtige
regel.

Der kan i princippet godt være en fejl, men jeg kan ikke lige se hvad
det skulle være

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

>>Øhh, synes ikke lige det virker - nu er det slet ikke muligt at få ssh
>>adgang til maskinen. Hvordan "resetter" man en iptables kommando, og kan
>>der være en fejl i linien herover ?
>
>
> Skift -A (add) ud med -D (delete).

Nu er da igen hul igennem til ssh. Men jeg vil stadig være meget
interesseret i en fungerende linie til at begrænse antallet af login
forsøg per minut.

Jørn

---

Den Sun, 16 Apr 2006 11:46:00 +0200 skrev Jørn Hundebøll:
> Kent Friis wrote:
>> Den Sun, 16 Apr 2006 11:25:02 +0200 skrev Jørn Hundebøll:
>>
>>>>>>2. Er det helt umuligt (fordi du ikke ved på forhånd hvornår du logger
>>>>>>ind fra kina), så sæt en LIMIT-regel op i iptables, og begræns den til
>>>>>>fx tre forsøg i minuttet.
>>>>>
>>>>
>>>>iptables er en kommando der sætter nogen regler op i kernen.
>>>>
>>>
>>>Hvis du har kommandoen til at begrænse antal login forsøg til 3 per
>>>minut vil jeg gerne starte med at prøve det først - det lyder som en nem
>>>og sikker løsning.
>>
>>
>> Det må være noget i retning af:
>>
>> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit ! --limit 3/minute -j DROP
>>
>
> Øhh, synes ikke lige det virker - nu er det slet ikke muligt at få ssh
> adgang til maskinen. Hvordan "resetter" man en iptables kommando, og kan
> der være en fejl i linien herover ?

Hmm, ! virker åbenbart ikke på limit, selvom den står nævnt i manualen.
Så må reglen jo deles i to:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/minute -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j DROP

Altså: Accepter (modtag) de første tre connections per minut, og smid
resten væk.

Der er iøvrigt en detalje der hedder --limit-burst, der default står
til 5, så det første minut vil de få log til fem forsøg. Den kan du
evt. lege med også...

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

>
> Hmm, ! virker åbenbart ikke på limit, selvom den står nævnt i manualen.
> Så må reglen jo deles i to:
>
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/minute -j ACCEPT
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j DROP
>
> Altså: Accepter (modtag) de første tre connections per minut, og smid
> resten væk.

Det ser ud som det virker - selvom man i den anden ende får lov til at
prøve mange gang I logfilen skriver den :

service(sshd) ignoring max retries; 4 > 3

antager det er reglen som komme i brug her. Og jo, jeg har forsøgt at
logge ind på maskinen fra en helt anden maskine, som ikke er på samme
sub-net overhovedet.

Jeg takker - og skal måske til at lege lidt med iptables - nu jeg ved
hvordan man "kommer tilbage". Men en reboot af maskinen vil vel også
nulstille alle regler ?

Jørn

---

Den Sun, 16 Apr 2006 12:06:30 +0200 skrev Jørn Hundebøll:
>
>>
>> Hmm, ! virker åbenbart ikke på limit, selvom den står nævnt i manualen.
>> Så må reglen jo deles i to:
>>
>> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/minute -j ACCEPT
>> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j DROP
>>
>> Altså: Accepter (modtag) de første tre connections per minut, og smid
>> resten væk.
>
> Det ser ud som det virker - selvom man i den anden ende får lov til at
> prøve mange gang

Er det ikke bare de 5 i brust-limit? De kan også sættes ned.

> I logfilen skriver den :
>
> service(sshd) ignoring max retries; 4 > 3

Hmm, det ligner ikke en typisk iptables log-besked den der.

> antager det er reglen som komme i brug her. Og jo, jeg har forsøgt at
> logge ind på maskinen fra en helt anden maskine, som ikke er på samme
> sub-net overhovedet.

Der er ingen regel i ovenstående om sub-net. Selv localhost er
begrænset.

I nyere kerner (2.6.16+) er der en der hedder hashlimit, den skulle
(hvis jeg har forstået det rigtigt) begrænse det til tre i minuttet
per ip-nummer, så du ikke risikerer selv at blive lukket ude fordi
andre allerede har brugt de tre forsøg.

> Jeg takker - og skal måske til at lege lidt med iptables - nu jeg ved
> hvordan man "kommer tilbage". Men en reboot af maskinen vil vel også
> nulstille alle regler ?

Ja, for at have reglerne fast ved boot, skal de gemmes et eller andet
sted. Hvor det er bedst at gemme dem afhænger af hvilken distro du
bruger.

En helt anden mulighed er iøvrigt at sætte "LogLevel ERROR" i
sshd_config (eller FATAL eller QUIET), for at få den til ikke at
logge hver eneste forsøg. Jeg kan dog ikke finde en mulighed for
at logge successfulde logins, men ikke mislykkede forsøg.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Jørn Hundebøll wrote:
> antager det er reglen som komme i brug her. Og jo, jeg har forsøgt at
> logge ind på maskinen fra en helt anden maskine, som ikke er på samme
> sub-net overhovedet.

Pas nu på Jørn, det ender med du ikke selv må logge på maskinen,
fordi angriberne trigger DROP reglen :)

Er det ikke nemmer at tillade den IP du normalt kommer fra, at
køre ssh eller slå password valideringen fra, og køre med DSA,
eller RSA?

---

Christian E. Lysel wrote:
> Jørn Hundebøll wrote:
> > antager det er reglen som komme i brug her. Og jo, jeg har forsøgt at
> > logge ind på maskinen fra en helt anden maskine, som ikke er på samme
> > sub-net overhovedet.
>
> Pas nu på Jørn, det ender med du ikke selv må logge på maskinen,
> fordi angriberne trigger DROP reglen :)
>
> Er det ikke nemmer at tillade den IP du normalt kommer fra, at
> køre ssh eller slå password valideringen fra, og køre med DSA,
> eller RSA?

Det er mere sådan at jeg gerne vil have muligheden for at kunne logge på
hos en kammerat uden på forhånd at have hans IP (det er måske 1 gang
hvert andet år - men principielt). Ved at kunne starte sshd ved at tilgå
en skjult side på serveren, kunne jeg logge ind. I de 5-6 år jeg har
haft serveren kørende 24-7 har jeg ikke haft gæster (å vidt vides), dels
ved at forhindre root-login og ved at vælge gode passwords, og holde
systemet opdateret. Det eneste jeg vil opnå ved at "slukke" for sshd og
kun starte den efter behov er at yderligere styrke sikkerheden, og
reducere antallet af events i syslog, da ca. halvdelen af min syslog er
mislykkede forsøg på at logge ind via ssh. Jeg har dog ikke fået det til
at virke - (vil egentligt gerne stadig vide hvordan man gør), men prøver
i stedet nogle iptables kommandoer fra Kent - hvilket dog ikke helt
opfylder mine ønsker.

Jørn

---

Jørn Hundebøll wrote:
> Det eneste jeg vil opnå ved at "slukke" for sshd og
> kun starte den efter behov er at yderligere styrke sikkerheden, og
> reducere antallet af events i syslog, da ca. halvdelen af min syslog er
> mislykkede forsøg på at logge ind via ssh.

Det forbedrer bestemt ikke din sikkerhed, at have apache kørende. sshd
er langt mere modstandsdygtig end apache nogensinde bliver.

Hvorfor er disse beskeder så stort et problem, at du vil køre apache og
give den mulighed for at starte en suid root binary?

Kan du ikke blot lære din log analyser at se bort fra beskederne?

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

---

Den Mon, 17 Apr 2006 02:31:34 +0200 skrev Alex Holst:
> Jørn Hundebøll wrote:
>> Det eneste jeg vil opnå ved at "slukke" for sshd og
>> kun starte den efter behov er at yderligere styrke sikkerheden, og
>> reducere antallet af events i syslog, da ca. halvdelen af min syslog er
>> mislykkede forsøg på at logge ind via ssh.
>
> Det forbedrer bestemt ikke din sikkerhed, at have apache kørende. sshd
> er langt mere modstandsdygtig end apache nogensinde bliver.
>
> Hvorfor er disse beskeder så stort et problem, at du vil køre apache og
> give den mulighed for at starte en suid root binary?
>
> Kan du ikke blot lære din log analyser at se bort fra beskederne?

Nu du er her og læser med i tråden - jeg kunne ikke finde en mulighed
for at sætte sshd op til kun at logge successfulde logins. Ved du
om man kan det?

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Nu du er her og læser med i tråden - jeg kunne ikke finde en mulighed
> for at sætte sshd op til kun at logge successfulde logins. Ved du
> om man kan det?

Jeg mener at alle log requests i auth.c bliver sendt gennem den samme
funktion, der logger til LOG_AUTH med prioritet LOG_INFO, så nej.

Jeg anbefaler i stedet at man logger til f.eks. /var/log/sshd i stedet
for authlog (så resten af indholdet i authlog ikke drukner) og lader log
analyseren lave et udtræk af de data man skal bruge.

I den aktuelle situation er denne patch heller ikke helt dum:

   http://jcs.org/patches/sshd-drop_brute_force.diff


--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

---

Alex Holst wrote:
> Det forbedrer bestemt ikke din sikkerhed, at have apache kørende. sshd
> er langt mere modstandsdygtig end apache nogensinde bliver.

Det er selvfølgelig forudsat han ikke oprindeligt havde brug for
en webserver.

---

Jørn Hundebøll wrote:
> hvert andet år - men principielt). Ved at kunne starte sshd ved at tilgå
> en skjult side på serveren, kunne jeg logge ind. I de 5-6 år jeg har

Installere sudo pakken.

Opret en bruger uden rettigheder, med navnet startssh

Tilføj følgende til /etc/sudoers

startssh ALL= NOPASSWD: /etc/init.d/sshd start


Nu kan startssh brugeren køre "sudo /etc/init.d/sshd start", og
få kørt "/etc/init.d/sshd start" som root.



Tilføj følgende til startssh's crontab, hvis checket skal køre hvert minut:

* * * * * tail -100 /var/log/httpd/access.log |
grep -q 'start ssh' && sudo /etc/init.d/sshd start


Det kan evt. målrettes bedre hvis man siger at apache's
tidslog er i følgende format "[06/Apr/2006:20:20:21 +0200]"

* * * * * tail -100 /var/log/httpd/access.log |
grep `date +%d/%b/%y:%H:%M` |
grep -q 'start ssh' && sudo /etc/init.d/sshd start

Her søger vi efter de sidste 100 linier i loggen der indeholde et
tidsstemple i formatet "06/Apr/2006:20:20".

Skru evt. "tail -100" op til fx "tail -1000", hvis du har meget
aktivitet på webserveren. Tallet angiver ca. antallet af hit pr. minut.

Når du kalder en url på din webserver med ordet "start ssh", vil din
ssh daemon starte inden for et minut.

---

> Når du kalder en url på din webserver med ordet "start ssh", vil din
> ssh daemon starte inden for et minut.
>
Takker !

---

Den Mon, 17 Apr 2006 15:08:42 +0200 skrev Christian E. Lysel:
>
> Tilføj følgende til startssh's crontab, hvis checket skal køre hvert minut:
>
> * * * * * tail -100 /var/log/httpd/access.log |
> grep -q 'start ssh' && sudo /etc/init.d/sshd start

Snedig løsning, den undgår problemerne med at lade enhver idiot
med en webbrowser få adgang til at køre scripts som root. Den burde
dermed være noget mere sikker.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Den Mon, 17 Apr 2006 00:17:12 +0200 skrev Christian E. Lysel:
> Jørn Hundebøll wrote:
> > antager det er reglen som komme i brug her. Og jo, jeg har forsøgt at
> > logge ind på maskinen fra en helt anden maskine, som ikke er på samme
> > sub-net overhovedet.
>
> Pas nu på Jørn, det ender med du ikke selv må logge på maskinen,
> fordi angriberne trigger DROP reglen :)
>
> Er det ikke nemmer at tillade den IP du normalt kommer fra, at
> køre ssh eller slå password valideringen fra, og køre med DSA,
> eller RSA?

Public key auth hjælper ikke på log-filen.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Public key auth hjælper ikke på log-filen.

Jo. På Fedora blive PAM slet ikke kaldt.

Ret /etc/ssh/sshd_config til

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no

Giver følgende logfiler for en eksisterne bruger (user):

Apr 17 13:45:47 bigfoot sshd[3474]: Received disconnect from
10.11.87.208: 11: No supported authentication methods available

Og for en ikke eksisterne bruger (test):

Apr 17 15:45:57 bigfoot sshd[3476]: Invalid user test from 1.2.3.4
Apr 17 13:45:57 bigfoot sshd[3477]: input_userauth_request: invalid user
test
Apr 17 13:45:57 bigfoot sshd[3477]: Failed none for invalid user test
from 1.2.3.4 port 2462 ssh2
Apr 17 13:45:57 bigfoot sshd[3477]: Received disconnect from 1.2.3.4:
11: No supported authentication methods available

Men "PasswordAuthentication yes", giver følgende for en eksisterne bruger:

Apr 17 15:44:46 bigfoot sshd[3439]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=speedy user=user
Apr 17 15:44:48 bigfoot sshd[3439]: Failed password for user from
1.2.3.4 port 2456 ssh2
Apr 17 13:44:48 bigfoot sshd[3440]: Failed password for user from
1.2.3.4 port 2456 ssh2
Apr 17 13:44:49 bigfoot sshd[3440]: Connection closed by 1.2.3.4

Og for en ikke eksisterne bruger:

Apr 17 15:45:01 bigfoot sshd[3442]: Invalid user test from 1.2.3.4
Apr 17 13:45:01 bigfoot sshd[3443]: input_userauth_request: invalid user
test
Apr 17 13:45:01 bigfoot sshd[3443]: Failed none for invalid user test
from 1.2.3.4 port 2457 ssh2
Apr 17 15:45:04 bigfoot sshd[3442]: pam_unix(sshd:auth): check pass;
user unknown
Apr 17 15:45:04 bigfoot sshd[3442]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=speedy
Apr 17 15:45:04 bigfoot sshd[3442]: pam_succeed_if(sshd:auth): error
retrieving information about user test
Apr 17 15:45:06 bigfoot sshd[3442]: Failed password for invalid user
test from 1.2.3.4 port 2457 ssh2
Apr 17 13:45:06 bigfoot sshd[3443]: Failed password for invalid user
test from 1.2.3.4 port 2457 ssh2
Apr 17 13:45:06 bigfoot sshd[3443]: Failed none for invalid user test
from 1.2.3.4 port 2457 ssh2
Apr 17 13:45:07 bigfoot sshd[3443]: Connection closed by 1.2.3.4


Endvidere smider "PasswordAuthentication no" TCP sessionen i det øjeblik
den ser klienten køre med password validering.

---

Christian E. Lysel wrote:
> # To disable tunneled clear text passwords, change to no here!
> PasswordAuthentication no
>
> Giver følgende logfiler for en eksisterne bruger (user):
>
> Apr 17 13:45:47 bigfoot sshd[3474]: Received disconnect from
> 10.11.87.208: 11: No supported authentication methods available

Også når klienten i den anden ende ikke opfører sig pænt? (F.eks.
forsøger password auth, selvom serveren siger at den ikke tilbyder det?)

> Endvidere smider "PasswordAuthentication no" TCP sessionen i det øjeblik
> den ser klienten køre med password validering.

Det har jeg aldrig oplevet, og jeg kan heller ikke finde tegn på det i
sshds kode. Er det noget sshd-portable eller PAM gør?

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

---

Alex Holst wrote:
>> Apr 17 13:45:47 bigfoot sshd[3474]: Received disconnect from
>> 10.11.87.208: 11: No supported authentication methods available
> Også når klienten i den anden ende ikke opfører sig pænt? (F.eks.
> forsøger password auth, selvom serveren siger at den ikke tilbyder det?)

Nej. Klienten jeg testede med lukkede (FIN) selv TCP sessionen og ikke
serveren som jeg skrev.

>> Endvidere smider "PasswordAuthentication no" TCP sessionen i det øjeblik
>> den ser klienten køre med password validering.
> Det har jeg aldrig oplevet, og jeg kan heller ikke finde tegn på det i
> sshds kode. Er det noget sshd-portable eller PAM gør?

Nej, glem det.

---

Den Mon, 17 Apr 2006 15:50:30 +0200 skrev Christian E. Lysel:
> Kent Friis wrote:
>> Public key auth hjælper ikke på log-filen.
>
> Og for en ikke eksisterne bruger:
>
> Apr 17 15:45:01 bigfoot sshd[3442]: Invalid user test from 1.2.3.4
> Apr 17 13:45:01 bigfoot sshd[3443]: input_userauth_request: invalid user
> test
> Apr 17 13:45:01 bigfoot sshd[3443]: Failed none for invalid user test
> from 1.2.3.4 port 2457 ssh2
> Apr 17 15:45:04 bigfoot sshd[3442]: pam_unix(sshd:auth): check pass;
> user unknown
> Apr 17 15:45:04 bigfoot sshd[3442]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=speedy
> Apr 17 15:45:04 bigfoot sshd[3442]: pam_succeed_if(sshd:auth): error
> retrieving information about user test
> Apr 17 15:45:06 bigfoot sshd[3442]: Failed password for invalid user
> test from 1.2.3.4 port 2457 ssh2
> Apr 17 13:45:06 bigfoot sshd[3443]: Failed password for invalid user
> test from 1.2.3.4 port 2457 ssh2
> Apr 17 13:45:06 bigfoot sshd[3443]: Failed none for invalid user test
> from 1.2.3.4 port 2457 ssh2
> Apr 17 13:45:07 bigfoot sshd[3443]: Connection closed by 1.2.3.4

Det var da noget af en stak. Jeg tog udgangspunkt i min egen
log-fil, som indeholder flg:

Mar 15 21:32:05 gandalf sshd[3182]: Invalid user lars from 82.41.172.182
Mar 15 21:32:06 gandalf sshd[3184]: Invalid user keny from 82.41.172.182
Mar 15 21:32:07 gandalf sshd[3186]: Invalid user klaus from 82.41.172.182
Mar 15 21:32:08 gandalf sshd[3188]: Invalid user karl from 82.41.172.182
Mar 15 21:32:08 gandalf sshd[3190]: Invalid user kane from 82.41.172.182
Mar 15 21:32:09 gandalf sshd[3192]: Invalid user kenneth from 82.41.172.182
Mar 15 21:32:10 gandalf sshd[3194]: Invalid user keith from 82.41.172.182
Mar 15 21:32:10 gandalf sshd[3196]: Invalid user kelvin from 82.41.172.182

Det fylder ret godt, når der kommer en tre-fire linier i sekundet, og
det kan ikke reduceres ved at slå password-auth fra.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Det var da noget af en stak. Jeg tog udgangspunkt i min egen

Fedora core 5, i et test miljø. Min OpenBSD generere mindre, men
jeg ville ikke pille i en produktionsmaskine.

---

>>>>> "KF" == Kent Friis <nospam@nospam.invalid> writes:

KF> Det fylder ret godt, når der kommer en tre-fire linier i sekundet,
KF> og det kan ikke reduceres ved at slå password-auth fra.

Hvis man tilfældigvis kører Linux med en temmeligt ny kernel, så kan
sådan noget som det her måske hjælpe:

iptables -A INPUT -m tcp -p tcp --dport 22 -m recent --name SSH --hitcount 8 --update --seconds 60 -j REJECT
iptables -A INPUT -m tcp -p tcp --dport 22 -m state --state NEW -m recent --name SSH --set -j ACCEPT

Så tillader man kun 8 nye forbindelser på TCP port 22 indenfor et
minut fra hver IP-adresse. Og det bedste er at der skal være et minut
hvor der ikke kommer 8 forbindelser, før der lukkes op igen. Det
begrænser problemet væsentligt.

Til gengæld så rammer det også hvis man logger ind 8 gange med succes
-- det kan ikke nøjes med at kigge på mislykkede logins. Det kan være
et problem hvis man benytter f.eks. RSA-autentikering og scripts. SÃ¥
kan man skrue op til f.eks. 30 pr. minut.


/Benny

---

Jørn Hundebøll wrote:

> PS Ved godt at det sikkerhedsmæssigt ikke er godt, men tanken er at min
> sshd normalt ikke er kørende, men jeg via en skjult side kan starte den
> op. Jeg er bare træt af at halvdelen af min syslog er dårlige forsøg på
> at komme ind.

Hvad med at sætte procmail op, og så sende en mail til en bestemt bruger,
med et bestemt indhold i subj, måske også en bestemt afsender, og så starte
SSHD fra procmail?

Der går noget længer tid inden nogen finder udaf det, end finder en sikke
særligt skjult fide man bare skal tilgå.

Jeg har aldrig fået sat det op til noget der skal køre som root, men som
alm. bruger har jegl, og så en komando med sudo foran, og sudores sat op
til brugeren kan køre den komando uden passwd, så skulle det vist virke,
vil jeg mene,,,

Hvis du har en mobil tlf. med e-mail klient, så kan du også begranse til det
IP range som din mobil udbyder har, hvis ikke du også skal kunne få adgang
ude fra den store romaing verden.

--
Med venlig hilsen
Ivar Madsen
--------------------------------------------------------------------------------

---

Ivar Madsen wrote:
> Hvad med at sætte procmail op, og så sende en mail til en bestemt bruger,
> med et bestemt indhold i subj, måske også en bestemt afsender, og så starte
> SSHD fra procmail?

Erhm. Så skal han køre en mailserver i stedet for apache? Jeg gad godt
kigge mig lidt omkring i jeres verdener hvor det er en større risiko at
køre den nyeste sshd end det er at køre en mailserver eller webserver.

Det lader til, at det oprindelige problem er syslog beskeder fra
forkerte ssh logins. Hvad med at løse dét problem, i stedet for at kaste
flere internet-facing programmer efter maskinen?

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

---

Alex Holst wrote:

>> Hvad med at sætte procmail op, og så sende en mail til en bestemt bruger,
>> med et bestemt indhold i subj, måske også en bestemt afsender, og så
>> starte SSHD fra procmail?
> Erhm. Så skal han køre en mailserver i stedet for apache? Jeg gad godt
> kigge mig lidt omkring i jeres verdener hvor det er en større risiko at
> køre den nyeste sshd end det er at køre en mailserver eller webserver.

Det er naturligvis en forudsætning af at han køre mailserver.

Dengang jeg havde sat det op på den måde, så var det fordi jeg fra tid til
anden havde behov for at kunne starte et program, hjemme på maskinerne,
uanset hvor i landet jeg var, og så det en let måde. Kunne jeg have kørt
SSH fra min mobiltlf.? Mig bekendt ikke,,,

> Det lader til, at det oprindelige problem er syslog beskeder fra
> forkerte ssh logins. Hvad med at løse dét problem, i stedet for at kaste
> flere internet-facing programmer efter maskinen?

Jeg er enig i at det er beder for Jørn, at løse hans problem, istædet for at
finde en vej udenom problemmet.


--
Med venlig hilsen
Ivar Madsen
--------------------------------------------------------------------------------

---

Ivar Madsen wrote:
> Dengang jeg havde sat det op på den måde, så var det fordi jeg fra tid til
> anden havde behov for at kunne starte et program, hjemme på maskinerne,
> uanset hvor i landet jeg var, og så det en let måde. Kunne jeg have kørt
> SSH fra min mobiltlf.? Mig bekendt ikke,,,

Jah - der findes flere forskellige typer programmer du kan
købe/installere alt efter hvilken telefon du har :)

http://www.idokorro.com/products/ssh-features.shtml
http://www.xk72.com/midpssh/

Som eksempler...

Mvh
Johan

---

Alex Holst wrote:
> Ivar Madsen wrote:
>
>> Hvad med at sætte procmail op, og så sende en mail til en bestemt bruger,
>> med et bestemt indhold i subj, måske også en bestemt afsender, og så
>> starte
>> SSHD fra procmail?
>
>
> Erhm. Så skal han køre en mailserver i stedet for apache? Jeg gad godt
> kigge mig lidt omkring i jeres verdener hvor det er en større risiko at
> køre den nyeste sshd end det er at køre en mailserver eller webserver.

Nu kører jeg både mail og web hosting for mere end 10 domæner i
forvejen, så sikkerhedsrisikoen på den konto er uændret.

Jørn

---

Jørn Hundebøll wrote:
> Alex Holst wrote:

>> Erhm. Så skal han køre en mailserver i stedet for apache? Jeg gad godt
>> kigge mig lidt omkring i jeres verdener hvor det er en større risiko
>> at køre den nyeste sshd end det er at køre en mailserver eller webserver.
>
> Nu kører jeg både mail og web hosting for mere end 10 domæner i
> forvejen, så sikkerhedsrisikoen på den konto er uændret.

Så må du huske at implementere den samme, vigtige beskyttelse for både
din mailserver og webserver.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

---

> PS Ved godt at det sikkerhedsmæssigt ikke er godt, men tanken er at min
> sshd normalt ikke er kørende, men jeg via en skjult side kan starte den
> op. Jeg er bare træt af at halvdelen af min syslog er dårlige forsøg på
> at komme ind.

Jeg har ændret min sshd til at køre på en anden port end standarden. Det
har fjernet langt de fleste login forsøg.

/Jan

---

Jan Birk wrote:

>> PS Ved godt at det sikkerhedsmæssigt ikke er godt, men tanken er at
>> min sshd normalt ikke er kørende, men jeg via en skjult side kan
>> starte den op. Jeg er bare træt af at halvdelen af min syslog er
>> dårlige forsøg på at komme ind.
>
> Jeg har ændret min sshd til at køre på en anden port end standarden.
> Det har fjernet langt de fleste login forsøg.

En anden god metode er at sætte port knocking op til at kontrollere
adgangen til port 22. Korrekt opsat forhindrer det også login forsøg
fra folk der fandt din SSH port ved at scanne igennem dine porte.
Afhængig af hvilken type maskine man forbinder fra, så kan det dog være
en smule besværligt at få den rigtige sekvens sendt afsted for at lukke
op.

--
PeKaJe

Linux is not a desktop OS for people whose VCRs are still flashing "12:00".
      -- Paul Tomblin

---

Jan Birk wrote:
>> PS Ved godt at det sikkerhedsmæssigt ikke er godt, men tanken er at
>> min sshd normalt ikke er kørende, men jeg via en skjult side kan
>> starte den op. Jeg er bare træt af at halvdelen af min syslog er
>> dårlige forsøg på at komme ind.
>
>
> Jeg har ændret min sshd til at køre på en anden port end standarden. Det
> har fjernet langt de fleste login forsøg.

Det skal prøves - det er vel bare at rette i sshd_config filen ?

Jørn

---

> Det skal prøves - det er vel bare at rette i sshd_config filen ?

Ja, du kan skrive/ændre:

Port XX

og genstarte sshd

/Jan