Pont filtrant sans ip: Indetectable?

Le Thu, 03 Nov 2005 19:02:59 +0000, MaXX a écrit :
[Pont filtrant sans IP]

1. sa présence est "détectable" (je pense qu'un pro poura noter sa présence)

Oui, puisqu'il applique aux flux réseau des contraintes qui
n'existeraient pas sans lui. On va donc voir des paquets disparaître dans
raison, ou des retours avec une TTL pas cohérente avec les observations,
pour ne citer que les cas les plus évidents.

2. est-il possible d'en prendre le contrôle autrement qu'en acces
physique? (faille de secu dans la pile TCP/IP?)

Personne n'a jusqu'à aujourd'hui mis en exergue une faille exploitable
sur une pile réseau. Mais ce n'est théoriquement pas impossible.

Question subsidaire: un P200 ça peut tenir le coup avec un
snort-inline (ou apparenté) sur de l'ADSL 4460/512 Kbps(FreeBSD)?

Pour ceux qui veulent faire tourner Snort Inline (développé pour
iptables, donc Linux) avec ipfw :

http://freebsd.rogness.net/snort_inline/


--
BC> je ne fais rire que les dinos
Mais vous faites gerber tous les autres.
-+-AC in <http://neuneu.mine.nu> : Dépôt de gerbe -+-

Salut,

1. sa présence est "détectable" (je pense qu'un pro poura noter sa présence)

Selon la configuration, ca pourrait être detectable dans un traceroute
par exemple (ca dépend si les paquets sont routés ou pas ==>
decrementation du TTL).

2. est-il possible d'en prendre le contrôle autrement qu'en acces physique?
(faille de secu dans la pile TCP/IP?)

Pas si la machine est bien blindée et sous reserve d'absence de
failles... ce qu'on ne peut "garantir". Mais faut pas non plus être
parano... on ne va pas te sortir un 0day si tu n'as rien de trés grande
"valeur" dans ta machine.

Je ne sais pas ce que ca vaut, mais tu pourrais tester la "root plug"
apparue dans le kernel 2.6 de Linux: le kernel detecte la présence ou
l'absence d'un certain peripherique USB, et en son absence aucun
processus ne peut être lancé en root (par contre ceux déjà lancés le
restent).

@+
Bertrand

Cedric Blancher wrote:

Le Thu, 03 Nov 2005 19:02:59 +0000, MaXX a écrit :
[Pont filtrant sans IP]

1. sa présence est "détectable" [...]
Oui, puisqu'il applique aux flux réseau des contraintes qui

n'existeraient pas sans lui. On va donc voir des paquets disparaître dans
raison, ou des retours avec une TTL pas cohérente avec les observations,
pour ne citer que les cas les plus évidents.
C'est bien ce qui me semblait...

2. est-il possible d'en prendre le contrôle autrement qu'en acces
physique? [...]
Personne n'a jusqu'à aujourd'hui mis en exergue une faille exploitable

sur une pile réseau. Mais ce n'est théoriquement pas impossible.

Question subsidaire: un P200 ça peut tenir le coup avec un
snort-inline (ou apparenté) sur de l'ADSL 4460/512 Kbps(FreeBSD)?
Pour ceux qui veulent faire tourner Snort Inline (développé pour

iptables, donc Linux) avec ipfw :
http://freebsd.rogness.net/snort_inline/
Genial, je viens d'y jeter un oeil et c'est ce qu'il me faut... Je vais

juste le compiler pour voir ce qu'il bouffe comme RAM (la machine est
vachement limite de ce coté à moins que je ne retrouve une barrette)..

Merci,
--
MaXX

Salut,
Bertrand wrote:

Salut,

1. sa présence est "détectable" ?[...]
Selon la configuration, ca pourrait être detectable dans un traceroute

par exemple (ca dépend si les paquets sont routés ou pas ==>
decrementation du TTL).
Je m'en doutais, mais en fait comme le pont est "IP less" il ne fera que 3

actions possible pour les paquets entrants:
- Rejet
- Réémettre sur interface 1 (DMZ)
- Réémettre sur interface 2 (LAN)
Il n'y aura pas de "routage" au sens habituel du terme, je vois ça comme une
sorte de switch "intelligent" qui balance ce qu'il ne lui plait pas...
Ca ne change pas le "metric" il me semble (corriger au besoin)...

2. est-il possible d'en prendre le contrôle autrement qu'en acces
physique? [...]
Pas si la machine est bien blindée et sous reserve d'absence de

failles... ce qu'on ne peut "garantir". Mais faut pas non plus être
parano... on ne va pas te sortir un 0day si tu n'as rien de trés grande
"valeur" dans ta machine.
Je me suis débarassé du concept de "donnée de valeur" sur mes machines, mais

je pense plutôt "ressources de valeur", genre 4 CPU, 200GB de disque...
Un kernel a jour, et une surveillance régulière des packages installés
devrait suffir (en exemple la faille de Snort (senseur BO) détectée il y a
qq semaines)...

Je ne sais pas ce que ca vaut, mais tu pourrais tester la "root plug"
apparue dans le kernel 2.6 de Linux: le kernel detecte la présence ou
l'absence d'un certain peripherique USB, et en son absence aucun
processus ne peut être lancé en root (par contre ceux déjà lancés le
restent).
ça semble intéressant, mais on fait comment en cas de coupure de secteur? Ca

s'active après le boot la protection?
J'ai bien l'intention de m'offrir un UPS pour ma Noël mais il va déjà avoir
du boulot avec mon serveur (un Netfinity 7000M10 qui n'avais rien à faire
dans une benne à ordure)...

@+
Bertrand

Merci,
--
MaXX

"Cedric Blancher" <blancher@cartel-securite.fr> wrote in message
news:pan.2005.11.03.20.55.53.60651@cartel-securite.fr

ou des retours avec une TTL pas cohérente avec les observations,
pour ne citer que les cas les plus évidents.

Un TTL qui change sur un équipement de couche 2, on m'aurait menti ? ;-)



--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

2. est-il possible d'en prendre le contrôle autrement qu'en acces
physique? (faille de secu dans la pile TCP/IP?)

Personne n'a jusqu'à aujourd'hui mis en exergue une faille exploitable
sur une pile réseau. Mais ce n'est théoriquement pas impossible.

Et l'histoire du DOS sur la pile IP microsoft, ca n'a rien donne?

http://www.cve.mitre.org/cgi-bin/cvename.cgi?nameÊN-2005-0048
pour rappel, microsoft protegeait mal le champ option du paquet IP.
En envoyant un paquet avec 39 ou 40 octets d'option faisait peter
la pile IP qui s'imaginait n'en recevoir que 38 au max.

le thread original:
http://groups.google.fr/group/fr.comp.securite/msg/d0dbd29eac939829?hl=fr
et suivants.

Salut,

Je m'en doutais, mais en fait comme le pont est "IP less" il ne fera que 3
actions possible pour les paquets entrants:
- Rejet
[...]

Ca reste detectable, puisque ça rejette, comme l'a souligné Cedric
Blancher. Mais le fait d'être détectable ne gène en rien au niveau securité.
Et de toute façon, la sécurité par l'obscurité, c'est mal(tm).

ça semble intéressant, mais on fait comment en cas de coupure de secteur? Ca
s'active après le boot la protection?

Excellente question :)

J'ai regardé le code source du module (simplissime), et dés qu'il est
chargé il active la protection (à chaque fois que un process est chargé
en egid=0, le module verifie la présence d'un periphérique USB donné; si
le péripherique est absent, l'execution est annulée).
Tu peux donc le charger en dernier, une fois que le système a booté, et
le système pourra démarrer tranquilement. A tester !

Sinon à cet instant je suis entrain de monter une machine serveur que je
souhaite securiser relativement bien (dans mes moyens quoi), j'ai choisi
une Debian Stable, un kernel 2.4.31, et grsecurity, qui permet
d'autoriser a chaque process et a chaque utilisateur seulement ce qu'il
est sensé faire. Du coup même root est consideré comme un intrus
potentiel, et ca facilite bien des choses.
Peut etre que tu pourrais partir sur un schema similaire ?
Avec toujours une bonne surveillance des logs et des découvertes de
vulnérabilités, ca devrait assez bien tenir.

J'ai bien l'intention de m'offrir un UPS pour ma Noël mais il va déjà avoir
du boulot avec mon serveur (un Netfinity 7000M10 qui n'avais rien à faire
dans une benne à ordure)...

Si tu mets un onduleur sur le serveur il en faut un sur ton switch
"intelligent" aussi, sinon de toute façon le reseau tombe et il ne sert
donc plus à rien de protéger le serveur (sauf pour éviter tout problème
de pertes de données).

Il y a en effet IMHO deux stratégies pour l'onduleur: la stratégie de la
continuité de service, et la stratégie de préservation de l'integrité de
l'infrastructure (c'est bien pompeux tout ça).
La première stratégie consiste à limiter l'impact de la coupure
d'alimentation vis à vis des services offerts par le système, et donc si
possible de garder l'alimentation pendant toute la coupure.
La seconde stratégie consiste simplement à avoir assez d'autonomie pour
avoir juste le temps de couper les machines proprement et donc d'éviter
toute dégradation matérielle ou "logicielle" (perte de données par exemple).

@+
Bertrand

Le Fri, 04 Nov 2005 18:44:56 +0000, octane a écrit :

Et l'histoire du DOS sur la pile IP microsoft, ca n'a rien donne?

Manifestement non. Il parait qu'elle est vraiment coton à exploiter
celle-là. Plus généralement, les exploits en kernel land, c'est chaud.


--
essai tout simplement
-+- A4 in : Guide du Neuneu d'Usenet - Neuneu tout simplement -+-

Bertrand wrote:

Salut,
Salut,

Je m'en doutais, mais en fait comme le pont est "IP less" il ne fera que
3 actions possible pour les paquets entrants:
- Rejet
[...]
Ca reste detectable, puisque ça rejette, comme l'a souligné Cedric

Blancher. Mais le fait d'être détectable ne gène en rien au niveau
securité. Et de toute façon, la sécurité par l'obscurité, c'est mal(tm).
D'accord avec l'aspect sécurité, mais le post de Eric Lalitte (TTL pour du

niveau 2) continue de me turlupiner... Enfin c'est du chipotage sur les
mot.

ça semble intéressant, mais on fait comment en cas de coupure de secteur?
Ca s'active après le boot la protection?
Excellente question :)

J'ai regardé le code source du module (simplissime), et dés qu'il est
chargé il active la protection (à chaque fois que un process est chargé
en egid=0, le module verifie la présence d'un periphérique USB donné; si
le péripherique est absent, l'execution est annulée).
Tu peux donc le charger en dernier, une fois que le système a booté, et
le système pourra démarrer tranquilement. A tester !
Le principe en tout cas semble être vraiment pas mal en tout cas...

Sinon à cet instant je suis entrain de monter une machine serveur que je
souhaite securiser relativement bien (dans mes moyens quoi), j'ai choisi
une Debian Stable, un kernel 2.4.31, et grsecurity,
[...]

Peut etre que tu pourrais partir sur un schema similaire ?
J'y compte bien, mais, si possible, sous FreeBSD. Je ne suis pas aussi

familier avec Linux que Fribi. J'ai lu récement que "l'expérience était
amie avec la sécurité" (bien que j'ai du mal à me dire que je suis
expérimenté)

Avec toujours une bonne surveillance des logs et des découvertes de
vulnérabilités, ca devrait assez bien tenir.
C'est le premier truc que je fait après avoir fait couler le café le matin

(sans déconner).

J'ai bien l'intention de m'offrir un UPS pour ma Noël mais il va déjà
avoir du boulot avec mon serveur (un Netfinity 7000M10 qui n'avais rien à
faire dans une benne à ordure)...
Si tu mets un onduleur sur le serveur il en faut un sur ton switch

"intelligent" aussi, sinon de toute façon le reseau tombe et il ne sert
donc plus à rien de protéger le serveur (sauf pour éviter tout problème
de pertes de données).
PostgreSQL n'aime pas les coupures, et j'aime pas restore (sauf quand y'a

pas le choix), mais je ne suis pas encore fâché avec dump...

Il y a en effet IMHO deux stratégies pour l'onduleur: la stratégie de la
continuité de service, et la stratégie de préservation de l'integrité de
l'infrastructure (c'est bien pompeux tout ça).
Bah, ça le fait devant des néophite/membres du C.A., le simple fait de caser

les mots "serveur", "firewall" ou "routeur" leur fait prendre une drôle de
moue... ;-)

La première stratégie consiste à limiter l'impact de la coupure
d'alimentation vis à vis des services offerts par le système, et donc si
possible de garder l'alimentation pendant toute la coupure.
La seconde stratégie consiste simplement à avoir assez d'autonomie pour
avoir juste le temps de couper les machines proprement et donc d'éviter
toute dégradation matérielle ou "logicielle" (perte de données par
exemple).
En fait je me demande comment implémenter un truc SOL (Sleep On LAN) pour

envoyer gentillement au dodo les deux bécannes d'un coup...

@+

--
MaXX

Salut,

En fait je me demande comment implémenter un truc SOL (Sleep On LAN) pour
envoyer gentillement au dodo les deux bécannes d'un coup...

C'est dangereux ca, à moins de faire ca de manière securisée par exemple
avec un challenge cryptographique. Si tu le fais simplement avec un
paquet tout bête ca pourrait devenir facile de faire un DoS sur ton LAN.
Et puis si ce qui est sensé generer le paquet SOL tombe, il se passe
quoi ?...

Si tu as un onduleur avec une sortie "etat" qui change de niveau
logiquel lors d'une coupure, tu relie ca par exemple au port // ou au
port serie des PCs sur une ligne qui ne peut servir que d'entrée
(attention aux ports // bidirectionnels), et tu fais du polling dessus;
quand la ligne est à l'etat "sur batterie" pendant plus de 2 minutes, tu
inities un shutdown...

Remarque hors sujet (on dévie vers l'electronique): bien implementer un
anti "rebond" (ou plutot parasites) en soft, et ceci est d'autant plus
important que la ligne est longue car elle sera plus susceptible aux
parasites. Cet effet est cependant limité puisqu'il faut que la ligne
reste en etat d'"alerte" pendant 2 minutes pour qu'on agisse.

Exemple: se brancher sur la ligne d'ACK du port //, et lire le registre
de status du controlleur de celui ci (ca doit etre à l'adresse
378h+qqchose genre 2 ou 3). Je ne sais pas si ca peut etre fait
facilement sous FreeBSD. Ca risque de faire un peu Mac Gyver avec des
fils partout et des connecteurs fait maison, mais le resultat pourrait
être trés efficace.

J'aurai tendance à privilegier cette solution face à une solution du
type onduleur USB car avec un onduleur USB on retrouve le problème de
l'absence de redondance de la génération du paquet "SOL" cité au debut
de ce post, puisqu'on ne pourra brancher que un seul PC sur le port USB
de l'onduleur.

@+
Bertrand