Hvad er formålet med en server i soveværelset?

[Børge Jensen]

Hej gruppe,

Hvad er formålet med en server i soveværelset?

... eller et andet sted i huset.

For mit vedkommende er min forbindelse på uploadområdet
ikke noget at skrive hjem om, den ligger på omkring 400 kb,
det er der ingen der kan bruge til noget.

Endelig er der sikkerheden, den skal man selv sørge for, det
er næsten det værste.

one.com og unoeuro har billige webhoteller, hvorfor vælger man
ikke bare den løsning? her er man sikker på at de har sikkerheden
i orden

Fra 1999 til 2004 havde jeg min egen server kørende, det var et
helvede, den blev hele tiden angrebet af alt muligt, så den blev til
sidst lukket ned. Siden har jeg KUN brugt webhoteller.

--
Børge Jensen

[Bertel Lund Hansen]

Børge Jensen skrev:

> Hvad er formålet med en server i soveværelset?
> ... eller et andet sted i huset.

Det er vist indlysende.

> Endelig er der sikkerheden, den skal man selv sørge for, det
> er næsten det værste.

Der er folk der har bedre forstand på den slags end du åbenbart
har.

> Siden har jeg KUN brugt webhoteller.

Jeg har altid kun brugt webhoteller. Jeg gider heller ikke rode
med egen server, men jeg kan nemt se formålet med at gøre det.

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

[scootergrisen]

Hvis du har din egen computer med din egen server s� kan du jo bestemme alt.

Hvis du bruger et webhotel s� er du jo begr�nset til at bruge den server
de har med de indstillinger de har valgt og med de udviddelser som de
syntes der skal v�re. Du kan ikke bare lige �ndre en indstillinger hvis
webhotellet har valgt at det ikke skal v�re muligt at �ndre.

Lad os for eksempel sige du vil lave en hjemmeside hvor folk kan uploade
filer. S� kan det v�re at webhotellet har en gr�nse som siger at hver
fil max m� v�re 20 MB stor, det jo lidt noget tis hvis folk s� skal
kunne uploade st�rre filer.
Hvis det var din egen server kunne du bare �ndre det, p� webhotellet er
det ikke sikkert du kan �ndre det.

Eller lad os sige du vil bruge et forum. Forummet har s� nogen krav som
serveren skal opfylde, hvis dit webhotel ikke opfylder de krav s� er det
bare sur r�v og du kan ikke bruge forummet. Hvis din egen computers
server ikke opfylder kravene s� fixer du det bare ved at opdater,
installer det som mangler eller hvad der nu skal til.

Jeg er da st�dt p� nogen ting hvor mit webhotel er begr�nset ogs� m� jeg
lade v�re med at bruge det eller ogs� lave om p� det jeg ellers ville.

Da jeg for eksempel skulle flytte min hjemmeside s� m�tte jeg �ndre
filendelsen p� mine filer fra .html til .php bare fordi webhotellets
server var indstillet s�dan. Hvis det var min egen server s� kunne man
let have �ndret det men da webhotellet ikke tillod det s� m�tte jeg
sidde og �ndre fil navnene.

[Kim Ludvigsen]

scootergrisen skrev:
> Hvis du har din egen computer med din egen server så kan du
> jo bestemme alt.

Ja, men hvis man bruger pengene til webhotel i stedet for
indkøb af computer og de par tusinde kroner det koster om
året i strøm, så kan man altså få det stort set, som man vil
have det.

Jeg havde i sin tid min egen server, men det var
drønbesværligt - og dyrt. Og med konstant stress, fordi jeg
skulle sikre mig, at forbindelsen var i orden. En
forbindelse som for øvrigt var langt langsommere end, hvad
man får på et webhotel. Sikkerheden var ikke et problem i
mit tilfælde, fordi jeg brugte et styresystem, som ingen
hacker vidste, hvad de skulle gøre med.

--
Mvh. Kim Ludvigsen
Undgå faldgruberne, sådan vælger du det rette webhotel:
http://kimludvigsen.dk/tips-internet-websnedker-webhotel.php

[Uffe Kousgaard]

"Børge Jensen" <bo...@invalid.com> wrote in message
news:jm4v98$38a$1...@speranza.aioe.org...

> Hej gruppe,
>
> Hvad er formålet med en server i soveværelset?

1) Jeg kan installere lige den software jeg har lyst til og lade mine kunder
afprøve den.

2) Jeg har altid en pc der er tændt, så jeg kan gå på nettet. Ikke noget med
at skulle vente.

[Stig Johansen]

Børge Jensen wrote:

> Hej gruppe,
>
> Hvad er formålet med en server i soveværelset?
>
> ... eller et andet sted i huset.

Er det mig du referer til?

Jeg har valgt at flytte fra et (stort) hus til en lille lejlighed.
Hvis man skal have sine egne servere er der to muligheder:
1) I stuen.
2) I soveværelset.

Jeg vægler 1).

Som andre beskriver har man fuldstændig kontrol over egne servere, og er
ikke begrænset af diverse udbydere.

Ad strømforbrug:
Du kender åbenbart ikke til lavt forbrugende servere, hint her:
http://www.ezz.dk/401354-byg-selv-server-med-lavt


--
Med venlig hilsen
Stig Johansen

[Kim Ludvigsen]

Stig Johansen skrev:

> Ad strømforbrug:
> Du kender åbenbart ikke til lavt forbrugende servere, hint her:
> http://www.ezz.dk/401354-byg-selv-server-med-lavt

Gad vide, hvor relevant det stadig er her næsten 10 år senere.

[Karl Erik Christensen]

Jamen fordelene kan jo være mange - vi er også nogle stykker der er født
"nysgerrige" og higer efter lærdom :-)

Min apache (www) og mail server kørte fint i flere år bag sofaen i
stuen. Men da jeg akut røg på hospitalet, syntes et familiemadlem at der
ikke var grund til at have den kørende - og slukkede den :-)

Det er også nødvendigt med noget UPS, ellers standses den ved hver
strømafbrydelse.

Hvis man vil spare penge, er egen server ikke en option.

Karl Erik.

--
http://dmwebdesign.dk - DM i Webdesign
http://produceret-i.dk/ - Køb danske produkter
http://webdesign.ranunkelvej.com - Artikler om webdesign

[Martin]

On 12-04-2012 00:05, Børge Jensen wrote:
> Hej gruppe,
>
> Hvad er formålet med en server i soveværelset?
>
> ... eller et andet sted i huset.

Det er nu rart at have 3x linux dists, 1x windows 2008 server

Desuden så ligger alle mine film, billeder osv også på den server.
Så 1 server og mange instanser og det er næsten bare at trykke på en
knap, så har jeg en ny dist af linux.

Kører normalt en instans pr projekt, grunden er egentlig ret simpel -
når projektet er gået live, så kan jeg smide det ud i verden fx på
amazon eller microsoft azure - så kan jeg igen trykke på en knap og
vupti så er hele projektet væk fra mig af, og så ligger det kun på fx
github.

Så når jeg skal lave en ændring eller lign, så er det bare at trykke på
en knap, så der kommer en instans af webserveren, klone fra git, lave
ændringen, pushe til github også smide instansen ud.

> For mit vedkommende er min forbindelse på uploadområdet
> ikke noget at skrive hjem om, den ligger på omkring 400 kb,
> det er der ingen der kan bruge til noget.

Min upload er kun en 10mbit, så nej jeg hoster selvfølgelig ikke
offentlige projekter (eller jo de små af dem, men ikke de store)

>
> Endelig er der sikkerheden, den skal man selv sørge for, det
> er næsten det værste.

Der er det også rigtig smart at have sine instanser i et virtuelt miljø,
så hvis der kommer noget ukrudt - smide instansen ud, og op med den igen :)

>
> one.com og unoeuro har billige webhoteller, hvorfor vælger man
> ikke bare den løsning? her er man sikker på at de har sikkerheden
> i orden

one.com og unoeuro er da fine nok til små billige projekter, men når man
både leger med nodejs, ruby, php og .net - så er det ikke
tilfredsstillende mere. - og hvis du så har et projekt der lige
pludselig begynder at blive populært, så har du et problem. Enten lukker
de sitet ned uden varsel, eller du, hvis du er heldig, modtager en mail
om at du skal købe en større løsning eller du skal finde dig et nyt hus
at bo i.

amazons ec2/azure er rigtig dejligt - for man for mange kunder, så
deployer man bare en ny instans og bummelum, så har du dobbelt så meget
power.

>
> Fra 1999 til 2004 havde jeg min egen server kørende, det var et
> helvede, den blev hele tiden angrebet af alt muligt, så den blev til
> sidst lukket ned. Siden har jeg KUN brugt webhoteller.
>

Det handler bare om at have en god router, med en lille processor, lidt
ram og lidt harddisk plads - så kan man programmere sig ud af det :)
Eller bare blokere alle dem man nu ikke ønsker

[Børge Jensen]

Stig Johansen wrote:

> Er det mig du referer til?

Nej, det var mere generelt hvorfor folk vælger den løsning
i stedet for et webhotel med styr på sikkerheden.

> Ad strømforbrug:

Det er så en anden side af sagen.

--
Børge Jensen

[Stig Johansen]

Børge Jensen wrote:

> Stig Johansen wrote:
>
>> Er det mig du referer til?
>
> Nej, det var mere generelt hvorfor folk vælger den løsning
> i stedet for et webhotel med styr på sikkerheden.

He he - webhoteller har netop *ikke* styr på sikkerheden ;-)

Prøv at læse tilbage i gruppen og se hvor mange der har været angrebet af
SQL injections og remote execution af PHP-filer m.m.

[Stig Johansen]

Martin <martinprikaarhofsnabelagmailprikcom> wrote:

> Der er det også rigtig smart at have sine instanser i et virtuelt miljø,
> så hvis der kommer noget ukrudt - smide instansen ud, og op med den igen
> :)

VMWare er 'ikke så ringe endda' ;-)

Copy/Paste af et par filer og så har man både backup og nye instanser.

[Børge Jensen]

Stig Johansen wrote:

>> Nej, det var mere generelt hvorfor folk vælger den løsning
>> i stedet for et webhotel med styr på sikkerheden.
>
> He he - webhoteller har netop *ikke* styr på sikkerheden ;-)

Dem jeg bruger har meget bedre styr på sikkerhed end de
mange private servere, de skal jo representere sikkerhed på
serveren over for deres kunder, og kan de ikke det, mister de
dem hurtigt.

--
Børge Jensen

[Stig Johansen]

Jo, men nu har jeg ligesom 32 års erfaring udi programmering, herunder
bamksystemer og værdipapirhandel.

Endvidere har jeg rådgivet, og kontrolleret, sikkerhedsløsninger i
forbindelse med store leverancer til det offentlige.

Herunder også Rigsrevisionen i forbindelse med aftalen om SKB (Statens
Koncern Betalinger) med Jyske Bank.

Så jo - jeg tror jeg hasr styr på sikkerheden ;-)

<blær value="off">

[Mcwm]

Den 24-04-2012 08:38, Stig Johansen skrev:
> <blær value="off">

Hov, hvornår blev der erklæret første gang? Enten en sikkerhedsbrist
eller også har der været en del blær fra din side hehe ;-)

Sorry, lå lige for ;-)

Venligst
Mcwm

[Stig Johansen]

He - *vidste* den ville komme ;-)

Den var lidt sarkastisk ment, for det er et start tag, og ikke et end tag.

Overvejede at lave det som et tomt XML tag.

[Rune Jensen]

On 27 Apr., 08:45, Stig Johansen <wopr...@gmail.com> wrote:

> Den var lidt sarkastisk ment, for det er et start tag, og ikke et end tag.

Så du kørte i quirks mode? He...

Men spøg til side, så har jeg nu stor respekt for din viden om
sikkerhed. Mest fordi det igennem tiden har vist sig at passe, hvad du
har sagt omkring emnet. Så al respekt for nybegyndere her med egne
meninger om sikkerhed, men intet slår altså erfaring.

Nåhja, og hostersikkerhed - f.eks. UE...?

Var vel lidt af en oplevelse :)
http://www.version2.dk/artikel/dansk-sikkerhedssite-overtaget-af-hackere-10055

...læg mærke til, at JSen blev injected FØR hjemmesidens egen kode, så
webmasteren var virkelig på r... eneste mulighed for at komme udenom
det på var en 301 redirect til f.eks. google.com. Selv en 404-side fik
den JS-injection.

Og som Stig også skrev et sted - eneste mulighed for, de kunne lave
det trick var, de havde hacked hosteren på Admin-niveau.

Den bedste/højeste sikkerhed får man ved selv at styre den 100%, og
det betyder dedikeret server (hvor man selv kan styre alt), eller egen
(hjemme)hosting.


MVH
Rune Jensen

[Stig Johansen]

Rune Jensen wrote:

> Nåhja, og hostersikkerhed - f.eks. UE...?
>
> Var vel lidt af en oplevelse :)
>
http://www.version2.dk/artikel/dansk-sikkerhedssite-overtaget-af-hackere-10055
>

Husker godt denne sag.

Det var jo særdeles kedeligt at hjemmesiden som skulle fungere som
sikkerhedsoplysninger blev 'hacket'

Jeg husker også at Unoeuro indførte et eller andet anti 'diller daller', som
gjorde at mine .js filer på w-o-p-r.dk 'automagisk' blev slettet uagtet der
ikke var tale om infektion.

Nu er siden ikke aktiv (endnu), men jeg måtte jo ty til de samme metoder som
hackerne, at encrypte .js-filerne, så de kunne virke.

Lidt af en falliterklæring fra de såkaldte 'anti firmaer' at man ikke kan
skelne skæg og snot.

Måske - måske ikke - retablerer jeg siden, især STORM monitor, som afslører
ethvert angreb på hjemmesider - incl. CMS baseret på MS SQLServer.

Men jeg tvivler på der er nogen der forstår vigtigheden i at holde sin
server 'ren', selvom man(IMO) er medskyldig til inficering af sine brugere.

Det største problem er at dem der tror de ved noget om sikkeerhed kalder dem
for 'script kiddies' - se bare Karl Erik's indlæg 'New kids..'

DON'T UNDERESTIMATE YOUR ENEMY!!

Disse 'folk' er langt mere intelligente end man tror.

Jeg har ikke lige linket og observationen, men når vi snakker webdesign og
CSS, så tænk over at man kan udføre javascript i en .css-fil.

Jeg har set eksempler på dette, og det kunne passende være ugens
'konkurrence':

* Beskriv hvordan man udfører javascript i en .css fil.

[Rune Jensen]

On 30 Apr., 10:10, Stig Johansen <wopr...@gmail.com> wrote:

> Måske - måske ikke - retablerer jeg siden, især STORM monitor, som afslører
> ethvert angreb på hjemmesider - incl. CMS baseret på MS SQLServer.

Jeg fik jo fornøjelsen af at afprøve den, og den sløvede ikke min side
på nogen mærkbar måde, men var til gengæld yderst effektiv. Jeg havde
selv oprettet én dedikeret mail-adresse til storm-detektoren, og den
gav mig meddelelser om samtlige ændringer, som var foretaget på
serveren, uanset hvordan de var foretaget.

Hvis man kunne smække dét system ind i en slags samlet pakke med
webdesign OG sikkerhed, mon så ikke det kan sælges?

Private brugere vil formentlig kræve et slags "point-and-click"-
system, noget a la "Du er inficeret" kontra "Du er ikke inficeret".
Derfor jeg ville gå efter de lidt mere teknisk mindede som f.eks.
webbureauer.

Ellers, så kunne jeg forestille mig f.eks. nyhedssites eller blogs
eller måske webshops eller sociale medier, hvor der er et ansvar for
brugeres data. Kommmer også an på, hvor meget systemet kan skaleres,
og hvor meget, der kan automatiseres udover det nuværende, for så kan
man jo også gå efter større kunder - her tænker jeg så på
indtjeningsmuligheder.


MVH
Rune Jensen

[Anders Wegge Keller]

Stig Johansen <wop...@gmail.com> writes:

> * Beskriv hvordan man udfører javascript i en .css fil.

Er der stadig browsere der hopper på den slags?

--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

[Karl Erik Christensen]

On 30-04-2012 10:10, Stig Johansen wrote:
> Det største problem er at dem der tror de ved noget om sikkeerhed kalder dem
> for 'script kiddies' - se bare Karl Erik's indlæg 'New kids..'

Nu kan jeg ikke lige i min naivitet gennemskue hvad du mener med
ovenstående.

Hvis man bare sidder med fingeren i "gaskanalen" sker der jo ikke noget.
Så må det såguda' være bedre at forsøge sig med de tiltag man nu en gang
kan, på det niveau hvor man befinder sig.

Jeg forsøger at sende russere, kinesere og andre slyngler væk - det er
da "at gøre noget".

At slynglerne så har anderen metoden - ja, så ved de jo bare mere end jeg.
At jeg "leger lidt" med ip-adresse check, er sgu da at gøre noget.

Jeg er hverken "it-sikkerheds ekspert" eller hacker, selvom nogen mener
at kunne bevise noget andet.

Egentlig utroligt at de der ved noget om emnerne, kun latterliggør
fremfor at hjælpe.

Karl Erik.

--
http://dmwebdesign.dk/karlerik/ - Ny hjemmeside

[Philip Nunnegaard]

Stig Johansen skrev:

> Jeg husker også at Unoeuro indførte et eller andet anti 'diller daller', som
> gjorde at mine .js filer på w-o-p-r.dk 'automagisk' blev slettet uagtet der
> ikke var tale om infektion.
>
> Nu er siden ikke aktiv (endnu), men jeg måtte jo ty til de samme metoder som
> hackerne, at encrypte .js-filerne, så de kunne virke.
>
> Lidt af en falliterklæring fra de såkaldte 'anti firmaer' at man ikke kan
> skelne skæg og snot.

Den slags kunne få mig til at overveje at skifte udbyder.

Jeg har oplevet lignende ting med mine mailprogrammer gennem tiderne.
.jpg og .doc-filer blev blokeret over én kam.

(Og jeg der i forvejen aldrig åbner vedhæftede filer uanset om jeg
kender afsenderen eller ikke, med mindre jeg på forhånd forventer at
modtage en sådan fil fra netop den person.)

For mange vil den slags nok give en "ulven kommer"-effekt, ligesom folk
i 90'erne lærte at de bare skulle klikke "Ja" til det hele, når Windows
kom med popup-advarsler.
Det samme hvis webhotellerne begynder at slette .js-filer eller lignende
i flæng.

--
Philip

[Stig Johansen]

Karl Erik Christensen wrote:

> Jeg er hverken "it-sikkerheds ekspert" eller hacker, selvom nogen mener
> at kunne bevise noget andet.
>
> Egentlig utroligt at de der ved noget om emnerne, kun latterliggør
> fremfor at hjælpe.

Kære Karl Erik.

Jeg mener ikke på nogen måde jeg har latterliggjort nigen, heller ikke dig -
hvis du menere det har du læst forkert mellem linierne.

Nej - dem der latterliggør folk er de ekstremt intelligente hackere, der bla
i deres javascript erklærer:

var fuckAntivirus ;

Og jo - det er fra det virkelige liv.

[Stig Johansen]

Rune Jensen wrote:

> Hvis man kunne smække dét system ind i en slags samlet pakke med
> webdesign OG sikkerhed, mon så ikke det kan sælges?

Har ligget til gratis download som både windows service og linux deamon.

Ligger formentlig stadig til download hvis man kigger efter 'Stigs ting',
som jeg mener jeg kaldte indlægget dengang.

Da der er noget javascript, der afspejler virkelige hændelser mener jeg at
Jens Peter f.eks. fik falske positiver på download af .zip filen.

[Stig Johansen]

Karl Erik Christensen wrote:

> At slynglerne så har anderen metoden - ja, så ved de jo bare mere end jeg.
> At jeg "leger lidt" med ip-adresse check, er sgu da at gøre noget.

Se gerne:
http://dtbaker.com.au/random-bits/catching-and-preventing-echo-md5-just_a_test-exploit-attempts.html

[Stig Johansen]

Anders Wegge Keller wrote:

> Stig Johansen <wop...@gmail.com> writes:
>
>> * Beskriv hvordan man udfører javascript i en .css fil.
>
> Er der stadig browsere der hopper på den slags?

Skal jeg ikke kunne sige dig ;-)

Måske kan du bikke noget sammen ud fra denne her:
http://stackoverflow.com/questions/476276/using-javascript-in-css

Har ikke lige den der 'browser' i nyeste version tilgængeligt p.t.

[Karl Erik Christensen]

On 02-05-2012 07:24, Stig Johansen wrote:
> Karl Erik Christensen wrote:
>
>> At slynglerne så har anderen metoden - ja, så ved de jo bare mere end jeg.
>> At jeg "leger lidt" med ip-adresse check, er sgu da at gøre noget.
>
> Se gerne:
> http://dtbaker.com.au/random-bits/catching-and-preventing-echo-md5-just_a_test-exploit-attempts.html
>

Beskriver lige præcis hvad jeg var udsat for, både på dmwebdesign.dk og
ranunkelvej.com.

Henvendelser til de udbydere der ejede ip-adresserne, medførte i nogle
tilfælde positive resultater, men få botter vendte blot tilbage under ny
ip-adresse.

Skulle det være så vanskeligt på internationalt plan, at boykotte de
skide russere når de etablerer sig hos diverse udbydere verden over?

Alle er jo klar over at russere sjældent er ude i lovligt ærinde.

[Karl Erik Christensen]

On 02-05-2012 13:22, Karl Erik Christensen wrote:
> Skulle det være så vanskeligt på internationalt plan, at boykotte de
> skide russere når de etablerer sig hos diverse udbydere verden over?

Selv jeg har da kunnet finde ud af, at det er russere der står bag,
selvom ip-adressen siger "Fiji Island".

[Rune Jensen]

On 2 Maj, 13:22, Karl Erik Christensen <karle...@none.invalid> wrote:

> Alle er jo klar over at russere sjældent er ude i lovligt ærinde.

Det er ikke korrekt.

Russerne har både en søgemaskine og en antivirus, som er accepteret
ret bredt.

Nu ved jeg ikke, om Kaspersky laver en "for-download", men det var ret
populært før i tiden. Dér hvor selve AVet hentede siden FØR browseren
for den kunne sammenlignes med en blacklist hos AV-producenten.

Det vil under alle omstændigheder betyde, du ikke kan bruge russiske
services, og at sådanne evt. for-download, hvadenten de bliver udført
af selve AVet eller en bot fra AV-firmaet - ikke vil virke. Du
risikerer at lukke dig ude pga. du ikke vil fortælle, hvem du er og
hvad du står for til russiske bots. Hvilket er hvad der sker, når en
(godartet) bot kører igennem sin side.

"Russerne" er ikke pr. definition ondartede, og du har et problem med
at skære alle over én kam.

DET, du kan sige er:

HVIS du har mange (rigtigt mange) russiske IPer, som stammer fra den
samme udbyder, og her taler jeg om langt størstedelen af IPerne er
blacklistede, så kan du blocke udbyderens IPer. Jeg oplevede det med
Ukrainske og Israelske udbydere, som tillod dedikeret spamservere.

Og det kan man se, ved at man checker IPen på bl.a.
projecthoneypot.org. Her vil du få de sammenhængende IPer, så du kan
se, hvor mange IPer fra den udbyder, som er ondartede.

Det er vigtigt at kigge på, hvor persistent de IPer er. Det skal være
gennemgående IPer, som har ligget en del tid på listen, så du er
sikker på, det ikke er fast-flux-IPer.

Som du selv har oplevet, så skifter en del spammere IPer ret ofte.
Uofficielt hedder det noget med at bruge én IP én gang, derefter 3
måneders dvale, før den kan bruges igen. Så ødelægger man det for dem,
som vil IP-blokere, fordi man ikke kan bygge en ordentlig black list.

De hostere, som giver tilladelse til at bruge serverne til spam (det
var klart mest Ukrainere før i tiden), er ret nemme at blocke, fordi
de IPer er de samme hver gang, også selvom de botter som regel også er
lidt mere intelligente. Men de skal tages med "skalpel" - ikke en
generel IP-blocking, som du gør det.

Fast-flux derimod, det er private brugeres PC, som er blevet
inficeret, og de botter er skrevet til ikke at fylde noget, derfor
ligner de meget hinanden. Langt de mest kendte er JAVA-botter, som
bruges til harvesting. Det er _ikke_ en god idé at blocke fast-flux-
IPer _alene_ på IPen. Du kan risikere at blocke naboen.

Der er forskel på, om en IP, som angriber, kommer fra en privat PC -
eller en dedikeret server til formålet.

Generelt er IP-blocking noget man skal foretage efter en grundig
analyse, og kun for en nærmere defineret tid.

_Langt_ det bedste er, at man sikrer sin sides forskellige dele, som
der også _er_ blevet gjort opmærksom på her utallige gange. _Derefter_
kan du i ro og mag finde på metoder til at detektere disse botter og
analysere deres angrebsmetoder (en honeypot er rigtigt godt værktøj),
og først derefter finde en måde at bekrige dem på. Hvis det er det, du
vil...

At begynde en krig, før man selv har opbygget et solidt forsvar, det
levner ikke mange chancer for at vinde.

Næste gang, så angriber de dig bare fra et andet land, hvad med f.eks.
Colombia? Eller Saudi Arabien? Eller Mexico?

Det kan såmænd ske igennem en vulnerability i Googles APIer, så man
bliver angrebet af en IP fra Google. Det _har_ jeg prøvet, og jeg
havde lissom ikke rigtigt lyst til at blokere Google.


MVH
Rune Jensen

[Karl Erik Christensen]

On 02-05-2012 17:17, Rune Jensen wrote:
> Næste gang, så angriber de dig bare fra et andet land

Ja det er da korrekt Rune, men jeg mangler: "Det man kan gøre er .... "

Der findes ligeså mange dumme Nordjyder, som der findes venlige russere
og kinesere.
Hvis jeg udelukker alle russere og kinesere fra at se min hjemmeside, så
er det det jeg gør - og fred være med dem.

Hvis de vil accepteres af mig, må de gøre sig fortjent til det.
Dumme Nordjyder accepterer jeg, for de gør ingen skade.
Kun nogle få i Brønderslev, men de var jo "udenbys".

[Rune Jensen]

On 2 Maj, 18:19, Karl Erik Christensen <karle...@none.invalid> wrote:
> On 02-05-2012 17:17, Rune Jensen wrote:
>
> > Næste gang, så angriber de dig bare fra et andet land
>
> Ja det er da korrekt Rune, men jeg mangler: "Det man kan gøre er .... "

Imod botterne?

Jeg har været igennem alle dine tanker omkring bot-squashing, og jeg
har endda forsøgt en del af tingene også.

Bl.a. det med at sende bestemte spambotter til en "konkurrerende" spam-
side.

Jeg var jo også pissed på de her botter engang og villet have hævn,
ikk.

Det er meget lærerigt at få egne erfaringer, og såmænd også at begå
sine egne fejl, men hvis du spørger dem som selv har været det
igennem, hvilke erfaringer du så vil ende med at få... så er det, at
IP-blocking er hammersvært at lave ordentligt, og ikke er godt nok som
eneste forsvar.

Men hvis du bare ikke opfatter IP-blocking som "endemålet", men en del
af indlæringen, så går det nok.


MVH
Rune Jensen

[Karl Erik Christensen]

Hvis jeg nu var "bot-lystmorder", er jeg sikker på at jeg ville blive
frikendt, og tildelt Elefantordenen.

Der er åbenbart masser der har forsøgt at tage kampen op mod botterne,
men uden held.

Derfor er min pointe, at russere og kinesere må gøre noget i egen
baghave, hvis de vil accepteres internationalt - på internettet.

De kan jo godt finde ud af at skyde 10.000, hvis bare den ene forbryder
er imellem.

[Stig Johansen]

Karl Erik Christensen wrote:

> On 02-05-2012 07:24, Stig Johansen wrote:
>> Karl Erik Christensen wrote:
>>
>>> At slynglerne så har anderen metoden - ja, så ved de jo bare mere end
>>> jeg. At jeg "leger lidt" med ip-adresse check, er sgu da at gøre noget.
>>
>> Se gerne:
>>
http://dtbaker.com.au/random-bits/catching-and-preventing-echo-md5-just_a_test-exploit-attempts.html
>>
>
> Beskriver lige præcis hvad jeg var udsat for, både på dmwebdesign.dk og
> ranunkelvej.com.

Hmm - nåh. så er du sårbar overfor namogoferen....!

Gør dig selv den tjeneste at finde hullet, hvis det da ikke var et 'globalt'
intrusion.

Kig på robtex.com, der kan du se hvor mange du deler 'værelse' med.

Hvus histeren ikke har sikkerheden i orden, kan samtlige 'værelser' blive
inficeret.

> Skulle det være så vanskeligt på internationalt plan, at boykotte de
> skide russere når de etablerer sig hos diverse udbydere verden over?
>
> Alle er jo klar over at russere sjældent er ude i lovligt ærinde.

Du har ret, men jeg tror der er noget du har misforstået.

Disse bot'er er IKKE familie PC'ere, men SERVERE der er inficerede.

Du vil se langt størstedelen fra Kina/Rusland, men det er fordi de er
lettest at inficere, og dermed størst i antal.

Rune (og jeg) har haft bot-angreb fra ret usandsynlige steder, bla:
http://www.webhostingtalk.com/showthread.php?t=634336
og det største knudepunkt i Las Vegas analogt med DIX i DK.

Kan ikke lige finde oplysningerne på denne (Linux VM), men den er (var) god
nok.

Lad mig recitere:

DON'T UNDERESTIMATE YOUR ENEMY!!

[Karl Erik Christensen]

On 03-05-2012 08:14, Stig Johansen wrote:
> Hmm - n�h. s� er du s�rbar overfor namogoferen....!
>
> G�r dig selv den tjeneste at finde hullet, hvis det da ikke var et 'globalt'
> intrusion.
>
> Kig p� robtex.com, der kan du se hvor mange du deler 'v�relse' med.

For ca. 1 �r siden modtog jeg en del beskeder fra mailformularer, der
dengang ikke havde captcha.

Beskederne s� s�dan ud:

VobavO <a href=\"http://ansqemxwpzfc.com/\">ansqemxwpzfc</a>,
[url=http://aiyjetmpeqns.com/]aiyjetmpeqns[/url],
[link=http://qkfbuvscwdeq.com/]qkfbuvscwdeq[/link], http://jiesntpzlygi.com/
url:http://eiurblvhaujc.com/
ip-adresse:178.239.58.143

Denne er fra en ip-adresse hjemmeh�rende i Holland, men ogs� ip-adresser
i usa er repr�senteret, s� det kunne jo tyde p� at det er maskiner der
er inficeret, der udsender beskederne.

Den "m�rkelige" besked er uden tvivl fors�g p� at sende injektions-kode.

Mailformular med captcha stopper disse beskeder effektivt.

Men det �ndrer ikke ved det faktum, at ip-adresse check, fanger mindst
15-20 "kinesere" hver dag.

Karl Erik.

--
http://dmwebdesign.dk/karlerik/ - Ny hjemmeside

http://produceret-i.dk/ - K�b danske produkter

[Stig Johansen]

Karl Erik Christensen wrote:

> Men det ændrer ikke ved det faktum, at ip-adresse check, fanger mindst
> 15-20 "kinesere" hver dag.

Det er vi da fuldstændig enige om ;-)

Men der er så lige det problem hvis familien er på ferie i et Kinesisk (IP)
land.

Det bedste er at køre filter på blacklistede IP adresser, men det kræver
egen hosting, og lidt 'behändigkeit'.

[Karl Erik Christensen]

Jeg er temmelig sikker på, at ranunkelvej.com blev inficeret da jeg for
ca. 1 år siden fjernede ip-checket.

En dansker på ferie i østen beklagede sig over, at han ikke kunne komme
ind på min hjemmeside, og så fjernede jeg ip-checket.

I øvrigt har jeg lige udvidet min ip-check funktion sådan, at
ip-adresser der bliver nægtet adgang, gemmes i en fil.
Så må vi se hvor hurtigt den vokser.

De lande jeg nægter adgang er:
'PaKistan','KoRea','BulGarien','SuDan','InDonesien','ChiNa','RUsland','HunGary'

Hvis folk vil se min hjemmeside medens de er på ferie nævnte steder, så
kan de altså bare vente til de kommer hjem :-)

Jo større problemet bliver for folk i disse lande, jo større pres må de
lægge for, at der gøres noget ved problemet.

Karl Erik.

--
http://dmwebdesign.dk/karlerik/ - Ny hjemmeside

http://produceret-i.dk/ - Køb danske produkter

[Jens Peter Karlsen]

Eller bed dem bruge en tjeneste som anonymouse.org

Regards Jens Peter Karlsen.

[Karl Erik Christensen]

Risikerer de så ikke at komme på The Pirate Bay i stedet? :-)

[Rune Jensen]

On 3 Maj, 11:24, Karl Erik Christensen <karle...@none.invalid> wrote:

> Jo større problemet bliver for folk i disse lande, jo større pres må de
> lægge for, at der gøres noget ved problemet.

Ja. I princippet kan man sige, du lukker internettet for en del af
dine brugere for at undgå nogle andre brugere.

Det er efter min mening altfor dyrekøbt forsvar.

Hvis dine angribende IPer er fra korrupte hostere, kan du blocke
hosternes IP i stedet for hele landet. Men ellers er IP-blocking ikke
den eneste metode, ejheller altid den bedste.

Bortset altså fra, at det er "rettidig omhu" at sikre borgmurens
beskaffenhed, før man investerer i kogende olie.


MVH
Rune Jensen

[Karl Erik Christensen]

Rune, jeg beundrer din vedholdenhed :-)

Som jeg svarede Stig, var den "mystiske" besked fra en mailformular,
postet af en "maskine" med en ip hjemmehørende i Holland.

En anden fra 98.217.60.63, som er hjemmehørende hos COMCAST CABLE
COMMUNICATIONS INC i USA.

Der er sikkert tale om inficerede maskiner - og hvem mon har inficeret dem?

Da russere og kinesere "trawler" nettet, og besøger steder hvor de intet
har at gøre - nogle gange med op til 20 kinesiske ip-adresser på *1*
dag, har jeg overhovedet ingen skrupler ved at boykotte hele nationen.

Bare synd for søde "Nina" - Li Ying fra Shanghai, for så kan hun ikke
følge "Erik" på hans hjemmeside.

De må sgu presse på for at få gjort noget ved problemet.

[Rune Jensen]

On 3 Maj, 18:28, Karl Erik Christensen <karle...@none.invalid> wrote:

> Bare synd for søde "Nina" - Li Ying fra Shanghai, for så kan hun ikke
> følge "Erik" på hans hjemmeside.

Du bestemmer selfølgelig selv hvem du vil blocke på din egen side.

Synes bare ikke, at IP-blocking på hele lande skal italesættes som et
effektivt middel imod de her botter her i grupperne, for det er det
ikke. Man skal ikke lære andre sådan nogle tricks heller, uden man har
100% styr på, hvad konsekevnserne er.

Det korrekte er, at man sikrer sidens dele efter best practice, før
man gør nogetsomhelst andet.

Og så får sig en dybdegående logging-funktion, hvis man yderligere vil
lege med diverse blocking.

Der er, efter min mening, forskel på, om det er til leg eller alvor. I
produktion ville jeg aldrig bruge IP-blokering på hele lande, men til
leg og læring er det fint nok.


MVH
Rune Jensen

[Karl Erik Christensen]

On 03-05-2012 18:46, Rune Jensen wrote:
> Det korrekte er, at man sikrer sidens dele efter best practice, før
> man gør nogetsomhelst andet.

Som Stig skriver, uhyre vanskeligt hvis man ikke har fuld kontrol med
serveren.

Men kan du ikke give nogle "fiduser" til brug på et webhotel.
Det er bare for nemt at bruse ud med "best practice" uden at give eksempler.

Mailformular med captcha har minimeret forsøg på injektion ad den vej.
SQL-injektion begrænses med preg_match - har du bedre forslag?

Der er vel ingen grund til at bygge en Boing 747, hvis man bare skal
over åen - billedlig talt.

[Jens Peter Karlsen]

Kommer jo an på hvad de skriver.:-)

Regards Jens Peter Karlsen.

[Jens Peter Karlsen]

Brug parametre i stored procedures. Blandes disse er det mig bekendt
ikke muligt at gennemføre en SQL Injection succesfuldt. Kræver dog en
professionel DBM (SQL Server, Oracle eller lignende).

Et simpelt eksempel:
CREATE PROCEDURE VerifyUser
@username varchar(50),
@password varchar(50)
AS
BEGIN
SELECT * FROM UserTable
WHERE UserName = @username
AND Password = @password;
END
GO

Lånt herfra:
http://blogs.msdn.com/b/brian_swan/archive/2011/02/16/do-stored-procedures-protect-against-sql-injection.aspx

Læste engang en meget omhyggelig gennemgang af SQL injection. Hvis du
er interesseret kan jeg prøve om jeg kan finde den.

Regards Jens Peter Karlsen.

[Anders Wegge Keller]

Jens Peter Karlsen <jpka...@mvps.org> writes:

> Brug parametre i stored procedures. Blandes disse er det mig bekendt
> ikke muligt at gennemføre en SQL Injection succesfuldt. Kræver dog en
> professionel DBM (SQL Server, Oracle eller lignende).

Mindre kan nu gøre det. PHPs mysqli med prepared statements er det
heller ikke så nemt[1] at lave SQL injection med.

1. Medmindre man da finder et hul i implementationen, men den bør
udenforstående ikke have adgang til at kende.

[Karl Erik Christensen]

On 03-05-2012 20:53, Jens Peter Karlsen wrote:
> Læste engang en meget omhyggelig gennemgang af SQL injection. Hvis du
> er interesseret kan jeg prøve om jeg kan finde den.
>
> Regards Jens Peter Karlsen.

Jeg tygger mig gennem flere artikler om sikkerhed.

Er nu nået til denne om php og sql:
http://www.phpfreaks.com/tutorial/php-security

Jeg synes det er lidt svært at finde gode artikler. De fleste mener det
er vigtigt at skifte kodeord ofte. Men hos Unoeuro er det bare sådan, at
hvis man f.eks. vil skifte ftp-kodeord, skiftes for alle funktioner,
også for MySql og mail-konto. Og så er det altså lidt tumpet at man skal
gennem alle dokumenter der benytter database, for at ændre kodeordet.

En løsning kunne være kun at benytte et dokument til alle sider i
over/under mapper, da man kun har een db.
Så forudseende har jeg desværre ikke været.

Hvis det er en rigtig god artikel, må du gerne finde linket :-)

[Jens Peter Karlsen]

Fandt det.
http://www.unixwiz.net/techtips/sql-injection.html

Jeg synes den giver en meget god gennemgang af grund problemet og for
mere avancerede teknikker så se links i bunden (samt det til en comic
strip).

Regards Jens Peter Karlsen.

[Rune Jensen]

On 3 Maj, 19:45, Karl Erik Christensen <karle...@none.invalid> wrote:

> Mailformular med captcha har minimeret forsøg på injektion ad den vej.
> SQL-injektion begrænses med preg_match - har du bedre forslag?

Ja... til at sikre imod SQL-injection bruges Parameter Binding. Det
sikrer, at selve SQLdelen sendes separat fra diverse variable, som
f.eks. brugerinput. Sådan lidt kort, så sørger det for, at alle
brugerinput opfattes som ren tekst, og derfor ikke kan eksekveres.

"
Basically, your statement is parsed and processed ahead of time, and
the parameters are sent separately instead of being handled along with
the SQL code. This eliminates SQL-injection attacks because the SQL is
parsed before the parameters are even set.
"

http://stackoverflow.com/questions/14934/parameter-binding-what-happens-under-the-hood

Jeg har lidt problemer med at finde en god tutorial til PHP, desværre,
men de må jo findes.

Mht. Cross Site Scripting, så kig på OWASP XSS Cheat Sheet
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

I forbindelse med din anti-spam, kan du jo sådan set sagtens lave en
function, som kræver en CAPTCHA, hvis IPen er alt andet end DK.


MVH
Rune Jensen

[Karl Erik Christensen]

On 05-05-2012 11:41, Rune Jensen wrote:
> Ja... til at sikre imod SQL-injection bruges Parameter Binding. Det
> sikrer, at selve SQLdelen sendes separat fra diverse variable, som
> f.eks. brugerinput. Sådan lidt kort, så sørger det for, at alle
> brugerinput opfattes som ren tekst, og derfor ikke kan eksekveres.

Tak for forklaring/links Rune.

Med preg_match mener jeg, at fjerne f.eks. disse tegn fra brugerinput
"/\;", hvilket jo "fanger" en hel del forsøg på sql-injection.

På ranunkelvej.com var det noget php-kode der var inficeret med, og som
jeg ser det, var eneste "hul", et mailformular eksempel på
webdesign.renunkelvej.com - uden captcha. Der kom en del "mærkelige
beskeder" fra den - som jeg nævnte for Stig.

Mailformularen var en "tilpasset" version af php's sendmail, med e-mail
adresse og spam check.

Enten det eller så må det være fra en af dem jeg "deler værelse" med hos
Unoeuro. Der har jeg jo ikke adgang til log-filerne på serveren.

[Karl Erik Christensen]

Tak for linket.

[Rune Jensen]

On 3 Maj, 19:45, Karl Erik Christensen <karle...@none.invalid> wrote:
> On 03-05-2012 18:46, Rune Jensen wrote:
>
> > Det korrekte er, at man sikrer sidens dele efter best practice, før
> > man gør nogetsomhelst andet.
>
> Som Stig skriver, uhyre vanskeligt hvis man ikke har fuld kontrol med
> serveren.

Nah, best practise er bare noget man skal lære på rygraden, eller,
skal man have et link til en korrekt tutorial, sådan man har et slags
opslagsværk, som man kan følge hver gang.

Tror mere, at Stig snakkede om IP-blocking, som kan bruges, men som er
ret svært at lave optimalt, hvis man vil bruge det i større stil i
hvert fald.

Der var én, som foreslog en function til indsættelse af CAPTCHA-krav,
hvis IPen er mistænkelig. Du kan for så vidt ligeså godt lave dette
som en white list, sådan at der kræves CAPTCHA, hvis IPen ikke er
Dansk.

Det vil jo ikke afskrive folk fra andre lande at kommentere, de skal
bare igennem et ekstra tjek først, og det mener jeg nok er prisen
værd. Regner med, at dine primære brugere er danskere.


MVH
Rune Jensen

[Rune Jensen]

On 5 Maj, 14:11, Karl Erik Christensen <karle...@none.invalid> wrote:

> Med preg_match mener jeg, at fjerne f.eks. disse tegn fra brugerinput
> "/\;", hvilket jo "fanger" en hel del forsøg på sql-injection.

Jo - men hvorfor begrænse brugerens gøren og laden med sådanne tiltag,
hvis man med en standard best practice kan eliminere alle SQL-
injection forsøg?

Iøvrigt så tager "stripping" ikke alle forsøg, den er ikke 100%
sikker. Som du også selv antyder.

Med Parameterized Queries (som er ASPs betegnelse for Parameter
Bindings), der kan jeg lade brugeren skrive hvad f... det skal være,
for PM eksekverer intet af det alligevel.

Tænkt også på navne, som f.eks. Mc' Donald, hvor der er apostroffer i.
Hvorfor ikke lade brugeren tillade det, når det ikke skader alligevel?
Det er jo et validt navn, altså...

Der hvor man så escaper, det er fra databasen og ud til siden, når
HTMLen skal skrives. Der HTML-escaper man outputtet - se OWASPs side
om samme. Grundlæggende er det en encoding af farlige tegn, man laver,
sådan man ikke kan lave en meddelelse, som f.eks. indeholder <script>,
som jo ellers ville blive udført, når browseren læser koden.

Jeg mener, at både Leif Neland og Birger Sørensen har ganske godt styr
på PHPs udgave af Parameter Bindings. Får du hjælp derfra, er du godt
på vej, og de skriver vel begge i PHP-gruppen.

Tro ikke på alle mulige "escape-rutiner" tíl DBer, de er aldrig lige
så sikre som Parameter Bindings, og de anbefales altid af folk, som
egentlig ikke ved så meget om sikkerhede når det kommer til stykket.
Der er desværre langt flere af sådanne tutorials, end der er til den
korrekte metode med Parameter Bindings. Det ødelægger EMM PHPs ry en
hel del.


MVH
Rune Jensen

[Karl Erik Christensen]

On 05-05-2012 15:45, Rune Jensen wrote:
> Der var én, som foreslog en function til indsættelse af CAPTCHA-krav,
> hvis IPen er mistænkelig. Du kan for så vidt ligeså godt lave dette
> som en white list, sådan at der kræves CAPTCHA, hvis IPen ikke er
> Dansk.
>
> Det vil jo ikke afskrive folk fra andre lande at kommentere, de skal
> bare igennem et ekstra tjek først, og det mener jeg nok er prisen
> værd. Regner med, at dine primære brugere er danskere.

Takker for dit fine "foredrag" Rune :-)

Det dæmrer mere og mere efterhånden som jeg lærer at forstå de
"fagudtryk" du bruger.

Parameter Bindings er nok et af de emner der får 1.st priority.

Brugere på dmwebdesign.dk og faktisk også på min egen hjemmeside, er
hovedsalig Nordiske og nord-central EU.
Men .dk maskiner kan vel også inficeres?

Ca. 25 har for øvrigt sagt ja til at ville deltage i "Open DM i
Webdesign", men om jeg gider arrangere må tiden vise.
Det bliver i hvert fald ikke i disse grupper jeg annoncerer, her hersker
for meget "Jantelov", desværre.

[Rune Jensen]

On 5 Maj, 16:48, Karl Erik Christensen <karle...@none.invalid> wrote:

> Brugere på dmwebdesign.dk og faktisk også på min egen hjemmeside, er
> hovedsalig Nordiske og nord-central EU.
> Men .dk maskiner kan vel også inficeres?

Jo, men jeg omtaler to forskellige injection-former (som også er
blandt de mest populære). Det ene er SQL-injections, som kan afvises
fuldstændigt med Parameter Bindings. Det er din DB du beskytter på den
måde.

Det andet er XSS, som kommer til udtryk, hvis siden sender eksekverbar
kode til browseren. Her er det altså brugeren, som hovedsageligt er
sårbar - inklusive Admin. XSS kan risikeres, hvis du ikke encoder på
outputtet til browseren.

F.eks. Lad os sige, jeg laver et indlæg, som hedder

Dav <script "alert'dette er JS'"> med dig.

Når browseren læser det, vil den opfatte < som begyndelsen på et tag,
og "script" inde i tagget vil blive udført. Så alle, der læser mit
indlæg, vil få en JavaScript popup.

Det kan bruges til at stjæle folks cookies f.eks. - cookies kan læses
og skrives til fra JS.

Derfor, så encoder man < & og visse andre, da disse tegn har speciel
betydning i HTML (dobbeltfunktion). Når et tegn er encoded, vil det
blive vist, i stedet for at blive "udført".

Hvor meget man skal encode, kommer an på, hvad man tillader brugeren
at inputte fra starten - jeg tillader aldrig andet end HTML imellem
tags, dvs ikke noget med brugerdefineret CSS eller JS. Dvs. jeg
indsætter ikke brugerdefinerede input i eget JS f.eks. det er alt for
farligt, og kan ikke gøres sikkert.

OWASP er godt opslagsværk til formålet, men til alm. indlæg:

For HTML er det - for højeste sikkerhed:

Convert & to &amp;
Convert < to &lt;
Convert > to &gt;
Convert " to &quot;
Convert ' to &#x27;
Convert / to &#x2F;

https://www.owasp.org/index.php/Abridged_XSS_Prevention_Cheat_Sheet#How_to_Output_Encode

En function, som gør denne encoding automatisk findes muligvis i PHP -
det gør den for så vidt også i ASP (den hedder HTMLEncode), men jeg
har haft problemer med at få den til at virke med UTF-8 tegnsæt.
Derfor laver jeg min egen function, hvor jeg bruger ovenstående med
functionen Replace til at encode på output.

Man kan diskutere, om det er nødvendigt at encode alle disse tegn,
f.eks. / og ' og " vil kun blive interessante, hvis browseren når så
langt. En browser vil normalt blive stoppet allerede, ved &lt; i
stedet for < (som er begyndelsen på et tag). Det er en vurdering
imellem sikkerheden og så hvor meget den endelige HTML fylder.
Encoding får altid HTML til at fylde mere.


MVH
Rune Jensen

[Stig Johansen]

Anders Wegge Keller wrote:

> Jens Peter Karlsen <jpka...@mvps.org> writes:
>
>> Brug parametre i stored procedures. Blandes disse er det mig bekendt
>> ikke muligt at gennemføre en SQL Injection succesfuldt. Kræver dog en
>> professionel DBM (SQL Server, Oracle eller lignende).
>
> Mindre kan nu gøre det. PHPs mysqli med prepared statements er det
> heller ikke så nemt[1] at lave SQL injection med.
>
> 1. Medmindre man da finder et hul i implementationen, men den bør
> udenforstående ikke have adgang til at kende.

Jeg er selv opvokset med 'større' databaser, og Jens Peter betragter MS
SQLServer som en sådan, selvom der er en 'lille lort'.

Som du selv siger så er µSQL vokset i capabilities, især da de 'slog sig
sammen' med SapDB.

Dog understøtter PHP/µSQL ikke såkaldte stacked queries, så indtil videre er
man 'sikker' på den front - men #beware of the Devil..."

[Stig Johansen]

Rune Jensen wrote:

> Tror mere, at Stig snakkede om IP-blocking, som kan bruges, men som er
> ret svært at lave optimalt, hvis man vil bruge det i større stil i
> hvert fald.

Ja og nej ;-)

Ja til jeg snakkede om IP blocking, men Nej til det er svært at lave
optimalt.

Det kræver naturligvis adgang til (og programmering) af egen server, men
ellers er det rimeligt let.

Det handler blot om en blacklist,whitelist samt en dubiøs liste.

Opateringen kan nok være lidt sværere, da blacklists ikke alle er gratis
tilgængelige (sidst jeg kiggede for nogle år siden).

[Karl Erik Christensen]

Hvis det skal laves perfekt, bør man selvf. bruge blacklist-whitelist.
men da de udbydere jeg kalder "slyngler", ofte mixer good guys and bad
guys, er denne løsning uinteressant på et webhotel.

Ukraine, Rusland og Kina er kendte "slyngelstater", og derfor blokeret
hos mig. Det rammer "uskyldige" - bare ærgerligt, men så må good guys
forlange at der gøres noget ved problemet.

[Jens Peter Karlsen]

Nu skrev jeg kun "professionel".

Regards Jens Peter Karlsen.

On Tue, 08 May 2012 09:42:57 +0200, Stig Johansen <wop...@gmail.com>
wrote:

[Rune Jensen]

On 8 Maj, 09:49, Stig Johansen <wopr...@gmail.com> wrote:

> Opateringen kan nok være lidt sværere, da blacklists ikke alle er gratis
> tilgængelige (sidst jeg kiggede for nogle år siden).

Min anke ville være, om alle black listede IPer var servere, som man
med god samvittighed kunne blocke.

Hvis bare én er resultat af malware på privat PC, og man blocker den,
så ryger en potentiel kunde. Eller mange kunder, da flere brugere som
regel sidder på samme IP, og nok ikke alle er skyldige.

Jeg kunne også godt tænke mig at vide, hvad disse her black lists vil
gøre ved, jeg spammer en side igennem Opera Turbo, hvor jeg så får
Operas IP-adresse. Blocking af Operas IPer, think it's not a good
idea... så blocker man lige en god del mobiler samtidig.

Bedre er det, hvis man har IPen plus en anden ting, som er unik for
denne "bad user". F.eks. den opgivne emailadresse ved blogspamming. Så
kan man blocke på IP og mailadresse, den er ret sikker.

Jeg foreslog Karl Erik at lave en white list i stedet for black
listen, sådan at if UserIP != dansk IP, ville trigge en CAPTCHA. Det
er fordi, det rent statistisk er forholdsvist sjældent at danske IPer
(automatisk) spammer danske hjemmesider.

Jeg har selv brugt en sådan white list, fordi hovedbrugerne var
danske, men jeg ikke ønskede at lukke andre lande ude. Dog ikke som
eneste sikring.


MVH
Rune Jensen

[Jens Peter Karlsen]

I øvrigt er det nok de færreste der har brug for en database der er
større end 524258TB.:-)
Desuden var min tanke mere en sammenligning med noget som Access.

Regards Jens Peter Karlsen.

[Rune Jensen]

On 8 Maj, 10:26, Karl Erik Christensen <karle...@none.invalid> wrote:

> Ukraine, Rusland og Kina er kendte "slyngelstater", og derfor blokeret
> hos mig. Det rammer "uskyldige" - bare ærgerligt, men så må good guys
> forlange at der gøres noget ved problemet.

Tjah. Præcist hvad jeg også tænkte omkring 2009-2010. Særligt om
Ukraine...

Fra 2010 - 2011 deromkring kørte jeg ret intensivt min egen
automatiserede dynamiske blacklist, hvor der blev (manuelt) analyseret
på 24 timers log hver nat - kravet: Der måtte ikke være nogen falske
positiver på listen, dvs. alle black listede skulle være "bad guys".

Det kræver automatisk "udvælgelse" af bad guys til black listen, og
netop "automatisk udvælgelse" er ikke sikker. Tænk bare på
Antivirusser, som er nødt til at tilføje noget "heuristik", som i dén
grad "opfinder" malware, hvor der intet er. Eller omvendt lader
"snald" slippe igennem fordi det ikke passer med algoritmen.

Uanset, hvordan du vender og drejer det, så kan enhver bot efterligne
en "human being" 100%, hvis ellers rettighederne er til stede (som de
vil være på en dedikeret server f.eks.).

Kan godt genkende din tankegang, jep, men nu er jeg altså blevet
klogere på andre områder siden da. Dvs. ikke at jeg er imod IP black
listing, men jeg har fundet andre metoder med mindre usikkerhed, som
jeg satser på inden IP black listing.

Hovedsageligt er jeg gået fra at angribe de her botter til simpelthen
at beskytte selve systemet og mindske huller i koden. Botter mister
tålmodigheden efter ca. 3 måneder, hvis de ikke kommer igennem.

Men det handler selvfølgelig også om, hvad de kan "opsnuse" hos deres
bot"kolleger" om din sides kode. Hvis ingen bot kan komme igennem, så
giver de hurtigere op. Kommer bare én igennem, så er det som et
digebrud.


MVH
Rune Jensen

[Karl Erik Christensen]

On 08-05-2012 17:24, Rune Jensen wrote:
> Hvis bare én er resultat af malware på privat PC, og man blocker den,
> så ryger en potentiel kunde. Eller mange kunder, da flere brugere som
> regel sidder på samme IP, og nok ikke alle er skyldige.

Ja kunde :-)

Nu har jeg ikke så mange kunder på min hjemmeside, men en del svenskere
og nordmænd har faktisk skrevet til mig pga. min artikel om reparation
af B&O Redline højttalere, og B&O produkter generelt.

At sende captcha hvis ikke dansk ip, vil jeg ikke overveje fordi captcha
sender signal om, at ejeren har tænkt på sikkerhed.

IP-blocking er og bliver en ufuldstændig løsning - og jeg har hele mit
lange liv arbejdet på at blive klogere - med mere eller mindre held :-)

[Anders Wegge Keller]

Rune Jensen <runeof...@gmail.com> writes:

> Jeg foreslog Karl Erik at lave en white list i stedet for black
> listen, sådan at if UserIP != dansk IP, ville trigge en CAPTCHA. Det
> er fordi, det rent statistisk er forholdsvist sjældent at danske
> IPer (automatisk) spammer danske hjemmesider.

Det er nok ikke så velovervejet at servere en captcha for ale
ikke-danske adresser. Google, bing og hvad der elles er af
søgemaskiner holder nok ret nurtigt op med at sende trafik, hvis det
eneste de får lov til at indexere er et forvrænget billede.

Dertil kan selvfølgelig indvendes at man kn undlade captcha for et
passende udvalg af søgemaskiner. Det bliver bare noget bøvl, når man
får besøg af en probe for en eller anden wordpress-vulnerability, der
netop udgiver sig for at være GoogleBot:


216.95.154.102 - - [06/May/2012:10:15:09 +0200] "GET
/wp-content/uploads/2007/02/2008.php HTTP/1.1" 404 12757
"-" "Mozilla/5.0 (compatible; Googlebot/2.1;
+http://www.google.com/bot.html)"
216.95.154.102 - - [06/May/2012:10:15:11 +0200] "GET
/wp-content/uploads/2007/03/2008.php HTTP/1.1" 404 12757
"-" "Mozilla/5.0 (compatible; Googlebot/2.1;
+http://www.google.com/bot.html)"

Det kan man selvflgelig også kode sig ud af. Men det tager også tid.

Blacklistning kommer ret hurtigt til at gribe så meget om sig, at man
ville kunne sikre sig overfor angreb på kortere tid og med mndre
indsats.

Frankrig gjorde sig iøvrigt en interessant opdagelse i starten af
anden verdenskrig: Det nytter ikke at have verdens bedst befæstede
grænse, hvis tyskerne løber Holland og Belgien over ende, og kommer
ind ad den vej. Opgaven til den opmærksomme læser, der har fulgt med
hele vejen hertil, er at forkare hvorfor det er relevant.

[Karl Erik Christensen]

On 08-05-2012 20:54, Anders Wegge Keller wrote:
>> Jeg foreslog Karl Erik at lave en white list i stedet for black
>> > listen, sådan at if UserIP != dansk IP, ville trigge en CAPTCHA. Det
>> > er fordi, det rent statistisk er forholdsvist sjældent at danske
>> > IPer (automatisk) spammer danske hjemmesider.
> Det er nok ikke så velovervejet at servere en captcha for ale
> ikke-danske adresser. Google, bing og hvad der elles er af
> søgemaskiner holder nok ret nurtigt op med at sende trafik, hvis det
> eneste de får lov til at indexere er et forvrænget billede.

Jamen hovsa for den da.
Jeg har fuldstændig misforstået Rune.
Han mener jo at hvis den besøgende _ikke_ er en dansk ip, så skal der
præsenteres en side med captcha.
Jeg tænkte kun i mailformular baner.

Mine intentioner med at udelukke visse nationer, er ren provokation.
Akkurat som politiet i Jylland også konsekvent standser alle litauiske
biler.

PS: Tyskerne har vel altid snydt franskmændene - ikke kun i krigstid.

[Stig Johansen]

Anders Wegge Keller wrote:

> Dertil kan selvfølgelig indvendes at man kn undlade captcha for et
> passende udvalg af søgemaskiner. Det bliver bare noget bøvl, når man
> får besøg af en probe for en eller anden wordpress-vulnerability, der
> netop udgiver sig for at være GoogleBot:
>
>
> 216.95.154.102 - - [06/May/2012:10:15:09 +0200] "GET
> /wp-content/uploads/2007/02/2008.php HTTP/1.1" 404 12757
> "-" "Mozilla/5.0 (compatible; Googlebot/2.1;
> +http://www.google.com/bot.html)"
> 216.95.154.102 - - [06/May/2012:10:15:11 +0200] "GET
> /wp-content/uploads/2007/03/2008.php HTTP/1.1" 404 12757
> "-" "Mozilla/5.0 (compatible; Googlebot/2.1;
> +http://www.google.com/bot.html)"
>
> Det kan man selvflgelig også kode sig ud af. Men det tager også tid.

Har du logget om 'de' accepterer gzip encoding?

[Stig Johansen]

Jens Peter Karlsen wrote:

> Nu skrev jeg kun "professionel".
>
> Regards Jens Peter Karlsen.

Ja, ud fra et MS-brille synspunkt tror man nok at MSSQLServer er
'professionel', men i min verden (Mainframe), er MSSQLServer blot noget man
bruger til DW/BI.

[Rune Jensen]

On 8 Maj, 20:54, Anders Wegge Keller <we...@wegge.dk> wrote:

>  Det er nok ikke så velovervejet at servere en captcha for ale
> ikke-danske adresser.

Ikke helt det, jeg mener. Jeg mener, man skal _tilføje_ en captcha.
Selve siden er den samme som en dansker vil få, der er bare ét felt
mere for en ikke-dansker.

Det kan også laves som f.eks. et JS-check i stedet for en captcha.

Jeg snakker udelukkende om POST.

> Dertil kan selvfølgelig indvendes at man kn undlade captcha for et
> passende udvalg af søgemaskiner. Det bliver bare noget bøvl, når man
> får besøg af en probe for en eller anden wordpress-vulnerability, der
> netop udgiver sig for at være GoogleBot:

Mjah. Jeg laver så ikke captcha, men falske form-felter til Google-
bot, MSN-bot, Yahoo-SLURP, til w3-validator (og validatorer iøvrigt)
udfra den betragtning, at disse botter og services ikke skal poste
alligevel, så de har intet at bruge den rettighed til.

Google har intet at gøre bag en POST, uanset hvad de selv mener (og
foreløbig holder de sig også til GET - ellers ville de nok også ret
hurtigt få mange utilfredse brugere). Der er ingen, som skal poste til
min side fra en Google-cashed side heller. Så må de gå ind på selve
hjemmesiden, hvis de vil det.

Men udover at formfelternes navne er forfalskede til disse botter, så
er siden helt ens for botterne og brugeren, så der laves ikke
violation imod nogle af Googles regler heller iøvrigt.

> 216.95.154.102 - - [06/May/2012:10:15:09 +0200] "GET
>            /wp-content/uploads/2007/02/2008.php HTTP/1.1" 404 12757
>            "-" "Mozilla/5.0 (compatible; Googlebot/2.1;
>            +http://www.google.com/bot.html)"
> 216.95.154.102 - - [06/May/2012:10:15:11 +0200] "GET
>            /wp-content/uploads/2007/03/2008.php HTTP/1.1" 404 12757
>            "-" "Mozilla/5.0 (compatible; Googlebot/2.1;
>            +http://www.google.com/bot.html)"
>
>  Det kan man selvflgelig også kode sig ud af. Men det tager også tid.

Hvis man vælger at besøge en hjemmeside med Googles ID, er man så i
god tro?

Som sagt, hvis man gør det på mine sider, så får man da lov at _læse_
siden, men ikke at poste til den.

> Blacklistning kommer ret hurtigt til at gribe så meget om sig, at man
> ville kunne sikre sig overfor angreb på kortere tid og med mndre
> indsats.

Det er og var også en del af min pointe til Karl Erik. Luk hullerne i
systemet før du gør noget andet. Det har førsteprioritet.

IP-blocking (og anden black listing) skal ske i små, kontrollerede
bidder, og med logging, så man kan følge, når blockingen fejler -
hvilket den vil gøre.


MVH
Rune Jensen

[Anders Wegge Keller]

Stig Johansen <wop...@gmail.com> writes:

> Har du logget om 'de' accepterer gzip encoding?

Nej, jeg logger generelt ikke request ud over hvad jeg får i mine
logger.