---

Som led i et projekt skal jeg designe et firewall system til IT-C.

Jeg har lavet et diagram over min firewalls arkitektur som ligger på
http://www.it.edu/~morton/firewall.jpg

En kort forklaring: VIP er forskere, mens STUD er studerende. Således er de
to VIP hhv. STUD DMZer, steder hvor studerende og forskere kan sætte mere
risikofyldte servere op, med åbne porte ud mod nettet.

"C" er bare alm. klienter. Disse må selvfølgelig ikke kunne
nås/identificeres direkte fra nettet, ergo ligger de bag en router der
samtidig anvender NAT.

Bastion www, DNS og mail er så de vigtige offentlig tilgængelige servere.

Spørgsmålet er om designet virker godt nok. Den router der ligger ud mod
nettet virker noget sårbar. Ergo overvejer jeg at bytte denne ud, el.
forlænge denne, med en firewall der ikke har nogen IP-adresse (kan ikke
huske hvad disse hedder - anyone!?).

Kommentarer modtages meget gerne!

TIA

-- Morton

---

Morton P. Christiansen <morton_c@worldonline.dk> wrote:
> Som led i et projekt skal jeg designe et firewall system til IT-C.
>
> Jeg har lavet et diagram over min firewalls arkitektur som ligger på
> http://www.it.edu/~morton/firewall.jpg
>
> Bastion www, DNS og mail er så de vigtige offentlig tilgængelige servere.
>
> Spørgsmålet er om designet virker godt nok. Den router der ligger ud mod
> nettet virker noget sårbar. Ergo overvejer jeg at bytte denne ud, el.
> forlænge denne, med en firewall der ikke har nogen IP-adresse (kan ikke
> huske hvad disse hedder - anyone!?).

Det hedder en bridging firewall. Jeg ville ikke skifte routeren ud med en
firewall, da de fleste firewalls ikke er fabelagtige til at route trafik.
Hvorfor foeler du at den ydereste router er udsat? Hvilke services skal
koere paa den?

Dit design indeholder et par single points of failure. Er det acceptabelt?

I hvilke retninger havde du planer om at tillade trafik, og hvis der er mere
end een type trafik og een retning: hvilke typer trafik havde du taenkt dig
at tillade i de forskellige retninger?

Ud fra dit diagram forstaar jeg, at f.eks. jeres DNS server frit kan sende
trafik til jeres mail og www serverei -- og omvendt. Har du virkeligt lyst
til det? Hvis du ikke har mulighed for per VLAN filtering, har du saa
mulighed for host filters?

Er det klienter der sidder direkte paa dit VIP DMZ?

Skal STUD og VIP maskinerne bag NAT have lov til at sende trafik til
hinanden?

Hvilke former for authentication skal benyttes mod de forskellige services?

Jeg har flere spoergsmaal, men nu skal jeg ud og drikke roedvin.

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

---

Alex Holst wrote:

>Jeg har flere spoergsmaal, men nu skal jeg ud og drikke roedvin.

Alex Holst, ladies and gentleman! He'll be here all week.

--
http://chran.dyndns.dk - Nu med konsulentbistand!

Tina Dickow - Fuel. Et album du MÅ eje!

---

Christian Andersen <m4jni76ztglp001@sneakemail.com> wrote:
> Alex Holst wrote:
>
>>Jeg har flere spoergsmaal, men nu skal jeg ud og drikke roedvin.
>
> Alex Holst, ladies and gentleman! He'll be here all week.

Ugh, shhh. Ikke taste saa haardt. Jeg har det rigtigt daarligt i dag.

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

---

Alex Holst wrote:

>>>Jeg har flere spoergsmaal, men nu skal jeg ud og drikke roedvin.

>> Alex Holst, ladies and gentleman! He'll be here all week.

>Ugh, shhh. Ikke taste saa haardt. Jeg har det rigtigt daarligt i dag.

Drik noget cola, det hjæølper på tømmermænd.

--
http://chran.dyndns.dk - Nu med konsulentbistand!

Tina Dickow - Fuel. Et album du MÅ eje!

---

"Christian Andersen" <m4jni76ztglp001@sneakemail.com> wrote in message
news:3c207148$0$62890$edfadb0f@dspool01.news.tele.dk...

> Drik noget cola, det hjæølper på tømmermænd.

> http://chran.dyndns.dk - Nu med konsulentbistand!

Hvad man dog finder på nettet...!

vh
Jan

---

Jan Boegh wrote:

>> Drik noget cola, det hjæølper på tømmermænd.
>
>> http://chran.dyndns.dk - Nu med konsulentbistand!

>Hvad man dog finder på nettet...!

Ja, det er utroligt er det ikke?

--
http://chran.dyndns.dk - Nu med konsulentbistand!

Tina Dickow - Fuel. Et album du MÅ eje!

---

"Christian Andersen" <m4jni76ztglp001@sneakemail.com> wrote in message
news:3c20d876$0$62851$edfadb0f@dspool01.news.tele.dk...
> Jan Boegh wrote:
>
> >> Drik noget cola, det hjæølper på tømmermænd.
> >
> >> http://chran.dyndns.dk - Nu med konsulentbistand!
>
> >Hvad man dog finder på nettet...!
>
> Ja, det er utroligt er det ikke?

Jowda - på den anden side så synes jeg dog at det er et af
de mere sobre konsulent-svar - jeg har oplevet denne race komme
med langt mindre anvendelige råd end dit.

Så når jeg i morgen skal mødes med et par stykker af slagsen,
har jeg nu en reference jeg kan måle deres rådgivning på.

vh
Jan

---

Jan Boegh wrote:

>Så når jeg i morgen skal mødes med et par stykker af slagsen,
>har jeg nu en reference jeg kan måle deres rådgivning på.

Prøv at drikke dig fuld først, så er det sikkert en del mere
interessant.

--
http://chran.dyndns.dk - Nu med konsulentbistand!

Tina Dickow - Fuel. Et album du MÅ eje!

---

"Christian Andersen" <m4jni76ztglp001@sneakemail.com> wrote in message
news:3c20fc6c$0$62890$edfadb0f@dspool01.news.tele.dk...


> Prøv at drikke dig fuld først, så er det sikkert en del mere
> interessant.

Et endog meget attraktivt råd.
Jeg er overbevist om at du har kvaliteterne til at kunne blive
min yndlingskonsulent )
Ham jeg talte med idag (desværre helt ædru) ville bare sælge
noget så kedeligt som båndbredde.

mvh
Jan

---

Jan Boegh wrote:

>> Prøv at drikke dig fuld først, så er det sikkert en del mere
>> interessant.

>Et endog meget attraktivt råd.
>Jeg er overbevist om at du har kvaliteterne til at kunne blive
>min yndlingskonsulent )

Ja. Jeg opfordrer mine klienter til at blive fulde. Det skal nok gå godt


"Du er min beschte ven!" - "Ja, ja. Skriv nu under her."

>Ham jeg talte med idag (desværre helt ædru) ville bare sælge
>noget så kedeligt som båndbredde.

Båndbredde er godt.

--
http://chran.dyndns.dk - Nu med konsulentbistand!

Tina Dickow - Fuel. Et album du MÅ eje!

---

> Dit design indeholder et par single points of failure.
Forhåbentligt er der vel ikke flere..!? ;-\

> I hvilke retninger havde du planer om at tillade trafik, og hvis der er
mere
> end een type trafik og een retning: hvilke typer trafik havde du taenkt
dig
> at tillade i de forskellige retninger?

Ingen servere på VIP og STUD nettet (spæret af den indre router). Tilgengæld
al udgående (mod Internetet) trafik tilladt herfra, med mindre andet er
eksplicit sat.
Serverne (hvad enten det er på VIP DMZ, STUD DMZ el. bare "DMZ"!) får åbnet
indgangen efter behov individuelt. Udgående trafik herfra ønskes undgået.

> Ud fra dit diagram forstaar jeg, at f.eks. jeres DNS server frit kan sende
> trafik til jeres mail og www serverei -- og omvendt. Har du virkeligt lyst
> til det? Hvis du ikke har mulighed for per VLAN filtering, har du saa
> mulighed for host filters?
God pointe. Så vi forbinder de forskellige bastioner til en VLAN switch (/me
trækker kabler! :+))

> Er det klienter der sidder direkte paa dit VIP DMZ?
Argh. Nej, selvfølgelig ikke - tegnefejl.

> Skal STUD og VIP maskinerne bag NAT have lov til at sende trafik til
> hinanden?
Nej.

> Hvilke former for authentication skal benyttes mod de forskellige
services?
Mener du på applikationsniveau el. authentication af nodes el...?

Dit forslag/kommentarer?

Og så iøvrigt tak for et "tankevækkende" indslag!

-- Morton

---

"Morton P. Christiansen" wrote:
>
> > Dit design indeholder et par single points of failure.
> Forhåbentligt er der vel ikke flere..!? ;-\

Som det fremgår af tegningen vil studnet og vipnet hver
skulle igennem mindsst tre netsegmenter og to routere før
de når den første mulighed for alternative ruter. Dermed
vil alle disse netsegmenter og begge routere udgøre single
points of failure.

Det er meget normalt at sætte netværk op med single points
of failure, man skal blot være opmærksom på problemet og
vilig til at leve med det.

--
Kasper Dupont

---

Morton P. Christiansen <morton_c@worldonline.dk> wrote:
> Ingen servere på VIP og STUD nettet (spæret af den indre router).
> Tilgengæld al udgående (mod Internetet) trafik tilladt herfra, med mindre
> andet er eksplicit sat. Serverne (hvad enten det er på VIP DMZ, STUD DMZ
> el. bare "DMZ"!) får åbnet indgangen efter behov individuelt. Udgående
> trafik herfra ønskes undgået.

Begraesning af udgaaende trafik er en god ting at vaere opmaerksom paa da
det drastisk formindsker en angribers muligheder for at faa opnaa
kommandolinie adgang paa en maskine, skulle han eller hun finde en metode
til at udfoere kommandoer.

Det boer haenge sammen med et "deny all" regelsaet for indgaaende
forbindelse, som indeholder specifikke regler der tillader trafik til port
80 og 443 paa www serveren, port 25 til mail serveren, etc. Disse filtre
alene goer at en angriber skal ud i en del krumspring for at kunne bruge en
saarbar service eller CGI til noget. Man fejer effektivt trusslen fra script
kiddies af bordet.

I nogle tilfaelde betyder det endda at man ikke skal ud af sengen kl 4 om
natten for at patche BIND, men i stedet kan vente til naeste morgen -- det
kommer naturligvis an paa hvad det er du beskytter.

> > Ud fra dit diagram forstaar jeg, at f.eks. jeres DNS server frit kan
> > sende trafik til jeres mail og www serverei -- og omvendt. Har du
> > virkeligt lyst til det? Hvis du ikke har mulighed for per VLAN
> > filtering, har du saa mulighed for host filters?
> God pointe. Så vi forbinder de forskellige bastioner til en VLAN switch
> (/me trækker kabler! :+))

Mail maskinerne skal naturligvis tale til DNS serveren paa et tidspunkt saa
det skal der vaere mulighed for. WWW maskinerne skal ogsaa i mindre omfang.

> > Hvilke former for authentication skal benyttes mod de forskellige
> > services?
> Mener du på applikationsniveau el. authentication af nodes el...?

Jeg mener: hvordan skal jeres sysadmins authenticate naar de logger ind i
jeres routere og kritiske maskiner? Hvordan skal brugere authenticate hvis
de logger ind paa f.eks. jeres www server? Hvis du har mulighed for det boer
du benytte noget andet end passwords.

Du kan ogsaa komme et stykke vej ved kun at tillade logins fra den IP range
som sysadmins og evt. brugere sidder paa.

Hvilken rolle skal dine bastion maskiner uden for NAT routeren fylde?

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

---

Alex Holst <a@area51.dk> writes:

> Jeg mener: hvordan skal jeres sysadmins authenticate naar de logger ind i
> jeres routere og kritiske maskiner? Hvordan skal brugere authenticate hvis
> de logger ind paa f.eks. jeres www server? Hvis du har mulighed for det boer
> du benytte noget andet end passwords.

Hvad vil du anbefale istedet for passwords?
(Ikke at jeg skal bruge det til noget men
er bare nysgerrig)


Martin

---

Martin Schultz wrote:
>
> Alex Holst <a@area51.dk> writes:
>
> > Jeg mener: hvordan skal jeres sysadmins authenticate naar de logger ind i
> > jeres routere og kritiske maskiner? Hvordan skal brugere authenticate hvis
> > de logger ind paa f.eks. jeres www server? Hvis du har mulighed for det boer
> > du benytte noget andet end passwords.
>
> Hvad vil du anbefale istedet for passwords?
> (Ikke at jeg skal bruge det til noget men
> er bare nysgerrig)

Man kunne bruge nøglebasseret autentifikation. Men passwords
udgør et væsentligt mindre problem, hvis man nøjes med at
bruge dem over sikre forbindelser. Protokoler der sender
passwords i klartekst skal undgås.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:
> Men passwords udgør et væsentligt mindre problem, hvis man nøjes med at
> bruge dem over sikre forbindelser. Protokoler der sender passwords i
> klartekst skal undgås.

I disse tider med SSH og switched netvaerk er sniffing ikke saa stor en
trussel som det har vaeret, og de fleste organisationer er meget lang tid om
at reagere paa de "nye" trusler.

Jeg har set langt flere eksempler paa passwords der er blevet stjaalet fra
en maskine efter et indbrud (enten ved at cracke system password filen,
eller ved at droppe en trojansk ssh klient ind) end jeg har set passwords
der er blevet sniffet.

Det gaelder om at komme vaek fra authentication information der kan genbruges
af en angriber uden at det bliver opdaget i tide. Der skal meget arbejde til
for at kunne misbruge to faktor authentication (blandt andet indbrud paa
folks workstations eller at overfalde sysadmins efter arbejde og slaa indtil
staklen giver sin token og pin fra sig).

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

---

In article <slrna241hk.2cog.a@C-Tower.Area51.DK>, Alex Holst wrote:

>> Men passwords udgør et væsentligt mindre problem, hvis man nøjes med at
>> bruge dem over sikre forbindelser. Protokoler der sender passwords i
>> klartekst skal undgås.
>
> I disse tider med SSH og switched netvaerk er sniffing ikke saa stor en
> trussel som det har vaeret, og de fleste organisationer er meget lang tid om
> at reagere paa de "nye" trusler.

Kan alle skiddies ikke efterhånden finde ud af at arp-spoofe eller
arp-floode i de tilfælde, hvor det virker?

--
Andreas Plesner Jacobsen | micro:
| Thinker toys.

---

Andreas Plesner Jacobsen <apj@daarligstil.dk> wrote:
> In article <slrna241hk.2cog.a@C-Tower.Area51.DK>, Alex Holst wrote:
>> I disse tider med SSH og switched netvaerk er sniffing ikke saa stor en
>> trussel som det har vaeret, og de fleste organisationer er meget lang tid om
>> at reagere paa de "nye" trusler.
>
> Kan alle skiddies ikke efterhånden finde ud af at arp-spoofe eller
> arp-floode i de tilfælde, hvor det virker?

De fleste kiddies forstaar ikke hvordan dsniff virker, da det kraever mere
end een kommando at spoofe arp eller dns og derefter mitm paa SSH. Desuden
skal brug af SSH komplementeres af en clueful sysadmin der siger "wtf?" naar
hans SSH klient fortaeller om en aendret hostkey. Nogle SSH klienter brokker
sig desvaerre ikke naar en hostkey aendres.

Med to faktor authentication ville en angriber ikke senere faa blanket
adgang til systemet da authentication informationen ikke kan genbruges, men
man skal naturligvis vaere opmaerksom paa sshmitm -I:

-I Monitor / hijack an interactive session.

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

---

Alex Holst wrote:
>
> De fleste kiddies forstaar ikke hvordan dsniff virker, da det kraever mere
> end een kommando at spoofe arp eller dns og derefter mitm paa SSH. Desuden
> skal brug af SSH komplementeres af en clueful sysadmin der siger "wtf?" naar
> hans SSH klient fortaeller om en aendret hostkey.

Så vidt jeg erindrer opdager openssh hvis en hostkey er ændret.
Man bliver ikke spurgt om man ønsker at fortsætte, der kommer
blot en advarsel med STORE bogstaver og openssh nægter at
connecte.

> Nogle SSH klienter brokker
> sig desvaerre ikke naar en hostkey aendres.

Det er jo meget skidt, så er der ikke særlig meget sikkerhed
tilbage.

>
> Med to faktor authentication ville en angriber ikke senere faa blanket
> adgang til systemet da authentication informationen ikke kan genbruges, men
> man skal naturligvis vaere opmaerksom paa sshmitm -I:
>
> -I Monitor / hijack an interactive session.

Den har jeg alligevel aldrig hørt om.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:
> Så vidt jeg erindrer opdager openssh hvis en hostkey er ændret.
> Man bliver ikke spurgt om man ønsker at fortsætte, der kommer
> blot en advarsel med STORE bogstaver og openssh nægter at
> connecte.

Det er faktisk en option (StrictHostKeyChecking) i ~/.ssh/config saa man kan
indstille hver klient i overensstemmelse med den lokale politik.

>> Nogle SSH klienter brokker
>> sig desvaerre ikke naar en hostkey aendres.
>
> Det er jo meget skidt, så er der ikke særlig meget sikkerhed
> tilbage.

Endnu en grund til at holde sig fra ssh.com's og F-Secure's klienter. Jeg
ved ikke om SecureCRT er smartere.

>> man skal naturligvis vaere opmaerksom paa sshmitm -I:
>>
>> -I Monitor / hijack an interactive session.
>
> Den har jeg alligevel aldrig hørt om.

sshmitm er en del af dsniff, skrevet af Dug Song. (OpenBSD/OpenSSH
udvikler). http://www.monkey.org/~dugsong/dsniff/

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

---

On Fri, 21 Dec 2001 01:14:49 +0100, Alex Holst <a@area51.dk> wrote:

[...]

>>> Nogle SSH klienter brokker
>>> sig desvaerre ikke naar en hostkey aendres.
>>
>> Det er jo meget skidt, så er der ikke særlig meget sikkerhed
>> tilbage.
>
>Endnu en grund til at holde sig fra ssh.com's og F-Secure's klienter. Jeg
>ved ikke om SecureCRT er smartere.

Kan bekrefte at SecureCRT klager faelt om hostkey er aendret.

[...]

--
remove no- to reply.

---

Martin Schultz <di010416@diku.dk> wrote:
> Hvad vil du anbefale istedet for passwords?

To faktor authentication (noget man har _og_ noget man ved). Det kan vaere
SSH noegler og en lang passphrase, eller en fysisk token og et pin eller
password.

I SSH's tilfaelde er RSA eller DSA noegler meget staerke hvis de ellers
bliver behandlet korrekt af ejeren og det er en ganske billig loesning. Hvis
man har mange maskiner og mange ansatte kan det blive noget rod -- isaer
hvis man ikke har en account management system der kan fjerne eller give
adgang til produktionsmaskiner. Et noeglesystem benytter ikke en central
resource som bestemmer om en bruger skal have lov at logge ind eller ej.

De fleste token baserede systemer og Kerberos har et centralt punkt som
kontaktes, men det koster penge i form af server software, tokens og server
hardware. Der udover skal serveren vedligeholdes og have naesten 100%
oppetid.

Kerberos kan skalere ret godt, men bruger som standard en passphrase til at
kryptere dens tickets. I nogle tilfaelde kan denne passphrase skiftes ud med
nummeret fra en token samt et pin. Dette goer at en angriber ikke kan bruge
X uger paa at cracke sig frem til passphrase, for derefter at faa adgang som
den bruger indtil vedkommende skifter passphrase igen.

Et token nummer og pin brugt som kryptering af en Kerberos ticket kan
crackes meget hurtigere end en god passphrase kan, men kan ikke genbruges,
og det er det vigtigste.

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