03. januar 2005 - 20:41Der er
38 kommentarer og 4 løsninger
eMule: sikkerhed / risiko for at blive hacket
INFO: Lad os sige at PC'en der kører eMule er sat sådan op: ADSL forbindelse Router - DHCP server / NAT - ingen porte åbne for eMule. (giver lavt id: det ved jeg) Win XP fuldt opdateret Norton Internet Security - Auto opdatering slået til - Portene TCP 4662 og UDP 4672 åbne for eMule (incomming) - Alle porte TCP + UDP åbne for eMule (outgoing) - Alle andre porte er blocked for eMule - Alle andre programmer (end eMule) er konfigureret ift. hvad NIS selv foreslår (eks: Microsoft Generic Host Process for win32 står til Automatic, Microsoft Internet Explorer står til Permit all, osv..) eMule kører som restricted client (ikke medl. af nogle grupper) - Deler kun default-mapperne temp og incomming
1. Hvad er det for en risiko jeg løber for at blive hacket ? - Og jeg mener IKKE risiko ved de filer man henter i eMule (om der f.eks. er virus i dem) - det lader jeg Norton om ...
2. De 2 åbne porte i firewallen: kan en dygtig hacker bruge disse 2 porte til at få adgang til/hacke min pc ?
3. De 2 åbne porte i firewallen: er kun åbne for eMule (..\program\emule.exe). Betyder det at en hacker skal finde/kende til et "hul" i eMule og hacke ad den vej eller er det muligt at bruge portene uden om eMule?
4. Hvad nu hvis PC'en der kører eMule er den samme som ovenfor, men IKKE har en router (=> PC'ens netkort får sin ip fra ISP og ikke som ovenfor af router DHCP)
Jeg vil meget gerne have uddybende svar (altså IKKE ja/nej) og meget gerne links til eksempler på folk der faktisk er blevet hacket pga. eMule.
1) Risikoen er vel lige så stor som ved alle andre netværksprogrammer. Hvis nogen ligger inde med et exploit, så har de dig.
2) Når du ikke forwarder portene i routeren, har det ikke nogen betydning at du åbner dem i firewallen.. routeren forhindrer jo at man opretter forbindelse til dig udefra.
Men når en port er åben, så er den åben. Dvs en hacker behøver ikke at gennembryde din firewall, han skal blot have genskab til sårbarheder i emule.
3) Man kan kun hacke det program som lytter på porten. Dvs man kan ikke hacke "Windows" igennem emule-porten.
4) Så er man jo lidt mere såbar, da hackeren kan etablere en forbindelse til din maskine udefra. Antag en hacker udvikler en orm baseret på et sikkerhedshul (i stil med blaster og sasser), hvis emule sidder direkte på internettet med åbne porte, så har han dig med det samme.
1. jo der er en forøget risiko ved programmer som eMule. Dels er det et program, med tilsvarende huller som alle andre programmer, der kan udnyttes. Dels er ideen ved eMule og lignende programmer at man deler ressourcer, der er her en stor risiko for at få delt tind der ikke skulle være delt. Det at du deler ressourcer betyder også at en evt. hacker allerede har et brohoved på din maskine der kan udnyttes. Endelig er eMule et aktivt program der annoncere over for eMule netværket at du er på. Det at du er aktiv og melder at du er på, kan udnyttes af en hacker, han behøver ikke lede efter dig eller vente på at du kommer på, han kan vente til du selv melder dig.
2. Sagtens. En dygtig hacker behøver kun et lille hul, så er han igennem og er et hul åbnet uden begrændsninger, så er det intet problem. De huller eMule laver er uden begrændsninger, hvorfor deter den slags enhver hacker elsker
3. Nej ikke nødvendigvis. Et hvert hul i et hvert program kan udnytte de prote eMule skal bruge. Med programmer Fpipe kan du pipe alt tcp trafik ud af andre porte, så det behøver ikke være eMule der har hullet, selvom det også sagtens kan bruges
4. Det eren fordel at have en router, da disse ofte har et vist mimimum at firewall funktionalitet indbygget, I forhold til hackeren gør det i første omgang ingen forskel om du har routeren stående hos dig selv eller den står hos din ISP 8du skal jo have en router et eller andet sted)Med routeren stående hos dig selv, kan du begrændse hullet mest muligt
Det teoretisk riktige svaret det er jo uten tvil at det er en betydelig sikkerhetsmassig rissiko ved å bruke slike program som Emule.
Den største risikoen den ligger jo ikke i at maskinen "blir hacket" i tradisjonell forstand, men heller i filinnholdet i de tingene som lastes ned.
Emule kan konfigureres slik at den kjører gjennom en firewall som er "100 prosent" lukket for all inngående trafikk. Man behøver ikke å konfigurere slik at det står noen inngående porter åpne.
Når hele forbindelsen kjører slik at det hele kjører kun i prinsipp som utgående trafikk så er det kanskje ikke så stor risiko for at det vil kunne skje en "hacking" i tradisjonell forstand.
For å være sikker på at man virkelig kjører med lukking for all trafikk inn så kan det være en god ide å kjøre gjennom en hardware firewall som sikrer dette.
Emule utnytter sånn sett ikke nødvendig vis noen "hull" i en firewall, (man kan med fordel benytte en hardware firewall som er 100 prosent lukket) derfor så behøver det sånn sett heller ikke å være noen slike huller til å kunne "hacke gjennom".
Ved siden av en hardware firewall som gir en ekstra sikkerhet, så vil det være en fordel å skanne for trojanere og slike ting med regelmessige mellomrom, for eksempel med Lavasoft. Dessuten så kan man jo benytte en trafikkmonitor til å kontrollere hvilen trafikk som virkelig flyter.
Dersom man for eksempel velger å sette opp en Linux maskin som hardware firewall så inneholder denne også en ganske utmerket trafikkmonitor som heter iptraf. Linux har også gode muligheter for å kunne konfigureres slik at den tar vekk den største risikoen ved bruk av emule og liknende programmer. Alternativt, dersom man ikke har en slik Linux boks så kan man kjøre trafikkmonitor på ens Windows maskin.
De største risiko for uten de tingene som kan ødelegge for egene data, det er hvis ens maskin blir brukt til dos angrep mot andre eller for e-mail spam relay. Hvis man har en hardware firewall, Linux eller en annen så kan man ha mulighet for å sette opp effektive firewall rules som hindrer dette.
Jeg ville imidlertid ikke sette opp et program som Emule på min ordinære arbeidsstasjon.
Det å anvende slike programmer som Emule medfører selvfølgelig en viss initiell risiko. Ved anvendelse av de riktige forholdsregler, så kan man stort sett, eller i hvert fall et stykke på vei kompensere for denne risiko.
En "sikker" emule installasjon, ville for eksempel være dersom man hadde 2 gamle PC til oppgaven. PC no 1 settes opp som Linux hardware firewall med riktig kontroll av inn og utgående trafikk. PC no 2 settes opp som "Emule stasjon". Denne kjører så som eneste maskin på et eget lan segment på innsiden av Linux firewall.
Det vil i de fleste tilfeller finnes en sikkerhetsmessig rissiko ved det å være tilkoplet internett. Det vil i de fleste tilfeller også være mulig å kompensere, mer eller mindre, for denne sikkerhetsmessige risiko.
Konfigurerer man Emule og PC slik at den er uten åpning for inngående trafikk, pluss at man fortløpende kontrollerer for virus og trojanere, samt at man aldri åpner rissikofiler, så er man jo et stykke på vei.
Dersom man ønsker å lage en trafikkmonitoring på ens Windows maskin, og hvis man ikke har en Linux boks til å la trafikken flyte gjennom (for monitoring) så kan man jo benytte TCPView fra Mark Russinovitch/Systeminternals. Har brukt TCPView i lang tid og synes det fungerer rimelig bra.
Når det gjelder formuleringen om at firewall skal eller kan være 100 % lukket for all inngående trafikk, så er jo dette selvfølgelig til dels en "skrivemåte".
Pointet er det att all komunikasjon skjer eller addreseres eventuelt via en ekstern server, slik som Emule har muligheten til. Firewall kan da være "lukket" i den forstand at det er "statefull inspection funksjonen" som lukker opp for den inngåednde trafikk all den tid at den registerer denne som returtrafikk til trafikk som er initiert eller satt opp innenfra. Firewall kan med andre ord være konfigurert som "lukket". Den vil så allikevell kunne lukke opp for den trafikk til Emule som den registrerer som returtrafikk.
Langbein: Jeg lærte noget nyt om eMule, at man ikke behøver at åbne firewallen (og routeren) for indkommende forbindelser - Men man downloader dog meget langsommere og man kan ikke bruge KAD. Men tak for det.
Jeg vil prøve at summere det I har sagt og som jeg tror jeg forstår:
Grundlæggende er der 3 problemer med eMule (eller p2p-programmer generelt): 1. PC'er online i længere tid af gangen og dermed potentielt i fare for angreb. 2. PC'ens ip publiceres til andre klienter og servere og en potentiel hacker kan derfor begynde at hacke på ip'en direkte. 3. Filerne man downloader kan indeholde virus, orme osv. En opdateret virusscanner er derfor en absolut nødvendighed, men vil ikke nødvendigvis finde alt !
Hvis en hacker kender til en exploit i windows kan denne bruges eller hvis en hacker kender til en exploit i eMule kan denne bruges. Men køres eMule som begrænset bruger (ikke medlem af nogle grupper, kun adgang til sine egne mapper) kan hackeren højst fucke eMule op (få den til at gå ned eller slette downloads osv.(ren teori-har aldrig hørt om det)) og dermed ikke gøre noget der egentlig er skadeligt for PC'en f.eks. bruge den som remailer eller hacke andre computere via PC'en. Det rigtig store problem er egentlig windows exploits, for da man jo som sagt er online og publicerer sin ip kan en hacker i ro og mag hacke windows, det kræver dog at han kan komme forbi routeren (her forudsætter jeg at man bruger NAT og ikke forwarder nogle porte) og forbi ens firewall (eks. NIS).
Så hvad skal man gøre hvis man ønsker at bruge eMule på en "sikker" måde: 1. Bruge et OS der bruger NTFS, så man kan køre eMule som begrænset bruger. 2. Holde sit OS opdateret 3. Bruge en firewall og antivirus der altid er opdateret 4.Skifte ip så ofte som muligt (min 1 gang om dagen) - Hvis du bruger en ISP med dynamisk ip, så Skift din MAC-adresse på netkortet (eller på routeren) ind imellem, så får du en ny ip. Hvis du har en fast ip - så kan du ikke! 5. Lad være med at åbne for indkommende forbindelser, altså ikke forwarde porte i routeren og ikke tillade indkommende trafik i firewallen. 6. Scan PC'en jævnligt med dit antivirus-program og evt. scan for spyware. 7. Vær opmærksom på at downloaded programmer sagtens kan indeholde virus/trojanere/spyware selv om din antivirus ikke finder den (før du har eksekveret programmet og dermed aktiveret den).
Langbein: Som du nok har bemærket, har jeg ikke kommenteret opsætningen med Linux, det er umiddelbart en løsning der er alt for omfattende for mig, først og fremmest fordi jeg ikke kender det eller nogensinde har beskæftiget mig med det. Jeg bliver nødt til at holde mig til en løsning med kun 1 pc med windows på (og en router).
Jeg har stadig ikke forstået følgende: Hvis jeg forwarder en port i routeren/åbner en port for indkommende trafik i firewallen til eMule.exe, kan denne port så også bruges til windows exploits eller kan den ene og alene bruges til at hacke eMule med?
Langbein: Jeg har prøvet at bruge TCPview, men jeg kan ikke finde ud af hvordan jeg adskiller en hacker fra en anden eMule klient (som jo er ok). Altså jeg kan ikke se hvad jeg får ud af at bruge det. Det vil sige, jo hvis jeg lukker eMule og der stadig er forbindelser; Er det det du mener?
Jeg kunne stadig godt tænke mig nogle praktiske eksempler på at nogle er blevet hacket pga./vha. eMule (eller andet P2P), for jeg har aldrig hørt om det, kun læst teoretiske artikler skrevet af dommedagsprofeter.
Bare lidt info: Mine gene oplevelser med eMule: Jeg har brugt eMule (og andre P2P) de sidste 5 år, både med og uden router, jeg har altid brugt en fuldt opdateret windows og en firewall (som NIS) der ligeledes var opdateret. Det eneste jeg har oplevet (udover masser af downloaded virusbefængte filer) er forsøg på angreb med trojanere og denail of service osv. Alt sammen noget min firewall har fanget (indtil nu :-)).
Hvis jeg forwarder en port i routeren/åbner en port>Som alle gode spørgsmål er der to svar. ja og nej.
indledningsvis (hackerens første angreb) kan kun udføres mod eMule, kun exploits mod eMule kan køres af mod dig, men.
Er hackeren inde, eller kommer han ind på en anden måde, f.eks via trådløs hacking, e-mail bagdør, crosssite scripting, vil han kunne udnytte den mappede eMule port til at få hvad som heldst ud af
Hvis du kender navne på de filer hvor passwords gemmes i, så prøv at søg på de navne i p2p programmer. Du vil blive orverraskede, hvor mange der urkitisk deler flere ressourcer de ikke burde over p2p netværk. hvis du ved hvad de kritiske filer hedder, så er alle p2p netværk guldgrupper.
Er vel faktisk stort sett enig i det meste. Kjørte en liten test med Emule for litt siden og kunne vel faktisk ikke finne eller avsløre noen åpenbare "feil". Kjørte med konfigurering slik at det var lukket for alle inngående porter. Syntes liksom dette var det mest naturlige ut i fra et "sikkerhetsstandpunkt".
Det er jo ellers ikke riktig at det at man har et "hull" eller to i ens firewall nødvendig vis medfører at en hacker "kommer inn". Hvis dette var tilfellet så skulle jo samtlige servere i denne verden bli hacket, ettersom samtlige servere ut i fra sin funksjon og virkemåte må ha inngående "hull" i firewall for at de skal kunne virke som servere.
Det er vel ingen ting som i utgangspunktet skulle tilsi at det skulle være enklere "å hacke" en Emule server funksjon enn en hvilken som helst annen server funksjon (Hvis vi da holder utenom problemstillingen rundt tvilsomme data på vei inn gjennom de ordinære fildelingsfunksjonene.)
En hvilken som helst server funksjon vil jo i utgangspunktet kunne være utsatt for forsøk på hacking, enten det dreier seg om en Web server, en ssh server, en ftp server, en dns server, eller hva det måtte være.
Jeg har ellers heller ikke hørt om et eneste tilfelle der en hacker har klart å "hacke seg inn" via Emule, slik at han for eksempel har klart å oppnå root/admin rettigheter over maskinen. Det skulle vært interessant å hørt/sett noen praktiske eksempler på dette, dersom det finnes (hvilket selvfølgelig ikke kan utelukkes).
Der i mot så er vel virus/trojanere som har spredd seg gjennom filinnholdet en kjent problemstilling.
Vedrørende Linux eller en annen hardware firewall: Dette behøver ikke være komplissert overhodet. Enten så kan man bruke en Linux som er spesialisert for formålet og som er lett å konfigurere http://www.smoothwall.org eller man kunne kjøpe en liten hardware firewall til 4-500 kr. Ville personlig være litt skeptisk til en software firewall som eneste beskyttelse og ekstern ip rett inn på PC, men det kan da selvfølgelig kjøre bra. Min erfaring det er at en hardware firewall kan fungere som medisin mot det aller meste.
Vedrørende bruk av TCPVIew: Hvis man kjører med åpne porter, der det normalt skal skje en pålogging, så kan man nok ikke med en slik trafikkmonitor se om det dreier seg om hacking eller "normaltrafikk". Da må man i så fall gå et sted videre og inspisere/lese datainnholdet i de pakkene som passerer, eller man kan lese disse nærmest på stikkprøvebasis. Da behøver man en protocol analyzer / packet sniffer: http://www.ethereal.com/download.html
"Hvis jeg forwarder en port i routeren/åbner en port for indkommende trafik i firewallen til eMule.exe, kan denne port så også bruges til windows exploits eller kan den ene og alene bruges til at hacke eMule med?"
De fleste "Windows exploits" er vel i utgangspunktet bare "synlige" på et lan, altså ikke i det miljø som Emule kjører i (typisk wan - internett).
I utgangspunktet så skal jo enhver server funksjon beskytte det underliggende operativsystem. Allikevell så viser det seg jo i praksis at det er mulig å for eksempel nå inn gjennom internettserveren på Windows 2000/2003 slik at man blir i stand til å eksekvere systemkommandoer og andre kommandoer på det bakenforliggende operativsystem. Likeledes så kan jo slike ting som MS ASP og PHP være utsatt for "angrep" med slike kodestrenger, for eksempel i en URL eller en datamengde at det gir de effekter som en hacker kan ønske seg, i en eller annen situasjon.
På tilsvarende måte så kan jo i prinsipp en hvilket som helst server funksjon inklusive også Emule kunne brukes som basis for et forsøk på en eller annen type hacking.
Når det gjelder de kjente server funksjonene som Apache og MS IIS så finnes det jo et omfattende rapporteringssystem som tar vare på og følger opp eventuelle feil når de oppdages. Hvordan dette ivaretas hos Emule, det vet man vel ikke, og i dette at man ikke vet så ligger det jo i utgangspunktet en sikkerhetsrissiko.
All teori, det er jo bare et mer eller mindre godt bilde av den praktiske virkelighet. Hvis man har kjørt Emule i fem år, (det har ikke jeg) så har man jo et ganske vesentlig argument.
I det hele så er det vel viktig å sette proporsjoner på ting, slik at man hele tiden tar høyde for "worst case". Hvi dette er å formatere opp en harddisk, så kan man vel klare det, i hvert fall hvis dette skjer hvert 5 år.
Det som man kanskje spesielt bør ta høyde for, det er etter min mening:
1. Desom en hacker skulle oppnå administratorrettigheter over min maskin, så vil han kunne bruke denne i utgangspunktet til alle typer kriminalitet, inklusive økonomiske forbrytelser. Den ip som da vil ligge igjen hos offret vil ikke være hackerens, men min ip.
2. Dersom det passeres ut trojanere på min maskin, for eksempel via fildeling, så vil min maskin kunne bidra til å spre et stort anntall kopier av denne trojaneren. Avsender ip: Min ip.
3. På tilsvarende måte så vil den kunne brukes til ddos angrep, for eksempel mot kjente kommersielle nettsteder, uten at jeg en gang vet om det (min ip).
4. Min PC vil kunne brukes til å sende ut eller å videreutsende spam, uten at jeg vet om det. (min ip).
Den største rissiko ligger vel kanskje ikke i Emule eller i noe bestemt program, men heller i hvilken grad den som bruker PC'er tenker over de tingene man holder på med og i hvilken grad man følger med i det som skjer.
Det kan vel godt hende at man kan Kjøre Emule i 5 år uten at det skjer noe, men man kan vel på den annen side klare å bli innblandet i ganske store ulykker uten hjelp fra Emule.
Noen brukermiljøer er slik at man stort sett ikke tenker, det kan for eksempel være barn som er brukere. Da må man kjøre ganske strenge sikkerhetsregler for de fleste ting. Hvis man har kontroll på hvem som er brukerne og man i det hele fortløpende tar høyde for det som kan skje, så kan man vel tillate seg noen flere muligheter. Da blir det jo i all enkelhet viktig å følge med og tenke over det som skjer eller kan skje.
Når deg gjelder problemstillingen rundt deling av passordfiler ved hjelp av Emule .. Hva kan man eventuelt bruke en passordfil til ? En eventuelt kryptert passordfil til en annen server .. hva kan man benytte den til ?
Kjenner ikke til noe praktisk eksempel der en hacker har gått inn på en PC via Emule og hentet ut en passordfil på den aktuelle serveren. (I historisk tid så hentet man vel ut passordfilene på Linux servere på denne måten, via webserveren.)
a. "Er hackeren inde, eller kommer han ind på en anden måde, f.eks via trådløs hacking, e-mail bagdør, crosssite scripting, vil han kunne udnytte den mappede eMule port til at få hvad som heldst ud af".
Hva menes med at "hackeren er inde" ? Menes det det at hackeren har oppnådd root eller administrator shell til PC ? (eller menes det noe annet ?) I så fall hvilken praktisk rolle spiller da en eksisterende kommuniksjonskanal via Emule noen praktisk rolle fra eller til ? (Hackeren ville jo da kunne sette opp den utadrettede kommunikasjon som han måtte ønske (?!)
b. "f.eks via trådløs hacking," Hva har trådløs hacking med Emule eller fildeling å gjøre. Betyr dette atter igjen at hackeren har skaffet seg root/admin shell til PC ? Har han da noen større bruk for Emule eller den komunikasjon som er satt opp av denne ?
c. "e-mail bagdør" .. Og dette vil i praksis si .. ??
d. "crosssite scripting" Hva har dette i praksis med problemstillingene rundt Emule å gjøre ? Hvordan og på hvilken måte ?
e. "vil han kunne udnytte den mappede eMule port til at få hvad som heldst ud af" Hvordan skjer så dette i praksis ?
Når det for eksempel gjelder muligheten til å få en root/admin shell adgang (hvis det er dette som menes med at hackeren "er inde") hvordan skulle dette i prinsipp kunne skje gjennom den kommunikasjon som kjører via Emule ?
Internett har jo et omfattende rapporteringssystem for de forskjellige sikkerhetsmessige utfordringer som finnes og de problemstillinger som finnes rundt om i hverden.
Finnes det praktiske rapporterte tilfeller der emule har vært årsak til at de problemstillinger som står beskrevet i spørsmål a til e faktisk har skjedd ??
(Kan huske at jeg har lest om ormer og slike ting som har spredd seg som data, men ikke noe stort mer enn det. Det kan jo ha skjedd en del andre ting allikevell.)
Synes problemstillingen er interessant og skulle like å finnu ut noe mer omkring de objektivt riktige svar på disse problemstillingene.
Forsøkte ellers å google litt for å finne konkrete og virkelig erfarte angivelser av sikkerhetsmessige brist ved Emule. Fant egentlig ikke særlig mye om det. Fant en artikkel om buffer overflow her:
Dette er jo et typisk eksempel på hvordan man i større eller mindre grad kan klare å bryte gjennom sikkerhetsbarierene i en server funksjon og nå inn til det bakenforliggende operativsystem.
En bufferoverflow mulighet, der er jo ikke noe som er spesielt for Emule. Dette er jo noe som nær sagt alle server systemer har vært utsatt for i større eller mindre grad og på ett eller annet tidspunkt (til det har blitt rettet.)
Finner ingen ting så langt av konkrete eksempler at Emule har medført en spesielt stor sikkerhetsmessig rissiko, med unntak av det som har med selve data innholdet å gjøre. Eller finnes disse eksemplene ?
Forøkte også å gå inn på diskusjonsforumet til Emule for å finne ut om det fantes rapporterte tilfeller der man har blitt hacket via Emule eller der brukerne har opplevd sikkerhetsmessige problemer pga emule.
det ser faktisk ikke ut til å være tilfellet (??!!)
(Synes det er ganske interesant å se litt inn på denne problemstillingen rundt Emule/fileshare og sikkerhet :-) (Mon virkeligheten er en annen enn det som man kanskje umiddlbart vil ha lett for å tro ??)
Dette at Emule eller andre p2p skulle gi et godt utgangspunkt for "tradisjonell hacking", ser ikke ut til å være beskrevet noe sted .. Problemstillingene ser ut til å være relatert til selve datainnholdet ..
Det ble visst kanskje litt vel mye dette, men liker å gå problemstillingene litt etter i sømmene i stedet for bare å akseptere den aller første og enkleste konklusjon.
Tror faktisk jeg må revidere mitt syn på Emule en smule. "Alle" vet jo at det er en vedtatt sannhet at for eksempel Emule medfører en del sikkerhetsmessige problemstillinger, men går man litt inn i denne problemstillingen, så finner man at denne problemstillingen er ganske nyansert.
Ut i fra den måte som Emule kan kommunisere på, uten at inngående porter er åpnet, så vil det være heller komplisert å stanse denne trafikken vha en tradisjonell firewall. (Fordi den ikke vil kunne se forskjell på den trafikk som Emule står for og annen trafikk.) Dette betyr vel i praksis at det kjører en del Emule installasjoner der de var forutsatt å ikke skulle være.
Til tross for det så ser det ut til å være i nokså få tilfeller at det faktisk har skjedd noen tradisjonell "hacking" via Emule.
Skulle det en dag være slik at noen skulle klare å få root/admin accsess via Emule på en PC som står inne på LAN bak en firewall, for eksempel i en bedrift, så ville jo dette kunne få særdeles uheldige konsekvenser. Emule bør sånn sett ikke forekomme i et bedriftsmiljø.
For et hjemme PC miljø så blir det vel kanskje litt andreledes. Man må i all enkelhet vurdere risiko opp mot nyteverdi.
Da jeg testet ut Emule så kjørte jeg uten åpne porter inn, og jeg benyttet ikke noen personal firewall på maskinen.
Uten at jeg faktisk har prøvd dette, så skulle man vel egentlig tro at det å kjøre en prosessorientert firewall på den maskinen som har Emule installert ville være en god ide, for eksempel Zonealarm eller noe liknende.
Når det gjelder de største risiko, knyttet til spam utsendelse, ddos angrep, hacking mot andre maskiner og automatisert utsendelse av trojanere eller virus, så bør vel en prosessorientert firewall i de fleste tilfeller fange opp dette. (For eksempel Zonealarm.)
Når man ganger ut sansynligheten for at en hacking skal kunne skje via Emule med sannsynligheten for at en hacker skal klare å gjennomføre sine aktiviteter uten å bli avslørt av en personal firewall, så vil jeg tro at man kommer opp med en sikkerhet som ikke er så helt galt, for et hjemmedatanettverk. (Selvfølgelig så bør man ikke la det ligge sensitive opplysninger på en makin som har Emule intallert.)
sven-sveder -> I det hele og store så vil jeg mene at dine konklusjoner er korrekte.
a. Hva menes med at "hackeren er inde" ? Menes det det at hackeren har oppnådd root eller administrator shell til PC ? > Ja det er det jeg mener, og her er det faktisk afgørende at der er huller ud. Det at han er root eller administrator på den lokale maskine, kan han jo ikke udnytte hvis der ikke er udgående huller i firewallen. Læs min artikel om overvejelser omkring firewall regler http://www.eksperten.dk/artikler/554 . Er han først inde og kan hente programmer som f.eks. Fpipe, behøver han kun at f.eks. port 53 eller 25 er sat løst op for at kunne pipe ud af dem. Hvis eMule er tilstede og der i firewallen er åbnet for denne kommunikation uden restriktioner, vil han kunne udnytte dette. Helt generelt er det sådan at jo flere huller og muligheder en hacker har, jo svære er han at standse og finde. Og jo svære er det at sikre at han er helt ude b. "f.eks via trådløs hacking," Hva har trådløs hacking med Emule eller fildeling å gjøre. Betyr dette atter igjen at hackeren har skaffet seg root/admin shell til PC ? > Jep, trådløs hacking er endnu en måde at skaffe sig adgang til en maskine. Læs denne practicals kapitel 4 http://www.giac.org/practical/GCFW/Kim_Guldberg_GCFW.pdf, hvor jeg udnytter det trådløse netkort samt trådløse net på en direktørs bærbare maskine og hans private netværk, til at hacke firmaet. Igen udgør eMule endnu en udgang. c. "e-mail bagdør" .. Og dette vil i praksis> Samme som ovenstående d. "crosssite scripting" > Samme som ovenstående e. "vil han kunne udnytte den mappede eMule port til at få hvad som heldst ud af"Hvordan skjer så dette i praksis> Du opsætter f.eks. Fpipe til at pipe f.eks. ftp trafik ud af eMule porten hvis du har brug for FTP. Du opsætter så en (vi kan jo kalde den) Fpipe proxy server, hos dig selv, der modtager ftp trafikken på eMule porten og så piper den tilbage til de oprindelige ftp porte f. Når det for eksempel gjelder muligheten til å få en root/admin shell adgang (hvis det er dette som menes med at hackeren "er inde") hvordan skulle dette i prinsipp kunne skje gjennom den kommunikasjon som kjører via Emule > Via huller i eMule og exploits. Det tog mig mindre end 30 sekunders søgning på securityfocus at finde et eMule buffer overflow der potentielt kunne udnyttes. Se her http://www.securityfocus.com/bid/10039/info/ g. Finnes det praktiske rapporterte tilfeller der emule har vært årsak til at de problemstillinger som står beskrevet i spørsmål a til e faktisk har skjedd ??> Jeg har ikke kunne finde nogen andre end dem på securityfocus, men hvis de findes her, så er de normalt også blevet udnyttet h. Synes problemstillingen er interessant og skulle like å finnu ut noe mer omkring de objektivt riktige svar på disse problemstillingene. >Jeg tror ikke der findes nogle helt objektive rigtige svar
Vil forsøke å tenke gjennom tingene litt bedre, men griper umiddelbart og på sparket tak i den ene problemstilling, f, buffer overflow -
Det er jo ganske normalt at så godt som alle serverfunksjoner har problemstillinger relatert til buffer overflow, og at disse tettes fortløpende tettes som en resultat av et fortløpende vedlikehold.
Det er imidlertid, slik som jeg ser det et hav av avstand mellom det å konstantere en buffer flow feil i programvaren, til det å oppnå root/admin shell access over serveren som helhet.
Når det gjelder den konkrete melding på securityfocus, så kan man lese som følger:
2. Den problemstilling som kan oppstå som følge av bufferoverflow er i utgangspunktet ikke at en hacker får kontroll over maskinen, men der i mot at tjenesten, eller deler av denne (Emule/chat program) går ned. http://www.securityfocus.com/bid/10039/discussion/
Successful exploitation would immediately produce a denial of service condition in the affected process.
Men så står det også videre:
This issue may also be leveraged to execute code on the affected system within the security context of the user running the vulnerable process.
Dette er jo en hypotese eller en spekulasjon. Det er jo en ganske stor avstand mellom en hypotese om at det kanskje er mulig å eksekvere systemkommandoer, til det at man virkelig har oppnådd å utføre systemkommandoer på en slik måte at man virkelig har oppnådd root/admin shell kontroll, eller at det har blitt oppnådd en tilsvarende tilstand.
Her er det jo ellers interessant å merke seg svend_sveder sine opplysninger om at han kjører Emule programmet ut fra en bruker med begrensede rettigheter, dvs ikke i regi av admin konto. Denne buffer overflow problemtaikk skulle altså i høyden kunne medføre at en meget sofistikert hacker i et hypotetisk tilfelle skulle kunne klare å utføre systemkommandoer med ikke prioriterte rettigheter.
"The vendor has released an upgrade dealing with this issue."
Dette viser jo at Emule prosjektet har et vedlikehold, og et rapporteringssystem i forhold til sikkerhetsmessige problemstillinger som i prinsipp fungerer likt med det som finnes hos de kommersielle leverandørene og det som finnes i forbindelse med utvikling av Linux.
Mener at den refererte rapporten hos securityfocus bygger opp under et inntrykk at Emule faktisk har et sikkerhetsmessig opplegg som er bedre enn det man kanskje skulle tro.
Kvalitetssikring gjennom globale feilrapporteringssystemer, det var vel noe som ble funnet opp av den amerikanske flyindustrien på 50 tallet, eller kanskje noe før. Mon ikke det var den militære del av denne industrien som for alvor var pionerene.
Etterhvert som komplesiteten i den tekniske konstruksjonen økte på, samtidig som konsekvensene av ulykker kunne være ganske store, så behøvde man et system for å ta vare på dette.
Det man da gjorde det var at man laget et globalt rapporteringssystem der man rapporterte alle feil av betydning til en sentral oppfølgingsenhet for disse feilene. Denne oppfølgingsenheten laget man todelt med paralelle funksjoner hos luftfartsmyndigheter og flyfabrikker.
Man sluttet å betrakte luftfartøene som ferdig konstruerte når de ble satt i drift. Det dreide seg kun om revisjon nummer en. Etterhvert som det ble opparbeidet driftserfaringer gjennom systematisk rapportering og statistikkføring så sendte den sentrale oppfølgingsenheten for teknisk kvalitet forløpende revisjonsanmodninger, der de forskjellige driftsoperatørene av flymateriell fortløpende innarbeidet de modifikasjoner som man vurderte som nødvendig på basis av en global rapportering for alle luftfartøy.
På denne måten så kunne man slå fast objektive fakta av typen: Gearboks a har feilet 3 ganger i løpet av 8 millioner driftstimer. I ingen tilfeller så har dette medført en fatal betydning for flysikkerheten.
Et av de kjente tilfellene av slik oppfølging det er jo problemstillingen rundt 3 motors DC 10 fly, for noen år siden der flere fly mistet en av motorene, med flere havarier som resultat. Etterhvert så klarte man å fange opp en feil ved innfestingen av motorene, slik at samtlige fly på verdensbasis etterhvert ble modifisert i forhold til dette.
Etter hvert så har jo mange industrigrener adaptert dette prinsippet eller systemet for kvalitetssikting gjennom mer eller mindre systematisk rapportering og en sentral oppfølging, og påfølgende modifikasjoner som følge av dette.
Den største rissiko for en server funksjon, det må vel være dersom det ikke finnes noe slikt oppfølgingssystem. Alle progammer og alle servere har vel feil, og problemer med såkalt "bufferower flow" er vel en klassiker der stort sett alle servere har en feilrettingshistorie.
Det mest tvilsomme med en hvilken som helst server, Emule eller et hvilket som helst annet program, det er hvis det ikke finnes noen slik oppfølging, for eksempel fordi all videreutvikling ble lagt ned for noen år siden. Dersom det da blir funnet feil som "bare" hackere kjenner til og som ikke blir korrigert over lang tid, så kan jo dette gi en del potensiell risiko.
Gjennom at det finnes et levende miljø og rapporteringssystem rundt en server eller en programvare, så kan man for eksempel forholde seg til objektive fakta av typen: Det finnes ca 8 millioner installasjoner av programvaretype x på verdensbasis. På basis av dette så er det rapportert y antall feil av type a,b og c.
Man vil så kunne vurdere hvordan man kan unngå eller begrense skadevirningen av feil a, b og c, eller om man vil vurdere feilene som så alvorlige at man ikke vil benytte programvaren.
Er stadig vekk stort sett enig i konklusjonene til sven_sveder.
Vil forsøke å tenke litt over de øvrige problemstillingene rundt root/admin access litt senere ..
For å sette ting litt i perspektiv .. søker man på "emule" så finner man ca 8 rapporterte tilfeller om sikkerhetsmessige problemstillinger, der ingen ser ut til å være spesielt eller særlig alvorlige.
Søker man alternativt for eksempel på "Apache" eller "IIS" som er Linux og Microsoft sine webservere så finner man om lag 10 ganger så mange rapporterte feil, hvor av "buffer overflow" er en gjenganger.
Mener at det i dette tilfellet er et objektivt faktum at Emule har færre rapporterte feil enn for eksempel verdens mest brukte webservere (en annen problemstilling, det er jo også "hvorfor er det da slik ?"
Man kan jo ellers også forsøke å sammenlikne Emule med andre kjente serverfunksjoner.
Det har i følge Securityfocus blitt rapportert ett enkelt tilfelle av feil hos Emule som rent hypotetisk kan medføre en sikkerhetsmessig rissiko i løpet av året 2004. På basis av dette så har teamet bak Emule laget en enkelt sikkerhetspatch.
I løpet av året 2004, hvor mange rapporterte feil hadde man for operativsystemet Windows XP, og hvor mange sikkerhetspatcher behøvde man å gjennomføre for å holde sikkerheten innenfor akseptable rammer ?
... Læs denne practicals kapitel 4 http://www.giac.org/practical/GCFW/Kim_Guldberg_GCFW.pdf, hvor jeg udnytter det trådløse netkort samt trådløse net på en direktørs bærbare maskine og hans private netværk, til at hacke firmaet.
Er det du som har laget denne rapporten ? Imponerende flott i så fall !
Rapporten er en en del at GCFW certificeringen. Du skal bestå en bunden rapport på max 100 sider med 4 opgaver samt 2 examnier med mere end 70% rigtige får at bestå. Opgaven i linket er min
This issue may also be leveraged to execute code> Denne formulering er ganske normal at finde på bogtrac (bid står for bugtraq ID). Et bufferoverflow udvikler sig oftefra en DOS condition til root access. Grunden til at udviklingen og formuleringer er som den er, eregentlig naturlig nok. Bufferoverflowet findes ved at en DOS situation opstår, herefter findes de præcise konditioner for at DOS situationen opstår og til sidst skrives et exploit der giver access. Du kan finde talrige eksempler på dette, og hvis du venter lidt kan du være heldig at også dette overflow udvikles, eller du kan gøre det selv. Som du ser under exploit tabben er kodestrengen til overflowet lavet, så er det ikke en uoverskuelig opgave at lave et exploit derkunne give root access.
Grunden til at jeg valgde dette overflow, var at det lige var det jeg faldt over, med lidt mere tid kunne jeg sikkert finde et andet og mere brugbart.
Antallet af fundne huller hænger ofte sammen med udbredelsen, det er derfor du finder flere huller i apache og IIS. Jeg er sikker på at du selv kunne finde huller i f.eks. eMule hvis du satte dig for det. Det kræver ikke nødvendigvis den store viden, mere lidt viden og så masser af hårdt arbejde
"Et bufferoverflow udvikler sig oftefra en DOS condition til root access."
Det vil jo komme litt ann på for eksempel hvilket operativsystem det hele kjører på, minneadresseringsskjemaer, osv. I dette tilfellet så er det vel ikke umiddelbart noe holdepunkt for å hevde en slik sammenheng. Folkene hos securitufocos ser ut til å være av den samme oppfattning, sitat:
"Successful exploitation would immediately produce a denial of service condition in the affected process. This issue may also be leveraged to execute code on the affected system within the security context of the user running the vulnerable process."
For å utheve litt: "within the security context of the user running the vulnerable process" .. med andre ord ingen root/admin access men eventuelt restriktet av den brukerkonto som har prosessen kjørende.
Mener at noe av det som triller ut av diskusjonen over det er at det så langt ikke finnes et eneste konkret kjent rapportert tilfelle der noen reelt sett har klart å hacke en PC via Emule.
Tilsvarende så må man kunne argumentere ut fra et prinsipp basert på sansynlighet omtrent slik:
a. Finnes det kjente rapporeterte tilfeller der en PC har blitt hacket via Emule ?
b. Finnes det noen kjente rapporterte tilfeller der noen har kommet til skade ved bilkjøring ?
Hvis man vurderer disse to rissikosituasjonene, det å kjøre bil eller det å ha Emule kjørende, hvordan sakl man vurdere disse to rissikosituasjonene, med de aktuelle sannsynlige eller mulige konsekvensene opp mot hverandre ?
Jeg mener at sett opp mot de risikosituasjoner vi er utsatt for til daglig, på Internett og alle steder, kan det å kjøre Emule på en PC sikkres såpass godt at dette rent sikkerhetsmessig kan være forholdsvis forsvarlig.
Det er nok rett at det kanskje ikke finnes så mye systematisert rapportering rundt Emule som for eksempel web serverne, ut i fra en betrakning om hvem som normalt vil være brukerne. Allikevell så tror jeg nok at Emule pådrar seg en ganske høy grad av oppmerksomhet i forhold til bedriftsmiljøer fordi den er egnet til i noen grad "å punktere", dvs å sette opp åpninger gjennom, i hvert fall noen av virksomhetenes firewalls. Emule og slike programmer bør av den grunn, slik som jeg ser det ikke forekomme i et bedriftsmiljø ut i fra en betrakning at det ikke kan være opp til den enkelte bruker å sette sikkerhetspolicy for hele virksomheten.
restriktet av den brukerkonto som har prosessen kjørende.>Ohh ja, oftest dumper disse conditioner under contest af system, hvorefter det eren formsag at elevere rettighederne til root. Bare det at du kan eksekvere kode på en maskine er meget ofte det samme som root access i den sidste ende, med mindre brugeren har gjord rigtig meget for at hardne den, og så vil sårbarheden oftest slet ikke findes.
Min oplevelse er:
Hvis sårbarheden har potentialet for at køre abitrær kode, så vil et exploit blive lavet før eller siden. koden køres altid i den kontext applikationen køre under, men deter ikke et problem, da rettighederrelativt let kan eleveres hvis du først har access. Hvis sårbarheden eksistere på maskinen, er der oftest ikke gjort noget videre for at hardne maskinen, hvorfor root access kan opnås.
kan det å kjøre Emule på en PC sikkres såpass godt at dette rent sikkerhetsmessig kan være forholdsvis forsvarlig.>
Her er jeg uenig. Der er ingen af mine brugere der får lov til at kører nogen former for p2p programmer overhoved. Hverken eMule eller andre. Det er fyringsgrundlag at anvende den slags på firmaets maskinel og fra firmates netværk. Ikke engang Messenger er installeret
Er ikke helt enig i at det er så lett å heve rettighetene sånn rent umiddelbart. Tror at det da ikke ville finnes så mange servere tilbake, der brukerne for eksempel i noen grad har shell access.
Er som sagt enig i at Emule ikke kan ha noe i et bedriftsmiljø å gjøre. Det må eventuelt være en sak for hjemmedatanlegget. Er også enig i at Emule og MS Messenger faktisk har enkelte egenskaper til felles, slik at en gjennomført logisk konsekvens av å forby den ene blir at man også forbyr den annen.
Tror at det da ikke ville finnes så mange servere tilbake, der brukerne for eksempel i noen grad har shell access.>Det er præcist grunden til at jeg kører med fysisk adskildte systemer. Der findes intet materiale på de servere mine brugere har fysisk adgang til, som de ikke er klassificerede til at måtte se. I praksis betyder det faktisk at jeg har brugere der har adgang til (optil) 4 forskellige maskiner, fordi de har behov for at tilgå materiale af forskellige klassifikations grader.
En maskine du har fysisk adgang til, enten fordi du sidder ved den eller fordi du har shell adgang over net, er i min verden pr. definition usikker. Alle vores internetmaskiner er enten stand alone, eller på et særligt internetnet
Mener prinsippielt at det forholder seg slik at sikkerhet ofte koster penger og at den kan redusere funksjonalitet.
Dersom man innførte et påbud om hjelm, knebeskyttere og et blinkende rødt lys for alle fotgjengere i trafikken, så ville dette sikkert redusere antall skadet. Likeledes så ville et effektiv fartsgrense på 50 km også kunne virke positivt. Dersom ingen svømmer eller bader eller er i nærheten av vand så vil heller ingen drukne.
Det vil kunne variere en hel del hvor mye sikkerhet man har behov for og hvor mye sikkerhet man ønsker.
Noen vil kunne synes at det tryggeste er å sitte hjemme og se på TV mens andre setter pris på å padle kajakk eller å klatre i fjell.
På tilsvarende måte så må datasikkerhet også kunne tilpasses de behov som man faktisk har i forhold til funksjonalitet, aktivitet og sikkerhet.
På samme måte som det er mulig å padle kajakk uten å drukne så er det også mulig å kjøre en emule installsjon uten å bli invadert av virus og hackere.
På et hjemmenettverk, så kan man godt kjøre Emule, dersom man finner risikoen ved dette akseptabel, all den tid at det først og fremst er en selv det går ut over. (Men det kan også gå ut over andre.) Man må i det hele være bevist ansvaret i det man gjør.
På et berdiftsnettverk så utsetter man i prinsipp ikke bare egen PC men også hele nettverket for risiko. Derfor så er Emule på bedriftsnettverk i utgangspunktet uakseptabelt. Emule spiser også båndbredde, og det er også en grunn.
En annen problemstilling, det er at de personer som setter opp og driver bedriftsnettverk godt kunne tenke wan tenknologi i stedet for lan teknologi, slik at man deler inn nettverket i sikkerhetssoner i form av separate adskilte sikkerhetssoner. På denne måte så kunne sikkerheten på lokalnettverket bli den samme som den er mellom de forskjellige enhetene på Internett.
Undskyld jeg bryder ind, men jeg har et lille, men meget vigtigt hængeparti. I ser ud til at være nogle hajer på det her område. Har I lyst til at hjælpe mig med http://www.eksperten.dk/spm/576653?
Mange tak for jeres indlæg og links - meget interessant. Meget flot behandling I har givet mig!
Jeg er klar til at afslutte og give points, men jeg har lige en ide:
Er der en af jer (eller andre som læser dette) der ville være interesseret i at prøve at hacke min pc (I får min ip, jeg fortæller jer om hele mit setup (hw/sw) og jeg holder eMule tændt og min pc online) ?
Det ville være den ultimative (og objektive) test/bevis - eller hvad :-)?
Har mottatt svend_sveder sin ip og gjennomført en scan mot hans adresse. Hans firewall er 100 % lukket selv om han opplyser at emule kjører. Det er absoulutt ingen ting "å gripe fat i" for å kunne gjennomføre en hacking. Det er heller ikke mulig å oppnå en slik kontakt med serveren som behøves for å utnytte det buffer overflow problematikk som står beskrevet over. Det kan se ut som om at det for "en tilfeldig hacker utenfra" vil være betydelig mer komplisert å hacke sven_sveder sin emule installasjon enn det vil være å hacke en hvilke som helst web server, ftp server, telnet eller ssh server. Her vil det jo være mulig å opprette en dialog i forhold til serveren slik at man i det hele har noe å gripe fat i for et eventuelt hacker angrep. (Han kjører nå med samtlige inngående porter lukket.)
Skulle man ha noen mulighet så måtte man eventuelt på en eller annen måte opprette en kontakt via en felles emule pålogging. Tror det i praksis ville tatt ganske lang tid, i det hele å finne sven_sveder sin emule file share, selv om jeg vet hans ip (?!)
sven_sveder -> Din firewall eller internett tilkpling gir ingen respons som helst, slik som du hadde konfigurert tingene da jeg testet (med en "lett" portscan.) Dette vil si at det ikke synes i det hele tatt at PC er koplet opp mot internett eller at det finnes noen servere kjørende.
Den første "runde" i et hacker angrep, det er jo å scanne nettet for noen passende "objekter" å angripe. De som ikke gir noen respons overhodet, de vil man passere forbi. De vil være de minst interessante. "Alle" andre servere, enten det dreier seg om web servere, ftp, ssh, telnet, hva det måtte være vil gi en respons som en hacker vil kunne forholde seg til som et utgangspunkt for en hacking. Dette er altså i utgangspunktet ikke tilfellet med Emule. (Jeg går ut fra at du har konfigurert med lukking av alle inngående porter, når responsen blir slik, og at jeg ville ha sett de åpene portene, hvis det var noen. Med åpne porter så ville jo også emule ha gitt en respons.)
Den "eneste" måten å komme i dialig på, for å utnytte eventuelle muligheter for buffer overflow, etc det ville vel være hvis jeg selv også var koplet opp mot "en felles" emule server og at jeg i forbindelse med dette oppnådde å få satt i gang overføring av filer mellom våre PC'er. Hvis jeg kunne se at denne trafikken var etablert og i gang så kunne jeg i teorien forsøke å utnytte denne etablerte kanalen for datatransport.
Har ikke prøvd noen slik litt avanserte metoder, kun en "lett" portscanning, og ut i fra denne så ser det hele i hver fall ut til å være "sikkert".
Den neste "runde" eller "trinn" i et ordinært hackerandrep, det ville vel kanskje være å forsøke med litt "tyngre skyts" dvs forskjellige dos liknende teknikker, dvs man overfører større megder data, hvor ved man forsøker å finne fram til forskjellige svakheter under noe tyngre belastning.
Forutsetningen for et slikt "trinn to angrep" det er vel "vanligvis" at man førts har gjennomført et innledende "sweep" der man først med enkle og "lette teknikker" kartlegger de objekter som er egnet for videre angrep.
Det finnes i denne sammenheng automatiserte "sweep tools" som gjør at man vil kunne kartlegge tusenvis av ip i løpet av sekunder eller minutter. Det ser ut som om at en emule installasjon med alle porter lukket ikke vil bli funnet. Alle ordinære server funksjoner vil bli funnet. Likeledes så vil man umiddelbart kunne "se" eventuelle Windows maskiner som kjører uten firewall.
Ut i fra et slikt innledende sweep så vil hackeren, etter å ha kjørt gjennom for eksempel alle kundene til en leverandør av adsl oppkopling, sitte igjen med en liste over de mest interesante objektene for videre angrep. Her vil hackeren så typisk kunne gjøre et utvalg av de objekter han har spersielt stor kompetanse på. Er han dyktig på Windows, så finner han fram til de windows maskiner på, sin liste, som kjører uten firewall. Han vil så kunne plukke ut for eksempel 10 objekter på listen som han bestemmer seg for å jobbe videre med, for eksempel for å få plassert ut en trojaner. En annen hacher vil kanskje være "spesialist" på en type webservere, slik at han vil konsentrere den videre innsats mot de serverne av denne typen han finner på listen sin. Når Emule kjører med åpne porter, da vil den komme opp på en slik liste som "emule". Hvis en "emule hacker" ser dette, så vet han hvor han skal starte sine angrep. Når man kjører med lukkede porter slik som det ser ut til å være tilfellet for sven_sveder så vil man normalt ikke være med på en slik "sweep liste" i det hele.
Av denne grunn så er en Emule installasjon med alle porter lukket i utgangspunktet og på mange måter (men ikke nødvendig vis alle måter) mer sikker enn de fleste ordinære server installasjoner.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
