[Eisfair] Eis und IPv6 NICHT!

[Kay Martinen]

Am 22.11.20 um 14:31 schrieb Juergen Edner:
> Hallo Kay,
> 
>>> tcp6       0      0 :::25             :::*                LISTEN
>>> tcp6       0      0 :::587            :::*                LISTEN
>>> tcp6       0      0 :::143            :::*                LISTEN
>>> tcp6       0      0 :::465            :::*                LISTEN
> 
> die Listener der aufgeführten Ports werden vom mail-Paket geöffnet.
> Mit meiner Skriptänderung sollten diese bei deaktivierten IPv5-
> Schnittstellen nicht mehr gestartet werden.
> 
>>> tcp6       0      0 :::19                   :::*                   
>>> LISTEN
>>> tcp6       0      0 :::37                   :::*                   
>>> LISTEN
>>> tcp6       0      0 :::7                    :::*                   
>>> LISTEN
>>> tcp6       0      0 :::9                    :::*                   
>>> LISTEN
>>> tcp6       0      0 :::13                   :::*                   
>>> LISTEN
>>> udp6       0      0 :::7                    :::*
>>> udp6       0      0 :::9                    :::*
>>> udp6       0      0 :::13                   :::*
>>> udp6       0      0 :::19                   :::*
>>> udp6       0      0 :::37                   :::*
> 
> Bei den aufgeführten Parts bin ich mir nicht ganz sicher durch welche
> Programme diese geöffnet werden. 

Diese Niedrigen Portnummern sind gewiss xinetd eigene Dienste wie
chargen, daytime u.s.w.


> Führe doch bitte einmal folgenden
> Befehl aus:
> 
> # netstat -alp | grep -E "udp6|tcp6"

> base     : 2.8.25
> eiskernel: 4.9.220-eisfair-64-VIRT
> 
> eismail # netstat -alp | grep -E "udp6|tcp6"
> tcp6       0      0 [::]:chargen            [::]:*                  LISTEN      2120/xinetd         
> tcp6       0      0 [::]:smtp               [::]:*                  LISTEN      2279/exim           
> tcp6       0      0 [::]:time               [::]:*                  LISTEN      2120/xinetd         
> tcp6       0      0 [::]:echo               [::]:*                  LISTEN      2120/xinetd         
> tcp6       0      0 [::]:discard            [::]:*                  LISTEN      2120/xinetd         
> tcp6       0      0 [::]:submission         [::]:*                  LISTEN      2279/exim           
> tcp6       0      0 [::]:daytime            [::]:*                  LISTEN      2120/xinetd         
> tcp6       0      0 [::]:imap4              [::]:*                  LISTEN      2328/dovecot        
> tcp6       0      0 [::]:smtps              [::]:*                  LISTEN      2279/exim           
> udp6       0      0 [::]:echo               [::]:*                              2120/xinetd         
> udp6       0      0 [::]:discard            [::]:*                              2120/xinetd         
> udp6       0      0 [::]:daytime            [::]:*                              2120/xinetd         
> udp6       0      0 [::]:chargen            [::]:*                              2120/xinetd         
> udp6       0      0 [::]:time               [::]:*                              2120/xinetd         
> eismail # 

Ich sag's ja. Viel davon ist xinetd. Ich hab die VM noch nicht wieder
neu gebootet. Das hätte im übrigen auch ein

> eismail # netstat -ltu
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address           Foreign Address         State      
> ...
> tcp6       0      0 [::]:chargen            [::]:*                  LISTEN     
> tcp6       0      0 [::]:smtp               [::]:*                  LISTEN     
> tcp6       0      0 [::]:time               [::]:*                  LISTEN     
> tcp6       0      0 [::]:echo               [::]:*                  LISTEN     
> tcp6       0      0 [::]:discard            [::]:*                  LISTEN     
> tcp6       0      0 [::]:submission         [::]:*                  LISTEN     
> tcp6       0      0 [::]:daytime            [::]:*                  LISTEN     
> tcp6       0      0 [::]:imap4              [::]:*                  LISTEN     
> tcp6       0      0 [::]:smtps              [::]:*                  LISTEN     
> udp6       0      0 [::]:echo               [::]:*                             
> udp6       0      0 [::]:discard            [::]:*                             
> udp6       0      0 [::]:daytime            [::]:*                             
> udp6       0      0 [::]:chargen            [::]:*                             
> udp6       0      0 [::]:time               [::]:* 

gezeigt.

>> Gibt es auch eine Möglichkeit Mail nur auf bestimmte Adressen lauschen
>> zu lassen - i.s.v. Interface-auswahl?
> 
> Nein, dies ist bis dato nicht vorgesehen, da ein Heimserver
> üblicherweise nicht sehr viele Interfaces besitzt, dass ich
> hier eine weitere Einschränkung für nötig erachtet habe.

Hmm, okay. Mit dem Bond und Bridge tool hat man nat. auch 2 Interfaces
die aber zusammengefaßt werden zu einem - wobei <Paket> dann entweder
auf dem bridge-device oder dem bond aufsetzen müßte. Hab ich noch nicht
probiert mangels bedarf und kann nicht sagen ob das läuft. Doch nun gibt
es auch ein vlan-paket das zusätzliche interfaces einrichten kann - auf
der gleichen HW. Von der immer vorhanden gewesenen Möglichkeit eine 2.
NIC dazu zu Klicken/stecken ganz abgesehen. :)

Ich weiß, das macht das Setup sicher schwieriger. Ein Heimserver der
z.b. maildienste nur für das eigene LAN anbieten soll, filedienste aber
z.b. auch für ein Gäste-VLAN oder für den befreundeten Nachbarn (evtl.
RO) Freigegeben wäre scheint mir nicht so weit her geholt vom üblichen
use-case. Was unterschiedliche Autorisierung, Zugang oder Privilegierung
je nach Interface erfordern würde. Vielleicht sollte man mal Umfragen ob
das jemand so nutzt, nutzen wollte oder mit eigenen/anderen "Hacks" umsetzt?

Bei Samba z.b. gibt es m.W. nur trusted_Nets und keine Unterscheidung
bei den Shares nach Interface. Es tauchen alle an allen NICs auf.

Bleiben derzeit nur iptables-regeln die den Zugang blockierten wo er
nicht sein soll. Was bezgl. der Sicherheit eher einem Stopfen in einem
löchernen Faß gleichkommt. :-)

Kay

-- 
Posted via leafnode