Newsgroup: it.comp.os.linux.sys
Titolo: Strane connessioni da http (80) verso porte privilegiate (<1024)

Oggi, per diverse ore, il mio sito e' stato praticamente bloccato da
una caterva di strane richieste, io me ne sono accorto per caso e non
ci ho fatto un gran che fino al pomeriggio. Stasera mi sono scaricato
il log per darci un'occhiata.
Quello che vedo e' che ci sono una caterva di messaggi del tipo:
Oct 25 13:12:42 gort kernel: [Firewall] IN= OUT=eth0 SRC=82.94.182.66
DST=69.17.240.126 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP
SPT=80 DPT=989 WINDOW=5792 RES=0x00 ACK SYN URGP=0
82.94.182.66 e' il mio server, 69.17.240.126 e' una qualche macchina
in Montreal, ce ne sono a pacchi di linee cosi' ed ogni volta l'ip del
destinatario e' diverso. Queste sembrano essere "risposte" di Apache
verso richieste fatte dal altre macchine, che pero' vengono bloccate
dal firewall perche' vanno verso porte privilegiate (che io non
consento).
Dato il numero di richieste tendo a pensare ad un qualche tentativo di
spamming o DOS, ma mi lascia perplesso... Al momento ho alterato il
firewall per _rifiutare_ connessioni _da_ porte privilegiate (oltre
che non consentirne il ritorno).
Qualcuno ha mai visto niente di simile?
Davide

 Qualcuno ha mai visto niente di simile?
Senza dubbio anomalo, ma nulla di particolarmente inquietante, direi, in
mancanza di altri sintomi.
Fossi in te, risponderei con un RST piuttosto che con un icmp port
unreachable.

 consento).
Premesso che ognuno ci fa quel che vuole con le sue macchine:
- perche' impedire l'interazione ai client che inviano da porte <1024?
- perche' bloccare le risposte a richieste provenienti da porte <1024,
  che oramai hanno impegnato il socket, e non bloccare direttamente le
  richieste?
... e spero solo che la chain in cui entra questo traffico non finisca
in DROP, da cui si spiegherebbe il rallentamento del server  :-)
Giusto un'osservazione contro questa pratica: l'overload dei nat cisco
assegna porte a partire dalla 1/tcp a salire ai client mascherati, nel
caso di collisione della quaterna ip-nat:porta-src<->ip-dst:porta-dst.
Quindi, se due host 1) appena accesi e 2) dietro allo stesso nat cisco
accedessero contemporaneamente al tuo sito avresti che la richiesta da
parte del primo host arrivera' dalla 1024/tcp e l'altra dalla 1/tcp.
Fabio

 caso di collisione della quaterna ip-nat:porta-src<->ip-dst:porta-dst.
Non si finisce mai di imparare. Questa proprio non la sapevo.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 in DROP, da cui si spiegherebbe il rallentamento del server  :-)
No e' in reject.
Ma buono a sapersi questa pratica-contro-natura Cisco.
Davide

 Ma buono a sapersi questa pratica-contro-natura Cisco.
non è contro natura, imho.
Max

 
Scusa un attimo... ma il IANA che ci sta' a fare allora? (dubito sia 
solo una cosa dei "sistemi *nix")
http://www.iana.org/assignments/port-numbers
e anche
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_ports

 
http://www.iana.org/assignments/port-numbers
Qui leggo
postgresql      5432/tcp   PostgreSQL Database
non vorrai per� impedire al mio client di collegarsi dalla
sua 5432 alla tua 80?
Quelle sono solo le well-known, quindi se mi collego alla tua 80
so *con ragionevole certezza* che ci trover� un webserver, ma
potresti anche averci messo un echo server.
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
CBR600F "Cerbero" - In vendita - 
http://www.slimmit.com/go.asp?7X0
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png

 solo una cosa dei "sistemi *nix")
Dove sta scritto che non possono essere usate come porte sorgente di 
connessioni TCP? Well Known Ports non vuol dire Unusable Ports.
L'elenco ha un senso solo per chi mette un servizio in ascolto.


1024, ma è un altro discorso), al punto che sui sistemi *nix queste
porte sono utilizzabili solo da root (o da un fork di root): conseguenza
- non causa - del fatto appunto che sono porte in qualche modo
*usualmente* riservate a servizi ben precisi, e non a disposizione dei
client come origine.
Il che vuol dire che vedere una connessione /client/ *proveniente* da
una porta p.e. 80 è anche a mio avviso "anomala", anche se tecnicamente
lecita, e IMHO *non* andrebbe fatta.
Ma credo che stiamo entrando in un campo più filosofico che tecnico!
-- 
Massimo Bacilieri AKA Crononauta

 Ma credo che stiamo entrando in un campo più filosofico che tecnico!
Non è filosofia.
Se l'informatica fosse fatta di filosofia, ci sarebbe anarchia (e 
parzialmente c'è già perché molti sviluppatori non sanno leggere le RFC, 
come qui appare chiaro).
Non solo è lecito farlo, ma è obbligatorio accettarlo perchè non c'è 
scritto da nessuna parte che è vietato.
Anche su *unix si può fare.
Esempio su linux:
Su una macchina:
# echo "100 1000" > /proc/sys/net/ipv4/ip_local_port_range
# telnet 10.10.10.102 55
Sull'altra macchina:
# tcpdump -n  port 55
10:21:11.154595 IP 10.10.10.101.677 > 10.10.10.102.55: Flags [S], seq 
2157516743
, win 5840, options [mss 1460,nop,nop,TS val 128479483 ecr 0], 
length 0
10:21:11.155197 IP 10.10.10.102.55 > 10.10.10.101.677: Flags [R.], seq 0, 
ack 
2157516744
, win 0, length 0

  e non a disposizione dei client come origine.
Beh, prova un po' a vedere che porta usa un client ntp, ad esempio...;)

 scritto da nessuna parte che è vietato.
Rammento una occasione (credo fosse il 2001) in cui per conto di una
grossa società internazionale misi in piedi un webserver (in realtà un
cluster di) con di fronte un reverse proxy per servizi che dovevano
erogare a $TELCO.
Proxy in DMZ e webserver in MZ, di mezzo un firewall la cui
amministrazione è affidata al loro gestore IT, grossa società di Milano
specializzata in IT e Security.
Loro configurano il pinhole sul firewall, e dopo un po' la comunicazione
tra proxy e webserver smette di funzionare.
IO: E' come se i vostri apparati stessero applicando un blocco basato
sulle porte sorgenti scelte dal proxy, perchè funziona solo quando la
connessione parte da porte maggiori di X (che non ricordo, ma tipo
32000; ndSkull)
LORO: Beh, allora dicci da quali porte deve poter arrivare...
IO: Posso farlo dal range che scegliamo, se lo riteniamo opportuno, ma
non ne vedo il senso. La cosa più sensata, se proprio volete
"stringere", è richiedere che la porta sorgente sia >1024...
LORO: Eh, sì, apriamo a tutto....
IO: Mi prendete per il culo?
Non ho mai saputo in base a quale assurdità fosse stato scelto il range
di porte sorgenti che avevano apposto di testa loro...
-- 
Professional System & Network Sarcazzer
http://bofhskull.wordpress.com/


Eh ma quello è un "well-known client" (se ci sono i "well-known
services"...) :-D


 di porte sorgenti che avevano apposto di testa loro...
Io, che sono sicuramente uno sprovveduto in fatto di sicurezza e pecco di 
ottimismo, non capisco proprio il concetto per cui si debbano applicare 
regole al proprio firewall sulle porte di *origine*.
L'unico motivo "valido" che mi viene in mente è creare una VPN dei poveri 
fra due LAN dietro NAT, senza utilizzare una VPN.
-- 
Vide