Newsgroup: it.comp.os.linux.iniziare
Titolo: ipchains e regole

Dove:
Workstation standalone, nessuna lan locale, connessione a internet NON
permanente.
Scopo:
Impedire qualsiasi tentativo di richieste di connessioni da internet (syn,
ftp,telnet..) ,nessuna restrizione dall'interno verso l'esterno.
Ho letto l'howto di ipchains, ma mi permane qualche dubbio su quali e
quante parti (e porte) devo mettere le "catene" ,qualcuno che ha gia`
affrontato il problema potrebbe postare le regole che ha applicato
come esempio?
-- 
db-crash.

db-crash scriveva:

Basta modificare i file /etc/host.allow e /etc/host.deny
il primo ALL:localhost e il secondo ALL:ALL
-- 
Ciao
Salvatore 
               L'unico modo di accelerare Windows e'...a 9,8m/s^2
                Bad Penguin, la distribuzione Linux in italiano
                               ICQ# 268227566

il primo ALL:localhost e il secondo ALL:ALL
[paranoia mode on]
Avevo gia` inserito quello che mi hai suggerito, quello che non so e`
se tale azione rende sicura la workstation senza bisogno di altro
[paranoia mode off]
PS: ..ragionevolmente sicura, non ho segreti militari da custodire ;)
-- 
db-crash.

Il giorno Sat, 08 Jan 2000 10:48:17 GMT, db-crash scriveva:

Se guardi "man hosts.allow" mi pare ci sia appunto una parola chiave PARANOID
che credo si riferisca alla possibilità di rigettare i pacchetti provenienti da
hosts il cui nome non corrisponde all'indirizzo... non ho approfondito cmq, l'ho
solo visto...
Ciao,
-- 
Riccardo Tromba
(per rispondermi in mailbox, rimuovete NO e SPAM dall'indirizzo)
   Per pensare, scrivere, spedire questo messaggio
  non è stato necessario alcun software commerciale
--*     (-:   L I N U X : join & enjoy!   :-)     *--

> Basta modificare i file /etc/host.allow e /etc/host.deny
db> Avevo gia` inserito quello che mi hai suggerito, quello che non so e`
db> se tale azione rende sicura la workstation senza bisogno di altro
agendo  su  /etc/host.[allow|deny]  puoi  controllare  solo  i  server
lanciati tramite inetd (vedi /etc/inetd.conf) quando qualcuno cerca di
connettersi, ma non ad esempio sendmail, che potrebbe partire di suo. 
Chiudi tutte  le porte sotto la  1024, ad eccezione  della 113. Chiudi
anche la 6000.
-- 
"Grazie a Dio sono ateo."
		-- Luis Bunuel

anche la 6000.
Uhm... ma calma, la 25, la 110 e 119 tcp le devo pur lasciare aperte,
sennň posta e news come le spedisco e/o ricevo?
Sulla 6000 invece cosa ci gira? Un po' con le porte mi ci oriento, mi ero
fatto due palle cosě a configurare il Conseal, perň non ricordo nulla in
winzozz sulla 6000.
-- 
Crononauta
==========
ICQ UIN: 4005815
IDAnet: 
http://adcserver1.biodip.unimi.it/ida/index.htm
GP Legends: 
http://www.multiplayer.it/driving/

winzozz sulla 6000.
E' il server X, il server grafico. Ma se lo chiudo, ovvero no lo
apro, come diamine uso Agent ?  :-)
Ciao.

 anche la 6000.
parlo solo per sentito dire, ma la fonte e' autorevole.
ma la 6000
e' chiusa di default verso l' esterno ache se netstat da x ovvio te la
fa' vedere.
Ciao
roberto

apro, come diamine uso Agent ?  :-)
Uhm... ma scusa, non si può allora impostare un rule che chiuda l'accesso
alla porta 6000 a tutti _tranne_ che a 127.0.0.1?
L'unico problema è che così non si sarebbe al sicuro dagli spoof...uhm
uhmz uhmz... :-(
Qualcuno ha qualche idea?



Chiuso per default niente, questo č un mio prospetto di netstat da
DISCONNESSO, mentre leggo le news:
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 
127.0.0.1:119
 
127.0.0.1:1024
     ESTABLISHED 
tcp        0      0 
127.0.0.1:1024
 
127.0.0.1:119
      ESTABLISHED 
tcp        0      0 
0.0.0.0:6000
            0.0.0.0:*               LISTEN      
tcp        0      0 
0.0.0.0:25
              0.0.0.0:*               LISTEN      
tcp        0      0 
0.0.0.0:515
             0.0.0.0:*               LISTEN      
tcp        0      0 
0.0.0.0:113
             0.0.0.0:*               LISTEN      
tcp        0      0 
0.0.0.0:119
             0.0.0.0:*               LISTEN      
tcp        0      0 
0.0.0.0:110
             0.0.0.0:*               LISTEN      
tcp        0      0 
0.0.0.0:513
             0.0.0.0:*               LISTEN      
tcp        0      0 
0.0.0.0:514
             0.0.0.0:*               LISTEN      
tcp        0      0 
0.0.0.0:23
              0.0.0.0:*               LISTEN      
tcp        0      0 
0.0.0.0:21
              0.0.0.0:*               LISTEN      
udp        0      0 
0.0.0.0:177
             0.0.0.0:*                           
raw        0      0 
0.0.0.0:1
               0.0.0.0:*               7           
raw        0      0 
0.0.0.0:6
               0.0.0.0:*               7         
In pratica sono presenti TUTTI i servizi in listening. E cosě c'č leafnode
(119), il server X (6000), sendmail (25), auth (113), ftpserver (21),
telnet (23), pop server (110) e altre robe.
La cosa sconcertante č che io mi sono creato dei rules del firewall per
bloccare le porte di questi servizi ma... non c'č niente da fare! =:-O
I servizi restano aperti fottendosene del firewall! Mi pare di
impazzire... 
Qualcuno riesce a convincere ipchains a fare il suo lavoro?


 wrote:
 >515    open        tcp      printer                root
 Questo e` lpd, ma di default non e` possibile collegarsi.
 >6000    open        tcp      X11                    root
 Questo e` X, idem.
 --
 ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
 Marco | * The Internet is full. Go away.  -- Joel Furr *

On Tue, 11 Jan 2000 03:25:42 +0100, Crononauta wrote
| La cosa sconcertante è che io mi sono creato dei rules del firewall per
| bloccare le porte di questi servizi ma... non c'è niente da fare! =:-O
| I servizi restano aperti fottendosene del firewall! Mi pare di
| impazzire... 
E` ovvio!
| Qualcuno riesce a convincere ipchains a fare il suo lavoro?
Quello e` esattamente il suo lavoro...
Per chiudere un servizio devi disabilitare il programma che apre la
porta: ora, se non vuoi la porta 6000 aperta non c'entra ipchains, non
devi eseguire X.
Il firewall non chiude le porte, le filtra e le rende (al massimo) non
disponibili.
-- 
 ____      ___              | 3/4 Romulan, 1/4 Vorta. | Ho imparato qualcosa
/_  / ___ / _/______ ___ _  | Stirred, not Shaked.    |  - Kintaro Oe	
 / /_/ -_) _/ __/ _ `/  ' \ | 
http://zefram.8m.com
    | Lasciate che i concetti 
/___/\__/_//_/  \_,_/_/_/_/ | 
zef...@iol.it
	      | fluiscano liberi - ZC
	      - Zefram is on a K6-166 - RH6.0 - Kernel 2.2.12 -

On Mon, 10 Jan 2000 21:10:57 +0100, Crononauta wrote
| Uhm... ma scusa, non si puň allora impostare un rule che chiuda l'accesso
| alla porta 6000 a tutti _tranne_ che a 127.0.0.1?
| L'unico problema č che cosě non si sarebbe al sicuro dagli spoof...uhm
| uhmz uhmz... :-(
| 
| Qualcuno ha qualche idea?
Hai molta confusione in testa...
Dai una lettura al Firewall-HOWTO.
Per una regola di ipchains che non permetta l'accesso dall'esterno sulla 
porta 6000 puoi usare questa:
/sbin/ipchains -A input -p tcp -d <tuo_ip_da_connesso> 6000 -j -l REJECT


>>>>> "C" == Crononauta  <ta...@t-rex.tato> writes:
C> 
C> Uhm... ma calma, la 25, la 110 e 119 tcp le devo pur lasciare aperte,
C> sennò posta e news come le spedisco e/o ricevo?
certo, ti servono *dentro* la tua macchina, ma vanno chiuse per quelli
che arrivano da *fuori* e vorrebbero fare un giro in giostra gratis :-)
C> Sulla 6000 invece cosa ci gira? 
il server X
Ciao
Marco
-- 
Domattina alle sei saro' giustiziato per un crimine che non ho commesso.
Dovevo essere giustiziato alle cinque, ma ho un avvocato in gamba.
		-- Woody Allen

 writes:
B> 
B> ma la 6000 e' chiusa di default verso l' esterno 
sě, dovrebbe essere chiusa, ma preferisco esagerare :)
B> ache se netstat da x ovvio te la fa' vedere.  
certo,  ma io  voglio che  non  si veda  nulla, o  il meno  possibile.
Impostando DENY come target per la  regola, si butta il pacchetto IP a
mare e  lo scanner non trova  proprio nulla, credo. Se  qualcuno sa di
piů, aggiunga.
-- 
Principio di Abrams:
	Il percorso piu' breve tra due punti scavalca il muro.

/sbin/ipchains -A input -p tcp -d <tuo_ip_da_connesso> 6000 -j -l REJECT
				   ^^^^^^^^^^^^^^^^^^^^
AH MA PORCA PUTTANA, ecco il problema!!!!!!!!!!!!!!!!!!!!!
Miiiiiiiiiiihhhhhhhhhh, io continuavo a mettere 127.0.0.1!!! :-((((
Questo cambia tutto! :-O
Solo che ho un ip dinamico, come diavolo faccio a intendere "il mio ip
sulla rete esterna"???????
potrei usare il metodo "taglialo grosso e infilalo a calci"... gli do come
ip di destinazione 255.255.255.255 e mask 0.0.0.0 :-))))))))))))
Dite che funziona?



questo e' un pezzo dei post di quest'estate tra thorin e Cimaschi,
"firewall su linux, un consiglio", adatto a te:
=-=-=-=-=-=-=-=-=-=-=-=> CLIP HERE < =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 
 
# -------------------------- Variable definition - #
# Set the location of $IPCHAINS.
 
IPCHAINS="/sbin/ipchains"
LOCALIP=`ifconfig $LOCALIF | grep inet | cut -d : -f 2 | cut -d \  -f
1` LOCALMASK=`ifconfig 
$LOCALIF | grep Mask | cut -d : -f 4`
LOCALNET="$LOCALIP/$LOCALMASK"
 
=-=-=-=-=-=-=-=-=-=-=> CLIP HERE < =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 
cerca su deja, e' un post illuminante! Comunque io ho scaricato tutti
i post, e li ho riorganizzati, e d'accordo con cimaschi forse se ne fa
un mini-howto, se mi scrivi per email te li mando compressi
--------------------------------------------------
When a packet hits a pocket on a socket on a port,
And the buss is interrupted as a very last resort,
And the address of the memory makes your floppy disk abort,
Then the socket packet pocket has an error to report

On Tue, 11 Jan 2000 17:58:25 +0100, Crononauta wrote
| Solo che ho un ip dinamico, come diavolo faccio a intendere "il mio ip
| sulla rete esterna"???????
| 
| potrei usare il metodo "taglialo grosso e infilalo a calci"... gli do come
| ip di destinazione 255.255.255.255 e mask 0.0.0.0 :-))))))))))))
Cosi` blocchi tutto, anche la loopback...
usa questo:
LOCAL_IF="ppp0"
LOCAL_IP=$(ifconfig $LOCAL_IF 2> /dev/null | \
            awk '/inet/ {sub(/addr:/, "", $2); print $2}')
 
-- 
 ____      ___              | 3/4 Romulan, 1/4 Vorta. | [70 2E] [71 FF] 
/_  / ___ / _/______ ___ _  | Stirred, not Shaked.    |  - CMOS 
 / /_/ -_) _/ __/ _ `/  ' \ | 
http://zefram.8m.com
    | Lasciate che i concetti 
/___/\__/_//_/  \_,_/_/_/_/ | 
zef...@iol.it
	      | fluiscano liberi - ZC
	- Zefram is on a K6-166 32MB - RH6.0 - Kernel 2.2.12 -

            awk '/inet/ {sub(/addr:/, "", $2); print $2}')
Hai ragione anche tu, infatti non ho fatto cosě... ho trovato meno
cervellotico questo:
-s ! 127.0.0.1 --destination port xxx -j REJECT
con xxx la porta che voglio chiudere dall'esterno ma non dall'interno :-)


proprio nulla, credo. Se qualcuno sa di più, aggiunga.
Credo che la politica di DENY sia  più "sospetta", nel senso che se vuoi
fingere che la porta sia chiusa, è meglio un REJECT che fa credere a chi
tenta di collegarsi  che la porta sia effettivamente chiusa.  Il DENY in
compenso torna utile per gli attacchi  DoS, perchè evita di rispondere e
conseguentemente risparmia banda.
Non so però se il REJECT risponde con un "connection refused" oppure con
un "destination unreachable".
-- 
  _      ___ ____
 | | /| / (_)_  /
 | |/ |/ / / / /_	ANTI-SPAM WARNING:
 |__/|__/_/ /___/	the e-mail address is fake.
 
Monica Lewinski and Windows 98: both of them suck a lot, both of them are
giving Bill some trouble.

 db-crash.
Non su servizi che non passano per inetd.
Quindi sendmail o httpd. Per sendmail puoi inserirlo dentro i servizi
controllati da inetd e quindi controllati via host.allow e host.deny .
Per httpd (Apache di solito) secondo me puoi farne tranquillamente a
meno e toglierlo (non credo ti serva un server web sulla tua macchina di
casa...).
			Giulio

 writes:
L> 
L> Non  so perň  se il  REJECT  risponde con  un "connection  refused"
L> oppure con un "destination unreachable".
L> 
ho fatto qualche prova... e sono un po' perplesso!
- porta con ACCEPT o REJECT, telnetto e ottengo "connection refused"
- porta con DENY, telnet resta lě nel tentativo di connettersi
Se  provo  un  connect  scan   con  nmap,  la  porta  con  DENY  viene
riconosciuta come  "filtered".  Se  solo passo ad  un SYN  scan allora
viene vista come  "filtered" pure la porta protetta  con REJECT. Ormai
ci sono e provo pure altri stealth scan: la porta con DENY viene vista
"open", mentre quella con REJECT č vista "filtered". Curiosamente, per
me,  le porte  ACCEPT su  cui  non c'č  nulla in  ascolto non  vengono
segnalate in alcun modo...
Ciao
Marco
-- 
Se puo' essere vero che una pentola osservata non bolle mai, quella a cui
non dai un'occhiata puo' fare un macello sulla tua cucina.
		-- Edward Stevenson

segnalate in alcun modo...
Mi sembra abbastanza giusto (impallamenti  e confusione del firewall a
parte) Se ho capito come funziona la cosa, il firewall ti filtra (bene
o male) ma in  effetti chi ti fa' vedere la porta e'  il demone che la
ascolta, se non  c'e' demone non puo' esserci risposta  e quindi e' un
buco nero.
Ciao Francesco.
 
<*>  Appunti Linux per il pinguino che non deve chiedere mai. <*>  
<*>  
http://www.pluto.linux.it
                                <*>

>PGP public key avaiable<<
fingerprint: 14AA 1D7A 1653 E132 47CE  334C C9D3 6A97 208B A915

- porta con DENY, telnet resta lě nel tentativo di connettersi
A me spiegarono la storia in questi termini (ma non posso ovviamente
garantire l'affidabilitŕ): DENY semplicemente "butta a mare" i pacchetti,
ma chi tenta l'accesso continua a restare collegato e a tentare il
collegamento, fino al timeout. Questo si traduce in un carico per la cpu e
nell'aumento di lag.
REJECT rifiuta la connessione subito, e sgancia il remote; quindi si
riduce il carico di cpu e il lag.
Ve la riporto come me l'hanno detta, eh, non ditemi delle boiate!


 writes:
F> 
F> poi bisognerebbe vedere come sono impostate le regole del firewall.
# ipchains -A input -p tcp -s 0/0 -d 0/0 60000 -j DENY
# ipchains -A input -p tcp -s 0/0 -d 0/0 60001 -j REJECT
# ipchains -A input -p tcp -s 0/0 -d 0/0 60002 -j ACCEPT
F> ma  in effetti  chi ti  fa' vedere  la porta  e' il  demone  che la
F> ascolta, se non  c'e' demone non puo' esserci  risposta e quindi e'
F> un buco nero.
esatto, io  avrei voluto  dare un buco  nero anche delle  porte aperte
all'interno, ma chiuse  verso l'esterno, ma a quanto  pare gli scanner
sono abbastanza furbi da riconoscere i finti buchi neri :-)
Ciao
Marco
-- 
Il QI di un gruppo e' il piu' basso QI di un membro del gruppo diviso
per il numero di persone nel gruppo.

>>>>> "C" == Crononauta  <ta...@t-rex.tato> writes:
C> 
C> REJECT rifiuta  la connessione subito, e sgancia  il remote; quindi
C> si riduce il carico di cpu e il lag.
- il carico di cpu di chi? del firewall o dell'intruder?
- in  ogni caso,  quanto  impatta un  tentativo  di connessione  sulla
  macchina firewall?
- Cos'è il lag?
C> Ve la riporto come me l'hanno detta, eh, non ditemi delle boiate!
ok, qualcun altro sa rispondermi?
-- 
"Pierino, cos'e' un temporale?".
"Sono delle nubi che, spaventate dai tuoni, scoppiano a piangere".
		-- Da it.hobby.umorismo