Newsgroup: it.comp.os.linux.iniziare
Titolo: Aprire la porta 23 telnet

Ciao a tutti,
ho installato ed avviato il servizio telnet su linux redhat 9.
Ho provato a collegarmi sia da linux sia da windows con telnet, ma non mi si
connette, con ssh sì.
Ho scoperto che la porta 23 è chiusa. Come fare ad aprirla? (nel file di
conf /etc/services il servizio è già associato alla porta.
Grazie

In data Wed, 10 Sep 2003 12:53:53 +0200, Perseo scrive:

se usi inetd basta decommentare la riga relativa al telnet in inetd.conf:
#telnet stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd
se usi xinetd non saprei....google rulez
ciao
-- 
Marco Mampreso - Linux User # 296644
Slackware 9.0 - Kernel 2.4.20

 conf /etc/services il servizio è già associato alla porta.
vi /etc/xinetd.d/telnet
disable = no  <<==
/etc/rc.d/init.d/xinetd restart
vi /etc/hosts.deny
ALL: ALL
vi /etc/hosts.allow
in.telnetd: LOCAL 192.168.0.     # fa accedere tutta la lan 192.168.0.x
bye G.L.
--
« E' assolutamente evidente che l'arte del cinema
 si ispira alla vita, mentre la vita si ispira alla TV »
(Woody Allen)

Perseo wrote:

Se non hai configurato iptable o ipchains per chiudere la porta 23, sei
sicuro di aver avviato il demone in.telnetd ?
-- 
Ciao,
        Fabrizio
<=- 
http://www.negusweb.it
 -=>

 ha scritto nel messaggio
news:ah1njb...@192.168.1.1...

E' tutto avviato, e nel file di conf di telnet, disable = no.
Non so dove mettere le mani.

 Non so dove mettere le mani.
netstat -n | grep 23    ?
iptables-save | grep 23    ?


 iptables-save | grep 23    ?
Intanto... cosa significa?
Secondo... ho provato e non funziona.

> > Non so dove mettere le mani.
Non e' che stai provando ad accedere come root?  L'accesso via telnet
a root e' disabilitato di default.  Prova ad accedere come utente
comune.
-- 
Sono un servitore del Fuoco Segreto, e reggo la fiamma di Anor.
A nulla ti servira' il fuoco oscuro, fiamma di Udun.
Torna nell'Ombra! Non puoi passare.

 Secondo... ho provato e non funziona.
Su, su... sii un po' piu' preciso. ;-)
Ho fatto un errore, bisogna dare "netstat -na | grep 23"
Comunque, se la porta 23 e' in ascolto, "netstat -na | grep 23 ti restituisce
almeno una riga. Se questa riga e' del tipo:
tcp        0      0 
0.0.0.0:23
              0.0.0.0:*               LISTEN
Allora telnet e' in ascolto.
La successiva serve (ma potrebbe non essere per nulla indicativa, dipende da
come e' stato strutturato il firewall) perlomeno a dare un indizio di
"filtratura" da parte di netfilter.


 comune.
La porta 23 è chiusa. Lo vedo con uno scanner di porte. Non mi chiede
neanche la password, mi dice che non accedo e basta.

 Ho fatto un errore, bisogna dare "netstat -na | grep 23"
Non ottengo nessuna riga, mentre mettendoci la porta 25 (smtp) me lo
segnala. La porta 23 è chiusa.
C.O.M.E.  F.A.C.C.I.O. .A.D. .A.P.R.I.R.L.A?  :-))
Ciao

 C.O.M.E.  F.A.C.C.I.O. .A.D. .A.P.R.I.R.L.A?  :-))
Una porta non si apre manualmente, deve esserci un programma che
ascolta su quella porta, in questo caso il telnet server che, nel tuo
caso, per un motivo o per l'altro non e' partito.
ma inetd/xinetd e' in esecuzione?  ps aux | grep inetd


 C.O.M.E.  F.A.C.C.I.O. .A.D. .A.P.R.I.R.L.A?  :-))
aprire porta = far partire opportuno servizio -> demone telnet
quindi:
telnet (server) e` installato?
Che dicono i log di (x)inetd?
-- 
 Francesco Romani - Ikitt  | Describe your vision, the meaning is missing |
*** mailserver: 
freemail.it
| Won't anybody listen?                        |
   >>> La questione brevetti software: 
http://www.softwarelibero.org
 <<<

Perseo wrote:

H.A.I.  L.E.T.T.O  I.L  M.I.O  P.O.S.T., in questo stesso thread, in cui
ti dico come fare? Non hai neanche risposto, a quell'articolo...
Dapprima, verifica con "ps -ef | grep xinetd" se xinetd e' avviato.


 caso, per un motivo o per l'altro non e' partito.
Telnet e xinetd sono in esecuzione, ma la porta non è aperta. Non so cosa
dire. Anche a me sembra strano. Nel file services il servizio telnet è
associato correttamente alla porta 23.

 Dapprima, verifica con "ps -ef | grep xinetd" se xinetd e' avviato.
I servizi sono avviati. I file hosts.allow e hosts.deny sono vuoti, ho
provato a modificarli come dici tu ma niente, del resto la porta 23 è chiusa
comunque.
La voce "disable" di telnet é "no", ovviamente.

 La voce "disable" di telnet é "no", ovviamente.
Beh... per non mettere troppa carne al fuoco, per il momento metti ALL: ALL in
entrambe i files /etc/hosts.deny e hosts.allow: anche se il problema e' a monte,
potrebbero dare problemi dopo.
Se digiti "in.telnetd" (o altrimenti quello che richiama in
/etc/xinetd.d/telnet), che da?


 I servizi sono avviati.
Cerca di postare un po' di "output" di quello che stai facendo, e quello che la
macchina ti ritorna: si puo' arrivare piu' rapidamente ad una soluzione...  (e
magari poi scoprire che ci si perde in un bicchier d'acqua)


 /etc/xinetd.d/telnet), che da?
La risposta é:
/usr/sbin/in.telnetd: getpeername: Socket operation on non-socket
Allora, allora, aspetta.
Vorrei tralasciare un attimo il discorso telnet.
Per proteggere la rete ci sono sia i files hosts.deny e hosts.allow, sia la
configurazione della iptables e ipchain (quest'ultima non so ancora come si
gestisca).
Lo script che ho trovato lavora solo invocando la iptables e non tocca i
file hosts. Ovvio che se sul .deny impongo ALL:ALL, non passa piů nessuno.
Il mio problema adesso č capire come gestire queste configurazioni, cioč i
file hosts e lo script di impostazione del firewall.
Quello che ho trovato č questo: firewall.sh
----------------------------------------------------------------------------
--------
#!/bin/sh
#
# firewall.sh - Version 20020319 - Coresis
#
# Used random IPs
#
### DEBUGGING ###
set -x
### FLUSHING CHAIN ###
/sbin/iptables -F
/sbin/iptables -X
/sbin/iptables -Z
### DEFAULT CHAIN ###
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT DROP
### SETTING IPFORWARDING ###
/bin/echo "1" > /proc/sys/net/ipv4/ip_forward
### DISABLE RESPOND TO BROADCAST ###
/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
### ENABLE BAD ERROR MESSAGE PROTECTION ###
/bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
### DISABLE ICMP REDIRECT ACCEPTANCE ###
/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
### SETTING ANTISPOOFING PROTECTION ###
/bin/echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
### DON'T RESPOND TO BROADCAST PINGS ###
/bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
##################################################################
#GW1 AND GW2 ARE TRUSTED HOSTS FROM WHICH SSH COMMUNICATION IS PERMITTED
GW1=10.10.10.4
GW2=192.168.1.5
#LINEA1 AND LINEA2 ARE TRUSTED NETWORKS FROM WHICH ICMPS ARE ALLOWED
LINEA1=
10.10.10.0/24
LINEA2=
192.168.1.0/24
# NTP_SRV IS A NETWORK TIME PROTOCOL SERVER
NTP_SRV=10.198.151.1
##################################################################
# ======================= LOCALHOST ================================
/sbin/iptables -A INPUT -s 127.0.0.1 -j ACCEPT
/sbin/iptables -A OUTPUT -s 127.0.0.1 -j ACCEPT
# ======================= SSH RULE ================================
/sbin/iptables -A INPUT -i eth0 -p TCP --dport 22  -s $GW1 -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p TCP --dport 22  -s $GW2 -j ACCEPT
/sbin/iptables -A OUTPUT -o eth0 -p TCP --sport 22  -d $GW1 -j ACCEPT
/sbin/iptables -A OUTPUT -o eth0 -p TCP --sport 22  -d $GW2 -j ACCEPT
# ======================= DNS RULE ==========================
/sbin/iptables -A INPUT  -p TCP -s 0/0 --sport 53 -j ACCEPT
/sbin/iptables -A INPUT  -p udp -s 0/0 --sport 53 -j ACCEPT
/sbin/iptables -A OUTPUT -p udp -s 0/0 --dport 53 -j ACCEPT
/sbin/iptables -A OUTPUT -p TCP -s 0/0 --dport 53 -j ACCEPT
# ======================= ICMP RULE ==========================
/sbin/iptables -A INPUT  -p icmp -s $LINEA1 -j ACCEPT
/sbin/iptables -A INPUT  -p icmp -s $LINEA2 -j ACCEPT
/sbin/iptables -A OUTPUT -p icmp -s $LINEA1 -j ACCEPT
/sbin/iptables -A OUTPUT -p icmp -s $LINEA2 -j ACCEPT
# ======================= NTP RULE =========================
/sbin/iptables -A INPUT  -p udp --sport ntp -s $NTP_SRV -j ACCEPT
/sbin/iptables -A INPUT  -p tcp --sport ntp -s $NTP_SRV -j ACCEPT
/sbin/iptables -A OUTPUT -p udp --dport ntp -d $NTP_SRV -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --dport ntp -d $NTP_SRV -j ACCEPT
# ================== MAIL SEND RULE ========================
/sbin/iptables -A INPUT  -p tcp --sport 25 -s $LINEA1 -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --dport 25 -d $LINEA1 -j ACCEPT
/sbin/iptables -A INPUT  -p tcp --sport 25 -s $LINEA2 -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --dport 25 -d $LINEA2 -j ACCEPT
### ADD CUSTOM SERVER RULES BELOW
# ================= HTTP & HTTPS ============================
/sbin/iptables -A INPUT -i eth0 -p TCP --dport 80 -j ACCEPT
/sbin/iptables -A OUTPUT -o eth0 -p TCP --sport 80 -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p TCP --dport 443 -j ACCEPT
/sbin/iptables -A OUTPUT -o eth0 -p TCP --sport 443 -j ACCEPT
----------------------------------------------------------------------------
---------------
In pratica, definisce delle regole per l'accesso ai servizi SSH e come web
server pubblico. Ok, a parte il fatto che in questo modo non riesco a
limitare l'accesso SSH ad altri, cosa manca per la protezione completa??
Grazie mille per l'aiuto
Perseo

 Vorrei tralasciare un attimo il discorso telnet.
No. Scusa, ma tralasci o dai per scontato molte cose. Vorrei ADESSO sapere se
adesso netstat dice se la porta telnet e' aperta. DOPO, si puo' affrontare il
discorso del tcpwrapper (hosts.[deny|allow]), ed il firewall.
[SNIP]


 discorso del tcpwrapper (hosts.[deny|allow]), ed il firewall.
netstat -na | grep 23 dice:
unix  2      [ ACC ]     STREAM     LISTENING     3023   /dev/gpmctl
unix  2      [ ACC ]     STREAM     LISTENING     4472
/tmp/orbit-root/linc-caa-0-7ccdf53123cc9
unix  3      [ ]         STREAM     CONNECTED     4610
/tmp/orbit-root/linc-caa-0-7ccdf53123cc9
unix  3      [ ]         STREAM     CONNECTED     4482
/tmp/orbit-root/linc-caa-0-7ccdf53123cc9
unix  3      [ ]         STREAM     CONNECTED     4475
/tmp/orbit-root/linc-caa-0-7ccdf53123cc9
unix  3      [ ]         STREAM     CONNECTED     4323
/tmp/orbit-root/linc-c51-0-7d51df0f91b16

 [SNIP]
Tutti unix domain socket, vale a dire di telnet nemmeno l'ombra...
Adesso, serve l'OUTPUT di "ps -ef | grep inet


 Adesso, serve l'OUTPUT di "ps -ef | grep inet
root      2764     1  0 09:25 ?        00:00:00 xinetd -stayalive -pidfile
/var/run/xinetd.pid
root      3325  3287  0 10:06 pts/0    00:00:00 grep inet
E xinetd va...
Prossimo passo?

 Prossimo passo?
Prova a postare il file di config di xinet che riguarda telnet, a
questo punto e' piu' una curiosita' :)


 questo punto e' piu' una curiosita' :)
Tanto lo soOoOO che tutti i servizi di xinet sono disabilitati di
default, su rh9, gne' gne'...     ;-)


 Prossimo passo?
l'output di:
# cat /etc/xinetd.d/telnet
A seconda di quello che ci sara', riceverai un colpo di mazza da baseball
virtuale per aver ignorato i consigli gia' dati nel post famoso, a cui non hai
risposto. Stiamo facendo le stesse verifiche e le stesse azioni...   ;-)


 # cat /etc/xinetd.d/telnet
service telnet
{
    disable=no
    flags=reuse
    socket_type=stream
    wait=no
    user=root
    server=/usr/sbin/in.telnetd
    log_on_failure += userid
}

 }
"/etc/rc.d/init.d/xinetd restart", seguito da un "netstat -na | grep 23"


 "/etc/rc.d/init.d/xinetd restart", seguito da un "netstat -na | grep 23"
unix 3  [ ]   STREAM   CONNECTED  4523    /tmp/.x11-unix/X0

 unix 3  [ ]   STREAM   CONNECTED  4523    /tmp/.x11-unix/X0
Chiama un prete. Oppure prova:
http://www.chkrootkit.org


 
http://www.chkrootkit.org
Vedi che avevo ragione? L'unica è reinstallare qualche pacchetto. Per
fortuna su questo PC non serve il telnet.
Comunque grazie per le delucidazioni!

 Vedi che avevo ragione? L'unica è reinstallare qualche pacchetto.
No, io temo tu abbia qualche rookit installato (=computer hackerato, vari
comandi rimpiazzati fra cui netstat...).
Comunque, prima di pensare al peggio, guarda i log in /var/log/messages subito
dopo il restart, e vedi se c'e' qualche messaggio relativo a xinetd.


 
http://www.chkrootkit.org
A questo non ci avrei pensato in questa occasione, eppure, a questo
punto... mi sa che, sfortunatamente per perseo, puoi pure avere
ragione.


 A questo non ci avrei pensato in questa occasione
Si, e' da prendere come ultima spiegazione... difatti dopo ho cambiato
rotta... ma sara' per poco, presumo.    :-)


 50% di pigrizia...   ;-)
Per ogni evenienza padre Karras e' disponibile stasera su Italia1..
sono convinto che se si fermasse a leggere certe richieste di aiuto qui
concluderebbe che oggi il maligno alberga nei case di certi niubbi..
-- 
L'unico motivo per tenere ancora Windows
http://www.farb-rausch.com

 concluderebbe che oggi il maligno alberga nei case di certi niubbi..
^__^
