---

Jeg er pt. igang med at kigge på firewall løsninger til en større
organisation.

Valget af 'kasse' mellem Internettet og VLAN'et med bla. mail servere
har fået mig til at tænke over om man bør gå efter en firewall med en
SMTP proxy eller en firewall med L7 funktionalitet.

Det der taler for førstnævnte er naturligvis at ens mailservere aldig
bliver direkte eksponeret mod internettet. Istedet er man 100% afhængig
af sikkerheden i den hærdede SMTP server som firewall'en/proxien benytter.

Det der taler for sidstnævnte er vel primært at man også beskyttes mod
uheldigt indhold i de enkelte mails - og at der er en væsentligt større
fleksibilitet omkring hvad man ønsker at tillade og ikke tillade.

Helt konkret kan jeg nævne at de produkter der kigges på er Borderware's
Steelgate som falder i den første kategori. Sonicwalls Pro 4100 som
falder i den sidste.
og Astaro's ASG 220 som kombinerer de to ting (så vidt jeg kan se).

Nogen der vil dele deres tanker med mig ??

--
Mail mig på uffe <snabelA> skelmose <prik> dk

---

"Uffe S. Callesen" wrote:
>
> Jeg er pt. igang med at kigge på firewall løsninger til en større
> organisation.
>
> Valget af 'kasse' mellem Internettet og VLAN'et med bla. mail servere
> har fået mig til at tænke over om man bør gå efter en firewall med en
> SMTP proxy eller en firewall med L7 funktionalitet.

Jeg vil råde imod at have en firewall til at holde øje med
SMTP transaktionerne. Protokollen er så kompliceret, at der
nemt kan være fejl i software, som skal holde øje med
kommunikationen mellem klient og server. Så ville jeg hellere
sætte en ekstra SMTP server ind imellem og lave filtre på
pakkeniveau.

Hvis sådan en server holdes på et minimum af funktionalitet
og kun implementerer hvad SMTP protokollen kræver, så kan det
gøres med omkring 10KB sourcekode.

Omkring sådan et primitivt SMTP relay kan man så lave
pakkefiltre, så kun de absolut nødvendige TCP forbindelser
kan etableres. Relayet kan jo konfigureres, så det sender alt
videre til den egentlige mailserver på en kendt IP adresse.
Dermed er der end ikke brug for DNS opslag.

Jeg vil tro det er nemmest at lave en sikker løsning, hvis
man bruger forskellige servere til indgående og udgående email.

>
> Helt konkret kan jeg nævne at de produkter der kigges på er Borderware's
> Steelgate som falder i den første kategori. Sonicwalls Pro 4100 som
> falder i den sidste.
> og Astaro's ASG 220 som kombinerer de to ting (så vidt jeg kan se).

Jeg kender ikke de konkrete produkter, så jeg kan ikke udtale
mig om, hvorvidt de fungerer på den måde jeg ville anbefale.

--
Kasper Dupont
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Kasper Dupont wrote:
> Jeg vil råde imod at have en firewall til at holde øje med
> SMTP transaktionerne. Protokollen er så kompliceret, at der

Intet siger at den fulde protokol skal implementeres.

---

"Christian E. Lysel" wrote:
>
> Kasper Dupont wrote:
> > Jeg vil råde imod at have en firewall til at holde øje med
> > SMTP transaktionerne. Protokollen er så kompliceret, at der
>
> Intet siger at den fulde protokol skal implementeres.

Hvis en firewall skal overvåge en kommunikation hvor den selv
er hverken klient eller server, så er den næsten nødt til at
implementere den fulde protokol.

Jeg ved da også, at dengang vi fik vores første Pix forsøgte
den at overvåge kommunikationen. Men det virkede ikke korrekt.
En passende sekvens af kommandoer, og pludselig troede
firewallen at man var i gang med at sende data selvom det
ikke var tilfældet. Så kunne man pludseligt sende vilkårlige
kommandoer lige gennem firewallen.

Det er blot et eksempel på, hvad der kan gå galt.

--
Kasper Dupont
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Kasper Dupont wrote:
>>Intet siger at den fulde protokol skal implementeres.
>
>
> Hvis en firewall skal overvåge en kommunikation hvor den selv
> er hverken klient eller server, så er den næsten nødt til at
> implementere den fulde protokol.

Følgende behøver man ikke at supportere:

ESMTP
AUTH
ARTN
ETRN
EXPN
VRFY

> Jeg ved da også, at dengang vi fik vores første Pix forsøgte
> den at overvåge kommunikationen. Men det virkede ikke korrekt.
> En passende sekvens af kommandoer, og pludselig troede
> firewallen at man var i gang med at sende data selvom det
> ikke var tilfældet. Så kunne man pludseligt sende vilkårlige
> kommandoer lige gennem firewallen.
>
> Det er blot et eksempel på, hvad der kan gå galt.

Er det ikke blot en statefull inspection application layer firewall når
den er værst, i sit forsøg på at efterligne en proxy servers egenskaber?

Borderware og Raptor/Symantec har ikke haft ligende børne sygdomme.
Symantec'en havde men det bundede "blot" i en fejl opsætning af http
proxien.

---

"Christian E. Lysel" wrote:
>
> Kasper Dupont wrote:
> >>Intet siger at den fulde protokol skal implementeres.
> >
> >
> > Hvis en firewall skal overvåge en kommunikation hvor den selv
> > er hverken klient eller server, så er den næsten nødt til at
> > implementere den fulde protokol.
>
> Følgende behøver man ikke at supportere:
>
> ESMTP
> AUTH
> ARTN
> ETRN
> EXPN
> VRFY

Og hvad vil du så gøre når klienten sender sådan
en kommando, og serveren svarer på den?

--
Kasper Dupont
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Kasper Dupont wrote:

> Og hvad vil du så gøre når klienten sender sådan
> en kommando, og serveren svarer på den?

Økse forbindelsen!

--
Niels Callesøe - dk pfy
pfy[at]nntp.dk - http://www.t29.dk/~nica/disclaimer.php

SKDLD!

---

Den 04 Jan 2006 07:29:31 GMT skrev Niels Callesøe:
> Kasper Dupont wrote:
>
>> Og hvad vil du så gøre når klienten sender sådan
>> en kommando, og serveren svarer på den?
>
> Økse forbindelsen!

På samme måde som visse (specielt Cisco) firewalls afviser connections
fra maskiner der kører ECN? "Så kan du bare ikke modtage mails fra
dem!"

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:

>>> Og hvad vil du så gøre når klienten sender sådan
>>> en kommando, og serveren svarer på den?
>>
>> Økse forbindelsen!
>
> På samme måde som visse (specielt Cisco) firewalls afviser
> connections fra maskiner der kører ECN? "Så kan du bare ikke
> modtage mails fra dem!"

Præcis! Både det ene og det andet er jo sådan noget nymodens skrammel,
det kan vi virkelig ikke have.

--
Niels Callesøe - dk pfy
pfy[at]nntp.dk - http://www.t29.dk/~nica/disclaimer.php

Serious +[-------------------|-]- Sarcastic

---

>>>>> "KD" == Kasper Dupont <15336448385666263580@expires.14.feb.2006.kasperd.net.invalid> writes:

KD> "Christian E. Lysel" wrote:

>> Følgende behøver man ikke at supportere:
>>
>> ESMTP AUTH ARTN ETRN EXPN VRFY

KD> Og hvad vil du så gøre når klienten sender sådan en kommando,

Senden en not-supported tilbage til klienten og pille kommandoen ud af
datastrømmen.

KD> og serveren svarer på den?

Det gør serveren ikke, for serveren ser den ikke.


/Benny

---

On Tue, 03 Jan 2006 23:03:00 +0100, Kasper Dupont
<15336448385666263580@expires.14.feb.2006.kasperd.net.invalid> wrote:

>> VRFY

> Og hvad vil du så gøre når klienten sender sådan en kommando,

"500 #5.5.1 command not recognized".

> og serveren svarer på den?

Det gør den ikke, for man sender den ikke videre.

-A

---

On Mon, 02 Jan 2006 11:12:32 +0100, "Uffe S. Callesen"
<anon@anon.local> wrote:

> Valget af 'kasse' mellem Internettet og VLAN'et med bla. mail servere
> har fået mig til at tænke over om man bør gå efter en firewall med en
> SMTP proxy eller en firewall med L7 funktionalitet.

IMO bør man til en større organisation placere externt tilgængelige
mail-servere på et separat ben på firewall'en, ikke sende mail direkte
ind til de 'indre' mail-servere. De pågældende servere kan så passende
være noget, der kan (er beregnet til at) lave anti-spam, anti-virus
etc.

IMO bør man ikke køre en SMTP-server (eller 'proxy') på en firewall.
Man får en simplere firewall og mere funktionalitet ved at vælge den
førstnævnte løsning.

-A

---

Asbjorn Hojmark wrote:
> IMO bør man til en større organisation placere externt tilgængelige
> mail-servere på et separat ben på firewall'en, ikke sende mail direkte
> ind til de 'indre' mail-servere. De pågældende servere kan så passende
> være noget, der kan (er beregnet til at) lave anti-spam, anti-virus
> etc.

Så det setup du beskriver er noget lignende:

Inet -> Firewall -> SSN -> AV/antispam-box -> mailserver

?

--
Mail mig på uffe <snabelA> skelmose <prik> dk

---

On Mon, 02 Jan 2006 13:08:49 +0100, "Uffe S. Callesen"
<anon@anon.local> wrote:

> Inet -> Firewall -> SSN -> AV/antispam-box -> mailserver

Jeg er ikke sikker på, hvad du mener med "SSN", måske 'secure server
net', der er en BorderWare-betegnelse. (Normalt bruges det om et CPR-
nummer fra USA, social security number). Folk kalder det tit et 'DMZ-
net', omend det ikke har noget med en demilitrariseret zone at gøre
(hverken i krigs- eller it-termer). Det er et separat netværk, typisk
på 'siden' af en firewall, som bruges til alle ingående forbindelser,
sådan at ingenting tillades at lave forbindelser ind til en intern
server.

Ja, det er et meget almindeligt setup i større organisationer. Før i
tiden var anti-virus/anti-spam-boxen (i din skitse) typisk en 'general
purpose' mail-server (som Exchange eller Domino), typisk med noget AV-
software på. Anti-virus/anti-spam-løsningen er dog ved at være ret
almindelig i en eller flere boxe.

-A

---

> Det er et separat netværk, typisk
> på 'siden' af en firewall, som bruges til alle ingående forbindelser,
> sådan at ingenting tillades at lave forbindelser ind til en intern
> server.

Er dette et eksempel på, hvad en DMZ kan være, eller et eksempel på den
typiske misforståelse?

Ovenstående beskrivelse passer nemlig meget godt på min definition af en
DMZ, men i fald det ikke er, så vil jeg gerne vide det...

- Mikkel

---

On Sat, 14 Jan 2006 12:07:17 +0100, "Mikkel H. Nielsen"
<mhn@FJERNMIG.onbeat.dk> wrote:

>> Det er et separat netværk, typisk på 'siden' af en firewall, som
>> bruges til alle ingående forbindelser, sådan at ingenting tillades
>> at lave forbindelser ind til en intern server.

> Er dette et eksempel på, hvad en DMZ kan være, eller et eksempel på
> den typiske misforståelse?

Well, I Gamle Dage(TM) var DMZ området mellem to forskellige firewalls
(og i Rigtig Gamle Dage(TM) var det mellem to hære). I dag bruges det
ofte om det med et ben på siden af en firewall. Jeg skrev det sådan,
fordi 'DMZ' kan blive misforstået.

-A

---

Asbjorn Hojmark wrote:
> Well, I Gamle Dage(TM) var DMZ området mellem to forskellige firewalls

Du mener vel mellem to routere der ikke har hinandens routes (firewalls
eksistere jo ikke dengang).

Net A----R1----DMZ---R2----Net B

Net A kan route R1.
R1 kan route til DMZ
DMZ kan route til R2
R2 kan route til Net B

Men R1 kan ikke route til R2, ej Net A til Net B:

Hvis det var rigtigt vildt kunne R2 og Net B evt. køre en anden protokol
end IP, fx IPX, som maskinen på DMZ også skulle understøtte.


I dag er boks løsninger populærer, så R1, DMZ og R2 er blevet smidt ind
i en firewall (FW), der har et ben til DMZ nettet.

DMZ
|
Net A --FW-- Net B

---

Uffe S. Callesen wrote:
> Jeg er pt. igang med at kigge på firewall løsninger til en større
> organisation.
[..]
> Nogen der vil dele deres tanker med mig ??

Tænk over hvor meget kode der er tilgængeligt fra internettet.

En application proxy giver kun mening i de tilfælde hvor man har en
meget komplex applikation der ikke kan gøres mere simpel og heller ikke
kan udskiftes, og derfor ikke har noget andet valg end at sætte et
simplere og mere pålideligt produkt op foran til at tage de værste slag.

Du har ikke nævnt hvilken MTA du benytter og jeg kender ikke de nævnte
produkter, men hvis jeg skulle designe en SMTP proxy ville jeg antage,
at der var fejl i min kode og designe således at de ikke gav angriberen
mulighed for at komme videre.

Den slags indrømmelser finder man næppe i kommercielt software og derfor
vil der nok ikke være ret meget defense in depth at hente. Du bør se på,
om en fejl i proxy produktet vil forhindre at angriberen tager kontrol
med proxy systemet og/eller fortsætter sit angreb videre ind på dit netværk.

--
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:
>
> Du har ikke nævnt hvilken MTA du benytter og jeg kender ikke de nævnte
> produkter, men hvis jeg skulle designe en SMTP proxy ville jeg antage,
> at der var fejl i min kode og designe således at de ikke gav angriberen
> mulighed for at komme videre.

Tja, hvis man opnår 100% kontrol over proxyen kan man læse og
modificere al indgående email. Og man kan gå i gang med at
angribe mailserveren bagved.

Hvis man kun opnår kontrol over en enkelt process på proxyen
så vil man være begrænset til at forsøge på at angribe den
bagvedliggende mailserver.

Det med at begrænse skaden til en enkelt process kan lade sig
gøre på nogle OS. Det forudsætter selvfølgelig at angriberen
ikke kan slippe afsted med at udnytte bugs i OS.

Jeg ved er er blevet eksperimenteret med en feature til Linux,
hvor en process kan begrænses til et meget lille udvalg af
systemkald. Når først TCP forbindelser er etableret burde
read, write og exit være nok. Og det er ret usandsynligt, at
man kan udnytte kernel exploits vha. kun de tre kald.

I sådan et design ville en kompromiteret proxy være begrænset
til kun at foretage angreb over SMTP forbindelsen videre til
næste server.

Man kunne tage et skridt videre, og lade være med at bruge
en så kompliceret protokol hele vejen. (SMTP burde have
heddet CMTP). Hvis nu proxyen blev delt op i to uafhængige
komponenter, så kunne de kommunikerer med en meget simpel
protokol:
Klient->server: 32 bits længde (MSB er længde af modtager
adressen de resterende 24 bits er længden
af data).
Klient->server: modtageradresse
Klient->server: data
Server->klient: 3 tegns SMTP respons.

Den protokol er så simpel, at det vil være en udfordring at
lave fejl i implementationen. Så kræves det bare, at de to
komponenter holdes adskilt.

--
Kasper Dupont
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Kasper Dupont wrote:
> Hvis man kun opnår kontrol over en enkelt process på proxyen
> så vil man være begrænset til at forsøge på at angribe den
> bagvedliggende mailserver.
>
> Det med at begrænse skaden til en enkelt process kan lade sig
> gøre på nogle OS. Det forudsætter selvfølgelig at angriberen
> ikke kan slippe afsted med at udnytte bugs i OS.

Jeg ville tro, at hvis man virkeligt er interesseret i at sikre sin
mailserver, er man villig til at lære om andre systemer der kan løse ens
opgave.

> Jeg ved er er blevet eksperimenteret med en feature til Linux,
> hvor en process kan begrænses til et meget lille udvalg af
> systemkald. Når først TCP forbindelser er etableret burde
> read, write og exit være nok. Og det er ret usandsynligt, at
> man kan udnytte kernel exploits vha. kun de tre kald.

Systrace?

De fleste daemoner i OpenBSD, og et par userland tools, benytter sig af
privilege seperation nu om dage, således at de komplicerede opgaver sker
i en non-root process der er chrooted til et tomt directory. Der sendes
således simple beskeder frem og tilbage mellem parent og child processer
når det er nødvendigt.

FreeBSDs nye sikkerhedsmodel giver gode muligheder for at give mindst
mulige rettigheder til processer man ikke har grund til at stole på.

Windows har ca. de samme muligheder, men fordi de færrest admins gør
det, er mange services er skrevet så hjernedøde at de alligevel skal
have adgang til alt.

--
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:
>
> således at de komplicerede opgaver sker
> i en non-root process der er chrooted til et tomt directory.

Det er da meget godt. Men det endnu mere effektivt at
begrænse processen til et beskedent udvalg af systemkald.
Det er fuldstændig ligegyldigt, om processen er chrootet
eller ej, hvis den ikke har adgang til et eneste systemkald
som kan tilgå filsystemet gennem andet end allerede åbne
file descriptors.

>
> FreeBSDs nye sikkerhedsmodel giver gode muligheder for at give mindst
> mulige rettigheder til processer man ikke har grund til at stole på.

Hvor meget kan de begrænses? Kan en process faktisk forbydes
adgang til f.eks. open, fork og execve systemkaldene?

>
> Windows har ca. de samme muligheder, men fordi de færrest admins gør
> det, er mange services er skrevet så hjernedøde at de alligevel skal
> have adgang til alt.

Jeg kender ikke Windows godt nok til at udtale mig om,
hvorvidt de begrænsninger jeg nævnte, overhovedet ville give
mening på den platform.

--
Kasper Dupont
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Kasper Dupont wrote:
> Alex Holst wrote:
>
>>således at de komplicerede opgaver sker
>>i en non-root process der er chrooted til et tomt directory.
>
>
> Det er da meget godt. Men det endnu mere effektivt at
> begrænse processen til et beskedent udvalg af systemkald.
> Det er fuldstændig ligegyldigt, om processen er chrootet
> eller ej, hvis den ikke har adgang til et eneste systemkald
> som kan tilgå filsystemet gennem andet end allerede åbne
> file descriptors.

Enig, her kan systrace bruges.

>>FreeBSDs nye sikkerhedsmodel giver gode muligheder for at give mindst
>>mulige rettigheder til processer man ikke har grund til at stole på.
>
>
> Hvor meget kan de begrænses? Kan en process faktisk forbydes
> adgang til f.eks. open, fork og execve systemkaldene?

i systrace kan du begrænse til enkelte system kald og der kan
bygges regulære udtryk til systemkaldets parametre. Fx

native-bind: sockaddr match "inet-*:53" then permit
native-rename: filename match "/slave/*" and filename[1] match
"/slave/*" then permit

se evt.
http://www.onlamp.com/pub/a/bsd/2003/01/30/Big_Scary_Daemons.html

---

"Christian E. Lysel" wrote:
>
> i systrace kan du begrænse til enkelte system kald og der kan
> bygges regulære udtryk til systemkaldets parametre.

Der synes jeg så regulære udtryk lyder som overkill. Og det er
jo en feature, som vil betyde en mere kompliceret implementation
og dermed større risiko for fejl. (Til deres forsvar skal så
selvfølgelig siges, at de regulære udtryk kommer fra en pålidelig
kilde. Men alligevel...)

>
> se evt.
> http://www.onlamp.com/pub/a/bsd/2003/01/30/Big_Scary_Daemons.html

Er der forresten nogen som har nogle forslag til hvordan man
slipper for den slags tåbelige reklamer uden at slå javascript
helt fra?

--
Kasper Dupont
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Kasper Dupont wrote:
> Er der forresten nogen som har nogle forslag til hvordan man
> slipper for den slags tåbelige reklamer uden at slå javascript
> helt fra?

Undskyld, du får istedet den rigtige manual :)

http://www.openbsd.org/cgi-bin/man.cgi?query=systrace

---

"Christian E. Lysel" wrote:
>
> Kasper Dupont wrote:
> > Er der forresten nogen som har nogle forslag til hvordan man
> > slipper for den slags tåbelige reklamer uden at slå javascript
> > helt fra?
>
> Undskyld, du får istedet den rigtige manual :)

Hvis bare man slår javascript fra først, så er det ikke noget
problem at læse siden. Og den giver da en udmærket fornemmelse
for, hvad systrace er for en størrelse.

Jeg synes bare jeg oftere og oftere støder på disse sider,
hvor et eller andet javascript spreder links til irrelevante
reklamer ud over hele teksten. Så jeg begyndte at spekulere
over, hvordan man nemmest slipper for dem.

--
Kasper Dupont
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Kasper Dupont wrote:
> Hvis bare man slår javascript fra først, så er det ikke noget
> problem at læse siden. Og den giver da en udmærket fornemmelse
> for, hvad systrace er for en størrelse.

Engang kunne man holde "shift" eller "alt" eller var det "ctrl" nede
når man besøgte en side, herved blev javascript ikke fortolket...kan
dog ikke få det til at virke.

---

"Christian E. Lysel" wrote:
>
> Kasper Dupont wrote:
> > Hvis bare man slår javascript fra først, så er det ikke noget
> > problem at læse siden. Og den giver da en udmærket fornemmelse
> > for, hvad systrace er for en størrelse.
>
> Engang kunne man holde "shift" eller "alt" eller var det "ctrl" nede
> når man besøgte en side, herved blev javascript ikke fortolket...kan
> dog ikke få det til at virke.

Det virkede heller ikke for mig. Men til gengæld fandt jeg ud
af, at ctrl åbner linket i en ny tab, og det er da også til
tider en praktisk feature. Nu prøver jeg at blokke IP adressen.
Jeg har en mistanke om, at alle disse tossede reklamer kommer
samme sted fra.

Forresten du må hellere lige finde ud af, hvorfor du bliver
ved med at sende dit svar en time før det du svarer på.

--
Kasper Dupont
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

"Christian E. Lysel" wrote:
>
> se evt.
> http://www.onlamp.com/pub/a/bsd/2003/01/30/Big_Scary_Daemons.html

Det lyder som om systrace kan en del af det jeg foreslog. Men
ikke helt. Eksemplet bruger et langt mere kompliceret regelsæt
end jeg ville have gjort. Grunden til de komplicerede regelsæt
er, at processen skal lave noget opsætning før den begynder at
kommunikere med klienter.

Mit forslag var, at begrænsningerne først træder i kraft i det
øjeblik, man begyner at modtage data fra en klient. Dermed kan
man nøjes med nogle meget simplere regler. Og jo simplere
regler, des mindre risiko for fejl.

--
Kasper Dupont
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Kasper Dupont wrote:
> Mit forslag var, at begrænsningerne først træder i kraft i det
> øjeblik, man begyner at modtage data fra en klient. Dermed kan
> man nøjes med nogle meget simplere regler. Og jo simplere
> regler, des mindre risiko for fejl.

Du kan evt. knytte systrace til en kørende process.

---

Kasper Dupont wrote:
> Alex Holst wrote:
>> FreeBSDs nye sikkerhedsmodel giver gode muligheder for at give mindst
>> mulige rettigheder til processer man ikke har grund til at stole på.
>
> Hvor meget kan de begrænses? Kan en process faktisk forbydes
> adgang til f.eks. open, fork og execve systemkaldene?

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html

Hvilken feature på Linux er i øvrigt det du gør brug af? (Du overså vist
mit "Systrace?" spørgsmål tidligere, der skulle tolkes som "Er det
systrace du benytter?")

--
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:
>
> Hvilken feature på Linux er i øvrigt det du gør brug af?

Jeg kan ikke huske hvor jeg læste om den. Den var ikke i
standardkernen på daværende tidspunkt, og det er den muligvis
heller ikke i dag. Jeg er ret sikker på det var noget langt
simplere end systrace.

I min søgen faldt jeg så til gengæld over en side som
fortalte mig, at systrace også er porteret til Linux:
http://www.citi.umich.edu/u/provos/systrace/linux.html

Er der egentlig nogle ligheder mellem systrace og selinux?

--
Kasper Dupont
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Kasper Dupont wrote:
> Er der egentlig nogle ligheder mellem systrace og selinux?

Ikke funktionsmæssigt, men man kan sige at de begge gør det muligt at
sikre integriteten af systemet.

Systrace kan kun tillade eller afvise på funktionsniveau.

SELinux har support for MAC samt mulighed for kun at afvikle programmer
der er korrekt signed, etc. ("SELinux merged with the 2.6 series Linux
Kernel." siger Wikipedia.)


--
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

---

Uffe S. Callesen wrote:

> Nogen der vil dele deres tanker med mig ??

Du giver ikke så meget at arbejde med -- og du griber problemstillingen
forkert an, efter min mening, når du beder om vurdering af produkter i
stedet for løsninger. Men det skal da ikke forhindre mig i at komme med
lidt input.

Sikkerhed handler om simplicitet, mere end avanceret teknologi. Drop
det med L7 proxying, med mindre du har en rigtig god grund til det. Og
med mindre du har en bestemt grund til det, er der typisk ikke meget at
hente ved at bruge en SMTP-proxy fremfor en simpel, dedikeret
mailserver der kan relaye videre til det interne net. Denne beskyttes
typisk lettest og bedst ved et simpelt pakkefilter.

Du snakker om en "større organisation" så jeg vil gå ud fra at
kommunikationsplatformen hedder MS Office med alt hvad dertil hører af
mere eller mindre brugbart programmel, herunder Exchange. At eksponere
Exchange direkte mod nettet er selvfølgelig selvmord -- med mindre man
har imponerende resourcer til rådighed til vedligehold og sikring -- så
helt ind bag firewall'en med den.

Et simpelt in-depth setup kunne se således ud:

[cloud] ---- [firewall] --- [firewall] --- LAN --- [etc]
| | |
| | | ---- [etc]
DMZ | |
| | | ---- [etc]
| | |
[bastion mailserver] ----| | ---- [Exchange server]

Resten er så bare et spørgsmål om at konfigurere firewalls til kun at
tillade kommunikation på de nødvendige porte, til og fra de nødvendige
maskiner. Hvis du alligevel er helt vild med ideen om L7-analyse, kan
du lade den anden firewall i diagrammet rode i pakkerne og sikre at
bastion mailserveren kun snakker SMTP og ikke andet med Exchange
serveren.

At komme en specifik løsning til dig nærmere vil nok kræve noget mere
tid og kendskab til opgaven, men forhåbentlig kan du bruge ovenstående
til lidt inspiration.

--
Niels Callesøe - dk pfy
pfy[at]nntp.dk - http://www.t29.dk/~nica/disclaimer.php

Hint: postfix

---

Niels Callesøe wrote:
> At komme en specifik løsning til dig nærmere vil nok kræve noget mere
> tid og kendskab til opgaven, men forhåbentlig kan du bruge ovenstående
> til lidt inspiration.

Tak for forslagene - jeg vil give jer lidt yderligere info at arbejde
med - mail serveren er en Novell Groupwise (kører pt på netware men vil
senere skulle køre på SLES)

Grunden til at jeg kigger på L7 firewall's er ikke udelukkende pga. af
mailserveren - vi vil gøre flittigt brug at http, WTS og citrix servere
som skal eksponeres mod internettet også.

---

Uffe S. Callesen wrote:
> Grunden til at jeg kigger på L7 firewall's er ikke udelukkende pga. af
> mailserveren - vi vil gøre flittigt brug at http, WTS og citrix servere
> som skal eksponeres mod internettet også.

Jeg kan ikke se hvad det skulle hjælpe i ovenstående.

Simplificere istedet setup'et, og lad vær med at regne simplificitet i
antallet af bokse.

Har du fundet et produkt der specifik håndtere ovenstående?

---

Christian E. Lysel wrote:
> Simplificere istedet setup'et, og lad vær med at regne simplificitet i
> antallet af bokse.

Den tankegang syntes jeg ikke rigtigt holder længere - problemet med
uønskede besøgende fra nettet er ikke at de forsøger at forbigå simple
pakke filtre eller at de ikke overholder de forskellige protokollers RFC's.

Problemet er i mine øjne snarere at en stor del af den trafik som efter
alle standarder er helt legal stadig sagtens kan indeholde exploit kode
- sql injection forsøg osv. Det er alt dette jeg mener man bør sikre sig
imod når man "bygger" perimeter forsvar idag.

> Har du fundet et produkt der specifik håndtere ovenstående?

Øhhh nej så havde jeg ikke startet tråden

--
Mail mig på uffe <elefantnæseA> skelmose <prik> dk

---

Uffe S. Callesen wrote:
> Problemet er i mine øjne snarere at en stor del af den trafik som efter
> alle standarder er helt legal stadig sagtens kan indeholde exploit kode
> - sql injection forsøg osv. Det er alt dette jeg mener man bør sikre sig
> imod når man "bygger" perimeter forsvar idag.

I mange tilfælde er der ikke nogen perimeter længere.

De fleste orme infektioner på virksomhedernes netværk sker ikke udefra,
men fra en orm-inficeret laptop der er slæbt ind på kontoret og koblet
på det (åbne) trådløse net.

Hvis du forsøger at fange sql injection og andre payloads i en proxy har
du tabt på forhånd. Gør applikationerne modstandsdygtige i stedet for at
smide mere tvivlsom kode op foran.

--
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:
> Hvis du forsøger at fange sql injection og andre payloads i en proxy har
> du tabt på forhånd. Gør applikationerne modstandsdygtige i stedet for at
> smide mere tvivlsom kode op foran.

Det er en mægtig god plan når man selv udvikler og drifter
applikationerne... men i alle de andre tilfælde hvor det ikke er
tilfældet..

--
Mail mig på uffe <elefantnæseA> skelmose <prik> dk

---

Uffe S. Callesen wrote:
> Alex Holst wrote:
>> Hvis du forsøger at fange sql injection og andre payloads i en proxy
>> har du tabt på forhånd. Gør applikationerne modstandsdygtige i stedet
>> for at smide mere tvivlsom kode op foran.
>
> Det er en mægtig god plan når man selv udvikler og drifter
> applikationerne... men i alle de andre tilfælde hvor det ikke er
> tilfældet..

Så må man jo købe produkter der kan levere det man har behov for, eller
skrive kontrakter og SLAs omhyggeligt.

Hvis du ikke selv udvikler og drifter jeres applikationer, hvorfor
overlader du så ikke disse tekniske bekymringer til driftsfolkene?


--
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

---

Uffe S. Callesen wrote:
>> har du tabt på forhånd. Gør applikationerne modstandsdygtige i stedet
>> for at smide mere tvivlsom kode op foran.
> Det er en mægtig god plan når man selv udvikler og drifter
> applikationerne... men i alle de andre tilfælde hvor det ikke er
> tilfældet..

Det er ikke svært at gøre applikationer modstandsdygtige også selvom man
ikke selv har udviklet dem.

Kik fx på Check Point Firewall-1. I default installationen har den haft
mange fejl i fx de sidste 5 år, typisk i services man ikke bruger, fx
OpenSSL, H.323, ISAKMP, HTTP, SMTP, VPN FWZ (denne blev derefter i en
service pack pr. default slået fra.

Men var den samme firewall hardnet, fx ved at slå services fra man ikke
benyttede, havde man ikke det samme antal fejl.

---

Alex Holst wrote:
>
> Hvis du forsøger at fange sql injection og andre payloads i en proxy har
> du tabt på forhånd.

Så har debat.computerworld.dk tabt?

--
Kasper Dupont
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Uffe S. Callesen wrote:
> Den tankegang syntes jeg ikke rigtigt holder længere - problemet med
> uønskede besøgende fra nettet er ikke at de forsøger at forbigå simple
> pakke filtre eller at de ikke overholder de forskellige protokollers RFC's.

Simplificitet styre.

Prøv at begræns skaden, hvis angrebet lykkes; segmentering.

Hvem siger fx at en mail server skal stå på det interne segment?

I mit hjemme setup står min mail server på ydersiden af min firewall.
Der er således ingen adgang fra Internet til det interne segment, for
der er ikke brug for det.

Hvis mailserveren skal indeholde følsomme ting giver det måske ikke
mening at placere den på Internet...eller også kan man evt. kryptere
følsomme mails (hvilket generelt er en god idé hvis man tænker de tanker).


Prøv at begræns mulighederne for angrebet lykkes; hardning.

Installere/konfigurer kun det du har behov for.

> Problemet er i mine øjne snarere at en stor del af den trafik som efter
> alle standarder er helt legal stadig sagtens kan indeholde exploit kode
> - sql injection forsøg osv. Det er alt dette jeg mener man bør sikre sig
> imod når man "bygger" perimeter forsvar idag.

Tror du virkelig på at en leverandør tilbyder den form for beskyttelse?

Hvis den oprindelige leverandør af standarden ikke kan finde ud af det,
hvordan skal en firewall leverandør så kunne finde ud af det?

Raptor firewall havde fx en SQLNet proxy...koden den kørte kom fra
Oracle, jeg mener det også var tilfældet med Borderware...hvor langt er
man så nået?

Hvad gør firewall leverandøren når du opgradere din server, eller
klienter, vil det forsat virke?

>> Har du fundet et produkt der specifik håndtere ovenstående?

> Øhhh nej så havde jeg ikke startet tråden

Du kan da godt have fundet et produkt der tillyder proxy/inspection af
http/OWA/citrix/etcetetera, det var jeg blot interesseret i at vide.

---

"Uffe S. Callesen" <anon@anon.local> skrev i en meddelelse
news:43b8fc4f$0$46975$edfadb0f@dread15.news.tele.dk...
> Jeg er pt. igang med at kigge på firewall løsninger til en større
> organisation.
>
> Valget af 'kasse' mellem Internettet og VLAN'et med bla. mail servere
> har fået mig til at tænke over om man bør gå efter en firewall med en
> SMTP proxy eller en firewall med L7 funktionalitet.
>
> Det der taler for førstnævnte er naturligvis at ens mailservere aldig
> bliver direkte eksponeret mod internettet. Istedet er man 100% afhængig
> af sikkerheden i den hærdede SMTP server som firewall'en/proxien benytter.
>
> Det der taler for sidstnævnte er vel primært at man også beskyttes mod
> uheldigt indhold i de enkelte mails - og at der er en væsentligt større
> fleksibilitet omkring hvad man ønsker at tillade og ikke tillade.
>
> Helt konkret kan jeg nævne at de produkter der kigges på er Borderware's
> Steelgate som falder i den første kategori. Sonicwalls Pro 4100 som
> falder i den sidste.
> og Astaro's ASG 220 som kombinerer de to ting (så vidt jeg kan se).
>
> Nogen der vil dele deres tanker med mig ??

Vi modtager x tusinde spammails hver dag. For at undgå at mail-serveren skal
blive overbebyrdet, bruger vi bla. firewallen til at smide det åbenlyse
snask væk, men efter firewallen og foran selve mail-server programmet har vi
så et filter-program, som kun slipper mails igennem til valide modtagere
(Folk eller fælles-adresser, som er eller har været ansatte). I dette
filterprogram er der også et anti-virus filter fra et firma. Ude på
klienterne har vi så et anti-virus program fra en anden udbyder, som vores
primære anti-virus forsvar. Så der er dobbelt anti-virus forsvar og
frasortering af ca. 40 af alle mails inden at de kommer frem til
mail-serveren.

Vi har dog så fået en opgave med at skanne de frasorterede mails igennem, da
der en gang imellem optræder "falske positive" fra marginale
mail-programmer, hvor header osv. ikke overholder internationale standarder.

--

Med venlig hilsen
Carsten Overgaard
http://www.carstenovergaard.dk/undskyld.htm
"Hvis du ikke kan lide indlægget, så er det webmasterens skyld"