Je suis en train de concevoir un système dans lequel des dispositifs distants envoient en toute sécurité des mises à jour d'état à un serveur central d'enregistrement pour agrégation. Sur le serveur, j'utilise la solution Redis + Logstash + Elasticsearch. Les données envoyées au serveur sont sensibles et doivent être cryptées. Je m'efforce de trouver un moyen efficace et sûr de "LPUSH" les journaux à la liste Redis.
Les appareils sont actuellement capables d'envoyer la commande Redis suivante directement au port 6379.
"*3\r\n$5\r\nLPUSH\r\n$3\r\nkey\r\n$5\r\nvalue\r\n"
La clé correcte et l'entrée de la liste sont créées dans Redis sur le serveur.
L'étape suivante consiste à placer redis derrière un pare-feu et à crypter les paquets. Ma tentative actuelle consistait à utiliser Apache comme reverse proxy. Un appareil établit une connexion SSL bidirectionnelle avec Apache, puis renvoie les informations décryptées vers le port 6379 en utilisant l'interface de bouclage. La connexion SSL bidirectionnelle est établie sans problème et un message est transmis à Redis. Malheureusement, ce n'est pas le message que le périphérique a envoyé. tcpdump me dit ce qui suit...
tcpdump -nnXvv -i lo host localhost and port 6379
127.0.0.1.48916 > 127.0.0.1.6379: Flags [P.], cksum 0xfeab (incorrect -> 0x9415),
seq 1:132, ack 1, win 1025, options [nop,nop,TS val 299310518 ecr 299310518],
length 131
0x0000: 4500 00b7 12b7 4000 4006 2988 7f00 0001 E.....@.@.).....
0x0010: 7f00 0001 bf14 18eb ce9c 0f04 e920 abec ................
0x0020: 8018 0401 feab 0000 xxxx xxxx xxxx xxxx ................
0x0030: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx ....*3./.HTTP/1.
0x0040: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx 1..Host:.localho
0x0050: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx st:6379..X-Forwa
0x0060: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx rded-For:.xx.xxx
0x0070: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx .xxx.xxx..X-Forw
0x0080: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx arded-Server:.xx
0x0090: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx .xxx.xxx.xx..Con
0x00a0: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx nection:.Keep-Al
0x00b0: xxxx xxxx xxxx xx ive....
Comme on peut le voir dans la traduction ASCII, Apache tronque le message au premier CRLF après *3 et ajoute des informations d'en-tête HTTP pour le transfert, comme il est censé le faire. Bien sûr, Redis répond avec une erreur car le message n'est plus formaté en utilisant le Redis Serialization Protocol (RESP).
1) Existe-t-il un moyen de configurer Apache pour qu'il transfère aveuglément les paquets TCP bruts ?
2) Sinon, existe-t-il une solution standard à code source ouvert pour résoudre ce problème ?
Merci pour votre temps !
1 votes
Qu'essayez-vous de faire que le simple transfert de port NAT ne peut pas accomplir ?
0 votes
@MichaelHampton cryptage.
1 votes
Je choisirais un tunnel SSH et non un proxy.