|
| Hacher-angreb Fra : Kall, Mogens |
Dato : 17-05-04 22:50 |
|
Dato: 16-05-2004 Klokkeslæt: 19:44:37
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.79.85.33,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.85.33,5000)
Fjernadresse, tjeneste er (62.83.20.42,4614)
Procesnavn er "N/A"
Dato: 16-05-2004 Klokkeslæt: 19:44:53
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.79.85.33,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.85.33,5000)
Fjernadresse, tjeneste er (62.79.39.235,netshow(1755))
Procesnavn er "N/A"
Dato: 16-05-2004 Klokkeslæt: 19:47:34
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.79.85.33,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.85.33,5000)
Fjernadresse, tjeneste er (62.226.106.88,4441)
Procesnavn er "N/A"
Dato: 16-05-2004 Klokkeslæt: 19:49:58
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.79.85.33,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.85.33,5000)
Fjernadresse, tjeneste er (62.147.39.76,1186)
Procesnavn er "N/A"
Dato: 16-05-2004 Klokkeslæt: 19:50:23
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.79.85.33,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.85.33,5000)
Fjernadresse, tjeneste er (62.79.86.5,1428)
Procesnavn er "N/A"
Dato: 16-05-2004 Klokkeslæt: 19:59:47
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.29.176.247,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.86.111,5000)
Fjernadresse, tjeneste er (62.29.176.247,4370)
Procesnavn er "N/A"
Dato: 16-05-2004 Klokkeslæt: 20:00:02
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.47.50.143,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.86.111,5000)
Fjernadresse, tjeneste er (62.47.50.143,3039)
Procesnavn er "N/A"
Dato: 16-05-2004 Klokkeslæt: 20:00:05
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.134.74.173,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.86.111,5000)
Fjernadresse, tjeneste er (62.134.74.173,4458)
Procesnavn er "N/A"
Dato: 16-05-2004 Klokkeslæt: 20:00:38
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.147.83.101,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.86.111,5000)
Fjernadresse, tjeneste er (62.147.83.101,2636)
Procesnavn er "N/A"
Dato: 16-05-2004 Klokkeslæt: 20:13:50
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.79.39.235,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.87.171,5000)
Fjernadresse, tjeneste er (62.79.39.235,4608)
Procesnavn er "N/A"
Dato: 16-05-2004 Klokkeslæt: 20:21:09
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.79.85.4,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.87.171,5000)
Fjernadresse, tjeneste er (62.79.85.4,2283)
Procesnavn er "N/A"
Dato: 16-05-2004 Klokkeslæt: 20:21:39
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.79.74.237,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.87.171,5000)
Fjernadresse, tjeneste er (62.79.74.237,1288)
Procesnavn er "N/A"
Dato: 16-05-2004 Klokkeslæt: 20:24:15
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.79.86.5,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.87.171,5000)
Fjernadresse, tjeneste er (62.79.86.5,3641)
Procesnavn er "N/A"
Dato: 17-05-2004 Klokkeslæt: 09:11:08
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.219.69.76,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.85.147,5000)
Fjernadresse, tjeneste er (62.219.69.76,3950)
Procesnavn er "N/A"
Dato: 17-05-2004 Klokkeslæt: 09:12:42
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.85.199.108,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.85.147,5000)
Fjernadresse, tjeneste er (62.85.199.108,2956)
Procesnavn er "N/A"
Dato: 17-05-2004 Klokkeslæt: 15:18:31
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.87.134.45,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.86.106,5000)
Fjernadresse, tjeneste er (62.87.134.45,2063)
Procesnavn er "N/A"
Dato: 17-05-2004 Klokkeslæt: 17:47:13
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.167.114.8,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.85.141,5000)
Fjernadresse, tjeneste er (62.167.114.8,3164)
Procesnavn er "N/A"
Dato: 17-05-2004 Klokkeslæt: 22:45:03
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.39.236.89,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.85.230,5000)
Fjernadresse, tjeneste er (62.39.236.89,3359)
Procesnavn er "N/A"
Dato: 17-05-2004 Klokkeslæt: 22:47:38
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.79.69.200,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.85.230,5000)
Fjernadresse, tjeneste er (62.79.69.200,2850)
Procesnavn er "N/A"
Dato: 17-05-2004 Klokkeslæt: 23:10:43
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.175.14.200,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.86.126,5000)
Fjernadresse, tjeneste er (62.175.14.200,3207)
Procesnavn er "N/A"
Dato: 17-05-2004 Klokkeslæt: 23:11:20
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.83.101.145,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.86.126,5000)
Fjernadresse, tjeneste er (62.83.101.145,3674)
Procesnavn er "N/A"
Dato: 17-05-2004 Klokkeslæt: 23:12:41
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.47.189.133,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.86.126,5000)
Fjernadresse, tjeneste er (62.47.189.133,1703)
Procesnavn er "N/A"
Dato: 17-05-2004 Klokkeslæt: 23:12:48
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.135.40.92,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.86.126,5000)
Fjernadresse, tjeneste er (62.135.40.92,1436)
Procesnavn er "N/A"
-
Kender nogen noget til disse fjern-computere ?
Med venlig hilsen
Mogens Kall
The servant of Michael
Last-Informationfile:
( use http://www.google.dk/grphp )
1662 news:sbX3c.108512$jf4.6509896@news000.worldonline.dk
2124 news:HzXpc.164474$jf4.8497342@news000.worldonline.dk
File-number:
2148
| |
Alex Holst (17-05-2004)
| Kommentar Fra : Alex Holst |
Dato : 17-05-04 23:17 |
| | |
Kall, Mogens (18-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 18-05-04 10:47 |
|
"Alex Holst" skrev
news:40a939bd$0$161$edfadb0f@dtext02.news.tele.dk
[ ... ]
> > Kender nogen noget til disse fjern-computere ?
>
> http://sikkerhed-faq.dk/indledning#bedste
Arh ... du misforstod mig.
Det, jeg ønsker, er at kontakte ejermændene af disse fjerncomputere mhp., at
de får lukket hullerne. Endvidere - om muligt - at tyvene pågribes!!!
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2150
| |
Kim Ludvigsen (18-05-2004)
| Kommentar Fra : Kim Ludvigsen |
Dato : 18-05-04 11:10 |
|
Kall, Mogens wrote:
>
> [ ... ]
> > > Kender nogen noget til disse fjern-computere ?
>
> Det, jeg ønsker, er at kontakte ejermændene af disse fjerncomputere mhp., at
> de får lukket hullerne. Endvidere - om muligt - at tyvene pågribes!!!
Der er nok ikke den store chance for, at vi kender ejermændene af nogle
tilfældige computere spredt rundt omkring i verden. Jeg forstår
forøvrigt ikke, hvorfor du tror, at computerne skulle være stjålet, men
der er så meget jeg ikke forstår - for eksempel, hvorfor du bliver ved
med at bekymre dig om advarsler fra din firewall.
Men hvis du keder dig så meget, at du vil gøre noget ved sagerne, skal
du kontakte de enkelte computeres ejermænd - eller rettere ejermændenes
internetudbydere, der så evt. vil kontakte ejermændene. Du har vist
tidligere fået at vide hvordan, men her kommer det igen:
Tag ip-nummeret ud for Fjernadresse, det er de fire første tal adskilt
af punktummer. Brug en whois-tjeneste som den du finder på
http://www.dnsstuff.com til at slå ip-nummeret op. Et eller andet sted
på den resulterende side kan du finde en oplysning i stil med følgende
(der er fra den første advarsel på din lange liste): "for net abuse
questions: abuse@auna.es". Du skriver så en mail til den pågældende
adresse, hvor du forklarer, hvad problemet er. Vedlæg advarslen fra din
firewall, og husk at notere, hvis din computers ur ikke går korrekt.
Forvent ikke at få svar fra den pågældende udbyders abuse-afdeling.
--
Mvh. Kim Ludvigsen
| |
Christian E. Lysel (18-05-2004)
| Kommentar Fra : Christian E. Lysel |
Dato : 18-05-04 11:41 |
|
In article <40A9E0E8.58AB@kimludvigsen.dk>, Kim Ludvigsen wrote:
> Tag ip-nummeret ud for Fjernadresse, det er de fire første tal adskilt
Husk evt. lige at undersøge om IP adressen er spoofet. :)
Ellers anklager du den forkerte.
--
Mvh.
Christian E. Lysel
http://www.spindelnet.dk/
| |
Troels Arvin (18-05-2004)
| Kommentar Fra : Troels Arvin |
Dato : 18-05-04 12:09 |
|
On Tue, 18 May 2004 10:40:59 +0000, Christian E. Lysel wrote:
> Husk evt. lige at undersøge om IP adressen er spoofet. :)
Hvordan skulle det kunne undersøges?
--
Greetings from Troels Arvin, Copenhagen, Denmark
| |
Kall, Mogens (18-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 18-05-04 22:48 |
|
"Christian E. Lysel" skrev
news:slrncajq1r.h2.chel@weebo.dmz.spindelnet.dk
> In article <40A9E0E8.58AB@kimludvigsen.dk>, Kim Ludvigsen wrote:
> > Tag ip-nummeret ud for Fjernadresse, det er de fire første tal adskilt
>
> Husk evt. lige at undersøge om IP adressen er spoofet. :)
>
> Ellers anklager du den forkerte.
Hvad vil det sige, at IP adressen er *spoofet* ?
(Serveren *infekseret* og bruges som terminal ?)
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2154
| |
Christian E. Lysel (18-05-2004)
| Kommentar Fra : Christian E. Lysel |
Dato : 18-05-04 23:13 |
| | |
Kall, Mogens (19-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 19-05-04 18:41 |
|
"Christian E. Lysel" skrev
news:slrncal2k6.alo.chel@weebo.dmz.spindelnet.dk
[ ... ]
> >> Husk evt. lige at undersøge om IP adressen er spoofet. :)
> >>
> >> Ellers anklager du den forkerte.
> >
> > Hvad vil det sige, at IP adressen er *spoofet* ?
>
> På Dansk
>
> http://www.google.com/search?q=spoofet
>
> På Engelsk (nok den bedste forklaring)
>
> http://www.google.com/search?q=spoof+ip
Jeg fandt ...
Name: Peter
Date: 7. maj 2004 CET 01:07
Subject: Hvad dækker "spoofet" over?
Newsgroups: dk.edb.sikkerhed
news:c7egbr$qlu$1@news.net.uni-c.dk
.... og de dertil knyttede indlæg.
Et af dem lyder således:
Name: Lars Kim Lund
Date: 7. maj 2004 CET 11:04
news:imjm90p8jjetc00e4n2f7uig1aldk8a4jv@dtext.news.tele.dk
=== citat start ===
Spoofing dækker generelt over forfalskning. Jeg kan bedst forklare det
med et traditionelt brev hvor adressen både kan stå på kuverten og
inde i brevet. Det der står i brevet kan være falsk, hvorimod det der
står på kuverten er rigtigt, for ellers når brevet ikke frem.
I e-mail regi gælder det samme forhold. Forskellen er blot at du ikke
kan se de oplysninger der står på kuverten da det udvekslen mellem
mail-serverne. Du ser kun oplysningerne inde i brevet, og eftersom de
ikke bruges til at levere posten så kan uden problemer forfalskes.
Hvis det stadig ikke står klart for dig, så prøv at søge på nettet
efter SMTP envelope headers og message headers.
=== citat slut ====
Glimrende forklaring
Jeg var også lige inde på siden ... http://www.net-faq.dk/faq.pl?get=spoof
Her stod der bl.a.
=== citat start ===
Spoofing er den praksis, at man sender pakker ud på netværket med en anden
afsender-addresse end ens egen.
=== citat slut ====
Men det gjalt jo E-mail.
I min situation er der tale om, at en fremmed computer systematisk laver en
LIVE *portscanning*.
Kan forfalskning også her muliggøres ?
Og i så fald, hvordan ?
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2162
| |
Christian E. Lysel (20-05-2004)
| Kommentar Fra : Christian E. Lysel |
Dato : 20-05-04 00:07 |
|
In article <%_Mqc.84$Vf.4616@news000.worldonline.dk>, Kall, Mogens wrote:
> Spoofing er den praksis, at man sender pakker ud på netværket med en anden
> afsender-addresse end ens egen.
>
> Men det gjalt jo E-mail.
Nej, han mener nok en netværkspakke.
> Kan forfalskning også her muliggøres ?
Ja.
> Og i så fald, hvordan ?
Man skriver en IP pakke med en anden afsender
adresse.
Læs evt. en bog om IP eller RFC 791...
Det er tåbeligt at anklage folk, når man
ikke forstår sit "bevis" matriale.
--
Mvh.
Christian E. Lysel
http://www.spindelnet.dk/
| |
Michael Knudsen (19-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 19-05-04 16:50 |
|
Kall, Mogens wrote:
> Hvad vil det sige, at IP adressen er *spoofet* ?
Du ved godt, at vi har en OSS, ikke?
http://sikkerhed-faq.dk/angreb/spoof
I oevrigt er afsnittet med beskrivelser af forskellige angreb langt fra
faerdigt, saa foel jer hermed kraftigt opfordret til at skrive om et
emne. Lige nu har jeg sat foelgende ind paa listen over ting, der
mangler beskrivelser:
o DNS poisoning
o Session hijacking
o Trojanske heste
Der er naturligvis mange flere. Derudover er rettelser og forbedringer
til de eksisterende ogsaa meget velkomne.
Mvh. Michael.
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)
| |
Kall, Mogens (18-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 18-05-04 22:48 |
|
"Kim Ludvigsen" skrev
news:40A9E0E8.58AB@kimludvigsen.dk
> Kall, Mogens wrote:
> >
> > [ ... ]
> > > > Kender nogen noget til disse fjern-computere ?
> >
> > Det, jeg ønsker, er at kontakte ejermændene af disse fjerncomputere
> > mhp., at
> > de får lukket hullerne. Endvidere - om muligt - at tyvene pågribes!!!
>
> Der er nok ikke den store chance for, at vi kender ejermændene af nogle
> tilfældige computere spredt rundt omkring i verden. ...
I dag få, i morgen mange.
Ligesom i naturen, hvor vi har immunforsvaret (der dog ikke kender nye
varianter), *skal* vi have oprettet en forebyggelse af angreb på globalt
plan ved simpel isolering af "uheldige" elementer (se nedenfor).
> ... Jeg forstår
> forøvrigt ikke, hvorfor du tror, at computerne skulle være stjålet, men
> der er så meget jeg ikke forstår - ...
Arh, det var nu hackeren, som er indbrudstyven.
> ... for eksempel, hvorfor du bliver ved
> med at bekymre dig om advarsler fra din firewall.
Er du ansat i et anti-virus-firma ?
At din firewall virker i dag, er i sig selv INGEN garanti for at den virker
i morgen (et eksempel: Sasser, herefter oprettes bagdør).
> Men hvis du keder dig så meget, at du vil gøre noget ved sagerne, skal
> du kontakte de enkelte computeres ejermænd - eller rettere ejermændenes
> internetudbydere, der så evt. vil kontakte ejermændene.
Min tanke var nu (på længere sigt), at de servere internetudbyderen råder
over "kobles" af netten automatisk, dersom de ikke samarbejder med os
forbrugere på globalt plan.
Eksempelvis kunne min internet-udbyder ("hypotetisk" set) muligvis nægte
*al* kommunikation med de berørte servere ? - Kan det lade sig gøre, teknisk
set ?
> ... Du har vist
> tidligere fået at vide hvordan, men her kommer det igen:
Det må jeg have overhørt, desværre
> Tag ip-nummeret ud for Fjernadresse, det er de fire første tal adskilt
> af punktummer. Brug en whois-tjeneste som den du finder på
> http://www.dnsstuff.com til at slå ip-nummeret op. Et eller andet sted
> på den resulterende side kan du finde en oplysning i stil med følgende
> (der er fra den første advarsel på din lange liste): "for net abuse
> questions: abuse@auna.es". Du skriver så en mail til den pågældende
> adresse, hvor du forklarer, hvad problemet er. Vedlæg advarslen fra din
> firewall, og husk at notere, hvis din computers ur ikke går korrekt.
> Forvent ikke at få svar fra den pågældende udbyders abuse-afdeling.
Mange tak for hjælpen, Kim.
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2153
| |
Alex Holst (19-05-2004)
| Kommentar Fra : Alex Holst |
Dato : 19-05-04 00:14 |
|
Kall, Mogens <John@15.13> wrote:
> Ligesom i naturen, hvor vi har immunforsvaret (der dog ikke kender nye
> varianter), *skal* vi have oprettet en forebyggelse af angreb p? globalt
> plan ved simpel isolering af "uheldige" elementer (se nedenfor).
*plonk*
--
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
| |
Niels Callesøe (19-05-2004)
| Kommentar Fra : Niels Callesøe |
Dato : 19-05-04 00:45 |
|
Alex Holst wrote:
>> Ligesom i naturen, hvor vi har immunforsvaret (der dog ikke
>> kender nye varianter), *skal* vi have oprettet en forebyggelse af
>> angreb p? globalt plan ved simpel isolering af "uheldige"
>> elementer (se nedenfor).
>
> *plonk*
Først nu?
--
Niels Callesøe - dk pfy
pfy[at]nntp.dk - http://www.pcpower.dk/disclaimer.php
Bogus virus warnings are spam. Reject them using Postfix:
http://www.t29.dk/antiantivirus.txt
| |
Michael U. Hove (19-05-2004)
| Kommentar Fra : Michael U. Hove |
Dato : 19-05-04 06:37 |
|
Kall, Mogens wrote:
> Ligesom i naturen, hvor vi har immunforsvaret (der dog ikke kender nye
> varianter), *skal* vi have oprettet en forebyggelse af angreb på globalt
> plan ved simpel isolering af "uheldige" elementer (se nedenfor).
I listen over dårlige metaforer, er det den værste jeg har hørt hidtil!
Men den var sgu meget sjov
>>... Jeg forstår
>>forøvrigt ikke, hvorfor du tror, at computerne skulle være stjålet, men
>>der er så meget jeg ikke forstår - ...
>
>
> Arh, det var nu hackeren, som er indbrudstyven.
Hvis der er registreret et "indbrud" som du kalder det i din fw-log, er
det fordi proben af porten er blevt opfanget og blokket!Altså ikke et
indbrud. Dine porte probes tusindvis af gange dagligt uden at du lægger
mærke til det, ell. er der til at panikke over en tilfældig log.
Ikke for at være grov, *men*:
At forveksle evnen til at gå i panik over en personlig firewall
log/meddelelse med evnen til at skelne ml. et "angrebsforsøg" og en reel
kompromittering er en typisk sikkerheds-novice fejl.
Succesfulde indbrud detekteres som regel *aldrig* af firewalls. Det er
bl.a. en af grundene til at flere af de kvalificerede folk herinde tit
råber "firewalls er ikke løsningen...".
Grunden til at folk kommer igennem og kompromitterer en given host er
*netop*, fordi de har fundet et hul i firewallen, ell. et hul i en
applikation der ligger bag en forwardet port.
Hvorfor vil du ikke tage OSS'ens afsnit om personlige firewalls til
efterretning?! Den er skrevet af folk, der *virkelig* ved, hvad de
snakker om...og formentlig har set millioner af fw-log linier.
>>... for eksempel, hvorfor du bliver ved
>>med at bekymre dig om advarsler fra din firewall.
>
>
> Er du ansat i et anti-virus-firma ?
>
> At din firewall virker i dag, er i sig selv INGEN garanti for at den virker
> i morgen (et eksempel: Sasser, herefter oprettes bagdør).
Hvis du virkelig vil gøre noget for din personlige computersikkerhed, så
gå igang med at læse nogen tekster om hærdning/minimering af
OS/services. Det er i længden et *lidt* mere frugtbar projekt. Du kan
bruge resten af dine dage på at læse fw-logs og sende abuse mails, uden
at din computer bliver meget sikrere af den grund...
>>Men hvis du keder dig så meget, at du vil gøre noget ved sagerne, skal
>>du kontakte de enkelte computeres ejermænd - eller rettere ejermændenes
>>internetudbydere, der så evt. vil kontakte ejermændene.
>
>
> Min tanke var nu (på længere sigt), at de servere internetudbyderen råder
> over "kobles" af netten automatisk, dersom de ikke samarbejder med os
> forbrugere på globalt plan.
Jeg tror nu ISP'erne har andet at lave, men de skal vel også have noget
at snakke om til julefrokosten...
> Eksempelvis kunne min internet-udbyder ("hypotetisk" set) muligvis nægte
> *al* kommunikation med de berørte servere ? - Kan det lade sig gøre, teknisk
> set ?
Hvorfor sætter du ikke selv et blokerende filter op i din
router/firewall/whatever, hvis du er så bekymret...?!
[snip]
> Med venlig hilsen
> Mogens Kall
> The servant of Michael
>
> File-number:
> 2153
Huh?
Mvh.
Michael
--
A typical day in the life of a UNIX user:
"unzip, touch, finger, strip, mount, yes, core dump, umount, sleep"
Mark Taylor.
| |
Brian R. Jensen (19-05-2004)
| Kommentar Fra : Brian R. Jensen |
Dato : 19-05-04 06:45 |
|
"Kall, Mogens" <John@15.13> skrev i en meddelelse
news:dwvqc.164874$jf4.8584788@news000.worldonline.dk...
> > Der er nok ikke den store chance for, at vi kender ejermændene af nogle
> > tilfældige computere spredt rundt omkring i verden. ...
>
> I dag få, i morgen mange.
>
> Ligesom i naturen, hvor vi har immunforsvaret (der dog ikke kender nye
> varianter), *skal* vi have oprettet en forebyggelse af angreb på globalt
> plan ved simpel isolering af "uheldige" elementer (se nedenfor).
Hvor vil du hen med den omgang?
> > ... Jeg forstår
> > forøvrigt ikke, hvorfor du tror, at computerne skulle være stjålet, men
> > der er så meget jeg ikke forstår - ...
>
> Arh, det var nu hackeren, som er indbrudstyven.
Hvor er han brudt ind, det fremgår ikke af dit indlæg at nogen er brudt ind.
> > ... for eksempel, hvorfor du bliver ved
> > med at bekymre dig om advarsler fra din firewall.
>
> Er du ansat i et anti-virus-firma ?
Hvor vil du hen med det? Hvilken relevans er der mellem et spørgsmål til din
forståelse af firewalls, og så din formodning om at manden er ansat i et
antivirus firma?
> At din firewall virker i dag, er i sig selv INGEN garanti for at den
virker
> i morgen (et eksempel: Sasser, herefter oprettes bagdør).
Du vrøvler, sasser var ikke i stand til at omgå en firewall, faktisk ville
de fleste standardkonfigurerede routere have stoppet den.
Er du helt sikker på du ikke blander begreberne sammen? Det lyder som om du
har svært ved at skelne mellem firewalls og antivirus.
> > Men hvis du keder dig så meget, at du vil gøre noget ved sagerne, skal
> > du kontakte de enkelte computeres ejermænd - eller rettere ejermændenes
> > internetudbydere, der så evt. vil kontakte ejermændene.
Som flere har skrevet, så kan ud ikke være sikker på at det er den korrekte
ip du har i loggen.
Deruover kan det rent faktisk være helt lovlig trafik, der blot ved en
tastefejl er rettet mod dit ip-nr. istedet for det tiltænkte - du ved det
ikke
/Brian
| |
Kall, Mogens (19-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 19-05-04 12:44 |
|
"Brian R. Jensen" skrev
news:40aaf45f$0$260$edfadb0f@dread16.news.tele.dk
[ ... ]
> > At din firewall virker i dag, er i sig selv INGEN garanti for at den
> > virker
> > i morgen (et eksempel: Sasser, herefter oprettes bagdør).
>
> Du vrøvler, sasser var ikke i stand til at omgå en firewall, faktisk ville
> de fleste standardkonfigurerede routere have stoppet den.
>
> Er du helt sikker på du ikke blander begreberne sammen? Det lyder som om
> du har svært ved at skelne mellem firewalls og antivirus.
Du misforstod mig.
Mange computere blev inficseret med sasser. Når et maskinkode-program først
afvikles på en computer, er der INGEN begrænsninger for hvilke operationer,
der kan foretages. Man kan ændre eller slette filer på Harddiskene, inficere
MasterBootRecorden (ved mindre denne er skrivebeskyttet i BIOS-opsætningen)
eller BootRecorden osv. - eller oprette en bagdør (hvorved man går *udenom*
firewall'en).
Forebyggelse
--------------
For at *forebygge* dette, bør man have en Harddisk med skrivebeskyttede
zoner, således at Operativsystemet ALTID under opstart indlæser filerne fra
disse sikre zoner. Filer, som ændres undervejs af OS under programafvikling,
kan af gode grunde ikke ligge i denne sikre zone, men disses original-filer
kan godt. Dersom computeren ønskes *steriliseret* kan man under opstart
kopiere disse filer fra den sikrede zone til den læse- og skrivebare zone.
Nogle filer ændres ofte, mens andre ændres sjældent, hvorfor det er
relevant at have flere zoner, end blot de to nævnte.
Eksempelvis kunne en bruger ønske et nyt maskinkode-program installeret på
computeren. Dette program er godkendt officielt med sikkerhedskoder osv.,
men 100 % sikker kan man aldrig være. Derfor kan filer herfra ALDRIG komme
ind i den skrivebeskyttede zone, hvor udelukkende OS'ets læsefiler ligger.
Men filerne skal jo lagres og gerne herefter komme ind i en skrivebeskyttet
zone. Dette kan gøres ved en kold-boot + midlertidig reinstallering af
original-OS'et. Herved er der 100 % sikkerhed for, at computeren INDEN
programinstalleringen er uden infektion. Så kan det nye program installeres
i en dertil oprettet *ny* skrivebeskyttet zone.
På den måde vil der opstå et utal af mere eller mindre skrivebeskyttede
zoner på HD'en/ene.
Sikkerhedsregel: Når en zone først er skrivebeskyttet kan den ikke ændres,
undtagen af et rent (midlertidigt) OS.
For at muliggøre dette, skal der foretages nogle ændringer i Hardwaren, men
det må kunne lade sig gøre. Electric-eraseable-ROM kunne anvendes til at
huske de skrivebeskyttede zoner (BIOS-opsætningen). Et lille
maskinkodeprogram under BIOS kunne så tjekke, at der UDELUKKENDE foretages
*oprettelse* af nye skrivebeskyttede zoner (og altså ikke omvendt).
Med hensyn til OS. Hermed en lille udfordring til fx. Linux-nørder
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2157
| |
Andreas Plesner Jaco~ (19-05-2004)
| Kommentar Fra : Andreas Plesner Jaco~ |
Dato : 19-05-04 12:53 |
|
On 2004-05-19, Kall, Mogens <John@15.13> wrote:
>
> Mange computere blev inficseret med sasser. Når et maskinkode-program først
> afvikles på en computer, er der INGEN begrænsninger for hvilke operationer,
Dette er ikke rigtigt, mange processorer har beskyttelsesmekanismer.
--
Andreas Plesner Jacobsen | A is for Apple.
| -- Hester Pryne
| |
Kall, Mogens (19-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 19-05-04 15:37 |
|
"Andreas Plesner Jacobsen" skrev
news:slrncamiku.iv.apj@slartibartfast.nerd.dk
> On 2004-05-19, Kall, Mogens <John@15.13> wrote:
> >
> > Mange computere blev inficseret med sasser. Når et maskinkode-program
> > først afvikles på en computer, er der INGEN begrænsninger for hvilke
> > operationer,
>
> Dette er ikke rigtigt, mange processorer har beskyttelsesmekanismer.
Interessant og glædeligt at høre!
Kan du oplyse mig nærmere herom ?
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2159
| |
Kent Friis (19-05-2004)
| Kommentar Fra : Kent Friis |
Dato : 19-05-04 15:52 |
|
Den Wed, 19 May 2004 16:36:36 +0200 skrev Kall, Mogens:
> "Andreas Plesner Jacobsen" skrev
> news:slrncamiku.iv.apj@slartibartfast.nerd.dk
>
>> On 2004-05-19, Kall, Mogens <John@15.13> wrote:
>> >
>> > Mange computere blev inficseret med sasser. Når et maskinkode-program
>> > først afvikles på en computer, er der INGEN begrænsninger for hvilke
>> > operationer,
>>
>> Dette er ikke rigtigt, mange processorer har beskyttelsesmekanismer.
>
> Interessant og glædeligt at høre!
>
> Kan du oplyse mig nærmere herom ?
Få fat i en manual til 80386 eller nyere, Motorola 68000 eller nyere,
eller tilsvarende processor fra efter Commodore 64 tiden.
Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/
| |
Kasper Dupont (19-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 19-05-04 16:13 |
|
Kent Friis wrote:
>
> Den Wed, 19 May 2004 16:36:36 +0200 skrev Kall, Mogens:
> > "Andreas Plesner Jacobsen" skrev
> > news:slrncamiku.iv.apj@slartibartfast.nerd.dk
> >
> >> On 2004-05-19, Kall, Mogens <John@15.13> wrote:
> >> >
> >> > Mange computere blev inficseret med sasser. Når et maskinkode-program
> >> > først afvikles på en computer, er der INGEN begrænsninger for hvilke
> >> > operationer,
> >>
> >> Dette er ikke rigtigt, mange processorer har beskyttelsesmekanismer.
> >
> > Interessant og glædeligt at høre!
> >
> > Kan du oplyse mig nærmere herom ?
>
> Få fat i en manual til 80386 eller nyere, Motorola 68000 eller nyere,
> eller tilsvarende processor fra efter Commodore 64 tiden.
Der var beskyttelse allerede i 80286. Designet i 80386
indeholder faktisk stadig spor efter det oprindelige
design, pga. bagudkompatibilitet. Og kønt er det ikke.
Med lidt statisk analyse af koden før den startes tror
jeg næsten man må kunne implementere noget der ligner
beskyttelse på selv en 8086.
Til gengæld troede jeg ikke der var rigtig beskyttelse
på en 68000. Det er da rigtigt nok, at der var nogen
priviligerede instruktioner. Men upriviligerede
programmer havde stadig mulighed for at skrive til
vilkårlig hukommelse. Skulle man ikke have minimum en
68020 og en mmu chip ved siden af?
Hvis man vil have nogle lidt mere uptodate uplysninger,
så vil jeg foreslå man kigger på:
http://www.x86-64.org/
http://developer.intel.com/
Hvis man er mere interesseret i teori end praksis, så
er Tanenbaums bøger et udmærket sted at starte.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Kent Friis (19-05-2004)
| Kommentar Fra : Kent Friis |
Dato : 19-05-04 16:21 |
|
Den Wed, 19 May 2004 17:12:55 +0200 skrev Kasper Dupont:
> Kent Friis wrote:
>>
>> Den Wed, 19 May 2004 16:36:36 +0200 skrev Kall, Mogens:
>> > "Andreas Plesner Jacobsen" skrev
>> > news:slrncamiku.iv.apj@slartibartfast.nerd.dk
>> >
>> >> On 2004-05-19, Kall, Mogens <John@15.13> wrote:
>> >> >
>> >> > Mange computere blev inficseret med sasser. Når et maskinkode-program
>> >> > først afvikles på en computer, er der INGEN begrænsninger for hvilke
>> >> > operationer,
>> >>
>> >> Dette er ikke rigtigt, mange processorer har beskyttelsesmekanismer.
>> >
>> > Interessant og glædeligt at høre!
>> >
>> > Kan du oplyse mig nærmere herom ?
>>
>> Få fat i en manual til 80386 eller nyere, Motorola 68000 eller nyere,
>> eller tilsvarende processor fra efter Commodore 64 tiden.
>
> Der var beskyttelse allerede i 80286. Designet i 80386
> indeholder faktisk stadig spor efter det oprindelige
> design, pga. bagudkompatibilitet. Og kønt er det ikke.
> Med lidt statisk analyse af koden før den startes tror
> jeg næsten man må kunne implementere noget der ligner
> beskyttelse på selv en 8086.
Min pointe var sådan set også bare at hvis han betragter det som en
nyhed, så er han meget langt bagud.
> Til gengæld troede jeg ikke der var rigtig beskyttelse
> på en 68000. Det er da rigtigt nok, at der var nogen
> priviligerede instruktioner. Men upriviligerede
> programmer havde stadig mulighed for at skrive til
> vilkårlig hukommelse. Skulle man ikke have minimum en
> 68020 og en mmu chip ved siden af?
Det har du nok ret i, jeg blandede lige 68000 og 68030 sammen.
Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/
| |
Kasper Dupont (19-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 19-05-04 18:09 |
|
Kent Friis wrote:
>
> Min pointe var sådan set også bare at hvis han betragter det som en
> nyhed, så er han meget langt bagud.
Kun omkring 15 år
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Kall, Mogens (19-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 19-05-04 18:40 |
|
"Kent Friis" skrev
news:40ab748b$0$3048$14726298@news.sunsite.dk
[ ... ]
> >> On 2004-05-19, Kall, Mogens <John@15.13> wrote:
> >> >
> >> > Mange computere blev inficseret med sasser. Når et maskinkode-program
> >> > først afvikles på en computer, er der INGEN begrænsninger for hvilke
> >> > operationer,
> >>
> >> Dette er ikke rigtigt, mange processorer har beskyttelsesmekanismer.
> >
> > Interessant og glædeligt at høre!
> >
> > Kan du oplyse mig nærmere herom ?
>
> Få fat i en manual til 80386 eller nyere, Motorola 68000 eller nyere,
> eller tilsvarende processor fra efter Commodore 64 tiden.
Jeg kan da med et forholdsvis simpelt maskinkodeprogram oprette, overskrive
og slette filer på fx. Windows 98
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2161
| |
Michael Knudsen (19-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 19-05-04 19:41 |
|
Kall, Mogens wrote:
> Jeg kan da med et forholdsvis simpelt maskinkodeprogram oprette, overskrive
> og slette filer på fx. Windows 98
Windows 98 har ingen sikkerhedsmodel.
Mvh. Michael.
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)
| |
Kall, Mogens (20-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 20-05-04 00:58 |
|
"Michael Knudsen" skrev
news:40abaa3e$0$3050$14726298@news.sunsite.dk
> Kall, Mogens wrote:
> > Jeg kan da med et forholdsvis simpelt maskinkodeprogram oprette,
> > overskrive
> > og slette filer på fx. Windows 98
>
> Windows 98 har ingen sikkerhedsmodel.
Det er korrekt.
I Windows 2000 og XP skal man så igennem en hel procedure af API-opkald,
førend man får tilladelse til dit og dat, men det er og bliver blot et
software-mæssigt problem, desværre
Dét, jeg taler om, er en gang for alle at løse problemet hardware-mæssigt
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2168
| |
Kasper Dupont (19-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 19-05-04 19:55 |
|
"Kall, Mogens" wrote:
>
> Jeg kan da med et forholdsvis simpelt maskinkodeprogram oprette, overskrive
> og slette filer på fx. Windows 98
Det siger mere om Windows 98 end det siger om maskinen.
Havde man brugt Linux dengang ville det ikke have været
muligt. Det siges at file permissions i Linux blev
implementeret kort tid efter at Linus selv i December
1991 ved en fejltagelse var kommet til at prøve at
ringe op vha. en harddisk partition i stedet for sit
modem.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Jesper Louis Anderse~ (19-05-2004)
| Kommentar Fra : Jesper Louis Anderse~ |
Dato : 19-05-04 17:25 |
|
Kall, Mogens <John@15.13> wrote:
> Med hensyn til OS. Hermed en lille udfordring til fx. Linux-n?rder
Med lidt god vilje kan FreeBSDs jail-environment godt tage sig ud for
at vaere det du soeger. Men hvem gider dog at spilde tid paa saadan en
loesning?
--
j.
| |
Kall, Mogens (21-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 21-05-04 01:18 |
|
"Jesper Louis Andersen" skrev
news:7cesn1-64u.ln1@miracle.mongers.org
> > Med hensyn til OS. Hermed en lille udfordring til fx. Linux-n?rder
>
> Med lidt god vilje kan FreeBSDs jail-environment godt tage sig ud for
> at vaere det du soeger. Men hvem gider dog at spilde tid paa saadan en
> loesning?
Aner ikke hvad det er
Men jeg vil gerne lære noget om det.
Linux er for nørdet, og det må ændres, så vi andre tungnemme også kan komme
med forhåbentlig gode idéer
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2186
| |
Brian R. Jensen (20-05-2004)
| Kommentar Fra : Brian R. Jensen |
Dato : 20-05-04 07:38 |
|
"Kall, Mogens" <John@15.13> skrev i en meddelelse
news:HLHqc.12$Vf.796@news000.worldonline.dk...
> > Du vrøvler, sasser var ikke i stand til at omgå en firewall, faktisk
ville
> > de fleste standardkonfigurerede routere have stoppet den.
> >
> > Er du helt sikker på du ikke blander begreberne sammen? Det lyder som om
> > du har svært ved at skelne mellem firewalls og antivirus.
>
> Du misforstod mig.
Det tror jeg ikke, men det er muligt du skrev noget andet end du mente
> Mange computere blev inficseret med sasser. Når et maskinkode-program
først
> afvikles på en computer, er der INGEN begrænsninger for hvilke
operationer,
> der kan foretages. Man kan ændre eller slette filer på Harddiskene,
inficere
> MasterBootRecorden (ved mindre denne er skrivebeskyttet i
BIOS-opsætningen)
> eller BootRecorden osv. - eller oprette en bagdør (hvorved man går
*udenom*
> firewall'en).
Du skrev
<citat>
At din firewall virker i dag, er i sig selv INGEN garanti for at den virker
i morgen (et eksempel: Sasser, herefter oprettes bagdør).
</citat>
Og jeg gentager, selv en standard konfigureret router vil have stoppet den.
Selv en åben bagdør på din PC er uden effekt hvis den lytter på en port der
ikke er nattet i din fw/router.
Det er muligt din software"firewall" vil have problemer, men det ændre ikke
ved mit udsagn.
/Brian
| |
Kall, Mogens (20-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 20-05-04 12:55 |
|
"Brian R. Jensen" skrev
news:40ac523c$0$236$edfadb0f@dread16.news.tele.dk
[ ... ]
> > Du misforstod mig.
>
> Det tror jeg ikke, men det er muligt du skrev noget andet end du mente
Sikkert!
[ ... ]
> Du skrev
> <citat>
> At din firewall virker i dag, er i sig selv INGEN garanti for at den
> virker
> i morgen (et eksempel: Sasser, herefter oprettes bagdør).
> </citat>
>
> Og jeg gentager, selv en standard konfigureret router vil have stoppet
> den.
Sasser-ormen benyttede jeg blot for at anskueliggøre problemet. Når/dersom
angriberen først på den ene-eller-anden måde har fået adgang til din
computer og har haft held til at eksekvere en maskinkode, da vil angriberen
være i stand til at sætte både software-firewall'en ud af kraft og muligvis
omgås hardware-firewall'en (routeren) ved ganske simpelt at lave et opkald
ud-af-huset til angriberens såkaldte mellemled
Eksempelvis kunne jeg ... nej! Det må jeg hellere holde mund med.
(folk kunne jo få gode idéer).
> Selv en åben bagdør på din PC er uden effekt hvis den lytter på en port
> der ikke er nattet i din fw/router.
> Det er muligt din software"firewall" vil have problemer, men det ændre
> ikke ved mit udsagn.
(se ovenfor)
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2173
| |
Kasper Dupont (20-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 20-05-04 14:59 |
|
"Kall, Mogens" wrote:
>
> Sasser-ormen benyttede jeg blot for at anskueliggøre problemet. Når/dersom
> angriberen først på den ene-eller-anden måde har fået adgang til din
> computer og har haft held til at eksekvere en maskinkode,
Sasser slipper ind fordi der er en fejl i dit OS. Mere
præcist, så er det så vidt jeg har forstået i et library.
Det betyder at man udefra kan opnå kontrol over en af de
sårbare server processer.
På det sted havde det været muligt at stoppe ormen, så
den ikke kunne skade nogen filer på maskinen. Men man har
i sit design af systemet valgt at give disse processer
for mange privilegier.
Features i hardwaren til at beskytte dig hjælper kun,
hvis dit OS bruger dem rigtigt. Hardwaren har ikke bedre
viden om, hvad der skal beskyttes, end de oplysninger OS
giver.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Kall, Mogens (21-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 21-05-04 01:18 |
|
"Kasper Dupont" skrev
news:40ACB9BD.326D8C77@daimi.au.dk
> "Kall, Mogens" wrote:
> >
> > Sasser-ormen benyttede jeg blot for at anskueliggøre problemet.
> > Når/dersom
> > angriberen først på den ene-eller-anden måde har fået adgang til din
> > computer og har haft held til at eksekvere en maskinkode,
>
> Sasser slipper ind fordi der er en fejl i dit OS. Mere
> præcist, så er det så vidt jeg har forstået i et library.
> Det betyder at man udefra kan opnå kontrol over en af de
> sårbare server processer.
>
> På det sted havde det været muligt at stoppe ormen, så
> den ikke kunne skade nogen filer på maskinen. Men man har
> i sit design af systemet valgt at give disse processer
> for mange privilegier.
"Lidt" for mange beføjelser
Kan dette for øvrigt ændres ?
> Features i hardwaren til at beskytte dig hjælper kun,
> hvis dit OS bruger dem rigtigt. Hardwaren har ikke bedre
> viden om, hvad der skal beskyttes, end de oplysninger OS
> giver.
Der var en, der *plonk*-ede, blot fordi jeg sammenlignede problemstillingen
med et eksempel fra naturen. Men faktisk kan vi lære en hel del af naturen.
Den har jo immervæk eksisteret på hårde konkurrencebetingelser i mange år.
Der er - kort sagt - 2 måder at gribe problemet an på:
1.
At opnå immunitet.
2.
At holde sig isoleret.
Immuniteten opnår vi ved at holde os løbende opdateret med
anti-virusprogrammer osv.
Hardware-routere er for så vidt at holde sig isoleret.
Mit forslag er sådan set bare at udvide denne forsvarsstrategi til også at
omfatte *fysisk* skrive-beskyttelse af OS-filer (fx. kernel32.dll), som jo
alligevel ALDRIG bliver ændret. Herved har man en 100% garanti for, at ingen
fremmed-programmer har infekseret dem.
Jeg håber Linux-nørderne hopper med på idéen
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2189
| |
Kasper Dupont (21-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 21-05-04 07:36 |
|
"Kall, Mogens" wrote:
>
> "Kasper Dupont" skrev
> news:40ACB9BD.326D8C77@daimi.au.dk
>
> > På det sted havde det været muligt at stoppe ormen, så
> > den ikke kunne skade nogen filer på maskinen. Men man har
> > i sit design af systemet valgt at give disse processer
> > for mange privilegier.
>
> "Lidt" for mange beføjelser
>
> Kan dette for øvrigt ændres ?
På Linux og BSD er der nogen distributioner, som gør
en stor indsats for at begrænse services rettigheder.
Jeg har ikke hørt om tilsvarende tiltag til at
forbedre Windows.
Men da de fleste af disse services er overflødige er
en nemmere og mere sikker løsning at bare slå dem fra.
(Ikke nemt, bare nemmere end at ændre på, hvilke
rettigheder servicen har.)
>
> 1.
> At opnå immunitet.
Det opnås kun med fejlfri kode. Det er ikke realistisk.
Det næstbedste er at rette fejl så snart de bliver
opdaget.
At sammenligne med imunforsvaret beskytter sig på er
helt hen i vejret. Imunforsvaret er langt fra fejlfrit.
Der findes både falske positiver og falske negativer.
>
> 2.
> At holde sig isoleret.
Den løsning bliver tit foreslået.
>
> Immuniteten opnår vi ved at holde os løbende opdateret med
> anti-virusprogrammer osv.
Nej, glem antivirusprogrammet og hold dit OS opdateret
i stedet for.
>
> Hardware-routere er for så vidt at holde sig isoleret.
Nej. Der skal mere til at holde sig isoleret. Du kan
f.eks. trække netkablet ud.
>
> Mit forslag er sådan set bare at udvide denne forsvarsstrategi til også at
> omfatte *fysisk* skrive-beskyttelse af OS-filer (fx. kernel32.dll), som jo
> alligevel ALDRIG bliver ændret.
Den skal da udskiftes hver gang, der bliver fundet en
fejl i den.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Brian R. Jensen (20-05-2004)
| Kommentar Fra : Brian R. Jensen |
Dato : 20-05-04 18:19 |
|
"Kall, Mogens" <John@15.13> skrev i en meddelelse
news:_%0rc.509$Vf.13540@news000.worldonline.dk...
> > Du skrev
> > <citat>
> > At din firewall virker i dag, er i sig selv INGEN garanti for at den
> > virker
> > i morgen (et eksempel: Sasser, herefter oprettes bagdør).
> > </citat>
> >
> > Og jeg gentager, selv en standard konfigureret router vil have stoppet
> > den.
>
> Sasser-ormen benyttede jeg blot for at anskueliggøre problemet. Når/dersom
Hmm, så var det et meget dårligt eksempel, jeg forstor ihvertfald ikke hvad
du ville anskueliggøre.
> angriberen først på den ene-eller-anden måde har fået adgang til din
> computer og har haft held til at eksekvere en maskinkode, da vil
angriberen
> være i stand til at sætte både software-firewall'en ud af kraft og
muligvis
> omgås hardware-firewall'en (routeren) ved ganske simpelt at lave et opkald
> ud-af-huset til angriberens såkaldte mellemled
Det er der jo sådan set ikke meget nyt i, bortset fra at lige netop dit valg
af eksempel ikke virker på den måde, men det er en kendt sag at personlige
firewalls er trivielle at omgåes ved eksempelvis at kommunikere via Internet
Explorer eller andre godkendt programmer.
Men det er egentlig noget langt fra det indlæg jeg kommenterede oprindeligt,
sandsynligvis fordi du mener noget andet end det du skriver - og jeg kan kun
kommentere på det du skriver.
Jeg stopper denne del af tråden her, vi diskutere åbenbart ikke det samme.
/Brian
| |
Kasper Dupont (20-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 20-05-04 15:19 |
|
"Kall, Mogens" wrote:
>
> For at muliggøre dette, skal der foretages nogle ændringer i Hardwaren, men
> det må kunne lade sig gøre. Electric-eraseable-ROM kunne anvendes til at
> huske de skrivebeskyttede zoner (BIOS-opsætningen). Et lille
> maskinkodeprogram under BIOS kunne så tjekke, at der UDELUKKENDE foretages
> *oprettelse* af nye skrivebeskyttede zoner (og altså ikke omvendt).
Når først OS er startet har BIOS intet at skulle have
sagt mere. Alt hvad din BIOS kan gøre kan OS også gøre.
En mulig beskyttelse kunne fungere ved at have et
register på bundkortet, der kun kan nulstilles ved en
koldstart, og som kan sættes af BIOS inden kontrollen
overgives til OS.
Men en beskyttelse af harddisk på sektorniveau er ikke
realistisk. For det første ville det kræve store
ændringer af protokollen som disk og controller
kommunikerer med, med deraf følgende inkompatibilitet
og nye fejl (sikkerhedshuller).
Desuden ville det for de fleste filsystemer ikke være
praktisk. Man kunne måske beskytte de sektorer hvor en
given fil ligger, men så ændrer jeg bare i en
directory indgang eller FAT tabellen, så filen i stedet
bliver indlæst fra nogle andre sektorer.
En mere realistisk løsning (udfra hvad jeg har hørt,
jeg kender ikke til alle bits i IDE og SCSI protokollerne),
ville være en SCSI harddisk hvor skrivelinien til kablet
kunne afbrydes. Den mulighed eksisterer kun med SCSI,
det kan ikke lade sig gøre med IDE, fordi det fungerer
anderledes.
Så kunne man have en lille SCSI harddisk til sit OS, og
en større IDE harddisk til programmer og data. Så kunne
BIOS vha. et register på bundkortet slå skrivebeskyttelsen
til, som så kun kan slås fra ved en koldstart. BIOS skal
selvfølgelig give en mulighed for at boote uden at slå
skrivebeskyttelsen til.
Personligt ville jeg nok foretrække at skrivebeskyttelsen
blev styret med en kontakt.
Men du kan jo prøve at overbevise nogen motherboard-
producenter om, at det skulle laves. Jeg tror ikke, der er
et marked. Jeg ved heller ikke, hvordan man skulle få
sådan en maskine til at køre Windows, men jeg burde kunne
få Linux til at fungere.
>
> Med hensyn til OS. Hermed en lille udfordring til fx. Linux-nørder
Der er sådanset allerede lavet noget lidt hen i den
retning, som dog fungerer uden ændringer i hardwaren:
http://www.nsa.gov/selinux/index.cfm
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Kall, Mogens (21-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 21-05-04 01:18 |
|
"Kasper Dupont" skrev
news:40ACBE51.1927086C@daimi.au.dk
> "Kall, Mogens" wrote:
> >
> > For at muliggøre dette, skal der foretages nogle ændringer i Hardwaren,
> > men
> > det må kunne lade sig gøre. Electric-eraseable-ROM kunne anvendes til at
> > huske de skrivebeskyttede zoner (BIOS-opsætningen). Et lille
> > maskinkodeprogram under BIOS kunne så tjekke, at der UDELUKKENDE
> > foretages
> > *oprettelse* af nye skrivebeskyttede zoner (og altså ikke omvendt).
>
> Når først OS er startet har BIOS intet at skulle have
> sagt mere. Alt hvad din BIOS kan gøre kan OS også gøre.
Arh, du misforstår mig.
(jeg er desværre ikke så god til at forklare mig)
Vi har et *rent* OperativSystem.
Vi har ændret "lidt" i organiseringen mht. hvor filerne lægges på
HardDisken.
Og nu vil vi gerne beskytte, så meget af OS'et som overhovedet mulig.
Fordi vi kan sige *Okay* til systemets renhed, oprette fx. en fil (på HD
eller A-drev) med informationer om, hvilke HD-zoner, der skal
skrivebeskyttes. Og så Booter vi.
Under opstart omdirigerer vi programmet, fx. ligesom under BIOS-setup.
En valgmulighed her kunne så være, at denne fil indlæses, hvorefter HD'en
fremover er skrivebeskyttet i disse zoner, akkurart som MasterBootRecord
virus-protection. Filerne kan herefter aldrig úmiddelbart ændres af et
software-program (kun i BIOS-setup fx. kan genåbning foretages).
Herefter kører OS fuldstændig ligesom alle andre tidligere udgaver
-
Et nyt program (1) skal indlæses og dette ønskes ligeledes skrivebeskyttet!
Vi gentager proceduren som ovenfor beskrevet, men ... under BIOS-setup kan
vi *ikke* umiddelbart genåbne de allerede beskyttede zoner på HD'en.
Hvorfor ikke ?
Fordi vi måske ikke et 100% sikre på, at det nye program nu også et rent!
Derfor oprettes der blot en ny beskyttet zone til dette programs filer.
-
Faktisk fungerer dette system akkurart på samme måde, som når vi i et
laboratorium opretter sterile zoner.
-
Næste program (2) skal indlæses ... osv.
For at undgå eventuel *smittespredning* fra program (1) indlæses dette IKKE
under boot.
Men ellers foregår alting på samme måde.
-
Ligeledes med program (3) ... osv.
-
Under normal program-afvikling kan et nyt program altid afprøves - UDEN at
den kommer under beskyttelsesproceduren, akkurart for det normalt foregår på
computeren.
Sidenhen kan man så vælge at beskytte programmet.
**************************************
Det var blot et forslag
**************************************
> En mulig beskyttelse kunne fungere ved at have et
> register på bundkortet, der kun kan nulstilles ved en
> koldstart, og som kan sættes af BIOS inden kontrollen
> overgives til OS.
Jeg har tabt tråden
Hvad skulle dette register foretage ?
HardDisk-kontrol ?
> Men en beskyttelse af harddisk på sektorniveau er ikke
> realistisk. ...
Nej - det er for omfattende.
Jeg vil foreslå 10-20 MByte af gangen.
På en ældre HD giver det ca. 1000 enheder.
> ... For det første ville det kræve store
> ændringer af protokollen som disk og controller
> kommunikerer med, med deraf følgende inkompatibilitet
> og nye fejl (sikkerhedshuller).
Her må jeg melde pas (det har jeg ikke forstand på).
> Desuden ville det for de fleste filsystemer ikke være
> praktisk. Man kunne måske beskytte de sektorer hvor en
> given fil ligger, men så ændrer jeg bare i en
> directory indgang eller FAT tabellen, så filen i stedet
> bliver indlæst fra nogle andre sektorer.
>
> En mere realistisk løsning (udfra hvad jeg har hørt,
> jeg kender ikke til alle bits i IDE og SCSI protokollerne),
> ville være en SCSI harddisk hvor skrivelinien til kablet
> kunne afbrydes. ...
Men ville du så her have en on/off swiths, der tænder og slukker alt efter,
hvor der læses/skrives på Scasi-HD'en ?
> ... Den mulighed eksisterer kun med SCSI,
> det kan ikke lade sig gøre med IDE, fordi det fungerer
> anderledes.
Men MBR-området kan jo godt beskyttes, så teknisk set må det da kunne lade
sig gøre.
> Så kunne man have en lille SCSI harddisk til sit OS, og
> en større IDE harddisk til programmer og data. ...
> ... Så kunne
> BIOS vha. et register på bundkortet slå skrivebeskyttelsen
> til, ...
.... under opstart formoder jeg
> ...som så kun kan slås fra ved en koldstart. BIOS skal
> selvfølgelig give en mulighed for at boote uden at slå
> skrivebeskyttelsen til.
>
> Personligt ville jeg nok foretrække at skrivebeskyttelsen
> blev styret med en kontakt.
Med nøgle
> Men du kan jo prøve at overbevise nogen motherboard-
> producenter om, at det skulle laves. Jeg tror ikke, der er
> et marked. Jeg ved heller ikke, hvordan man skulle få
> sådan en maskine til at køre Windows, ...
Det bliver deres problem
> ... men jeg burde kunne
> få Linux til at fungere.
Det lyder RIGTIG spændende!!!
> > Med hensyn til OS. Hermed en lille udfordring til fx. Linux-nørder
>
> Der er sådanset allerede lavet noget lidt hen i den
> retning, som dog fungerer uden ændringer i hardwaren:
>
> http://www.nsa.gov/selinux/index.cfm
Det må jeg jo så sætte mig ind i
Tak for hjælpen
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2190
| |
Asbjorn Hojmark (19-05-2004)
| Kommentar Fra : Asbjorn Hojmark |
Dato : 19-05-04 07:22 |
|
On Tue, 18 May 2004 23:47:53 +0200, "Kall, Mogens" <John@15.13>
wrote:
> Eksempelvis kunne min internet-udbyder ("hypotetisk" set)
> muligvis nægte *al* kommunikation med de berørte servere ?
> - Kan det lade sig gøre, teknisk set ?
Ja.
-A
| |
Kim Ludvigsen (19-05-2004)
| Kommentar Fra : Kim Ludvigsen |
Dato : 19-05-04 07:54 |
|
Asbjorn Hojmark wrote:
>
> On Tue, 18 May 2004 23:47:53 +0200, "Kall, Mogens" <John@15.13>
> wrote:
>
> > Eksempelvis kunne min internet-udbyder ("hypotetisk" set)
> > muligvis nægte *al* kommunikation med de berørte servere ?
> > - Kan det lade sig gøre, teknisk set ?
>
> Ja.
Men Mogens kan opnå den samme effekt - endda meget hurtigere og uden en
masse skriverier - ved at trække netstikket ud af computeren. Og så
ville vi andre stadig have vores internet.
--
Mvh. Kim Ludvigsen
| |
Asbjorn Hojmark (19-05-2004)
| Kommentar Fra : Asbjorn Hojmark |
Dato : 19-05-04 08:02 |
|
On Wed, 19 May 2004 08:54:09 +0200, Kim Ludvigsen
<usenet@kimludvigsen.dk> wrote:
>>> Eksempelvis kunne min internet-udbyder ("hypotetisk" set)
>>> muligvis nægte *al* kommunikation med de berørte servere ?
>>> - Kan det lade sig gøre, teknisk set ?
>> Ja.
> Men Mogens kan opnå den samme effekt - endda meget hurtigere
> og uden en masse skriverier - ved at trække netstikket ud af
> computeren.
Ja, i tilfældet Mogens var det nok ikke det værste, han kunne
gøre, men det var ikke det der var spørgsmålet, og det var ikke
det, jeg svarede på.
-A
| |
Kall, Mogens (19-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 19-05-04 12:43 |
|
"Asbjorn Hojmark" skrev
news:95vla05b1mc7remmdb4nlcc1ujg7j22tja@news.sunsite.dk
> On Tue, 18 May 2004 23:47:53 +0200, "Kall, Mogens" <John@15.13>
> wrote:
>
> > Eksempelvis kunne min internet-udbyder ("hypotetisk" set)
> > muligvis nægte *al* kommunikation med de berørte servere ?
> > - Kan det lade sig gøre, teknisk set ?
>
> Ja.
Glæder mig at høre
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2156
| |
Alex Holst (18-05-2004)
| Kommentar Fra : Alex Holst |
Dato : 18-05-04 12:18 |
| | |
Michael Knudsen (18-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 18-05-04 14:09 |
|
| |
Christian E. Lysel (18-05-2004)
| Kommentar Fra : Christian E. Lysel |
Dato : 18-05-04 19:37 |
|
In article <Pine.GSO.4.50.0405181508380.13579-100000@fire2.cs.auc.dk>, Michael Knudsen wrote:
> Maaske var det Christians pointe.
Ja
--
Mvh.
Christian E. Lysel
http://www.spindelnet.dk/
| |
Martin Schultz (19-05-2004)
| Kommentar Fra : Martin Schultz |
Dato : 19-05-04 07:55 |
|
On Mon, 17 May 2004 23:49:52 +0200, Kall, Mogens wrote:
> Kender nogen noget til disse fjern-computere ?
>
>
> Med venlig hilsen
> Mogens Kall
> The servant of Michael
>
> Last-Informationfile:
> ( use http://www.google.dk/grphp )
> 1662 news:sbX3c.108512$jf4.6509896@news000.worldonline.dk
> 2124 news:HzXpc.164474$jf4.8497342@news000.worldonline.dk
>
> File-number:
> 2148
*plonk* Du er vist ude af stand til at forstå noget som helst.
Martin
--
Besøg http://www.adsltips.dk for guider til
ADSL og opsætning af Cisco/Zyxel routere.
| |
Michael Knudsen (19-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 19-05-04 19:12 |
|
| |
Kall, Mogens (19-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 19-05-04 21:06 |
|
"Michael Knudsen" skrev
news:Pine.GSO.4.50.0405192007050.3396-100000@fire2.cs.auc.dk
[ ... ]
> > Kan forfalskning også her muliggøres ?
>
> Ja.
>
> > Og i så fald, hvordan ?
>
> Der er to maader.
>
> 1. Scan paa traditionel vis, men send samtidig en masse pakker
> med forfalsket afsender. Modtageren kan ikke vide, hvilken der
> er den `aegte' scanner, eller om der i i det hele taget er tale
> om en portscanning. Det kan lige saa vel vaere mange, legale
> tilslutningsforsoeg.
>
> 2. Passiv/idle scan:
>
> http://www.insecure.org/nmap/idlescan.html
Nåh - det må jeg jo så lige sætte mig ind i
(øv - den er på engelsk, det forstår jeg ikke)
Tak, Michael.
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2165
| |
Kall, Mogens (20-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 20-05-04 00:58 |
|
"Michael Knudsen" skrev
news:Pine.GSO.4.50.0405192007050.3396-100000@fire2.cs.auc.dk
[ ... ]
> > Kan forfalskning også her muliggøres ?
>
> Ja.
>
> > Og i så fald, hvordan ?
>
> Der er to maader.
>
> 1. Scan paa traditionel vis, men send samtidig en masse pakker
> med forfalsket afsender. Modtageren kan ikke vide, hvilken der
> er den `aegte' scanner, eller om der i i det hele taget er tale
> om en portscanning. Det kan lige saa vel vaere mange, legale
> tilslutningsforsoeg.
>
> 2. Passiv/idle scan:
>
> http://www.insecure.org/nmap/idlescan.html
Nu har jeg læst lidt og forsøgt at forstå noget heraf
(mit engelsk er MEGET dårligt)
1.
Angriberen angriber først et forsvarsløst mellemled (Zombie).
2.
Zombie'ns IP-adresse benyttes herefter i angrebet.
(og det er denne IP-adresse, jeg registrerer)
3.
Angriberen indhenter oplysningerne herefter fra Zombie'n
Korrekt forstået ?
Hvis svaret herpå er *JA*, da kan man roligt klage over denne IP-adresse til
dets Internet-udbyder; idet
computeren jo benyttes af angriberen.
Internet-udbyderen til Zombie'n kan muligvis *spore* angriberens IP-adresse
via "korrespondancen" mellem angriberen og Zombie'n med henblik på
erstatningskrav!
Hvis jeg var Internet-udbyder ville jeg registrere "korrespondancerne",
således at jeg altid sidenhen kan efterspore *uønskede* elementer!!!
(man kan muligvis tjene MANGE penge på dette)
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2167
| |
Michael Knudsen (19-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 19-05-04 20:02 |
|
| |
Kasper Dupont (19-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 19-05-04 20:27 |
|
Michael Knudsen wrote:
>
> On Wed, 19 May 2004, Kasper Dupont wrote:
> > Det siges at file permissions i Linux blev
> > implementeret kort tid efter at Linus selv i December
> > 1991 ved en fejltagelse var kommet til at prøve at
> > ringe op vha. en harddisk partition i stedet for sit
> > modem.
>
> Der kan man tale om at laere paa den haarde maade. :)
Ja, det var et hel det var Minix der blev slettet og
ikke Linux.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Kall, Mogens (19-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 19-05-04 20:41 |
|
"Kall, Mogens" skrev
news:6saqc.164635$jf4.8542374@news000.worldonline.dk
[ ... ]
Hermed tillader jeg mig at offentliggøre yderligere hack'ning, således at
efterforskere i IT-kriminalitet har mulighed for at opsnappe mistænksomme
IP-adresser:
(for en god ordens skyld skal jeg oplyse, at jeg har blokeret så godt som
SAMTLIGE programmer på min computer med Internet-opkald. I samtlige
hacker-tilfælde er der tale om LIVE *portscanning*, hvorfor der IKKE kan
være tale om en såkaldt IP-adressefejl. Tidsintervallerne afslører
endvidere, at der er tale om et systematisk angreb)
(mit computer afviger med blot +/- nogle sekunder)
Dato: 18-05-2004 Klokkeslæt: 11:34:42
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.177.77.197,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.89.142,5000)
Fjernadresse, tjeneste er (62.177.77.197,1250)
Procesnavn er "N/A"
Dato: 18-05-2004 Klokkeslæt: 22:43:32
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.79.152.112,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.85.76,5000)
Fjernadresse, tjeneste er (62.79.152.112,3762)
Procesnavn er "N/A"
Dato: 18-05-2004 Klokkeslæt: 22:50:48
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.79.25.173,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.85.76,5000)
Fjernadresse, tjeneste er (62.79.25.173,1990)
Procesnavn er "N/A"
Dato: 18-05-2004 Klokkeslæt: 23:46:51
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.197.82.11,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.87.249,5000)
Fjernadresse, tjeneste er (62.197.82.11,4591)
Procesnavn er "N/A"
Dato: 18-05-2004 Klokkeslæt: 23:53:20
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.245.161.94,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.87.249,5000)
Fjernadresse, tjeneste er (62.245.161.94,2880)
Procesnavn er "N/A"
Dato: 19-05-2004 Klokkeslæt: 00:02:08
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.79.70.194,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.87.249,5000)
Fjernadresse, tjeneste er (62.79.70.194,3829)
Procesnavn er "N/A"
Dato: 19-05-2004 Klokkeslæt: 00:04:14
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.216.16.236,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.87.249,5000)
Fjernadresse, tjeneste er (62.216.16.236,1505)
Procesnavn er "N/A"
Dato: 19-05-2004 Klokkeslæt: 00:09:50
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.79.39.235,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.87.249,5000)
Fjernadresse, tjeneste er (62.79.39.235,1424)
Procesnavn er "N/A"
Dato: 19-05-2004 Klokkeslæt: 00:10:09
Regel "Bloker som standard Sokets de Trois v1. Trojan" blokeret
(62.57.84.250,5000). Detaljer:
Indkommende TCP-forbindelse
Lokal adresse, tjeneste er (62.79.87.249,5000)
Fjernadresse, tjeneste er (62.57.84.250,3253)
Procesnavn er "N/A"
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2164
| |
Kall, Mogens (19-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 19-05-04 21:06 |
|
"Kall, Mogens" skrev
news:RKOqc.114$Vf.7896@news000.worldonline.dk
[ ... ]
Shall we set on the "program", DAD ?
Date: 3. januar 2004 CET 16:56 (Winter-time)
Subject: Re: Evangelist Kristi
1125 news:GEBJb.66385$jf4.4258298@news000.worldonline.dk
DADDY-Break:
(2004-05-19, CET 21:47:1x)
- "Ja, gør det bare."
INT Ap.G. (Act) 13,11 "program" ON.
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2166
| |
Kim Ludvigsen (19-05-2004)
| Kommentar Fra : Kim Ludvigsen |
Dato : 19-05-04 21:15 |
|
Kall, Mogens wrote:
>
> "Kall, Mogens" skrev
>
> [ ... ]
> Hermed tillader jeg mig at offentliggøre yderligere hack'ning, således at
> efterforskere i IT-kriminalitet har mulighed for at opsnappe mistænksomme
> IP-adresser:
Jeg tror ikke, efterforskere i it-kriminalitet holder til her. Og hvis
de gør, så er de nok totalt ligeglade med din firewalls advarsler. Der
er flere af eksperterne i denne gruppe, der har plonket dig. Prøv og
tænk hårdt - og gerne længe - over hvorfor.
> (for en god ordens skyld skal jeg oplyse, at jeg har blokeret så godt som
> SAMTLIGE programmer på min computer med Internet-opkald. I samtlige
> hacker-tilfælde er der tale om LIVE *portscanning*, hvorfor der IKKE kan
> være tale om en såkaldt IP-adressefejl. Tidsintervallerne afslører
> endvidere, at der er tale om et systematisk angreb)
Systematiske angreb fra forskellige adresser, det er nogle skrappe
hackere, der er ude efter dig. Sagt på en anden måde:
Kære Mogens
Læs denne gruppes udmærkede OSS, ikke mindst afsnittene om personlige
firewalls. Du har fået links til de relevante afsnit flere gange, kig
tilbage i tråden eller i en af dine tidligere tråde. Jeg gider ærligt
talt ikke finde dem frem til dig igen.
Hvis du ikke kan forstå afsnittene, så læs dem igen og igen, indtil du
forstår dem. Hvis du stadig ikke forstår dem efter gentagne
gennemlæsninger, så spørg pænt her, om det du ikke forstår. Måske
teksten skal skrives i et mere pædagogisk sprog (omend alle andre
tilsyneladende godt kan forstå den). Og for alt i verden, stop med at
sende din firewalls advarsler til os. De rager os en høstblomst!
Chokolade, jeg må have noget chokolade (lys).
--
Mvh. Kim Ludvigsen
| |
Kall, Mogens (20-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 20-05-04 10:09 |
|
"Kim Ludvigsen" skrev
news:40ABC026.2FCA@kimludvigsen.dk
[ ... ]
> Jeg tror ikke, efterforskere i it-kriminalitet holder til her. Og hvis
> de gør, så er de nok totalt ligeglade med din firewalls advarsler.
Arh ... Dét skal du nu ikke være så sikker på.
Hvorfor ?
Fordi navnlig piratkopiering koster ophavsindehaverne MANGE penge.
Jeg har i hvert fald konstateret konkrete tilfælde, hvor såkaldte udsendte
agenter bl.a. herfra har forsøgt at lokke IP-adresser ud af folk på
Nyhedsgrupper, selvfølgelig med det formål - om muligt - at fange
forbryderne.
> ... Der
> er flere af eksperterne i denne gruppe, ...
Jeg var slet ikke klar over, at der deltager eksperter her i gruppen, men så
meget desto bedre
Så kan I nemlig godt følge mig i min tankegang:
Firewall er et defensivt forsvarssystem.
Jeg EFTERLYSER et *offensivt forsvarssystem*
Betragt mine offentliggørelser som et primitivt manuelt forsøg herpå, men
dét jeg egentlig ønsker, er et AUTOMATISK system:
1.
Dersom man kunne programmere firewall'en til automatisk at sende min
Internet-udbyder en meddelse om IP-adressen (angriberens computer-mellemled,
Zombie'n); da ville min Internet-udbyder have mulighed for ØJEBLIKKELIG at
*nægte* enhver kommunikation med denne IP-adresse, og dermed ville *alle*
kunderne/forbrugerne i selskabet præventivt blive beskyttet.
Mange forbrugere ville blive glade for en sådan tjeneste-ydelse, sågar
skifte selskab, dersom denne tjeneste ikke tilbydes. Så selskaberne har
altså af økonomiske grunde en interesse i at få udviklet dette system
2.
Min Internet-udbyder kunne sende klagen videre til den pågældende
IP-adresses Internet-udbyder. Herved kan dette selskab *overvåge* den
pågældende IP-adresse med henblik på at opsnappe kommunikation med
angriberen og dermed finde vedkommendes IP-adresse (angriberen bruger sikker
mange computer-mellemled for at skjule sig).
Nægter denne Internet-udbyderen at samarbejde (fordi vedkommende muligvis
i det skjulte er en del af angriber-systemet) kan denne Internet-udbyder
BOYKOTTES på globalt plan.
Dersom min Internet-udbyder ikke vil boykotte denne Internet-udbyder, er
det muligvis på tide at skifte Internet-udbyder-selskab. Konkurrenten er
mere forbrugervenlig
3.
Endvidere kunne min Internet-udbyder sende klagen til nyhedsgruppen
dk.edb.sikkerhed - nej, selvfølgelig ikke! - til et centralt register på
verdensplan. Herved kunne andre Internet-udbydere blive advaret (måske i
tide). Samtidig kan man få et samlet overblik over angriberne.
IT-kriminalitet kunne herved på længere sigt hæmmes.
Dette koster selvfølgelig nogle penge, men da pengeinstitutter også er
berørt af disse problemer, må investeringen betragtes som værende ret
beskeden sammenlignet med fordelene
Have a nice day, Sir!
With kind regards,
Mogens Kall
The servant of Michael
File-number:
2169
| |
Michael Knudsen (20-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 20-05-04 12:09 |
|
Kall, Mogens wrote:
>>Jeg tror ikke, efterforskere i it-kriminalitet holder til her. Og hvis
>>de gør, så er de nok totalt ligeglade med din firewalls advarsler.
>
>
> Arh ... Dét skal du nu ikke være så sikker på.
>
> Hvorfor ?
Fordi de allerede har travlt nok med at kigge paa sager, hvor folk som
dig selv sender ligegyldige logs fra ZoneAlarm og lignende produkter, de
ikke forstaar.
> Fordi navnlig piratkopiering koster ophavsindehaverne MANGE penge.
Dette har intet med _sikkerhed_ at goere.
> Jeg har i hvert fald konstateret konkrete tilfælde, hvor såkaldte udsendte
> agenter bl.a. herfra har forsøgt at lokke IP-adresser ud af folk på
> Nyhedsgrupper, selvfølgelig med det formål - om muligt - at fange
> forbryderne.
Det er noget _helt_ andet. Jeg siger det igen: Piratkopiering har lige
saa meget med sikkerhed at goere, som jeg har med dronningen (og det er
ikke meget, skal jeg hilse at sige).
>>... Der
>>er flere af eksperterne i denne gruppe, ...
>
>
> Jeg var slet ikke klar over, at der deltager eksperter her i gruppen, men så
> meget desto bedre
Du har efterhaanden optraadt saa uheldigt saa mange gange, at jeg vil
blive overrasket hvis ret mange af dem ikke allerede ignorerer dine
indlaeg vha. deres killfilter.
> Så kan I nemlig godt følge mig i min tankegang:
Overhovedet ikke. Den er hamrende naiv og baerer tydeligt praeg af din
manglende tekniske forstaaelse for nettets virkemaade og
sikkerhedsproblemer.
> Firewall er et defensivt forsvarssystem.
>
> Jeg EFTERLYSER et *offensivt forsvarssystem*
>
> Betragt mine offentliggørelser som et primitivt manuelt forsøg herpå, men
> dét jeg egentlig ønsker, er et AUTOMATISK system:
>
> 1.
> Dersom man kunne programmere firewall'en til automatisk at sende min
> Internet-udbyder en meddelse om IP-adressen (angriberens computer-mellemled,
> Zombie'n); da ville min Internet-udbyder have mulighed for ØJEBLIKKELIG at
> *nægte* enhver kommunikation med denne IP-adresse, og dermed ville *alle*
> kunderne/forbrugerne i selskabet præventivt blive beskyttet.
Har du stadig ikke laest afsnittet i OSS'en om spoofing?
http://sikkerhed-faq.dk/angreb/spoof
Lad os indfoere det system, du foreslaar. Jeg vil have dig pillet af
netvaerket, fordi jeg er en ond angriber. Hvad goer jeg saa? Jeg
begynder blot at portscanne en masse maskiner, men jeg soerger
naturligvis for at spoofe, saa det ser ud som om, at det er dig, der har
gjort det. Farvel, Mogens.
> Mange forbrugere ville blive glade for en sådan tjeneste-ydelse, sågar
> skifte selskab, dersom denne tjeneste ikke tilbydes. Så selskaberne har
> altså af økonomiske grunde en interesse i at få udviklet dette system
Der var nok efterhaanden kommet noget ud, hvis det ikke var fordi, at
det ikke er trivielt at opnaa.
> 2.
> Min Internet-udbyder kunne sende klagen videre til den pågældende
> IP-adresses Internet-udbyder. Herved kan dette selskab *overvåge* den
> pågældende IP-adresse med henblik på at opsnappe kommunikation med
> angriberen og dermed finde vedkommendes IP-adresse (angriberen bruger sikker
> mange computer-mellemled for at skjule sig).
Vi skal have halvdelen af kloden ansat ved internetudbyderne, hvis vi
skulle overvaage alle de IP-adresser, som du og andre mistaenker for
hacking, fordi I ikke har forstaaet at slaa loggen i jeres firewall fra.
> Nægter denne Internet-udbyderen at samarbejde (fordi vedkommende muligvis
> i det skjulte er en del af angriber-systemet) kan denne Internet-udbyder
> BOYKOTTES på globalt plan.
Jeg tror ikke, at du er klar over, hvor meget politik der ligger i at
goere det.
> 3.
> Endvidere kunne min Internet-udbyder sende klagen til nyhedsgruppen
> dk.edb.sikkerhed - nej, selvfølgelig ikke! - til et centralt register på
> verdensplan. Herved kunne andre Internet-udbydere blive advaret (måske i
Hah, tror du selv paa, at alle verdens internetudbydere kan blive enige
om et centralt register over blacklistede IP-numre? Hvis man kunne
dette, havde problemet med spam nok vaeret noget mindre, end det er i dag.
Der ville ogsaa vaere kolossale sikkerhedsspoergsmaal ved at have dette.
Hvordan forhindrer man, at uskyldige ikke kommer i registret? Igen, hvis
man kan snyde dette system, saa goer jeg, den onde angriber dette, og
faar placeret dig og CCU i systemet, og saa har I svaert ved at bruge
jeres netforbindelse.
> tide). Samtidig kan man få et samlet overblik over angriberne.
> IT-kriminalitet kunne herved på længere sigt hæmmes.
> Dette koster selvfølgelig nogle penge, men da pengeinstitutter også er
> berørt af disse problemer, må investeringen betragtes som værende ret
> beskeden sammenlignet med fordelene
Jeg tror nu nok, at pengeinstitutterne gerne _selv_ vil kunne bestemme,
om de vil snakke med et givet IP-nummer eller ej.
Mvh. Michael.
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)
| |
Kall, Mogens (21-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 21-05-04 01:19 |
|
"Michael Knudsen" skrev
news:40ac91b1$0$3045$14726298@news.sunsite.dk
[ ... ]
> > Fordi navnlig piratkopiering koster ophavsindehaverne MANGE penge.
>
> Dette har intet med _sikkerhed_ at goere.
Nej - ikke umiddelbart, men hackere har det jo med at lave andre
ulovligheder såsom piratkopiering
[ ... ]
> Du har efterhaanden optraadt saa uheldigt saa mange gange, at jeg vil
> blive overrasket hvis ret mange af dem ikke allerede ignorerer dine
> indlaeg vha. deres killfilter.
Det bliver jo så deres problem
>
> > Så kan I nemlig godt følge mig i min tankegang:
>
> Overhovedet ikke. Den er hamrende naiv og baerer tydeligt praeg af din
> manglende tekniske forstaaelse for nettets virkemaade og
> sikkerhedsproblemer.
Men jeg er jo nu TVUNGET til at lære lidt om det
> > Firewall er et defensivt forsvarssystem.
> >
> > Jeg EFTERLYSER et *offensivt forsvarssystem*
> >
> > Betragt mine offentliggørelser som et primitivt manuelt forsøg herpå,
> > men dét jeg egentlig ønsker, er et AUTOMATISK system:
> >
> > 1.
> > Dersom man kunne programmere firewall'en til automatisk at sende min
> > Internet-udbyder en meddelse om IP-adressen (angriberens
> > computer-mellemled,
> > Zombie'n); da ville min Internet-udbyder have mulighed for ØJEBLIKKELIG
> > at
> > *nægte* enhver kommunikation med denne IP-adresse, og dermed ville
> > *alle*
> > kunderne/forbrugerne i selskabet præventivt blive beskyttet.
>
> Har du stadig ikke laest afsnittet i OSS'en om spoofing?
>
> http://sikkerhed-faq.dk/angreb/spoof
Jo, jo - men jeg har dårlig indlæring. Jeg glemmer det, jeg lige har lært
> Lad os indfoere det system, du foreslaar. Jeg vil have dig pillet af
> netvaerket, fordi jeg er en ond angriber. Hvad goer jeg saa? Jeg
> begynder blot at portscanne en masse maskiner, men jeg soerger
> naturligvis for at spoofe, saa det ser ud som om, at det er dig, der har
> gjort det. Farvel, Mogens.
Heri har du ret, så dét var en dårlig idé
(Jamen så må vi finde på noget nyt)
Min Internet-udbyder bliver kontaktet, og denne har nu mulighed for at se
*hvorfra* meddelsen kom (det er IKKE IP-adressen jeg her taler om). En eller
anden computer må jo have videre-bragt pakken. Denne instans kunne så
kontaktes ... og så fremdeles.
Gradvis indkredses den egentlige afsender, navnlig hvis du hele tiden bruger
min IP-adresse
Var det for øvrigt ikke netop tilfældet med Sasser-ormens ophavsmand ?
> > Mange forbrugere ville blive glade for en sådan tjeneste-ydelse,
> > sågar
> > skifte selskab, dersom denne tjeneste ikke tilbydes. Så selskaberne har
> > altså af økonomiske grunde en interesse i at få udviklet dette system
> >
>
> Der var nok efterhaanden kommet noget ud, hvis det ikke var fordi, at
> det ikke er trivielt at opnaa.
Det er jo dét, vi nu skal forsøge på
*offensivt forsvarssystem*
> > 2.
> > Min Internet-udbyder kunne sende klagen videre til den pågældende
> > IP-adresses Internet-udbyder. Herved kan dette selskab *overvåge* den
> > pågældende IP-adresse med henblik på at opsnappe kommunikation med
> > angriberen og dermed finde vedkommendes IP-adresse (angriberen bruger
> > sikker mange computer-mellemled for at skjule sig).
>
> Vi skal have halvdelen af kloden ansat ved internetudbyderne, hvis vi
> skulle overvaage alle de IP-adresser, som du og andre mistaenker for
> hacking, fordi I ikke har forstaaet at slaa loggen i jeres firewall fra.
Nej. Faktisk havde jeg tænkt mig at automatisere det, således at det er
nogle maskiner, der foretager disse eftersporingen. De er billigere og mere
effektive i drift
> > Nægter denne Internet-udbyderen at samarbejde (fordi vedkommende
> > muligvis
> > i det skjulte er en del af angriber-systemet) kan denne Internet-udbyder
> > BOYKOTTES på globalt plan.
>
> Jeg tror ikke, at du er klar over, hvor meget politik der ligger i at
> goere det.
Skal vi X-poste i dk.politik ?
> > 3.
> > Endvidere kunne min Internet-udbyder sende klagen til nyhedsgruppen
> > dk.edb.sikkerhed - nej, selvfølgelig ikke! - til et centralt register på
> > verdensplan. Herved kunne andre Internet-udbydere blive advaret (måske i
>
> Hah, tror du selv paa, at alle verdens internetudbydere kan blive enige
> om et centralt register over blacklistede IP-numre? Hvis man kunne
> dette, havde problemet med spam nok vaeret noget mindre, end det er i dag.
Med tiden vil man muligvis *forlange* det som forbrugere. Ombudsmanden ér
allerede sat ind i Spam-problematikken!
> Der ville ogsaa vaere kolossale sikkerhedsspoergsmaal ved at have dette.
> Hvordan forhindrer man, at uskyldige ikke kommer i registret?
Hvis jeg kan slippe af med bæsterne, er jeg ikke chikaneret meget af en
lille overvågning. Jeg har rent mel i posen
> Igen, hvis
> man kan snyde dette system, saa goer jeg, den onde angriber dette, og
> faar placeret dig og CCU i systemet, og saa har I svaert ved at bruge
> jeres netforbindelse.
CCU - hvem eller hvad er det ?
> > tide). Samtidig kan man få et samlet overblik over angriberne.
> > IT-kriminalitet kunne herved på længere sigt hæmmes.
> > Dette koster selvfølgelig nogle penge, men da pengeinstitutter også
> > er
> > berørt af disse problemer, må investeringen betragtes som værende ret
> > beskeden sammenlignet med fordelene
>
> Jeg tror nu nok, at pengeinstitutterne gerne _selv_ vil kunne bestemme,
> om de vil snakke med et givet IP-nummer eller ej.
Sikkert
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2191
| |
Kasper Dupont (21-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 21-05-04 07:48 |
|
"Kall, Mogens" wrote:
>
> "Michael Knudsen" skrev
> news:40ac91b1$0$3045$14726298@news.sunsite.dk
>
> [ ... ]
> > > Fordi navnlig piratkopiering koster ophavsindehaverne MANGE penge.
> >
> > Dette har intet med _sikkerhed_ at goere.
>
> Nej - ikke umiddelbart, men hackere har det jo med at lave andre
> ulovligheder såsom piratkopiering
Dokumentation?
>
> Min Internet-udbyder bliver kontaktet, og denne har nu mulighed for at se
> *hvorfra* meddelsen kom (det er IKKE IP-adressen jeg her taler om). En eller
> anden computer må jo have videre-bragt pakken. Denne instans kunne så
> kontaktes ... og så fremdeles.
Du har vist lige glemt at overveje, hvor mange skridt
der er på vejen. Her er lige et eksempel på et output
fra traceroute. 17 routere på vejen. Og jeg kan enda
ikke vide, om der kan være nogle tunneller, så der i
virkeligheden er endnu flere.
traceroute to 62.79.89.115 (62.79.89.115), 30 hops max, 40 byte packets
1 10.11.0.1 904.371 ms 899.117 ms 811.696 ms
2 10.250.0.177 8.793 ms 10.093 ms 7.435 ms
3 62.242.107.17 7.588 ms 22.382 ms 231.701 ms
4 195.249.14.153 6.083 ms 7.828 ms 7.701 ms
5 195.249.7.118 27.677 ms 36.069 ms 127.514 ms
6 195.249.7.238 91.230 ms 117.854 ms 224.021 ms
7 80.63.80.122 489.302 ms 509.718 ms 561.037 ms
8 83.88.0.78 513.752 ms 484.759 ms 498.768 ms
9 192.38.7.61 593.544 ms 509.329 ms 608.407 ms
10 213.200.73.6 524.086 ms 668.708 ms 592.996 ms
11 212.54.86.42 704.343 ms 604.225 ms 494.116 ms
12 213.237.127.60 701.780 ms 388.958 ms 615.189 ms
13 213.237.127.104 738.322 ms 858.443 ms 716.563 ms
14 213.237.127.109 624.179 ms 829.928 ms 830.204 ms
15 213.237.127.1 904.062 ms 694.107 ms 839.688 ms
16 213.237.5.73 965.191 ms 896.342 ms 874.608 ms
17 213.237.5.73 1025.237 ms !H 1000.574 ms !H *
Husk på, at ingen af disse routere er i stand til at
logge alt trafikken. Så du er nødt til at have fat i
dem enkeltvis og finde ud af, hvor trafikken kommer
fra. Og det skal ske mens det står på.
Hvis du først går i gang når trafikken er ophørt kan
du prøve at undersøge, hvor den kunne være kommet fra.
Så er der pludslig mange flere muligheder.
En bedre løsning ville være, at bare forhindre pakker
med spoofet afsender. Nogle udbydere forhindre deres
kunder i at sende pakker med spoofet afsender IP. Men
så længe man kan finde en udbyder, der ikke forhindre
det, så kan man ikke gardere sig mod spoofet source.
>
> Gradvis indkredses den egentlige afsender, navnlig hvis du hele tiden bruger
> min IP-adresse
Muligt i teorien. Men næppe i praksis. Det er nemmere
at forhindre det end at prøve at spore det.
>
> Var det for øvrigt ikke netop tilfældet med Sasser-ormens ophavsmand ?
Nej, han blev snuppet fordi han ikke kunne holde sin
kæft. Han gik og pralede med sin præstation, og så
var der nogen, der ikke kunne stå for fristelsen med
de dusører, der plejede at blive udlovet.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Asbjorn Hojmark (20-05-2004)
| Kommentar Fra : Asbjorn Hojmark |
Dato : 20-05-04 17:35 |
|
On Thu, 20 May 2004 11:09:18 +0200, "Kall, Mogens" <John@15.13>
wrote:
> Jeg har i hvert fald konstateret konkrete tilfælde, hvor såkaldte
> udsendte agenter bl.a. herfra har forsøgt at lokke IP-adresser ud
> af folk på Nyhedsgrupper
Der er ikke meget grund til at lokke. Du har fx 62.79.89.161
(eller havde det i hvert fald, da du sendte beskeden). Det står i
headeren på dit indlæg.
Hvis du laver noget, du ikke må, kan de få en dommerkendelse til
at få Tiscali til at fortælle dem, hvem der har den adresse
(eller havde det på det tidspunkt).
-A
| |
Kall, Mogens (21-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 21-05-04 01:19 |
|
"Asbjorn Hojmark" skrev
news:hdnpa0t2qh949all262imr81kgk1klmrjl@news.sunsite.dk
> > Jeg har i hvert fald konstateret konkrete tilfælde, hvor såkaldte
> > udsendte agenter bl.a. herfra har forsøgt at lokke IP-adresser ud
> > af folk på Nyhedsgrupper
>
> Der er ikke meget grund til at lokke. Du har fx 62.79.89.161
> (eller havde det i hvert fald, da du sendte beskeden). Det står i
> headeren på dit indlæg.
>
> Hvis du laver noget, du ikke må, kan de få en dommerkendelse til
> at få Tiscali til at fortælle dem, hvem der har den adresse
> (eller havde det på det tidspunkt).
Jamen de bor her skam allerede; fast inventar
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2193
| |
Jesper Louis Anderse~ (20-05-2004)
| Kommentar Fra : Jesper Louis Anderse~ |
Dato : 20-05-04 17:26 |
|
Kall, Mogens <John@15.13> wrote:
>
> Firewall er et defensivt forsvarssystem.
>
> Jeg EFTERLYSER et *offensivt forsvarssystem*
En stor del af det du skriver er helt hen i vejret, fordi det
ikke kan lade sig goere med internettet. Det fungerer anderledes
i praksis.
Jeg vil ogsaa godt have gjort op med din misopfattelse af en firewall
som et defensivt forsvarssystem. Der er nok mange sikkerhedsfirmaer,
der godt vil have dig til at opfatte en firewall som en saadan, men
virkeligheden er noget simplere.
En firewall er bare en del af dit system, der er i stand til at filtrere
netvaerkstrafik udfra nogle angivne kriterier sat op af producenten eller
dig selv. Intet andet.
--
j.
| |
Kall, Mogens (21-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 21-05-04 01:19 |
|
"Jesper Louis Andersen" skrev
news:8q2vn1-tlj.ln1@miracle.mongers.org
> > Firewall er et defensivt forsvarssystem.
> >
> > Jeg EFTERLYSER et *offensivt forsvarssystem*
>
> En stor del af det du skriver er helt hen i vejret, fordi det
> ikke kan lade sig goere med internettet. Det fungerer anderledes
> i praksis.
>
> Jeg vil ogsaa godt have gjort op med din misopfattelse af en firewall
> som et defensivt forsvarssystem. Der er nok mange sikkerhedsfirmaer,
> der godt vil have dig til at opfatte en firewall som en saadan, men
> virkeligheden er noget simplere.
>
> En firewall er bare en del af dit system, der er i stand til at filtrere
> netvaerkstrafik udfra nogle angivne kriterier sat op af producenten eller
> dig selv. Intet andet.
Og dermed sagt, er der ENDNU mere behov for et *offensivt forsvarssystem*
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2192
| |
Anders Nielsen (20-05-2004)
| Kommentar Fra : Anders Nielsen |
Dato : 20-05-04 21:38 |
|
Er der dømt Bo Warming ell. !?!? måske bare troll :-/
| |
Kall, Mogens (20-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 20-05-04 16:08 |
|
"Kall, Mogens" skrev
news:RKOqc.114$Vf.7896@news000.worldonline.dk
[ ... ]
Oh - I see, You don't like, I'm following Your "footsteps".
There is no server-informations in regard to "Your" IP-adrress 62.42.77.62
(2004-05-20, CET 16:46:08)
.... when I'm useing http://www.dnsstuff.com/
I hope You understand the rule of the "game" ?
Input memory:
Date: 19. maj 2004 CET 22:06
Subject: Re: Hacher-angreb
2166 news:27Pqc.125$Vf.8762@news000.worldonline.dk
(If You wanna die; it's Your problem; not mine)
-
Er der nogen her på dk.edb.sikkerhed som kan foreslå en alternativ
server-søger ?
På forhånd mange tak
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2177
| |
a servant of Isa, Ye~ (24-05-2004)
| Kommentar Fra : a servant of Isa, Ye~ |
Dato : 24-05-04 10:52 |
|
"Kall, Mogens" skrev
news:BR3rc.772$Vf.14362@news000.worldonline.dk
[ ... ]
There is NO such kind of informations on my HardDisk
I give You a little help now, where You shall look ...
(code: AIRPORT de la MaTT 24,28)
Win (vind) 1000 Danish Kr. (around 140 US $), jump ...
2233 news:Gb3sc.1684$Vf.53534@news000.worldonline.dk
If You can crack the code, You will understand a lot more about "them"
File 2244, 2246, 2248, 2250, 2251, 2252 and 2253
can also help You to understand, what's going on
I want You to *use* Your brain
(be smart)
Med venlig hilsen
Mogens Kall
The servant of Michael
Last-Informationfile:
( use http://www.google.dk/grphp )
1662 news:sbX3c.108512$jf4.6509896@news000.worldonline.dk
2254 news:eAjsc.1939$Vf.82865@news000.worldonline.dk
File-number:
2255
| |
Michael Knudsen (20-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 20-05-04 01:24 |
|
| |
Kall, Mogens (20-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 20-05-04 12:54 |
|
"Michael Knudsen" skrev
news:Pine.GSO.4.50.0405200205160.9518-100000@fire2.cs.auc.dk
[ ... ]
> On Thu, 20 May 2004, Kall, Mogens wrote:
> > I Windows 2000 og XP skal man så igennem en hel procedure af API-opkald,
> > førend man får tilladelse til dit og dat, men det er og bliver blot et
> > software-mæssigt problem, desværre
>
> Hvis du tror, at det er et trivielt problem at omgaa sikkerhedsmodellen
> i Windows 2000 etc., saa er jeg bange for, at du tager grueligt fejl.
>
> Systemet er lavet paa en saadan maade, at du simpelthen ikke faar adgang
> til de ting, der er paakraevet for at gaa udenom sikkerhedsmodellen.
> Dette er delvist implementeret i hardware gennem e.g. forskellig grad af
> privilegier i CPU'en, beskyttet hukommelse saa en proces ikke kan laese
> og skrive vilkaarlige steder i hukommelsen og lignende.
Korrekt!
Men du kan vel sagtens få tilladelse til at overskrive de almindelige filer
ikke tilhørende OS.
Men mange små firmaer har således formodentlig mistet kostbar DATA.
> Hvis man skal omgaa sikkerhedsmodellen, er der to muligheder:
>
> 1. Man skal udnytte en designfejl.
> 2. Man skal udnytte en programmeringsfejl.
>
> Design-fejl er jeg skeptiske overfor at finde, men jeg har ikke kigget
> naermere paa det. Programmeringsfejl er langt det mest sandsynlige.
Og disse er (ikke fordi jeg kender disse) ... hvilket vi ikke taler om her
> > Dét, jeg taler om, er en gang for alle at løse problemet
> > hardware-mæssigt
>
> Der er ingen forskel paa hardware og software set ud fra et
> funktionalitetssynspunkt. ...
Okay (synspunkter er der jo nok af).
> ... Praecis de samme fejl kan optraede i en
> hardwareimplementation.
Forklar dette nærmere ?
> ... Forskellen er blot, at det er langt mere
> besvaerligt at rette fejl i hardware, og det koster ogsaa langt mere.
Men DATA-sikkerheden er ved hardware langt mere sikker (worst case).
Indbrudstyven ér kommet ind i systemet men kan ikke gøre nogen vital skade,
akkurart som i en bank, hvor tyvene godt nok er kommet ind i bygningen men
endnu ikke kan stjæle noget (først skal den armerede dør i kælderen brydes
op, og derefter skal hver enkelt box herinde brydes op, førend man kan
stjæle)
Hver gang der kommer et nyt computer-virus på markedet (og
anti-virus-firmaerne endnu ikke registreret det), så har forbrugerne et
alvorligt problem!
Ved hardware-sikring derimod har du ALTID en anti-virus-strategi liggende
parat!
> Hvordan vil du sikre dig, at man ikke laver de samme programmeringsfejl
> i en givet hardwareimplementation? ...
(se ovenfor. Jeg må have forklaret noget desangående, inden jeg udtaler mig)
(dersom jeg har forstået dig korrekt:)
Nogle bundkort har en manuel jumper, dersom brugeren ønsker at opgradere
BIOS-maskinkoden. Ændringen kan kun således ske, dersom bruger *bevidst*
flytter denne jumper. Herved skulle det teknisk set være mulig at korrigere
eventuelle programmeringsfejl.
> ... Man kan ogsaa lige saa let lave en
> designfejl i et stykke hardware (RTL8139 er et glimrende bevis paa
> designfejl, i oevrigt), saa du vinder reelt intet udover besvaer og oeget
> produktionspris, og det er ikke just den vej, man ser markedet gaa for
> tiden.
Nogle vil gerne betale lidt ekstra for denne forebyggelse
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2171
| |
Kasper Dupont (20-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 20-05-04 14:39 |
|
"Kall, Mogens" wrote:
>
> Men du kan vel sagtens få tilladelse til at overskrive de almindelige filer
> ikke tilhørende OS.
Det kommer da fuldstændig an på operativsystemet. På de
systemer jeg bruger kan jeg kun overskrive de filer,
jeg har skriverettigheder til. Som udgangspunkt har jeg
kun skriverettigheder til de filer, jeg selv opretter.
>
> Men DATA-sikkerheden er ved hardware langt mere sikker
Hvadfor hardware? I nogen tilfælde vil en hardware
løsning være at foretrække. F.eks. ved firewalls.
Men når vi snakker om at beskytte filer er en hardware
løsning ikke mulig. Hardwaren kender af gode grunde
ikke til systemets filbegreb. Så man er altså nødt til
at arbejde på et lidt lavere niveau.
Du kan allerede få en udmærket hardware beskyttelse af
dit OS i dag. Brænd OS på en CDRW disk og sæt den i et
CD-ROM drev, der fysisk er ude af stand til at skrive på
den.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Kall, Mogens (21-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 21-05-04 01:18 |
|
"Kasper Dupont" skrev
news:40ACB507.BFF3322@daimi.au.dk
[ ... ]
> > Men DATA-sikkerheden er ved hardware langt mere sikker
>
> Hvadfor hardware? ...
Jeg nævnte i en tidligere tråd, at ...
Date: 19. maj 2004 CET 13:43
news:HLHqc.12$Vf.796@news000.worldonline.dk
=== citat start ===
Forebyggelse
--------------
For at *forebygge* dette, bør man have en Harddisk med skrivebeskyttede
zoner, således at Operativsystemet ALTID under opstart indlæser filerne fra
disse sikre zoner ... osv.
=== citat slut ===
> ... I nogen tilfælde vil en hardware
> løsning være at foretrække. F.eks. ved firewalls.
Korrekt, den kan ikke infekeres.
> Men når vi snakker om at beskytte filer er en hardware
> løsning ikke mulig. Hardwaren kender af gode grunde
> ikke til systemets filbegreb. ...
Fuldstændig korrekt.
Og derfor taler jeg om, at vi skal ændre OS'erne, så de er mere fleksible
end de er i dag.
Måske er det lidt OFF-tropic, men medens vi er ved emnet, så efterlyser jeg
et OS, som vi også kan få op at køre igen under Worst-Case tilfældene. Det
kan fx. være en computers HD, der er gået i stykker på en robot på Mars
eller Månen, eller en vejrstation på Antarktis, en "Tjernobyl"-robot,
"ebola"-robot osv.
Mig bekendt benytter alle systemer *altid* HD'ens side 0, spor 0, sektor
1 til MBR'en. Og det er idiotisk, når/dersom netop lige denne zone er gået i
stykker. Så er HD'en ubrugelig. Det skal være et mere fleksibelt system.
HD'en skal bruges ligesom en bog, hvor side 1-10 kan mangle, og så kan man
benytte side 11 som sin start-side (MBR'en). Hardwaren til HD'en skal altså
først tjekke om side 0, spor 0, sektor 1 *faktisk* er den benyttede MBR.
Dersom sektor 3 kan identificeres med MBR-indhold, da er konklusionen jo, at
denne erstatter den oprindelige. Denne kan også være nedslidt, derfor
tjekkes sektor 5 osv. indtil indholdet IKKE er identisk med MBR'en.
Alternativet hertil er, at et udvalgt område på HD'en reserveres til
MBR-adresse memory. Området slides ikke op, idet bit-ændringer her kun
foretages, når/dersom der er opstået problemer med HD'en. Området skal
selvfølgelig være skrivebeskyttet efter BIOS-opkoblingen
> ... Så man er altså nødt til
> at arbejde på et lidt lavere niveau.
>
> Du kan allerede få en udmærket hardware beskyttelse af
> dit OS i dag. Brænd OS på en CDRW disk og sæt den i et
> CD-ROM drev, der fysisk er ude af stand til at skrive på
> den.
Tænk, det siger du ikke - jeg anvender faktisk systemet præventivt
(og det er forøvrigt derfor min HD opslides)
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2184
| |
Michael Knudsen (20-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 20-05-04 15:42 |
|
Kall, Mogens wrote:
>>... Praecis de samme fejl kan optraede i en
>>hardwareimplementation.
>
>
> Forklar dette nærmere ?
Naar man skriver et program i software og udforer det paa en processer,
henter processoren en instruktion. Den finder ud af, hvilken instruktion
der er tale om, og derefter udfoeres den. Dette gentager sig, til
programmet eventuelt er faerdigt.
Naar dette foregaar ``i hardware'', sker praecis det samme, bortset fra
at funktionaliteten er ``braendt ned i silicium''.
Hvis man har lavet en programmeringsfejl, vil programmet udfoert ``i
software'' ikke opfoere sig korrekt. Hvis man har lavet en fejl, da man
har lavet hardwaren, vil hardwareprogrammet opfoere sig forkert.
Software eller hardware, begge dele er et program, og det kan der vaere
fejl i. Et andet sted naevner kasper F00F-fejlen i Pentium, og det er et
glimrende eksempel paa, at der ogsaa kan vaere fejl i hardwarelogik.
>>Hvordan vil du sikre dig, at man ikke laver de samme programmeringsfejl
>>i en givet hardwareimplementation? ...
>
>
> (se ovenfor. Jeg må have forklaret noget desangående, inden jeg udtaler mig)
>
> (dersom jeg har forstået dig korrekt:)
> Nogle bundkort har en manuel jumper, dersom brugeren ønsker at opgradere
> BIOS-maskinkoden. Ændringen kan kun således ske, dersom bruger *bevidst*
> flytter denne jumper. Herved skulle det teknisk set være mulig at korrigere
> eventuelle programmeringsfejl.
Hvordan sikrer du dig, at den softwareopdatering du henter er den
korrekte? At den bliver skrevet korrekt i hardwaren?
>>... Man kan ogsaa lige saa let lave en
>>designfejl i et stykke hardware (RTL8139 er et glimrende bevis paa
>>designfejl, i oevrigt), saa du vinder reelt intet udover besvaer og oeget
>>produktionspris, og det er ikke just den vej, man ser markedet gaa for
>>tiden.
>
>
> Nogle vil gerne betale lidt ekstra for denne forebyggelse
Det er langt under flertallet, gaetter jeg paa. Hr. og Fr. Jensen vil
have en billig computer, hvor de skal goere minimum indsats for at holde
den opdateret. Banker, som du saa gladeligt bruger som eksempel, vil
maaske gerne bruge flere penge, naar de indkoeber hardware, men de har
ressourcer til at haandtere sikkerheden paa en anden maade.
Mvh. Michael.
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)
| |
Kall, Mogens (21-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 21-05-04 01:18 |
|
"Michael Knudsen" skrev
news:40acc3b9$0$3054$14726298@news.sunsite.dk
> Kall, Mogens wrote:
> >>... Praecis de samme fejl kan optraede i en
> >>hardwareimplementation.
> >
> >
> > Forklar dette nærmere ?
>
> Naar man skriver et program i software og udforer det paa en processer,
> henter processoren en instruktion. Den finder ud af, hvilken instruktion
> der er tale om, og derefter udfoeres den. Dette gentager sig, til
> programmet eventuelt er faerdigt.
>
> Naar dette foregaar ``i hardware'', sker praecis det samme, bortset fra
> at funktionaliteten er ``braendt ned i silicium''.
Okay - den er jeg med på (jeg kender blot ikke alle disse fagudtryk).
>
> Hvis man har lavet en programmeringsfejl, vil programmet udfoert ``i
> software'' ikke opfoere sig korrekt. Hvis man har lavet en fejl, da man
> har lavet hardwaren, vil hardwareprogrammet opfoere sig forkert.
>
> Software eller hardware, begge dele er et program, og det kan der vaere
> fejl i. Et andet sted naevner kasper F00F-fejlen i Pentium, og det er et
> glimrende eksempel paa, at der ogsaa kan vaere fejl i hardwarelogik.
Som forbruger vælger man jo så det firma-produkt, der funker
For mig at se er det ikke uoverkommelige ændringer vi taler om. Faktisk blot
HD'en.
Og da maskinkode-instruktionerne hertil kan lagres på elektrisk-sletbar-ROM,
er problemet mht. programmeringsfejl jo stort set løst ved en opgradering.
> >>Hvordan vil du sikre dig, at man ikke laver de samme programmeringsfejl
> >>i en givet hardwareimplementation? ...
> >
> >
> > (se ovenfor. Jeg må have forklaret noget desangående, inden jeg udtaler
mig)
> >
> > (dersom jeg har forstået dig korrekt:)
> > Nogle bundkort har en manuel jumper, dersom brugeren ønsker at opgradere
> > BIOS-maskinkoden. Ændringen kan kun således ske, dersom bruger *bevidst*
> > flytter denne jumper. Herved skulle det teknisk set være mulig at
korrigere
> > eventuelle programmeringsfejl.
>
> Hvordan sikrer du dig, at den softwareopdatering du henter er den
> korrekte? At den bliver skrevet korrekt i hardwaren?
Faktisk har nogle hjemmefuskere dette problem, når/dersom de laver en
opgradering på deres BIOS. Hvis der er sket en fejl undervejs; ja så virker
computeren ikke længere
En simpel løsning her kunne være, at have 2 BIOS'er. Originalen som ALDRIG
kan ændres samt en elektrisk-sletbar-ROM. Skulle der opstå et
hardware-problem, kobles originalen bare på vhj. jumpere på bundkortet. I
tilfælde af fjernstyring skal denne jumper selvfølgelig erstattes af en
elektrisk RESET tilkoblet modtager-modulet.
> > Nogle vil gerne betale lidt ekstra for denne forebyggelse
>
> Det er langt under flertallet, gaetter jeg paa. Hr. og Fr. Jensen vil
> have en billig computer, hvor de skal goere minimum indsats for at holde
> den opdateret. Banker, som du saa gladeligt bruger som eksempel, vil
> maaske gerne bruge flere penge, naar de indkoeber hardware, men de har
> ressourcer til at haandtere sikkerheden paa en anden maade.
Tænker du her på Sasser-ormen
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2185
| |
Michael Knudsen (20-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 20-05-04 01:37 |
|
| |
Kall, Mogens (20-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 20-05-04 12:55 |
|
"Michael Knudsen" skrev
news:Pine.GSO.4.50.0405200225520.9518-100000@fire2.cs.auc.dk
> On Wed, 19 May 2004, Kall, Mogens wrote:
> > Mange computere blev inficseret med sasser. Når et maskinkode-program
> > først
> > afvikles på en computer, er der INGEN begrænsninger for hvilke
> > operationer,
> > der kan foretages. Man kan ændre eller slette filer på Harddiskene,
> > inficere
> > MasterBootRecorden (ved mindre denne er skrivebeskyttet i
> > BIOS-opsætningen)
> > eller BootRecorden osv. - eller oprette en bagdør (hvorved man går
> > *udenom* firewall'en).
>
> Det lyder som om, du totalt har misforstaaet noget. Du snakker om et
> `maskinkodeprogram', hvad mener du med det? Maskinkode er typisk det,
> man oversaetter sit programkode (C, Pascal, assembler etc.) til. Det er
> altsaa ikke noget magisk kode med saerlige privilegier. Det er ganske
> almindelige instruktioner til processoren.
Korrekt. Alle programmer afvikles på computeren i maskincoder.
Højprogrammeringssprogene C og Pascal og ligeledes assembler er for så vidt
blot nødvendige hjælpe-værktøjer.
Men i det øjeblik en maskinkode afvikles på computeren, da er det faktisk
dette program, som har "magtbeføjelserne". OS-kontrolsystemet kan kun
overvåge programmet ved hjælp af Interrupt (program-afbrydelse). Disse
Interrupt adresse-jump kan ændres (i hvert tilfælde på de gamle OS'er).
Selv NMI-jumpet kan ændres !!!
> Derudover er der i oevrigt paa langt de fleste processorer
> begraensninger for, hvilke instruktioner der maa udfoeres, som blandt
> andet Kent ogsaa naevner. ...
Kunne du være så elskværdig at referere dine henvisninger (i dette tilfælde
Kent) konkret, så jeg (og andre fremover har lettere ved umiddelbart at
fatte, hvad du hentyder til.
Et eksempel:
Date: (angiv hvornår Kent bragte sit indlæg. Dette kan spores Off-line,
selvom hans indlæg ikke er downloaded)
Navn: (hvilket du allerede vist nok har gjort, ved mindre Kent officielt
identificerer sig under en anden betegnelse)
Subject: (angiv emne, dersom indlægget er bragt i en anden tråd)
Og meget gerne også indlæg-identifikation:
Fx. (dette dit indlæg, du bragte)
news:Pine.GSO.4.50.0405200225520.9518-100000@fire2.cs.auc.dk
Jeg arbejder Off-line
På forhånd tak
> ... Eksempelvis paa en almindelig PC opererer
> processoren med tre eller fire `ringe' eller niveauer af privilegier.
Korrekt.
> Operativsystemer saasom Linux, BSD og Windows NT-serien koerer i den
> inderste ring, almindelige programmer koerer i den yderste. Paa denne
> sikrer operativsystemet, at dét bestemmer hvem der faar adgang til hvad.
Korrekt (forudsat at Interrupt-tabellerne ikke er blevet infeceret).
> I oevrigt er der flere ting i dit design, der er temmeligt svaere at
> haandtere. ...
Det skal du ikke være ked af. Jeg er en håbløs amatør
> ... Du skriver noget med, at operativsystemet ``ALTID laeser
> disse filer'' -- ...
Du klippe for meget i min tekst, så sammenhængen smuttede.
Mener du ... Nåh ... nu fandt jeg den
=== citat start ===
Forebyggelse
--------------
For at *forebygge* dette, bør man have en Harddisk med skrivebeskyttede
zoner, således at Operativsystemet ALTID under opstart indlæser filerne fra
disse sikre zoner. Filer, som ændres undervejs af OS under programafvikling,
kan af gode grunde ikke ligge i denne sikre zone, men disses original-filer
kan godt. Dersom computeren ønskes *steriliseret* kan man under opstart
kopiere disse filer fra den sikrede zone til den læse- og skrivebare zone.
Nogle filer ændres ofte, mens andre ændres sjældent, hvorfor det er
relevant at have flere zoner, end blot de to nævnte.
=== citat slut ====
Dét, jeg mente, var/er, at computeren indlæser de såkaldte "døde" filer
(filer som forbliver uændret efter Operativ Systemet er installeret) fra
skrivebeskyttede zoner.
Herved er der 100% garanti for, at intet fremmed-program har pillet i
filerne. Det gælder fx. Kernel32.dll filen osv.
> det er ikke noedvendigvis trivielt eller opnaaeligt i
> praksis.
Det kræver en gennemgribende ændring i Harddiskens konstruktion, men i
praksis mulig
Idéen hermed offentliggjort, mere kan jeg ikke gøre i første omgang
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2172
| |
Michael Knudsen (20-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 20-05-04 14:36 |
|
Kall, Mogens wrote:
> Korrekt. Alle programmer afvikles på computeren i maskincoder.
> Højprogrammeringssprogene C og Pascal og ligeledes assembler er for så vidt
> blot nødvendige hjælpe-værktøjer.
Hoejniveausprogene goer i hvert fald mange ting meget lettere.
> Men i det øjeblik en maskinkode afvikles på computeren, da er det faktisk
> dette program, som har "magtbeføjelserne". OS-kontrolsystemet kan kun
> overvåge programmet ved hjælp af Interrupt (program-afbrydelse). Disse
> Interrupt adresse-jump kan ændres (i hvert tilfælde på de gamle OS'er).
> Selv NMI-jumpet kan ændres !!!
Noeglen til den sandhed er ``gamle OS'er'' -- eller rettere
operativsystemer uden en sikkerhedsmodel som eksempelvis DOS og familien
af Windows, der ikke baserer sig paa NT, dvs. 95, 98 etc.
I operativsystemer _med_ en sikkerhedsmodel har et program ikke fuld
kontrol over computeren -- det er udelukkende operativsystemet, der har
det. Hvis det eksempelvis forsoeger at tilgaa noget hukommelse, som det
ikke har adgang til, laver processoren en page fault (eller en anden
exception, jeg er ikke helt sikker), som resulterer i, at
programudfoerslen overtages af operativsystemet, som vil afslutte
programmet. Programmet bliver standset, inden det faar lavet ravage.
Det samme gaelder, hvis programmet forsoeger at udfoere instruktioner,
der kraever et hoejere niveau af privilegier eller lignende.
>>Derudover er der i oevrigt paa langt de fleste processorer
>>begraensninger for, hvilke instruktioner der maa udfoeres, som blandt
>>andet Kent ogsaa naevner. ...
>
>
> Kunne du være så elskværdig at referere dine henvisninger (i dette tilfælde
> Kent) konkret, så jeg (og andre fremover har lettere ved umiddelbart at
> fatte, hvad du hentyder til.
Nu regnede jeg med, at du godt kunne huske indlaegget, da du selv fulgte
op, men det var altsaa:
40ab748b$0$3048$14726298@news.sunsite.dk
>>... Eksempelvis paa en almindelig PC opererer
>>processoren med tre eller fire `ringe' eller niveauer af privilegier.
>
>
> Korrekt.
Kun operativsystemet kan aendre et programs privilegieniveau, da dette
skal goeres fra ring 0, saa et program kan ikke bryde ud og derved
eskalere sine privilegier.
>>Operativsystemer saasom Linux, BSD og Windows NT-serien koerer i den
>>inderste ring, almindelige programmer koerer i den yderste. Paa denne
>>sikrer operativsystemet, at dét bestemmer hvem der faar adgang til hvad.
>
>
> Korrekt (forudsat at Interrupt-tabellerne ikke er blevet infeceret).
Hvordan skulle dette kunne ske, naar kun operativsystemet selv har
adgang til hukommelsesomraadet, hvor interruptvektoren ligger?
> Herved er der 100% garanti for, at intet fremmed-program har pillet i
> filerne. Det gælder fx. Kernel32.dll filen osv.
>
>
>>det er ikke noedvendigvis trivielt eller opnaaeligt i
>>praksis.
>
>
> Det kræver en gennemgribende ændring i Harddiskens konstruktion, men i
> praksis mulig
Dermed er den ikke interessant, da det allerede er muligt at beskytte
operativsystemerne tilstraekkeligt med den af processoren givne
privilegieopdeling.
Mvh. Michael.
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)
| |
Kall, Mogens (21-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 21-05-04 01:18 |
|
"Michael Knudsen" skrev
news:40acb44c$0$3057$14726298@news.sunsite.dk
> Hoejniveausprogene goer i hvert fald mange ting meget lettere.
Dét tør man nok antyde
> > Men i det øjeblik en maskinkode afvikles på computeren, da er det
> > faktisk
> > dette program, som har "magtbeføjelserne". OS-kontrolsystemet kan kun
> > overvåge programmet ved hjælp af Interrupt (program-afbrydelse). Disse
> > Interrupt adresse-jump kan ændres (i hvert tilfælde på de gamle OS'er).
> > Selv NMI-jumpet kan ændres !!!
>
> Noeglen til den sandhed er ``gamle OS'er'' -- eller rettere
> operativsystemer uden en sikkerhedsmodel som eksempelvis DOS og familien
> af Windows, der ikke baserer sig paa NT, dvs. 95, 98 etc.
Korrekt - ved mindre du er blevet infekseret under boot.
(fx. BIOS-opgraderingen var falsk)
> I operativsystemer _med_ en sikkerhedsmodel har et program ikke fuld
> kontrol over computeren -- det er udelukkende operativsystemet, der har
> det. Hvis det eksempelvis forsoeger at tilgaa noget hukommelse, som det
> ikke har adgang til, laver processoren en page fault (eller en anden
> exception, jeg er ikke helt sikker), som resulterer i, at
> programudfoerslen overtages af operativsystemet, som vil afslutte
> programmet. Programmet bliver standset, inden det faar lavet ravage.
>
> Det samme gaelder, hvis programmet forsoeger at udfoere instruktioner,
> der kraever et hoejere niveau af privilegier eller lignende.
Fuldstændig korrekt, men al dette *forudsætter*, at system-filerne på HD'en
ikke er blevet infekseret
Jeg har ikke studeret Sasser-ormen, men jeg hørte på TV forleden dag, at
nogle - vist nok eksperter - sagde, at fremtidens Sasser sågar kunne
formatere HD'en.
Såfremt dette er korrekt (jeg kan jo have hørt galt, og jeg husker
dårligt), betyder det jo, at de sikkerhedsgarantier du opstiller, er
luftkasteller. Og det er jo ikke så godt
> >>Derudover er der i oevrigt paa langt de fleste processorer
> >>begraensninger for, hvilke instruktioner der maa udfoeres, som blandt
> >>andet Kent ogsaa naevner. ...
> >
> >
> > Kunne du være så elskværdig at referere dine henvisninger (i dette
> > tilfælde
> > Kent) konkret, så jeg (og andre fremover har lettere ved umiddelbart at
> > fatte, hvad du hentyder til.
>
> Nu regnede jeg med, at du godt kunne huske indlaegget, ...
Jeg har desværre en MEGET dårlig hukommelse
> ... da du selv fulgte
> op, men det var altsaa:
>
> 40ab748b$0$3048$14726298@news.sunsite.dk
Desværre kan denne oplysning ikke benyttes, når man (som jeg) læser
Off-line.
Men da jeg selv har kommenteret hans indlæg indgår tekststrengen
40ab748b$0$3048...osv. i min download. Kunne du næste gang gøre det således:
Name: Kent Friis
Date: 19. maj 2004 CET 16:51
40ab748b$0$3048$14726298@news.sunsite.dk
.... så er det hele meget lettere. Også når man om nogle måneder/år evt.
læser disse linier.
På forhånd tak
Kent Friss skrev...
=== citat start ===
Få fat i en manual til 80386 eller nyere, Motorola 68000 eller nyere,
eller tilsvarende processor fra efter Commodore 64 tiden.
=== citat slut ====
Disse CPU'er har *mulighed* for at begrænse, hvilke instruktioner der må
udføres; ja, men der afhænger af OS'en.
> >>... Eksempelvis paa en almindelig PC opererer
> >>processoren med tre eller fire `ringe' eller niveauer af privilegier.
> >
> >
> > Korrekt.
>
> Kun operativsystemet kan aendre et programs privilegieniveau, da dette
> skal goeres fra ring 0, saa et program kan ikke bryde ud og derved
> eskalere sine privilegier.
Dét kan muligvis godt gøres, dersom ... nej, det taler vi ikke om her
(folk kunne jo få gode idéer)
Jeg har dog ikke testet min ide (det er noget tid siden, jeg sidst har
programmeret), og det kræver temmelig meget arbejde at sætte sig ind i
dette. Og det er heller ej min primære opgave her i livet. Men muligvis kan
det lade sig gøre
> >>Operativsystemer saasom Linux, BSD og Windows NT-serien koerer i den
> >>inderste ring, almindelige programmer koerer i den yderste. Paa denne
> >>sikrer operativsystemet, at dét bestemmer hvem der faar adgang til hvad.
> >
> >
> > Korrekt (forudsat at Interrupt-tabellerne ikke er blevet infeceret).
>
> Hvordan skulle dette kunne ske, naar kun operativsystemet selv har
> adgang til hukommelsesomraadet, hvor interruptvektoren ligger?
Under boot (dette forudsætter dog at OS-filerne allerede ér blevet
infekseret).
> > Det kræver en gennemgribende ændring i Harddiskens konstruktion, men i
> > praksis mulig
>
> Dermed er den ikke interessant, da det allerede er muligt at beskytte
> operativsystemerne tilstraekkeligt med den af processoren givne
> privilegieopdeling.
Også når du får tilsendt en hidtil ukendt virus med E-mailen (og dit
Anti-virusprogram derfor ikke fanger den) fra en såkaldt "sikker" person ?
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2187
| |
Kasper Dupont (20-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 20-05-04 14:53 |
|
"Kall, Mogens" wrote:
>
> Men i det øjeblik en maskinkode afvikles på computeren, da er det faktisk
> dette program, som har "magtbeføjelserne". OS-kontrolsystemet kan kun
> overvåge programmet ved hjælp af Interrupt (program-afbrydelse). Disse
> Interrupt adresse-jump kan ændres (i hvert tilfælde på de gamle OS'er).
Du snakker om et OS fra før beskyttelsen blev indført.
Hvis man da overhovedet vil tillade sig at kalde DOS for
et OS. Jeg ved godt, at DOS står for Dirty Operating
System, så nogen syntedes åbenbart at det fortjente at
blive kaldt for et OS.
De ting du beskriver kan ikke lade sig gøre på et moderne
OS som BSD eller Linux.
>
> > Operativsystemer saasom Linux, BSD og Windows NT-serien koerer i den
> > inderste ring, almindelige programmer koerer i den yderste. Paa denne
> > sikrer operativsystemet, at dét bestemmer hvem der faar adgang til hvad.
>
> Korrekt (forudsat at Interrupt-tabellerne ikke er blevet infeceret).
Du mener modificeret. Men ellers har du ret, beskyttelsen
virker selvfølgelig kun så længe, der ikke er fejl i den.
Bliver der fundet fejl i beskyttelsen, så bliver de rettet.
Nogle gange ligger fejlen i OS, så er det nemt at rette.
Nogle gange ligger fejlen i hardware, så er det ikke nemt
at rette. Derfor skal der laves så lidt som muligt i
hardware, så man ikke har så mange fejl, der er svære at
rette.
Nogle af fejlene i hardwaren kan OS så undgå ved at sætte
hardwaren passende op. Fra start af er det jo kun den OS
kode, du stoler på, der kører. Den kan så sætte hardwaren
op så man fanger fejlene, hvis de skulle blive triggeret
af upriviligerede programmer. F.eks. kan man slippe omkring
F00F bugen i nogle pentium processorer ved at sætte nogle
pages og segmenter op på en speciel måde og checker for
nogle usædvanlige conditions i en exception handler. Andre
fejl kan være umulige at gøre noget ved.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Kall, Mogens (21-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 21-05-04 01:18 |
|
"Kasper Dupont" <kasperd@daimi.au.dk> skrev i en meddelelse
news:40ACB83E.26FF482E@daimi.au.dk...
> "Kall, Mogens" wrote:
> >
> > Men i det øjeblik en maskinkode afvikles på computeren, da er det
faktisk
> > dette program, som har "magtbeføjelserne". OS-kontrolsystemet kan kun
> > overvåge programmet ved hjælp af Interrupt (program-afbrydelse). Disse
> > Interrupt adresse-jump kan ændres (i hvert tilfælde på de gamle OS'er).
>
> Du snakker om et OS fra før beskyttelsen blev indført.
> Hvis man da overhovedet vil tillade sig at kalde DOS for
> et OS. Jeg ved godt, at DOS står for Dirty Operating
> System, så nogen syntedes åbenbart at det fortjente at
> blive kaldt for et OS.
>
> De ting du beskriver kan ikke lade sig gøre på et moderne
> OS som BSD eller Linux.
Jeg har aldrig studeret Linux, og jeg er desværre for dum til det. Men jeg
ville gerne, fordi netop Linux kan ændres
> > > Operativsystemer saasom Linux, BSD og Windows NT-serien koerer i den
> > > inderste ring, almindelige programmer koerer i den yderste. Paa denne
> > > sikrer operativsystemet, at dét bestemmer hvem der faar adgang til
hvad.
> >
> > Korrekt (forudsat at Interrupt-tabellerne ikke er blevet infeceret).
>
> Du mener modificeret. Men ellers har du ret, beskyttelsen
> virker selvfølgelig kun så længe, der ikke er fejl i den.
> Bliver der fundet fejl i beskyttelsen, så bliver de rettet.
>
> Nogle gange ligger fejlen i OS, så er det nemt at rette.
> Nogle gange ligger fejlen i hardware, så er det ikke nemt
> at rette. Derfor skal der laves så lidt som muligt i
> hardware, så man ikke har så mange fejl, der er svære at
> rette.
Fuldstændig korrekt!
Men, men ... det er jo så lille en ændring, jeg ønsker at foretage ... blot
gøre HD'en lidt mere skriveskyttet
> Nogle af fejlene i hardwaren kan OS så undgå ved at sætte
> hardwaren passende op. Fra start af er det jo kun den OS
> kode, du stoler på, der kører. ...
Jo, men den har én ALVORLIG sårbarhed. Den ligger úbeskyttet på HD'en! Havde
den nu fx. ligget på en CD-ROM, da ville du ikke kunne pille i filerne.
> ... Den kan så sætte hardwaren
> op så man fanger fejlene, ...
Ja!
> ... hvis de skulle blive triggeret
> af upriviligerede programmer.
(sætning ej forstået)
Tænker du her på BIOS-opkald ?
> ... F.eks. kan man slippe omkring
> F00F bugen i nogle pentium processorer ved at sætte nogle
> pages og segmenter op på en speciel måde og checker for
> nogle usædvanlige conditions i en exception handler. Andre
> fejl kan være umulige at gøre noget ved.
Det samme vil man også kunne gøre med "mit" system
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2188
| |
Kasper Dupont (21-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 21-05-04 07:28 |
|
"Kall, Mogens" wrote:
>
> Jeg har aldrig studeret Linux, og jeg er desværre for dum til det. Men jeg
> ville gerne, fordi netop Linux kan ændres
Jeg har hørt, at Mandrake skulle være nem at komme
i gang med. (Jeg har ikke selv prøvet den).
>
> Jo, men den har én ALVORLIG sårbarhed. Den ligger úbeskyttet på HD'en!
Nej. OS er ikke ubeskyttet. Det er lavet til at
beskytte sig selv.
> Havde
> den nu fx. ligget på en CD-ROM, da ville du ikke kunne pille i filerne.
Det har sine fordele. Og den er stadig til at
udskifte hvis der bliver fundet fejl.
>
> > ... hvis de skulle blive triggeret
> > af upriviligerede programmer.
>
> (sætning ej forstået)
Jeg siger bare, at selvom der er en fejl i hardwaren
kan man nogen gange lave softwaren, så det ikke gør
noget. F00F fejlen ville umiddelbart betyde, at et
program med en enkelt instruktion kunne crashe
maskinen. Men da fejlen blev opdaget fandt nogle
personer en snedig måde at opnå en exception i stedet
for et crash, og inde fra denne exception kunne man
så bare stoppe programmet og OS kørte upåvirket
videre.
>
> Tænker du her på BIOS-opkald ?
Nej. BIOS er overvurderet. Et moderne OS behøver
ikke bruge BIOS. Alt hvad der kan gøres fra BIOS kan
lige så vel gøres af OS kernen. BIOS er bare noget
kode, der er intet magisk ved den.
Og som der står i kommentarerne til Linux opstarts
kode: "we don't need no steenking BIOS anyway (except
for the initial loading ."
>
> Det samme vil man også kunne gøre med "mit" system
Jo mere kompliceret du gør det, des flere fejl vil
der være. Og des større er risikoen for en fejl, som
softwaren ikke kan gøre noget ved.
Og dit system lider af den alvorlige designfejl, at
du forudsætter, at hardwaren er fejlfri. En enkelt
fejl i hardwaren, som OS er nødt til at forhindre
misbrug af, betyder, at din beskyttelse overhovedet
ikke virker. Tilbage er kun den beskyttelse, som OS
implementerer. Og den har vi allerede i dag.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Michael Knudsen (20-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 20-05-04 01:45 |
|
| |
Michael Knudsen (20-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 20-05-04 01:58 |
|
| |
Kall, Mogens (20-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 20-05-04 12:54 |
|
"Michael Knudsen" skrev
news:Pine.GSO.4.50.0405200245170.9518-100000@fire2.cs.auc.dk
> On Thu, 20 May 2004, Kall, Mogens wrote:
> > 1.
> > Angriberen angriber først et forsvarsløst mellemled (Zombie).
>
> Nej.
Tak for dit svar, Michael.
Du må bære over med mig (for en tid). Jeg er desværre ret tungnem
Dette forstod jeg ikke helt.
Angriberen kontakter mellemleddet (for mig at se ér dette et angreb).
Den eneste måde angriberen kan feedback på sin henvendelse, er vel at
Zombie'n sender besked tilbage til angriberens IP-adresse, eller hva' ?
Kan alle computere bruges af angriberen som mellemled (Zombie), dersom
angriberen besidder denns IP-adresse ?
Vil min computer også kunne benyttes hertil, selvom jeg har firewall ?
Hvilke begrænsninger er der mht. disse computere ?
> > 2.
> > Zombie'ns IP-adresse benyttes herefter i angrebet.
> > (og det er denne IP-adresse, jeg registrerer)
>
> Ja.
Og dette sker mens Zombie'n er on-line, således at angriberen kan få
feedback under punkt 3, eller hva' ?
Sender min computer besked til Zombie'n (hvilket afslører mig), når min
computer har firewall ?
Såfremt svaret er *JA*; vil man kunne omprogrammere min computer til IKKE at
sende disse beskeder ?
Og i så fald - hvilke konsekvenser kan det få for andre programmer og
Internet-kommunikation ?
> > 3.
> > Angriberen indhenter oplysningerne herefter fra Zombie'n
>
> Delvist.
>
> > Korrekt forstået ?
>
> Delvist. Lidt forenklet sagt saa skyder du som angriber skylden paa
> en anden, som vil se ud som den egentlige angriber. ...
Den har jeg fattet (angriberens den falske IP-adresse)
> ... Derefter kan du
> spoerge din syndebuk paa den korrekte maade og udlede den oenskede
> information af svaret fra din syndebuk.
Men syndebukken (Zombie'n) bliver jo igen kontaktet af angriberen (her under
punkt 3) og sender oplysningerne (vedrørende mine portes status) fra punkt 2
til angriberen. Korrekt forstået ?
Og disse oplysninger sendes vel til angriberens IP-adressen (hvordan skulle
vedkommende ellers modtage dem). Korrekt forstået ?
Såfremt dit svar herpå er *JA*, da må det da være muligt at opsnappe
angriberens IP-adresse ved at overvåge mellemleddet's kommunikation, eller
hva' ?
> > Hvis svaret herpå er *JA*, da kan man roligt klage over denne IP-adresse
> > til
> > dets Internet-udbyder; idet computeren jo benyttes af angriberen.
>
> Nej, du kan ej! Det er jo netop ikke den, der har angrebet dig. Du har
> ikke set _een eneste_ pakke med den reelle angribers IP-adresse. Det er
> _det_, der er det smarte ved denne metode.
Du misforstår mig (mit ordvalg var dumt). Klagen er IKKE over syndebukken,
men at angriberen benytter syndebukkens IP-adresse. Henvendelsen til
syndebukken (Zombie'n) er således blot et opsporingsforsøg.
> > Internet-udbyderen til Zombie'n kan muligvis *spore* angriberens
> > IP-adresse
> > via "korrespondancen" mellem angriberen og Zombie'n med henblik på
> > erstatningskrav!
>
> Hvis du paa nogen maade kan komme med en god, effektiv og, foerst og
> fremmest, korrekt metode til at afgoere denne korrespondence paa, saa
> kan du sandsynligvis blive baade rig og beroemt.
>
> Taenk lidt over det, bare med _to_ pakker. En til den angrebne og en til
> syndebukken. Disse _to_ pakker i en potentiel stroem af _millioner_ af
> andre pakker. Disse to pakker har forskellige modtagere og afsendere.
> Hvordan vil du paa nogen maade kunne afgoere en sammenhaeng mellem disse
> to pakker? For _resten_ af alle pakkerne?
Såfremt jeg har forstået al dette korrekt:
Brug tiden som et våben.
Angriberen registreres af mit computer-ur (dette kan dog gå forkert). Men
hvis min firewall AUTOMATISK (og ØJEBLIKKELIG) sender en besked til min
Internet-udbyder samt et centralt globalt register, se ...
Date: 20. maj 2004 CET 11:09
2169 news:2B_qc.208$Vf.12228@news000.worldonline.dk
.... da vil deres ur angive den korrekte tid.
Dersom mellemleddets (Zombie'ns) Internet-udbyderen har nogle minutters
DATA-memory på sine kunders Internet-kommunikation, da vil man herfra kunne
indkredse angriberens IP-adresse til blot nogle få ud af mange millioner
(gruppe A).
Dersom dette DATA-memory IKKE haves på alle kunder, bør der i hvert fald
oprettes et for "udvalgte" kunder (dem, angriberne allerede tidligere har
benyttet).
Dersom angriberen fortsætter sit angreb, men nu blot fra et nyt mellemled
(Zombie), vil man igen kunne indkredse angriberens IP-adresse til blot nogle
få ud af mange millioner (gruppe B).
Sammenlignes nu de to grupper A og B med hinanden; da vil man yderligere
kunne indkredse angriberens IP-adresse. Muligvis er der kun én IP-adresse i
fællesmængden !!!
Denne IP-adresse behøver ikke at være selve angriberens. Det kan godt
være blot endnu et mellemled (Zombie no 2), men på et tidspunkt er der en
ende i denne kæde, og her sidder angriberen. Desto længere kæder er, desto
længere tid tager det for angriberen at få et svar, og derfor er vedkommende
lettere at spore
Men systemet vil kun virke, dersom rapporteringen sker ØJEBLIKKELIG (ellers
bliver DATA-memory-mængderne for store og úoverskuelige).
Lad os prøve at konkretisere dette med et eksempel:
(jeg benytter her mine egne DATA-kilder)
Date: 17. maj 2004 CET 23:49
Subject: Hacher-angreb
2148 news:6saqc.164635$jf4.8542374@news000.worldonline.dk
=== citat start (relevante oplysninger medtaget ) ===
Dato: 16-05-2004 Klokkeslæt: 20:13:50 - 62.79.39.235
Dato: 16-05-2004 Klokkeslæt: 20:21:09 - 62.79.85.4
Dato: 16-05-2004 Klokkeslæt: 20:21:39 - 62.79.74.237
Dato: 16-05-2004 Klokkeslæt: 20:24:15 - 62.79.86.5
=== citat slut ====
Samtlige 4 IP-adresser tilhører Internet-udbyderen Tiscali.dk
Klokken 20:13:50 sender min firewall besked til min Internet-udbyder. Denne
blokerer al trafik fra tiscali.dk, dersom afsenderens IP-adresse er
62.79.39.235.
Samtidig kontakter min Internet-udbyder Tiscali.dk indenfor 30 sekunder
(søgning i DATA-registeret for IP-adressens Internetudbyder må selvfølgelig
ske automatisk)
Tiscali overvåger herefter eventuelt kommunikation til og fra dets kunde med
IP-adressen 62.79.39.235, og opsnapper IP-adresser. Det kunne jo være, at
*din* firewall, Michael 3 minutter senere ligeledes slår alarm, og Tiscali
STRAKS får meddelelse herom.
Da vil man være i stand til at udpege angriberens IP-adresse
Klokken 20:21:09 gentages proceduren.
Klokken 20:21:39 gentages proceduren.
Her afsløres det, at angriberen ikke har mange mellemled, dersom det blot er
en enkelt computer, der benyttes under angrebet ( max. 30 sekunder)
Klokken 20:24:15 gentages proceduren.
> > Hvis jeg var Internet-udbyder ville jeg registrere "korrespondancerne",
> > således at jeg altid sidenhen kan efterspore *uønskede* elementer!!!
>
> Er du klar over, hvor store maengder traffik, der skal logges og
> analyseres?
Ikke hvis min firewall (automatisk og øjeblikkelig) sender alarmer om
mistænkelige IP-adresser til min Internet-udbyder. Så er DATA-mængden
faktisk ret overskuelig
> > (man kan muligvis tjene MANGE penge på dette)
>
> Du kan ikke tjene penge paa erstatningskrav. Erstatningskrav skal daekke
> tabt indtaegt og lignende, og ikke en krone mere.
Pengeinstitutter bryder sig ikke om hackere, og betaler gerne en lille
dusør, dersom røveri forhindres. Og røverne kommer i *fængsel*
Tak for din hjælp, Michael.
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2170
| |
Kasper Dupont (20-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 20-05-04 14:26 |
|
"Kall, Mogens" wrote:
>
> Angriberen kontakter mellemleddet (for mig at se ér dette et angreb).
Vi andre kalder ikke enhver kontakt for et angreb.
>
> Den eneste måde angriberen kan feedback på sin henvendelse, er vel at
> Zombie'n sender besked tilbage til angriberens IP-adresse, eller hva' ?
Ja.
>
> Kan alle computere bruges af angriberen som mellemled (Zombie), dersom
> angriberen besidder denns IP-adresse ?
Det forudsætter, at Zombien bruger forudsigelige IPID
numre, og ikke bruger sin netforbindelse ret meget.
>
> Vil min computer også kunne benyttes hertil, selvom jeg har firewall ?
Det afhænger af mange faktorer. Men et forsøg på at
løse problemet med en firewall, vil typisk medføre en
række større problemer.
>
> Hvilke begrænsninger er der mht. disse computere ?
Det kræver maskinen bruger nogle forudsigelige IPID
værdier, som faktisk fortæller noget om, hvor mange
pakker maskinen har sendt.
Der er mange måder en IP implementation kan beskytte
sig selv imod at blive misbrugt som mellemled.
F.eks. kan man bruge forskellige strategier for IPID
tildeling på pakker, hvor der er brug for IPID og
hvor der ikke er brug for IPID.
Hvis DF flaget er sat (hvilket ofte vil være tilfældet
på TCP pakker), så kan IPID lige så godt være nul
eller noget fuldstændigt tilfældigt. (Ja, nul ville
være forudsigeligt, men det kan alligevel ikke bruges
til noget, da det intet fortæller om, hvor mange
pakker maskinen har sendt).
På pakker hvor der er brug for IPID kan det genereres
så det er svære at forudsige. Det eneste krav er, at
man ikke bruger den samme værdi for tit. Så da der er
65536 forskellige muligheder, kunne man have en liste
hvoraf de seneste brugte fremgik, og så vælge et
tilfældigt blandt de 32768 det var længst siden man
sidst havde brugt. Det ville kræver 128KB RAM og kunne
gøres meget effektivt.
Alternativt kunne man bruge forskellige sekvenser af
IPID afhængigt af destinations IP. Hvordan man lige
undgår, at det fører til stort hukommelsesforbrug har
jeg ikke noget forslag til.
>
> > > 2.
> > > Zombie'ns IP-adresse benyttes herefter i angrebet.
> > > (og det er denne IP-adresse, jeg registrerer)
> >
> > Ja.
>
> Og dette sker mens Zombie'n er on-line, således at angriberen kan få
> feedback under punkt 3, eller hva' ?
Ja.
>
> Sender min computer besked til Zombie'n
Ja, det skal den ifølge TCP standarden.
> (hvilket afslører mig),
Hvad mener du med at afsløre dig? Det eneste svaret
fortæller er, om du har en server kørende. Og hvis du
har en server kørende er du jo nødt til at svare, for
at den kan bruges.
> når min computer har firewall ?
Der findes firewalls, der overtræder TCP standarden.
>
> Såfremt svaret er *JA*; vil man kunne omprogrammere min computer til IKKE at
> sende disse beskeder ?
Det kunne man godt, men den ville ikke længere overholde
standarden. Jeg kan heller ikke lige se, hvad formål,
det skulle tjene.
>
> Og i så fald - hvilke konsekvenser kan det få for andre programmer og
> Internet-kommunikation ?
Nogle ting vil blive sløvet ned, fordi de bliver ved med
at sende pakker til dig, som de forventer at få et svar
på. Det ville også gøre det nemmere at spoofe din IP
adresse i andre angreb, f.eks. mod maskiner med forudsigelige
TCP sekvens numre.
>
> > > 3.
> > > Angriberen indhenter oplysningerne herefter fra Zombie'n
> >
> > Delvist.
> >
> > > Korrekt forstået ?
> >
> > Delvist. Lidt forenklet sagt saa skyder du som angriber skylden paa
> > en anden, som vil se ud som den egentlige angriber. ...
>
> Den har jeg fattet (angriberens den falske IP-adresse)
>
> > ... Derefter kan du
> > spoerge din syndebuk paa den korrekte maade og udlede den oenskede
> > information af svaret fra din syndebuk.
>
> Men syndebukken (Zombie'n) bliver jo igen kontaktet af angriberen
Ja.
> og sender oplysningerne (vedrørende mine portes status)
Nej. Men de kan indirekte udledes fra svarene, og viden
om de spoofede pakker man har sendt. Alt sammen under
antagelse af, at der ikke er anden trafik på zombien.
>
> Såfremt dit svar herpå er *JA*, da må det da være muligt at opsnappe
> angriberens IP-adresse ved at overvåge mellemleddet's kommunikation, eller
> hva' ?
Ja i teorien. Men det er mange personer, der skal
overbevises om at overvåge uskyldige menneskers
ligegyldige kommunikation. Og at overhovedet få sat den
overvågning i gang med så kort varsel er urealistisk.
Du skal være opmærksom på, at mellemledet strengt taget
ikke er blevet misbrugt. Den har heller ikke været
involveret i misbruget. Den har udelukkende overholdt
standarden og sendt svar på de pakker, den nu engang
modtog. I tilfælde at alle porte har været lukket, har
zombien faktisk slet ikke sendt en eneste pakke til den
scannede maskine.
Og trafik mellem scanneren og zombien kan være hvad som
helst. Det kan være ganske legitim trafik. Det behøver
ikke engang være initieret af scanneren. Jeg kunne sætte
en server op, og når så min maskine bliver kontaktet, så
spoofer jeg klientens IP i en idle-scan.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Kall, Mogens (21-05-2004)
| Kommentar Fra : Kall, Mogens |
Dato : 21-05-04 01:18 |
|
"Kasper Dupont" skrev
news:40ACB1F6.601352D3@daimi.au.dk
> "Kall, Mogens" wrote:
> >
> > Angriberen kontakter mellemleddet (for mig at se ér dette et angreb).
>
> Vi andre kalder ikke enhver kontakt for et angreb.
Selvfølgelig ikke, men når vi konstaterer under punkt 2, at dennes
IP-adresse bliver misbrugt, da kan vi roligt sige ... muligvis også juridisk
set ... at der er tale om et bevidst angreb, og som man kan blive
straffet for. Findes der smuthuller i den nuværende danske lovgivning; ja,
så ændrer vi den bare (her og nu), så man i fremtiden kan blive draget til
ansvar for denne sin forbrydelse!
Punkt 1:
> > Den eneste måde angriberen kan feedback på sin henvendelse, er vel at
> > Zombie'n sender besked tilbage til angriberens IP-adresse, eller hva' ?
>
> Ja.
Fedt nok !!!
"Arkiveres" angriberens IP-adresse på Zombiens computer, således at man
senere kan efterspore denne ?
(Såfremt svaret er *nej*:)
Kan man muliggøre dette med et program ?
Kan man få et program (Pg-1.2), der forhindrer, at min computer svarer
tilbage til angriberen, således at man derved undgår at blive en Zambie ?
> > Kan alle computere bruges af angriberen som mellemled (Zombie), dersom
> > angriberen besidder denns IP-adresse ?
>
> Det forudsætter, at Zombien bruger forudsigelige IPID
> numre, og ikke bruger sin netforbindelse ret meget.
Okay.
> > Vil min computer også kunne benyttes hertil, selvom jeg har firewall ?
>
> Det afhænger af mange faktorer. ...
Hvilke ?
> ... Men et forsøg på at
> løse problemet med en firewall, vil typisk medføre en
> række større problemer.
Og disse er ?
> > Hvilke begrænsninger er der mht. disse computere ?
>
> Det kræver maskinen bruger nogle forudsigelige IPID
> værdier, som faktisk fortæller noget om, hvor mange
> pakker maskinen har sendt.
>
> Der er mange måder en IP implementation kan beskytte
> sig selv imod at blive misbrugt som mellemled.
>
> F.eks. kan man bruge forskellige strategier for IPID
> tildeling på pakker, hvor der er brug for IPID og
> hvor der ikke er brug for IPID.
>
> Hvis DF flaget er sat (hvilket ofte vil være tilfældet
> på TCP pakker), så kan IPID lige så godt være nul
> eller noget fuldstændigt tilfældigt. (Ja, nul ville
> være forudsigeligt, men det kan alligevel ikke bruges
> til noget, da det intet fortæller om, hvor mange
> pakker maskinen har sendt).
>
> På pakker hvor der er brug for IPID kan det genereres
> så det er svære at forudsige. Det eneste krav er, at
> man ikke bruger den samme værdi for tit. Så da der er
> 65536 forskellige muligheder, kunne man have en liste
> hvoraf de seneste brugte fremgik, og så vælge et
> tilfældigt blandt de 32768 det var længst siden man
> sidst havde brugt. Det ville kræver 128KB RAM og kunne
> gøres meget effektivt.
>
> Alternativt kunne man bruge forskellige sekvenser af
> IPID afhængigt af destinations IP. Hvordan man lige
> undgår, at det fører til stort hukommelsesforbrug har
> jeg ikke noget forslag til.
Kan man ligeledes her få et program som *automatisk* vanskeliggør
forudsigeligheden af IPID numrene (således at brugeren ikke skal tænke
nærmere over dette) ?
Punkt 2:
> > Og dette sker mens Zombie'n er on-line, således at angriberen kan få
> > feedback under punkt 3, eller hva' ?
>
> Ja.
Fedt nok !!!
Hvis vi opretter dette offensive forsvarssystem, da vil vi kunne kontakte
Zombien og vente på at angriberen kommer og *afslører* sin IP-adresse.
> > Sender min computer besked til Zombie'n
>
> Ja, det skal den ifølge TCP standarden.
>
> > (hvilket afslører mig),
>
> Hvad mener du med at afsløre dig? Det eneste svaret
> fortæller er, om du har en server kørende. Og hvis du
> har en server kørende er du jo nødt til at svare, for
> at den kan bruges.
>
> > når min computer har firewall ?
>
> Der findes firewalls, der overtræder TCP standarden.
Og disse er ?
> > Såfremt svaret er *JA*; vil man kunne omprogrammere min computer til
> > IKKE at sende disse beskeder ?
>
> Det kunne man godt, men den ville ikke længere overholde
> standarden. ...
Hvorledes foregår denne omprogrammering ?
> ... Jeg kan heller ikke lige se, hvad formål,
> det skulle tjene.
Der er et ordsprog, som lyder:
Tale er sølv, tavshed er guld
> > Og i så fald - hvilke konsekvenser kan det få for andre programmer og
> > Internet-kommunikation ?
>
> Nogle ting vil blive sløvet ned, fordi de bliver ved med
> at sende pakker til dig, som de forventer at få et svar
> på. ...
Også selvom jeg *aldrig* har bedt om disse pakker ?
(hvordan skulle afsenderen i så fald kunne have kendskab til min computers
eksistens)
> ... Det ville også gøre det nemmere at spoofe din IP
> adresse i andre angreb, f.eks. mod maskiner med forudsigelige
> TCP sekvens numre.
.... forudsat at min maskine sender svar, Pg-1.2
Punkt 3.
> > Men syndebukken (Zombie'n) bliver jo igen kontaktet af angriberen
>
> Ja.
Og angriberen kan ikke få et svar uden at opgive sin IP-adresse.
(svaret fået nedenfor, search *001*)
> > og sender oplysningerne (vedrørende mine portes status)
>
> Nej. Men de kan indirekte udledes fra svarene, ...
Henholdsvis aktuel port åben eller lukket ...
(fx. web servers on port 80 and mail servers on port 25)
.... og viden
> om de spoofede pakker man har sendt. Alt sammen under
> antagelse af, at der ikke er anden trafik på zombien.
Hvor mange sekunder taler vi her om ?
> > Såfremt dit svar herpå er *JA*, da må det da være muligt at opsnappe
> > angriberens IP-adresse ved at overvåge mellemleddet's kommunikation,
> > eller hva' ?
>
> Ja i teorien. ...
Fedt nok!
Markør *001*.
> ... Men det er mange personer, der skal
> overbevises om at overvåge uskyldige menneskers
> ligegyldige kommunikation. Og at overhovedet få sat den
> overvågning i gang med så kort varsel er urealistisk.
Ikke for mig at se, dersom vi kan minimere overvågningen til blot et enkelt
objekt
>
> Du skal være opmærksom på, at mellemledet strengt taget
> ikke er blevet misbrugt. ...
Det har vi så delte meninger om (IP-adresse misbrug)!
> ... Den har heller ikke været
> involveret i misbruget. ...
Nej på ingen måde!
> ... Den har udelukkende overholdt
> standarden og sendt svar på de pakker, den nu engang
> modtog. I tilfælde at alle porte har været lukket, har
> zombien faktisk slet ikke sendt en eneste pakke til den
> scannede maskine.
Korrekt.
> Og trafik mellem scanneren og zombien kan være hvad som
> helst. Det kan være ganske legitim trafik. Det behøver
> ikke engang være initieret af scanneren. Jeg kunne sætte
> en server op, og når så min maskine bliver kontaktet, så
> spoofer jeg klientens IP i en idle-scan.
Hackere foretager YDERST sjældent kun disse angreb én gang. Gentagelserne
vil afsløre hackeren!
(det er *derfor*, at der skal indsamles DATA)
Et spørgsmål melder sig:
Forestiller vi os ("hypotetisk" set), at min IP-adresse benyttes af
angriberen. Vil min firewall registrere, når angriberen kontakter Zombien
(mig) ?
.... og give alarm-meddelse ?
Tak for dit svar, Kasper.
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2183
| |
Kasper Dupont (21-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 21-05-04 06:44 |
|
"Kall, Mogens" wrote:
>
> "Kasper Dupont" skrev
> news:40ACB1F6.601352D3@daimi.au.dk
>
> > "Kall, Mogens" wrote:
> > >
> > > Angriberen kontakter mellemleddet (for mig at se ér dette et angreb).
> >
> > Vi andre kalder ikke enhver kontakt for et angreb.
>
> Selvfølgelig ikke, men når vi konstaterer under punkt 2, at dennes
> IP-adresse bliver misbrugt, da kan vi roligt sige
IP-adressen bliver misbrugt, men det betyder ikke, at maskinen
med den pågældende IP-adresse er blevet udsat for noget angreb.
Er IP spoofing i sig selv ulovligt? Jeg ved det ikke, men du
får en ret tung bevisbyrde at løfte.
>
> "Arkiveres" angriberens IP-adresse på Zombiens computer, således at man
> senere kan efterspore denne ?
Nej.
>
> (Såfremt svaret er *nej*:)
> Kan man muliggøre dette med et program ?
ethereal
>
> Kan man få et program (Pg-1.2), der forhindrer, at min computer svarer
> tilbage til angriberen, således at man derved undgår at blive en Zambie ?
Din computer skal svare, at unlade at svare ville være en
overtrædelse af TCP standarden. Men med en god IP implementation
ville svarene ikke kunne bruges til noget.
>
> > > Vil min computer også kunne benyttes hertil, selvom jeg har firewall ?
> >
> > Det afhænger af mange faktorer. ...
>
> Hvilke ?
Hvilken firewall du bruger. Hvordan den er opsat. Hvor mange
maskiner, der sidder bagved firewallen, og hvor meget de
bruger netforbindelsen. NAT slået til eller fra i firewallen.
Sendes svaret af firewallen selv eller maskinen bagved.
Ændres IPID i firewallen. Hvordan genererer firewallen IPID.
Under nogen omstændigheder kunne firewallen faktisk gøre det
nemmere at udføre angrebet. Hvis f.eks. firewallen selv
sender svarene, men bruger sekventielle IPID. Så ville din
firewall kunne bruges som zombie, uanset om maskinen bagved
ville kunne være brugt eller ej.
>
> > ... Men et forsøg på at
> > løse problemet med en firewall, vil typisk medføre en
> > række større problemer.
>
> Og disse er ?
Hvis du bruger en firewall med en NAT funktion vil det være
svært at garantere at der ikke sendes samme IPID to gange
med for kort mellemrum. Det samme gælder, hvis nogen pakker
genereres af firewallen, og andre genereres af maskiner
bagved.
En god firewall kunne selv generere IPID til alle udgående
pakker, inklusiv dem, der kom fra maskiner bagved. Men så
skal den også holde øje med IPID på de pakker den modtager
fra maskinerne. Hvis en maskine sender to pakker med samme
destination og IPID med kort mellemrum, så skal firewallen
også bruge samme IPID til de to pakker.
>
> Kan man ligeledes her få et program som *automatisk* vanskeliggør
> forudsigeligheden af IPID numrene (således at brugeren ikke skal tænke
> nærmere over dette) ?
Det skal ligge i IP implementationen i dit OS. For det
første kan du undersøge, om dit OS allerede har en god
algoritme til generering af IPID. Det kan man vist teste
med nmap. Hvis det ikke er tilfældet kan du undersøge, om
IP implementationen kan udskiftes med en anden mere
sikker version, eller om den har nogle hooks, som gør det
muligt at ændre på IPID.
>
> Punkt 2:
>
> > > Og dette sker mens Zombie'n er on-line, således at angriberen kan få
> > > feedback under punkt 3, eller hva' ?
> >
> > Ja.
>
> Fedt nok !!!
>
> Hvis vi opretter dette offensive forsvarssystem, da vil vi kunne kontakte
> Zombien og vente på at angriberen kommer og *afslører* sin IP-adresse.
Det kan du ikke. Zombien kan på ingen måde vide, hvilke
pakker der bliver brugt til at probe dens IPID numre.
Enhver pakke Zombien sender indeholder oplysninger om
dens IPID numre. Desuden ville dit system være alt for
usikkert, da det ville tillade at trække alt for mange
data ud af vilkårlige maskiner.
> >
> > Nogle ting vil blive sløvet ned, fordi de bliver ved med
> > at sende pakker til dig, som de forventer at få et svar
> > på. ...
>
> Også selvom jeg *aldrig* har bedt om disse pakker ?
Hvis du opretter en udgående forbindelse vil nogen
maskiner kontakte din maskine på andre porte. F.eks.
for at logge hvilken bruger på din maskine, der har
åbnet forbindelsen. Du kan selv vælge, om den oplysning
skal logges. Hvis du kører IDENT bliver brugernavnet
logget, ellers gør det ikke. Men hvis din maskine ikke
svarer, vil modparten være nødt til at sende sin pakke
igen og igen indtil du svarer, eller der forekommer et
timeout.
En anden grund til at oprette forbindelser tilbage til
din maskine kunne være, at man kiggede efter åbne
proxies på din maskine. Hvis din maskine havde en åben
proxy, og dermed kunne misbruges, vil nogen ikke tage
imod forbindelser fra dig. Igen vil det gå hurtigt,
hvis din maskine blot sender en besked om, at porten
er lukket. Hvis din maskine ikke svarer bliver du nødt
til at vente på et timeout.
> (hvordan skulle afsenderen i så fald kunne have kendskab til min computers
> eksistens)
>
> > ... Det ville også gøre det nemmere at spoofe din IP
> > adresse i andre angreb, f.eks. mod maskiner med forudsigelige
> > TCP sekvens numre.
>
> ... forudsat at min maskine sender svar,
Nej, forudsat at din maskine ikke sender svar.
>
> ... og viden
> > om de spoofede pakker man har sendt. Alt sammen under
> > antagelse af, at der ikke er anden trafik på zombien.
>
> Hvor mange sekunder taler vi her om ?
Det kommer an på, hvor mange porte, der scannes ad
gangen. Man kan f.eks. sende 100 pakker til den maskine,
man vil scanne, mellem hver pakke sendt til zombien.
Hvis man går ud fra, at der er minimum 32kb/s til
rådighed kan de 100 pakker sendes på et sekund. Så skal
man efterfølgende vente længe nok, til man er sikker på,
at der er gået en roundtrip tid. Man kunne f.eks. vente
et sekund. Så der skal nok ca. 3 sekunder uden trafik
til, for at udføre dette scan.
Hvis alle porte var lukket og zombien var idle, så ville
IPID vokse med en i mellem de to probes. Hvis IPID var
vokset mere end det, så måtte man prøve igen og kun tage
halvdelen af portene hver gang.
>
> > ... Men det er mange personer, der skal
> > overbevises om at overvåge uskyldige menneskers
> > ligegyldige kommunikation. Og at overhovedet få sat den
> > overvågning i gang med så kort varsel er urealistisk.
>
> Ikke for mig at se, dersom vi kan minimere overvågningen til blot et enkelt
> objekt
Det kan du ikke. Der er ingen måde at bevise, om en
maskine bliver brugt som zombie. En nemmere og bedre
løsning ville være, at afskaffe usiker IPID generering.
>
> >
> > Du skal være opmærksom på, at mellemledet strengt taget
> > ikke er blevet misbrugt. ...
>
> Det har vi så delte meninger om (IP-adresse misbrug)!
Du kan sagtens misbruge en maskines IP adresse uden at
misbruge maskinen.
>
> > Og trafik mellem scanneren og zombien kan være hvad som
> > helst. Det kan være ganske legitim trafik. Det behøver
> > ikke engang være initieret af scanneren. Jeg kunne sætte
> > en server op, og når så min maskine bliver kontaktet, så
> > spoofer jeg klientens IP i en idle-scan.
>
> Hackere foretager YDERST sjældent kun disse angreb én gang. Gentagelserne
> vil afsløre hackeren!
IPID probes kan foretages ved legitim trafik. Desuden
kan de maskeres ved samtidig at spoofe SYN pakker til
lukkede porte på zombien.
Forestil dig følgende scenarie:
A er en legitim bruger af serveren B
A vil scanne maskinen C
A opretter en forbindelse til B for at probe for dennes
IPID. Samtidig sendes en spoofet pakke fra A til B, som
angiver D som afsender. B sender et svar til D. A kan
forudsige, hvad IPID denne pakke måtte være.
Når jeg siger samtidig kunne det f.eks. gøres ved, at
pakkerne sendes i en tilfældig rækkefølge, for at det
bliver lidt sværere at gennemskue, hvad A har gang i.
Herefter sender A en række pakker til C og spoofer
afsender adressen B.
Dernæst prober A igen for Bs IPID. Dette gøres som før
ved at maskere det med en pakke fra D.
A kan nu udfra svarene udregne hvor mange åbne porte
der var på C i det scannede interval. Og regne ud,
hvad D ville være kommet frem til, hvis D havde lavet
et konventionelt idlescan af C vha. zombien B.
Det vil se ud som om, D er ved at lave et idlescan af
C. Men pga. trafikken fra A bliver D nødt til at prøve
igen og igen.
Der er ingen måde B kan vide, om det var A eller D,
der udførte et idlescan af C. Faktisk ville B nok
komme frem til den konklusion, at B var blevet udsat
for et portscan af D.
>
> (det er *derfor*, at der skal indsamles DATA)
>
> Et spørgsmål melder sig:
>
> Forestiller vi os ("hypotetisk" set), at min IP-adresse benyttes af
> angriberen. Vil min firewall registrere, når angriberen kontakter Zombien
> (mig) ?
Måske.
>
> ... og give alarm-meddelse ?
Forhåbentlig ikke. Den slags er bare til gene for
brugeren. Det skal logges, så man kan kigge på det
efterfølgende.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Kasper Dupont (21-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 21-05-04 07:08 |
|
Kasper Dupont wrote:
>
> Der er ingen måde B kan vide, om det var A eller D,
> der udførte et idlescan af C. Faktisk ville B nok
> komme frem til den konklusion, at B var blevet udsat
> for et portscan af D.
Og for så lige at sætte kronen på værket. Indser
man, at det fra Ds synspunkt næsten ser ud som om,
at D er blevet brugt som zombie i et idlescan af B.
Bortset fra de manglende IPID probes. Men dem kan
A så passende spoofe med E som afsender. Så nu har
A opnået at scanne C, men:
C tror at han er blevet portscannet af B.
B tror at han er blevet portscannet af D. Med
mindre B kan gennemskue, at det er et idlescan,
så tror B nemlig at D har brugt B som zombie i
et idlescan af C.
Og endelig tror D, at E har brugt D som zombie i
et idlescan af B.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
a servant of Isa, Ye~ (22-05-2004)
| Kommentar Fra : a servant of Isa, Ye~ |
Dato : 22-05-04 20:54 |
|
"Kasper Dupont" skrev
news:40AD972D.9C288C19@daimi.au.dk
Jeg har for nemhedens skyld klippet mit indlæg over i 2
PART 1:
NB!
Spring til part 2, den er sjovere
[ ... ]
> IP-adressen bliver misbrugt, men det betyder ikke, at maskinen
> med den pågældende IP-adresse er blevet udsat for noget angreb.
> Er IP spoofing i sig selv ulovligt? Jeg ved det ikke, men du
> får en ret tung bevisbyrde at løfte.
> > "Arkiveres" angriberens IP-adresse på Zombiens computer, således at man
> > senere kan efterspore denne ?
>
> Nej.
Øv!
> > (Såfremt svaret er *nej*:)
> > Kan man muliggøre dette med et program ?
>
> ethereal
Den må du lige uddybe for mig
(jeg er som tidligere sagt en håbløs amatør)
> > Kan man få et program (Pg-1.2), der forhindrer, at min computer svarer
> > tilbage til angriberen, således at man derved undgår at blive en Zambie
> > ?
>
> Din computer skal svare, at unlade at svare ville være en
> overtrædelse af TCP standarden. Men med en god IP implementation
> ville svarene ikke kunne bruges til noget.
Og hvordan får jeg på min computer en god IP implementation ?
(vedr. zombie)
>...> Vil min computer også kunne benyttes hertil, selvom jeg har firewall ?
> Hvilken firewall du bruger. Hvordan den er opsat. Hvor mange
> maskiner, der sidder bagved firewallen, og hvor meget de
> bruger netforbindelsen. NAT slået til eller fra i firewallen.
> Sendes svaret af firewallen selv eller maskinen bagved.
> Ændres IPID i firewallen. Hvordan genererer firewallen IPID.
>
> Under nogen omstændigheder kunne firewallen faktisk gøre det
> nemmere at udføre angrebet. ...
Ups!
> ... Hvis f.eks. firewallen selv
> sender svarene, men bruger sekventielle IPID. Så ville din
> firewall kunne bruges som zombie, uanset om maskinen bagved
> ville kunne være brugt eller ej.
Jeg har meget at lære, kan jeg se
> > > ... Men et forsøg på at
> > > løse problemet med en firewall, vil typisk medføre en
> > > række større problemer.
> >
> > Og disse er ?
>
> Hvis du bruger en firewall med en NAT funktion vil det være
> svært at garantere at der ikke sendes samme IPID to gange
> med for kort mellemrum. Det samme gælder, hvis nogen pakker
> genereres af firewallen, og andre genereres af maskiner
> bagved.
>
> En god firewall kunne selv generere IPID til alle udgående
> pakker, inklusiv dem, der kom fra maskiner bagved. ...
Taler vi her både om software og hardware firewall's ?
Har du konkrete forslag på sådanne firewall, således at jeg (og andre)
úmiddelbart kan anskaffe os sådan nogle ?
> ... Men så
> skal den også holde øje med IPID på de pakker den modtager
> fra maskinerne. Hvis en maskine sender to pakker med samme
> destination og IPID med kort mellemrum, så skal firewallen
> også bruge samme IPID til de to pakker.
Hvorfor *skal* firewallen det ?
> > Kan man ligeledes her få et program som *automatisk* vanskeliggør
> > forudsigeligheden af IPID numrene (således at brugeren ikke skal tænke
> > nærmere over dette) ?
>
> Det skal ligge i IP implementationen i dit OS. For det
> første kan du undersøge, om dit OS allerede har en god
> algoritme til generering af IPID. Det kan man vist teste
> med nmap. Hvis det ikke er tilfældet kan du undersøge, om
> IP implementationen kan udskiftes med en anden mere
> sikker version, eller om den har nogle hooks, som gør det
> muligt at ændre på IPID.
Puha - jeg lærer det nok aldrig
Punkt 2:
> > > > Og dette sker mens Zombie'n er on-line, således at angriberen kan få
> > > > feedback under punkt 3, eller hva' ?
> > >
> > > Ja.
> >
> > Fedt nok !!!
> >
> > Hvis vi opretter dette offensive forsvarssystem, da vil vi kunne
> > kontakte
> > Zombien og vente på at angriberen kommer og *afslører* sin IP-adresse.
>
> Det kan du ikke. ...
Æv!
> ... Zombien kan på ingen måde vide, hvilke
> pakker der bliver brugt til at probe dens IPID numre.
Dét, jeg tænkte på, var, at huske SAMTLIGE pakkers returadresser.
(angriberen må vel være en af dem)
Ved at sammenligne mange - rigtig mange - sådanne DATA-indsamlinger, vil
"visse" IP-adresser gå igen, og dermed afsløre angriberen.
> Enhver pakke Zombien sender indeholder oplysninger om
> dens IPID numre. Desuden ville dit system være alt for
> usikkert, da det ville tillade at trække alt for mange
> data ud af vilkårlige maskiner.
Det var nu også Internet-udbyderens forbindelse til klienten (zombien), jeg
havde i tankerne at overvåge og indsamle DATA fra.
> > > Nogle ting vil blive sløvet ned, fordi de bliver ved med
> > > at sende pakker til dig, som de forventer at få et svar
> > > på. ...
> >
> > Også selvom jeg *aldrig* har bedt om disse pakker ?
>
> Hvis du opretter en udgående forbindelse vil nogen
> maskiner kontakte din maskine på andre porte. F.eks.
> for at logge hvilken bruger på din maskine, der har
> åbnet forbindelsen. Du kan selv vælge, om den oplysning
> skal logges. Hvis du kører IDENT bliver brugernavnet
> logget, ellers gør det ikke. Men hvis din maskine ikke
> svarer, vil modparten være nødt til at sende sin pakke
> igen og igen indtil du svarer, eller der forekommer et
> timeout.
Det forstod jeg ikke helt:
Så problemet opstår altså kun, dersom der en flere brugere logget på det
interne netværk, eller hva' ?
Min tanke var jo, at computeren SELVFØLGELIG svarer "visse" udvalgte
modparter
> En anden grund til at oprette forbindelser tilbage til
> din maskine kunne være, at man kiggede efter åbne
> proxies på din maskine. Hvis din maskine havde en åben
> proxy, og dermed kunne misbruges, vil nogen ikke tage
> imod forbindelser fra dig. Igen vil det gå hurtigt,
> hvis din maskine blot sender en besked om, at porten
> er lukket. Hvis din maskine ikke svarer bliver du nødt
> til at vente på et timeout.
Hvor meget taler vi om i tid (Timeout's varighed) ?
> > (hvordan skulle afsenderen i så fald kunne have kendskab til min
> > computers eksistens)
> >
> > > ... Det ville også gøre det nemmere at spoofe din IP
> > > adresse i andre angreb, f.eks. mod maskiner med forudsigelige
> > > TCP sekvens numre.
> >
> > ... forudsat at min maskine sender svar,
>
> Nej, forudsat at din maskine ikke sender svar.
Nå
(jeg lærer det aldrig)
> > ... og viden
> > > om de spoofede pakker man har sendt. Alt sammen under
> > > antagelse af, at der ikke er anden trafik på zombien.
> >
> > Hvor mange sekunder taler vi her om ?
>
> Det kommer an på, hvor mange porte, der scannes ad
> gangen. Man kan f.eks. sende 100 pakker til den maskine,
> man vil scanne, mellem hver pakke sendt til zombien.
Det vil altså sige 2*100 pakker ?
For X = 1 to 100
1 pakke til offeret
1 pakke til zombien
NEXT X
Korrekt forstået ?
Efter hvor mange port-opkald slår firewallen for øvrigt alarm ?
Kan dette antal ændres ?
> Hvis man går ud fra, at der er minimum 32kb/s til
> rådighed kan de 100 pakker sendes på et sekund. Så skal
> man efterfølgende vente længe nok, til man er sikker på,
> at der er gået en roundtrip tid. Man kunne f.eks. vente
> et sekund. Så der skal nok ca. 3 sekunder uden trafik
> til, for at udføre dette scan.
Som en primitiv løsning, kunne man sætte sin computer til (i baggrunden) at
downloade et eller andet ligegyldigt på Internettet for derved at forhindre
NON-trafic-position ?
> Hvis alle porte var lukket og zombien var idle, så ville
> IPID vokse med en i mellem de to probes. ...
Kan dette forhindres ved at computer programmeres til altid at ventes med
feedback (indtil noget andet er sendt), således at IPID bliber úforudsigelig
?
> ... Hvis IPID var
> vokset mere end det, så måtte man prøve igen og kun tage
> halvdelen af portene hver gang.
Jeg har vist desværre misforstået noget her mht. (For X=1 to 100), æv
> > > ... Men det er mange personer, der skal
> > > overbevises om at overvåge uskyldige menneskers
> > > ligegyldige kommunikation. Og at overhovedet få sat den
> > > overvågning i gang med så kort varsel er urealistisk.
> >
> > Ikke for mig at se, dersom vi kan minimere overvågningen til blot et
> > enkelt objekt
>
> Det kan du ikke. Der er ingen måde at bevise, om en
> maskine bliver brugt som zombie. ...
Ved simpel sammenligning af mange rapporter fra indsamlede zombier,
fremkommer gentagelsesmønstret vel (angriberens IP-adresse) ?
> ... En nemmere og bedre
> løsning ville være, at afskaffe usiker IPID generering.
Med ordet *usiker* mener du givetvis, at computere i tide og utide svarer
med et IPID ?
Hvad er i så fald en såkaldt *sikker* IPID generering ?
> > > Du skal være opmærksom på, at mellemledet strengt taget
> > > ikke er blevet misbrugt. ...
> >
> > Det har vi så delte meninger om (IP-adresse misbrug)!
>
> Du kan sagtens misbruge en maskines IP adresse uden at
> misbruge maskinen.
Fuldstændig korrekt, men jeg betragter det som en art *falsk* underskrift.
Nogen udgiver sig for at være zombiens computers ejermand.
I det øjeblik zombien også benyttes, svarer det faktisk til, at angriberen
står og roder i min hoveddørslås og forsøger at dirke den op!
> > > Og trafik mellem scanneren og zombien kan være hvad som
> > > helst. Det kan være ganske legitim trafik. Det behøver
> > > ikke engang være initieret af scanneren. Jeg kunne sætte
> > > en server op, og når så min maskine bliver kontaktet, så
> > > spoofer jeg klientens IP i en idle-scan.
Jeg glemte lige hertil at tilføje, at i dette tilfælde har klienten jo
kontaktet dig, inden du på den foranledning påbegynder scanningen.
> > Hackere foretager YDERST sjældent kun disse angreb én gang.
> > Gentagelserne vil afsløre hackeren!
>
> IPID probes kan foretages ved legitim trafik. Desuden
> kan de maskeres ved samtidig at spoofe SYN pakker til
> lukkede porte på zombien.
Fint at du nu her efterfølgende kommer med et eksempel,
for jeg var desværre stået af
Jump PART 2
Tak for din hjælp, Kasper
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2221
| |
Christian E. Lysel (22-05-2004)
| Kommentar Fra : Christian E. Lysel |
Dato : 22-05-04 21:27 |
|
In article <zdOrc.1541$Vf.39606@news000.worldonline.dk>, a servant of Isa, Yeshua wrote:
>> > Kan man muliggøre dette med et program ?
>>
>> ethereal
>
> Den må du lige uddybe for mig
> (jeg er som tidligere sagt en håbløs amatør)
Hvor gammel er du?
--
Mvh.
Christian E. Lysel
http://www.spindelnet.dk/
| |
Kasper Dupont (22-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 22-05-04 22:57 |
|
"a servant of Isa, Yeshua" wrote:
>
> "Kasper Dupont" skrev
> news:40AD972D.9C288C19@daimi.au.dk
> >
> > ethereal
>
> Den må du lige uddybe for mig
> (jeg er som tidligere sagt en håbløs amatør)
Det er et program, som kan overvåge trafikken på netværket.
Det kan gemme trafikken i en fil, åbne en tidligere gemt
fil og afkode en række protokoller, eller afkode trafikken
i realtime.
Du kan selv vælge om det skal lytte på et enkelt eller
alle netværks interfaces. Du kan også vælge, om den skal
lytte efter alt trafik på dette interface, eller kun den
som kommer dig ved.
Endelig kan du opsætte filter regler for, hvilke pakker,
der skal holdes øje med, og hvilke, der skal ignoreres.
Jeg bruger det selv de fleste gange jeg har netværks
problemer. Hvis man er mere til kommandolinien kan
tcpdump bruges, den kan ikke så meget som ethereal, men
du kan vist godt lade tcpdump gemme trafik i en fil, som
senere kan analyseres med ethereal.
Jeg kører selv Fedora, men jeg har hørt at ethereal også
fås til Windows.
>
> Og hvordan får jeg på min computer en god IP implementation ?
Jeg må indrømme, at jeg kender ikke til detaljer i de
enkelte systemers IP implementationer, så jeg håber en,
der kender dem bedre vil uddybe.
Så vidt jeg ved har OpenBSD en af de bedste du kan finde.
Hvad angår Windows er jeg meget i tvivl, for jeg har
både hørt, at den er hugget fra BSD, og at den er i den
dårlige ende. Og hvordan de to ting kan hænge sammen kan
jeg ikke lige gennemskue.
Jeg ved ikke, om det under Windows er muligt at udskifte
sin IP implementation med en anden og bedre. Men det er
tit blevet sagt, at trojaner kan installere deres egen
for at slippe udenom evt. firewalls, så det er måske
muligt.
> >
> > En god firewall kunne selv generere IPID til alle udgående
> > pakker, inklusiv dem, der kom fra maskiner bagved. ...
>
> Taler vi her både om software og hardware firewall's ?
Når jeg siger firewall mener jeg hardware. En
software firewall vil altid indebære en risiko.
Bare i år har to af dem været berørt af alvorlige
sikkerhedshuller, som reelt gjorde maskinerne mere
udsatte med firewalle end uden.
Så en god firewall er seperat hardware. Bemærk, at
nogen firewalls som f.eks. iptables både kan sættes op
på den maskine, der skal beskyttes, og kan sættes op
på en seperat maskine, der så beskytter en anden
maskine bagved. Så iptables kan afhængigt af opsætningen
høre i den ene eller den anden klasse.
IPID problematiken bliver selvfølgelig lidt simplere,
hvis der kun er én maskine, da man muligvis kan undgå
den koordinering, der skulle til for at undgå
repeterede ID'er. Men hvis firewallen selv sender
pakker og har sin egen tilstand til generering af IPID
har man igen problematikken, på den anden side kan en
software firewall også sagtens ændre IPID inden
pakkerne sendes.
Det ville altså være muligt for en firewall (hardware
eller software) at kompensere for dårlige IPID fra
systemerne bagved. Men det er svært at gøre rigtigt.
>
> Har du konkrete forslag på sådanne firewall, således at jeg (og andre)
> úmiddelbart kan anskaffe os sådan nogle ?
Desværre, jeg kender ikke udvalget godt nok. Er der
nogen i gruppen, som ved hvordan en OpenBSD maskine
konfigureret til at fungere som firewall ville
håndtere IPID? Eller evt. om der findes andre
firewall produkter med en god håndtering af IPID?
>
> > ... Men så
> > skal den også holde øje med IPID på de pakker den modtager
> > fra maskinerne. Hvis en maskine sender to pakker med samme
> > destination og IPID med kort mellemrum, så skal firewallen
> > også bruge samme IPID til de to pakker.
>
> Hvorfor *skal* firewallen det ?
Har du forstået hvad formålet med IPID er?
Der er forskel på hvor store pakker, der kan sendes
over forskellige forbindelser på nettet. En pakke
kan altså på sin vej komme ud for at komme til en
forbindelse, hvor den simpelthen er for stor og
skal opdeles.
Disse fragmenterede pakker skal samles igen. Til
dette formål er der tre oplysninger at kigge på
afsender, modtager og IPID. Hvis alle tre er
identiske kan man gå ud fra at fragmenterne stammer
fra samme originale pakke og sætte dem sammen.
Bemærk at portnumre ikke kommer ind i billedet her,
fordi de ligger på et højere protokollag. Man kan
ikke se portnummere på en fragmenteret pakke (kun
på det første fragment, som i øvrigt sagents kunne
blive sendt sidst).
Hvis en maskine sender to pakke til samme destination
og med samme IPID indenfor kort tid, så er der en
risiko for at begge bliver fragmenteret og sat forkert
sammen.
Så der er to fejl firewallen kan begå, og det er svært
at undgå begge. Hvis en pakke allerede er fragmenteret
når den sendes udad indefra, så kommer der to pakker
til firewallen med samme IPID, og de skal sendes
videre med samme IPID for at kunne sættes rigtigt
sammen. (Men ikke nødvendigvis samme IPID på indersiden
og ydersiden af firewallen). Sendes de to pakker
videre med forskelligt IPID kan de ikke sættes sammen
som de skal.
Hvis der foregår NAT vil pakker indefra, fra to
forskellige maskiner blive sendt videre ud på
internettet med samme afsender IP. Det betyder, at to
pakker indefra som før havde forskellig afsender, har
samme afsender, når de kommer ud på internettet. Hvis
de også har samme modtager og IPID kan de fejlagtigt
blive sat sammen.
Og det er ikke usandsynligt at to maskiner på samme
tid snakker med samme server. Og en kollision på IPID
er sandsynlig pga. det meget få valgmuligheder. IPID
er nemlig kun på 16 bits.
Der er en mulighed for at mærke pakker, som ikke må
opdeles. Hvis sådan en pakke viser sig at være for
stor, så sendes der en fejlmelding tilbage. Det
bruges f.eks. tit af TCP, så kan man nøjes med at
sende pakker, som ligger indenfor grænsen. TCP kan
nemlig selv lave en opdeling, og TCPs egen opdeling
er meget bedre end opdeling på IP niveauet. Når
opdelingen sker i TCP kalder man det segmentering.
Hvis pakken ikke må opdeles har man slet ikke brug
for IPID. Og så er det bedre at bare sætte et IPID
på, som afslører så lidt som muligt, for der er ikke
risiko for kollisioner.
>
> Dét, jeg tænkte på, var, at huske SAMTLIGE pakkers returadresser.
> (angriberen må vel være en af dem)
Det kan du godt. Men du kan jo ikke undersøge alle
pakkerne.
>
> Ved at sammenligne mange - rigtig mange - sådanne DATA-indsamlinger, vil
> "visse" IP-adresser gå igen, og dermed afsløre angriberen.
En IP adresse kunne jo sagtens gå igen af andre
årsager. Og selvom der kun er en IP adresse, der går
igen hos to zombier, så kan det jo være de er blevet
af forskellige maskiner, der har foretaget scanningen.
>
> > Enhver pakke Zombien sender indeholder oplysninger om
> > dens IPID numre. Desuden ville dit system være alt for
> > usikkert, da det ville tillade at trække alt for mange
> > data ud af vilkårlige maskiner.
>
> Det var nu også Internet-udbyderens forbindelse til klienten (zombien), jeg
> havde i tankerne at overvåge og indsamle DATA fra.
OK, det gør alt andet lige situationen lidt bedre.
Både hvad angår risiko for misbrug og praktiske
forhold omkring implementationen. Men det ville være
både nemmere og bedre hvis udbyderne bare forhindrede
deres egne kunder i at spoofe source IP.
>
> > > > Nogle ting vil blive sløvet ned, fordi de bliver ved med
> > > > at sende pakker til dig, som de forventer at få et svar
> > > > på. ...
> > >
> > > Også selvom jeg *aldrig* har bedt om disse pakker ?
> >
> > Hvis du opretter en udgående forbindelse vil nogen
> > maskiner kontakte din maskine på andre porte. F.eks.
> > for at logge hvilken bruger på din maskine, der har
> > åbnet forbindelsen. Du kan selv vælge, om den oplysning
> > skal logges. Hvis du kører IDENT bliver brugernavnet
> > logget, ellers gør det ikke. Men hvis din maskine ikke
> > svarer, vil modparten være nødt til at sende sin pakke
> > igen og igen indtil du svarer, eller der forekommer et
> > timeout.
>
> Det forstod jeg ikke helt:
>
> Så problemet opstår altså kun, dersom der en flere brugere logget på det
> interne netværk, eller hva' ?
IDENT er kun relevant hvis din computer har flere
brugere. Modparten kan så logge ikke blot, at din
computer er blevet brugt, men også hvilken bruger.
Selvfølgelig kun, hvis du selv vil afsløre det.
Hvis du efterfølgende bliver kontaktet omkring at
din maskine har været involveret i noget misbrug
(spam f.eks.), så kan du få at vide, hvilken bruger
på din maskine, der er ansvarlig.
Men der er andre situationer. Der kan f.eks. være
mailservere, som for at undgå spam undersøger, om
din maskine står åben for misbrug inden de vil tage
imod mail fra den.
I begge tilfælde vil dit forsøg på at kontakte
serveren blive besvaret af et forsøg på at åbne en
forbindelse tilbage. Du kommer til at vente på at
dette er overstået. Hvis din computer hurtigt
melder tilbage, at der er lukket, bliver ventetiden
kortere.
>
> Min tanke var jo, at computeren SELVFØLGELIG svarer "visse" udvalgte
> modparter
Man kunne holde øje med, hvem man selv kontatker,
og kun svare til dem. Det ville nok virke i de
fleste tilfælde. Men der kan både være falske
positiver og falske negativer.
For det første kunne forbindelsen tilbage godt
komme et andet sted fra, selvom det er usædvanligt.
Og på den anden side, så kunne jeg nok nare dig
til at åbne en forbindelse til min computer.
>
> Hvor meget taler vi om i tid (Timeout's varighed) ?
Meget varierende, det kan vist være alt fra et par
sekunder til flere minutter. Jeg har selv lige
målt timeouts i nogle lignende situationer og der
var timeouts på både 3 sekunder og 3 minutter.
> >
> > Det kommer an på, hvor mange porte, der scannes ad
> > gangen. Man kan f.eks. sende 100 pakker til den maskine,
> > man vil scanne, mellem hver pakke sendt til zombien.
>
> Det vil altså sige 2*100 pakker ?
>
> For X = 1 to 100
> 1 pakke til offeret
> 1 pakke til zombien
> NEXT X
>
> Korrekt forstået ?
Nej.
Send 1 pakke til zombien
Vent på svar fra zombien
For X = 1 to 100
vent 0.01 sekund
send 1 pakke til offerets port X med zombien angivet som afsender
Next X
Vent 1 sekund
Send 1 pakke til zombien
Vent på svar fra zombien
>
> Efter hvor mange port-opkald slår firewallen for øvrigt alarm ?
Min firewall slår aldrig alarm. Den logger alle
uventede pakker, så kan jeg selv kigge i min
logfil.
>
> Som en primitiv løsning, kunne man sætte sin computer til (i baggrunden) at
> downloade et eller andet ligegyldigt på Internettet for derved at forhindre
> NON-trafic-position ?
Alternativ løsning, men ja, det ville gøre det
sværere at bruge din maskine som zombie i et
idle-scan. Artiklen fortæller dog, at en maskine
med noget trafik også godt kan bruges ved at
sende så mange pakker ad gangen, at de stadig gør
en synlig forskel.
Den bedste løsning ville selvfølgelig være en
bedre algoritme for IPID. Bemærk at de RST pakker
som zombien sender til offeret er så små, at de
aldrig vil blive fragmenteret. Det vil sige, at
man kunne skrive en tilfældig værdi i IPID feltet
og helt unlade at tælle sin IPID tæller op. Så
ville man med en meget lille ændring af IP
implementationen forhindre at man blev zombie i et
idle-scan.
I praksis burde det gøres ved at sætte DF flaget
på alle TCP pakker og lade IP laget bruge forskellig
IPID tildelingsstrategi for pakker med og uden DF.
>
> > Hvis alle porte var lukket og zombien var idle, så ville
> > IPID vokse med en i mellem de to probes. ...
>
> Kan dette forhindres ved at computer programmeres til altid at ventes med
> feedback (indtil noget andet er sendt), således at IPID bliber úforudsigelig
> ?
Det er nok ikke en god idé at vente for længe med
at sende RST pakken. Du kan jo ikke vide hvor længe,
der vil gå, før der kommer anden trafik. Desuden
ville det kunne misbruges. Jeg kunne jo sende pakker
til dig, og udfra svartiden regne ud hvad du ellers
sendte af trafik. Det kan man selvfølgelig allerede
i nogen udstrækning gør i dag, men dit forslag
ville gøre den slags misbrug meget nemmere.
> >
> > Det kan du ikke. Der er ingen måde at bevise, om en
> > maskine bliver brugt som zombie. ...
>
> Ved simpel sammenligning af mange rapporter fra indsamlede zombier,
> fremkommer gentagelsesmønstret vel (angriberens IP-adresse) ?
Udfør scanningen forskellige stedder fra, og tilføj
samtidig nogle spoofede IPID probes. Så vil din
analyse af angrebsmønstret nemt kunne pege på en
forkert maskine.
>
> > ... En nemmere og bedre
> > løsning ville være, at afskaffe usiker IPID generering.
>
> Med ordet *usiker* mener du givetvis, at computere i tide og utide svarer
> med et IPID ?
Der er et IPID på alle pakker der sendes med IP. Og
svarene skal sendes. Men i mange tilfælde kan man
sætte et ubrugeligt IPID i pakken. At sætte et
ubrugeligt IPID på alle pakker, hvor man alligevel
ikke har noget at bruge IPID til ville løse problemet
med idle scan.
>
> Hvad er i så fald en såkaldt *sikker* IPID generering ?
Mit forslag er her:
http://www.daimi.au.dk/~kasperd/ipid.c
Det skal selvfølgelig kun bruges til de pakker, hvor
man faktisk har brug for IPID. Alle pakker med et DF
flag kan man bare smide en tilfældig værdi i IPID.
Alternativt kunne man prøve at lave forskellig IPID
generering afhængig af modtagerens IP adresse. Men
jeg har ikke nogen god idé til hvordan man gør det
med et acceptabelt hukommelsesforbrug.
>
> > > > Du skal være opmærksom på, at mellemledet strengt taget
> > > > ikke er blevet misbrugt. ...
> > >
> > > Det har vi så delte meninger om (IP-adresse misbrug)!
> >
> > Du kan sagtens misbruge en maskines IP adresse uden at
> > misbruge maskinen.
>
> Fuldstændig korrekt, men jeg betragter det som en art *falsk* underskrift.
Enig. Men det er ikke nødvendigvis sket i ond mening.
Det kan f.eks. være sket ved en fejl. Og hvis det
heller ikke gør nogen skade (og det gør det ikke i
det her tilfælde), så er det nok ikke engang ulovligt.
> Nogen udgiver sig for at være zombiens computers ejermand.
>
> I det øjeblik zombien også benyttes, svarer det faktisk til, at angriberen
> står og roder i min hoveddørslås og forsøger at dirke den op!
Den sammenligning kan ikke bruges til noget.
>
> > > > Og trafik mellem scanneren og zombien kan være hvad som
> > > > helst. Det kan være ganske legitim trafik. Det behøver
> > > > ikke engang være initieret af scanneren. Jeg kunne sætte
> > > > en server op, og når så min maskine bliver kontaktet, så
> > > > spoofer jeg klientens IP i en idle-scan.
>
> Jeg glemte lige hertil at tilføje, at i dette tilfælde har klienten jo
> kontaktet dig, inden du på den foranledning påbegynder scanningen.
Ja. Men det er ikke klienten jeg scanner. Det er dig
jeg scanner. Og for dig vil det se ud som om du
bliver scannet af min klient. Og hvis jeg spoofer et
par IPID probes til min klient, så vil klienten nok
tro det er den maskine, der har foretaget et idle-scan
og ikke min server, som han jo selv har kontaktet, og
som ikke har sendt en eneste uventet pakke til klienten.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use kasperd@kd.lir.dk and abuse@kd.lir.dk
I'd rather be a hammer than a nail.
| |
Kent Friis (23-05-2004)
| Kommentar Fra : Kent Friis |
Dato : 23-05-04 09:09 |
|
Den Sat, 22 May 2004 23:57:15 +0200 skrev Kasper Dupont:
> "a servant of Isa, Yeshua" wrote:
>>
>> Hvor meget taler vi om i tid (Timeout's varighed) ?
>
> Meget varierende, det kan vist være alt fra et par
> sekunder til flere minutter. Jeg har selv lige
> målt timeouts i nogle lignende situationer og der
> var timeouts på både 3 sekunder og 3 minutter.
Der findes sågar FTP-servere der helt afviser folk hvis ikke de får
mindst connection refused på en ident-forespørgsel.
Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/
| |
a servant of Isa, Ye~ (23-05-2004)
| Kommentar Fra : a servant of Isa, Ye~ |
Dato : 23-05-04 14:30 |
|
"Kasper Dupont" skrev
news:40AFCCBB.EDD589B0@daimi.au.dk
> > > ethereal
> >
> > Den må du lige uddybe for mig
> > (jeg er som tidligere sagt en håbløs amatør)
>
> Det er et program, som kan overvåge trafikken på netværket.
> Det kan gemme trafikken i en fil, åbne en tidligere gemt
> fil og afkode en række protokoller, eller afkode trafikken
> i realtime.
>
> Du kan selv vælge om det skal lytte på et enkelt eller
> alle netværks interfaces. Du kan også vælge, om den skal
> lytte efter alt trafik på dette interface, eller kun den
> som kommer dig ved.
>
> Endelig kan du opsætte filter regler for, hvilke pakker,
> der skal holdes øje med, og hvilke, der skal ignoreres.
>
> Jeg bruger det selv de fleste gange jeg har netværks
> problemer. Hvis man er mere til kommandolinien kan
> tcpdump bruges, den kan ikke så meget som ethereal, men
> du kan vist godt lade tcpdump gemme trafik i en fil, som
> senere kan analyseres med ethereal.
>
> Jeg kører selv Fedora, men jeg har hørt at ethereal også
> fås til Windows.
Dette program er lige noget for mig
(elsker at pille)
Hvor kan jeg få dette program ?
Ved free download fra Internettet:
Hvorledes kan jeg sikre mig, at programmet ikke ved et uheld downloades fra
en såkaldt
hackers hjemmeside (mange forfalskninger forekommer jo), der så - straks
foretager en scanning af min computers porte (således som du selv har
fortalt, at du gør, når en klient kontakter din server) mhp. hack'ning ?
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2228
| |
Kasper Dupont (23-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 23-05-04 15:56 |
|
"a servant of Isa, Yeshua" wrote:
>
> Dette program er lige noget for mig
> (elsker at pille)
>
> Hvor kan jeg få dette program ?
Her er oplysningerne fra min maskine (og jeg checkede
lige, at man også kan downloade Windows versionen fra
ethereal.com):
Name : ethereal Relocations: (not relocateable)
Version : 0.10.0a Vendor: Red Hat, Inc.
Release : 0.1 Build Date: Thu Dec 18 17:09:59 2003
Install Date: Wed Mar 31 21:38:05 2004 Build Host: daffy.perf.redhat.com
Group : Applications/Internet Source RPM: ethereal-0.10.0a-0.1.src.rpm
Size : 10632677 License: GPL
Signature : DSA/SHA1, Thu Dec 18 17:22:38 2003, Key ID b44269d04f2a6fd2
Packager : Red Hat, Inc. < http://bugzilla.redhat.com/bugzilla>
URL : http://www.ethereal.com/
Summary : Network traffic analyzer
Description :
Ethereal is a network traffic analyzer for Unix-ish operating systems.
This package lays base for libpcap, a packet capture and filtering
library, contains command-line utilities, contains plugins and
documentation for ethereal. A graphical user interface is packaged
separately to GTK+ package.
>
> Ved free download fra Internettet:
> Hvorledes kan jeg sikre mig, at programmet ikke ved et uheld downloades fra
> en såkaldt
> hackers hjemmeside (mange forfalskninger forekommer jo),
Alt der skrives på usenet uden nogen signatur kan jo
forfalskes. Så uanset hvad jeg fortæller dig, kan det
ikke blive mere sikkert end blot at downloade filen
fra ethereal.com.
Selvfølgelig er spørgsmålet relevant. Jeg selv har
pakkerne fra Red Hat med Red Hats signatur på. Men det
er jo kun Linux versionen. Og den signatur kan kun
bruges til noget hvis du i forvejen har den offentlige
nøgle og et program til at checke denne.
> der så - straks
> foretager en scanning af min computers porte
Nej, nu er du naiv. Hvis du er ved at downloade en
programfil er det da meget nemmere at bare give dig en
trojan, i stedet for at gå gennem alt det andet besvær.
> (således som du selv har
> fortalt, at du gør, når en klient kontakter din server) mhp. hack'ning ?
Det var ikke det jeg sagde.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use kasperd@kd.lir.dk and abuse@kd.lir.dk
I'd rather be a hammer than a nail.
| |
a servant of Isa, Ye~ (23-05-2004)
| Kommentar Fra : a servant of Isa, Ye~ |
Dato : 23-05-04 14:30 |
|
"Kasper Dupont" skrev
news:40AFCCBB.EDD589B0@daimi.au.dk
[ ... ]
> > Og hvordan får jeg på min computer en god IP implementation ?
>
> Jeg må indrømme, at jeg kender ikke til detaljer i de
> enkelte systemers IP implementationer, så jeg håber en,
> der kender dem bedre vil uddybe.
Svar herpå efterlyses.
På forhånd tak
> Så vidt jeg ved har OpenBSD en af de bedste du kan finde.
> Hvad angår Windows er jeg meget i tvivl, for jeg har
> både hørt, at den er hugget fra BSD, og at den er i den
> dårlige ende. Og hvordan de to ting kan hænge sammen kan
> jeg ikke lige gennemskue.
>
> Jeg ved ikke, om det under Windows er muligt at udskifte
> sin IP implementation med en anden og bedre. ...
Svar herpå efterlyses.
På forhånd tak
> ... Men det er
> tit blevet sagt, at trojaner kan installere deres egen
> for at slippe udenom evt. firewalls, ...
I den forbindelse melder spørgsmålet sig:
Kan trojaneren da spille udenom både en software- og hardware-firewall ?
> ... så det er måske
> muligt.
Det bør i hvert fald af- eller bekræftes.
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2229
| |
Kasper Dupont (23-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 23-05-04 16:02 |
|
"a servant of Isa, Yeshua" wrote:
>
> Kan trojaneren da spille udenom både en software- og hardware-firewall ?
Hvis ikke dit OS har en sikkerhedsmodel, der forhindrer
det, så kan trojanen slippe udenom enhver software
firewall.
En hardware firewall kan den selvfølgelig ikke på samme
måde slippe udenom, men firewallen kan jo ikke se,
hvilket program, der kommunikerer. Så trafik som er
tilladt af din firewall konfiguration kan trojanen
sende på lige vilkår med alle andre programmer.
En software firewall kan prøve at undersøge, hvilket
program, der kommunikerer. Men det kan som regel nemt
omgås. (Der er i øvrigt nogen, der har prøvet at lave
en modificeret IP protokol til brug på lokalnettet, så
firewallen kan se, hvilket program, der bruges. Men
stadigvæk forudsætter det en sikkerhedsmodel, som
trojanen ikke kan slippe udenom.)
Og i øvrigt er det ikke særligt interessant at prøve
at forhindre en trojan i at kommunikere på netværket.
Den kan gøre meget skade uden at bruge netværket, så
den skal slet ikke lukkes ind i første omgang.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use kasperd@kd.lir.dk and abuse@kd.lir.dk
I'd rather be a hammer than a nail.
| |
a servant of Isa, Ye~ (23-05-2004)
| Kommentar Fra : a servant of Isa, Ye~ |
Dato : 23-05-04 14:30 |
|
"Kasper Dupont" skrev
news:40AFCCBB.EDD589B0@daimi.au.dk
[ ... ]
> > > En god firewall kunne selv generere IPID til alle udgående
> > > pakker, inklusiv dem, der kom fra maskiner bagved. ...
> >
> > Taler vi her både om software og hardware firewall's ?
>
> Når jeg siger firewall mener jeg hardware. En
> software firewall vil altid indebære en risiko.
> Bare i år har to af dem været berørt af alvorlige
> sikkerhedshuller, som reelt gjorde maskinerne mere
> udsatte med firewalle end uden.
>
> Så en god firewall er seperat hardware. Bemærk, at
> nogen firewalls som f.eks. iptables både kan sættes op
> på den maskine, der skal beskyttes, og kan sættes op
> på en seperat maskine, der så beskytter en anden
> maskine bagved. Så iptables kan afhængigt af opsætningen
> høre i den ene eller den anden klasse.
>
> IPID problematiken bliver selvfølgelig lidt simplere,
> hvis der kun er én maskine, da man muligvis kan undgå
> den koordinering, der skulle til for at undgå
> repeterede ID'er. Men hvis firewallen selv sender
> pakker og har sin egen tilstand til generering af IPID
> har man igen problematikken, på den anden side kan en
> software firewall også sagtens ændre IPID inden
> pakkerne sendes.
>
> Det ville altså være muligt for en firewall (hardware
> eller software) at kompensere for dårlige IPID fra
> systemerne bagved. Men det er svært at gøre rigtigt.
Med hensyn til software-firewall:
(Mange mennesker kører med Windows som OS, og en hel del af dem er sårbare
overfor misbrug)
For dem som køber firewall af Antivirus-firmaerne:
Hvilke producenter kan her anbefales ?
(så disses firewall kompenserer for dårlige IPID'er)
Er dette for øvrigt et fast standart-indstilling i disse produkter ?
(mht. Windows XP's firewall, om denne kan ændres og dermed kompensere for
dårlige IPID'er, er spørgsmålet gentaget i forrige indlæg, se fil 2229)
> > Har du konkrete forslag på sådanne firewall, således at jeg (og andre)
> > úmiddelbart kan anskaffe os sådan nogle ?
>
> Desværre, jeg kender ikke udvalget godt nok. Er der
> nogen i gruppen, som ved hvordan en OpenBSD maskine
> konfigureret til at fungere som firewall ville
> håndtere IPID? Eller evt. om der findes andre
> firewall produkter med en god håndtering af IPID?
Svar herpå efterlyses.
På forhånd tak
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2230
| |
Kasper Dupont (23-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 23-05-04 16:04 |
|
"a servant of Isa, Yeshua" wrote:
>
> Med hensyn til software-firewall:
>
> (Mange mennesker kører med Windows som OS, og en hel del af dem er sårbare
> overfor misbrug)
>
> For dem som køber firewall af Antivirus-firmaerne:
>
> Hvilke producenter kan her anbefales ?
http://sikkerhed-faq.dk/personlig-fw-eval
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use kasperd@kd.lir.dk and abuse@kd.lir.dk
I'd rather be a hammer than a nail.
| |
a servant of Isa, Ye~ (23-05-2004)
| Kommentar Fra : a servant of Isa, Ye~ |
Dato : 23-05-04 14:30 |
|
"Kasper Dupont" skrev
news:40AFCCBB.EDD589B0@daimi.au.dk
[ .... ]
> > > ... Men så
> > > skal den også holde øje med IPID på de pakker den modtager
> > > fra maskinerne. Hvis en maskine sender to pakker med samme
> > > destination og IPID med kort mellemrum, så skal firewallen
> > > også bruge samme IPID til de to pakker.
> >
> > Hvorfor *skal* firewallen det ?
>
> Har du forstået hvad formålet med IPID er?
Nej - nok ikke helt
> Der er forskel på hvor store pakker, der kan sendes
> over forskellige forbindelser på nettet. En pakke
> kan altså på sin vej komme ud for at komme til en
> forbindelse ...
Markør *1
> ... , hvor den simpelthen er for stor og
> skal opdeles.
Bare lige af nysgerighed:
Hvor meget taler vi ca. om i Bytes pr. pakke ?
(100, 1K, 10K, 100K)
> Disse fragmenterede pakker skal samles igen. Til
> dette formål er der tre oplysninger at kigge på
> afsender, modtager og IPID. ...
Tillad mig at gøre et lille break her:
Hvor mange forbindelser er der undervejs ?
(fra afsender A til modtager B)
Det afhænger selvfølgelig af, hvor A og B befinder sig. Fra Danmark til Kina
er der flere mellemled, end ved en kort distance fra Christania til
Christiansborg (må vi antage).
Taler vi om et interval fra 10 til 10.000 stk. ?
Minimum og maximun værdierne ?
-
Hvorfor jeg nu begynder at efterlyse dette, skyldes at vi jo indenfor mange
områder benytter kilde-henvisninger. Vi ønsker - kort og godt - at kunne
gendanne originalen.
Forstå mig ret:
Vi er alle - næsten alle - blevet trætte af dette misbrug med spoofet
pakke-post.
Hvorledes kan dette forebygges ?
Ved at afsløre afsenderen.
Hvis nu alle mellemled (*1) havde et *identitetsnummer*, og at dette nummer
blev hæftet på hver eneste pakke, som løber igennem mellemleddet, da ville
vi - teoretisk set - kunne spore den egentlige afsender.
Problemet med et sådant system er, at hver pakke vil vokse med nogle bytes
for hvert mellemled, det passerer.
Lad os beregne dette:
Antager vi, at der er ca. 1000 milliarder mellemled (*1) i alt, så har jeg
vist ikke underdrevet.
Dette givet et identitetsnummer på ca. 5 Bytes (256^5=1GB)
Hvis der er ca. 1000 mellemled, da får vi altså 5000 Bytes hæftet på
original pakken.
Og det er alt for meget !!!
Derfor kunne vi videre-udvikle idéen:
Afsender A's første mellemled (forbindelse, *1) påhæfter sit
identitetsnummer, og dette nummer følger pakken resten af ruten til
modtageren B. B får hermed mulighed for at spore A's første forbindelsesled
(fx. A's Internet-udbyder).
(sølle 5 Bytes ekstra i systemet)
Dumt forslag ?
Jamen - hvad nu hvis A's første mellemled er en del af sammensværgelsen ?
Så kunne vi jo sige, at første *autoriserede* mellemled, DESFORUDEN
vedhæfter sit identitetsnummer SAMT klokkeslet.
Så har vi da fået indkredset de "uheldige" elementer noget, eller hva' ?
-
Jeg venter med at gennemlæse resten, Kasper.
Jeg er jo allerede kommet håbløs bagud, men jeg takker mange gange for din
hjælp, og jeg glæder mig til at gennemgå resten. Det tager blot en
skrækkelig tid. Som du selv skriver: "Kasper Dupont -- der bruger for meget
tid paa usenet."
Hav' en god dag - og som sagt: Tak for hjælpen
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2231
| |
Kasper Dupont (23-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 23-05-04 16:28 |
|
"a servant of Isa, Yeshua" wrote:
>
> Bare lige af nysgerighed:
>
> Hvor meget taler vi ca. om i Bytes pr. pakke ?
> (100, 1K, 10K, 100K)
Maksimalt 64KB (minus 1 byte) per IP pakke. Det er summen
af alle fragmenter. Det vil sige at uanset hvor mange
fragmenter der sendes må den samlede pakke ikke nå op på
64KB eller mere.
En typisk fejl at begå, når man laver en IP implementation
er, at ikke checke dette rigtigt. Så når det sidste
fragment starter indenfor de 64KB så kan det godt være at
slutningen når ud til 65KB og så går computeren ned (eller
det der er værre).
Størrelsen på det enkelte fragment afhænger af netværks
typen. På ethernet er grænsen f.eks. 1500 bytes hvoraf de
20 bruges til IP headeren. Så en pakke kunne f.eks. bestå
af 44 fragmenter af 1480 bytes hver. Det er dog sjældent
en god idé at bruge så mange fragmenter.
>
> > Disse fragmenterede pakker skal samles igen. Til
> > dette formål er der tre oplysninger at kigge på
> > afsender, modtager og IPID. ...
>
> Tillad mig at gøre et lille break her:
>
> Hvor mange forbindelser er der undervejs ?
> (fra afsender A til modtager B)
Typisk 10-30 styk. Jeg gav et eksempel i et af
indlægene.
>
> Det afhænger selvfølgelig af, hvor A og B befinder sig. Fra Danmark til Kina
> er der flere mellemled, end ved en kort distance fra Christania til
> Christiansborg (må vi antage).
>
> Taler vi om et interval fra 10 til 10.000 stk. ?
>
> Minimum og maximun værdierne ?
Absolut maximum er 255. Der bruges nemlig kun en byte
på TTL. (En tæller som skal forhindre at en pakke
kører i ring i uendelig lang tid.)
Men de fleste systemer sætter en mindre TTL på pakkerne,
64 er vist meget normalt. Så hvis der er mere end 64 hop
så bliver pakken smidt væk inden den når sit mål.
>
> Hvis nu alle mellemled (*1) havde et *identitetsnummer*,
Det har de allerede.
> og at dette nummer
> blev hæftet på hver eneste pakke, som løber igennem mellemleddet, da ville
> vi - teoretisk set - kunne spore den egentlige afsender.
Den mulighed er allerede til stede, det kræver blot at
afsenderen beder om det. Men jeg er ikke sikker på, at
der er ret mange som understøtter det. Desuden ville det
give performance problemer.
Og ligesom med alle de andre forslag. Hvis du ikke kan
få udbyderne til at lukke for spoofing, hvordan i
alverden ville du så få dem til at lave så omfattende
ændringer.
Ingen af de forslag du er kommet med har været bedre end
mine forslag om at simpelthen gøre to ting:
1) Forhindre sine egne kunder i spoofing
2) Ret i operativsystemerne, så de genererer bedre IPID.
I øvrigt 255 hops der skal skrive 4 bytes hver i pakken.
Det betyder, at 1020 af de 1500 bytes skal bruges på
registrering af ruten. Så skal der også bruges 20 bytes
på hhv IP og TCP headers, så er der 440 bytes tilbage
til en TCP payload. Dermed skal du (i bedste fald) bruge
3.4 gange så lang tid på den samme dataoverførsel.
>
> Jamen - hvad nu hvis A's første mellemled er en del af sammensværgelsen ?
>
> Så kunne vi jo sige, at første *autoriserede* mellemled, DESFORUDEN
> vedhæfter sit identitetsnummer SAMT klokkeslet.
Der er ikke noget der hedder autoriseret i det her system.
Desuden er der flere problemer med dit forslag. Det ville
kræve ændringer i protokollen, så ville det være nemmere
at få folk til at indføre IPv6 og/eller lukke for misbrug
i stedet for at prøve på at registrere det.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use kasperd@kd.lir.dk and abuse@kd.lir.dk
I'd rather be a hammer than a nail.
| |
a servant of Isa, Ye~ (23-05-2004)
| Kommentar Fra : a servant of Isa, Ye~ |
Dato : 23-05-04 19:00 |
|
Win (vind) 1000 Danish Kr. (around 140 US $), jump ...
2233 news:Gb3sc.1684$Vf.53534@news000.worldonline.dk
**************************************************
"Kasper Dupont" skrev
news:40B0C30A.528C4E96@daimi.au.dk'
> > Hvor meget taler vi ca. om i Bytes pr. pakke ?
> > (100, 1K, 10K, 100K)
>
> Maksimalt 64KB (minus 1 byte) per IP pakke. Det er summen
> af alle fragmenter. Det vil sige at uanset hvor mange
> fragmenter der sendes må den samlede pakke ikke nå op på
> 64KB eller mere.
>
> En typisk fejl at begå, når man laver en IP implementation
> er, at ikke checke dette rigtigt. Så når det sidste
> fragment starter indenfor de 64KB så kan det godt være at
> slutningen når ud til 65KB og så går computeren ned (eller
> det der er værre).
>
> Størrelsen på det enkelte fragment afhænger af netværks
> typen. På ethernet er grænsen f.eks. 1500 bytes hvoraf de
> 20 bruges til IP headeren. Så en pakke kunne f.eks. bestå
> af 44 fragmenter af 1480 bytes hver. Det er dog sjældent
> en god idé at bruge så mange fragmenter.
Nej - bestemt ikke.
Tak for dit svar.
> > > Disse fragmenterede pakker skal samles igen. Til
> > > dette formål er der tre oplysninger at kigge på
> > > afsender, modtager og IPID. ...
> >
> > Tillad mig at gøre et lille break her:
> >
> > Hvor mange forbindelser er der undervejs ?
> > (fra afsender A til modtager B)
>
> Typisk 10-30 styk. Jeg gav et eksempel i et af
> indlægene.
Har muligvis overset det (eller har ikke gennemlæst det endnu).
Kunne jeg anmode dig om fremover - i disse tilfælde - at henvise til
indlægget meget gerne med Dato-angivelse, således at enhver meget hurtigt
kan finde indlægget (også selvom man er gået Off-line) - På forhånd tak
> > Det afhænger selvfølgelig af, hvor A og B befinder sig. Fra Danmark til
Kina
> > er der flere mellemled, end ved en kort distance fra Christania til
> > Christiansborg (må vi antage).
> >
> > Taler vi om et interval fra 10 til 10.000 stk. ?
> >
> > Minimum og maximun værdierne ?
>
> Absolut maximum er 255. Der bruges nemlig kun en byte
> på TTL. (En tæller som skal forhindre at en pakke
> kører i ring i uendelig lang tid.)
>
> Men de fleste systemer sætter en mindre TTL på pakkerne,
> 64 er vist meget normalt. Så hvis der er mere end 64 hop
> så bliver pakken smidt væk inden den når sit mål.
Yderst interessante oplysninger
> > Hvis nu alle mellemled (*1) havde et *identitetsnummer*,
>
> Det har de allerede.
Fint !!!
> > og at dette nummer
> > blev hæftet på hver eneste pakke, som løber igennem mellemleddet, da
ville
> > vi - teoretisk set - kunne spore den egentlige afsender.
>
> Den mulighed er allerede til stede, det kræver blot at
> afsenderen beder om det. ...
Kunne man ikke gøre det til et globalt systemkrav ?
Nægter nogen at samarbejde, kan vi andre vælge at boykotte disse. Min
Internetudbyder kunne muligvis tilbyde denne service; idet det jo for dem
også koster en hel del at have al den spoofet trafik. Mange af deres kunder
har jo indgået en kontrakt, hvor de uanset forbrug betaler et fast beløb pr.
måned. Mindre trafik lavere omkostninger
> ... Men jeg er ikke sikker på, at
> der er ret mange som understøtter det. Desuden ville det
> give performance problemer.
Sætning ej forstået. Kunne du uddybe den ?
> Og ligesom med alle de andre forslag. Hvis du ikke kan
> få udbyderne til at lukke for spoofing, hvordan i
> alverden ville du så få dem til at lave så omfattende
> ændringer.
Vil Internet-udbyderne da ikke lukke for spoofingen ?
> Ingen af de forslag du er kommet med har været bedre end
> mine forslag om at simpelthen gøre to ting:
> 1) Forhindre sine egne kunder i spoofing
> 2) Ret i operativsystemerne, så de genererer bedre IPID.
Punkt 1 forhindrer jo ikke de andre i at gøre ligeså, vel ?
(vi skal have et verdensomspændende krav, med mulighed for boykot)
Punkt 2 kan jeg fuldt ud tilslutte mig
> I øvrigt 255 hops der skal skrive 4 bytes hver i pakken.
> Det betyder, at 1020 af de 1500 bytes skal bruges på
> registrering af ruten. ...
Og dét ville jo være regulær vanvid!
> ... Så skal der også bruges 20 bytes
> på hhv IP og TCP headers, så er der 440 bytes tilbage
> til en TCP payload. Dermed skal du (i bedste fald) bruge
> 3.4 gange så lang tid på den samme dataoverførsel.
Hvorfor denne løsning IKKE kan bruges.
> > Jamen - hvad nu hvis A's første mellemled er en del af sammensværgelsen
?
> >
> > Så kunne vi jo sige, at første *autoriserede* mellemled, DESFORUDEN
> > vedhæfter sit identitetsnummer SAMT klokkeslet.
>
> Der er ikke noget der hedder autoriseret i det her system.
Nej, det er korrekt, men det kan vi jo indføre
Min Internet-udbyder, kunne jeg da forestille mig, úmiddelbart kunne
godkendes som *autoriseret*.
> Desuden er der flere problemer med dit forslag. Det ville
> kræve ændringer i protokollen, så ville det være nemmere
> at få folk til at indføre IPv6 og/eller lukke for misbrug
> i stedet for at prøve på at registrere det.
Dette forstod jeg desværre ikke helt
.... men jeg er jo heller ej fagmand på dette område,
jeg er blot den, som sidder med problemet
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2243
| |
Kasper Dupont (23-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 23-05-04 20:10 |
|
"a servant of Isa, Yeshua" wrote:
>
> Win (vind) 1000 Danish Kr. (around 140 US $), jump ...
> 2233 news:Gb3sc.1684$Vf.53534@news000.worldonline.dk
>
> **************************************************
>
> "Kasper Dupont" skrev
> news:40B0C30A.528C4E96@daimi.au.dk'
>
> >
> > Typisk 10-30 styk. Jeg gav et eksempel i et af
> > indlægene.
>
> Har muligvis overset det (eller har ikke gennemlæst det endnu).
>
> Kunne jeg anmode dig om fremover - i disse tilfælde - at henvise til
> indlægget meget gerne med Dato-angivelse, således at enhver meget hurtigt
> kan finde indlægget (også selvom man er gået Off-line) - På forhånd tak
Jeg kan da ikke huske alle mine indlæg. Men det lykkedes
at finde det: <news:40ADA638.62C820CE@daimi.au.dk>
> >
> > Den mulighed er allerede til stede, det kræver blot at
> > afsenderen beder om det. ...
>
> Kunne man ikke gøre det til et globalt systemkrav ?
Nej.
>
> Nægter nogen at samarbejde, kan vi andre vælge at boykotte disse. Min
> Internetudbyder kunne muligvis tilbyde denne service; idet det jo for dem
> også koster en hel del at have al den spoofet trafik. Mange af deres kunder
> har jo indgået en kontrakt, hvor de uanset forbrug betaler et fast beløb pr.
> måned. Mindre trafik lavere omkostninger
Du må hellere lige regne efter igen. Pakker med spoofet
afsender udgør nok under 1% af trafikken på internettet.
Dit forslag kunne risikere at tredoble mængden af trafik.
>
> > ... Men jeg er ikke sikker på, at
> > der er ret mange som understøtter det. Desuden ville det
> > give performance problemer.
>
> Sætning ej forstået. Kunne du uddybe den ?
Jeg mener at hvis du satte en record route option på en
IP pakke, ville den sikkert blive ignoreret af mange
routere. Nogen ville måske enda gå så vidt som til at
smide hele pakken væk. Men det er ikke noget jeg gider
bruge tid på at eksperimentere med. Du burde i øvrigt
tage et kig på RFC 791, det er forklaret der, hvordan
det fungerer:
http://rfc.sunsite.dk/rfc/rfc791.html
Og nu du er i gang, så er RFC 793 også interesant. De
to dokumenter definerer hhv. IP og TCP.
http://rfc.sunsite.dk/rfc/rfc793.html
>
> > Og ligesom med alle de andre forslag. Hvis du ikke kan
> > få udbyderne til at lukke for spoofing, hvordan i
> > alverden ville du så få dem til at lave så omfattende
> > ændringer.
>
> Vil Internet-udbyderne da ikke lukke for spoofingen ?
Nogen vil ikke, andre har allerede gjort det. Pointen
er bare den, at der vil altid være nogle udbydere tilbage,
der ikke vil gøre noget.
>
> > Ingen af de forslag du er kommet med har været bedre end
> > mine forslag om at simpelthen gøre to ting:
> > 1) Forhindre sine egne kunder i spoofing
> > 2) Ret i operativsystemerne, så de genererer bedre IPID.
>
> Punkt 1 forhindrer jo ikke de andre i at gøre ligeså, vel ?
Næh. Men man skal jo starte et sted.
> (vi skal have et verdensomspændende krav, med mulighed for boykot)
Gid det virkede. Men som det ser ud i dag er der ikke ret
meget samarbejde mellem udbyderne på at gribe ind overfor
misbrug. Der findes allerede i dag tilfælde, hvor udbydere
i større eller mindre omfang boykotter hinanden. Men det
sker på et alt for lemfældigt grundlag, så en udbyder sagtens
kan finde på at boykotte uskyldige mennesker samtidig med at
de ser gennem fingrene med deres egne kunders misbrug, og
afviser emails med klager over deres egne kunder.
>
> Min Internet-udbyder, kunne jeg da forestille mig, úmiddelbart kunne
> godkendes som *autoriseret*.
Autoriseret betyder altså at du har en myndighed til at
udstede autorisationer, det er ikke blot et spørgsmål om,
hvad du forestiller dig.
Og vi kan da også godt sige, at en internetudbyder skal
autoriseres af IANA. Men alle udbydere har jo allerede i
dag fået deres adresser tildelt direkte eller indirekte fra
IANA, så de er på en måde allerede autoriseret. Det gælder
også dem, der misbruger nettet i stor stil/ser gennem
fingrene med deres kunders misbrug.
>
> > Desuden er der flere problemer med dit forslag. Det ville
> > kræve ændringer i protokollen, så ville det være nemmere
> > at få folk til at indføre IPv6 og/eller lukke for misbrug
> > i stedet for at prøve på at registrere det.
>
> Dette forstod jeg desværre ikke helt
Du har store forventinger om, at alle internetudbydere i
verden skal blive enige om at iværksætte en omfattende
overvågning for at finde personerne bag et beskedent
misbrug af nettet.
Men samme udbydere vil ikke engang gøre en begrænset
indsats for at forhindre deres egne kunder i misbrug.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use kasperd@kd.lir.dk and abuse@kd.lir.dk
I'd rather be a hammer than a nail.
| |
a servant of Isa, Ye~ (22-05-2004)
| Kommentar Fra : a servant of Isa, Ye~ |
Dato : 22-05-04 20:54 |
|
"Kasper Dupont" skrev
news:40AD972D.9C288C19@daimi.au.dk
Jeg har for nemhedens skyld klippet mit indlæg over i 2
PART 2:
> Forestil dig følgende scenarie:
> A er en legitim bruger af serveren B
> A vil scanne maskinen C
1.
> A opretter en forbindelse til B for at probe for dennes
> IPID. ...
Mit forslag lyder:
(det er ikke særlig gennemtænkt, og skal derfor rettes og korrigeres)
(god fornøjelse hermed)
B arkiverer internt ...
A's IP-adresse
IPID-nummeret
Time
2.
> ... Samtidig sendes en spoofet pakke fra A til B, som
> angiver D som afsender. B sender et svar til D. ...
Mit forslag lyder:
D kontakter B (fordi D ikke kendte noget til pakken)
B kontakter O (Global Overvågning, lokal afdeling)
O modtager B's interne arkiv
(heriblandt A's IP-adresse, IPID-nummeret, Time)
(heriblandt B's IP-adresse)
(heriblandt D's IP-adresse)
*Alle* Internet-udbydere opdateres løbende igennem O.
Men i praksis er dette úrealistisk!
O kontakter de Internet-udbydere B's arkiv indeholdt.
A's Internet-udbyder ved nu,
at pakker med D's IP-adresse *SKAL* rapporteres til O.
> ... A kan
> forudsige, hvad IPID denne pakke måtte være.
.... fordi A fik oplysningen i starten (profe for B's IPID) går jeg ud fra.
> Når jeg siger samtidig kunne det f.eks. gøres ved, at
> pakkerne sendes i en tilfældig rækkefølge, for at det
> bliver lidt sværere at gennemskue, hvad A har gang i.
3.
> Herefter sender A en række pakker til C og spoofer
> afsender adressen B.
Mit forslag lyder:
C kontakter B (fordi C ikke kendte noget til pakken)
B kontakter O
O modtager B's interne arkiv
(heriblandt A's IP-adresse, IPID-nummeret, Time)
(heriblandt B's IP-adresse)
(heriblandt C's IP-adresse)
A's Internet-udbyder ved nu,
at pakker med C's IP-adresse *SKAL* rapporteres til O.
4.
> Dernæst prober A igen for Bs IPID. Dette gøres som før
> ved at maskere det med en pakke fra D.
Mit forslag lyder:
A's Internet-udbyder's ALARM går i gang !!!
(D var jo under mistanke)
A's Internet-udbyder sammenligner A's faktiske IP-adresse med A's foregivne
IP-adresse (D's), og tyven er fundet!
A afkobles fysisk fra nettet.
-
Hvad nu hvis A's Internet-udbyder ikke vil samarbejde ?
(en sammensværgelse)
Når A's Internet-udbyder videresender pakker fra A til næste led i kæden
(undervejs til B), kan IP-adressen vil stadigvæk spores, selvom DATA'erne er
komprimerede.
A's Internet-udbyder må derfor overvåges allerede under punkt 3 af O's
lokale afdeling til A's Internet-udbyder.
> A kan nu udfra svarene udregne hvor mange åbne porte
> der var på C i det scannede interval. Og regne ud,
> hvad D ville være kommet frem til, hvis D havde lavet
> et konventionelt idlescan af C vha. zombien B.
>
> Det vil se ud som om, D er ved at lave et idlescan af
> C. Men pga. trafikken fra A bliver D nødt til at prøve
> igen og igen.
>
> Der er ingen måde B kan vide, om det var A eller D,
> der udførte et idlescan af C. Faktisk ville B nok
> komme frem til den konklusion, at B var blevet udsat
> for et portscan af D.
Nixch so gut.
> > (det er *derfor*, at der skal indsamles DATA)
> >
> > Et spørgsmål melder sig:
> >
> > Forestiller vi os ("hypotetisk" set), at min IP-adresse benyttes af
> > angriberen. Vil min firewall registrere, når angriberen kontakter
> > Zombien (mig) ?
>
> Måske.
Hvad afhængiger det af ?
> > ... og give alarm-meddelse ?
>
>
> Forhåbentlig ikke. Den slags er bare til gene for
> brugeren. Det skal logges, så man kan kigge på det
> efterfølgende.
Tak for din hjælp, Kasper
Som jeg indledningsvis skrev:
Mit forslag er ikke særlig gennemtænkt, og skal derfor rettes og korrigeres.
Til de af jer, som har lyst: god fornøjelse hermed
Med venlig hilsen
Mogens Kall
The servant of Michael
File-number:
2222
| |
Kasper Dupont (22-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 22-05-04 23:35 |
|
"a servant of Isa, Yeshua" wrote:
>
> "Kasper Dupont" skrev
> news:40AD972D.9C288C19@daimi.au.dk
>
> Jeg har for nemhedens skyld klippet mit indlæg over i 2
>
> PART 2:
>
> > Forestil dig følgende scenarie:
> > A er en legitim bruger af serveren B
> > A vil scanne maskinen C
>
> 1.
>
> > A opretter en forbindelse til B for at probe for dennes
> > IPID. ...
>
> Mit forslag lyder:
>
> (det er ikke særlig gennemtænkt, og skal derfor rettes og korrigeres)
> (god fornøjelse hermed)
>
> B arkiverer internt ...
>
> A's IP-adresse
> IPID-nummeret
> Time
A's adresse og tidspunktet bliver muligvis allerede
logget. Det afhænger selvfølgelig af hvad det er for
en slags service A tilgår, og hvordan denne er opsat.
Men en samlet logning af alle forbindelser uafhængig
af service/port foretages normalt ikke.
At logge IPID nummeret ville være spild, det er da
meget nemmere at bruge en bedre IPID generering.
Desuden kender jeg ikke nogen kerne, der giver mulighed
for at servicen kan få nogen oplysninger om de
anvendte IPID numre. Desuden ville det pludselig
betyde at du skulle have en logindgang for hver eneste
pakke, og ikke blot en for hver TCP forbindelse.
>
> 2.
>
> > ... Samtidig sendes en spoofet pakke fra A til B, som
> > angiver D som afsender. B sender et svar til D. ...
>
> Mit forslag lyder:
>
> D kontakter B (fordi D ikke kendte noget til pakken)
Jeg tror nok det ville være en overtrædelse af RFC 793.
Men jeg er ikke helt sikker. Hvad enten det er en
overtrædelse af RFC 793 eller ej, så er det en meget
dårlig idé. Vi snakker om at reagere på en uventet RST
pakke, som RFC 793 af meget gode grunde siger man skal
ingorere. En uventet RST pakke kan have mange årsager.
F.eks. at en af maskinerne er blevet genstartet mens
en tidligere forbindelse har været åben. Desuden kan
D jo slet ikke vide om afsenderen på RST pakken er
spoofet. Hvis man begynder at reagere på uventede RST
pakker er der mulighed for at udnytte det til DoS
angreb.
>
> B kontakter O (Global Overvågning, lokal afdeling)
Overvågning er ikke løsningen på problemet. Folk
ønsker ikke overvågning, og slet ikke overvågning uden
god grund. I stedet for at overvåge er det meget
nemmere at lukke de små sikkerhedshuller rundt omkring.
Fjern muligheden for at spoofe source IP og generer
bedre IPID.
>
> O modtager B's interne arkiv
> (heriblandt A's IP-adresse, IPID-nummeret, Time)
> (heriblandt B's IP-adresse)
> (heriblandt D's IP-adresse)
>
> *Alle* Internet-udbydere opdateres løbende igennem O.
>
> Men i praksis er dette úrealistisk!
Fuldstændigt. Ikke nok med at folk ikke vil have det,
og ingen udbydere ville ofre resourcer på det, så
ville systemet selv hvis det blev etablet bryde sammen
på ingen tid. Der ville simpelthen komme så meget
trafik til dem, at de ikke kunne håndtere det hele.
(Og det er bare inden folk der ikke bryder sig om
systemet sætter et DoS angreb ind).
>
> O kontakter de Internet-udbydere B's arkiv indeholdt.
>
> A's Internet-udbyder ved nu,
> at pakker med D's IP-adresse *SKAL* rapporteres til O.
>
> > ... A kan
> > forudsige, hvad IPID denne pakke måtte være.
>
> ... fordi A fik oplysningen i starten (profe for B's IPID) går jeg ud fra.
Ja. A prober Bs IPID før eller efter den spoofede
pakke. Så må IPID være hhv. en mindre eller større
end svaret på den ægte probe.
>
> > Når jeg siger samtidig kunne det f.eks. gøres ved, at
> > pakkerne sendes i en tilfældig rækkefølge, for at det
> > bliver lidt sværere at gennemskue, hvad A har gang i.
>
> 3.
>
> > Herefter sender A en række pakker til C og spoofer
> > afsender adressen B.
>
> Mit forslag lyder:
>
> C kontakter B (fordi C ikke kendte noget til pakken)
>
> B kontakter O
>
> O modtager B's interne arkiv
> (heriblandt A's IP-adresse, IPID-nummeret, Time)
> (heriblandt B's IP-adresse)
> (heriblandt C's IP-adresse)
>
> A's Internet-udbyder ved nu,
> at pakker med C's IP-adresse *SKAL* rapporteres til O.
Skal vi begynde at regne på, hvor meget trafik
én spoofet pakke kan medføre, og hvilke DoS
angreb det kan bruges til?
>
> 4.
>
> > Dernæst prober A igen for Bs IPID. Dette gøres som før
> > ved at maskere det med en pakke fra D.
>
> Mit forslag lyder:
>
> A's Internet-udbyder's ALARM går i gang !!!
A har valgt en internet udbyder, der fuldstændigt
ignorerer misbrug. Hvis As internet udbyder tog det
seriøst ville de jo ikke have tilladt A at sende de
spoofede pakker i første omgang.
Så enten får du alle internet udbydere i hele
verden til at gribe ind overfor misbrug, eller også
går du ud fra, at As udbyder ikke er til nogen hjælp.
At få alle udbydere til at gøre noget ved misbrug er
komplet urealistisk. Nogen udbydere har ikke engang
en fungerende abuse adresse.
>
> (D var jo under mistanke)
>
> A's Internet-udbyder sammenligner A's faktiske IP-adresse med A's foregivne
> IP-adresse (D's), og tyven er fundet!
Her er ingen tyv.
>
> A afkobles fysisk fra nettet.
Nej. As udbyder gør intet. De svarer ikke engang på
din henvendelse (hvis det da overhovedet kan lade
sig gøre at kontakte dem).
>
> -
>
> Hvad nu hvis A's Internet-udbyder ikke vil samarbejde ?
Det kan du roligt gå ud fra, at de ikke vil.
> (en sammensværgelse)
Never attribute to malice that which can be adequately
explained by stupidity.
http://www.jargon.net/jargonfile/h/HanlonsRazor.html
>
> Når A's Internet-udbyder videresender pakker fra A til næste led i kæden
> (undervejs til B), kan IP-adressen vil stadigvæk spores, selvom DATA'erne er
> komprimerede.
Næste udbyder på vejen kan selvfølgelig se, at pakken
kommer fra As udbyder. Men viden om hvilken af denne
udbyders kunder, der har sendt pakken er allerede gået
tabt. Og det er ikke sikkert den næste udbyder ved, om
en legitim pakke fra D til B faktisk kan tage denne
rute. Så muligvis kan den næste udbyder intet gøre.
> > >
> > > Forestiller vi os ("hypotetisk" set), at min IP-adresse benyttes af
> > > angriberen. Vil min firewall registrere, når angriberen kontakter
> > > Zombien (mig) ?
> >
> > Måske.
>
> Hvad afhængiger det af ?
Det afhænger af din firewall og din firewall
opsætning. Det afhænger også af, hvilken trafik,
der udnyttes til at foretage probes. Foretages
probes med legitim trafik vil din firewall nok
pænt lukke det igennem og ikke tage sig af det.
>
> Mit forslag er ikke særlig gennemtænkt, og skal derfor rettes og korrigeres.
Eller forkastes. Det ville være nemmere at bruge
bedre IPID numre og lukke for spoofing så tidligt
som muligt. (Lidt mere præcist formuleret, så er det
kun muligt at forhindre spoofing hvis det gøres tidligt
på ruten).
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use kasperd@kd.lir.dk and abuse@kd.lir.dk
I'd rather be a hammer than a nail.
| |
Kasper Dupont (20-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 20-05-04 09:13 |
|
Michael Knudsen wrote:
>
> Design-fejl er jeg skeptiske overfor at finde, men jeg har ikke kigget
> naermere paa det.
Den her designfejl har de vist ikke gjort noget ved endnu.
http://security.tombom.co.uk/shatter.html
http://security.tombom.co.uk/moreshatter.html
Det nyeste jeg kunne finde var en note fra 8 februar 2003
om at Microsoft har frigivet en patch, som ikke helt løser
problemet. Nogen der har noget nyere?
> RTL8139 er et glimrende bevis paa designfejl, i oevrigt
Ja, dem der skriver driver til det er i hvert fald ikke
overvældende begejstret. Men jeg har da ikke hørt om
nogen designfejl i RTL8139 skulle have nogen betydning
for sikkerheden.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Michael Knudsen (20-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 20-05-04 11:01 |
|
Kasper Dupont wrote:
> Michael Knudsen wrote:
>
>>Design-fejl er jeg skeptiske overfor at finde, men jeg har ikke kigget
>>naermere paa det.
>
>
> Den her designfejl har de vist ikke gjort noget ved endnu.
>
> http://security.tombom.co.uk/shatter.html
> http://security.tombom.co.uk/moreshatter.html
Jeg foelger nok bare ikke ordentligt med.
>>RTL8139 er et glimrende bevis paa designfejl, i oevrigt
>
>
> Ja, dem der skriver driver til det er i hvert fald ikke
> overvældende begejstret. Men jeg har da ikke hørt om
> nogen designfejl i RTL8139 skulle have nogen betydning
> for sikkerheden.
Delvist. Som en sideeffekt til, at kortet ikke kan checke, om de sendte
frames har den korrekte laengde, kan man bruge kortet til 802.1Q --
mange chips smider frames laengere end 1514 bytes vaek.
Mvh. Michael.
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)
| |
Kent Friis (20-05-2004)
| Kommentar Fra : Kent Friis |
Dato : 20-05-04 11:10 |
|
Den Thu, 20 May 2004 12:01:28 +0200 skrev Michael Knudsen:
> Kasper Dupont wrote:
>> Michael Knudsen wrote:
>>
>>>Design-fejl er jeg skeptiske overfor at finde, men jeg har ikke kigget
>>>naermere paa det.
>>
>>
>> Den her designfejl har de vist ikke gjort noget ved endnu.
>>
>> http://security.tombom.co.uk/shatter.html
>> http://security.tombom.co.uk/moreshatter.html
>
> Jeg foelger nok bare ikke ordentligt med.
>
>>>RTL8139 er et glimrende bevis paa designfejl, i oevrigt
>>
>>
>> Ja, dem der skriver driver til det er i hvert fald ikke
>> overvældende begejstret. Men jeg har da ikke hørt om
>> nogen designfejl i RTL8139 skulle have nogen betydning
>> for sikkerheden.
>
> Delvist. Som en sideeffekt til, at kortet ikke kan checke, om de sendte
> frames har den korrekte laengde, kan man bruge kortet til 802.1Q --
> mange chips smider frames laengere end 1514 bytes vaek.
Det er da kun en fordel at man ikke behøver at købe hundedyre
cisco-ting for at kunne bruge 802.1Q.
Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/
| |
Kasper Dupont (20-05-2004)
| Kommentar Fra : Kasper Dupont |
Dato : 20-05-04 12:20 |
|
Michael Knudsen wrote:
>
> Delvist. Som en sideeffekt til, at kortet ikke kan checke, om de sendte
> frames har den korrekte laengde, kan man bruge kortet til 802.1Q --
> mange chips smider frames laengere end 1514 bytes vaek.
Kan man forårsage et bufferoverløb ved at sende en for
lang frame til kortet?
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Andreas Plesner Jaco~ (20-05-2004)
| Kommentar Fra : Andreas Plesner Jaco~ |
Dato : 20-05-04 12:23 |
|
On 2004-05-20, Kasper Dupont <kasperd@daimi.au.dk> wrote:
>>
>> Delvist. Som en sideeffekt til, at kortet ikke kan checke, om de sendte
>> frames har den korrekte laengde, kan man bruge kortet til 802.1Q --
>> mange chips smider frames laengere end 1514 bytes vaek.
>
> Kan man forårsage et bufferoverløb ved at sende en for
> lang frame til kortet?
Næppe, de fleste generiske dele af ethernet-drivere burde kunne håndtere
jumbo-frames i dag.
Jeg tror der menes at man med 802.1q frames har mulighed for at få sig
en side-channel man kan gemme data i, hvis man har en kompromitteret
host.
--
Andreas Plesner Jacobsen | A chicken is an egg's way of producing more eggs.
| |
Michael Knudsen (21-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 21-05-04 16:52 |
|
| |
Michael Knudsen (21-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 21-05-04 17:27 |
|
| |
Michael Knudsen (21-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 21-05-04 17:31 |
|
| |
Michael Knudsen (21-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 21-05-04 17:46 |
|
| |
Michael Knudsen (21-05-2004)
| Kommentar Fra : Michael Knudsen |
Dato : 21-05-04 18:08 |
|
| |
|
|