---

Jeg kører med Norton Internet security.

Når jeg sende og modtager post, er der lige som et eller andet der liige skal time out, inden der går hul på bylden.
Når jeg kigger i loggen står der:

Date: 27-12-2001 Time: 21:50:31
Unused port blocking has blocked communications. Details:
Inbound TCP connection
Remote address,local service is (mail.midtfyn.net,auth)

Hvordan undgår jeg denne pause, uden at kompromittere sikkerheden. ?
Kan jeg bare åbne for AUTH. Hvilken sikkerhedsrisiko ligger der i det ?
(Jeg har naturligvis samme problem med FTP)

/Karsten

---

Karsten Rasmussen <dk@dk.dk> wrote:
> Jeg kører med Norton Internet security.
>
> Når jeg sende og modtager post, er der lige som et eller andet der liige
> skal time out, inden der går hul på bylden.
> Når jeg kigger i loggen står der:
>
> Date: 27-12-2001 Time: 21:50:31
> Unused port blocking has blocked communications. Details:
> Inbound TCP connection
> Remote address,local service is (mail.midtfyn.net,auth)

Hvis du lader din firewall sende en reset tilbage, i stedet for blot at
droppe pakkerne vil mail serveren tage imod posten med det samme.

> (Jeg har naturligvis samme problem med FTP)

Nej, dit problem med FTP er fordi du bruger aktiv i stedet for passiv FTP.

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

---

> Hvis du lader din firewall sende en reset tilbage, i stedet for blot at
> droppe pakkerne vil mail serveren tage imod posten med det samme.

Hmm.
Efter nærmere undersøgelse, kan jeg se at alle porte der er sat til block automatisk er sat til stealth.
Det er vel normalt meget godt, undtagen i dette tilfælde.

Så vidt jeg kan se er alle uønskede porte som standard sat til block og dermed stealth.
Der er så vidt jeg kan se også mulighed for at sætte dem til ignore, men så vidt jeg kan læse mig til, vil norton så derefter søge
videre for at se om en anden regel evt. passer, hvilket ikke umiddelbart lyder særligt betryggende.

Hvorfor har man ikke muligheden for at lave "stealth" eller "drop" i de enkelte regler.

Er der ikke en eller anden der lige har det gyldne svar, eller skal jeg til at sætte en dedikeret FW op til mit hjemmenetværk. (Jeg
ved godt at det burde jeg eftersom jeg kører mest windåse)

/Karsten

---

Nu bliver det hele lidt mere mystisk (for mig i hvert fald)

Jeg har først lavet en regel der siger at :

permit inbound&outbound TCP AUTH for C:\Programmer\Outlook Express\msimn.exe

Hvis jeg så tester TCP auth (for C:\Programmer\Outlook Express\msimn.exe) får jeg at vide at "network communication is blocked by
the following rule: high securty block"

permit inbound&outbound TCP AUTH for all programs

Så drøner det bare deruda'

(Har også prøvet både at tillade TCP og UDP med samme resultat)

/Karsten

---

Hej Karsten !

AUTH har ikke noget med Outlook express at gøre. Hvis du ønsker at din
maskine skal svare på en AUTH forespørgsel skal du installere en
IDENT-klient, som også findes til Windows.

/Peter



"Karsten Rasmussen" <dk@dk.dk> wrote in message
news:a0gj6g$mnc$1@sunsite.dk...
> Nu bliver det hele lidt mere mystisk (for mig i hvert fald)
>
> Jeg har først lavet en regel der siger at :
>
> permit inbound&outbound TCP AUTH for C:\Programmer\Outlook
Express\msimn.exe
>
> Hvis jeg så tester TCP auth (for C:\Programmer\Outlook Express\msimn.exe)
får jeg at vide at "network communication is blocked by
> the following rule: high securty block"
>
> permit inbound&outbound TCP AUTH for all programs
>
> Så drøner det bare deruda'
>
> (Har også prøvet både at tillade TCP og UDP med samme resultat)
>
> /Karsten
>

---

peter wrote:

> AUTH har ikke noget med Outlook express at gøre. Hvis du ønsker at din
> maskine skal svare på en AUTH forespørgsel skal du installere en
> IDENT-klient, som også findes til Windows.


Men hvis mailserveren bruger AUTH, og klient maskinen kører stealth, kan
det godt gå laaang tid før man kan oprette en pop3/imap session til
serveren.

Derfor skal en evt. firewall sættes op til at sende en besked til
serveren om at servicen ikke tilbydes.

---

Helt enige, men så vidt jeg kan se af Karstens mail, har han givet
tilladelse til AUTH indgående, men samtidig knyttet det sammen med MS
Outlook express hvilket aldrig vil virke, idet OE ikke kan håndtere AUTH.

Jeg har selv haft en del problemer med nedenstående, idet jeg ikke kunne få
min firewall til at sende en RST. Derfor skulle jeg hele tiden vente på at
timeren løb ud.

Det endte med at jeg måtte installere en IDENT-klien, men det løste så også
problemet omgående.

Mvh.

Peter


"Christian E. Lysel" <chlyshoswmdatapunktumcom@example.net> wrote in message
news:3C2CDBA7.5040403@example.net...
> peter wrote:
>
> > AUTH har ikke noget med Outlook express at gøre. Hvis du ønsker at din
> > maskine skal svare på en AUTH forespørgsel skal du installere en
> > IDENT-klient, som også findes til Windows.
>
>
> Men hvis mailserveren bruger AUTH, og klient maskinen kører stealth, kan
> det godt gå laaang tid før man kan oprette en pop3/imap session til
> serveren.
>
> Derfor skal en evt. firewall sættes op til at sende en besked til
> serveren om at servicen ikke tilbydes.
>
>
>

---

peter wrote:

> Helt enige, men så vidt jeg kan se af Karstens mail, har han givet
> tilladelse til AUTH indgående, men samtidig knyttet det sammen med MS
> Outlook express hvilket aldrig vil virke, idet OE ikke kan håndtere AUTH.


Ok.


> Jeg har selv haft en del problemer med nedenstående, idet jeg ikke kunne få
> min firewall til at sende en RST. Derfor skulle jeg hele tiden vente på at
> timeren løb ud.


Er det så ikke nemmest at ikke at knytte indgående AUTH til outlook, men
blot tillade det generelt. TCP/IP stakken vil selv sørge for at fortælle
mailserveren at servicen ikke tilbydes.


> Det endte med at jeg måtte installere en IDENT-klien, men det løste så også
> problemet omgående.


Men har du ikke blot installeret endnu en service, som måske er sårbar?

---

>
> > Jeg har selv haft en del problemer med nedenstående, idet jeg ikke kunne
få
> > min firewall til at sende en RST. Derfor skulle jeg hele tiden vente på
at
> > timeren løb ud.
>
>
> Er det så ikke nemmest at ikke at knytte indgående AUTH til outlook, men
> blot tillade det generelt. TCP/IP stakken vil selv sørge for at fortælle
> mailserveren at servicen ikke tilbydes.

Jo - men af en eller anden årsag kunne jeg ikke få den RST tilbage til
mailserveren. Jeg havde en sniffer på, men uanset hvad jeg gjorde (sikkert
også en del forkert ) så kunne jeg ikke få den afsted.

>
>
> > Det endte med at jeg måtte installere en IDENT-klien, men det løste så
også
> > problemet omgående.
>
>
> Men har du ikke blot installeret endnu en service, som måske er sårbar?
>
Jo - desværre, men da jeg i forvejen sidder bag en firewall er risikoen nok
begrænset


/Peter

---

peter wrote:

>> Men har du ikke blot installeret endnu en service, som måske er sårbar?

>Jo - desværre, men da jeg i forvejen sidder bag en firewall er risikoen nok
>begrænset

Her må jeg lige bryde ind...

Har du ikke netop åbnet op i firewallen for den, måske, usikre service?
Så hjælper din fine firewall intet, hvis Hans Hakker[1] kan downloade dine
kærestebreve til Moster Oda via auth-serveren.

[1] I mine glade supporter-dage ved en Større Dansk Internetudbyder(tm),
fik jeg en kunde i røret der meddelte at han blev hakket(sic) af vores
DNS-server.

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

---

peter wrote:

>>Men har du ikke blot installeret endnu en service, som måske er sårbar?
> Jo - desværre, men da jeg i forvejen sidder bag en firewall er risikoen nok
> begrænset


Kan du så ikke få denne firewall til at fortælle mailserveren at auth
ikke tilbydes?

---

Jeg bruger Tiny personal firewall og så vidt jeg kan se er der ingen steder
hvor man kan sætte den op til hvordan den skal afvise en pakke som der ikke
er en indgående regel for. Firewall´en kører som standard som stealth og vil
vist ikke andet.

Mht. den anden firewall som jeg sidder bag, så er det pga. nettets opbygning
ikke muligt at afvise AUTH der.

Jeg er fuldt ud med på at AUTH kan være usikker, men reglen i den personlige
firewall er begrænset til at det kun er mailserveren som må få en AUTH
forespørgelse igennem. En risiko - jeps - men vurderet til at være minimal.

/P


"Christian E. Lysel" <chlyshoswmdatapunktumcom@example.net> wrote in message
news:3C2CFC94.3040103@example.net...
> peter wrote:
>
> >>Men har du ikke blot installeret endnu en service, som måske er sårbar?
> > Jo - desværre, men da jeg i forvejen sidder bag en firewall er risikoen
nok
> > begrænset
>
>
> Kan du så ikke få denne firewall til at fortælle mailserveren at auth
> ikke tilbydes?
>

---

> Jeg er fuldt ud med på at AUTH kan være usikker, men reglen i den personlige
> firewall er begrænset til at det kun er mailserveren som må få en AUTH
> forespørgelse igennem. En risiko - jeps - men vurderet til at være minimal.
>
Det er jo netop det jeg prøver på, men som jeg ikke kan få til at virke med norton.
Hvis nu jeg kunne få den til at lave stealth, som nu, undtagen når min mailserver spørger, så skal den bare fortælle den er blokket.

Men jeg kan forstå, at det var bedre at eleminere AUTH fra mailserveren, måske skulle jeg arbejde på det i stedet.
Det er en RH7.2 maskine med sendmail.

/Karsten

---

Hej Karsten !

Hvis det lykkes dig vil jeg meget gerne høre om det.

Det var der jeg startede i sin tid, men efter at have søgt i alskens
dokumentation og forespurgt i div. nyhedsgrupper opgav jeg at få sendmail
til at droppe sin AUTH forespørgsel.

Mvh.

Peter



"Karsten Rasmussen" <dk@dk.dk> wrote in message
news:a0j6mj$85c$1@sunsite.dk...
> > Jeg er fuldt ud med på at AUTH kan være usikker, men reglen i den
personlige
> > firewall er begrænset til at det kun er mailserveren som må få en AUTH
> > forespørgelse igennem. En risiko - jeps - men vurderet til at være
minimal.
> >
> Det er jo netop det jeg prøver på, men som jeg ikke kan få til at virke
med norton.
> Hvis nu jeg kunne få den til at lave stealth, som nu, undtagen når min
mailserver spørger, så skal den bare fortælle den er blokket.
>
> Men jeg kan forstå, at det var bedre at eleminere AUTH fra mailserveren,
måske skulle jeg arbejde på det i stedet.
> Det er en RH7.2 maskine med sendmail.
>
> /Karsten
>

---

peter wrote:

> Hej Karsten !
>
> Hvis det lykkes dig vil jeg meget gerne høre om det.
>
> Det var der jeg startede i sin tid, men efter at have søgt i alskens
> dokumentation og forespurgt i div. nyhedsgrupper opgav jeg at få sendmail
> til at droppe sin AUTH forespørgsel.


Den dovne løsning er at bruge iptables på mailserveren. :)

Men noget helt andet, min sendmail bruger ikke auth, jeg kører redhat 7.1.

En netstat på mit system giver følgende:

# netstat -nap|grep LISTEN|grep :25
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 683/sendmail: accep

Hvad giver det på dit?


Jeg vil blot se hvem der "ejer" listneren på port 25, måske sidder din
sendmail i inet, som laver auth opslaget.

---

> Den dovne løsning er at bruge iptables på mailserveren. :)
>
> Men noget helt andet, min sendmail bruger ikke auth, jeg kører redhat 7.1.
>
> En netstat på mit system giver følgende:
>
> # netstat -nap|grep LISTEN|grep :25
> tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 683/sendmail: accep
>
> Hvad giver det på dit?
>
>
> Jeg vil blot se hvem der "ejer" listneren på port 25, måske sidder din
> sendmail i inet, som laver auth opslaget.
>
>
Min giver:

tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 12038/sendmail: acc

/Karsten

---

Min giver:

tcp 0 0 10.0.0.2:25 0.0.0.0:* LISTEN
719/sendmail: accep


Mvh.

Peter


"Christian E. Lysel" <chlyshoswmdatapunktumcom@example.net> wrote in message
news:3C2DB32A.7090900@example.net...
> peter wrote:
>
> > Hej Karsten !
> >
> > Hvis det lykkes dig vil jeg meget gerne høre om det.
> >
> > Det var der jeg startede i sin tid, men efter at have søgt i alskens
> > dokumentation og forespurgt i div. nyhedsgrupper opgav jeg at få
sendmail
> > til at droppe sin AUTH forespørgsel.
>
>
> Den dovne løsning er at bruge iptables på mailserveren. :)
>
> Men noget helt andet, min sendmail bruger ikke auth, jeg kører redhat 7.1.
>
> En netstat på mit system giver følgende:
>
> # netstat -nap|grep LISTEN|grep :25
> tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 683/sendmail: accep
>
> Hvad giver det på dit?
>
>
> Jeg vil blot se hvem der "ejer" listneren på port 25, måske sidder din
> sendmail i inet, som laver auth opslaget.
>
>

---

"Christian E. Lysel" <chlyshoswmdatapunktumcom@example.net> wrote:

>Den dovne løsning er at bruge iptables på mailserveren. :)

Er det? Jeg har netop undret mig over, at iptables tilsyneladende ikke
skelner mellem DENY og REJECT, som ipchains gjorde. Uddrag fra 'man
iptables':
>TARGETS
> A firewall rule specifies criteria for a packet, and a target. If the packet does
> not match, the next rule in the chain is the examined; if it does match, then the
> next rule is specified by the value of the target, which can be the name of a user-
> defined chain or one of the special values ACCEPT, DROP, QUEUE, or RETURN.
>
> ACCEPT means to let the packet through. DROP means to drop the packet on the
> floor. QUEUE means to pass the packet to userspace (if supported by the kernel).
> RETURN means stop traversing this chain and resume at the next rule in the previous
> (calling) chain. If the end of a built-in chain is reached or a rule in a built-in
> chain with target RETURN is matched, the target specified by the chain policy
> determines the fate of the packet.

Det er fra version 1.2.1a. Det er ved at være et stykke tid siden, jeg
har checket for opdateringer, så der kan selvfølgelig være sket nyt.

[..]
>Jeg vil blot se hvem der "ejer" listneren på port 25, måske sidder din
>sendmail i inet, som laver auth opslaget.

Sendmail kan i hvert fald også sagtens finde på at gøre det selv. Der
er et eller andet sted i sendmail.cf, hvor du særskilt kan stille
timeout-værdien for auth-opslag.


--
Allan Olesen, Lunderskov.
Danske musikere tjener penge ved ulovlig softwarekopiering.

---

Allan Olesen wrote:
>
> "Christian E. Lysel" <chlyshoswmdatapunktumcom@example.net> wrote:
>
> >Den dovne løsning er at bruge iptables på mailserveren. :)
>
> Er det? Jeg har netop undret mig over, at iptables tilsyneladende ikke
> skelner mellem DENY og REJECT, som ipchains gjorde.

Det target der i ipchains hed DENY hedder i iptables DROP,
hvilket beskriver lidt bedre, hvad den egentlig gør.

Det indbyggede target REJECT findes ikke mere i iptables,
tilgengæld findes der et modul til iptables, der implementerer
REJECT, og du kan så vidt jeg erindrer selv vælge, hvilken
ICMP fejl der skal returneres.

I min iptables firewall har jeg f.eks. disse tre regler:
-A INPUT -p udp -m udp --sport 1024:65535 --dport 1024:65535 \
-j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -d 192.168.0.0/255.255.0.0 -m owner ! --uid-owner \
root -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -p tcp -j REJECT --reject-with icmp-port-unreachable

--
Kasper Dupont

Notice: By sending SPAM (UCE/BCE) to this address, you are
accepting and agreeing to our charging a $1000 fee, per
email, for handling and processing, and you agree to pay any
and all costs for collecting this fee.

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:

>Det target der i ipchains hed DENY hedder i iptables DROP,
>hvilket beskriver lidt bedre, hvad den egentlig gør.

Ja, det er jeg klar over.

>Det indbyggede target REJECT findes ikke mere i iptables,
>tilgengæld findes der et modul til iptables, der implementerer
>REJECT, og du kan så vidt jeg erindrer selv vælge, hvilken
>ICMP fejl der skal returneres.

Ok. Takker.


--
Allan Olesen, Lunderskov.
Danske musikere tjener penge ved ulovlig softwarekopiering.

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:

>Det indbyggede target REJECT findes ikke mere i iptables,
>tilgengæld findes der et modul til iptables, der implementerer
>REJECT, og du kan så vidt jeg erindrer selv vælge, hvilken
>ICMP fejl der skal returneres.

Nemlig, og ikke alene ICMP; den variant der er velegnet til at
kvæle auth er:

iptables ... -j REJECT --reject-with tcp-reset

Den sender en TCP "Connection Reset" som til forveksling ligner
den reaktion man får hvis porten er åben, men der ikke er en
lyttende proces. Jeg har været ude for smtp-servere som blev
kede af at få en icmp-port-unreachable, men tcp-reset virker
fortræffeligt.

--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

> > Hej Karsten !
> >
> > Hvis det lykkes dig vil jeg meget gerne høre om det.
> >
> > Det var der jeg startede i sin tid, men efter at have søgt i alskens
> > dokumentation og forespurgt i div. nyhedsgrupper opgav jeg at få sendmail
> > til at droppe sin AUTH forespørgsel.
Jeg har prøvet hvad der står i
http://www.sendmail.org/faq/section3.html#3.12
Men det hjælper tilsyneladende ike !

/Karsten

---

Det var desværre også det jeg i sin tid konstaterede.

/Peter

"Karsten Rasmussen" <dk@dk.dk> wrote in message
news:a0ml00$bpr$1@sunsite.dk...
> > > Hej Karsten !
> > >
> > > Hvis det lykkes dig vil jeg meget gerne høre om det.
> > >
> > > Det var der jeg startede i sin tid, men efter at have søgt i alskens
> > > dokumentation og forespurgt i div. nyhedsgrupper opgav jeg at få
sendmail
> > > til at droppe sin AUTH forespørgsel.
> Jeg har prøvet hvad der står i
> http://www.sendmail.org/faq/section3.html#3.12
> Men det hjælper tilsyneladende ike !
>
> /Karsten
>

---

Karsten Rasmussen wrote:

> Jeg har prøvet hvad der står i
> http://www.sendmail.org/faq/section3.html#3.12
> Men det hjælper tilsyneladende ike !


Interessant.

Hvis jeg læse min sendmail.cf fil, finder jeg følgende:

#O Timeout.ident=5s


Prøv at ret det til

O Timeout.ident=0s

---

> Interessant.
>
> Hvis jeg læse min sendmail.cf fil, finder jeg følgende:
>
> #O Timeout.ident=5s
>
>
> Prøv at ret det til
>
> O Timeout.ident=0s

Det er jo netop det der står i min.
---------------

Kigger man lidt længere ned i filen ser man:

# is user trusted to authenticate as someone else?
Strust_auth
R$* $: $&{auth_type} $| $1
# required by RFC 2554 section 4.
R$@ $| $* $#error $@ 5.7.1 $: "550 not authenticated"
R$* $| $&{auth_authen} $@ identical
R$* $| <$&{auth_authen}> $@ identical
R$* $| $* $: $1 $| $>"Local_trust_auth" $1
R$* $| $#$* $#$2
R$* $#error $@ 5.7.1 $: "550 " $&{auth_authen} " not allowed to act as " $&{auth_author}

SLocal_trust_auth

------
Måske har det nogt med sagen at gøre.