jve a écrit 73 commentaires

Je viens de tester...ca marche plutôt bien

Oui ba c'est qu'une question de choix en fait, une fois que t'a codé le support pour un sgbd, si c'est bien fait, c'est pas trop dur d'en ajouter un autre.

Après, la guerre de religion entre sgbd....

ya quand même une table users qui stocke les logins et les préférences.

Et encore, les logins/mdp peuvent être conservées sur LDAP. C'est le cas sur ma config. De fait, roundcube ne conserve qu'une copie des ces infos, et même pas les mots de passes il me semble.

La base de données ne sert, à ma connaissance, qu'a conserver les préférences, les dossiers souscris ou encore le cache (important pour pas recharger complètement un répertoire de 5000 email à chaque ouverture).

Heeeuuu... apache est sur une architecture threadée il me semble.

Les fonctions de type select, poll, epoll et kqueue s'occupent de monitorer des ensembles de sockets (disons, par exemple, plusieurs milliers de connexions réseaux) et de ne renvoyer au programme que celles qui ont des données a traiter.

En pratique, plutot que d'avoir un thread par socket et de faire de l'attente active, ce qui plombe les performances, on a un processus qui gére les 35 000 sockets et ne renvoie que ceux sur lesquels il y a de l'activité.

J'avais écris un billet sur le sujet, ca vaut ce que ca vaut...
http://jve.linuxwall.info/blog/index.php?post/2008/12/04/70-(...)

Malheureusement, non ce n'est pas le cas. Et je parle d'expérience. J'ai déja eu pour une grande institution 40Go de logs en 1h (flood). Si tu calcules cela fait plus ou moins 12Mo/sec. Le(s) firewall(s) n'ont pas tenu la charge. Et ce n'était pas une petite machine. En plus, on prend le risque d'avoir le disque plein et donc de subir un deni de service.


Pas tenu la charge ? Il me semble avoir vu des résultats de Bench pour syslog qui allaient largement au dessus de ces valeurs.
Après, les questions d'espace disque sont indépendantes des capacités du système. C'est sur que si tu souhaite tout loguer sur une connexion 10Gbits, vaut mieux avoir un gros RAID5 de plusieurs tera sous la main.

Concernant le déni de service, je vois pas trop comment ca peux arriver... a moins que tu décide de mettre du swap sur un firewall, mais le je comprend pas l'intérêt.



C'est ce que je disais. Quel est le point ?

Ha ba non alors, si on dit la même chose, tout va bien :)

C'est joli un équipement de sécurité qui ne logue pas... c'est un peu comme une barrière sans garde barrière: comment tu sais que quelqu'un vient de passer par dessus ? :)

Un firewall sous Netfilter peux tout loguer, du moment que tu fait ca intelligemment :
1. syslog peux manger des lignes de logs plus vite que tu ne pourra jamais lui en fournir, et niveau I/O je doute que ton noyau ou ton disque soit saturés avant ta carte réseau

2. Les DROP, ca se logs par connexions, ou par paquets si ya pas de connexions. Pour ca, tu met pas de politique par défaut car elle ne permet pas de loguer. Par contre tu peux mettre ca a la fin de tes règles :


echo "Default log drop, at the end so we just drop what doesn't match the previous rules"
iptables -N LOGDROP
iptables -A LOGDROP -j LOG --log-prefix "DROP => " --log-level debug
iptables -A LOGDROP -j DROP

iptables -A INPUT -i eth0 -j LOGDROP
iptables -A OUTPUT -o eth0 -j LOGDROP


3. Les accepts, ca se log aussi. Mais pas tout, juste les etablissements de connexions. La plupart des protocoles sur TCP garde une seule connexion TCP ouverte (sauf HTTP sans le keep alive). De fait, tu aura que peux de logs pour les accepts en comparaison du nombre de paquets.

Bon, ca peux quand meme faire quelques gigas, mais quels machines n'a pas 40 gigas de disques aujourd'hui ? Et puis, pas besoin de garder les logs pendant 30 jours, si tu n'a pas vu l'attaque passer dans la semaine, alors il faut changer de métiers ;)

C'est pour ca qu'il faut lire le corps de la news et pas juste le titre ;)

C'est justement cette capacité de remise en question qui fait que Linux est plus populaire que BSD ;)

IPtables mange plusieurs centaines de mega octets par secondes, et plusieurs dizaines de milliers de connexions simmultannées sur pas mal de GROS sites. Mais non, c'est pas encore assez bien, alors on continue d'améliorer. C'est pas beau ca ?

Ba, de rien pour la news ! C'était initialement un billet sur mon blog :
http://jve.linuxwall.info/blog/index.php?post/2009/03/23/nft(...)
et je pensais pas que ca valait la peine d'en faire une dépêche... mais bon, si ca intéresse des gens, c'est cool :)

Ca se comprend bien.... Ya pas que l'interface dans netfilter, ya surtout le noyau. Et avec tout le boulot qui a été effectué sur les conntrack tools, les xtables et j'en passe, je comprend qu'il ait pas envie de tout reprendre :)

Il va vraiment falloir que je reprenne ce projet de test d'OpenBSD, car si tout ce que vous dites au sujet de PF est vrai, alors c'est la révolution...

Néanmoins, je m'étonne que PF soit si peux présent dans les environnements d'entreprise que j'ai croisé. Vous me direz, c'est comme netfilter, qui se voit généralement préféré un checkpoint ou un juniper. Mais tout de même... pourquoi tant de silence ?

Ce qui m'amène à la question suivante : existe t'il une bonne présentation de PF qui soit pas une page de man ?
En français, en anglais... ça me va tant que c'est pas du danois (rigolez pas, on me l'a faite ce matin !)

Merci. Par contre, ça fait pas trop dépêche et vraiment journal (puisque c'est une entrée de blog à la base), et j'imagine mal comment le transformer.... a voir

Marrante cette depêche, surtout de la part de quelqu'un qui a son blog sous wordpress.......

Joyeux anniversaire à LinuxFR !
Continuez comme ça, c'est toujours un plaisir de surfer sur ces pages :)

Bien d'accord.
Entre faire des requetes SQL qui défoncent les perfs à chaque hit et réutiliser les capacités de logs d'une architecture multithreadé dont la puissance a fait ses preuves, ya pas photos....

Après, rien n'empeche celui qui veut s'amuser d'enrichir les logs, de les insérer dans une base de données et de faire ses corrélations la dessus, mais pas sur un serveur de prod qui se prend 40mbps de traffic dans la tronche.

Huumm..... ce n'est pas ma question...
Je connais ces algorithmes et je les utilisent régulièrement via différentes API (le plus souvent, openssl).

La, ce que je souhaite étudier, c'est les calculs sur des clés de 1024 bits (par exemple) en C.
Comment on les stockent ? Comment on les calculent ?

Huhu ! très bonne :)

J'ai bidouillé un peu avec asterisk pour faire de la VoIP mais c'est vraiment pas le meilleur soft pour ça. Clairement destiné au boulot de PABX.
Enfin, c'était le cas il y a un an.

rhoo oui une armee de geek au reveil, le tout en mosaique sur mon client irc, le reve :D

J'utilise une autre fonction de calcul de checksum qui vient d'un article de phrack maintenant

int checksum (unsigned short *buf, int nwords)
{
/*! Compute Internet Checksum for "count" bytes
* beginning at location "addr".
*/
register long sum = 0;

while( nwords > 1 ) {
/*! This is the inner loop */
sum += *buf++;
nwords -= 2;
}

/*! Add left-over byte, if any */
if( nwords == 1 )
{
u_short oddbyte = 0;
*((u_char *) &oddbyte) = *(u_char *)buf;
sum += oddbyte;
}

/*! Fold 32-bit sum to 16 bits */
sum = (sum >> 16) + (sum & 0xffff); /* add high-16 to low-16 */
sum += (sum >> 16); /* add carry */
return(~sum);
}

de fait, le code de creation devient

/*! *******************
* compute TCP checksum
* ********************
*/
int PSEUDO_SIZE = /*! 12 = size of the pseudoheader */
PAYLOAD_SIZE + (replay_tcp->doff*4) + 12;

char pseudo_tcp[ PSEUDO_SIZE ];

/*! fill up the pseudo header
*/
struct pseudo_header *ph = (struct pseudo_header *) pseudo_tcp;

ph->saddr = iph->saddr;
ph->daddr = iph->daddr;
ph->mbz = 0;
ph->ptcl = 6;
ph->tcpl = htons(PSEUDO_SIZE - 12);

/*! fill check field to 0 for checksum computation
*/
replay_tcp->check = 0;

/*! add tcp header + payload to the pseudo packet
*/
memcpy((char *)&ph->tcp, (char *)&replay_tcp, PSEUDO_SIZE - 12);

/*! compute the checksum and store it in the TCP structure
*/
replay_tcp->check = checksum((unsigned short *) pseudo_tcp, PSEUDO_SIZE );

g_print("check = %x, size = %u \n", ntohs(replay_tcp->check), PSEUDO_SIZE);

mais ca marche toujours pas :'(

moi aussi je suis passé par là il y a quelques mois... avant de partir aux US en fait, je me suis dit que crypter mon home pouvait être une bonne idée :)

attention, il faut savoir qu'en France, la justice peut réclamer la clé et que sa non fourniture est pas facile a encaisser (faudrait confirmer mais c'est de l'ordre de 300 000 ¤ et 3 ans de cachot, je crois)

toujours est-il que j'ai consigné ma petite config ici :
http://wiki.linuxwall.info/doku.php?id=ressources:articles:p(...)

des fois que ça intéresse quelqu'un......

Ces documents hautement stratégiques ont été dérobés par un agent infiltré des chinois du FBI avec une fausse carte du Mossad.

tiens, ca me rapelle mon prof de licence ca :D le vieux gheorghes qui nous racontais que la NSA savais casser RSA et AES depuis longtemps et que les chinois du FBI écoutaient toutes les com. de l'élysée ;)

je repose tant que possible, mais n'étant pas développeur et codant en C une fois par an, les histoires de pointeurs ça repart aussi vite que ça revient

et c'était bien la que se trouvais le problème, car je stockais mal l'adresse de mon payload dans ma liste...
maintenant je fait ca :

New_List = g_slist_append(New_List, & m->payload);

et je récup avec ca

struct iphdr *iptest = (struct iphdr *) g_slist_nth_data(P_to_List, index);

et, forcément, ca marche !!!!

Pour ce qui est du design, j'ai choisi les B-Tree car je lit plus que je n'écris, de fait je gagne un peu en rapidité... menfin, B-Tree ou Hash Table, le résultat est le meme : c'est juste un point d'accès pour ma liste chaînée

Merci pour le coup de main, ca m'a bien aidé ! De toute façon, vous risquez de me revoir poster pendant l'été ;)

Je vois passer TOUTES les connections réseaux d'une machine

donc pour chaque connexion réseau, je crée une entrée dans le B-Tree. La clé de cette entrée est le tuple Source IP + Source Port + Dest IP + Dest Port.

maintenant, il faut également que je conserve TOUS les paquets de chaque connection, et je veux pouvoir retrouver facilement les paquets d'une connections spécifique

donc, je pensais lier un tableau, ou une liste chaînées, a la valeur de mon entrée dans le B-Tree

ca donne un truc comme ca :
http://jvehent.free.fr/ressources/connerie/Store-connections(...)

De fait, j'ai modifié mon code pour utiliser une GSList mais ca marche pas encore... j'insére et je récupère bien mon pointeur mais j'ai l'impression que les données ne sont plus en mémoire....

je l'avais déjà essayé celle là, et ça ne résoud pas le problème


REDIRECTION CHECK : Conn ID 128.8.37.122:13666:128.8.37.121:22 or 128.8.37.121:22:128.8.37.122:13666 is not redirected
NETFILTER_CONNTRACK : Connection check called for 128.8.37.122:13666:128.8.37.121:22 state = activ
PCAP_TOOL : Current packet writed to output pcap file
STORING FUNCTION : 163st packet of 128.8.37.122:13666:128.8.37.121:22 stored in memory
IP table: 128.8.37.122; length : 60
IP table: 160.2.22.208; length : 22
IP table: 0.0.0.0; length : 1460
IP table: 1.0.0.0; length : 0
IP table: 184.22.220.191; length : 61879
IP table: 3.0.0.0; length : 0
IP table: 12.0.0.0; length : 56511
IP table: 232.114.218.183; length : 56511
IP table: 1.0.0.0; length : 65463
IP table: 0.0.0.0; length : 0


Dans la doc de GLib, ils disent de ne pas mettre struct devant :

EDayViewEvent *event;

/* This gets a pointer to the 3rd element in the array of EDayViewEvent
structs. */
event = &g_array_index (events, EDayViewEvent, 3);


mais quand je fais ca

iph2 = & g_array_index(P_to_Array, iphdr, i);


il me dit que iphdr est une variable non déclarée....

Ok merci pour l'explication, ça confirme ce que je pensais....

le soucis, c'est que je n'ai pas qu'un seul élément à stocker dans la valeur de mon B-Tree, mais bien une liste d'élément

je vais me faire une structure du type :
- taille du buffer
- pointeur vers le buffer
- pointeur vers le buffer suivant

à moins que GLib ais un type pour créer des listes chaînées directement ?