---

---

Michal Wodzinski wrote:

> Jeg har spekuleret lidt over forskellene mellem netfilter (iptables) og
> ipfilter (ipf).

Netfilter er Linux's firewall-del - ipfilter er *BSD's firewall-del (det er
nu blevet erstattet af pf - som er næsten magen til i brug - i OpenBSD).

> Så vidt jeg har set er selve filtrerings muligheder, NAT, masquerading,
> statefull filtering, og en del andre ting stort set det samme i begge
> filtre.

Ja, ovenstaaende kan baade ipfilter og netfilter.

> Jeg har h°rt folk sige at ipfilter ikke k°rer så godt på linux kernen, men
> er mere velegnet til BSD, og vice versa med netfilter. Kan ipfilter k°re
> på en Linux, og kan netfilter k°re på en BSD?

Netfilter koerer kun paa Linux - ipfilter kun paa BSD (i hvert fald saa vidt
jeg er orienteret).

> Og så har jeg lagt mærke til at der på netfilters hjemmeside er angivet en
> række sikkerhedshuller, hvilke jeg ikke kan finde på nogen side relateret
> med ipfilter. Er ipfilter så sikkert, eller er det just dårligere
> dokumenteret?

Jeg tror ikke, man kan sige at en af dem er daarligere end den anden. De har
forskellig maade at goere de samme ting paa.

> Hvad ved i? Hvad mener i? Er det et præfferencesp°rgsmål eller er der
> noget dybere?

Kan du bedst lide *BSD er ipfilter nok noget for dig - tag netfilter, hvis
du er bedre kendt med Linux. Saa ja, det er formentlig mest et
praefenrencespoergsmaal. Jeg selv foretraekker netfilter - og det kommer af
et stoerre kendskab til Linux og netfilter end *BSD og ipfilter...

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
UNIX is user-friendly;
it's just particular about who it chooses to be friends with!
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

---

Michal Wodzinski wrote:

>> Ja, ovenstaaende kan baade ipfilter og netfilter.
>
> Hmm, kan de to også MLSI (MultiLayer Statefull Inspection... eller var det
> SMLI?) kan hverken finde noget i diverse man pages eller howto's. Eller er
> det kun almindelig statefull filtrering de understøtter? (Og er MLSI
> overhovedet det værd der bliver sagt om det?)

Hmmm... Det aner jeg slet ikke hvad er... Har du en URL el. lign.?

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
If you don't receive an answer, then it either indicates that the bug is
too obvious or too difficult.
-- Manfred Spraul
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

---

Michal Wodzinski wrote:

> On Thu, 12 Sep 2002, Rasmus Bøg Hansen wrote:
>
>> >> Ja, ovenstaaende kan baade ipfilter og netfilter.
>> >
>> > Hmm, kan de to også MLSI (MultiLayer Statefull Inspection... eller var
>> > det SMLI?) kan hverken finde noget i diverse man pages eller howto's.
>> > Eller er det kun almindelig statefull filtrering de understøtter? (Og
>> > er MLSI overhovedet det værd der bliver sagt om det?)

> sslug.dk/linuxbog/sikkerhed/bog/smli.html
>
> der står desværre ikke særlig meget... :/

Nej, ganske rigtigt ikke - jeg proevede google i stedet.

Forstaar jeg resultaterne ret er SMLI connection tracking med
understoettelse af ikke-trivielle protokoller - f. eks. IRC, FTP og H.323
(ip_conntrack_ftp, ip_conntrack_irc og ip_conntrack_h383).

Det lykkedes mig aldrig at faa den slags til at fungere i ipfilter, men
ovenstaaende moduler fungerer fint for mig under netfilter. Netfilter
kender dog ikke til saerlig mange protokoller (ftp og irc - flere som f.
eks. H.323 kan patches ind fra patch-o-matic pakken).

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot.
-- Microsoft help desk
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

---

Michal Wodzinski wrote:

> Connection tracking er noget i retningen af en related state, men blot på
> NAT tabellerne? IRC'en og FTP'en kan jo netop vælges til under NAT conf i
> kernen men ikke under filtering...

Connection tracking er vigtigt for NAT, ja - men det er også vigtigt for
almindelig firewalling, hvis man bruger statefull firewalling.

Connection tracking er på ingen måde begrænset til NAT - det har faktisk sit
eget punkt separat fra iptables...

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
Those who write "Optimized for Netscape" og "Best viewed with MSIE"
never figured out the difference between the WWW and a Word Perfect
4.2 Document.
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

---

Michal Wodzinski wrote:

> ok, så den tillader så state match...

Ja. Således kan du tillade en forbindelse, hvis du allerede har tilladt den
andetsteds - du behøver således ikke lave krumspring for at tillade at svar
kommer tilbage.

> IRC protocol support
> If you are .
> . using NAT, this extension will enable you to send files and initiate
> . chats. Note that you do NOT need this extension to get files or
> . have others initiate chats, or everything else in IRC.
>
> er det så kun i tilfælde af NAT eller også normal statefull filtrering?

Connection trackingen sørger for at det overhoevedet fungerer med NAT. Det
er ikke krævet for ikke-NAT, men gør det *meget* nemmere.

/sbin/iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

tillader DCC-forbindelser. ALternativt skal du åbne for forbindelser på f.
eks. port 8000-8010 i begge retninger og konfigurere din IRC-klient til at
bruge disse porte. Meget besværligere og betyder at 8000-8010 er pivåben
for alle forbindelser.

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
I think the sum of intelligence on the internet is constant.
Only the number of users grows.
- Uwe Ohse in the monastery
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

---

Michal Wodzinski wrote:


> iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Hov, der skulle naturligvis have staaet FORWARD.

> hvis man bruger filter på den klient som bruger DCC?

Saa soerger du for at saette reglen i INPUT og OUTPUT ogsaa.

(der synes ioevrigt at vaere et problem med DCC-conntrack, idet udgaaende
DCC tilsyneladende ikke bliver registreret som EXPECTED)

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
I think the sum of intelligence on the internet is constant.
Only the number of users grows.
- Uwe Ohse in the monastery
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

---

Michal Wodzinski wrote:

> men man behøver ikke have DCC-conntrack hvis man ikke kører NAT, men godt
> vil have DCC til at virke fuldt ud?

Hvis du vil have en fornuftig firewall er du noedt til at bruge
ip_conntrack_irc - ellers er du noedt til at aabne en masse porte.

> Og så et nyt sprøgsmål... jeg har hørt nogle sige det er direkte tåbeligt
> at kompilere netfilter/ipfilter ind i kernen og man burde have dem som
> loadable modules, mens andre siger det er langt bedre at have dem _I_
> kernen... Hvad er hurtigst/mest sikkert/stabilt?

Ja. (= det kan man ikke svare paa).

jeg foretraekker at have dem i kernen - saa er jeg sikker paa at de altid er
tilgaengelige. Andre kan bedre lide at have dem som moduler. Det er vist en
smagssag.

Ved at have dem som moduler bruger man nogle tusindedele sekunder mindre paa
at boote kernen - ved at have dem i kernen sparer man nogle tusindedele
sekunder paa at indlaese modulerne. Jeg er ret sikker paa, at der ikke er
ydelsesforskel paa at have dem som moduler og som ikke-moduler.

I princippet er der lidt stoerre sikkerhed i at have en modulloes kerne, da
en indtraengende forbryder herved ikke kan benytte standardmetoderne til
indlaesning af hans eget modul - men da det kan indlaeses paa andre
maader, saaa.....

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
I'm a unix system administrator
- sending me HTML formatted emails and/or attached Word documents is a
nice way to ensure I won't bother to answer you.
-- Jan Chrillesen
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

---

Michal Wodzinski wrote:

> On Fri, 13 Sep 2002, Rasmus Bøg Hansen wrote:
>
>> > men man behøver ikke have DCC-conntrack hvis man ikke kører NAT, men
>> > godt vil have DCC til at virke fuldt ud?
>>
>> Hvis du vil have en fornuftig firewall er du noedt til at bruge
>> ip_conntrack_irc - ellers er du noedt til at aabne en masse porte.
>
> Også på selve klientsiden?

Ja, hvis denne er firewallet.

> eller er det da nok med ip_conntrack på klienten og så på serveren
> (firewall/router whatever) ip_conntrack samt ip_conntrack_irc (og de andre
> conntrack addons)

Hvis klienten er firewallet, er det noedvendigt (eller i hvert fald
praktisk) at have ip_conntrack_irc. Hvis der staar en firewall mellem denne
og serveren er det noedvendigt paa denne. Er begge firewallet, er det
noedvendigt paa begge.

>> Ved at have dem som moduler bruger man nogle tusindedele sekunder mindre
>> paa at boote kernen - ved at have dem i kernen sparer man nogle
>> tusindedele sekunder paa at indlaese modulerne. Jeg er ret sikker paa, at
>> der ikke er ydelsesforskel paa at have dem som moduler og som
>> ikke-moduler.
>
> Tænkte jeg nok... Det hele bliver jo til en stor klump i hukommelsen til
> sidst?

Ja, hukommelsesforbruget er stort set ens. Der er en smule load/unload kode
ved moduler, som ikke er der, naar man har det i kernen - men det er ret
faa bytes.

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
When you have multiple CPUs with one interrupt controller, you don't
have much choice. You either use spin-locks or you Blue-Screen.
Since Linux doesn't have a "Blue-screen of death", it needs spin-
locks.
-- Richard B. Johnson
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

---

Michal Wodzinski wrote:

>> Ja, hukommelsesforbruget er stort set ens. Der er en smule load/unload
>> kode ved moduler, som ikke er der, naar man har det i kernen - men det er
>> ret faa bytes.
>
> Men den bruges jo kun idet man vælger at loade/unloade et modul.

Naturligvis. Jeg er ikke helt klar over, hvad du prøver at sige med dette?

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
When is it time to reinstall an operation system?
- When booted, the computer prints "Starting Windows..."
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

---

Michal Wodzinski wrote:

> On Mon, 16 Sep 2002, Rasmus Bøg Hansen wrote:
>
>> >> Ja, hukommelsesforbruget er stort set ens. Der er en smule load/unload
>> >> kode ved moduler, som ikke er der, naar man har det i kernen - men det
>> >> er ret faa bytes.
>> >
>> > Men den bruges jo kun idet man vælger at loade/unloade et modul.
>>
>> Naturligvis. Jeg er ikke helt klar over, hvad du prøver at sige med
>> dette?
>
> f.eks. modprobe :)

Ja?

Den bruger da ikke kernehukommelse? Nu har du haegtet mig helt af...

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
When is it time to reinstall an operation system?
- When booted, the computer prints "Starting Windows..."
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

---

Michal Wodzinski wrote:

>> > f.eks. modprobe :)

>> Den bruger da ikke kernehukommelse?

> Nej, netop... Derfor bruges de få bytes load/unload kode kun når man rent
> faktisk loader eller unloader et modul :)

Ahh, paa den maade. Ganske rigtigt bruges modprobe/insmod/rrmod kun ved
indlaesning/fjernelse af modulet, men jeg snakker om den kernehukommelse,
som bruges af den kode, der rent faktisk initialiserer modulet, registrerer
sig i ip_conntrack osv. Der er kode til dynamisk registrering og fjernelse
i modulet - det er der ikke i en statisk udgave. Men det drejer sig om saa
lidt, at det kan vaere lige meget (selve modulet bruger 3808 bytes paa min
maskine).

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
When is it time to reinstall an operation system?
- When booted, the computer prints "Starting Windows..."
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---