sonnenblen.de - Das unabhängige Sun User Forum
Betriebssysteme => Solaris => Thema gestartet von: msueper am 29. Juli 2007, 11:11:14
-
Hallo,
Leider hält der rpcbind einen Port (111) auf dem Netz offen. Mein Rechner ist zwar vernetzt, aber es sind keine weiteren Suns hier. Wie kann ich den Port "schließen"? Am liebsten wäre es mir, der rpcbind würde nur auf localhost horchen. Mir ist klar, dass der rpcbind Service benötigt wird.
$ lsof -i | grep -i listen
rpcbind 211 daemon 6u IPv4 0xd36e3dc0 0t0 TCP *:sunrpc (LISTEN)
smcboot 302 root 4u IPv4 0xd36e3040 0t0 TCP localhost:5987 (LISTEN)
smcboot 302 root 5u IPv4 0xd7e99b80 0t0 TCP localhost:898 (LISTEN)
smcboot 302 root 8u IPv4 0xd7e99280 0t0 TCP localhost:5988 (LISTEN)
smcboot 303 root 4u IPv4 0xd7e99700 0t0 TCP localhost:32771 (LISTEN)
smcboot 307 root 4u IPv4 0xd7e98e00 0t0 TCP localhost:32772 (LISTEN)
sshd 359 root 3u IPv4 0xd7e98980 0t0 TCP *:ssh (LISTEN)
sendmail 371 root 5u IPv4 0xd7e98500 0t0 TCP localhost:smtp (LISTEN)
sendmail 371 root 6u IPv4 0xd7e98080 0t0 TCP localhost:submission (LISTEN)
ttsession 738 internet 5u IPv4 0xd36e4240 0t0 TCP *:32779 (LISTEN)
firefox-b 818 internet 23u IPv4 0xd87b96c0 0t0 TCP localhost:32813 (LISTEN)
gconfd-2 836 internet 13u IPv4 0xd87b84c0 0t0 TCP localhost:32810 (LISTEN)
Gleiches gilt für den Prozess ttsession. Der ist aber weg, sobald ich mich auslogge und läuft zumindest nicht als root.
Zum Einsatz kommt Solaris 10.
Martin
-
Moin,
welche Solaris 10 Version hast du denn (siehe /etc/release)?
Ab Update 3 (das ist 11/06) gibt es dafuer den Befehl "netservices limited" (siehe Manpage falls du diese Version hast). Das schaltet die ganzen Netzwerk-Dienste ab (ausser ssh) bzw. konfiguriert sie so, dass nur localhost drauf zugreifen darf.
Siehe dazu: http://docs.sun.com/app/docs/doc/819-6764/6n8onr7pd?l=en&a=view (http://docs.sun.com/app/docs/doc/819-6764/6n8onr7pd?l=en&a=view)
Alternativ (aber auch erst ab 11/06) kannst du auch die Einstellungen gezielt an rpcbind vornehmen (config/local_only per svccfg setzen). Evtl. geht das auch bei aelteren Solaris 10 Releases mit entsprechenden Patchen.
Wenn das alles unklar ist, dann reich doch bitte mal die Ausgabe dieser beiden Befehle:
# cat /etc/release
# /usr/ccs/bin/what /usr/sbin/rpcbind
Tschau,
Drusus.
-
Hallo,
hier erstmal nähere Infos:
$ cat /etc/release
Solaris 10 11/06 s10x_u3wos_10 X86
Copyright 2006 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 14 November 2006
$ /usr/ccs/bin/what /usr/sbin/rpcbind
/usr/sbin/rpcbind:
pmap_svc.c 1.23 89/04/05 Copyr 1984 Sun Micro
SunOS 5.10 Generic 122661-07 Mar 2007
Die Grund-Installation ist schon älter, beim Upgrade habe ich "netservices limited" ausgeführt.
Danke erstmal, werde mir mal das verlinkte Dok. durchlesen.
Schönen Sonntag!
Martin
-
Hallo,
so, Dinge geprüft. Solaris wähnt den rpcbind im local_only Modus:
# svccfg -s network/rpc/bind listprop
config application
config/allow_indirect boolean true
config/enable_tcpwrappers boolean false
config/verbose_logging boolean false
config/value_authorization astring solaris.smf.value.rpc.bind
config/local_only boolean true
...
Von einem Windows Rechner aus, kann ich aber auf den Port 111 connecten:
$ telnet umbriel.local 111
Trying 192.168.0.23...
Connected to umbriel.local.
Escape character is '^]'.
Gleiches gilt für den ttsession Service. Hier gibt es zudem auch die Gruppe "config" nicht.
Martin
-
Moin,
also mit der Solaris Version sollte das eigentlich genau so gehen. Ist aber aber wohl eher eine Frage der Implementierung... Wenn man in den OpenSolaris Source schaut, so sieht man, dass ein "local_only" nicht dazu fuehrt, dass der listen() sich an localhost bindet sondern dass bei allen Anfragen an den rpcbind geprueft wird ob diese von einem lokalen Ursprung ausgehen.
Ergo wird zwar ein Versuch mit telnet gehen aber ein Versuch mit "rpcinfo -p umbriel.local" sollte zeigen, dass keine Anfragen von Remote beantwortet werden (sprich: der sollte nicht gehen).
Bei dem "ttsession" handelt es sich um keinen SMF Service sondern um ein Session-Service fuer Tooltalk (d.h. du benutzt noch irgenwelche CDE Anwendungen oder aehnliches). Der ttsession Manager wird dann von dem ersten Programm gestartet, dass ToolTalk verwendet. Auch wenn man den Start und die Optionen ueber Environment-Variablen veraendern kann (siehe "man ttsession" und dort z.B. TTSESSION_CMD), so sehe ich keine Moeglichkeit den Dienst auf localhost einzuschraenken. Ich sehe dort nur Moeglichkeiten die verwendete Authentisierung zu aendern und dann z.B. Kerberos zu nutzen.
Tschau,
Drusus.
p.s.: ttsession hat nichts mit dem SMF/inetd Service rpc/cde-ttdbserver zu tun (der wiederum fuer /usr/openwin/bin/rpc.ttdbserverd zustaendig ist).
-
Hallo drusus,
danke für die Erklärungen, jetzt ist mir das schon wesentlich klarer. Ich betrachte die jetzigen Einstellungen dann auch mal als sicher. Der telnet auf Port 111 bringt keine Antwort und wenn man irgendwas eingibt bricht die Verbindung ab.
Nachmals Danke!!
Grüße, Martin
-
Moin,
naja - "sicher" ist relativ ;-)
Der Test mit telnet sagt nichts aus, da du darueber sowieso keine gueltigen RPC Anfragen hinbekommst und die Verbindung immer geschlossen wird (auch wenn remote Anfragen angenommen werden wuerden). Daher mein Vorschlag mittels "rpcinfo -p <hostname>" zu pruefen (oder wie auch immer das Gegenstueck dazu auf Windows heisst). Aber auf jeden Fall ist deine SMF Config korrekt und sollte das wirklich blocken. Ergo ist das Thema meiner Meinung nach vom Tisch.
Bleibt aber noch der "ttsession" Service (zwar nicht von SMF sondern von Applikationen gestartet aber trotzdem noch ein Problem). Der lauscht naemlich sehr wohl noch auf remote Verbindungen und ist ein Sicherheitsrisiko, dass leider nicht so einfach per Config abschaltbar ist (es sei denn man goennt sich noch den ganzen Kerberos-Kram). Da hilft dann nur alle Ports per IP-Filter (oder einem Filter/Firewall deiner Wahl) zu blockieren und nur noch den Traffic durchlassen, den man moechte. IP-Filter ist bei Solaris 10 gleich mit dabei (siehe Manpages zu ipf und ipf.conf).
Tschau,
Drusus.
-
Hallo,
danke für den Tipp. Habe mich immer vor der FW "gefürchtet". War aber gar nicht so schlimm. Für Leser: so geht's =>
-1- vi /etc/ipf/pfil.ap
hier eure Interfaces vom # befreien, die von der FW geschützt werden sollen
-2- /usr/sbin/svcadm restart network/pfil
-3- vi /etc/ipf/ipf.conf
Dies hier eintragen (192.168.0.23 = meine IP und e1000g0 ist das Interface meiner Maschine). Die /16 hinter der IP ist Netzspezifisch. Die 192.168.-Netze haben diesen Wert. Jeder muss natürlich seine Dienste freischalten, z.B. anstelle von Port 22, 23 für Telnet oder 80 für den Apache.
#
# ipf.conf
# Block any packets which are too short to be real
block in log quick all with short
#
# drop and log any IP packets with options set in them.
block in log all with ipopts
#
# Allow all traffic on loopback.
pass in quick on lo0 all
pass out quick on lo0 all
#
# Public Network. Block everything not explicity allowed.
block in on e1000g0 all
block out on e1000g0 all
#
# Allow pings and to be pinged (icmp-type 8 is echo, icmp-type 0 is echo reply)
pass out quick on e1000g0 proto icmp from any to any icmp-type 8 keep state
pass in quick on e1000g0 proto icmp from any to any icmp-type 8 keep state
#
# Allow outbound state related packets. This should be further restricted.
pass out quick on e1000g0 proto tcp/udp from any to any keep state
#
# Allow ssh from any host
pass in quick on e1000g0 proto tcp from any to 192.168.0.23/16 port = 22 keep state
-4- Konfig. laden
ipf -Fa -f /etc/ipf/ipf.conf
-5- Interface durchstarten
ifconfig e1000g0 unplumb
sleep 1
ifconfig e1000g0 plumb 192.168.0.23 netmask 255.255.255.0 up
-6- Regeln prüfen (auslesen):
svcs -vx
(=> hier sollte nichts ausgegeben werden, falls doch läuft der ip-Filer-Dienst nicht, Grund steht hier).
ipfstat -io
Listet die Regeln auf, Regeln mit Syntax-Error fehlen in dieser Liste!
Martin