---

Hej Alle.

Jeg sidder og roder med et koncept, der pt på visse områder er på
brainstormingstadiet, på andre områder på prototype stadiet.
Det skal forstås sådan, at det måske mere er sparring, jeg er ude efter.

DMZ:
Jeg kunne grumme godt tænke mig, at diverse servere i DMZ kan boote op med
DHCP + PXE, hvor DHCP+TFTP serveren står på (dele af) corporate LAN.
Den eneste mulighed jeg kan se er, at køre DMZ på (dele af) samme fysiske
LAN som corporate LAN, så spørgemålet må være:
Er der en /reel/ risiko ved at køre DMZ fysisk på corporate LAN?
Her tænker jeg på en risiko, der er så stor og skadelig, så den opvejer
ekstra omkostninger ved ekstra H/W + komplexitet.

IPTABLES:
Jeg forestiller mig at bruge Linux + IPTABLES + ? som FW's, men spørgsmålet
er, 'Er det sikkert nok(TM)[1]?'
Eller: Hvilke funktioner får man typisk ekstra i diverse kommercielle FW's,
som ikke kan løses med Linux?

mm.:
Jeg vil nok også få brug for (HTTP(S)) loadbalancing samt noget
minimalistisk HTTP(S) proxy, selvfølgelig med hotplug.
Hvordan ser markedet ud på den front? - Priser?
Linuxbaseret?
(Det er ikke til mig selv, men til evt. kommende kunder).


[1] 'sikkert nok' er et trademark of ? - Jeg synes ikke google giver mig et
entydigt svar.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
>
> Jeg kunne grumme godt tænke mig, at diverse servere i DMZ kan boote op med
> DHCP + PXE, hvor DHCP+TFTP serveren står på (dele af) corporate LAN.

Du kunne udstyre den med to netkort. Men det betyder du skal
være ekstra påpasselig med sikkerheden af netop den maskine.
Er der et root exploit, som kan udnyttes fra DMZ siden er
der fri adgang til det andet LAN.

Men hvorfor ikke bare køre to forskellige DHCP+TFTP servere?

>
> IPTABLES:
> Jeg forestiller mig at bruge Linux + IPTABLES + ? som FW's, men spørgsmålet
> er, 'Er det sikkert nok(TM)[1]?'
> Eller: Hvilke funktioner får man typisk ekstra i diverse kommercielle FW's,
> som ikke kan løses med Linux?

Jeg kan kun fortælle dig hvad man får med iptables, og det
er et ganske avanceret filter på IP, ICMP, UDP og TCP. Men
den kigger stort set ikke på de højere lag. (Den har et FTP
modul som kan genkende de ekstra TCP forbindelser som opettes
til FTP data overførsler).

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Kasper Dupont wrote:
> Stig Johansen wrote:
>
>>Jeg kunne grumme godt tænke mig, at diverse servere i DMZ kan boote op med
>>DHCP + PXE, hvor DHCP+TFTP serveren står på (dele af) corporate LAN.
>
>
> Du kunne udstyre den med to netkort. Men det betyder du skal
> være ekstra påpasselig med sikkerheden af netop den maskine.
> Er der et root exploit, som kan udnyttes fra DMZ siden er
> der fri adgang til det andet LAN.

Det interne netværkskort kan være af denne type,
http://www.snapgear.dk/specs.asp?87

Her vil selv root adgang over maskinen ikke betyde noget for firewall
reglerne i netkortet.

---

"Christian E. Lysel" wrote:
>
> Det interne netværkskort kan være af denne type,
> http://www.snapgear.dk/specs.asp?87

Smart ser det ud, men er den pris ikke lige lovlig
høj for et netkort? En ekstern router med tilsvarende
specifikationer kunne vel købes til en tredjedel af
prisen.

>
> Her vil selv root adgang over maskinen ikke betyde noget for firewall
> reglerne i netkortet.

Måske, det synes jeg ikke fremgår af den side, du
linkede til.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Kasper Dupont wrote:
>>Det interne netværkskort kan være af denne type,
>>http://www.snapgear.dk/specs.asp?87
> Smart ser det ud, men er den pris ikke lige lovlig
> høj for et netkort? En ekstern router med tilsvarende
> specifikationer kunne vel købes til en tredjedel af
> prisen.

Jeg har ikke set en router i den prisklasse der kan det samme.
Forhandler priserne ligger en del under de vejledende.

På papiret kan de, men i praksis kan de ikke. Fx er deres MTU håndtering
en af de bedste jeg har set, således blever antallet af fragmenter holdt
på et minimum.

Det er snapgear's egen uClinux, snapgear er firmaet der har været med
til mange ting til uClinux, bla. port af freeswan til MIPS.

Se evt. en demo af webgrænsefladen:
http://www.cyberguard.com/products/firewall/SG_Family/Emulator.html?lang=de_EN

Prøv at se på http://vs01.snapgear.com/cgi-bin/config?page=46, (måske er
vs01 noget andet hos dig) der bliver diverse /proc, /var/log og /etc
filer dumpet.

Emulatoren bruger UML (user mode linux), så vendor_id'et passer ikke med
virkeligheden :)

Konfigurationen ligger i http://vs01.snapgear.com/cgi-bin/config?page=24

Jeg har lavet en autokonfiguationsgenerator, og har indtil videre sat
100 snapgear automatisk op, dvs. jeg ikke har haft pakken åbnet før den
bliver sat op på sitet. I vores tilfælde fik vi TDC til at installere
den, i forbindelse med sitene fik installeret ADSL.

>>Her vil selv root adgang over maskinen ikke betyde noget for firewall
>>reglerne i netkortet.
> Måske, det synes jeg ikke fremgår af den side, du
> linkede til.

Kortet er en linux maskine, med 3 netværkskort.

Kort nr 1, er forbundet til den eksterne ethernet grænsefladen og til
firewallen.

Kort nr 2, er forbundet til firewallen og en en lokal ethernet grænseflade.

Kort nr 3, er forbundet til kort nr 2, og PCI bussen, og er det kort
PC'en ser og snakker med.

Således er der ingen forskel på kortet og at have en PC med en hardware
firewall foran.

Kortet er således også ligeglad med om det sidder i en
Sun/windows/*BSD/Linux/SCO/Mac/ectetera, blot hosten har en driver til
realtek chippen der sidder på PCI bussen.

Der er flere specs på
http://www.cyberguard.com/products/firewall/SG_Family/SG630.html?lang=de_EN

---

Kasper Dupont wrote:
Tak for svaret, se kommentarer.


> Stig Johansen wrote:
>>
>> Jeg kunne grumme godt tænke mig, at diverse servere i DMZ kan boote op
>> med DHCP + PXE, hvor DHCP+TFTP serveren står på (dele af) corporate LAN.
>
> Du kunne udstyre den med to netkort. Men det betyder du skal
> være ekstra påpasselig med sikkerheden af netop den maskine.
> Er der et root exploit, som kan udnyttes fra DMZ siden er
> der fri adgang til det andet LAN.

Jeg er meget sikker på, at der ikke vil være root exploits på netop denne
maskine.

> Men hvorfor ikke bare køre to forskellige DHCP+TFTP servere?

For at undgå redundans i mindre(små) organisationer.
(Se evt. økonomiske betragtninger i svar til hhv Alex og Christian).

>> IPTABLES:
>> Jeg forestiller mig at bruge Linux + IPTABLES + ? som FW's, men
>> spørgsmålet er, 'Er det sikkert nok(TM)[1]?'
>> Eller: Hvilke funktioner får man typisk ekstra i diverse kommercielle
>> FW's, som ikke kan løses med Linux?
>
> Jeg kan kun fortælle dig hvad man får med iptables, og det
> er et ganske avanceret filter på IP, ICMP, UDP og TCP. Men
> den kigger stort set ikke på de højere lag. (Den har et FTP
> modul som kan genkende de ekstra TCP forbindelser som opettes
> til FTP data overførsler).

Jeg ved godt hvad man får med IPTABLES.
Spørgsmålet var mere hvad man typisk får af ekstra funktionalitet i
kommercielle FW's.
Jeg kunne godt undersøge markedet, men produktkendskab har for mig ikke den
store værdi.
Baggrunden er *ikke* at jeg er doven, men at jeg føler jeg har 'malet mig
selv ind i et hjørne' mht. sikkerhedsløsninger.
Årsagen er, at jeg gennem årene har deltaget i en del udbudsforretninger,
hvor der har været lagt vægt på sikkerhed.
Det har givet detaljeret indsigt i sikkerhedskoncepter i *meget* store
nationale og internationale driftscentre, men bagsiden er, at jeg har
underskrevet NDA'er med *erstatningsansvar*.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Er der en /reel/ risiko ved at køre DMZ fysisk på corporate LAN?
> Her tænker jeg på en risiko, der er så stor og skadelig, så den opvejer
> ekstra omkostninger ved ekstra H/W + komplexitet.

Du skal have usædvanlig meget styr på dit interne netværk før jeg ville
tilråde at "spare" de penge til seperate maskiner. Ideen er jo netop at
angribere skal arbejde meget hårdt for at komme ind til workstations og
interne payroll systemer, etc.

Hvad koster det til ekstra hardware at have en seperat server?
25-50.000? Hvor lidt skal der til før en fejl/indbrud hurtigt koster
meget mere?

Køb du blot den nødvendige hardware - eller sæt risikobudgettet højt.

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

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

---

Alex Holst wrote:

Tak for svaret, kommentarer følger.

> Stig Johansen wrote:
>> Er der en /reel/ risiko ved at køre DMZ fysisk på corporate LAN?
>> Her tænker jeg på en risiko, der er så stor og skadelig, så den opvejer
>> ekstra omkostninger ved ekstra H/W + komplexitet.
>
> Du skal have usædvanlig meget styr på dit interne netværk før jeg ville
> tilråde at "spare" de penge til seperate maskiner. Ideen er jo netop at
> angribere skal arbejde meget hårdt for at komme ind til workstations og
> interne payroll systemer, etc.
>
> Hvad koster det til ekstra hardware at have en seperat server?
> 25-50.000? Hvor lidt skal der til før en fejl/indbrud hurtigt koster
> meget mere?

Som jeg skrev til Christian, skal omkostning ses i relief af
driftsbudgettet.
Som nævnt, er konceptet stadig på brainstom-stadiet.
I min verden er det god latin, at man ikke kan være kreativ og kvalitativ på
samme tid - det her er et forsøg på at være kreativ.
Jeg forsøger at lave et koncept, der er så flexibelt, at det dækker fra
noget i omegnen af enkeltmandsvirksomheder til meget store organisationer.
For (meget) små organisationer kan 25K være 'alt for dyrt'.

> Køb du blot den nødvendige hardware - eller sæt risikobudgettet højt.

Nu er det ikke mig, der skal købe HW, men eventuelle kunder.
Hvis det nogensinde bliver til noget, vil det være en individuel betragtning
pr. installation.
Det er klart, at for større organisationer, er der ingen tvivl men-
Jeg kan måske præcisere spørgsmålet til:
Kan man under *ingen* omstændigheder anbefale at køre DMZ på samme kabler,
eller kan man op til en vis størrelse sige 'Det er for besværligt at bryde
ind i forhold til værdien'.

Jeg kan eksempelvis ikke forestille mig, at der er ret mange der gider at
bruge ressourcer på at 'bryde ind' i "foo bar VVS ApS"'s produktkatalog.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Jeg forsøger at lave et koncept, der er så flexibelt, at det dækker fra
> noget i omegnen af enkeltmandsvirksomheder til meget store organisationer.
> For (meget) små organisationer kan 25K være 'alt for dyrt'.

I de tilfælde kan du skalere ned til kr. 1-2000 med et mini-itx eller
lign. system hvis det er nødvendigt.

> Kan man under *ingen* omstændigheder anbefale at køre DMZ på samme kabler,
> eller kan man op til en vis størrelse sige 'Det er for besværligt at bryde
> ind i forhold til værdien'.

Jo da. Kunden kan få en kortsigtet besparing ved at acceptere en
langsigtet risiko. Det er sjældent en god ide, i min erfaring. Sæt et
regnestykke op med en ekstra TFTP server i den ene del og et estimeret
antal timer til oprydning hvis nogen får fat i TFTP serveren i den anden
del. Peg på din anbefaling og lad kunden tage valget.

Få valget på skrift :)

> Jeg kan eksempelvis ikke forestille mig, at der er ret mange der gider at
> bruge ressourcer på at 'bryde ind' i "foo bar VVS ApS"'s produktkatalog.

Det er ikke nødvendigvis produktkataloget man går efter. Det er måske
blot nogle maskiner at gemme sig bag - eller diskplads til bittorrent.
Jeg har selv hjulpet mindre virksomheder med at komme på benene igen
efter nogle ukendte individer fandt det passende at benytte diskplads og
liniekapacitet til deres warez. Den slags aktiviteter er aldrig billige.

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

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

---

Alex Holst wrote:
> Få valget på skrift :)

Enig, folk der stejer helt vildt, plejer at skifte holdning når tingene
skal på skrift.

---

Alex Holst wrote:

> Den slags aktiviteter er aldrig billige.

Ja, selvfølgelig.
Og det er nok ofså specielt ubehageligt hvis poliiet står og banker på
døren.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> DMZ:
> Jeg kunne grumme godt tænke mig, at diverse servere i DMZ kan boote op med
> DHCP + PXE, hvor DHCP+TFTP serveren står på (dele af) corporate LAN.

Hvor meget skal din PXE server trække?

http://www.nslu2-linux.org/wiki/Main/HomePage kan hurtigt modificeres
til en PXE server. Hvis man er usikker på oppetiden, tager det ikke lang
tid at lave en reduant boks, der deler et DHCP scope.

> Den eneste mulighed jeg kan se er, at køre DMZ på (dele af) samme fysiske
> LAN som corporate LAN, så spørgemålet må være:
> Er der en /reel/ risiko ved at køre DMZ fysisk på corporate LAN?
> Her tænker jeg på en risiko, der er så stor og skadelig, så den opvejer
> ekstra omkostninger ved ekstra H/W + komplexitet.

Hvad er den ekstra omkostning?

> IPTABLES:
> Jeg forestiller mig at bruge Linux + IPTABLES + ? som FW's, men spørgsmålet
> er, 'Er det sikkert nok(TM)[1]?'

Ja, på en hardnet boks.

Men ikke hvis du tænker at køre applikationer på en server der kan
tilgås fra Internet, samtidigt med den via iptables skal beskytte sig
selv imod LAN'et. Setup'et bliver for komplekst og med for mange
"hvis"'er. Jeg vil ikke anbefalde det.

> Eller: Hvilke funktioner får man typisk ekstra i diverse kommercielle FW's,
> som ikke kan løses med Linux?

Hvis du skal bruge et simpelt firewall filter, er der ingen forskel.

Der er måske lidt længere imellem leverandører der kan hjælpe med
konsulenter.

> Jeg vil nok også få brug for (HTTP(S)) loadbalancing samt noget
> minimalistisk HTTP(S) proxy, selvfølgelig med hotplug.

Hvad er det for en belastning der skal deles ud?

Hvor skal HTTPS sessionen terminieres? På applikations siden, eller før?
Hvis før, skal oplysninger om sessions overleveres til applikationen?


Den sidste store Internet butik, jeg var på, blev bygget stort og flot.
Med masser af redudant og balancering. 4 år efter er 11 servere blivet
reduceret til 3, og vi kan godt reducere det til 2 hvis vi ville.

Hold det simpelt, det kommer du længst med.

Prøv evt. at læs afsnittet "Kompleksitet" i
http://www.miracleas.dk/images/upload/Docs/OE27_Mogens.pdf

> Hvordan ser markedet ud på den front? - Priser?
> Linuxbaseret?
> (Det er ikke til mig selv, men til evt. kommende kunder).

VIA's C3 processoren kan fylde et 100 Mbit segment med SSL trafik og kan
købes med bundkort for under 1.400 kr. Så vidt jeg huske kan den også
PXE boote.

---

Christian E. Lysel wrote:

Tak for response, kommentarer følger.

> Stig Johansen wrote:
>> DMZ:
>> Jeg kunne grumme godt tænke mig, at diverse servere i DMZ kan boote op
>> med DHCP + PXE, hvor DHCP+TFTP serveren står på (dele af) corporate LAN.
>
> Hvor meget skal din PXE server trække?

Den skal ikke trække noget særligt.
Baggrunden er, at godt kunne tænke mig en fælles DHCP+TFTP server for både
internet delen og intranet delen.
Konceptet er stadig på 'det muliges kunst' stadiet, men jeg forestiller mig,
at det i mindre organisationer vil give en administrativ lettelse.

>> Den eneste mulighed jeg kan se er, at køre DMZ på (dele af) samme fysiske
>> LAN som corporate LAN, så spørgemålet må være:
>> Er der en /reel/ risiko ved at køre DMZ fysisk på corporate LAN?
>> Her tænker jeg på en risiko, der er så stor og skadelig, så den opvejer
>> ekstra omkostninger ved ekstra H/W + komplexitet.
>
> Hvad er den ekstra omkostning?

Forretningsmæssigt - relativ.
Det vil sige, at for store organisationer med en velfungerende IT afdeling +
Infrastruktur, er det ligegyldigt, da de højst sandsynligt har separat DMZ
i forvejen.
For små organisationer, uden egen IT kompetance, kan de være (for) høje i
forhold til værdien af konceptet.

>
>> IPTABLES:
>> Jeg forestiller mig at bruge Linux + IPTABLES + ? som FW's, men
>> spørgsmålet er, 'Er det sikkert nok(TM)[1]?'
>
> Ja, på en hardnet boks.

Det vil i givet fald være en minimalistisk Linux, hvor eneste adgang (ud
over fysisk) vil være ssh m. key auth.

> Men ikke hvis du tænker at køre applikationer på en server der kan
> tilgås fra Internet, samtidigt med den via iptables skal beskytte sig
> selv imod LAN'et. Setup'et bliver for komplekst og med for mange
> "hvis"'er. Jeg vil ikke anbefalde det.

Jeg kunne ikke drømme om at køre applikationer i DMZ.

>> Eller: Hvilke funktioner får man typisk ekstra i diverse kommercielle
>> FW's, som ikke kan løses med Linux?
>
> Hvis du skal bruge et simpelt firewall filter, er der ingen forskel.

Det er kun det, ja det tangerer en simpel NAT/PAT.

> Der er måske lidt længere imellem leverandører der kan hjælpe med
> konsulenter.

Uanset hvor mange gange jeg læser denne sætning, kan jeg ikke gennemskue om
du mener:
Der er længere mellem konsulenter til IPTABLES.
eller
Der er længere mellem konsulenter til kommercialle FW's.

>> Jeg vil nok også få brug for (HTTP(S)) loadbalancing samt noget
>> minimalistisk HTTP(S) proxy, selvfølgelig med hotplug.
>
> Hvad er det for en belastning der skal deles ud?

Det kommer an på belastningen. Jeg tænker primært på oppetid samt
skalérbarhed.

> Hvor skal HTTPS sessionen terminieres? På applikations siden, eller før?

På applikationssiden.

> Hold det simpelt, det kommer du længst med.

Jeg er selv tilhænger af KIS.
Dog vælger jeg at definere det som:
Keep IT Simple.
(Det er knap så nedladende)

> Prøv evt. at læs afsnittet "Kompleksitet" i
> http://www.miracleas.dk/images/upload/Docs/OE27_Mogens.pdf

Enig, en anden fejlagtig opfattelse er: Nyt er godt.
Ikke sådan at forstå, at nyt ikke er godt, men at Nyt ikke ukritisk er godt.

> VIA's C3 processoren kan fylde et 100 Mbit segment med SSL trafik og kan
> købes med bundkort for under 1.400 kr. Så vidt jeg huske kan den også
> PXE boote.

Det jeg arbejder på er ren software, men jeg har faktisk tænkt mig at
benytte netop VIA til udvikling/afprøvning.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
>>Hvor meget skal din PXE server trække?
> Den skal ikke trække noget særligt.
> Baggrunden er, at godt kunne tænke mig en fælles DHCP+TFTP server for både
> internet delen og intranet delen.
> Konceptet er stadig på 'det muliges kunst' stadiet, men jeg forestiller mig,
> at det i mindre organisationer vil give en administrativ lettelse.

>>>Den eneste mulighed jeg kan se er, at køre DMZ på (dele af) samme fysiske
>>>LAN som corporate LAN, så spørgemålet må være:
>>>Er der en /reel/ risiko ved at køre DMZ fysisk på corporate LAN?
>>>Her tænker jeg på en risiko, der er så stor og skadelig, så den opvejer
>>>ekstra omkostninger ved ekstra H/W + komplexitet.
>>Hvad er den ekstra omkostning?
> For små organisationer, uden egen IT kompetance, kan de være (for) høje i
> forhold til værdien af konceptet.

Du kan evt. smide DMZ'en eksternt, sådan er mit eget hjemmesetup

>>>IPTABLES:
>>Ja, på en hardnet boks.
> Det vil i givet fald være en minimalistisk Linux, hvor eneste adgang (ud
> over fysisk) vil være ssh m. key auth.

Det lyder fornuftigt.

Hvis du så er rigtig parnoid, lader du kunden slå ssh til og fra, via et
simpelt menu-system på konsolen.

Jeg slår adgang fra til kunders firewalls når jeg er færdig med
arbejdet, så jeg kan dokumentere jeg ikke har fortaget efterfølgende
ændringer. Er der brug for mere hjælp kan kunden slå adgang til igen.

>>Men ikke hvis du tænker at køre applikationer på en server der kan
>>tilgås fra Internet, samtidigt med den via iptables skal beskytte sig
>>selv imod LAN'et. Setup'et bliver for komplekst og med for mange
>>"hvis"'er. Jeg vil ikke anbefalde det.
> Jeg kunne ikke drømme om at køre applikationer i DMZ.

Der tabte du mig, hvad skal du så bruge DMZ'en til?

> Det er kun det, ja det tangerer en simpel NAT/PAT.

Hvis det kun er det, vil jeg ikke anbefalde en kommicielle firewall, de
har deres verden..typisk så er der en bunke default regler du ikke
aldtid kan se, hvilket du så skal ind og slå fra.

>>Der er måske lidt længere imellem leverandører der kan hjælpe med
>>konsulenter.
> Uanset hvor mange gange jeg læser denne sætning, kan jeg ikke gennemskue om
> du mener:

Enig.

> Der er længere mellem konsulenter til IPTABLES.

iptables.

> Det kommer an på belastningen. Jeg tænker primært på oppetid samt
> skalérbarhed.

Til VVS firmaet er det vel ikke et proglem, men dine største kunder skal
du vel tænke det ind.

>>Hvor skal HTTPS sessionen terminieres? På applikations siden, eller før?
> På applikationssiden.

Ok, hvordan vil du loadbalancere?

Vil du redirecte en session til sin egen selvstændig server, og dør
serveren så bliver sessionerne til den dræbt?

Eller vil du dele en sessionstabel for applikationen og SSL forbindelsen
imellem serverne via sit eget netværkssegment, fake nogle virtuelle
MAC/IP adresser (VRRP/CARP)....(forsæt selv det komplekse setup :).

>>Hold det simpelt, det kommer du længst med.
> Jeg er selv tilhænger af KIS.
> Dog vælger jeg at definere det som:
> Keep IT Simple.
> (Det er knap så nedladende)

Jeg kan ikke se det nedladende.

>>Prøv evt. at læs afsnittet "Kompleksitet" i
>>http://www.miracleas.dk/images/upload/Docs/OE27_Mogens.pdf
> Enig, en anden fejlagtig opfattelse er: Nyt er godt.
> Ikke sådan at forstå, at nyt ikke er godt, men at Nyt ikke ukritisk er godt.

Ren og skær marketing.

>>VIA's C3 processoren kan fylde et 100 Mbit segment med SSL trafik og kan
>>købes med bundkort for under 1.400 kr. Så vidt jeg huske kan den også
>>PXE boote.
> Det jeg arbejder på er ren software, men jeg har faktisk tænkt mig at
> benytte netop VIA til udvikling/afprøvning.

Kan du ikke få din applikation hostet ude i byen til de små kunder?

---

Christian E. Lysel wrote:

>>>Men ikke hvis du tænker at køre applikationer på en server der kan
>>>tilgås fra Internet, samtidigt med den via iptables skal beskytte sig
>>>selv imod LAN'et. Setup'et bliver for komplekst og med for mange
>>>"hvis"'er. Jeg vil ikke anbefalde det.
>> Jeg kunne ikke drømme om at køre applikationer i DMZ.
>
> Der tabte du mig, hvad skal du så bruge DMZ'en til?

Jeg ved ikke lige hvad jeg tænkte da jeg skrev det.
Det jeg mener er, at jeg ikke kunne drømme om at køre forretningskritiske
applikationer på servere der er tilgængelige fra internettet.

>>>Hvor skal HTTPS sessionen terminieres? På applikations siden, eller før?
>> På applikationssiden.
>
> Ok, hvordan vil du loadbalancere?

Det ved jeg ikke endnu. I første omgang nok bare Round Robin.

> Vil du redirecte en session til sin egen selvstændig server, og dør
> serveren så bliver sessionerne til den dræbt?
>
> Eller vil du dele en sessionstabel for applikationen og SSL forbindelsen
> imellem serverne via sit eget netværkssegment, fake nogle virtuelle
> MAC/IP adresser (VRRP/CARP)....(forsæt selv det komplekse setup :).

Konceptet er stadig mere eller mindre på idé stadiet.
Jeg ved godt, der er særlige problemstillinger med session management, men
det må komme senere.
Jeg leger lidt med tanken om redundante session management services.

>>>Hold det simpelt, det kommer du længst med.
>> Jeg er selv tilhænger af KIS.
>> Dog vælger jeg at definere det som:
>> Keep IT Simple.
>> (Det er knap så nedladende)
>
> Jeg kan ikke se det nedladende.

Ja, det ser ud til, jeg har en netværksfejl mellem hjernen og keyboardet.
Normalt siger man KISS, og det er det sidste Stupid, jeg synes lyder lidt
nedladende. Jeg er på ingen måde følsom, men hvis jeg siger det til en
kunde føler jeg lidt, at jeg implicit siger han er dum.

--
Med venlig hilsen
Stig Johansen