|
|
 | Shields Up /Online Test
Fra : Nielsen I |
Dato : 26-09-03 23:27 |
|
En venlig bruger henviste mig til denne site http://grc.com/zonealarm.htm
med henblik på at jeg kunne teste min pc her, hvilket jeg har gjort og under
File Share, fik jeg denne for mig betænkelige besked:
1. Attempting connection to your computer. . .
Shields UP! is now attempting to contact the Hidden Internet Server within
your PC. It is likely that no one has told you that your own personal
computer may now be functioning as an Internet Server with neither your
knowledge nor your permission. And that it may be serving up all or many of
your personal files for reading, writing, modification and even deletion by
anyone, anywhere, on the Internet!
Som jeg læser det er min pc åben for fildeling, hvilket jeg ikke forstår,
idet jeg under netværk i kontrolpanelet har fjernet fildelingsmuligheden.
Endvidere har jeg tjekket min ZoneAlarm, som skriver, at der har været 319
high-rated forsøg, men samtidigt står der også under INBOUND at der kun er
blokeret 54 intrusions? Betyder det, at de resterende at de High-rates, der
har været er gået 'igennem' for en hacker eller lign.? (undskyld, hvis det
er et dumt spørgsmål).
Jeg synes ellers jeg gør hvad jeg kan for sikkerheden med Antivirus og
Trojan scanner, men jeg kan ikke på denne testside finde noget om, hvad jeg
skal gøre, for at lukke denne tilsyneladende åbne fildeling, ligesom jeg
ikke forstår, at der står, at der kun er blokeret for 54 intrusions. Er det
mig der blander tingene sammen eller hvad?
Da jeg kørte (på samme testside) en scanning på mine porte, bestod maskinen
testen fuldstændigt, men det er jo ligemeget, hvis den alligevel er vidtåben
for alle og enhver i forbindelse med fildeling og hvis der er gået
eventuelle hacking forsøg igennem blandt de eks. 319 high-rated forsøg.
Hvordan skal jeg forstå denne test? Jeg har læst frem og tilbage på
ZoneAlarms website, men synes ikke jeg kan finde noget lige om det.
På forhånd tusind tak for enhver hjælp
mvh
Nielsen
| |
 Christian E. Lysel (26-09-2003)
| Kommentar
Fra : Christian E. Lysel |
Dato : 26-09-03 23:43 |
|
In article <B33db.1878$9Z1.30@news.get2net.dk>, Nielsen I wrote:
> 1. Attempting connection to your computer. . .
[cut]
> Som jeg læser det er min pc åben for fildeling, hvilket jeg ikke forstår,
> idet jeg under netværk i kontrolpanelet har fjernet fildelingsmuligheden.
Niks, de vil forsøge at se om du svarer på port 139.
> Endvidere har jeg tjekket min ZoneAlarm, som skriver, at der har været 319
> high-rated forsøg, men samtidigt står der også under INBOUND at der kun er
> blokeret 54 intrusions? Betyder det, at de resterende at de High-rates, der
> har været er gået 'igennem' for en hacker eller lign.? (undskyld, hvis det
> er et dumt spørgsmål).
Niks, blot at high-ratet og intrusions ikke er det samme.
> Jeg synes ellers jeg gør hvad jeg kan for sikkerheden med Antivirus og
> Trojan scanner, men jeg kan ikke på denne testside finde noget om, hvad jeg
Minimalisere evt. uddata fra "netstat -na".
> skal gøre, for at lukke denne tilsyneladende åbne fildeling, ligesom jeg
> ikke forstår, at der står, at der kun er blokeret for 54 intrusions. Er det
> mig der blander tingene sammen eller hvad?
Ja.
| |
Nielsen I (27-09-2003)
| Kommentar
Fra : Nielsen I |
Dato : 27-09-03 00:02 |
|
"Christian E. Lysel" skrev:
> > 1. Attempting connection to your computer. . .
> [cut]
> > Som jeg læser det er min pc åben for fildeling, hvilket jeg ikke
forstår,
> > idet jeg under netværk i kontrolpanelet har fjernet
fildelingsmuligheden.
>
> Niks, de vil forsøge at se om du svarer på port 139.
>
Hej Christian
Tusind tak for hjælpen.... det jeg tilsyneladende havde overset var, at
resultat nr. 1 ikke var et resultat men, som der står: ...et forsøg på at
kontakte computeren, og som du skriver port 139.
også tak for de øvrige svar. Glad for at der er nogle der gør sig den
ulejlighed at svare os dummies 
God weekend
mvh
Nielsen
| |
Anders Lund (27-09-2003)
| Kommentar
Fra : Anders Lund |
Dato : 27-09-03 00:01 |
|
Nielsen I wrote:
> 1. Attempting connection to your computer. . .
> Shields UP! is now attempting to contact the Hidden Internet Server
> within your PC. It is likely that no one has told you that your own
> personal computer may now be functioning as an Internet Server with
> neither your knowledge nor your permission. And that it may be
> serving up all or many of your personal files for reading, writing,
> modification and even deletion by anyone, anywhere, on the Internet!
>
> Som jeg læser det er min pc åben for fildeling, hvilket jeg ikke
> forstår, idet jeg under netværk i kontrolpanelet har fjernet
> fildelingsmuligheden.
Læs det igen! Læg mærke til ordet "may". Dette er bare en gennerl forklaring
som alle brugere af siden får.
> Endvidere har jeg tjekket min ZoneAlarm, som skriver, at der har
> været 319 high-rated forsøg, men samtidigt står der også under
> INBOUND at der kun er blokeret 54 intrusions? Betyder det, at de
> resterende at de High-rates, der har været er gået 'igennem' for en
> hacker eller lign.? (undskyld, hvis det er et dumt spørgsmål).
Det er lang tid siden at jeg har brugt ZA, så jeg kan ikke kommentere noget
med sikkerhed her. Men jeg kunne forstillige mig at ZA har forskellige
grænser for hvad den tror er indbrud på din computer. "Intrusions" lyder som
noget af det højeste, hvor high-rated er lige under. Men du skal ikke være
bange for at nogen af de forsøg den har logget er kommet igennem - du skal
være bange for de forsøg som lykkes, for dem får du sikkert ikke noget
afvide om.
> Jeg synes ellers jeg gør hvad jeg kan for sikkerheden med Antivirus og
> Trojan scanner, men jeg kan ikke på denne testside finde noget om,
> hvad jeg skal gøre, for at lukke denne tilsyneladende åbne fildeling,
> ligesom jeg ikke forstår, at der står, at der kun er blokeret for 54
> intrusions. Er det mig der blander tingene sammen eller hvad?
Det kræver noget af brugeren, at kunne bedømme hvad de forskellige beskeder
betyder. I dette tilfælde vil jeg sige at du ikke er i stand til dette. Prøv
at læse manualen til ZA, hvor de helt sikkert beskriver hvad de mener
"intrusions" dækker over.
Ellers er der lidt læsning om personlige firewalls her:
http://a.area51.dk/sikkerhed/hjemme_net
Jeg ved bare ikke om siden måske kommer til at forvirre dig lidt...
> Da jeg kørte (på samme testside) en scanning på mine porte, bestod
> maskinen testen fuldstændigt, men det er jo ligemeget, hvis den
> alligevel er vidtåben for alle og enhver i forbindelse med fildeling
> og hvis der er gået eventuelle hacking forsøg igennem blandt de eks.
> 319 high-rated forsøg. Hvordan skal jeg forstå denne test?
Du har blandet vejledningen sammen med testresultatet. Men du skal ikke tro
at du er "sikker" bare fordi denne test har givet dig grøn lys, hvilket jeg
også mener der står på siden.
> Jeg har
> læst frem og tilbage på ZoneAlarms website, men synes ikke jeg kan
> finde noget lige om det.
Jeg kan heller ikke helt finde frem til noget egentlig support på deres
side, ud over noget chat-support eller noget som kræver brugernavn/login.
Måske er det bare mig, men jeg kunne ikke lige finde noget brugbart support.
--
Anders Lund
spam2003@andersonline.dk
http://www.andersonline.dk
| |
Holger Danske (27-09-2003)
| Kommentar
Fra : Holger Danske |
Dato : 27-09-03 09:45 |
|
Nielsen I wrote:
> En venlig bruger henviste mig til denne site
> http://grc.com/zonealarm.htm med henblik på at jeg kunne teste min pc
> her, hvilket jeg har gjort og under File Share, fik jeg denne for mig
> betænkelige besked:
>
>
> 1. Attempting connection to your computer. . .
> Shields UP! is now attempting to contact the Hidden Internet Server
> within your PC. It is likely that no one has told you that your own
> personal computer may now be functioning as an Internet Server with
> neither your knowledge nor your permission. And that it may be
> serving up all or many of your personal files for reading, writing,
> modification and even deletion by anyone, anywhere, on the Internet!
>
> Som jeg læser det er min pc åben for fildeling, hvilket jeg ikke
> forstår, idet jeg under netværk i kontrolpanelet har fjernet
> fildelingsmuligheden.
>
> Endvidere har jeg tjekket min ZoneAlarm, som skriver, at der har
> været 319 high-rated forsøg, men samtidigt står der også under
> INBOUND at der kun er blokeret 54 intrusions? Betyder det, at de
> resterende at de High-rates, der har været er gået 'igennem' for en
> hacker eller lign.? (undskyld, hvis det er et dumt spørgsmål).
>
> Jeg synes ellers jeg gør hvad jeg kan for sikkerheden med Antivirus og
> Trojan scanner, men jeg kan ikke på denne testside finde noget om,
> hvad jeg skal gøre, for at lukke denne tilsyneladende åbne fildeling,
> ligesom jeg ikke forstår, at der står, at der kun er blokeret for 54
> intrusions. Er det mig der blander tingene sammen eller hvad?
>
> Da jeg kørte (på samme testside) en scanning på mine porte, bestod
> maskinen testen fuldstændigt, men det er jo ligemeget, hvis den
> alligevel er vidtåben for alle og enhver i forbindelse med fildeling
> og hvis der er gået eventuelle hacking forsøg igennem blandt de eks.
> 319 high-rated forsøg. Hvordan skal jeg forstå denne test? Jeg har
> læst frem og tilbage på ZoneAlarms website, men synes ikke jeg kan
> finde noget lige om det.
>
> På forhånd tusind tak for enhver hjælp
>
Jeg har afprøvet rigtig mange firewalls, og der er 1, der udmærker sig i
forhold til de andre, nemlig Sygate firewall Pro, her er f.eks. resultatet
fra ZA port scanning
"1056 Ports Tested
ALL PORTS tested were found to be: STEALTH.
TruStealth: PASSED - ALL tested ports were STEALTH,
- NO unsolicited packets were received,
- NO Ping reply (ICMP Echo) was received.
det er jo rigtig fint
Du kan hente den som trial på www.sygate.com, den er; IMHO, rigtig god.
Allan ( Som intet proffesionelt har med Sygate at gøre )
--
-- Som aldrig har hørt om dårlige tabere i Russisk roulette --
-- Kun døde fisk flyder med strømmen --
-- Skønhed afhænger af øjnene der ser --
-- Cum insantientibus fuere necesse est --
| |
Kent Friis (27-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-03 09:58 |
|
Den Sat, 27 Sep 2003 10:44:35 +0200 skrev Holger Danske:
>
>Jeg har afprøvet rigtig mange firewalls, og der er 1, der udmærker sig i
>forhold til de andre, nemlig Sygate firewall Pro, her er f.eks. resultatet
>fra ZA port scanning
>"1056 Ports Tested
>
>ALL PORTS tested were found to be: STEALTH.
>
>TruStealth: PASSED - ALL tested ports were STEALTH,
> - NO unsolicited packets were received,
> - NO Ping reply (ICMP Echo) was received.
>
>det er jo rigtig fint
Fint? Stealth er en type bombefly der er baseret på at man ikke opdager
angrebet før det er for sent. Nu er det så godt nok computere vi snakker
om, så det er nok ikke så meget bombefly man skal være nervøs for, men
stadig: Et angreb man ikke opdager før det er for sent, det er da ikke
en positiv ting.
Inden du går helt i panik, vil jeg dog anbefale at finde en portscanner
der er lidt mere troværdig. En der bruger de korrekte ord, så man ikke
er i tvivl om hvorvidt den mener at angreb mod dig (hjælp!) ikke bliver
opdaget før det er for sent, eller den mener de angreb du laver (fy!).
Mvh
Kent
--
The frozen north will hatch a flightless bird,
who will spread his wings and dominate the earth
And cause an empire by the sea to fall
To the astonishment, and delight of all.
| |
 Holger Danske (27-09-2003)
| Kommentar
Fra : Holger Danske |
Dato : 27-09-03 10:17 |
|
Kent Friis wrote:
> Den Sat, 27 Sep 2003 10:44:35 +0200 skrev Holger Danske:
>>
>> Jeg har afprøvet rigtig mange firewalls, og der er 1, der udmærker
>> sig i forhold til de andre, nemlig Sygate firewall Pro, her er
>> f.eks. resultatet fra ZA port scanning
>> "1056 Ports Tested
>>
>> ALL PORTS tested were found to be: STEALTH.
>>
>> TruStealth: PASSED - ALL tested ports were STEALTH,
>> - NO unsolicited packets were received,
>> - NO Ping reply (ICMP Echo) was received.
>>
>> det er jo rigtig fint
>
> Fint? Stealth er en type bombefly der er baseret på at man ikke
> opdager angrebet før det er for sent. Nu er det så godt nok computere
> vi snakker om, så det er nok ikke så meget bombefly man skal være
> nervøs for, men stadig: Et angreb man ikke opdager før det er for
> sent, det er da ikke
> en positiv ting.
>
> Inden du går helt i panik, vil jeg dog anbefale at finde en
> portscanner der er lidt mere troværdig. En der bruger de korrekte
> ord, så man ikke
> er i tvivl om hvorvidt den mener at angreb mod dig (hjælp!) ikke
> bliver opdaget før det er for sent, eller den mener de angreb du
> laver (fy!).
Nu valgte jeg ZA, fordi at det var der, den oprindelige spørger havde set at
der muligvis var problemer, men jeg vil da gerne sætte indholdet af software
på min PC på spil
Bank løs på 80.62.226.157 
Allan
--
-- Som aldrig har hørt om dårlige tabere i Russisk roulette --
-- Kun døde fisk flyder med strømmen --
-- Skønhed afhænger af øjnene der ser --
-- Cum insantientibus fuere necesse est --
| |
Jane (27-09-2003)
| Kommentar
Fra : Jane |
Dato : 27-09-03 11:14 |
|
Kent Friis skrev i <news:bl3jeu$l7g$1@sunsite.dk>:
> så man ikke er i tvivl om hvorvidt den mener at angreb mod dig
> (hjælp!) ikke bliver opdaget før det er for sent, eller den mener de
> angreb du laver (fy!).
Stealth betyder at din maskine er usynlig for den der prøver at
scanne den, du undgår hackerens "radar". Det er faktisk meget
praktisk hackeren ikke opdager der er en maskine på den ip adresse
"før det er for sent"?
Jane
| |
Holger Danske (27-09-2003)
| Kommentar
Fra : Holger Danske |
Dato : 27-09-03 11:15 |
|
Jane wrote:
> Kent Friis skrev i <news:bl3jeu$l7g$1@sunsite.dk>:
>
>> så man ikke er i tvivl om hvorvidt den mener at angreb mod dig
>> (hjælp!) ikke bliver opdaget før det er for sent, eller den mener de
>> angreb du laver (fy!).
>
> Stealth betyder at din maskine er usynlig for den der prøver at
> scanne den, du undgår hackerens "radar". Det er faktisk meget
> praktisk hackeren ikke opdager der er en maskine på den ip adresse
> "før det er for sent"?
Præcis Jane, og ikke nok med det, de er også samtidigt blokerede, skide
smart, altså
Allan
--
-- Som aldrig har hørt om dårlige tabere i Russisk roulette --
-- Kun døde fisk flyder med strømmen --
-- Skønhed afhænger af øjnene der ser --
-- Cum insantientibus fuere necesse est --
| |
Jane (27-09-2003)
| Kommentar
Fra : Jane |
Dato : 27-09-03 11:43 |
|
Holger Danske skrev i <news:bl3nvn$gq8$1@sunsite.dk>:
> Præcis Jane, og ikke nok med det, de er også samtidigt blokerede, skide
> smart, altså
Kan det være forskel på porte? Jeg fik nemlig to forskellige
meldinger - om at min port 1052 var åben og om at alle porte
var lukkede - nu er jeg jo nervøs for min port 1052 men hvad
gør jeg egentlig for at lukke den? Forstår ikke helt alt det
engelske på siden, en for-dummies forklaring vil være meget
kærkommen.
jane
| |
Holger Danske (27-09-2003)
| Kommentar
Fra : Holger Danske |
Dato : 27-09-03 11:46 |
|
Jane wrote:
> Holger Danske skrev i <news:bl3nvn$gq8$1@sunsite.dk>:
>
>
>> Præcis Jane, og ikke nok med det, de er også samtidigt blokerede,
>> skide smart, altså
>
> Kan det være forskel på porte? Jeg fik nemlig to forskellige
> meldinger - om at min port 1052 var åben og om at alle porte
> var lukkede - nu er jeg jo nervøs for min port 1052 men hvad
> gør jeg egentlig for at lukke den? Forstår ikke helt alt det
> engelske på siden, en for-dummies forklaring vil være meget
> kærkommen.
Bruger du selv Sygate PRO ?
Allan
--
-- Som aldrig har hørt om dårlige tabere i Russisk roulette --
-- Kun døde fisk flyder med strømmen --
-- Skønhed afhænger af øjnene der ser --
-- Cum insantientibus fuere necesse est --
| |
Jane (27-09-2003)
| Kommentar
Fra : Jane |
Dato : 27-09-03 12:51 |
|
Holger Danske skrev i <news:bl3ppc$rgs$1@sunsite.dk>:
> Bruger du selv Sygate PRO ?
Tror det ikke.
Jane
| |
Kent Friis (27-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-03 11:52 |
|
Den 27 Sep 2003 10:42:48 GMT skrev Jane:
>Holger Danske skrev i <news:bl3nvn$gq8$1@sunsite.dk>:
>
>
>> Præcis Jane, og ikke nok med det, de er også samtidigt blokerede, skide
>> smart, altså
>
>Kan det være forskel på porte? Jeg fik nemlig to forskellige
>meldinger - om at min port 1052 var åben og om at alle porte
>var lukkede - nu er jeg jo nervøs for min port 1052 men hvad
>gør jeg egentlig for at lukke den? Forstår ikke helt alt det
>engelske på siden, en for-dummies forklaring vil være meget
>kærkommen.
Portnumre højere end 1023 er de såkaldte "high-ports", der ikke har
nogen fast betydning, men blot tildeles til programmer der har brug
for at kommunikere. Det kunne fx være ICQ eller lignende.
Mvh
Kent
--
"Intelligence is the ability to avoid doing work, yet get the work done"
- Linus Torvalds
| |
Bertel Lund Hansen (27-09-2003)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 27-09-03 11:53 |
|
Jane skrev:
>Kan det være forskel på porte?
Der kan ikke være andet.
>Jeg fik nemlig to forskellige meldinger - om at min port 1052 var åben
Der er nogle reserverede porte. De er nummereret fra 0 til 1023.
Dem skal man normalt holde snitterne fra hvis man selv skriver
programmer.
Port 80 er browserporten, port 25 er mailporten osv.
Porte over 1023 kan hvem som helst bruge til hvad som helst, så
det er spild af tid at lave en liste med hvilket program der
bruger port 1052. Det er sikkert tilfældigt.
>nu er jeg jo nervøs for min port 1052 men hvad gør jeg egentlig for at lukke den?
Finder det program der har åbnet den og slagter det.
Åbn en kommandoboks og skriv "netstat -a". Så får du en oversigt
over netaktiviteten på dit system.
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
| |
Anders Lund (27-09-2003)
| Kommentar
Fra : Anders Lund |
Dato : 27-09-03 11:53 |
|
Jane wrote:
> Kan det være forskel på porte? Jeg fik nemlig to forskellige
> meldinger - om at min port 1052 var åben og om at alle porte
> var lukkede - nu er jeg jo nervøs for min port 1052 men hvad
> gør jeg egentlig for at lukke den? Forstår ikke helt alt det
> engelske på siden, en for-dummies forklaring vil være meget
> kærkommen.
Hver gang din computer skal lave en forbindelse ud på Internettet (eller et
hvilket som helst andet netværk), skal der åbnes en port, hvor du kan
modtage et svar på. Dette er en "dynamisk" port, som oftest ligger over port
1024. Derfor vil det være lidt forskelligt hvilken port der er åben til de
forskellige forbindelser. Det kan dog også være at du har et eller andet
program installeret som lytter...
Chancen er dog til stede, at den pågældende port er blevet lukket igen, men
at der måske er en (eller flere) ny port som er åben.
--
Anders Lund
spam2003@andersonline.dk
http://www.andersonline.dk
| |
Anders Lund (27-09-2003)
| Kommentar
Fra : Anders Lund |
Dato : 27-09-03 11:57 |
|
Anders Lund wrote:
> som oftest ligger over port 1024.
Port 1023.
--
Anders Lund
spam2003@andersonline.dk
http://www.andersonline.dk
| |
Kent Friis (27-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-03 11:29 |
|
Den 27 Sep 2003 10:13:57 GMT skrev Jane:
>Kent Friis skrev i <news:bl3jeu$l7g$1@sunsite.dk>:
>
>> så man ikke er i tvivl om hvorvidt den mener at angreb mod dig
>> (hjælp!) ikke bliver opdaget før det er for sent, eller den mener de
>> angreb du laver (fy!).
>
>Stealth betyder at din maskine er usynlig for den der prøver at
>scanne den,
Nej det gør ikke, det er et marketing ord, beregnet til at narre folk
der intet aner om sikkerhed.
>du undgår hackerens "radar".
Nej, det viser bare at "her er der en der forsøger at skjule noget,
det ser interessant ud".
Mvh
Kent
--
If you think about it, Windows XP is actually the OS that
started as "Microsoft OS/2 NT 3.0"
| |
Holger Danske (27-09-2003)
| Kommentar
Fra : Holger Danske |
Dato : 27-09-03 11:32 |
|
Kent Friis wrote:
> Den 27 Sep 2003 10:13:57 GMT skrev Jane:
>> Kent Friis skrev i <news:bl3jeu$l7g$1@sunsite.dk>:
>>
>>> så man ikke er i tvivl om hvorvidt den mener at angreb mod dig
>>> (hjælp!) ikke bliver opdaget før det er for sent, eller den mener de
>>> angreb du laver (fy!).
>>
>> Stealth betyder at din maskine er usynlig for den der prøver at
>> scanne den,
>
> Nej det gør ikke, det er et marketing ord, beregnet til at narre folk
> der intet aner om sikkerhed.
Nej, det viser at der ikke er nogen port der, på den anmodede IP.
>> du undgår hackerens "radar".
>
> Nej, det viser bare at "her er der en der forsøger at skjule noget,
> det ser interessant ud".
Hvis du synes, men det aktuelle er at den stadig, også er blokeret.
"forsøger at skjule noget", hvad mener du med det, at den der gør mest
muligt ud af sin firewall, gør det af suspekte årsager ?
Allan
--
-- Som aldrig har hørt om dårlige tabere i Russisk roulette --
-- Kun døde fisk flyder med strømmen --
-- Skønhed afhænger af øjnene der ser --
-- Cum insantientibus fuere necesse est --
| |
Kent Friis (27-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-03 11:48 |
|
Den Sat, 27 Sep 2003 12:31:54 +0200 skrev Holger Danske:
>Kent Friis wrote:
>> Den 27 Sep 2003 10:13:57 GMT skrev Jane:
>>> Kent Friis skrev i <news:bl3jeu$l7g$1@sunsite.dk>:
>>>
>>>> så man ikke er i tvivl om hvorvidt den mener at angreb mod dig
>>>> (hjælp!) ikke bliver opdaget før det er for sent, eller den mener de
>>>> angreb du laver (fy!).
>>>
>>> Stealth betyder at din maskine er usynlig for den der prøver at
>>> scanne den,
>>
>> Nej det gør ikke, det er et marketing ord, beregnet til at narre folk
>> der intet aner om sikkerhed.
>
>
>Nej, det viser at der ikke er nogen port der, på den anmodede IP.
I TCP/IP findes der ikke noget der hedder stealth. Det er et marketing-
ord.
>>> du undgår hackerens "radar".
>>
>> Nej, det viser bare at "her er der en der forsøger at skjule noget,
>> det ser interessant ud".
>
>Hvis du synes, men det aktuelle er at den stadig, også er blokeret.
Blokeret hedder for TCP: TCP reset / Connection refused, og for
UDP hedder det ICMP port unreachable.
For TCP's vedkommende kommer man ikke langt uden et svar, men hvis vi
snakker UDP, betyder "intet svar" faktisk at pakken er modtaget i den
anden ende.
En trojan kunne nemt laves sådan at den bruger UDP, og først svarer
tilbage når den har modtaget angriberens password. Da din portscanner
ikke kender passwordet, vil den ikke svare, og din portscanner ser
blot at der ikke kommer noget svar. I dette tilfælde er betegnelsen
stealth faktisk ikke dårlig, da der netop er noget skjult på den
port, noget som portscanneren ikke kan se, men som angriberen kan
bruge til at overtage computeren.
>"forsøger at skjule noget", hvad mener du med det, at den der gør mest
>muligt ud af sin firewall, gør det af suspekte årsager ?
Nej, jeg mener ikke "forsøge at skjule noget for politiet", men derimod
"forsøge at skjule noget for røveren". Der er ikke noget suspekt i det,
men det kan stadig påkalde "røverens" interesse.
Mvh
Kent
--
F0 0F C7 C8 - Intel Pentium bug
| |
Holger Danske (27-09-2003)
| Kommentar
Fra : Holger Danske |
Dato : 27-09-03 12:13 |
|
Kent Friis wrote:
> Den Sat, 27 Sep 2003 12:31:54 +0200 skrev Holger Danske:
>> Kent Friis wrote:
>>> Den 27 Sep 2003 10:13:57 GMT skrev Jane:
>>>> Kent Friis skrev i <news:bl3jeu$l7g$1@sunsite.dk>:
>>>>
>>>>> så man ikke er i tvivl om hvorvidt den mener at angreb mod dig
>>>>> (hjælp!) ikke bliver opdaget før det er for sent, eller den mener
>>>>> de angreb du laver (fy!).
>>>>
>>>> Stealth betyder at din maskine er usynlig for den der prøver at
>>>> scanne den,
>>>
>>> Nej det gør ikke, det er et marketing ord, beregnet til at narre
>>> folk der intet aner om sikkerhed.
>>
>>
>> Nej, det viser at der ikke er nogen port der, på den anmodede IP.
>
> I TCP/IP findes der ikke noget der hedder stealth. Det er et
> marketing- ord.
Man kunne have valgt at skrive skjult, men da programmet er engelsk, så ....
>>>> du undgår hackerens "radar".
>>>
>>> Nej, det viser bare at "her er der en der forsøger at skjule noget,
>>> det ser interessant ud".
>>
>> Hvis du synes, men det aktuelle er at den stadig, også er blokeret.
>
> Blokeret hedder for TCP: TCP reset / Connection refused, og for
> UDP hedder det ICMP port unreachable.
Hvilket også er hvad mine TCP porte er, ifølge portskanning.
> For TCP's vedkommende kommer man ikke langt uden et svar, men hvis vi
> snakker UDP, betyder "intet svar" faktisk at pakken er modtaget i den
> anden ende.
Nej, der kommer selvfølgelig ikke noget svar, men da jeg internt kan se at
der er forsøgt skanning på en ICMP port, som ikke er blevet modtaget, da jeg
jo har lukket dem, så kan du ikke generelisere som du gør.
> En trojan kunne nemt laves sådan at den bruger UDP, og først svarer
> tilbage når den har modtaget angriberens password. Da din portscanner
> ikke kender passwordet, vil den ikke svare, og din portscanner ser
> blot at der ikke kommer noget svar. I dette tilfælde er betegnelsen
> stealth faktisk ikke dårlig, da der netop er noget skjult på den
> port, noget som portscanneren ikke kan se, men som angriberen kan
> bruge til at overtage computeren.
Tjaaee. nu kan man også skanne for trojanere, og der er politikken den
samme, jeg kan se alt hvad der der prøves på af luskede metoder, men folk
får bare ikke svar, og intet kommer ind, medmindre jeg giver tilladelse.
Hvilket kan tjekkes på..
http://scan.sygate.com/
Og ja, jeg ved godt at det er fra producenten af selve programmet, men her
stoler jeg nu på de resultater der kommer, da det ikke kan være i firmaets
interesser at lyve sig til sikkerhed.
>> "forsøger at skjule noget", hvad mener du med det, at den der gør
>> mest muligt ud af sin firewall, gør det af suspekte årsager ?
>
> Nej, jeg mener ikke "forsøge at skjule noget for politiet", men
> derimod "forsøge at skjule noget for røveren". Der er ikke noget
> suspekt i det, men det kan stadig påkalde "røverens" interesse.
OK, godt ord igen
Allan
--
-- Som aldrig har hørt om dårlige tabere i Russisk roulette --
-- Kun døde fisk flyder med strømmen --
-- Skønhed afhænger af øjnene der ser --
-- Cum insantientibus fuere necesse est --
| |
Kent Friis (27-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-03 12:34 |
|
Den Sat, 27 Sep 2003 13:13:26 +0200 skrev Holger Danske:
>Kent Friis wrote:
>> Den Sat, 27 Sep 2003 12:31:54 +0200 skrev Holger Danske:
>>> Kent Friis wrote:
>>>> Den 27 Sep 2003 10:13:57 GMT skrev Jane:
>>>>> Kent Friis skrev i <news:bl3jeu$l7g$1@sunsite.dk>:
>>>>>
>>>>>> så man ikke er i tvivl om hvorvidt den mener at angreb mod dig
>>>>>> (hjælp!) ikke bliver opdaget før det er for sent, eller den mener
>>>>>> de angreb du laver (fy!).
>>>>>
>>>>> Stealth betyder at din maskine er usynlig for den der prøver at
>>>>> scanne den,
>>>>
>>>> Nej det gør ikke, det er et marketing ord, beregnet til at narre
>>>> folk der intet aner om sikkerhed.
>>>
>>>
>>> Nej, det viser at der ikke er nogen port der, på den anmodede IP.
>>
>> I TCP/IP findes der ikke noget der hedder stealth. Det er et
>> marketing- ord.
>
>Man kunne have valgt at skrive skjult, men da programmet er engelsk, så ....
Skjult hedder "hidden" på engelsk. Og der er ikke tale om at noget
er skjult, men derimod om noget der ikke svarer.
>>>>> du undgår hackerens "radar".
>>>>
>>>> Nej, det viser bare at "her er der en der forsøger at skjule noget,
>>>> det ser interessant ud".
>>>
>>> Hvis du synes, men det aktuelle er at den stadig, også er blokeret.
>>
>> Blokeret hedder for TCP: TCP reset / Connection refused, og for
>> UDP hedder det ICMP port unreachable.
>
>Hvilket også er hvad mine TCP porte er, ifølge portskanning.
>
>> For TCP's vedkommende kommer man ikke langt uden et svar, men hvis vi
>> snakker UDP, betyder "intet svar" faktisk at pakken er modtaget i den
>> anden ende.
>
>Nej, der kommer selvfølgelig ikke noget svar, men da jeg internt kan se at
>der er forsøgt skanning på en ICMP port, som ikke er blevet modtaget, da jeg
>jo har lukket dem, så kan du ikke generelisere som du gør.
ICMP har ikke porte.
Jeg generaliserer ikke, jeg siger at "Intet svar" ikke beviser noget
som helst. Det kan lige så godt være en trojan, som det kan være
en firewall.
>> En trojan kunne nemt laves sådan at den bruger UDP, og først svarer
>> tilbage når den har modtaget angriberens password. Da din portscanner
>> ikke kender passwordet, vil den ikke svare, og din portscanner ser
>> blot at der ikke kommer noget svar. I dette tilfælde er betegnelsen
>> stealth faktisk ikke dårlig, da der netop er noget skjult på den
>> port, noget som portscanneren ikke kan se, men som angriberen kan
>> bruge til at overtage computeren.
>
>Tjaaee. nu kan man også skanne for trojanere,
Det vil kun kigge efter de berømte, script-kiddie-trojans, så som
SubSeven.
>og der er politikken den
>samme, jeg kan se alt hvad der der prøves på af luskede metoder, men folk
>får bare ikke svar, og intet kommer ind, medmindre jeg giver tilladelse.
>Hvilket kan tjekkes på..
> http://scan.sygate.com/
>Og ja, jeg ved godt at det er fra producenten af selve programmet, men her
>stoler jeg nu på de resultater der kommer, da det ikke kan være i firmaets
>interesser at lyve sig til sikkerhed.
Det er ellers det adskillige store software-firmaer er berygtede for,
heriblandt firmaet Microsoft.
Mvh
Kent
--
You haven't seen _multitasking_ until you've seen Railroad
Tycoon II and Unreal Tournament run side by side
| |
Kasper Dupont (27-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 27-09-03 12:10 |
|
Kent Friis wrote:
>
> Den Sat, 27 Sep 2003 10:44:35 +0200 skrev Holger Danske:
> >
> >Jeg har afprøvet rigtig mange firewalls, og der er 1, der udmærker sig i
> >forhold til de andre, nemlig Sygate firewall Pro, her er f.eks. resultatet
> >fra ZA port scanning
> >"1056 Ports Tested
> >
> >ALL PORTS tested were found to be: STEALTH.
> >
> >TruStealth: PASSED - ALL tested ports were STEALTH,
> > - NO unsolicited packets were received,
> > - NO Ping reply (ICMP Echo) was received.
> >
> >det er jo rigtig fint
>
> Fint? Stealth er en type bombefly der er baseret på at man ikke opdager
> angrebet før det er for sent.
De bruger ordet stealth, fordi det lyder bedre end at sige, at
der er tale om en firewall, der overtrædder RFC 792 og RFC 793.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Kent Friis (27-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-03 12:13 |
|
Den Sat, 27 Sep 2003 13:10:10 +0200 skrev Kasper Dupont:
>Kent Friis wrote:
>>
>> Den Sat, 27 Sep 2003 10:44:35 +0200 skrev Holger Danske:
>> >
>> >Jeg har afprøvet rigtig mange firewalls, og der er 1, der udmærker sig i
>> >forhold til de andre, nemlig Sygate firewall Pro, her er f.eks. resultatet
>> >fra ZA port scanning
>> >"1056 Ports Tested
>> >
>> >ALL PORTS tested were found to be: STEALTH.
>> >
>> >TruStealth: PASSED - ALL tested ports were STEALTH,
>> > - NO unsolicited packets were received,
>> > - NO Ping reply (ICMP Echo) was received.
>> >
>> >det er jo rigtig fint
>>
>> Fint? Stealth er en type bombefly der er baseret på at man ikke opdager
>> angrebet før det er for sent.
>
>De bruger ordet stealth, fordi det lyder bedre end at sige, at
>der er tale om en firewall, der overtrædder RFC 792 og RFC 793.
Bingo.
Ren marketing.
Mvh
Kent
--
Desuden kan jeg ikke se nogen grund til at springe over hvor gærdet er
lavest, når man kan vente på at det alligevel bliver revet ned fordi
der skal bygges en omfartsvej...
- Claus Frørup og Asbjørn Christensen i dk.snak.
| |
Holger Danske (27-09-2003)
| Kommentar
Fra : Holger Danske |
Dato : 27-09-03 12:20 |
|
Kasper Dupont wrote:
> Kent Friis wrote:
>> Fint? Stealth er en type bombefly der er baseret på at man ikke
>> opdager angrebet før det er for sent.
>
> De bruger ordet stealth, fordi det lyder bedre end at sige, at
> der er tale om en firewall, der overtrædder RFC 792 og RFC 793.
Jeg kan godt leve med at standarter der er fra 1981 og som ikke er fulgt med
tiden *ikke* bliver overholdt, så længe min PC er så sikret som muligt, i
forhold til uvedkommedes adgang til den.
Allan
--
-- Som aldrig har hørt om dårlige tabere i Russisk roulette --
-- Kun døde fisk flyder med strømmen --
-- Skønhed afhænger af øjnene der ser --
-- Cum insantientibus fuere necesse est --
| |
Kent Friis (27-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-03 12:36 |
|
Den Sat, 27 Sep 2003 13:19:40 +0200 skrev Holger Danske:
>Kasper Dupont wrote:
>> Kent Friis wrote:
>>> Fint? Stealth er en type bombefly der er baseret på at man ikke
>>> opdager angrebet før det er for sent.
>>
>> De bruger ordet stealth, fordi det lyder bedre end at sige, at
>> der er tale om en firewall, der overtrædder RFC 792 og RFC 793.
>
>
>Jeg kan godt leve med at standarter der er fra 1981 og som ikke er fulgt med
>tiden *ikke* bliver overholdt,
Vi snakker om ICMP og TCP standarderne. Hvad pokker vil du ellers køre?
NetBeui? OSI?
>så længe min PC er så sikret som muligt, i forhold til uvedkommedes
>adgang til den.
At overtræde protokollerne giver ikke ekstra sikkerhed, det giver kun
problemer.
Mvh
Kent
--
"Intelligence is the ability to avoid doing work, yet get the work done"
- Linus Torvalds
| |
Kasper Dupont (27-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 27-09-03 14:14 |
|
Kent Friis wrote:
>
> Den Sat, 27 Sep 2003 13:19:40 +0200 skrev Holger Danske:
> >
> >Jeg kan godt leve med at standarter der er fra 1981 og som ikke er fulgt med
> >tiden *ikke* bliver overholdt,
Den eneste grund til, at vi stadig bruger IPv4 er folk, der ikke vil følge
med tiden. Hvis du interesseret i at følge med tiden, hvorfor bruger du så
ikke IPv6 endnu? Uanset om du vil bruge en forældet eller en lidt mere
tidssvarende protokol, så skal den overholdes.
>
> At overtræde protokollerne giver ikke ekstra sikkerhed, det giver kun
> problemer.
Enig. Hvis protokollerne i sig selv var en sikkerhedsrisiko ville de være
blevet opdateret. Og hvad angår problemerne, så tænk på, at det er nemmere
at spoofe din IP adresse, hvis din computer ikke svarer.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Jesper Dybdal (27-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 27-09-03 18:43 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>De bruger ordet stealth, fordi det lyder bedre end at sige, at
>der er tale om en firewall, der overtrædder RFC 792 og RFC 793.
Jeg har ikke slået de RFC'er op, men jeg tror godt jeg kan gennemskue
hvad du mener alligevel.
Mener du generelt at der er noget galt i at bruge firewalls der
overtræder dem? Det er mit indtryk (som da kan være forkert, og så
hører jeg gerne om det) at sådan gør ikke bare de personlige
firewalls, men et stort flertal af denne verdens firewalls, inkl. de
fleste af de hundedyre generelle firewallprodukter som alverdens
firmaer beskytter sig bag.
Det er også mit indtryk at ret mange af os netop i disse dage bliver
forskånet for tusindvis af eksemplarer af Swen.A-virussen fordi nogle
mailservere omhyggeligt undlader at overholde de RFC'er der ellers
fortæller hvad en mailserver skal gøre.
Firewalls og virusfiltre har det til fælles at deres formål netop er
at blokere for noget af den funktionalitet som RFC'erne omhyggeligt
beskriver. Derved kommer de nemt til at overtræde RFC'erne, som for
manges vedkommende er skrevet før der var nutidens behov for firewalls
og virusfiltre. Men de overtræder dem jo kun når nogen sender pakker
eller breve (vira) som ingen har lov til at sende til de systemer.
Man kan have masser af negative meninger om den moderne "personlig
firewall"-industri og dens tilhørende skræmmekampagner, men jeg kan
ikke se noget særlig galt i at vælge en kort og markedsføringsegnet
betegnelse for det at en firewall dropper pakker uden svar.
Naturligvis er ordet marketing-agtigt: behovet for sådan en betegnelse
er jo opstået fordi det pludselig et blevet noget der kan markedsføres
til masserne. Det nytter ikke at kæmpe mod marketing-opfundne navne:
datamater blev fx pludselig kaldt "computere" da de blev markedsført
til masserne, og selv jeg kan finde på at bruge det ord nu.
Der findes absolut valide argumenter der taler imod brugen af
personlige firewalls og virusscannere; men at man ikke kan lide ordet
"stealth", og at de overtræder nogle RFC'er ved at ignorere en pakke
fra en script-kiddie, synes jeg er meget dårlige argumenter mod
anvendelsen af disse værktøjer.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kent Friis (27-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-03 19:44 |
|
Den Sat, 27 Sep 2003 19:42:44 +0200 skrev Jesper Dybdal:
>Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
>>De bruger ordet stealth, fordi det lyder bedre end at sige, at
>>der er tale om en firewall, der overtrædder RFC 792 og RFC 793.
>
>Jeg har ikke slået de RFC'er op, men jeg tror godt jeg kan gennemskue
>hvad du mener alligevel.
>
>Mener du generelt at der er noget galt i at bruge firewalls der
>overtræder dem? Det er mit indtryk (som da kan være forkert, og så
>hører jeg gerne om det) at sådan gør ikke bare de personlige
>firewalls, men et stort flertal af denne verdens firewalls, inkl. de
>fleste af de hundedyre generelle firewallprodukter som alverdens
>firmaer beskytter sig bag.
Professionelle firewalls konfigurerer man til at gøre præcis som man
ønsker de skal gøre, firewall'en er komplet ligeglad. Det er altså op
til den administrator der sætter firewall'en op.
Desværre er der så mange administratorer der sætter deres firewalls op
til at overtræde diverse standarder, ikke kun de her nævnte, men også
fx at blokere for ICMP would fragment pakker, på trods af at det
gør at folk på PPPoE ADSL kan få problemer med at connecte.
Jeg tror faktisk også de fleste personlige firewalls kan konfigureres,
de har bare en elendig default opsætning.
>Firewalls og virusfiltre har det til fælles at deres formål netop er
>at blokere for noget af den funktionalitet som RFC'erne omhyggeligt
>beskriver. Derved kommer de nemt til at overtræde RFC'erne, som for
>manges vedkommende er skrevet før der var nutidens behov for firewalls
>og virusfiltre. Men de overtræder dem jo kun når nogen sender pakker
>eller breve (vira) som ingen har lov til at sende til de systemer.
Men her er der jo ikke tale om at blokere for skadelig trafik, men
derimod at nægte at afsende uskadelig, påkrævet trafik.
>Man kan have masser af negative meninger om den moderne "personlig
>firewall"-industri og dens tilhørende skræmmekampagner, men jeg kan
>ikke se noget særlig galt i at vælge en kort og markedsføringsegnet
>betegnelse for det at en firewall dropper pakker uden svar.
Kort betegnelse: DEFEKT.
>Der findes absolut valide argumenter der taler imod brugen af
>personlige firewalls og virusscannere; men at man ikke kan lide ordet
>"stealth", og at de overtræder nogle RFC'er ved at ignorere en pakke
>fra en script-kiddie, synes jeg er meget dårlige argumenter mod
>anvendelsen af disse værktøjer.
Det er jo ikke kun pakker fra en script-kiddie der bliver ignoreret.
Mvh
Kent
--
At køre i en stor Mercedes eller BMW viser ikke at man har mange penge.
Det viser blot at man er tysker.
| |
Lars Kim Lund (27-09-2003)
| Kommentar
Fra : Lars Kim Lund |
Dato : 27-09-03 20:25 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>Professionelle firewalls konfigurerer man til at gøre præcis som man
>ønsker de skal gøre, firewall'en er komplet ligeglad. Det er altså op
>til den administrator der sætter firewall'en op.
Og det skal man ikke overse er den vigtigste faktor. Udfører
naturligvis fejl og svagheder i softwaren så er den største risiko den
menneskelige faktor.
>Desværre er der så mange administratorer der sætter deres firewalls op
>til at overtræde diverse standarder, ikke kun de her nævnte, men også
>fx at blokere for ICMP would fragment pakker, på trods af at det
>gør at folk på PPPoE ADSL kan få problemer med at connecte.
Jeg enig i at der er et par ICMP typer det kan være uheldigt at
blokere. Men derudover så er en firewall vel i sin natur non standard.
F.eks. er det jo ikke ret standard at droppe pakker og ikke sende RST.
--
Lars Kim Lund
http://www.net-faq.dk/
| |
Kent Friis (27-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-03 20:40 |
|
Den Sat, 27 Sep 2003 21:25:04 +0200 skrev Lars Kim Lund:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>Professionelle firewalls konfigurerer man til at gøre præcis som man
>>ønsker de skal gøre, firewall'en er komplet ligeglad. Det er altså op
>>til den administrator der sætter firewall'en op.
>
>Og det skal man ikke overse er den vigtigste faktor. Udfører
>naturligvis fejl og svagheder i softwaren så er den største risiko den
>menneskelige faktor.
>
>>Desværre er der så mange administratorer der sætter deres firewalls op
>>til at overtræde diverse standarder, ikke kun de her nævnte, men også
>>fx at blokere for ICMP would fragment pakker, på trods af at det
>>gør at folk på PPPoE ADSL kan få problemer med at connecte.
>
>Jeg enig i at der er et par ICMP typer det kan være uheldigt at
>blokere. Men derudover så er en firewall vel i sin natur non standard.
>F.eks. er det jo ikke ret standard at droppe pakker og ikke sende RST.
Det er jo også netop dette der er FEJLEN. En fornuftig firewall sender
RST, når den ikke tillader en connection.
Mvh
Kent
--
Desuden kan jeg ikke se nogen grund til at springe over hvor gærdet er
lavest, når man kan vente på at det alligevel bliver revet ned fordi
der skal bygges en omfartsvej...
- Claus Frørup og Asbjørn Christensen i dk.snak.
| |
Lars Kim Lund (27-09-2003)
| Kommentar
Fra : Lars Kim Lund |
Dato : 27-09-03 20:54 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>>Jeg enig i at der er et par ICMP typer det kan være uheldigt at
>>blokere. Men derudover så er en firewall vel i sin natur non standard.
>>F.eks. er det jo ikke ret standard at droppe pakker og ikke sende RST.
>
>Det er jo også netop dette der er FEJLEN. En fornuftig firewall sender
>RST, når den ikke tillader en connection.
Alle professionelle firewalls jeg har mødt kan begge. Så det du mener
er vel at enhver fornuftig administrator beder firewallen om at sende
RST.
Det må du jo mene som du vil. Jeg tror der findes en del ufornuftige
mennesker derude i så fald. Og du bliver nødt til at argumentere bedre
end "det ødelægger internettet", hvis du vil forsøge at ændre noget.
--
Lars Kim Lund
http://www.net-faq.dk/
| |
Kent Friis (27-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-03 20:59 |
|
Den Sat, 27 Sep 2003 21:53:39 +0200 skrev Lars Kim Lund:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>>Jeg enig i at der er et par ICMP typer det kan være uheldigt at
>>>blokere. Men derudover så er en firewall vel i sin natur non standard.
>>>F.eks. er det jo ikke ret standard at droppe pakker og ikke sende RST.
>>
>>Det er jo også netop dette der er FEJLEN. En fornuftig firewall sender
>>RST, når den ikke tillader en connection.
>
>Alle professionelle firewalls jeg har mødt kan begge. Så det du mener
>er vel at enhver fornuftig administrator beder firewallen om at sende
>RST.
Før den er konfigureret, virker den ikke som firewall.
>Det må du jo mene som du vil. Jeg tror der findes en del ufornuftige
>mennesker derude i så fald. Og du bliver nødt til at argumentere bedre
>end "det ødelægger internettet", hvis du vil forsøge at ændre noget.
Der findes mange, og de skaber masser af problemer. Fx kan jeg ikke
komme ind på http://www.telebutikken.dk/ fordi TDC har en defekt
firewall der dropper pakker i strid med samtlige relevante RFC'er.
Mvh
Kent
--
6.0 FDiv 3.0 = 1.999773462873 - Intel Pentium bug
| |
Kasper Dupont (27-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 27-09-03 22:09 |
|
Kent Friis wrote:
>
> Der findes mange, og de skaber masser af problemer. Fx kan jeg ikke
> komme ind på http://www.telebutikken.dk/ fordi TDC har en defekt
> firewall der dropper pakker i strid med samtlige relevante RFC'er.
Tror du ikke bare serveren er nede? Nu har jeg prøvet med tre
forskellige operativsystemer, der kommer aldrig en SYNACK pakke
fra port 80 på den maskine.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Kent Friis (27-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-03 23:07 |
|
Den Sat, 27 Sep 2003 23:08:31 +0200 skrev Kasper Dupont:
>Kent Friis wrote:
>>
>> Der findes mange, og de skaber masser af problemer. Fx kan jeg ikke
>> komme ind på http://www.telebutikken.dk/ fordi TDC har en defekt
>> firewall der dropper pakker i strid med samtlige relevante RFC'er.
>
>Tror du ikke bare serveren er nede? Nu har jeg prøvet med tre
>forskellige operativsystemer, der kommer aldrig en SYNACK pakke
>fra port 80 på den maskine.
Jeg kunne heller ikke komme ind på siden for et halvt år siden, så
længe er en webshop normalt ikke nede af gangen. Jeg har faktisk engang
sendt en mail til TDC om problemet, og de svarede "det er et kendt
problem, vi arbejder på sagen".
Mvh
Kent
--
If you think about it, Windows XP is actually the OS that
started as "Microsoft OS/2 NT 3.0"
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 02:58 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>Der findes mange, og de skaber masser af problemer. Fx kan jeg ikke
>komme ind på http://www.telebutikken.dk/ fordi TDC har en defekt
>firewall der dropper pakker i strid med samtlige relevante RFC'er.
Naturligvis kan man ødelægge funktionalitet ved at miskonfigurere en
firewall.
Men dit eksempel har vel intet at gøre med om det er fornuftigt eller
ej at undlade at svare på pakker til porte hvor man ikke ønsker at
levere en service.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kent Friis (28-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 28-09-03 10:07 |
|
Den Sun, 28 Sep 2003 03:58:05 +0200 skrev Jesper Dybdal:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>Der findes mange, og de skaber masser af problemer. Fx kan jeg ikke
>>komme ind på http://www.telebutikken.dk/ fordi TDC har en defekt
>>firewall der dropper pakker i strid med samtlige relevante RFC'er.
>
>Naturligvis kan man ødelægge funktionalitet ved at miskonfigurere en
>firewall.
>
>Men dit eksempel har vel intet at gøre med om det er fornuftigt eller
>ej at undlade at svare på pakker til porte hvor man ikke ønsker at
>levere en service.
Nej, det er et eksempel på at hvis man overtræder protokollerne, så
ødelægger man det for sig selv og sine kunder.
Mvh
Kent
--
Demokrati er lige som den 29. februar - begge dele forekommer
en gang hver fjerde år.
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 23:49 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>Den Sun, 28 Sep 2003 03:58:05 +0200 skrev Jesper Dybdal:
>>leeloo@phreaker.net (Kent Friis) wrote:
>>
>>Men dit eksempel har vel intet at gøre med om det er fornuftigt eller
>>ej at undlade at svare på pakker til porte hvor man ikke ønsker at
>>levere en service.
>
>Nej, det er et eksempel på at hvis man overtræder protokollerne, så
>ødelægger man det for sig selv og sine kunder.
Ja, naturligvis. Hvis man overtræder protokollerne for ting der skal
virke - ikke hvis man overtræder protokollerne for netop at sikre at
ting *ikke* virker - hvilket er en firewalls funktion.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kent Friis (29-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-03 18:24 |
|
Den Mon, 29 Sep 2003 00:49:23 +0200 skrev Jesper Dybdal:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>Den Sun, 28 Sep 2003 03:58:05 +0200 skrev Jesper Dybdal:
>>>leeloo@phreaker.net (Kent Friis) wrote:
>>>
>>>Men dit eksempel har vel intet at gøre med om det er fornuftigt eller
>>>ej at undlade at svare på pakker til porte hvor man ikke ønsker at
>>>levere en service.
>>
>>Nej, det er et eksempel på at hvis man overtræder protokollerne, så
>>ødelægger man det for sig selv og sine kunder.
>
>Ja, naturligvis. Hvis man overtræder protokollerne for ting der skal
>virke - ikke hvis man overtræder protokollerne for netop at sikre at
>ting *ikke* virker - hvilket er en firewalls funktion.
Hvorfor ønsker du at sikre at "Connection refused" ikke virker?
Mvh
Kent
--
Journalist: En der har forstand på at skrive artikler, men typisk
ikke på det artiklerne handler om.
| |
Klaus Ellegaard (29-09-2003)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 29-09-03 18:28 |
|
leeloo@phreaker.net (Kent Friis) writes:
>Hvorfor ønsker du at sikre at "Connection refused" ikke virker?
Det gør portscanninger uendeligt meget hurtigere.
Mvh.
Klaus.
| |
Kent Friis (29-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-03 19:01 |
|
Den Mon, 29 Sep 2003 17:27:44 +0000 (UTC) skrev Klaus Ellegaard:
>leeloo@phreaker.net (Kent Friis) writes:
>
>>Hvorfor ønsker du at sikre at "Connection refused" ikke virker?
>
>Det gør portscanninger uendeligt meget hurtigere.
So what?
En portscan gør ingen skade. Og jo før Mr. Scriptkiddie konstaterer at
der er lukket, jo før opgiver han og går videre til næste system.
Mvh
Kent
--
Journalist: En der har forstand på at skrive artikler, men typisk
ikke på det artiklerne handler om.
| |
Jesper Dybdal (29-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 29-09-03 19:25 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>Den Mon, 29 Sep 2003 17:27:44 +0000 (UTC) skrev Klaus Ellegaard:
>>leeloo@phreaker.net (Kent Friis) writes:
>>
>>>Hvorfor ønsker du at sikre at "Connection refused" ikke virker?
>>
>>Det gør portscanninger uendeligt meget hurtigere.
>
>So what?
>
>En portscan gør ingen skade. Og jo før Mr. Scriptkiddie konstaterer at
>der er lukket, jo før opgiver han og går videre til næste system.
- og jo flere systemer kan han nå at genere pr. dag, og jo flere
sårbare systemer kan han finde pr. dag.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kent Friis (29-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-03 20:36 |
|
Den Mon, 29 Sep 2003 20:25:13 +0200 skrev Jesper Dybdal:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>Den Mon, 29 Sep 2003 17:27:44 +0000 (UTC) skrev Klaus Ellegaard:
>>>leeloo@phreaker.net (Kent Friis) writes:
>>>
>>>>Hvorfor ønsker du at sikre at "Connection refused" ikke virker?
>>>
>>>Det gør portscanninger uendeligt meget hurtigere.
>>
>>So what?
>>
>>En portscan gør ingen skade. Og jo før Mr. Scriptkiddie konstaterer at
>>der er lukket, jo før opgiver han og går videre til næste system.
>
>- og jo flere systemer kan han nå at genere pr. dag,
Hvis det er det han er ude på, er han komplet ligeglad med om
systemerne svarer.
>og jo flere sårbare systemer kan han finde pr. dag.
Gør det sikkerhedsmæssigt nogen forskel om man bliver angrebet
tirsdag eller først lørdag? Det bliver højst en mindre forsinkelse.
Mvh
Kent
--
"Intelligence is the ability to avoid doing work, yet get the work done"
- Linus Torvalds
| |
Jesper Dybdal (29-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 29-09-03 21:12 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>Gør det sikkerhedsmæssigt nogen forskel om man bliver angrebet
>tirsdag eller først lørdag? Det bliver højst en mindre forsinkelse.
Hvis angriberen kun har tænkt sig at bruge fx en uge til at lede efter
ofre, så gør det pokker til forskel om hvert forsøg på at finde et
offer tager 100 ms eller 30 s.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kent Friis (30-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 30-09-03 16:36 |
|
Den Mon, 29 Sep 2003 22:12:04 +0200 skrev Jesper Dybdal:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>Gør det sikkerhedsmæssigt nogen forskel om man bliver angrebet
>>tirsdag eller først lørdag? Det bliver højst en mindre forsinkelse.
>
>Hvis angriberen kun har tænkt sig at bruge fx en uge til at lede efter
>ofre, så gør det pokker til forskel om hvert forsøg på at finde et
>offer tager 100 ms eller 30 s.
Jeg tror de fleste sætter sig for at "nu vil jeg have 1000 DDOS-bots",
fremfor at sætte en uge af til formålet.
Iøvrigt er det heller ikke noget problem at afbryde scanningen så snart
man har set de første par porte ikke svarer, og springe videre til
næste maskine - der er jo maskiner nok at tage af.
Mvh
Kent
--
At køre i en stor Mercedes eller BMW viser ikke at man har mange penge.
Det viser blot at man er tysker.
| |
Klaus Ellegaard (29-09-2003)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 29-09-03 21:16 |
|
leeloo@phreaker.net (Kent Friis) writes:
>Gør det sikkerhedsmæssigt nogen forskel om man bliver angrebet
>tirsdag eller først lørdag? Det bliver højst en mindre forsinkelse.
Hvis vi snakker automatiserede angreb, gør det en gigantisk
forskel.
Det, du kalder "well-behaved" klienter, er med hensyn til
angrebets udbredelseshastighed enhver sikkerhedsmands mareridt.
(Under forudsætning af at den angribende maskine har et
forholdsvis begrænset antal sockets til rådighed og angrebet
er TCP-baseret)
Mvh.
Klaus.
| |
Kasper Dupont (30-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 30-09-03 15:06 |
|
Klaus Ellegaard wrote:
>
> (Under forudsætning af at den angribende maskine har et
> forholdsvis begrænset antal sockets til rådighed og angrebet
> er TCP-baseret)
Hvis man absolut vil scanne, så behøves man jo ikke huske
på alle de SYN pakker man har sendt. Det er nok at huske
på svarene, og det kan såmænd gøres med blot to bit per
port. (Eller en enkelt, hvis man ikke har tænkt sig at
skelne mellem RST og timeout). Det vil sige, at 1024MB
RAM er nok til at scanne et helt klasse B subnet for alle
TCP porte. Og med en 80GB harddisk kan du faktisk lagre
interessante svar fra hele internettet. At det så ville
tage 20-30 år at sende alle SYN pakkerne over et 100mbit
ethernet er den største forhindring for angriberen.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Asbjorn Hojmark (29-09-2003)
| Kommentar
Fra : Asbjorn Hojmark |
Dato : 29-09-03 22:36 |
|
On Mon, 29 Sep 2003 17:27:44 +0000 (UTC), Klaus Ellegaard
<klausellegaard@msn.com> wrote:
>> Hvorfor ønsker du at sikre at "Connection refused" ikke virker?
> Det gør portscanninger uendeligt meget hurtigere.
Det er jo det gode gamle argument, men jeg er ikke sikker på, det
rigtig holder længere, for i dag scanner man jo bare multiple
porte på én gang.
-A
--
http://www.hojmark.org/
| |
Kasper Dupont (27-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 27-09-03 21:35 |
|
Lars Kim Lund wrote:
>
> Alle professionelle firewalls jeg har mødt kan begge. Så det du mener
> er vel at enhver fornuftig administrator beder firewallen om at sende
> RST.
Jeg har aldrig set et godt argument for at ikke sende en RST pakke.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 02:58 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>Lars Kim Lund wrote:
>>
>> Alle professionelle firewalls jeg har mødt kan begge. Så det du mener
>> er vel at enhver fornuftig administrator beder firewallen om at sende
>> RST.
>
>Jeg har aldrig set et godt argument for at ikke sende en RST pakke.
Jeg har nævnt ét argument i mit svar til Kent. Et andet kunne være at
man måske ikke ønsker at bruge trafik på at svare.
Indrømmet, ingen af de argumenter er stærke nok til at gøre det oplagt
at man ikke skal sende en RST-pakke. Men de er dog en slags
argumenter, og jeg kan ikke rigtig se noget argument den anden vej.
I øvrigt er det jo sådan at enhver stump ledning har lov til at komme
til at tabe en pakke, svjv uden at være i konflikt med nogen RFC.
Alle protokoller skal i hvert fald kunne håndtere at pakker bare
forsvinder. Man kunne således måske argumentere for at en
bortsmidning af pakker ikke er i modstrid med nogen protokol - udover
at den naturligvis hindrer adgang til en service, men det er jo netop
formålet med en firewall.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kasper Dupont (28-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 28-09-03 10:11 |
|
Jesper Dybdal wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
> >Lars Kim Lund wrote:
> >>
> >> Alle professionelle firewalls jeg har mødt kan begge. Så det du mener
> >> er vel at enhver fornuftig administrator beder firewallen om at sende
> >> RST.
> >
> >Jeg har aldrig set et godt argument for at ikke sende en RST pakke.
>
> Jeg har nævnt ét argument i mit svar til Kent. Et andet kunne være at
> man måske ikke ønsker at bruge trafik på at svare.
Der bruges mere trafik hvis du unlader at svare. Hvis du svarer bliver
der kun sendt en enkelt pakke i hver retning. Hvis du unlader at svare
bliver klienten ved med at sende pakker, indtil et timeout. Hvis du er
bekymret for flooding med SYN pakker kan du lægge en begrænsning på
hvor meget båndbredde du bruger på RST pakker. Men hvis man vil
floode dig kan man jo stadig gøre det på en af dine åbne porte.
>
> Indrømmet, ingen af de argumenter er stærke nok til at gøre det oplagt
> at man ikke skal sende en RST-pakke. Men de er dog en slags
> argumenter, og jeg kan ikke rigtig se noget argument den anden vej.
Jeg har i hvert fald givet argumenter for, hvorfor man skal sende RST
pakker. At standarden kræver det er et tungtvejende, men langt fra det
eneste argument.
>
> I øvrigt er det jo sådan at enhver stump ledning har lov til at komme
> til at tabe en pakke, svjv uden at være i konflikt med nogen RFC.
Selvfølgelig kan der forekomme pakketab pga. transmitionsfejl eller
kongestion. Men der er stor forskel på, at tabe enkelte tilfældige
pakker, og konsekvent smide alle pakker fra en enkelt klient væk.
> Alle protokoller skal i hvert fald kunne håndtere at pakker bare
> forsvinder.
Ja, det er derfor klienten skal retransmitere pakken indtil det
lykkes at få den igennem. Med mindre noget udstyr på vejen ikke
virker vil det jo lykkes før eller siden.
> Man kunne således måske argumentere for at en
> bortsmidning af pakker ikke er i modstrid med nogen protokol
Det er ikke i strid med nogen protokol at smide pakker væk. Men det
kan være i strid med standarder at bruge indholdet af pakkerne, til
at afgøre hvilke pakker, der skal smides væk. Der er felter, som
eksplicit ikke må benyttes til at afgøre, hvilke pakker, der smides
væk. Og der er reserverede felter, hvis indhold skal ignoreres. De
må selvfølgelig heller ikke bruges til at afgøre, hvilke pakker,
man smider væk.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 23:49 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>Jesper Dybdal wrote:
>>
>> Jeg har nævnt ét argument i mit svar til Kent. Et andet kunne være at
>> man måske ikke ønsker at bruge trafik på at svare.
>
>Der bruges mere trafik hvis du unlader at svare. Hvis du svarer bliver
>der kun sendt en enkelt pakke i hver retning. Hvis du unlader at svare
>bliver klienten ved med at sende pakker, indtil et timeout.
Indrømmet - jeg tænkte mig vist ikke om. (På en asymmetrisk ADSL
koster 3 indgående SYN-pakker dog i en vist forstand mindre end 1
udgående RST-pakke, men jeg vil ikke påstå at det er noget seriøst
argument.)
>> Man kunne således måske argumentere for at en
>> bortsmidning af pakker ikke er i modstrid med nogen protokol
>
>Det er ikke i strid med nogen protokol at smide pakker væk. Men det
>kan være i strid med standarder at bruge indholdet af pakkerne, til
>at afgøre hvilke pakker, der skal smides væk. Der er felter, som
>eksplicit ikke må benyttes til at afgøre, hvilke pakker, der smides
>væk.
Hvilke? (Du har tydeligvis læst RFC'en for nylig.)
Udgangspunktet for denne diskussion var en personlig firewall der
smider alle indkommende pakker væk som ikke hører til en indefra
etableret "forbindelse" i bred forstand. Det mener jeg er en
overordentlig fornuftig opførsel for en firewall eller ruter der
beskytter et netværk som ikke indeholder servere.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kasper Dupont (29-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 29-09-03 07:20 |
|
Jesper Dybdal wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
> >Jesper Dybdal wrote:
> >>
> >> Jeg har nævnt ét argument i mit svar til Kent. Et andet kunne være at
> >> man måske ikke ønsker at bruge trafik på at svare.
> >
> >Der bruges mere trafik hvis du unlader at svare. Hvis du svarer bliver
> >der kun sendt en enkelt pakke i hver retning. Hvis du unlader at svare
> >bliver klienten ved med at sende pakker, indtil et timeout.
>
> Indrømmet - jeg tænkte mig vist ikke om. (På en asymmetrisk ADSL
> koster 3 indgående SYN-pakker dog i en vist forstand mindre end 1
> udgående RST-pakke, men jeg vil ikke påstå at det er noget seriøst
> argument.)
Afhængig af klientens timeout kan der vist godt komme mere
end 3 SYN pakker.
>
> >> Man kunne således måske argumentere for at en
> >> bortsmidning af pakker ikke er i modstrid med nogen protokol
> >
> >Det er ikke i strid med nogen protokol at smide pakker væk. Men det
> >kan være i strid med standarder at bruge indholdet af pakkerne, til
> >at afgøre hvilke pakker, der skal smides væk. Der er felter, som
> >eksplicit ikke må benyttes til at afgøre, hvilke pakker, der smides
> >væk.
>
> Hvilke? (Du har tydeligvis læst RFC'en for nylig.)
Desværre for længe siden til, at jeg kan finde stedet igen.
Jeg mener helt bestemt at have læst, at en router ikke må
droppe en pakke med ECN bit sat, hvis ikke den også ville
have droppet pakken hvis den ikke havde været sat. Og at
tidligere standarder sagde, at disse reserverede bits
skulle ignoreres. Det var nu også bare et eksempel på, at
selvom en router naturligvis gerne må smide pakker væk, så
kan der være restriktioner på, hvordan den må beslutte,
hvilke pakker, der smides væk.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Kent Friis (28-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 28-09-03 10:12 |
|
Den Sun, 28 Sep 2003 03:58:07 +0200 skrev Jesper Dybdal:
>Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
>>Lars Kim Lund wrote:
>>>
>>> Alle professionelle firewalls jeg har mødt kan begge. Så det du mener
>>> er vel at enhver fornuftig administrator beder firewallen om at sende
>>> RST.
>>
>>Jeg har aldrig set et godt argument for at ikke sende en RST pakke.
>
>Jeg har nævnt ét argument i mit svar til Kent. Et andet kunne være at
>man måske ikke ønsker at bruge trafik på at svare.
>
>Indrømmet, ingen af de argumenter er stærke nok til at gøre det oplagt
>at man ikke skal sende en RST-pakke. Men de er dog en slags
>argumenter, og jeg kan ikke rigtig se noget argument den anden vej.
>
>I øvrigt er det jo sådan at enhver stump ledning har lov til at komme
>til at tabe en pakke, svjv uden at være i konflikt med nogen RFC.
>Alle protokoller skal i hvert fald kunne håndtere at pakker bare
>forsvinder.
Og det håndteres ved at sende pakken igen. Så det eneste du får ud af
ikke at RST'e uønsket trafik, er ENDNU MERE uønsket trafik.
>Man kunne således måske argumentere for at en
>bortsmidning af pakker ikke er i modstrid med nogen protokol
Protokollen siger at der skal svares med TCP RST, hvis din firewall
ikke ønsker at etablere en connection. Så den eneste måde du kan
argumentere for at det ikke er i strid med protokollen, er ved at
sige at du ønsker at etablere en connection. Og i så fald er din
firewall fejlkonfigureret, idet den smider ønsket trafik væk.
Mvh
Kent
--
6.0 FDiv 3.0 = 1.999773462873 - Intel Pentium bug
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 23:50 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>Den Sun, 28 Sep 2003 03:58:07 +0200 skrev Jesper Dybdal:
>>Man kunne således måske argumentere for at en
>>bortsmidning af pakker ikke er i modstrid med nogen protokol
>
>Protokollen siger at der skal svares med TCP RST, hvis din firewall
>ikke ønsker at etablere en connection.
Er du sikker? RST er en del af tcp-protokollen mellem de to maskiner
i forbindelsens to ender. Hvis destinationsmaskinen ikke ønsker en
tcp-forbindelse, så er RST ganske rigtigt sagen, men hvis en firewall
mellem dem vil blokere forbindelsen bør det vel protokolmæssigt pænest
ske via en "icmp destination unreachable" (type 3) med en af de koder
der betyder "administratively prohibited" (code 9, 10, eller 13).
(Men i øvrigt mener jeg personligt at det ofte er mere praktisk at
simulere en RST fra destinationsmaskinen, fordi det i praksis giver
større sandsynlighed for fornuftig reaktion fra klienten.)
For sjovs skyld, og for at sætte hele denne diskussion om hvorvidt en
privatperson mon kan tillade sig at smide pakker væk lidt i
perspektiv, har jeg lavet en lille uvidenskabelig undersøgelse ved at
sende SYN-pakker til et antal (hovedsageligt web-)servere, herunder
nogle tilhørende organisationer der må forventes at have lidt forstand
på tcp/ip og firewallteknik, for at se hvad svar de, eller deres
beskyttende firewall, giver.
Bortset fra port 25-filteret, som naturligvis er prøvet på port 25,
har jeg sendt SYN-pakker til port 1234. Jeg har tjekket reaktionen
ved at køre tcpdump samtidig:
www.w3c.org icmp port unreachable
www.isc.org icmp host unreachable - admin prohibited
filter
www.rfc.org RST
www.ibm.com intet svar
www.icann.com intet svar
www.checkpoint.com intet svar
www.cisco.com intet svar
www.microsoft.com RST
www.hp.com intet svar
www.daimi.au.dk RST
sunsite.dk intet svar
www.tdc.dk RST
www.tiscali.dk intet svar
www.cybercity.dk RST
Slukket TDC
BB ADSL modem intet svar
TDC's filter mod
Verisigns Site Finder
(64.94.110.11) intet svar
TDC's port 25-filter icmp host unreachable - admin prohibited
filter
Jeg ved naturligvis ikke om dem der svarer RST, gør det fordi de er
beskyttet af en firewall der svarer RST eller fordi de ikke har en
firewall foran overhovedet.
Under alle omstændigheder har ovenstående lille stikprøve bekræftet
min opfattelse af at selv hvis du og Kasper teoretisk set skulle have
ret i at man ikke bør smide SYN-pakker væk uden svar (hvad jeg stadig
ikke på nogen måde er overbevist om), så er det i hvert fald så
udbredt at gøre det, også blandt anerkendte firmaer og organisationer
med ekspertise i emnet, at det i givet fald måske nok er RFC'erne der
er ude af trit med virkeligheden.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kent Friis (29-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-03 18:39 |
|
Den Mon, 29 Sep 2003 00:49:55 +0200 skrev Jesper Dybdal:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>Den Sun, 28 Sep 2003 03:58:07 +0200 skrev Jesper Dybdal:
>>>Man kunne således måske argumentere for at en
>>>bortsmidning af pakker ikke er i modstrid med nogen protokol
>>
>>Protokollen siger at der skal svares med TCP RST, hvis din firewall
>>ikke ønsker at etablere en connection.
>
>Er du sikker? RST er en del af tcp-protokollen mellem de to maskiner
>i forbindelsens to ender. Hvis destinationsmaskinen ikke ønsker en
>tcp-forbindelse, så er RST ganske rigtigt sagen, men hvis en firewall
>mellem dem vil blokere forbindelsen bør det vel protokolmæssigt pænest
>ske via en "icmp destination unreachable" (type 3) med en af de koder
>der betyder "administratively prohibited" (code 9, 10, eller 13).
Det er også helt ok med mig (jeg har ikke nærlæst standarden), bare
der kommer en eller anden form for svar, som den anden ende forstår.
Men så længe diskussionen drejer sig om personal firewalls, er der
ikke noget argument imod at bruge RST, når (hvis) man svarer.
>Under alle omstændigheder har ovenstående lille stikprøve bekræftet
>min opfattelse af at selv hvis du og Kasper teoretisk set skulle have
>ret i at man ikke bør smide SYN-pakker væk uden svar (hvad jeg stadig
>ikke på nogen måde er overbevist om), så er det i hvert fald så
>udbredt at gøre det, også blandt anerkendte firmaer og organisationer
>med ekspertise i emnet, at det i givet fald måske nok er RFC'erne der
>er ude af trit med virkeligheden.
Mit eget eksempel på at overtræde RFC'erne var TDC, de burde også have
ekspertise på området. Og eksemplet med ICMP would fragment var et par
store webhosting-firmaer.
Så det eneste jeg kan konkludere, er at ekspertisen hjælper ikke en sk*d
hvis den ikke ligger hos de personer der sætter firewall'en op.
Mvh
Kent
--
If I wanted a blue screen, I would type "xsetroot -solid blue"
- not c:\I386\WINNT.EXE
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 02:58 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>Den Sat, 27 Sep 2003 19:42:44 +0200 skrev Jesper Dybdal:
>>Firewalls og virusfiltre har det til fælles at deres formål netop er
>>at blokere for noget af den funktionalitet som RFC'erne omhyggeligt
>>beskriver. Derved kommer de nemt til at overtræde RFC'erne, som for
>>manges vedkommende er skrevet før der var nutidens behov for firewalls
>>og virusfiltre. Men de overtræder dem jo kun når nogen sender pakker
>>eller breve (vira) som ingen har lov til at sende til de systemer.
>
>Men her er der jo ikke tale om at blokere for skadelig trafik, men
>derimod at nægte at afsende uskadelig, påkrævet trafik.
Øh? Her er vel tale om at blokere for trafik til porte som man ikke
ønsker trafik til. Trafikken behøver naturligvis ikke være skadelig,
men den er på den anden side ret oplagt ikke en fordel at modtage og
behandle.
>>Man kan have masser af negative meninger om den moderne "personlig
>>firewall"-industri og dens tilhørende skræmmekampagner, men jeg kan
>>ikke se noget særlig galt i at vælge en kort og markedsføringsegnet
>>betegnelse for det at en firewall dropper pakker uden svar.
>
>Kort betegnelse: DEFEKT.
Hvorfor? Hvis nogen forsøger at etablere en tcp-forbindelse udefra
til fx port 139 eller 23 på nogle af de servere eller firewalls jeg
administrerer, så får de ikke svar. Hvad skulle formålet med at svare
være?
Det blev i hvert fald en gang betragtet som god praksis at undlade at
svare, således at angriberen (for sådan én er det jo oftest) skulle
spilde tid på en timeout i stedet for straks at få negativt svar. Det
argument er muligvis ikke særlig væsentligt nu til dags (de har såmænd
nok programmel der bruger ventetiden til at sende pakker til nogle
andre), men det forekommer alligevel at være end noget argument jeg
har hørt for det modsatte.
>>Der findes absolut valide argumenter der taler imod brugen af
>>personlige firewalls og virusscannere; men at man ikke kan lide ordet
>>"stealth", og at de overtræder nogle RFC'er ved at ignorere en pakke
>>fra en script-kiddie, synes jeg er meget dårlige argumenter mod
>>anvendelsen af disse værktøjer.
>
>Det er jo ikke kun pakker fra en script-kiddie der bliver ignoreret.
Ikke udelukkende, nej, men det er kun pakker som ikke har noget at
gøre på det system (medmindre den er miskonfigureret - jeg forsvarer
naturligvis ikke folk der blokerer "Need fragmentation", men forventer
at kunne bruge tcp alligevel).
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kent Friis (28-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 28-09-03 10:05 |
|
Den Sun, 28 Sep 2003 03:58:04 +0200 skrev Jesper Dybdal:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>Den Sat, 27 Sep 2003 19:42:44 +0200 skrev Jesper Dybdal:
>>>Firewalls og virusfiltre har det til fælles at deres formål netop er
>>>at blokere for noget af den funktionalitet som RFC'erne omhyggeligt
>>>beskriver. Derved kommer de nemt til at overtræde RFC'erne, som for
>>>manges vedkommende er skrevet før der var nutidens behov for firewalls
>>>og virusfiltre. Men de overtræder dem jo kun når nogen sender pakker
>>>eller breve (vira) som ingen har lov til at sende til de systemer.
>>
>>Men her er der jo ikke tale om at blokere for skadelig trafik, men
>>derimod at nægte at afsende uskadelig, påkrævet trafik.
>
>Øh? Her er vel tale om at blokere for trafik til porte som man ikke
>ønsker trafik til. Trafikken behøver naturligvis ikke være skadelig,
>men den er på den anden side ret oplagt ikke en fordel at modtage og
>behandle.
Der er ingen der har kritiseret at blokere indgående trafik. Men hvis
man ikke ønsker at modtage en connection, SKAL der svares tilbage med
TCP Reset. Hvis en firewall nægter at afsende denne uskadelige,
påkrævede pakke, så er den defekt.
>>>Man kan have masser af negative meninger om den moderne "personlig
>>>firewall"-industri og dens tilhørende skræmmekampagner, men jeg kan
>>>ikke se noget særlig galt i at vælge en kort og markedsføringsegnet
>>>betegnelse for det at en firewall dropper pakker uden svar.
>>
>>Kort betegnelse: DEFEKT.
>
>Hvorfor? Hvis nogen forsøger at etablere en tcp-forbindelse udefra
>til fx port 139 eller 23 på nogle af de servere eller firewalls jeg
>administrerer, så får de ikke svar. Hvad skulle formålet med at svare
>være?
At de lader være.
>>>Der findes absolut valide argumenter der taler imod brugen af
>>>personlige firewalls og virusscannere; men at man ikke kan lide ordet
>>>"stealth", og at de overtræder nogle RFC'er ved at ignorere en pakke
>>>fra en script-kiddie, synes jeg er meget dårlige argumenter mod
>>>anvendelsen af disse værktøjer.
>>
>>Det er jo ikke kun pakker fra en script-kiddie der bliver ignoreret.
>
>Ikke udelukkende, nej, men det er kun pakker som ikke har noget at
>gøre på det system (medmindre den er miskonfigureret - jeg forsvarer
>naturligvis ikke folk der blokerer "Need fragmentation", men forventer
>at kunne bruge tcp alligevel).
Hvis man ikke ønsker at modtage connections, så bør man netop svare
tilbage med connection refused, alt andet er dårlig kundeservice.
Mvh
Kent
--
"Intelligence is the ability to avoid doing work, yet get the work done"
- Linus Torvalds
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 23:50 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>Hvis man ikke ønsker at modtage connections, så bør man netop svare
>tilbage med connection refused, alt andet er dårlig kundeservice.
De mennesker/maskiner der forsøger at lave forbindelser som jeg ikke
ønsker, til min maskine, er ikke mine kunder, og jeg skylder dem ingen
som helst service.
De er enten folk der har ramt forkert, folk der eksperimenterer for at
se hvordan min firewall reagerer, eller folk der forsøger at bryde ind
- i alle 3 tilfælde tager de ikke skade af at vente på en timeout, og
i det sidstnævnte tilfælde er det endda godt at de kommer til at
vente.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kent Friis (29-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-03 18:40 |
|
Den Mon, 29 Sep 2003 00:49:56 +0200 skrev Jesper Dybdal:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>Hvis man ikke ønsker at modtage connections, så bør man netop svare
>>tilbage med connection refused, alt andet er dårlig kundeservice.
>
>De mennesker/maskiner der forsøger at lave forbindelser som jeg ikke
>ønsker, til min maskine, er ikke mine kunder, og jeg skylder dem ingen
>som helst service.
Du bliver aldrig sælger.
Folk kan deles i to grupper: Nuværende kunder og potentielle kunder.
Mvh
Kent
--
NT er brugervenligt - det er bare brugerne der ikke kan finde ud af det
- en NT-administrator
| |
Jesper Dybdal (29-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 29-09-03 19:27 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>Den Mon, 29 Sep 2003 00:49:56 +0200 skrev Jesper Dybdal:
>>De mennesker/maskiner der forsøger at lave forbindelser som jeg ikke
>>ønsker, til min maskine, er ikke mine kunder, og jeg skylder dem ingen
>>som helst service.
>
>Du bliver aldrig sælger.
Det er i den grad korrekt.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kasper Dupont (27-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 27-09-03 20:18 |
|
Jesper Dybdal wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
> >De bruger ordet stealth, fordi det lyder bedre end at sige, at
> >der er tale om en firewall, der overtrædder RFC 792 og RFC 793.
>
> Jeg har ikke slået de RFC'er op, men jeg tror godt jeg kan gennemskue
> hvad du mener alligevel.
>
> Mener du generelt at der er noget galt i at bruge firewalls der
> overtræder dem?
Den må gerne overtræde dem, så længde den ikke bliver opdaget. Med
andre ord mener jeg, at en firewall naturligvis skal forhindre
nogle pakker i at komme ind og ud. Men set udefra skal nettet med
firewall som helhed overholde gældende standarder. Det vil sige,
at hvis firewallen unlader at slippe en pakke gennem, skal den i
stedet sende et passende svar tilbage.
>
> Det er også mit indtryk at ret mange af os netop i disse dage bliver
> forskånet for tusindvis af eksemplarer af Swen.A-virussen fordi nogle
> mailservere omhyggeligt undlader at overholde de RFC'er der ellers
> fortæller hvad en mailserver skal gøre.
Det må du gerne uddybe.
>
> men jeg kan
> ikke se noget særlig galt i at vælge en kort og markedsføringsegnet
> betegnelse for det at en firewall dropper pakker uden svar.
I det konkrete tilfælde er problemet overtrædelse af standarderne,
hvad det bliver kaldt for er jeg fuldstændigt lige glad med, bare
folk lader være. Mere generelt mener jeg faktisk at disse
markedsføringsrettede ord er til skade, for tit vil man så unlade
at fortælle, hvad de i virkeligheden dækker over. Jeg vil hellere
have en præcis og korrekt forklaring, som man kan forstå med
passende forudsætninger. Det vil til enhver tid være bedre, end en
buzzword forklaring, der i virkeligheden intet siger.
>
> Der findes absolut valide argumenter der taler imod brugen af
> personlige firewalls og virusscannere; men at man ikke kan lide ordet
> "stealth", og at de overtræder nogle RFC'er ved at ignorere en pakke
> fra en script-kiddie, synes jeg er meget dårlige argumenter mod
> anvendelsen af disse værktøjer.
Hvor mange argumenter skal du have for, at forkert brug af firewalls
er skadeligt?
- Firewalls kaserer også legitime pakker, ikke kun pakker, der
indgår i et angreb.
- Firewalls skaber problemer med timeouts og stalled connections.
- Firewalls gør det i nogle tilfælde nemmere at spoofe IP adresser.
- Og nogle firewalls gør det nemmere at lave DoS angreb.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Lars Kim Lund (27-09-2003)
| Kommentar
Fra : Lars Kim Lund |
Dato : 27-09-03 20:30 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>> Mener du generelt at der er noget galt i at bruge firewalls der
>> overtræder dem?
>
>Den må gerne overtræde dem, så længde den ikke bliver opdaget. Med
>andre ord mener jeg, at en firewall naturligvis skal forhindre
>nogle pakker i at komme ind og ud. Men set udefra skal nettet med
>firewall som helhed overholde gældende standarder. Det vil sige,
>at hvis firewallen unlader at slippe en pakke gennem, skal den i
>stedet sende et passende svar tilbage.
Hvorfor er det vigtigt?
Jeg har selv været i situationer hvor TCP RST var til større
forvirring end gavn, for jeg kan ikke se om det er en firewall der
RST'er eller om det er serveren jeg forsøger at ramme.
Hvis pakker simpelthen bliver droppet så er jeg ret sikker på at jeg
rammer et firewall-filter, da de fleste servere RST'er SYN's til porte
der ikke lytter.
--
Lars Kim Lund
http://www.net-faq.dk/
| |
Kent Friis (27-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-03 20:39 |
|
Den Sat, 27 Sep 2003 21:29:54 +0200 skrev Lars Kim Lund:
>Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
>>> Mener du generelt at der er noget galt i at bruge firewalls der
>>> overtræder dem?
>>
>>Den må gerne overtræde dem, så længde den ikke bliver opdaget. Med
>>andre ord mener jeg, at en firewall naturligvis skal forhindre
>>nogle pakker i at komme ind og ud. Men set udefra skal nettet med
>>firewall som helhed overholde gældende standarder. Det vil sige,
>>at hvis firewallen unlader at slippe en pakke gennem, skal den i
>>stedet sende et passende svar tilbage.
>
>Hvorfor er det vigtigt?
For ikke at ødelægge principperne bag internettet.
>Jeg har selv været i situationer hvor TCP RST var til større
>forvirring end gavn, for jeg kan ikke se om det er en firewall der
>RST'er eller om det er serveren jeg forsøger at ramme.
Det er heller ikke meningen at en udefra skal vide det. Hvis angriberen
kan se hvornår det er firewall'en der blokerer, og hvornår der er
serveren, så har han allerede en information om netværket. Han er
et skridt nærmere målet.
Mvh
Kent
--
"A computer is a state machine.
Threads are for people who can't program state machines."
- Alan Cox
| |
Lars Kim Lund (27-09-2003)
| Kommentar
Fra : Lars Kim Lund |
Dato : 27-09-03 20:49 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>>>Den må gerne overtræde dem, så længde den ikke bliver opdaget. Med
>>>andre ord mener jeg, at en firewall naturligvis skal forhindre
>>>nogle pakker i at komme ind og ud. Men set udefra skal nettet med
>>>firewall som helhed overholde gældende standarder. Det vil sige,
>>>at hvis firewallen unlader at slippe en pakke gennem, skal den i
>>>stedet sende et passende svar tilbage.
>>
>>Hvorfor er det vigtigt?
>
>For ikke at ødelægge principperne bag internettet.
På hvilken måde mener du det skader internettet at droppe uønskede
connections istedet for at resette dem?
>Det er heller ikke meningen at en udefra skal vide det. Hvis angriberen
>kan se hvornår det er firewall'en der blokerer, og hvornår der er
>serveren, så har han allerede en information om netværket. Han er
>et skridt nærmere målet.
Konkret var det noget extranet med et ret kompleks scenario med
forskellige translationer og firewalls mellem de to maskiner. Og i den
sammenhæng kan det være okay at have et kvalificeret bud på hvad der
går galt når man henvender sig til modpartens helpdesk.
Mere generelt kan man jo med lige så stor ret sige at en angriber ikke
kan se hvornår der blot ikke er en maskine eller hvornår en pakke
bliver droppet.
--
Lars Kim Lund
http://www.net-faq.dk/
| |
Kent Friis (27-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-03 21:03 |
|
Den Sat, 27 Sep 2003 21:49:11 +0200 skrev Lars Kim Lund:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>>>Den må gerne overtræde dem, så længde den ikke bliver opdaget. Med
>>>>andre ord mener jeg, at en firewall naturligvis skal forhindre
>>>>nogle pakker i at komme ind og ud. Men set udefra skal nettet med
>>>>firewall som helhed overholde gældende standarder. Det vil sige,
>>>>at hvis firewallen unlader at slippe en pakke gennem, skal den i
>>>>stedet sende et passende svar tilbage.
>>>
>>>Hvorfor er det vigtigt?
>>
>>For ikke at ødelægge principperne bag internettet.
>
>På hvilken måde mener du det skader internettet at droppe uønskede
>connections istedet for at resette dem?
Det skader internettet at folk ignorerer de standarder der gør at det
hele virker. Og jo flere der ignorerer standarderne, jo værre bliver
det. Indtil en dag der slet ikke er noget der kan kommunikere
længere.
>>Det er heller ikke meningen at en udefra skal vide det. Hvis angriberen
>>kan se hvornår det er firewall'en der blokerer, og hvornår der er
>>serveren, så har han allerede en information om netværket. Han er
>>et skridt nærmere målet.
>
>Konkret var det noget extranet med et ret kompleks scenario med
>forskellige translationer og firewalls mellem de to maskiner. Og i den
>sammenhæng kan det være okay at have et kvalificeret bud på hvad der
>går galt når man henvender sig til modpartens helpdesk.
>
>Mere generelt kan man jo med lige så stor ret sige at en angriber ikke
>kan se hvornår der blot ikke er en maskine eller hvornår en pakke
>bliver droppet.
Hvis der ingen maskine er, vil det typisk give ICMP host unreachable.
Det vil en firewall ikke.
Og hvis firewall'en blokerer alt trafik, er det både nemmere, billigere
og sikrere at trække netkablet helt ud. Altså skal der være åben for
nogen ting, fx port 80 for en webserver, og så skal der altså ikke
meget intelligens til at regne ud at når port 80 svarer, og alle andre
ikke gør, så er det ikke fordi der ikke er nogen maskine på det
ip-nummer.
Mvh
Kent
--
Demokrati er lige som den 29. februar - begge dele forekommer
en gang hver fjerde år.
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 02:58 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>Det skader internettet at folk ignorerer de standarder der gør at det
>hele virker.
Nu er formålet med en firewall jo netop at sikre at noget uønsket ikke
virker. At den derved bryder standarder som skal overholdes når man
ønsker at det virker, generer ikke mig.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kent Friis (28-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 28-09-03 10:19 |
|
Den Sun, 28 Sep 2003 03:58:10 +0200 skrev Jesper Dybdal:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>Det skader internettet at folk ignorerer de standarder der gør at det
>>hele virker.
>
>Nu er formålet med en firewall jo netop at sikre at noget uønsket ikke
>virker.
Men her snakker vi om at TCP/IP virker, og hvis TCP/IP er uønsket er det
billigere at trække netkablet ud, end at investere i en firewall.
Mvh
Kent
--
Object orientation: the idea, that humans find it easier to understand
"you.car.engine.start" than "start your car engine".
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 23:50 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>Den Sun, 28 Sep 2003 03:58:10 +0200 skrev Jesper Dybdal:
>>leeloo@phreaker.net (Kent Friis) wrote:
>>
>>>Det skader internettet at folk ignorerer de standarder der gør at det
>>>hele virker.
>>
>>Nu er formålet med en firewall jo netop at sikre at noget uønsket ikke
>>virker.
>
>Men her snakker vi om at TCP/IP virker, og hvis TCP/IP er uønsket er det
>billigere at trække netkablet ud, end at investere i en firewall.
Det mener du ikke er et seriøst argument, vel? Visse forbindeler er
uønskede, andre ikke.
Hvis tcp/ip ikke virker, så er det sjovt at jeg er i stand til at
poste detteher, ikke?
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kent Friis (29-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-03 18:43 |
|
Den Mon, 29 Sep 2003 00:49:58 +0200 skrev Jesper Dybdal:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>Den Sun, 28 Sep 2003 03:58:10 +0200 skrev Jesper Dybdal:
>>>leeloo@phreaker.net (Kent Friis) wrote:
>>>
>>>>Det skader internettet at folk ignorerer de standarder der gør at det
>>>>hele virker.
>>>
>>>Nu er formålet med en firewall jo netop at sikre at noget uønsket ikke
>>>virker.
>>
>>Men her snakker vi om at TCP/IP virker, og hvis TCP/IP er uønsket er det
>>billigere at trække netkablet ud, end at investere i en firewall.
>
>Det mener du ikke er et seriøst argument, vel?
Jo, et seriøst argument imod at overtræde standarderne. Du overtræder
en del af standarden for at øge(?) din sikkerhed, Microsoft overtræder
en anden del af standarden, for at få det til at se ud som om at IIS
er hurtigere end Apache, og snart er der ikke nogen der kan snakke
sammen længere.
>Hvis tcp/ip ikke virker, så er det sjovt at jeg er i stand til at
>poste detteher, ikke?
Det er nok fordi at newsserveren netop IKKE dropper dine pakker.
Mvh
Kent
--
Journalist: En der har forstand på at skrive artikler, men typisk
ikke på det artiklerne handler om.
| |
Klaus Ellegaard (29-09-2003)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 29-09-03 19:06 |
|
leeloo@phreaker.net (Kent Friis) writes:
>Jo, et seriøst argument imod at overtræde standarderne. Du overtræder
>en del af standarden for at øge(?) din sikkerhed, Microsoft overtræder
>en anden del af standarden, for at få det til at se ud som om at IIS
>er hurtigere end Apache, og snart er der ikke nogen der kan snakke
>sammen længere.
Hvis "noget" går i stykker på grund af manglende overholdelse,
er det, fordi dette "noget" er defekt: "Be Liberal in What You
Accept, and Conservative in What You Send".
Ordene er Jon Postels og indbefattet i RFC1123, der fortsætter:
Software should be written to deal with every conceivable
error, no matter how unlikely; sooner or later a packet will
come in with that particular combination of errors and
attributes, and unless the software is prepared, chaos can
ensue. In general, it is best to assume that the network is
filled with malevolent entities that will send in packets
designed to have the worst possible effect.
Igen - hvis "noget" ikke har taget højde for ovenstående, er det
rigeligt til, at man bør smide det ud med det samme.
Har Microsofts manglende overholdelse af et eller andet i øvrigt
betydet andet, end at de får Apache til at fremstå som langsom?
Virker Microsofts løsning set i lyset af ovenstående citat? Og i
så fald, hvad er problemet så?
Bevares, set ud fra et akademisk synspunkt er det ikke så flot,
men hvornår har verden nogensinde interesseret sig for teori?
Mvh.
Klaus.
| |
Kent Friis (29-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-03 20:24 |
|
Den Mon, 29 Sep 2003 18:05:44 +0000 (UTC) skrev Klaus Ellegaard:
>leeloo@phreaker.net (Kent Friis) writes:
>
>>Jo, et seriøst argument imod at overtræde standarderne. Du overtræder
>>en del af standarden for at øge(?) din sikkerhed, Microsoft overtræder
>>en anden del af standarden, for at få det til at se ud som om at IIS
>>er hurtigere end Apache, og snart er der ikke nogen der kan snakke
>>sammen længere.
>
>Hvis "noget" går i stykker på grund af manglende overholdelse,
>er det, fordi dette "noget" er defekt: "Be Liberal in What You
>Accept, and Conservative in What You Send".
Som jeg læser det, går det på fejl-håndtering (fx ikke noget med
buffer-overflows bare fordi en eller anden size ikke passer), og ikke
på at man skal være i stand til at forstå hvad modtageren mener,
uanset hvor non-standard pakken er.
>Har Microsofts manglende overholdelse af et eller andet i øvrigt
>betydet andet, end at de får Apache til at fremstå som langsom?
Ikke endnu. Apache's markedsandel er stadig for stor til at de kan
gå skridtet fuldt ud.
Den dag IIS har så stor markedsandel at MS vælger at droppe SYN-pakken,
holder Apache op med at virke. Uanset hvor meget man skal acceptere
trafik der mangler SYN-pakken, er der ingen der nogensinde vil påstå
at man skal være parat til at åbne en connection uden SYN.
(eksemplet er ikke kunstigt, det har faktisk været fremme på slashdot
et par gange at nogen havde konstateret at IE først forsøger uden
SYN, og IIS reagerer på dette. Om det så er en pålidelig kilde?
Tja... Men jeg ville ikke blive overrasket hvis det viste sig at passe).
Mvh
Kent
--
Object orientation: the idea, that humans find it easier to understand
"you.car.engine.start" than "start your car engine".
| |
Klaus Ellegaard (29-09-2003)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 29-09-03 21:13 |
|
leeloo@phreaker.net (Kent Friis) writes:
>buffer-overflows bare fordi en eller anden size ikke passer), og ikke
>på at man skal være i stand til at forstå hvad modtageren mener,
>uanset hvor non-standard pakken er.
"Liberal in what you accept" skal forstås sådan, at uanset hvilke
forkerte flag og andre fejl, der er sat, bør du forsøge at få det
til at virke. Dit udgangspunkt skal være, at det er vigtigere, at
det virker, end at det er rigtigt.
Man kunne sammenligne det med et lyskryds, der har en føler foran,
så det kan finde ud af, hvornår det skal skifte. Hastighedsgrænsen
er 50 km/t, men det betyder jo ikke, at man sætter føleren til ikke
at trigge, når en bil med fart på over 50,00000001 km/t nærmer sig.
Det er vigtigere, at systemet virker, end at bilen overholder de
gældende regler 100%.
[Nu med uden SYN]
>Om det så er en pålidelig kilde?
Hardly. Men det er da et interessant koncept. Det væsentlige er jo
også, at Microsoft - i følge det forelagte - overholder standarden
og får data igennem til Apache. Måske ikke i første hug. Men så i
andet.
Man kan i den forbindelse sige, at Unix-boksen overholder 1123 i
bedste stil: den første pakke forstår den ikke, men omvendt går den
ikke i stykker. Den anden forstår den, og alle er glade.
Jeg kan ikke se problemet hverken med den første eller anden pakke.
Mvh.
Klaus.
| |
Kent Friis (30-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 30-09-03 16:19 |
|
Den Mon, 29 Sep 2003 20:13:08 +0000 (UTC) skrev Klaus Ellegaard:
>leeloo@phreaker.net (Kent Friis) writes:
>
>>buffer-overflows bare fordi en eller anden size ikke passer), og ikke
>>på at man skal være i stand til at forstå hvad modtageren mener,
>>uanset hvor non-standard pakken er.
>
>"Liberal in what you accept" skal forstås sådan, at uanset hvilke
>forkerte flag og andre fejl, der er sat, bør du forsøge at få det
>til at virke. Dit udgangspunkt skal være, at det er vigtigere, at
>det virker, end at det er rigtigt.
>
>[Nu med uden SYN]
>>Om det så er en pålidelig kilde?
>
>Hardly. Men det er da et interessant koncept. Det væsentlige er jo
>også, at Microsoft - i følge det forelagte - overholder standarden
>og får data igennem til Apache. Måske ikke i første hug. Men så i
>andet.
Men det gælder jo kun sålænge at MS rent faktisk sender andet forsøg,
den dag de mener at IIS har stor nok markedsandel til at det bliver
Apache og ikke IE der får skylden hos uvidende brugere[1], kan man
sagtens forestille at IE vil holde op med at "downgrade" til
standard TCP.
>Man kan i den forbindelse sige, at Unix-boksen overholder 1123 i
>bedste stil: den første pakke forstår den ikke, men omvendt går den
>ikke i stykker. Den anden forstår den, og alle er glade.
Og dermed er vi tilbage ved "den crasher ikke, men den forsøger
heller ikke at forstå pakken".
Mvh
Kent
[1] Ligesom Netscape får skylden når den fortolker Frontpage-"HTML"
efter HTML-standarden, i stedet for IE-"standarden".
--
You haven't seen _multitasking_ until you've seen Railroad
Tycoon II and Unreal Tournament run side by side
| |
Klaus Ellegaard (30-09-2003)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 30-09-03 16:27 |
|
leeloo@phreaker.net (Kent Friis) writes:
>Men det gælder jo kun sålænge at MS rent faktisk sender andet forsøg,
>den dag de mener at IIS har stor nok markedsandel til at det bliver
>Apache og ikke IE der får skylden hos uvidende brugere[1], kan man
>sagtens forestille at IE vil holde op med at "downgrade" til
>standard TCP.
Hardly. Det vil nemt udvikle sig til en ny monopolsag.
Nu lader det også til, at hele beskyldningen er forkert, så
det gør jo ikke så meget i praksis.
Faktisk er der ret stor opbakning omkring overholdelse af de
væsentlige dele af RFC'erne: praktisk talt alting virker jo
sammen.
>[1] Ligesom Netscape får skylden når den fortolker Frontpage-"HTML"
>efter HTML-standarden, i stedet for IE-"standarden".
*shrug* HTML har jo aldrig været en standard. RFC'erne er
en best-effort-opsamling af det, man har samlet sammen af
eksisterende hjemmesider.
Det svarer til at lave en RFC for traceroute i dag og så
beskylde GNU for at modarbejde standarden med deres flere
år gamle udgave.
Mvh.
Klaus.
| |
Kent Friis (30-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 30-09-03 16:42 |
|
Den Tue, 30 Sep 2003 15:27:26 +0000 (UTC) skrev Klaus Ellegaard:
>leeloo@phreaker.net (Kent Friis) writes:
>
>>Men det gælder jo kun sålænge at MS rent faktisk sender andet forsøg,
>>den dag de mener at IIS har stor nok markedsandel til at det bliver
>>Apache og ikke IE der får skylden hos uvidende brugere[1], kan man
>>sagtens forestille at IE vil holde op med at "downgrade" til
>>standard TCP.
>
>Hardly. Det vil nemt udvikle sig til en ny monopolsag.
Og hvad skete der lige ved de sidste to? Ikke en sk*d.
>Nu lader det også til, at hele beskyldningen er forkert, så
>det gør jo ikke så meget i praksis.
Forkert ifølge en der ikke har set trafikken, men kun gætter.
>Faktisk er der ret stor opbakning omkring overholdelse af de
>væsentlige dele af RFC'erne: praktisk talt alting virker jo
>sammen.
Ja, men jo flere der ikke overholder RFC'erne, og jo flere der
argumentere for ikke at overholde RFC'erne, jo mindre vil virke
sammen.
>>[1] Ligesom Netscape får skylden når den fortolker Frontpage-"HTML"
>>efter HTML-standarden, i stedet for IE-"standarden".
>
>*shrug* HTML har jo aldrig været en standard. RFC'erne er
>en best-effort-opsamling af det, man har samlet sammen af
>eksisterende hjemmesider.
HTML er en W3C-standard.
>Det svarer til at lave en RFC for traceroute i dag og så
>beskylde GNU for at modarbejde standarden med deres flere
>år gamle udgave.
Selv nyeste IE har problemer med flere år gamle udgaver af
HTML-standarden.
Mvh
Kent
--
Journalist: En der har forstand på at skrive artikler, men typisk
ikke på det artiklerne handler om.
| |
Klaus Ellegaard (30-09-2003)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 30-09-03 18:11 |
|
leeloo@phreaker.net (Kent Friis) writes:
>>Hardly. Det vil nemt udvikle sig til en ny monopolsag.
>Og hvad skete der lige ved de sidste to? Ikke en sk*d.
Joda. Der er kommet væsentlige restriktioner på, hvad Microsoft
må - og i et mindre omfang skal der også betales iht. forliget.
>Ja, men jo flere der ikke overholder RFC'erne, og jo flere der
>argumentere for ikke at overholde RFC'erne, jo mindre vil virke
>sammen.
Jeg kender intet overhovedet, der ikke virker sammen med alt
andet på IP-niveau. Så snart man får applikationer ind i det,
begynder behovet at dale.
Mvh.
Klaus.
| |
Kent Friis (30-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 30-09-03 18:59 |
|
Den Tue, 30 Sep 2003 17:11:21 +0000 (UTC) skrev Klaus Ellegaard:
>leeloo@phreaker.net (Kent Friis) writes:
>
>>>Hardly. Det vil nemt udvikle sig til en ny monopolsag.
>
>>Og hvad skete der lige ved de sidste to? Ikke en sk*d.
>
>Joda. Der er kommet væsentlige restriktioner på, hvad Microsoft
>må - og i et mindre omfang skal der også betales iht. forliget.
Første gang kom der den restriktion at de ikke måtte bundle IE med
windows. Hvor meget var den restriktion lige bevendt?
At de så måske har fået nogen nye forbud at ignorere, hvad kan man bruge
det itl?
>>Ja, men jo flere der ikke overholder RFC'erne, og jo flere der
>>argumentere for ikke at overholde RFC'erne, jo mindre vil virke
>>sammen.
>
>Jeg kender intet overhovedet, der ikke virker sammen med alt
>andet på IP-niveau. Så snart man får applikationer ind i det,
>begynder behovet at dale.
Det er heller ikke blevet så slemt med non-standard ting på ip-niveau
endnu, det er faktisk kun firewalls der er problemet.
Og jeg har nævnt et par eksempler på firewalls der blokerer pakker i
strid med TCP/IP standarderne, så nogen kunder ikke kan connecte.
Mvh
Kent
--
Object orientation: the idea, that humans find it easier to understand
"you.car.engine.start" than "start your car engine".
| |
Kasper Dupont (30-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 30-09-03 15:18 |
|
Kent Friis wrote:
>
> (eksemplet er ikke kunstigt, det har faktisk været fremme på slashdot
> et par gange at nogen havde konstateret at IE først forsøger uden
> SYN, og IIS reagerer på dette. Om det så er en pålidelig kilde?
> Tja... Men jeg ville ikke blive overrasket hvis det viste sig at passe).
Den historie har jeg læst. Jeg har ikke undersøgt det i detaljer,
men det blev påpeget, at personen der skrev historien nok ikke
havde forstået HTTP/1.1 godt nok. Det er lovligt at holde en HTTP
forbindelse åben og sende flere requests. Sagen er blot den, at
det ikke er korrekt implementeret i IE. Det har ført til, at det
er almindelig praksis, at apache servere er sat op til at nægte
at bruge den feature med IE klienter.
Hvad IE helt præcis gør, hvis serveren ikke vil være med til
keep-alive ved jeg ikke. Men jeg tvivler på, at både IE og IIS
omgår TCP standarden, som burde være implementeret på et niveau,
hvor de slet ikke kan få fingrene i den. Og hvis man endelig
prøver på at implementere TCP uden three-way handshake får man
nok også nogle sårbarheder som f.eks. SYN flood lignende DoS
angreb.
Jeg har læst om en standard der hedder noget i retning af T/TCP,
som vist nok er et forsøg på at skære et roundtrip eller to af
en TCP session. Jeg kender ikke detaljerne, og jeg ved ikke, om
den kan bruges til HTTP.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Kent Friis (30-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 30-09-03 16:27 |
|
Den Tue, 30 Sep 2003 16:18:09 +0200 skrev Kasper Dupont:
>Kent Friis wrote:
>>
>> (eksemplet er ikke kunstigt, det har faktisk været fremme på slashdot
>> et par gange at nogen havde konstateret at IE først forsøger uden
>> SYN, og IIS reagerer på dette. Om det så er en pålidelig kilde?
>> Tja... Men jeg ville ikke blive overrasket hvis det viste sig at passe).
>
>Den historie har jeg læst. Jeg har ikke undersøgt det i detaljer,
>men det blev påpeget, at personen der skrev historien nok ikke
>havde forstået HTTP/1.1 godt nok.
Personen selv påpegede at han udemærket vidste hvad HTTP pipelining
var, og det ikke var det der var tale om, men nye connections der
blev startet uden SYN.
Men som sagt... Om det så er en pålidelig kilde? Tja...
>Hvad IE helt præcis gør, hvis serveren ikke vil være med til
>keep-alive ved jeg ikke. Men jeg tvivler på, at både IE og IIS
>omgår TCP standarden, som burde være implementeret på et niveau,
>hvor de slet ikke kan få fingrene i den.
Det kan de ikke på en *nix, men husk på at MS efterhånden har
integreret alt i OS'et.
Jeg havde en overgang problemer med at bruge Terminal Services over VPN,
da fragmenterede pakker resulterede i RST. Normalt er RST et svar fra
TCP-stakken, og ikke fra userspace, og da andre programmer ikke havde
problemet, tyder det IMHO i retning af at Terminal Services bruger
sin egen TCP-stak.
Hvis TS kan have sin egen TCP-stak, kan IE og IIS også.
>Og hvis man endelig
>prøver på at implementere TCP uden three-way handshake får man
>nok også nogle sårbarheder som f.eks. SYN flood lignende DoS
>angreb.
Nu er det jo Microsoft vi taler om, det firma er berygtet for at enten
ved de intet om sikkerhed, eller også er de ligeglade.
>Jeg har læst om en standard der hedder noget i retning af T/TCP,
>som vist nok er et forsøg på at skære et roundtrip eller to af
>en TCP session. Jeg kender ikke detaljerne, og jeg ved ikke, om
>den kan bruges til HTTP.
Det var vist det der var ideen (jeg har også læst om den), og
beskrivelsen af IE's opførsel lignede faktisk et forsøg på at
implementere denne protokol, bare som en del af protokol 6.
Mvh
Kent
--
6.0 FDiv 3.0 = 1.999773462873 - Intel Pentium bug
| |
Jesper Dybdal (30-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 30-09-03 18:55 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>Kent Friis wrote:
>>
>> (eksemplet er ikke kunstigt, det har faktisk været fremme på slashdot
>> et par gange at nogen havde konstateret at IE først forsøger uden
>> SYN, og IIS reagerer på dette. Om det så er en pålidelig kilde?
>> Tja... Men jeg ville ikke blive overrasket hvis det viste sig at passe).
>
>Den historie har jeg læst. Jeg har ikke undersøgt det i detaljer,
>men ...
Tak for den udmærkede forklaring. Min IE under Win2000 sender de
nydeligste SYN-pakker som det første når man giver den en URL, så jeg
forstod ikke helt hvad det handlede om.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kent Friis (30-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 30-09-03 19:00 |
|
Den Tue, 30 Sep 2003 19:54:46 +0200 skrev Jesper Dybdal:
>Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
>>Kent Friis wrote:
>>>
>>> (eksemplet er ikke kunstigt, det har faktisk været fremme på slashdot
>>> et par gange at nogen havde konstateret at IE først forsøger uden
>>> SYN, og IIS reagerer på dette. Om det så er en pålidelig kilde?
>>> Tja... Men jeg ville ikke blive overrasket hvis det viste sig at passe).
>>
>>Den historie har jeg læst. Jeg har ikke undersøgt det i detaljer,
>>men ...
>
>Tak for den udmærkede forklaring. Min IE under Win2000 sender de
>nydeligste SYN-pakker som det første når man giver den en URL, så jeg
>forstod ikke helt hvad det handlede om.
Historien er heller ikke bekræftet af en uafhængig kilde. Jeg ville
have checket med Ethereal på arbejdet, men glemte det.
Mvh
Kent
--
Linux 0.12 is out
Windows 2003 is now obsolete!!!
| |
Asbjorn Hojmark (30-09-2003)
| Kommentar
Fra : Asbjorn Hojmark |
Dato : 30-09-03 23:10 |
|
On Mon, 29 Sep 2003 19:23:36 +0000 (UTC), leeloo@phreaker.net
(Kent Friis) wrote:
> (eksemplet er ikke kunstigt, det har faktisk været fremme på slashdot
> et par gange at nogen havde konstateret at IE først forsøger uden
> SYN, og IIS reagerer på dette. Om det så er en pålidelig kilde?
Det passer ikke med, hvad jeg har observeret, og det tager ca. 30
sekunder at afvise det med et sniffer-trace.
-A
--
http://www.hojmark.org/
| |
Kasper Dupont (27-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 27-09-03 21:34 |
|
Lars Kim Lund wrote:
>
> På hvilken måde mener du det skader internettet at droppe uønskede
> connections istedet for at resette dem?
Du forårsager unødvendige ventetider og mere trafik på nettet.
Desuden gør du fejlfinding svære, mens du gør det nemmere for
andre at spoofe din IP adresse.
>
> Mere generelt kan man jo med lige så stor ret sige at en angriber ikke
> kan se hvornår der blot ikke er en maskine eller hvornår en pakke
> bliver droppet.
Burde afsenderen ikke se en ICMP host-unreachable pakke, hvis
der ikke er en maskine på adressen, eller hvis maskinen er
slukket?
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Lars Kim Lund (27-09-2003)
| Kommentar
Fra : Lars Kim Lund |
Dato : 27-09-03 21:54 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>> Mere generelt kan man jo med lige så stor ret sige at en angriber ikke
>> kan se hvornår der blot ikke er en maskine eller hvornår en pakke
>> bliver droppet.
>
>Burde afsenderen ikke se en ICMP host-unreachable pakke, hvis
>der ikke er en maskine på adressen, eller hvis maskinen er
>slukket?
ICMP unreachables bliver svjh sendt af routere hvis den ikke kender
routen eller på anden vis ikke kan aflevere pakken. Det er muligt
nogle routere også sender unreachable tilbage hvis den ikke kan ARP'e
hosten, men det mener jeg ikke er standard, eller tilsigtet i RFC 792.
X-postet til dk.edb.netvaerk.stort, da der formentlig er nogle
routerfolk der, der ved en del mere om det end mig.
--
Lars Kim Lund
http://www.net-faq.dk/
| |
Kent Friis (27-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 27-09-03 23:04 |
|
Den Sat, 27 Sep 2003 22:54:24 +0200 skrev Lars Kim Lund:
>Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
>>> Mere generelt kan man jo med lige så stor ret sige at en angriber ikke
>>> kan se hvornår der blot ikke er en maskine eller hvornår en pakke
>>> bliver droppet.
>>
>>Burde afsenderen ikke se en ICMP host-unreachable pakke, hvis
>>der ikke er en maskine på adressen, eller hvis maskinen er
>>slukket?
>
>ICMP unreachables bliver svjh sendt af routere hvis den ikke kender
>routen eller på anden vis ikke kan aflevere pakken. Det er muligt
>nogle routere også sender unreachable tilbage hvis den ikke kan ARP'e
>hosten, men det mener jeg ikke er standard, eller tilsigtet i RFC 792.
Det er ikke usædvanligt at få ICMP host unreachable, når en router
ikke får svar på ARP. Om det er standard ved jeg faktisk ikke, men
jeg har set det fra Cisco og/eller Linux maskiner.
Hvis den ikke kender routen, bør det være ICMP network unreachable, da
man normalt har en route til et netværk, ikke til hver enkelt host.
Mvh
Kent
--
At køre i en stor Mercedes eller BMW viser ikke at man har mange penge.
Det viser blot at man er tysker.
| |
Kasper Dupont (27-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 27-09-03 23:08 |
|
Lars Kim Lund wrote:
>
> ICMP unreachables bliver svjh sendt af routere hvis den ikke kender
> routen eller på anden vis ikke kan aflevere pakken. Det er muligt
> nogle routere også sender unreachable tilbage hvis den ikke kan ARP'e
> hosten, men det mener jeg ikke er standard, eller tilsigtet i RFC 792.
Er det ikke det man har forskellige unreachable beskeder til?
Som jeg forstår Destination Unreachable er det kode 0, hvis
der ikke er en route til destinationen og kode 1 hvis det
rigtige subnet nås, men der ikke kommer svar på ARP
forespørgslen.
Der er en ting, jeg undrer mig over. Der står, at ICMP er
et krav, altså enhver IP implementation *skal* implementere
ICMP. Men det eneste sted, hvor der faktisk er et krav om,
at man sender en ICMP pakke er echo reply. En echo pakke
skal besvares med en echo reply pakke. Med alle ICMP
fejlmeldingerne står der blot, at routeren *må* sende en
fejlmelding tilbage, aldrig at den skal.
Det er rimeligt nok, at en router ikke skal sende en pakke
tilbage hvis der er congestion. Men hvorfor står der ikke
noget om hvornår en router bør sende svar pakker i tilfælde
af fejl?
Så det er tilsyneladende kun echo reply og TCP RST pakkerne,
der skal sendes tilbage. Jeg synes egentlig det er lidt
underligt, at man som jeg læser det gerne må sende både en
TCP RST pakke og en ICMP port unreachable som svar på en
lukket TCP port.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Lars Kim Lund (27-09-2003)
| Kommentar
Fra : Lars Kim Lund |
Dato : 27-09-03 23:24 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>> ICMP unreachables bliver svjh sendt af routere hvis den ikke kender
>> routen eller på anden vis ikke kan aflevere pakken. Det er muligt
>> nogle routere også sender unreachable tilbage hvis den ikke kan ARP'e
>> hosten, men det mener jeg ikke er standard, eller tilsigtet i RFC 792.
>
>Er det ikke det man har forskellige unreachable beskeder til?
>Som jeg forstår Destination Unreachable er det kode 0, hvis
>der ikke er en route til destinationen og kode 1 hvis det
>rigtige subnet nås, men der ikke kommer svar på ARP
>forespørgslen.
RFC792 skriver: "Codes 0, 1, 4, and 5 may be received from a gateway.
Codes 2 and 3 may be received from a host."
Læg mærke til valget af "may".
>Så det er tilsyneladende kun echo reply og TCP RST pakkerne,
>der skal sendes tilbage. Jeg synes egentlig det er lidt
>underligt, at man som jeg læser det gerne må sende både en
>TCP RST pakke og en ICMP port unreachable som svar på en
>lukket TCP port.
Jeg mener at RST er en permanent fejl og ICMP er en "soft error". Dvs.
en graduering mellem "Permanent fejl, prøv IKKE igen" og "Midlertidig
fejl, prøv igen senere".
--
Lars Kim Lund
http://www.net-faq.dk/
| |
Kent Friis (28-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 28-09-03 10:00 |
|
Den Sun, 28 Sep 2003 00:24:13 +0200 skrev Lars Kim Lund:
>Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
>>> ICMP unreachables bliver svjh sendt af routere hvis den ikke kender
>>> routen eller på anden vis ikke kan aflevere pakken. Det er muligt
>>> nogle routere også sender unreachable tilbage hvis den ikke kan ARP'e
>>> hosten, men det mener jeg ikke er standard, eller tilsigtet i RFC 792.
>>
>>Er det ikke det man har forskellige unreachable beskeder til?
>>Som jeg forstår Destination Unreachable er det kode 0, hvis
>>der ikke er en route til destinationen og kode 1 hvis det
>>rigtige subnet nås, men der ikke kommer svar på ARP
>>forespørgslen.
>
>RFC792 skriver: "Codes 0, 1, 4, and 5 may be received from a gateway.
>Codes 2 and 3 may be received from a host."
Det er også routeren der sender svar om at hosten ikke svarer på ARP,
det kan hosten ikke.
>Læg mærke til valget af "may".
Ja, men når man er igang med at scanne et subnet, og får:
1.1.1.1: Host unreachable
1.1.1.2: Host unreachable
1.1.1.3: Host unreachable
1.1.1.4: Timeout
1.1.1.5: Host unreachable
så er det nemt at gætte sig til hvor maskinen sidder, og dermed er
den ikke skjult. At det så er et absolut krav at routeren skal sende
Host unreachable gør kun en forskel i det tilfælde at man støder på
en router der ikke gør det.
>>Så det er tilsyneladende kun echo reply og TCP RST pakkerne,
>>der skal sendes tilbage. Jeg synes egentlig det er lidt
>>underligt, at man som jeg læser det gerne må sende både en
>>TCP RST pakke og en ICMP port unreachable som svar på en
>>lukket TCP port.
>
>Jeg mener at RST er en permanent fejl og ICMP er en "soft error". Dvs.
>en graduering mellem "Permanent fejl, prøv IKKE igen" og "Midlertidig
>fejl, prøv igen senere".
Ved UDP har man kun Port unreachable, så sådan kan du IMHO ikke skelne.
Iøvrigt får man også RST "Connection refused" i det kvarte sekund det
tager at genstarte httpd.
Mvh
Kent
--
You haven't seen _multitasking_ until you've seen Doom and
Quake run side by side
| |
Lars Kim Lund (28-09-2003)
| Kommentar
Fra : Lars Kim Lund |
Dato : 28-09-03 10:05 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>så er det nemt at gætte sig til hvor maskinen sidder, og dermed er
>den ikke skjult. At det så er et absolut krav at routeren skal sende
>Host unreachable gør kun en forskel i det tilfælde at man støder på
>en router der ikke gør det.
Hvor står det at det er et absolut krav?
--
Lars Kim Lund
http://www.net-faq.dk/
| |
Kent Friis (28-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 28-09-03 10:23 |
|
Den Sun, 28 Sep 2003 11:04:42 +0200 skrev Lars Kim Lund:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>så er det nemt at gætte sig til hvor maskinen sidder, og dermed er
>>den ikke skjult. At det så er et absolut krav at routeren skal sende
>>Host unreachable gør kun en forskel i det tilfælde at man støder på
>>en router der ikke gør det.
>
>Hvor står det at det er et absolut krav?
Ups, tastefejl.
"At det så IKKE er et absolut krav".
Utroligt så meget skade et glemt ord kan gøre 
Mvh
Kent
--
The frozen north will hatch a flightless bird,
who will spread his wings and dominate the earth
And cause an empire by the sea to fall
To the astonishment, and delight of all.
| |
Kasper Dupont (28-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 28-09-03 10:20 |
|
Lars Kim Lund wrote:
>
> Læg mærke til valget af "may".
Jeg har bemærket, at de ikke er påkrævet. Det er kun RST og
echo-reply, der er påkrævet.
>
> >Så det er tilsyneladende kun echo reply og TCP RST pakkerne,
> >der skal sendes tilbage. Jeg synes egentlig det er lidt
> >underligt, at man som jeg læser det gerne må sende både en
> >TCP RST pakke og en ICMP port unreachable som svar på en
> >lukket TCP port.
>
> Jeg mener at RST er en permanent fejl og ICMP er en "soft error". Dvs.
> en graduering mellem "Permanent fejl, prøv IKKE igen" og "Midlertidig
> fejl, prøv igen senere".
En RST pakke kan også indikere et midlertidigt problem. Hvis den
server process, der skal tage imod ikke kører i øjeblikket får du
en RST pakke. Det er mig bekendt almindelig praksis, at f.eks.
mailservere prøver igen, hvis de får en RST pakke fra modtagerens
server.
En ICMP port unreacable pakke sendt som svar på en UDP pakke er
nøjagtig lige så permenent/temporær som en RST pakke sendt som
svar på en TCP SYN pakke. De har faktisk nøjagtigt samme
betydning, nemlig at der ikke i øjeblikket er et program, der
lytter på porten.
Det jeg spekulerer over er, at standarden åbenbart tillader at
man sender en port unreacable pakke som svar på en TCP SYN. Er
der overhovedet nogen implementation, der gør det? Man skal jo
stadig også sende en RST pakke, og at sende to pakker som svar på
en enkelt SYN pakke giver jo ikke meget mening.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 02:58 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>> Det er også mit indtryk at ret mange af os netop i disse dage bliver
>> forskånet for tusindvis af eksemplarer af Swen.A-virussen fordi nogle
>> mailservere omhyggeligt undlader at overholde de RFC'er der ellers
>> fortæller hvad en mailserver skal gøre.
>
>Det må du gerne uddybe.
De mailservere jeg driver, bortkaster i disse dage alle breve som
indeholder Swen.A-virussen (eller et andet binært attachment der
tilfældigvis har præcis den linje jeg matcher på). Kun i loggen røber
de at det er sket.
Det er utvivlsomt i modstrid med reglerne for hvordan MTA'er "skal"
opføre sig, at smide breve væk. Men det er særdeles hensigtsmæssigt -
det har sparet mig for over 3000 eksemplarer af enten virussen (à ca.
150 kB = ca. 450 MB) eller beskeder fra en virusscanner.
Og det at jeg ikke bouncer dem, har sparet nogle formodentlig
forfalskede afsenderadresser for i alt over 3000 bounces.
Og jeg er ikke den eneste der gør sådan. Jeg vil påstå at det er
fornuftigt og normalt, og at standarderne bare ikke har taget højde
for eksistensen af den slags vira.
>Jeg vil hellere
>have en præcis og korrekt forklaring, som man kan forstå med
>passende forudsætninger. Det vil til enhver tid være bedre, end en
>buzzword forklaring, der i virkeligheden intet siger.
Helt enig. Men at nogen bruger et dumt ord for begrebet gør ikke
selve begrebet dårligt. Og en kamp mod marketing-valgte termer
generelt er vist tabt på forhånd.
>Hvor mange argumenter skal du have for, at forkert brug af firewalls
>er skadeligt?
>
>- Firewalls kaserer også legitime pakker, ikke kun pakker, der
> indgår i et angreb.
Efter mine begreber er pakker til porte som jeg ikke ønsker at levere
service på, ikke legitime. De kan være et angreb eller et tilfældigt
uheld - i begge tilfælde føler jeg intet ansvar for at svare på dem.
>- Firewalls skaber problemer med timeouts og stalled connections.
Ja, men kun for dem der sender pakker som ifølge min opfattelse, jf.
forrige punkt, ikke er legitime. Det betragter jeg som en fordel.
>- Firewalls gør det i nogle tilfælde nemmere at spoofe IP adresser.
Det er korrekt. En RST kan ødelægge spoofingen. Men problemet med
spoofede pakker er meget lille når de smides væk ubehandlet.
>- Og nogle firewalls gør det nemmere at lave DoS angreb.
Ved at smide pakker sporløst væk? Det forstår jeg vist ikke.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Christian Andersen (28-09-2003)
| Kommentar
Fra : Christian Andersen |
Dato : 28-09-03 08:47 |
|
Jesper Dybdal wrote:
> Det er utvivlsomt i modstrid med reglerne for hvordan MTA'er "skal"
> opføre sig, at smide breve væk.
Det er faktisk korrekt. Jeg var af den opfattelse at SMTP-servere kun
skulle lave en "best-effort" for at aflevere mail, men nej:
http://www.ietf.org/rfc/rfc2821.txt
6.1 Reliable Delivery and Replies by Email
[...]
If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message.
--
Party time, excellent, wiuuuu, wiuuuu, wiuuuuuuu!!!
| |
Lars Kim Lund (28-09-2003)
| Kommentar
Fra : Lars Kim Lund |
Dato : 28-09-03 08:58 |
|
Christian Andersen <zv856hm02@sneakemail.com> wrote:
>> Det er utvivlsomt i modstrid med reglerne for hvordan MTA'er "skal"
>> opføre sig, at smide breve væk.
>
>Det er faktisk korrekt. Jeg var af den opfattelse at SMTP-servere kun
>skulle lave en "best-effort" for at aflevere mail, men nej:
Det giver også god mening. Eller det gav i hvert fald god mening før
spamming og virus gjorde det så udbredt med falske adresser.
Men man skal tænke sig meget godt om, før man begynder at smide mail
væk efter at man har accepteret den i SMTP sessionen uden at advicere
hverken afsender eller den tiltænkte modtager.
--
Lars Kim Lund
http://www.net-faq.dk/
| |
Christian Andersen (28-09-2003)
| Kommentar
Fra : Christian Andersen |
Dato : 28-09-03 10:01 |
|
Lars Kim Lund wrote:
>>> Det er utvivlsomt i modstrid med reglerne for hvordan MTA'er "skal"
>>> opføre sig, at smide breve væk.
>>Det er faktisk korrekt. Jeg var af den opfattelse at SMTP-servere kun
>>skulle lave en "best-effort" for at aflevere mail, men nej:
> Det giver også god mening. Eller det gav i hvert fald god mening før
> spamming og virus gjorde det så udbredt med falske adresser.
Ja det gør.
> Men man skal tænke sig meget godt om, før man begynder at smide mail
> væk efter at man har accepteret den i SMTP sessionen uden at advicere
> hverken afsender eller den tiltænkte modtager.
Helt klart.
--
Party time, excellent, wiuuuu, wiuuuu, wiuuuuuuu!!!
| |
Bertel Lund Hansen (28-09-2003)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 28-09-03 09:01 |
|
Christian Andersen skrev:
>Det er faktisk korrekt. Jeg var af den opfattelse at SMTP-servere kun
>skulle lave en "best-effort" for at aflevere mail, men nej:
> If there is a delivery failure after acceptance of a message [...]
Man kan argumentere for at det ikke er en failure når man
omhyggeligt selv smider mailen i bitspanden.
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
| |
Christian Andersen (28-09-2003)
| Kommentar
Fra : Christian Andersen |
Dato : 28-09-03 09:59 |
|
Bertel Lund Hansen wrote:
>> Det er faktisk korrekt. Jeg var af den opfattelse at SMTP-servere kun
>> skulle lave en "best-effort" for at aflevere mail, men nej:
>> If there is a delivery failure after acceptance of a message [...]
> Man kan argumentere for at det ikke er en failure når man
> omhyggeligt selv smider mailen i bitspanden.
Nøøøh. Gyldendals Røde skriver (bl.a) om failure: svigtende bestræbelse,
og jeg er ret sikker på at det er sådan ordet skal opfattes i RFC2821.
Der er en bestræbelse (svaret 200 OK er givet i SMTP-dialogen) på at
aflevere mailen til den tilsigtede modtager, men det svigter (af en
eller anden grund) og derfor skal der sendes en fejlrapport.
Se også:
http://dictionary.reference.com/search?q=failure
--
Party time, excellent, wiuuuu, wiuuuu, wiuuuuuuu!!!
| |
Kent Friis (28-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 28-09-03 10:17 |
|
Den Sun, 28 Sep 2003 03:58:08 +0200 skrev Jesper Dybdal:
>
>>- Firewalls gør det i nogle tilfælde nemmere at spoofe IP adresser.
>
>Det er korrekt. En RST kan ødelægge spoofingen. Men problemet med
>spoofede pakker er meget lille når de smides væk ubehandlet.
At *du* smider dem væk ubehandlet, gør ikke problemet meget lille, når
nogen forsøger at spoofe *dit* ip-nummer. Det er jo netop ikke trafik
der bliver sendt til dig, når folk lader som om de er dig, men
derimod trafik der bliver sendt fx til din bank. Og din bank smider
nok ikke trafik væk der ser ud til at komme fra dig.
Mvh
Kent
--
6.0 FDiv 3.0 = 1.999773462873 - Intel Pentium bug
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 23:50 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>Den Sun, 28 Sep 2003 03:58:08 +0200 skrev Jesper Dybdal:
>>
>>>- Firewalls gør det i nogle tilfælde nemmere at spoofe IP adresser.
>>
>>Det er korrekt. En RST kan ødelægge spoofingen. Men problemet med
>>spoofede pakker er meget lille når de smides væk ubehandlet.
>
>At *du* smider dem væk ubehandlet, gør ikke problemet meget lille, når
>nogen forsøger at spoofe *dit* ip-nummer. Det er jo netop ikke trafik
>der bliver sendt til dig, når folk lader som om de er dig, men
>derimod trafik der bliver sendt fx til din bank. Og din bank smider
>nok ikke trafik væk der ser ud til at komme fra dig.
Du har ret. Altså teoretisk set: hvis hele IP-adresserummet havde den
egenskab at pakker til enhver IP-adresse gav en eller anden form for
svar, så ville spoofing være sværere.
Men det har ikke ret meget med den reelle verden at gøre, synes jeg.
Der er masser af IP-adresser man kan bruge hvis man ønsker at spoofe
en adresse som ikke svarer.
Udover de ikke-tildelte adresser (som man jo kan filtrere på hvis man
gider) kan jeg da fx nævne at en almindelig TDC ADSL-opkobling med
slukket ADSL-modem ikke giver nogen som helst form for reaktion på
SYN-pakker man sender til den (jeg har lige prøvet det på min
sommerhus-ADSL, som er slukket).
Min holdning til spoofing er i øvrigt at det kan og bør løses ved at
(alle) udbydere har filtre der hindrer deres kunder i at spoofe. Jeg
ved godt at det nok varer lidt før de alle gør det ...
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kasper Dupont (29-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 29-09-03 05:59 |
|
Jesper Dybdal wrote:
>
> Min holdning til spoofing er i øvrigt at det kan og bør løses ved at
> (alle) udbydere har filtre der hindrer deres kunder i at spoofe. Jeg
> ved godt at det nok varer lidt før de alle gør det ...
Min fornemmelse er, at min opkobling er blevet mere ustabil efter
min udbyder indførte den slags filtrering.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Jesper Dybdal (29-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 29-09-03 19:17 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>Jesper Dybdal wrote:
>>
>> Min holdning til spoofing er i øvrigt at det kan og bør løses ved at
>> (alle) udbydere har filtre der hindrer deres kunder i at spoofe. Jeg
>> ved godt at det nok varer lidt før de alle gør det ...
>
>Min fornemmelse er, at min opkobling er blevet mere ustabil efter
>min udbyder indførte den slags filtrering.
Det lyder forbavsende. Min udbyder (TDC) har da vist haft den slags
filtrering i meget lang tid, og de TDC-opkoblinger jeg kender til,
virker helt upåklageligt.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kasper Dupont (30-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 30-09-03 15:20 |
|
Jesper Dybdal wrote:
>
> Det lyder forbavsende. Min udbyder (TDC) har da vist haft den slags
> filtrering i meget lang tid, og de TDC-opkoblinger jeg kender til,
> virker helt upåklageligt.
Da jeg fik en opkobling hos TDC for to år siden var der
i begyndelsen ingen filtrering af nogen slags.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Jesper Dybdal (30-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 30-09-03 18:55 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>Jesper Dybdal wrote:
>>
>> Det lyder forbavsende. Min udbyder (TDC) har da vist haft den slags
>> filtrering i meget lang tid, og de TDC-opkoblinger jeg kender til,
>> virker helt upåklageligt.
>
>Da jeg fik en opkobling hos TDC for to år siden var der
>i begyndelsen ingen filtrering af nogen slags.
Jeg har på en eller anden vis fået indtryk af at der var
spoofing-filtrering allerede omkring det tidspunkt jeg fik min ADSL,
hvilket var efteråret 2000. Men jeg kan ikke finde dokumentation for
det (X-No-Archive er noget irriterende bras, når Google nu ellers er
så fremragende til den slags), så hvis du er rimelig sikker på det, så
har du jo nok ret alligevel.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kasper Dupont (01-10-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 01-10-03 06:27 |
|
Jesper Dybdal wrote:
>
> Jeg har på en eller anden vis fået indtryk af at der var
> spoofing-filtrering allerede omkring det tidspunkt jeg fik min ADSL,
> hvilket var efteråret 2000.
Der kan nemt have været forskel på deres linier baseret på hhv.
ADSL og kabeltv. Det ville i så fald være langt fra den eneste
forskel.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Kent Friis (29-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-03 18:50 |
|
Den Mon, 29 Sep 2003 00:49:59 +0200 skrev Jesper Dybdal:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>Den Sun, 28 Sep 2003 03:58:08 +0200 skrev Jesper Dybdal:
>>>
>>>>- Firewalls gør det i nogle tilfælde nemmere at spoofe IP adresser.
>>>
>>>Det er korrekt. En RST kan ødelægge spoofingen. Men problemet med
>>>spoofede pakker er meget lille når de smides væk ubehandlet.
>>
>>At *du* smider dem væk ubehandlet, gør ikke problemet meget lille, når
>>nogen forsøger at spoofe *dit* ip-nummer. Det er jo netop ikke trafik
>>der bliver sendt til dig, når folk lader som om de er dig, men
>>derimod trafik der bliver sendt fx til din bank. Og din bank smider
>>nok ikke trafik væk der ser ud til at komme fra dig.
>
>Du har ret. Altså teoretisk set: hvis hele IP-adresserummet havde den
>egenskab at pakker til enhver IP-adresse gav en eller anden form for
>svar, så ville spoofing være sværere.
>
>Men det har ikke ret meget med den reelle verden at gøre, synes jeg.
>Der er masser af IP-adresser man kan bruge hvis man ønsker at spoofe
>en adresse som ikke svarer.
Ofte er det ikke interessant blot at spoofe en adresse der ikke svarer.
Man ønsker at spoofe et ip-nummer der har adgang til et system, for
selv at få adgang.
>Udover de ikke-tildelte adresser (som man jo kan filtrere på hvis man
>gider) kan jeg da fx nævne at en almindelig TDC ADSL-opkobling med
>slukket ADSL-modem ikke giver nogen som helst form for reaktion på
>SYN-pakker man sender til den (jeg har lige prøvet det på min
>sommerhus-ADSL, som er slukket).
>
>Min holdning til spoofing er i øvrigt at det kan og bør løses ved at
>(alle) udbydere har filtre der hindrer deres kunder i at spoofe. Jeg
>ved godt at det nok varer lidt før de alle gør det ...
Ingress/egress filtrering forhindrer kun at spoofe folk på andre
netsegmenter, fx folk med kabelmodem kan spoofe enhver i den bydel,
uden at der er nogen mulighed for at filtrere det.
Mvh
Kent
--
Demokrati er lige som den 29. februar - begge dele forekommer
en gang hver fjerde år.
| |
Jesper Dybdal (29-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 29-09-03 19:32 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>Ofte er det ikke interessant blot at spoofe en adresse der ikke svarer.
>Man ønsker at spoofe et ip-nummer der har adgang til et system, for
>selv at få adgang.
Hvis ens ip-adresse er værdifuld på den måde at den har adgang til
noget som andre kunne finde på at ville tiltuske sig adgang til, så
har du ganske ret i at det en god ide at svare på en eller anden måde.
Men det er ikke ret tit tilfældet for almindelige hjemmeopkoblinger.
Min ip-adresse giver godt nok mulighed for at køre ssh til en maskine
som andre ikke kan køre ssh til, men dels skal man jo også lige bryde
ssh, og dels hindrer TDC nok den spoofing, da det handler om to
TDC-ADSL-opkoblinger.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kent Friis (29-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-03 20:29 |
|
Den Mon, 29 Sep 2003 20:32:29 +0200 skrev Jesper Dybdal:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>Ofte er det ikke interessant blot at spoofe en adresse der ikke svarer.
>>Man ønsker at spoofe et ip-nummer der har adgang til et system, for
>>selv at få adgang.
>
>Hvis ens ip-adresse er værdifuld på den måde at den har adgang til
>noget som andre kunne finde på at ville tiltuske sig adgang til, så
>har du ganske ret i at det en god ide at svare på en eller anden måde.
>
>Men det er ikke ret tit tilfældet for almindelige hjemmeopkoblinger.
Jeg kender optil flere nørder ("almindelig"?) med Warez-FTP-servere
der filtrerer på ip-nummer.
>Min ip-adresse giver godt nok mulighed for at køre ssh til en maskine
>som andre ikke kan køre ssh til, men dels skal man jo også lige bryde
>ssh, og dels hindrer TDC nok den spoofing, da det handler om to
>TDC-ADSL-opkoblinger.
Jeg er ikke sikker på at TDC filtrerer internt. Border-routerne bør
helt klart gøre det, men hver eneste router ude på centralerne?
Tja, der er ikke noget der forhindrer det, men det kræver dog at nogen
har slået det itl.
Mvh
Kent
--
Object orientation: the idea, that humans find it easier to understand
"you.car.engine.start" than "start your car engine".
| |
Jesper Dybdal (29-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 29-09-03 21:15 |
|
leeloo@phreaker.net (Kent Friis) wrote:
>Jeg er ikke sikker på at TDC filtrerer internt. Border-routerne bør
>helt klart gøre det, men hver eneste router ude på centralerne?
>Tja, der er ikke noget der forhindrer det, men det kræver dog at nogen
>har slået det itl.
Jeg mener at huske at Jesper Skriver engang har skrevet at de gør det.
Det kan dog være jeg husker galt, så hæng ikke Jesper op på det hvis
det er forkert.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kasper Dupont (30-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 30-09-03 15:26 |
|
Kent Friis wrote:
>
> folk med kabelmodem kan spoofe enhver i den bydel,
> uden at der er nogen mulighed for at filtrere det.
Det er nu ikke helt rigtigt. Jeg har selv et kabelmodem
og i begyndelsen var det da muligt at sætte computeren
op til en vilkårlig IP adresse. Men sidenhen har de
lagt filtre på, som på en eller anden måde holder øje
med den IP man får tildelt af DHCP serveren, og så
derefter filtrerer.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Kent Friis (30-09-2003)
| Kommentar
Fra : Kent Friis |
Dato : 30-09-03 16:34 |
|
Den Tue, 30 Sep 2003 16:26:02 +0200 skrev Kasper Dupont:
>Kent Friis wrote:
>>
>> folk med kabelmodem kan spoofe enhver i den bydel,
>> uden at der er nogen mulighed for at filtrere det.
>
>Det er nu ikke helt rigtigt. Jeg har selv et kabelmodem
>og i begyndelsen var det da muligt at sætte computeren
>op til en vilkårlig IP adresse. Men sidenhen har de
>lagt filtre på, som på en eller anden måde holder øje
>med den IP man får tildelt af DHCP serveren, og så
>derefter filtrerer.
Det forudsætter at de har noget ude hos dig, som kan garantere din
identitet. Enten din Mac-adresse eller kabel-modem'et.
Mac-adressen kan ændres.
Kabel-modem'et kan man pille ved opsætningen af, når det er muligt
at pille ved hastigheden[1], er det helt klart også muligt at slå
ip-filtrering fra.
Mvh
Kent
[1] Derfor bør hastigheden altid styres i udbyderens ende, ALDRIG i
kundens ende.
--
Those who write "Optimized for Netscape" or "Best viewed with MSIE"
never figured out the difference between the WWW and a
Word Perfect 4.2 Document.
| |
Kasper Dupont (30-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 30-09-03 17:34 |
|
Kent Friis wrote:
>
> Den Tue, 30 Sep 2003 16:26:02 +0200 skrev Kasper Dupont:
> >Kent Friis wrote:
> >>
> >> folk med kabelmodem kan spoofe enhver i den bydel,
> >> uden at der er nogen mulighed for at filtrere det.
> >
> >Det er nu ikke helt rigtigt. Jeg har selv et kabelmodem
> >og i begyndelsen var det da muligt at sætte computeren
> >op til en vilkårlig IP adresse. Men sidenhen har de
> >lagt filtre på, som på en eller anden måde holder øje
> >med den IP man får tildelt af DHCP serveren, og så
> >derefter filtrerer.
>
> Det forudsætter at de har noget ude hos dig, som kan garantere din
> identitet. Enten din Mac-adresse eller kabel-modem'et.
Kabel modemet husker på den første MAC adresse det ser.
Derefter vil det ikke modtage pakker fra andre (før det
er blevet genstartet). Udover det sker der også check
af MAC adresse på DHCP serveren, hvis den ikke er
registreret bliver man sendt ind på en særlig
registrerings server. De skriver selv, at kabelmodemets
identitet bliver checket ved samme lejlighed, jeg har
ikke haft mulighed for at undersøge, om det er sandt.
Om resten af filtreringen sker i kabelmodemet eller et
andet sted ved jeg ikke.
>
> Mac-adressen kan ændres.
>
> Kabel-modem'et kan man pille ved opsætningen af, når det er muligt
> at pille ved hastigheden[1], er det helt klart også muligt at slå
> ip-filtrering fra.
Jeg har hørt, at det skulle være muligt. Men jeg aner
ikke hvordan, og jeg har aldrig prøvet. Jeg ved dog, at
når de ændrer abonementstype til en anden hastighed
genstarter de kabelmodemet udefra.
>
> Mvh
> Kent
>
> [1] Derfor bør hastigheden altid styres i udbyderens ende, ALDRIG i
> kundens ende.
Ja, det har du fuldstændig ret i. Stol aldrig mere end
allerhøjst nødvendigt på udstyr ude hos kunden. I øvrigt
kan man også bruge et andet kabelmodem end det man har
fået leveret af Tele Danmark, der er dog ikke support
på det. (Man kan så diskutere, om der er support på det,
der er leveret af Tele Danmark. De påstod hårdnakket, at
da det pludslig en dag holdt op med at virke måtte det
være USB portene i begge mine computere, der var gået i
stykker samtidig. Der kunne umuligt være noget galt med
kabelmodemet.)
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Kasper Dupont (28-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 28-09-03 10:38 |
|
Jesper Dybdal wrote:
>
> Det er utvivlsomt i modstrid med reglerne for hvordan MTA'er "skal"
> opføre sig, at smide breve væk. Men det er særdeles hensigtsmæssigt -
> det har sparet mig for over 3000 eksemplarer af enten virussen (à ca.
> 150 kB = ca. 450 MB) eller beskeder fra en virusscanner.
Send en fejlmelding ved slutningen af DATA. Du behøver ikke sende
nogen bounce, og du overholder stadig standarden. Og du skal ikke
bruge mere båndbredde end du ellers ville have brugt.
>
> Efter mine begreber er pakker til porte som jeg ikke ønsker at levere
> service på, ikke legitime. De kan være et angreb eller et tilfældigt
> uheld - i begge tilfælde føler jeg intet ansvar for at svare på dem.
Du ved ikke, om pakkerne er legitime. Afsenderen ved det måske.
>
> >- Firewalls skaber problemer med timeouts og stalled connections.
>
> Ja, men kun for dem der sender pakker som ifølge min opfattelse, jf.
> forrige punkt, ikke er legitime. Det betragter jeg som en fordel.
Din opfattelse er ikke nødvendigvis rigtig.
>
> >- Firewalls gør det i nogle tilfælde nemmere at spoofe IP adresser.
>
> Det er korrekt. En RST kan ødelægge spoofingen. Men problemet med
> spoofede pakker er meget lille når de smides væk ubehandlet.
De spoofede pakker bliver netop ikke smidt væk ubehandlet. Og hvis
angrebet lykkes, vil alle spor pege på dig som ansvarlig.
>
> >- Og nogle firewalls gør det nemmere at lave DoS angreb.
>
> Ved at smide pakker sporløst væk? Det forstår jeg vist ikke.
Det konkrete eksempel er ikke det værste. Du laver selvfølgelig
ikke noget DoS angreb mod dig selv ved at kassere pakker til
lukkede porte. Jeg tænker mere på de personer, som vælger at
blackliste afsender IP adresser fra alle uventede pakker. Desuden
vil SYN flooding være mere effektiv jo flere, der kasserer
uventede pakker. Hvis angriberen spoofer din IP adresse på en af
pakkerne vil du modtage et SYN ACK. Hvis du besvarer med en RST
pakke er problemet løst, for serverens connection indgang kan
blive slettet. Hvis alle sendte de krævede RST pakker ville SYN
flooding ikke være lige så effektivt. Det er selvfølgelig stadig
et problem, at serveren ikke får ICMP pakker tilbage for alle
de ikke eksisterende hosts. Hvis angriberen kan gætte sekvens
numre bliver det straks meget værre. Et komplet angreb på en TCP
basseret service kan potentielt udføres med spoofet source IP,
og din IP adresse vil stå i loggen på den angrebne server.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Klaus Ellegaard (28-09-2003)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 28-09-03 13:44 |
|
Kasper Dupont <kasperd@daimi.au.dk> writes:
>Send en fejlmelding ved slutningen af DATA. Du behøver ikke sende
>nogen bounce, og du overholder stadig standarden. Og du skal ikke
>bruge mere båndbredde end du ellers ville have brugt.
Du har ikke noget at bounce i den situation - det vil være mod
standarden at sende noget som helst.
>Hvis alle sendte de krævede RST pakker ville SYN flooding ikke
>være lige så effektivt.
Findes der overhovedet noget system i praktisk anvendelse, der
har konkrete problemer med SYN flooding? Problemet er jo løst
rent teknisk.
>Et komplet angreb på en TCP basseret service kan potentielt
>udføres med spoofet source IP, og din IP adresse vil stå i
>loggen på den angrebne server.
*Shrug* Der er vel ingen, der tager sig af afsenderadresser -
udover til at få stoppet angrebet med?
Mvh.
Klaus.
| |
Kasper Dupont (28-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 28-09-03 15:28 |
|
Klaus Ellegaard wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> >Send en fejlmelding ved slutningen af DATA. Du behøver ikke sende
> >nogen bounce, og du overholder stadig standarden. Og du skal ikke
> >bruge mere båndbredde end du ellers ville have brugt.
>
> Du har ikke noget at bounce i den situation - det vil være mod
> standarden at sende noget som helst.
Normal ville man sende fejlmeldingen tilbage til afsenderen angivet
i "MAIL From:" kommandoen. Ved at afvise med en passende fejlkode
opnår du, at ansvaret ligger hos klienten. Det vil sige, at hvis
den komme fra en mailserver, så er det den mailserver, der skal
tage stilling. I tilfælde af et virus angreb er det meget sandsynligt,
at klienten er virusen selv.
>
> >Hvis alle sendte de krævede RST pakker ville SYN flooding ikke
> >være lige så effektivt.
>
> Findes der overhovedet noget system i praktisk anvendelse, der
> har konkrete problemer med SYN flooding? Problemet er jo løst
> rent teknisk.
SYN cookies begrænser skaderne ved en SYN flooding. Men det vil
stadig forringe performance for connections der bliver etableret
mens flooding står på. Også selvom der er masser af båndbredde
tilgængelig.
>
> >Et komplet angreb på en TCP basseret service kan potentielt
> >udføres med spoofet source IP, og din IP adresse vil stå i
> >loggen på den angrebne server.
>
> *Shrug* Der er vel ingen, der tager sig af afsenderadresser -
> udover til at få stoppet angrebet med?
Er det ikke meget almindeligt at bruge sine logfiler til at
lægge sag an mod gud og hvermand?
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Klaus Ellegaard (28-09-2003)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 28-09-03 16:56 |
|
Kasper Dupont <kasperd@daimi.au.dk> writes:
>> Du har ikke noget at bounce i den situation - det vil være mod
>> standarden at sende noget som helst.
>Normal ville man sende fejlmeldingen tilbage til afsenderen angivet
>i "MAIL From:" kommandoen.
Nej, ikke når du afviser mailen. Det indikerer, at du intet har
modtaget af den mail, der er forsøgt afleveret til dig. Ergo må
du heller ikke foretage dig noget som helst, der involverer data
i den mail.
>Ved at afvise med en passende fejlkode opnår du, at ansvaret ligger
>hos klienten.
Præcis. Ansvaret er klientens, og når man IKKE har ansvaret, må
man intet foretage sig.
>SYN cookies begrænser skaderne ved en SYN flooding. Men det vil
>stadig forringe performance for connections der bliver etableret
>mens flooding står på. Også selvom der er masser af båndbredde
>tilgængelig.
Ja, men det begrænser impactet til et ganske almindeligt DDoS-
angreb. Forskellen på manglende RST fra den anden ende og et DDoS
foretaget fra RFC1918-adresser (læs: spoofede adresser) er ens.
>> *Shrug* Der er vel ingen, der tager sig af afsenderadresser -
>> udover til at få stoppet angrebet med?
>Er det ikke meget almindeligt at bruge sine logfiler til at
>lægge sag an mod gud og hvermand?
Tjoh, men det kan jo være ligemeget.
Mvh.
Klaus.
| |
Kasper Dupont (28-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 28-09-03 17:38 |
|
Klaus Ellegaard wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> >Ved at afvise med en passende fejlkode opnår du, at ansvaret ligger
> >hos klienten.
>
> Præcis. Ansvaret er klientens, og når man IKKE har ansvaret, må
> man intet foretage sig.
I det øjeblik du melder 250 som svar på slutningen af DATA overtager
du ansvaret for mailen. Derefter har du ifølge standarden ansvaret
for, at mailen kommer frem, eller der kommer en fejlmelding tilbage
til afsenderen. Det er derfor jeg opfordrer til, at man melder fejl
på det sted så man aldrig nogensinde kommer til at stå med noget
ansvar.
>
> >SYN cookies begrænser skaderne ved en SYN flooding. Men det vil
> >stadig forringe performance for connections der bliver etableret
> >mens flooding står på. Også selvom der er masser af båndbredde
> >tilgængelig.
>
> Ja, men det begrænser impactet til et ganske almindeligt DDoS-
> angreb.
Forkert. Et SYN flooding angreb med meget lille båndbredde brugt
på SYN pakker kan gøre mere skade end et moderat DDoS attack. TCP
forbindelser oprettet under angreb er ikke lige så effektive som
TCP forbindelser oprettet under normale omstændigheder.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Klaus Ellegaard (28-09-2003)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 28-09-03 17:49 |
|
Kasper Dupont <kasperd@daimi.au.dk> writes:
>> Præcis. Ansvaret er klientens, og når man IKKE har ansvaret, må
>> man intet foretage sig.
>I det øjeblik du melder 250 som svar på slutningen af DATA overtager
>du ansvaret for mailen.
Udgangspunktet for tråden var, at man meldte 55x tilbage?
>> Ja, men det begrænser impactet til et ganske almindeligt DDoS-
>> angreb.
>Forkert. Et SYN flooding angreb med meget lille båndbredde brugt
>på SYN pakker kan gøre mere skade end et moderat DDoS attack. TCP
>forbindelser oprettet under angreb er ikke lige så effektive som
>TCP forbindelser oprettet under normale omstændigheder.
Du modtager 1 milliard SYN-pakker fra 192.168.1.1. Du får intet
svar, for adressen null-routes hos din ISP.
Du modtager 1 milliard SYN-pakker fra en valid host, der ikke
RST'er dine pakker, fordi han ikke gider.
Hvad er forskellen helt nøjagtigt?
Mvh.
Klaus.
| |
Kasper Dupont (28-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 28-09-03 21:34 |
|
Klaus Ellegaard wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> >I det øjeblik du melder 250 som svar på slutningen af DATA overtager
> >du ansvaret for mailen.
>
> Udgangspunktet for tråden var, at man meldte 55x tilbage?
Udgangspunktet var at kassere mails uden at melde tilbage:
http://tinyurl.com/oywx
>
> Du modtager 1 milliard SYN-pakker fra 192.168.1.1. Du får intet
> svar, for adressen null-routes hos din ISP.
>
> Du modtager 1 milliard SYN-pakker fra en valid host, der ikke
> RST'er dine pakker, fordi han ikke gider.
Det ville tage over en uge at modtage så mange SYN pakker på
min forbindelse.
>
> Hvad er forskellen helt nøjagtigt?
I det ene tilfælde er adressen åbenlyst forkert og pakken
kan kasseres.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Klaus Ellegaard (28-09-2003)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 28-09-03 21:53 |
|
Kasper Dupont <kasperd@daimi.au.dk> writes:
>> Hvad er forskellen helt nøjagtigt?
>I det ene tilfælde er adressen åbenlyst forkert og pakken
>kan kasseres.
Det ændrer ikke på, at din forbindelse er død i en uge?
Måske har din server det mindre hårdt, men det reelle impact
er nøjagtigt det samme.
Mvh.
Klaus.
| |
Kasper Dupont (28-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 28-09-03 22:17 |
|
Klaus Ellegaard wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> >> Hvad er forskellen helt nøjagtigt?
>
> >I det ene tilfælde er adressen åbenlyst forkert og pakken
> >kan kasseres.
>
> Det ændrer ikke på, at din forbindelse er død i en uge?
Har du overhovedet forstået, hvad et SYN flooding angreb går
ud på? Hvis serveren ikke gør noget for at undgå det, så kan
der udføres et DoS angreb selvom man ikke er i stand til at
bruge serverens båndbredde op.
Hvis vi snakker om en flooding, hvor hele båndbredden bruges
op, er det fuldstændigt ligegyldigt, hvad der floodes med.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Christian E. Lysel (28-09-2003)
| Kommentar
Fra : Christian E. Lysel |
Dato : 28-09-03 22:25 |
|
In article <3F774FE4.994FA33@daimi.au.dk>, Kasper Dupont wrote:
> Hvis vi snakker om en flooding, hvor hele båndbredden bruges
> op, er det fuldstændigt ligegyldigt, hvad der floodes med.
Ikke hvis det angrebne system svarer på flood angrebet, dette
kan kun gøre skaden størrer.
Således vil forbindelsen kunne floodes begge veje.
| |
Kasper Dupont (29-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 29-09-03 06:00 |
|
"Christian E. Lysel" wrote:
>
> In article <3F774FE4.994FA33@daimi.au.dk>, Kasper Dupont wrote:
> > Hvis vi snakker om en flooding, hvor hele båndbredden bruges
> > op, er det fuldstændigt ligegyldigt, hvad der floodes med.
>
> Ikke hvis det angrebne system svarer på flood angrebet, dette
> kan kun gøre skaden størrer.
>
> Således vil forbindelsen kunne floodes begge veje.
Det er nemt at undgå hvis man begrænser den båndbredde, der
benyttes til svar pakkerne.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Klaus Ellegaard (28-09-2003)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 28-09-03 22:31 |
|
Kasper Dupont <kasperd@daimi.au.dk> writes:
>Har du overhovedet forstået, hvad et SYN flooding angreb går
>ud på?
Jep.
Jeg har haft fornøjelsen af at arbejde med internet som sysadm
i snart 10 år, så jeg har set det meste - og prøvet at slås med
det meste. Det giver en god forståelse af de enkelte angrebstyper
- og viden om hvor man skal sætte ind i praksis, og hvad man skal
være ligeglad med.
Noget af det mest ligegyldige, der findes, er et SYN-flood-angreb,
der ikke rammer loftet. Og hvis det rammer loftet, er det ikke
SYN-flooden, der er problemet.
>Hvis serveren ikke gør noget for at undgå det, så kan der udføres
>et DoS angreb selvom man ikke er i stand til at bruge serverens
>båndbredde op.
Derfor min kommentar om, at cookies er en god plan. Så er angrebet
fejlet, allerede mens det står på.
>Hvis vi snakker om en flooding, hvor hele båndbredden bruges
>op, er det fuldstændigt ligegyldigt, hvad der floodes med.
Indeed. Og hvorfor - set fra gerningsmandens synspunkt - begrænse
sig til en dårligt virkende teknologi som SYN-floods, når flooding
er meget bedre?
Bevares, kan man slå to fluer med ét smæk via et (D)DoS-angreb,
der også får selve stakken i knæ, er det da et hit.
Det svarer lidt til at have en gigantisk lås på døren, som altid
er låst, og så overveje, om håndtaget nu også er stærkt nok: det
ser godt ud, men det er skønne spildte kræfter og penge.
Mvh.
Klaus.
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 23:50 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>Klaus Ellegaard wrote:
>>
>> Kasper Dupont <kasperd@daimi.au.dk> writes:
>>
>> >Ved at afvise med en passende fejlkode opnår du, at ansvaret ligger
>> >hos klienten.
>>
>> Præcis. Ansvaret er klientens, og når man IKKE har ansvaret, må
>> man intet foretage sig.
>
>I det øjeblik du melder 250 som svar på slutningen af DATA overtager
>du ansvaret for mailen. Derefter har du ifølge standarden ansvaret
>for, at mailen kommer frem, eller der kommer en fejlmelding tilbage
>til afsenderen. Det er derfor jeg opfordrer til, at man melder fejl
>på det sted så man aldrig nogensinde kommer til at stå med noget
>ansvar.
Ens server står ikke med noget RFC-defineret ansvar.
Men man har selv valgt at udsætte de tilsyneladende afsendere for den
bounce som afsenderserveren så giver dem. Jeg synes man har et ansvar
som almindelig ansvarlig serveradministrator for ikke bevidst at
udsætte folk for den slags når man lige så godt kan lade være - dvs.
når man *ved*, udover enhvher realistisk tvivl, at det er en virus man
har fat i. Det ved jeg når min server fanger en Swen.A, og så afviser
jeg den naturligvis ikke.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kasper Dupont (29-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 29-09-03 07:51 |
|
Jesper Dybdal wrote:
>
> Ens server står ikke med noget RFC-defineret ansvar.
RFC 2821:
In sending a positive
completion reply to the end of data indication, the receiver takes
full responsibility for the message (see section 6.1).
>
> Men man har selv valgt at udsætte de tilsyneladende afsendere for den
> bounce som afsenderserveren så giver dem. Jeg synes man har et ansvar
> som almindelig ansvarlig serveradministrator for ikke bevidst at
> udsætte folk for den slags når man lige så godt kan lade være - dvs.
> når man *ved*, udover enhvher realistisk tvivl, at det er en virus man
> har fat i. Det ved jeg når min server fanger en Swen.A, og så afviser
> jeg den naturligvis ikke.
Hvis du kan dokumentere, at afvisning af mailen ved slutningen af
DATA medfører en bounce vil jeg gerne give dig ret i, at der kan
være fornuft i at acceptere mail for derefter at smide den væk.
Under alle omstændigheder ville der være fornuft i at afvise virus
allerede ved den første SMTP server, som tager imod mailen.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Jesper Dybdal (29-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 29-09-03 19:17 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>Jesper Dybdal wrote:
>>
>> Ens server står ikke med noget RFC-defineret ansvar.
>
>RFC 2821:
>
> In sending a positive
> completion reply to the end of data indication, the receiver takes
> full responsibility for the message (see section 6.1).
Ja. Du har muligvis overset at den sætning du citerer mig for uden
kontekst, jo altså handlede om situationen når man netop *ikke* har
givet "a positive completion reply". (Og det var i øvrigt en sætning
der gav dig ret.)
>> Men man har selv valgt at udsætte de tilsyneladende afsendere for den
>> bounce som afsenderserveren så giver dem. Jeg synes man har et ansvar
>> som almindelig ansvarlig serveradministrator for ikke bevidst at
>> udsætte folk for den slags når man lige så godt kan lade være - dvs.
>> når man *ved*, udover enhvher realistisk tvivl, at det er en virus man
>> har fat i. Det ved jeg når min server fanger en Swen.A, og så afviser
>> jeg den naturligvis ikke.
>
>Hvis du kan dokumentere, at afvisning af mailen ved slutningen af
>DATA medfører en bounce vil jeg gerne give dig ret i, at der kan
>være fornuft i at acceptere mail for derefter at smide den væk.
Hvis den kommer fra en egentlig MTA, så medfører det naturligvis en
bounce. Hvis en MTA forsøger at aflevere et brev til en anden MTA, og
får en permanent fejlstatus (5xx) som svar, så er det dens soleklare
pligt at fortælle afsenderen om det (hvis der overhovedet er en
afsender, naturligvis, men det er der jo ca. altid når den fejlende
besked ikke selv er en bounce). Ellers ville vi jo ikke få at vide
når vores breve ikke kom frem.
Og Swen.A bruger en rigtig MTA - nemlig offerets normale server for
udgående post.
>Under alle omstændigheder ville der være fornuft i at afvise virus
>allerede ved den første SMTP server, som tager imod mailen.
Absolut. Hvis man ved at brevet kommer *direkte* fra en
virusinficeret maskine som selv kører smtp og ikke sender bounces (fx
SoBig.F, hvis man altså er sikker på at den ikke kommer via en
sekundær-MX som ikke har samme filter), så er det særdeles fornuftigt
at afvise den.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 23:50 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>Normal ville man sende fejlmeldingen tilbage til afsenderen angivet
>i "MAIL From:" kommandoen. Ved at afvise med en passende fejlkode
>opnår du, at ansvaret ligger hos klienten. Det vil sige, at hvis
>den komme fra en mailserver, så er det den mailserver, der skal
>tage stilling. I tilfælde af et virus angreb er det meget sandsynligt,
>at klienten er virusen selv.
Ikke i tilfældet Swen.A.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 23:50 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>Jesper Dybdal wrote:
>>
>> Det er utvivlsomt i modstrid med reglerne for hvordan MTA'er "skal"
>> opføre sig, at smide breve væk. Men det er særdeles hensigtsmæssigt -
>> det har sparet mig for over 3000 eksemplarer af enten virussen (à ca.
>> 150 kB = ca. 450 MB) eller beskeder fra en virusscanner.
>
>Send en fejlmelding ved slutningen af DATA. Du behøver ikke sende
>nogen bounce, og du overholder stadig standarden. Og du skal ikke
>bruge mere båndbredde end du ellers ville have brugt.
Derved sparer jeg ganske rigtigt min egen server for besværet, men jeg
er ikke så egoistisk at jeg synes det er nok. Den afsendende server
vil jo så sende en bounce til den stakkels tilsyneladende afsender, og
i betragtning af hvor irriteret jeg selv over at modtage den slags
bounces, vil jeg sandelig ikke medvirke til det.
Swen.A bruger en rigtig smtp-server til at sende med, så brevet bliver
faktisk bouncet hvis man sender fejlstatus efter DATA. (SoBig.F,
derimod, bruger ikke en rigtig server, så den kan man godt svare
fejlstatus på - hvis man altså lige husker at ens sekundær-MX så også
skal gøre det.)
>> Efter mine begreber er pakker til porte som jeg ikke ønsker at levere
>> service på, ikke legitime. De kan være et angreb eller et tilfældigt
>> uheld - i begge tilfælde føler jeg intet ansvar for at svare på dem.
>
>Du ved ikke, om pakkerne er legitime. Afsenderen ved det måske.
Jo, det ved jeg netop. En SYN-pakke til port 23 på min server er fx
ikke legitim, idet jeg tillader mig at definere hvad der er legitim
trafik til min server. Det kan godt være den ikke er ondskabsfuld,
men legitim er den ikke.
>> >- Firewalls skaber problemer med timeouts og stalled connections.
>>
>> Ja, men kun for dem der sender pakker som ifølge min opfattelse, jf.
>> forrige punkt, ikke er legitime. Det betragter jeg som en fordel.
>
>Din opfattelse er ikke nødvendigvis rigtig.
Korrekt. Det er din jo altså heller ikke nødvendigvis.
>De spoofede pakker bliver netop ikke smidt væk ubehandlet. Og hvis
>angrebet lykkes, vil alle spor pege på dig som ansvarlig.
Se mit svar til Kent om det punkt.
>> >- Og nogle firewalls gør det nemmere at lave DoS angreb.
>>
>> Ved at smide pakker sporløst væk? Det forstår jeg vist ikke.
>
>Det konkrete eksempel er ikke det værste. Du laver selvfølgelig
>ikke noget DoS angreb mod dig selv ved at kassere pakker til
>lukkede porte. Jeg tænker mere på de personer, som vælger at
>blackliste afsender IP adresser fra alle uventede pakker.
Enig. Det er typisk tåbeligt. Men det er vel den enkelte
organisations ansvar at vurdere om de synes de ved den mekanisme
vinder noget som er den forøgede risiko for DoS-angreb værd?
>Desuden
>vil SYN flooding være mere effektiv jo flere, der kasserer
>uventede pakker. Hvis angriberen spoofer din IP adresse på en af
>pakkerne vil du modtage et SYN ACK. Hvis du besvarer med en RST
>pakke er problemet løst, for serverens connection indgang kan
>blive slettet. Hvis alle sendte de krævede RST pakker ville SYN
>flooding ikke være lige så effektivt. Det er selvfølgelig stadig
>et problem, at serveren ikke får ICMP pakker tilbage for alle
>de ikke eksisterende hosts.
Nemlig. Hvis der eksisterede en implementeret standard der sagde at
alle ip-adresser overhovedet, også de ikke-tildelte, skulle give en
eller anden slags svar (uanset om udstyr var slukket eller tændt), så
ville jeg synes det var fornuftigt og være helt enig. Men vi er så
langt fra den situation at det forekommer inderlig ligegyldigt om en
enkelte IP-adresseejer gør sin firemilliardedel af den nødvendige
indsats. Jf. også mit svar til Kent.
>Hvis angriberen kan gætte sekvens
>numre bliver det straks meget værre. Et komplet angreb på en TCP
>basseret service kan potentielt udføres med spoofet source IP,
>og din IP adresse vil stå i loggen på den angrebne server.
Det sker fx også hvis mit ADSL-modem er slukket.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kasper Dupont (29-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 29-09-03 06:18 |
|
Jesper Dybdal wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
> >Jesper Dybdal wrote:
> >>
> >> Det er utvivlsomt i modstrid med reglerne for hvordan MTA'er "skal"
> >> opføre sig, at smide breve væk. Men det er særdeles hensigtsmæssigt -
> >> det har sparet mig for over 3000 eksemplarer af enten virussen (à ca.
> >> 150 kB = ca. 450 MB) eller beskeder fra en virusscanner.
> >
> >Send en fejlmelding ved slutningen af DATA. Du behøver ikke sende
> >nogen bounce, og du overholder stadig standarden. Og du skal ikke
> >bruge mere båndbredde end du ellers ville have brugt.
>
> Derved sparer jeg ganske rigtigt min egen server for besværet, men jeg
> er ikke så egoistisk at jeg synes det er nok. Den afsendende server
> vil jo så sende en bounce til den stakkels tilsyneladende afsender, og
> i betragtning af hvor irriteret jeg selv over at modtage den slags
> bounces, vil jeg sandelig ikke medvirke til det.
>
> Swen.A bruger en rigtig smtp-server til at sende med, så brevet bliver
> faktisk bouncet hvis man sender fejlstatus efter DATA. (SoBig.F,
> derimod, bruger ikke en rigtig server, så den kan man godt svare
> fejlstatus på - hvis man altså lige husker at ens sekundær-MX så også
> skal gøre det.)
Er du sikker? Jeg har modtaget tusindvis af eksemplarer af virusen.
Jeg har ikke modtaget et eneste bounce forårsaget af en fejlkode
ved afslutning af DATA.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Jesper Dybdal (29-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 29-09-03 19:17 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>Jesper Dybdal wrote:
>> Swen.A bruger en rigtig smtp-server til at sende med, så brevet bliver
>> faktisk bouncet hvis man sender fejlstatus efter DATA. (SoBig.F,
>> derimod, bruger ikke en rigtig server, så den kan man godt svare
>> fejlstatus på - hvis man altså lige husker at ens sekundær-MX så også
>> skal gøre det.)
>
>Er du sikker? Jeg har modtaget tusindvis af eksemplarer af virusen.
>Jeg har ikke modtaget et eneste bounce forårsaget af en fejlkode
>ved afslutning af DATA.
Jeg er sikker på at Swen.A bruger en rigtig MTA. Dels fordi jeg har
læst at den gør det, dels fordi jeg har set Received-linjer der viser
at min server får den fra noget der virkelig ligner en udbyders
smtp-server.
Jeg er også sikker på at en rigtig MTA faktisk bouncer når den får en
5xx-kode efter DATA.
Men ved nærmere eftertanke er jeg faktisk ikke sikker på at netop
Swen.A overhovedet forfalsker konvolutafsenderen. Jeg har modtaget
noget der lignede bounces, men det er muligvis falske bounces som den
har lavet - de ser ikke spor ægte ud, når jeg nu ser ordentligt efter.
Det er faktisk muligt at den bruger offerets ægte adresse som
konvolutafsender. Det forklarer de manglende bounces.
Hvis den ikke forfalsker konvolutafsenderen, så kan det være ganske
fornuftigt at bounce den til afsenderen (nemmest ved at afvise den).
Det vil jeg dog ikke gøre medmindre jeg bliver ganske sikker på at den
ikke forfalsker afsenderen.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Peder Vendelbo Mikke~ (28-09-2003)
| Kommentar
Fra : Peder Vendelbo Mikke~ |
Dato : 28-09-03 01:02 |
|
Jesper Dybdal skrev:
> Det er også mit indtryk at ret mange af os netop i disse dage bliver
> forskånet for tusindvis af eksemplarer af Swen.A-virussen fordi nogle
> mailservere omhyggeligt undlader at overholde de RFC'er der ellers
> fortæller hvad en mailserver skal gøre.
Jeg har ikke tjekket, men jeg regner da med at mailserveren svarer
tilbage med en 554 kode og en kort forklarende tekst, når antivirus-
programmet har genkendt Swen og har besluttet sig for at afsenderen er
en grim karl.
| |
Kasper Dupont (28-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 28-09-03 15:30 |
|
Peder Vendelbo Mikkelsen wrote:
>
> Jeg har ikke tjekket, men jeg regner da med at mailserveren svarer
> tilbage med en 554 kode og en kort forklarende tekst, når antivirus-
> programmet har genkendt Swen og har besluttet sig for at afsenderen er
> en grim karl.
Det ville da være den bedste løsning. Men det er desværre langt fra
alle, der håndterer det så fornuftigt.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 23:50 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>Peder Vendelbo Mikkelsen wrote:
>>
>> Jeg har ikke tjekket, men jeg regner da med at mailserveren svarer
>> tilbage med en 554 kode og en kort forklarende tekst, når antivirus-
>> programmet har genkendt Swen og har besluttet sig for at afsenderen er
>> en grim karl.
>
>Det ville da være den bedste løsning. Men det er desværre langt fra
>alle, der håndterer det så fornuftigt.
Det er ikke fornuftigt at belaste den tilsyneladende afsender af noget
man ved er virus, med en bounce, sådan som man - via afsenderserveren
- gør hvis man giver 554.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Peder Vendelbo Mikke~ (29-09-2003)
| Kommentar
Fra : Peder Vendelbo Mikke~ |
Dato : 29-09-03 10:25 |
|
Jesper Dybdal skrev:
> Kasper Dupont wrote:
>> Peder Vendelbo Mikkelsen wrote:
>>> Jeg har ikke tjekket, men jeg regner da med at mailserveren svarer
>>> tilbage med en 554 kode og en kort forklarende tekst, når
>>> antivirus-programmet har genkendt Swen og har besluttet sig for at
>>> afsenderen er en grim karl.
>> Det ville da være den bedste løsning. Men det er desværre langt fra
>> alle, der håndterer det så fornuftigt.
> Det er ikke fornuftigt at belaste den tilsyneladende afsender af
> noget man ved er virus, med en bounce, sådan som man - via
> afsenderserveren - gør hvis man giver 554.
Jeg har svært ved at se problemet i, at min mailserver siger til en af-
sendende mailserver "det der vil jeg ikke have, pak dig og gå væk".
Hvad den afsendende mailserver derefter gør, kan jeg vel ikke ligefrem
klandres for, da det afhænger af hvordan den er opsat og drives.
Hvis min mailserver ikke reagerer med en fejlmeddelelse, er jeg med
til, potentielt, at forlænge spredningen af f.eks. en virus fra en
inficeret maskine.
Vi kan vel godt blive enige om:
at spredning af virus er noget skidt?
at det er mere effektivt at gøre noget ved problemet når det opdages?
(fremfor at vende det blinde øje til og håbe at brugeren opdager det
på egen hånd)
at det er rart at du får en bounce når du har sendt en email forkert i
byen?
--
Mad DNS Disease:
http://ars.userfriendly.org/cartoons/?id=20030917
| |
Jesper Dybdal (29-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 29-09-03 19:17 |
|
"Peder Vendelbo Mikkelsen" <pedervm@myrealbox.com> wrote:
>Jeg har svært ved at se problemet i, at min mailserver siger til en af-
>sendende mailserver "det der vil jeg ikke have, pak dig og gå væk".
>
>Hvad den afsendende mailserver derefter gør, kan jeg vel ikke ligefrem
>klandres for, da det afhænger af hvordan den er opsat og drives.
Hvis den er en bare tilnærmelsesvis korrekt implementation af
standarderne, så leverer den en bounce til konvolutafsenderen (hvis
der overhovedet er sådan én).
>Vi kan vel godt blive enige om:
>
>at spredning af virus er noget skidt?
Ja.
>at det er mere effektivt at gøre noget ved problemet når det opdages?
>(fremfor at vende det blinde øje til og håbe at brugeren opdager det
>på egen hånd)
Ja - hvis man kan. Og det kan man kun hvis man ved hvem brugeren er.
>at det er rart at du får en bounce når du har sendt en email forkert i
>byen?
Ja - når *jeg* har sendt den.
Men det er ikke spor rart at få en bounce fordi en helt anden persons
maskine har sendt en virus med mig som falsk afsender. Det er
efterhånden gået op for mig, jf. mit svar til Kasper, at Swen.A
muligvis ikke forfalsker konvolutafsenderen - men det gør langt de
fleste andre vira, og jeg har fået masser af bounces fra vira.
At bounce en Klez, fx, er det samme som at sende meningsløs post til
en tilfældig modtager. Det er ikke hensynsfuldt. Og det kan vi vel
også blive enige om, mon ikke?
Så min holdning er:
* Hvis det kan tænkes ikke at være en virus (fx et filter der fanger
alle .exe-attachments): giv en fejlstatus, så vil den bounce hvis den
kommer fra en rigtig mailserver.
* Ellers, hvis man er sikker på at netop den virus ikke forfalsker
konvolutafsenderen: så er en bounce også helt ok.
* Ellers (dvs. man ved det er en virus, og man mistænker at afsenderen
er forfalsket): modtag den, sig "ok", smid den ud.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Peder Vendelbo Mikke~ (30-09-2003)
| Kommentar
Fra : Peder Vendelbo Mikke~ |
Dato : 30-09-03 00:52 |
|
Jesper Dybdal skrev:
Opfølgning er sat til dk.edb.sikkerhed.virus.
> "Peder Vendelbo Mikkelsen" wrote:
>> at det er mere effektivt at gøre noget ved problemet når det op-
>> dages? (fremfor at vende det blinde øje til og håbe at brugeren
>> opdager det på egen hånd)
> Ja - hvis man kan. Og det kan man kun hvis man ved hvem brugeren er.
Afsenderserveren må da vide hvorfra den har fået emailen. Hvis ikke,
hober mailen sig op i bad mail kataloget og postmaster må på arbejde.
>> at det er rart at du får en bounce når du har sendt en email forkert
>> i byen?
> Ja - når *jeg* har sendt den.
Så du vil ikke vide det, hvis din maskine bliver udsat for en hændelse
der gør at den sender emails (med din afsenderadresse) uden din viden?
Hændelsen kan være en virus, det kan også være et indbrud i din maskine
hvor din mailapplikation er blevet "patchet". Hvordan vil du nogensinde
vide det, med mindre du får en fejl tilbage?
> Men det er ikke spor rart at få en bounce fordi en helt anden persons
> maskine har sendt en virus med mig som falsk afsender. Det er
> efterhånden gået op for mig, jf. mit svar til Kasper, at Swen.A
> muligvis ikke forfalsker konvolutafsenderen - men det gør langt de
> fleste andre vira, og jeg har fået masser af bounces fra vira.
Jeg tror de fleste vira med egen mailserver indbygget, ikke forsøger at
gensende emails hvis de bliver afvist af modtagerserveren.
> At bounce en Klez, fx, er det samme som at sende meningsløs post til
> en tilfældig modtager. Det er ikke hensynsfuldt. Og det kan vi vel
> også blive enige om, mon ikke?
Jeg tror ikke at Klez mailserver er i stand til at bounce tilbage til
brugerens maskine.
Bemærk at vi ikke taler om nogle af disse åndssvage mail-programmer,
hvor brugeren kan lege at han kan bounce en email, vi taler om hvad
der foregår når mailservere taler med hinanden.
Nogen der kender til analyser af anvendte mailservere som er set i
det vilde i virus?
Opfølgning er sat til dk.edb.sikkerhed.virus.
| |
Jesper Dybdal (30-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 30-09-03 18:55 |
|
"Peder Vendelbo Mikkelsen" <pedervm@myrealbox.com> wrote:
>Afsenderserveren må da vide hvorfra den har fået emailen. Hvis ikke,
>hober mailen sig op i bad mail kataloget og postmaster må på arbejde.
Afsenderserveren ved hvad konvolutafsenderadressen er. Den kender
også ip-adressen brevet blev leveret fra, men den kan den ikke bruge
til noget når den først har accepteret at få brevet ind i sin kø.
Så den har altså kun en afsenderadresse som nemt kan forfalskes - og
som faktisk er falsk for de fleste vira og spams.
Så nej, i tilfældet en virus (eller spam) aner den faktisk typisk ikke
hvorfra den har fået den.
>>> at det er rart at du får en bounce når du har sendt en email forkert
>>> i byen?
>
>> Ja - når *jeg* har sendt den.
>
>Så du vil ikke vide det, hvis din maskine bliver udsat for en hændelse
>der gør at den sender emails (med din afsenderadresse) uden din viden?
Jo.
Men hvis det brev der ankommer til en server faktisk indeholder en
virus som må forventes af have forfalsket afsenderadressen, så er der
ingen som helst grund til at formode at jeg eller min maskine har
noget som helst at gøre med den, bare fordi min adresse står som
afsender. Og så vil jeg sandelig gerne være fri for at få at vide at
en hel masse servere har modtaget noget som bærer min adresse, men som
i øvrigt allerede er identificeret som en virus der forfalsker
adressen.
>Hændelsen kan være en virus, det kan også være et indbrud i din maskine
>hvor din mailapplikation er blevet "patchet". Hvordan vil du nogensinde
>vide det, med mindre du får en fejl tilbage?
Da det overvældende flertal af vira forfalsker afsenderen, så får
*jeg* det alligevel næppe at vide fordi der sendes en fejl "tilbage".
Det gør derimod en uskyldig stakkel. Husk at vi snakker om en
situation hvor den modtagende server har identificeret en virus med
overvældende sikkerhed - almindelig post skal man naturligvis ikke
smide væk uden spor.
>> Men det er ikke spor rart at få en bounce fordi en helt anden persons
>> maskine har sendt en virus med mig som falsk afsender. Det er
>> efterhånden gået op for mig, jf. mit svar til Kasper, at Swen.A
>> muligvis ikke forfalsker konvolutafsenderen - men det gør langt de
>> fleste andre vira, og jeg har fået masser af bounces fra vira.
>
>Jeg tror de fleste vira med egen mailserver indbygget, ikke forsøger at
>gensende emails hvis de bliver afvist af modtagerserveren.
Korrekt - for så vidt angår vira der kun sender direkte til
modtagerens server. Men mange vira sender via offerets normale
smtp-server for udgående post - og den bouncer korrekt hvis man nægter
at modtage fra den.
>> At bounce en Klez, fx, er det samme som at sende meningsløs post til
>> en tilfældig modtager. Det er ikke hensynsfuldt. Og det kan vi vel
>> også blive enige om, mon ikke?
>
>Jeg tror ikke at Klez mailserver er i stand til at bounce tilbage til
>brugerens maskine.
Nej. Men Klez afleverer faktisk posten til offerets normale udgående
mailserver (jeg har lige tjekket et par Klez'er jeg har på lager, og
de kom via udbyderes servere), og den bouncer naturligvis glad til den
forfalskede adresse hvis modtagerens server nægter at tage imod.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kasper Dupont (01-10-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 01-10-03 06:49 |
|
Jesper Dybdal wrote:
>
> "Peder Vendelbo Mikkelsen" <pedervm@myrealbox.com> wrote:
>
> >Afsenderserveren må da vide hvorfra den har fået emailen. Hvis ikke,
> >hober mailen sig op i bad mail kataloget og postmaster må på arbejde.
>
> Afsenderserveren ved hvad konvolutafsenderadressen er. Den kender
> også ip-adressen brevet blev leveret fra, men den kan den ikke bruge
> til noget når den først har accepteret at få brevet ind i sin kø.
>
> Så den har altså kun en afsenderadresse som nemt kan forfalskes - og
> som faktisk er falsk for de fleste vira og spams.
Jeg kender til tre forskellige måder at kontrollere afsenderen på:
1) Liste af gyldige IP adresser. (Med risiko for at blive listet
i ordb).
2) Tillade forbindelser fra IP adresser, der har etableret en POP
forbindelse indenfor det sidste x minutter.
3) Brug brugernavn og password i SMTP sessionen.
I alle tre tilfælde kan man vælge kun at acceptere afsender adresser,
som faktisk ligger i ens eget domæne. I tilfælde 2 og 3 kan man også
checke brugernavnet. Jeg har ikke kendskab til nogen, som faktisk
implemnterer disse checks. Måske fordi man så ikke ville kunne bruge
en anden af sine accounts som afsender adresse.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Jesper Dybdal (01-10-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 01-10-03 22:56 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>Jesper Dybdal wrote:
>>
>> "Peder Vendelbo Mikkelsen" <pedervm@myrealbox.com> wrote:
>>
>> >Afsenderserveren må da vide hvorfra den har fået emailen. Hvis ikke,
>> >hober mailen sig op i bad mail kataloget og postmaster må på arbejde.
>>
>> Afsenderserveren ved hvad konvolutafsenderadressen er. Den kender
>> også ip-adressen brevet blev leveret fra, men den kan den ikke bruge
>> til noget når den først har accepteret at få brevet ind i sin kø.
>>
>> Så den har altså kun en afsenderadresse som nemt kan forfalskes - og
>> som faktisk er falsk for de fleste vira og spams.
>
>Jeg kender til tre forskellige måder at kontrollere afsenderen på:
>1) Liste af gyldige IP adresser. (Med risiko for at blive listet
> i ordb).
>2) Tillade forbindelser fra IP adresser, der har etableret en POP
> forbindelse indenfor det sidste x minutter.
>3) Brug brugernavn og password i SMTP sessionen.
Ja, men nu snakker du om at afvise afsenderen *inden* man har modtaget
brevet.
Hvis en server først har accepteret brevet, og derefter ikke er i
stand til at viderelevere det (fordi modtagerserveren nægter at tage
imod, fx fordi den har identificeret en virus), så har den kun den
måske forfalskede konvolutafsenderadresse at sende en bounce til.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kasper Dupont (02-10-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 02-10-03 00:03 |
|
Jesper Dybdal wrote:
>
> Ja, men nu snakker du om at afvise afsenderen *inden* man har modtaget
> brevet.
Ja.
>
> Hvis en server først har accepteret brevet, og derefter ikke er i
> stand til at viderelevere det (fordi modtagerserveren nægter at tage
> imod, fx fordi den har identificeret en virus), så har den kun den
> måske forfalskede konvolutafsenderadresse at sende en bounce til.
Hvis du først har taget imod en email med en åbenlys falsk afsender,
så er der ikke ret meget du kan gøre for at finde den rigtige
afsender. Den bedste løsning må være, at ikke tage imod i første
omgang.
Jeg vil foreslå at afvise "RCPT to" hvis følgende er opfyldt:
1. Modtageren er ikke lokal.
2. Der er ikke foretaget korrekt autentifikation for afsender
adressen angivet med "MAIL from".
Så vil du aldrig komme ud i problemet omkring at skulle bounce til
en forfalsket adresse. Hvis modtageren er lokal kan mailen af gode
grunde ikke blive afvist af næste server. Og hvis der er foretaget
en korrekt autentifikation, så kan du trygt bounce, for du ved jo,
at afsenderen er korrekt. Det kræver selvfølgelig stadig, at du
ikke først tager imod en mail og først senere opdager, at den ikke
kan accepteres.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Jesper Dybdal (02-10-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 02-10-03 01:09 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>Jeg vil foreslå at afvise "RCPT to" hvis følgende er opfyldt:
>1. Modtageren er ikke lokal.
>2. Der er ikke foretaget korrekt autentifikation for afsender
> adressen angivet med "MAIL from".
>
>Så vil du aldrig komme ud i problemet omkring at skulle bounce til
>en forfalsket adresse.
Nej, men problemet er jo at ca. ingen udbyderes smtp-servere for
kundernes udgående post stiller krav 2 - som jo altså ville kræve at
udbyderen ved hvilke domæner brugeren kan finde på at bruge som
afsenderadresser, fx fordi han har et webhotel.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Kasper Dupont (02-10-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 02-10-03 06:21 |
|
Jesper Dybdal wrote:
>
> Nej, men problemet er jo at ca. ingen udbyderes smtp-servere for
> kundernes udgående post stiller krav 2 - som jo altså ville kræve at
> udbyderen ved hvilke domæner brugeren kan finde på at bruge som
> afsenderadresser, fx fordi han har et webhotel.
Udbyderen behøver jo ikke tillade, at man sender emails med et andet
domæne angivet som afsender. Hvis de vil tillade det bliver det
nødvendigt med en passende procedure for at checke, at det faktisk
er kundens adresse.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Jesper Dybdal (02-10-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 02-10-03 09:55 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>Jesper Dybdal wrote:
>>
>> Nej, men problemet er jo at ca. ingen udbyderes smtp-servere for
>> kundernes udgående post stiller krav 2 - som jo altså ville kræve at
>> udbyderen ved hvilke domæner brugeren kan finde på at bruge som
>> afsenderadresser, fx fordi han har et webhotel.
>
>Udbyderen behøver jo ikke tillade, at man sender emails med et andet
>domæne angivet som afsender. Hvis de vil tillade det bliver det
>nødvendigt med en passende procedure for at checke, at det faktisk
>er kundens adresse.
Hvis en opkoblingsudbyder ikke tillader at kunderne sender med en
afsenderadresse som hører til et webhotel kunden har andetsteds, så
tror jeg at den udbyder går glip mange kunder. Det ville simpelthen
være for ringe service nu til dags.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Asbjorn Hojmark (03-10-2003)
| Kommentar
Fra : Asbjorn Hojmark |
Dato : 03-10-03 22:47 |
|
On Thu, 02 Oct 2003 10:54:47 +0200, Jesper Dybdal
<jdunet@u9.dybdal.dk> wrote:
> Hvis en opkoblingsudbyder ikke tillader at kunderne sender med en
> afsenderadresse som hører til et webhotel kunden har andetsteds, så
> tror jeg at den udbyder går glip mange kunder.
Den anden mulighed er jo, at 'hoteludbyderen' tillader, at man
sender mail via dem, givet et sæt af sikkerhedsforanstaltninger.
-A
--
http://www.hojmark.org/
| |
Asbjorn Hojmark (29-09-2003)
| Kommentar
Fra : Asbjorn Hojmark |
Dato : 29-09-03 21:45 |
|
On Mon, 29 Sep 2003 11:24:36 +0200, "Peder Vendelbo Mikkelsen"
<pedervm@myrealbox.com> wrote:
> Jeg har svært ved at se problemet i, at min mailserver siger til en af-
> sendende mailserver "det der vil jeg ikke have, pak dig og gå væk".
Det har jeg også svært ved at forstå.
> Hvad den afsendende mailserver derefter gør, kan jeg vel ikke ligefrem
> klandres for, da det afhænger af hvordan den er opsat og drives.
>
> Hvis min mailserver ikke reagerer med en fejlmeddelelse, er jeg med
> til, potentielt, at forlænge spredningen af f.eks. en virus fra en
> inficeret maskine.
Mere væsentlig er det (for mig), at hvis man faktisk accepterer
mailen, så har man principielt også påtaget sig ansvaret for at
aflevere den til brugeren, og det gør man jo netop ikke, hvis man
*derefter* virusscanner den og smider den væk.
Det er mere 'rent' at se på, hvad man får smidt i hovedet, og med
det samme sige 'nej tak', hvis man ikke har tænkt sig at aflevere
det indhold til adressaten.
Hvordan afsenderens server- og/eller klient-software så håndterer
den situation, er basalt set afsenderens problem.
-A
--
http://www.hojmark.org/
| |
Jesper Dybdal (29-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 29-09-03 22:44 |
|
Asbjorn Hojmark <Asbjorn@Hojmark.ORG> wrote:
>Hvordan afsenderens server- og/eller klient-software så håndterer
>den situation, er basalt set afsenderens problem.
Ja - men det er den måske forfalskede, tilsyneladende afsender det
faktisk går ud over. Hvis afsenderen er forfalsket, hvilket den meget
ofte er når det er virus, så generer man en uskyldig.
Jeg har ikke selv oplevet det i mere end let irriterende grad, men jeg
har læst om folk som fik en hel masse eksemplarer af en virus, men
endnu mange flere bounces af den samme virus.
Hvis man akkurat lige så godt kan undlade at genere en uskyldig
tredjepart, så synes man skal gøre det.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Asbjorn Hojmark (29-09-2003)
| Kommentar
Fra : Asbjorn Hojmark |
Dato : 29-09-03 23:04 |
|
On Mon, 29 Sep 2003 23:43:54 +0200, Jesper Dybdal
<jdunet@u9.dybdal.dk> wrote:
>> Hvordan afsenderens server- og/eller klient-software så håndterer
>> den situation, er basalt set afsenderens problem.
> Ja - men det er den måske forfalskede, tilsyneladende afsender det
> faktisk går ud over. Hvis afsenderen er forfalsket, hvilket den meget
> ofte er når det er virus, så generer man en uskyldig.
Det er et praktisk problem, der primært hidrører fra, at man
(dvs. afsender-serveren) accepterer at transportere mail fra
brugere, som man ikke kender identiteten af.
Fra et principielt synspunkt, burde det være dét problem, man
søgte at løse, i stedet for at bøje reglerne for, hvordan man
skal forholde sig som modtager.
Nu skal man jo være forsigtig med analogierne, men prøv at følge
mig i, at man kunne gøre det samme ved telefoni, altså at jeg
kunne ringe fra min hjemmetelefon og præsentere 4585 1448 som
A-nummer.
Nu er mail desværre typisk implementeret sådan, at jeg kan
præsentere mig som Lyngby Politi, men hvis jeg gør det og der
sker en fejl ved det, er det vel trods alt bedre at Lyngby Politi
får det at vide, end at ingen gør det?
-A
--
http://www.hojmark.org/
| |
Jesper Dybdal (30-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 30-09-03 18:55 |
|
Asbjorn Hojmark <Asbjorn@Hojmark.ORG> wrote:
>On Mon, 29 Sep 2003 23:43:54 +0200, Jesper Dybdal
><jdunet@u9.dybdal.dk> wrote:
>
>>> Hvordan afsenderens server- og/eller klient-software så håndterer
>>> den situation, er basalt set afsenderens problem.
>
>> Ja - men det er den måske forfalskede, tilsyneladende afsender det
>> faktisk går ud over. Hvis afsenderen er forfalsket, hvilket den meget
>> ofte er når det er virus, så generer man en uskyldig.
>
>Det er et praktisk problem, der primært hidrører fra, at man
>(dvs. afsender-serveren) accepterer at transportere mail fra
>brugere, som man ikke kender identiteten af.
>
>Fra et principielt synspunkt, burde det være dét problem, man
>søgte at løse, i stedet for at bøje reglerne for, hvordan man
>skal forholde sig som modtager.
Det kan jeg kun være fuldstændig enig i.
Hvis alle udbyderes smtp-servere for udgående post fra kunder på en
eller anden vis vidste hvilke adresser der måtte komme fra hvilke
kunder, så ville det kunne gøres rigtig fint. Det er jo ikke helt
trivielt, for man skal jo gerne kunne sende med sin webhotel-adresse
som afsender, selvom man gør det gennem sin opkoblingsudbyder.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Asbjorn Hojmark (30-09-2003)
| Kommentar
Fra : Asbjorn Hojmark |
Dato : 30-09-03 23:15 |
|
On Tue, 30 Sep 2003 19:54:47 +0200, Jesper Dybdal
<jdunet@u9.dybdal.dk> wrote:
> Hvis alle udbyderes smtp-servere for udgående post fra kunder på en
> eller anden vis vidste hvilke adresser der måtte komme fra hvilke
> kunder, så ville det kunne gøres rigtig fint. Det er jo ikke helt
> trivielt, for man skal jo gerne kunne sende med sin webhotel-adresse
> som afsender, selvom man gør det gennem sin opkoblingsudbyder.
Jamen, det er jo muligt. Man kan fx bruge POP-before-SMTP, hvis
man ikke har andet at gøre godt med, og det burde alle rimeligt
opdaterede mailklienter kunne gøre. Og for dem der insisterer på
at bruge noget ældre, kan man jo tilbyde webmail som alternativ.
-A
--
http://www.hojmark.org/
| |
Jesper Dybdal (01-10-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 01-10-03 23:03 |
|
Asbjorn Hojmark <Asbjorn@Hojmark.ORG> wrote:
>On Tue, 30 Sep 2003 19:54:47 +0200, Jesper Dybdal
><jdunet@u9.dybdal.dk> wrote:
>
>> Hvis alle udbyderes smtp-servere for udgående post fra kunder på en
>> eller anden vis vidste hvilke adresser der måtte komme fra hvilke
>> kunder, så ville det kunne gøres rigtig fint. Det er jo ikke helt
>> trivielt, for man skal jo gerne kunne sende med sin webhotel-adresse
>> som afsender, selvom man gør det gennem sin opkoblingsudbyder.
>
>Jamen, det er jo muligt. Man kan fx bruge POP-before-SMTP, hvis
>man ikke har andet at gøre godt med, og det burde alle rimeligt
>opdaterede mailklienter kunne gøre. Og for dem der insisterer på
>at bruge noget ældre, kan man jo tilbyde webmail som alternativ.
Ja, det er meget bedre end ingenting.
Men en virus der fx lokker Outlook til at sende post for sig (det ved
jeg ikke om de gør i praksis), vil nemt have det problem at Outlook
kender password og bare leverer den rette SMTP authentication. Jeg
tror i hvert fald ikke et øjeblik på at ret mange
mailklientleverandører vil kræve at man manuelt indtaster password
hver gang.
Og måske kan en virus, hvis disse mekanismer bliver almindelige, finde
ud af at finde SMTP-auth-passwordet i registry'et, eller at lave en
POP-operation først.
En seriøse hindring af forfalskning af afsenderadresse kunne være
noget med at udbyderens mailserver for hver kunde (dvs. SMTP-auth
identifikation) havde en liste over afsenderdomæner (eller evt.
afsenderadresser) den ville acceptere. Så ville ingen virus kunne
sende med falsk afsender.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Lars Kim Lund (28-09-2003)
| Kommentar
Fra : Lars Kim Lund |
Dato : 28-09-03 16:29 |
|
"Peder Vendelbo Mikkelsen" <pedervm@myrealbox.com> wrote:
>> Det er også mit indtryk at ret mange af os netop i disse dage bliver
>> forskånet for tusindvis af eksemplarer af Swen.A-virussen fordi nogle
>> mailservere omhyggeligt undlader at overholde de RFC'er der ellers
>> fortæller hvad en mailserver skal gøre.
>
>Jeg har ikke tjekket, men jeg regner da med at mailserveren svarer
>tilbage med en 554 kode og en kort forklarende tekst, når antivirus-
>programmet har genkendt Swen og har besluttet sig for at afsenderen er
>en grim karl.
Det er vel de færreste AV produkter der scanner før de accepterer
modtagelsen i SMTP sessionen.
--
Lars Kim Lund
http://www.net-faq.dk/
| |
Asbjorn Hojmark (28-09-2003)
| Kommentar
Fra : Asbjorn Hojmark |
Dato : 28-09-03 23:04 |
|
On Sun, 28 Sep 2003 17:28:45 +0200, Lars Kim Lund <lkl@fabel.dk>
wrote:
> Det er vel de færreste AV produkter der scanner før de accepterer
> modtagelsen i SMTP sessionen.
En kunde lavede en Unix-kasse til at gøre det, og de smed mail
gennem 2-3 forskellige AV'er (almindelige kommandolinieting) før
de sagde OK for DATA. (De gør det sikkert sådan endnu).
Det er ikke voldsomt kompliceret at lave, når man først har fået
idéen.
-A
--
http://www.hojmark.org/
| |
Lars Kim Lund (29-09-2003)
| Kommentar
Fra : Lars Kim Lund |
Dato : 29-09-03 06:35 |
|
Asbjorn Hojmark <Asbjorn@Hojmark.ORG> wrote:
>> Det er vel de færreste AV produkter der scanner før de accepterer
>> modtagelsen i SMTP sessionen.
>
>En kunde lavede en Unix-kasse til at gøre det, og de smed mail
>gennem 2-3 forskellige AV'er (almindelige kommandolinieting) før
>de sagde OK for DATA. (De gør det sikkert sådan endnu).
>
>Det er ikke voldsomt kompliceret at lave, når man først har fået
>idéen.
Næ, ikke hvis man har en MTA, hvor det er muligt. Men jeg tænker på at
en asynkron scanning vil øge risikoen for at overbelaste MTA'en. Det
kommer naturligvis an på ens mail-politik og hvor meget hardware man
smider efter det ift. båndbredden,.
Principielt synes jeg det er en god idé at afvise det i SMTP sessionen
og lade ansvaret blive på afsender MTA'en. Jeg har dog også set
defekte mail-servere som ignorerer en 5xx fejlkode og insisterer på at
sende mailen indtil den timer ud.
--
Lars Kim Lund
http://www.net-faq.dk/
| |
Lars Kim Lund (29-09-2003)
| Kommentar
Fra : Lars Kim Lund |
Dato : 29-09-03 06:51 |
|
Lars Kim Lund <lkl@fabel.dk> wrote:
>>Det er ikke voldsomt kompliceret at lave, når man først har fået
>>idéen.
>
>Næ, ikke hvis man har en MTA, hvor det er muligt. Men jeg tænker på at
>en asynkron scanning vil øge risikoen for at overbelaste MTA'en. Det
>kommer naturligvis an på ens mail-politik og hvor meget hardware man
>smider efter det ift. båndbredden,.
En synkron scanning, mente jeg naturligvis.
--
Lars Kim Lund
http://www.net-faq.dk/
| |
Asbjorn Hojmark (29-09-2003)
| Kommentar
Fra : Asbjorn Hojmark |
Dato : 29-09-03 21:48 |
|
On Mon, 29 Sep 2003 07:35:20 +0200, Lars Kim Lund <lkl@fabel.dk>
wrote:
>> Det er ikke voldsomt kompliceret at lave, når man først har fået
>> idéen.
> Næ, ikke hvis man har en MTA, hvor det er muligt.
Jeg synes, det er så god en funktionalitet, at man bør have det
med i kravsspecifikationen når man vælger MTA. Og hvis man ikke
kan bruge den MTA man plejer, så vælger man da bare noget andet
til formålet.
> Men jeg tænker på at en asynkron scanning vil øge risikoen for at
> overbelaste MTA'en.
Oh well, så man kan jo sætte en større server op. Eller man kan
sætte flere MTA'er op og load-balancere dem.
-A
--
http://www.hojmark.org/
| |
Jesper Dybdal (28-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 28-09-03 23:50 |
|
Lars Kim Lund <lkl@fabel.dk> wrote:
>Det er vel de færreste AV produkter der scanner før de accepterer
>modtagelsen i SMTP sessionen.
Ja. Men vi er vist mange der har lavet et eksplicit og effektivt
filter på Swen.A på lavere niveau end en generel virusscanner, og så
har man valget mellem at afvise og at modtage og smide væk.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Peder Vendelbo Mikke~ (29-09-2003)
| Kommentar
Fra : Peder Vendelbo Mikke~ |
Dato : 29-09-03 00:42 |
|
Lars Kim Lund skrev:
> "Peder Vendelbo Mikkelsen" wrote:
>> Jeg har ikke tjekket, men jeg regner da med at mailserveren svarer
>> tilbage med en 554 kode og en kort forklarende tekst, når antivirus-
>> programmet har genkendt Swen og har besluttet sig for at afsenderen
>> er en grim karl.
> Det er vel de færreste AV produkter der scanner før de accepterer
> modtagelsen i SMTP sessionen.
Tjah, jeg så i en anden gruppe (.netmisbrug?) at en person havde lavet
et simpelt filter, hvor der var et par linier fra starten af den infi-
cerede fil som blev tjekket op imod det modtagne og afviste ud fra det.
Jeg kan ikke helt overskue om det er RFC-stridigt, at afbryde modta-
gelse af emails mens body modtages.
Hvad AV-programmerne gør, er sikkert meget afhængig af mailserveren.
| |
Jesper Dybdal (29-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 29-09-03 19:17 |
|
"Peder Vendelbo Mikkelsen" <pedervm@myrealbox.com> wrote:
>Lars Kim Lund skrev:
>
>> "Peder Vendelbo Mikkelsen" wrote:
>>> Jeg har ikke tjekket, men jeg regner da med at mailserveren svarer
>>> tilbage med en 554 kode og en kort forklarende tekst, når antivirus-
>>> programmet har genkendt Swen og har besluttet sig for at afsenderen
>>> er en grim karl.
>
>> Det er vel de færreste AV produkter der scanner før de accepterer
>> modtagelsen i SMTP sessionen.
>
>Tjah, jeg så i en anden gruppe (.netmisbrug?) at en person havde lavet
>et simpelt filter, hvor der var et par linier fra starten af den infi-
>cerede fil som blev tjekket op imod det modtagne og afviste ud fra det.
Det var såmænd nok mig der postede det filter.
>Jeg kan ikke helt overskue om det er RFC-stridigt, at afbryde modta-
>gelse af emails mens body modtages.
Det er jeg ret sikker på at man ikke kan. Det ville kræve at
afsenderserveren kunne lytte efter en fejlstatus samtidig med at den
sendte data, og det mener jeg ikke de gør. Man er nødt til at vente
til hele brevet er modtaget, og så give sin fejlstatus - det gør
postfix fx.
Hvis man bare afbryder forbindelsen, så prøver afsenderserveren igen
lidt efter, og det er jo ikke lige sagen.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Asbjorn Hojmark (29-09-2003)
| Kommentar
Fra : Asbjorn Hojmark |
Dato : 29-09-03 21:57 |
|
On Mon, 29 Sep 2003 01:41:33 +0200, "Peder Vendelbo Mikkelsen"
<pedervm@myrealbox.com> wrote:
> Jeg kan ikke helt overskue om det er RFC-stridigt, at afbryde modta-
> gelse af emails mens body modtages.
Er du sikker på, modtagelsen afbrydes (altså, at sessionen
smides) og at det sker *mens* body modtages?
Det lyder ikke klogt at gøre det sådan, da afsenderes server så
formentlig vil opfatte det som et transient problem og forsøge
igen senere.
Mest sandsynligt sker det dog også *efter* afslutningen af DATA,
og da har man ret til at sige kode 5xx, og dermed indikere, at
den mail ikke vil blive afleveret til adressaten.
-A
--
http://www.hojmark.org/
| |
Peder Vendelbo Mikke~ (30-09-2003)
| Kommentar
Fra : Peder Vendelbo Mikke~ |
Dato : 30-09-03 00:43 |
|
Asbjorn Hojmark skrev:
> "Peder Vendelbo Mikkelsen" wrote:
>> Jeg kan ikke helt overskue om det er RFC-stridigt, at afbryde modta-
>> gelse af emails mens body modtages.
> Er du sikker på, modtagelsen afbrydes (altså, at sessionen
> smides) og at det sker *mens* body modtages?
Nej, men det gik jeg ud fra. Jeg kender hverken postfix eller proc-
mail.
> Det lyder ikke klogt at gøre det sådan, da afsenderes server så
> formentlig vil opfatte det som et transient problem og forsøge
> igen senere.
Ok, så kan man ikke undgå at bruge båndbredde på at modtage hele
emailen.
| |
Asbjorn Hojmark (30-09-2003)
| Kommentar
Fra : Asbjorn Hojmark |
Dato : 30-09-03 06:26 |
|
On Tue, 30 Sep 2003 01:43:05 +0200, "Peder Vendelbo Mikkelsen"
<pedervm@myrealbox.com> wrote:
>> Det lyder ikke klogt at gøre det sådan, da afsenderes server så
>> formentlig vil opfatte det som et transient problem og forsøge
>> igen senere.
> Ok, så kan man ikke undgå at bruge båndbredde på at modtage hele
> emailen.
Mjo, en del afvisninger kan man da lave allerede efter HELO/EHLO,
fx hvis man har tænkt sig at droppe pga. et spam-filter. Men det
er klart, at hvis man afviser baseret på indhold, så er man nødt
til at se indholdet før man kan afvise det.
-A
--
http://www.hojmark.org/
| |
Kasper Dupont (30-09-2003)
| Kommentar
Fra : Kasper Dupont |
Dato : 30-09-03 15:43 |
|
Peder Vendelbo Mikkelsen wrote:
>
> Ok, så kan man ikke undgå at bruge båndbredde på at modtage hele
> emailen.
For de fleste er den tid personer skal bruge på at behandle
enkelte emails langt vigtigere end hvor meget båndbredde,
der bruges.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
Their business was zero and it was shrinking.
| |
Jesper Dybdal (30-09-2003)
| Kommentar
Fra : Jesper Dybdal |
Dato : 30-09-03 18:55 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>Peder Vendelbo Mikkelsen wrote:
>>
>> Ok, så kan man ikke undgå at bruge båndbredde på at modtage hele
>> emailen.
>
>For de fleste er den tid personer skal bruge på at behandle
>enkelte emails langt vigtigere end hvor meget båndbredde,
>der bruges.
I torsdags, inden jeg lukkede den adresse jeg i over et år har brugt
på Usenet, kom der lidt under én pr. minut. À ca. 150 kB.
Det betyder sjovt nok at mit daglige trafikforbrug blev sådan ca.
18-doblet af Swen. Fra ca. 10 MB/dag til ca. 180 MB/dag.
Jeg er glad for at det ikke er sådan en opkobling hvor man betaler 50
øre/MB (sådan en har jeg til sommerhuset, men der er heldigvis ingen
mailserver).
Det kunne egentlig være sjovt at vide hvor meget en stor udbyders
trafik stiger pga. sådan en.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).
| |
Carl Drud (27-09-2003)
| Kommentar
Fra : Carl Drud |
Dato : 27-09-03 10:13 |
|
Nielsen I wrote:
> Endvidere har jeg tjekket min ZoneAlarm, som skriver, at der har
> været 319 high-rated forsøg, men samtidigt står der også under
> INBOUND at der kun er blokeret 54 intrusions? Betyder det, at de
> resterende at de High-rates, der har været er gået 'igennem' for en
> hacker eller lign.? (undskyld, hvis det er et dumt spørgsmål).
Det er fordi "indbound" bliver nulstillet for hver start af
computer/firewall. De øverste to værdier er akkumulerede tal fra siden
firewall'en blev installeret.
"xxxxx intrusions has been blocked since install"
"xxx of those has been high-rated"
--
A. No.
Q. Does top-posting make sense?
| |
Spangkuk (27-09-2003)
| Kommentar
Fra : Spangkuk |
Dato : 27-09-03 11:52 |
|
Tak for linket
"Nielsen I" <liverpool3310@REMOVEPLEASEhotmail.com> skrev i en meddelelse
news:B33db.1878$9Z1.30@news.get2net.dk...
> En venlig bruger henviste mig til denne site http://grc.com/zonealarm.htm
> med henblik på at jeg kunne teste min pc her, hvilket jeg har gjort og
under
> File Share, fik jeg denne for mig betænkelige besked:
>
>
> 1. Attempting connection to your computer. . .
> Shields UP! is now attempting to contact the Hidden Internet Server within
> your PC. It is likely that no one has told you that your own personal
> computer may now be functioning as an Internet Server with neither your
> knowledge nor your permission. And that it may be serving up all or many
of
> your personal files for reading, writing, modification and even deletion
by
> anyone, anywhere, on the Internet!
>
> Som jeg læser det er min pc åben for fildeling, hvilket jeg ikke forstår,
> idet jeg under netværk i kontrolpanelet har fjernet fildelingsmuligheden.
>
> Endvidere har jeg tjekket min ZoneAlarm, som skriver, at der har været 319
> high-rated forsøg, men samtidigt står der også under INBOUND at der kun er
> blokeret 54 intrusions? Betyder det, at de resterende at de High-rates,
der
> har været er gået 'igennem' for en hacker eller lign.? (undskyld, hvis det
> er et dumt spørgsmål).
>
> Jeg synes ellers jeg gør hvad jeg kan for sikkerheden med Antivirus og
> Trojan scanner, men jeg kan ikke på denne testside finde noget om, hvad
jeg
> skal gøre, for at lukke denne tilsyneladende åbne fildeling, ligesom jeg
> ikke forstår, at der står, at der kun er blokeret for 54 intrusions. Er
det
> mig der blander tingene sammen eller hvad?
>
> Da jeg kørte (på samme testside) en scanning på mine porte, bestod
maskinen
> testen fuldstændigt, men det er jo ligemeget, hvis den alligevel er
vidtåben
> for alle og enhver i forbindelse med fildeling og hvis der er gået
> eventuelle hacking forsøg igennem blandt de eks. 319 high-rated forsøg.
> Hvordan skal jeg forstå denne test? Jeg har læst frem og tilbage på
> ZoneAlarms website, men synes ikke jeg kan finde noget lige om det.
>
> På forhånd tusind tak for enhver hjælp
>
> mvh
>
> Nielsen
>
>
>
>
>
>
>
>
>
| |
Alex Holst (27-09-2003)
| Kommentar
Fra : Alex Holst |
Dato : 27-09-03 13:21 |
|
Spangkuk <hohohoæøå@hihiæøå.dk> wrote:
> Tak for linket
Argh, den er slet ikke genial. Den er meget, meget i stykker.
--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org
| |
Spangkuk (27-09-2003)
| Kommentar
Fra : Spangkuk |
Dato : 27-09-03 18:11 |
|
> Argh, den er slet ikke genial. Den er meget, meget i stykker.
i stykker ??...hvordan ?
Spang
| |
Lars Kim Lund (27-09-2003)
| Kommentar
Fra : Lars Kim Lund |
Dato : 27-09-03 20:56 |
|
"Spangkuk" <hohohoæøå@hihiæøå.dk> wrote:
>> Argh, den er slet ikke genial. Den er meget, meget i stykker.
>
>i stykker ??...hvordan ?
Jeg tror det er Alex' måde at sige han ikke synes GRC/ZA er ret godt.
--
Lars Kim Lund
http://www.net-faq.dk/
| |
Spangkuk (27-09-2003)
| Kommentar
Fra : Spangkuk |
Dato : 27-09-03 21:06 |
|
> Jeg tror det er Alex' måde at sige han ikke synes GRC/ZA er ret godt.
ok, men det skyldtes jo nok port 1026....
Har jeg ret Alex ?
Spang
| |
Dan MOrtensen (27-09-2003)
| Kommentar
Fra : Dan MOrtensen |
Dato : 27-09-03 15:43 |
|
On Sat, 27 Sep 2003 00:27:26 +0200, "Nielsen I"
<liverpool3310@REMOVEPLEASEhotmail.com> wrote:
>En venlig bruger henviste mig til denne site http://grc.com/zonealarm.htm
>med henblik på at jeg kunne teste min pc her, hvilket jeg har gjort og under
Prøv evt.: http://www.qualys.com
Der er mulighed for at scanne gratis en enkelt gang eller to.
Meget detalieret og teknisk, og forslag til hvad man kan gøre.
--
/Dan MOrtensen
www.webgaden.dk
www.hpc-nord.dk
Svar ikke pr. mail, da din mailserver vil blive blacklisted
listme@listme.dsbl.org
Don't use my email - your mail server will be blacklisted.
| |
Holger Danske (27-09-2003)
| Kommentar
Fra : Holger Danske |
Dato : 27-09-03 16:41 |
|
Dan MOrtensen wrote:
> On Sat, 27 Sep 2003 00:27:26 +0200, "Nielsen I"
> <liverpool3310@REMOVEPLEASEhotmail.com> wrote:
>
>> En venlig bruger henviste mig til denne site
>> http://grc.com/zonealarm.htm med henblik på at jeg kunne teste min
>> pc her, hvilket jeg har gjort og under
>
> Prøv evt.: http://www.qualys.com
>
> Der er mulighed for at scanne gratis en enkelt gang eller to.
>
> Meget detalieret og teknisk, og forslag til hvad man kan gøre.
Med Sygate Pro, kommer denne besked, som, IMHO, er ganske udemærket...
"Our Apologies
Your Free Network Security Scan Interrupted.
A number of reasons could have caused the scan to interrupt.
For Example:
a.. Your host is inactive and does not respond to our QualysGuard
scanner.
b.. Your host is behind a firewall.
c.. Your host is not connected to the Internet.
Allan
--
-- Som aldrig har hørt om dårlige tabere i Russisk roulette --
-- Kun døde fisk flyder med strømmen --
-- Skønhed afhænger af øjnene der ser --
-- Cum insantientibus fuere necesse est --
| |
rea721 (27-09-2003)
| Kommentar
Fra : rea721 |
Dato : 27-09-03 17:00 |
|
Dan MOrtensen wrote:
> Prøv evt.: http://www.qualys.com
Ser fin ud
***
Congratulations
Your On-Demand Network Security Audit service did not find any
vulnerabilities on your system. However...
Using the QualysGuard® service, you would have detected Possible Threats and
additional information gathered from your system. Also, you would have the
opportunity to scan for single vulnerabilities and flag unauthorized
services and ports.
***
--
Rea721 AKA Leon Andrea skod1@721.dk http://721.dk
Bevar Eskadrille 721 på Flyvestation Værløse
Den sidste operative Flyvestation på Sjælland.
| |
Jesper Juul-Mortense~ (27-09-2003)
| Kommentar
Fra : Jesper Juul-Mortense~ |
Dato : 27-09-03 16:08 |
| | |
|
|