Re: [Netadm-devel] hi il-eok hwang [everyone readme please]
Status: Beta
Brought to you by:
linuxpark
From: jeho-park <lin...@gm...> - 2006-03-09 04:35:06
|
hi il-eok can you please cc net...@li... address whenever you send email ^-^ il-eok hwang wrote: > Hi, jeho park and everyone~~ > > Sorry, My work's results are not mine but my company. and I did leave > my company one month ago. > So i will give you any doc currently. > yes i understand, and i hope you to share some doc without breaking the license with your past company. > As you know, Snort Inline use netfilter target called IP_QUEUE. > and IP_QUEUE used netlink. i think these are not good solution. > How about you?? > last year, i heard that snort supports netfilter target. but i didn't check it or know more than that. from reading your letter, i realized the target is IP_QUEUE. i can't sure what is the best solution, but i think it may be dependent on network environment(gateway.. or sensor mode) and system performances. i suggest that before starting design, we should talk about this. because it is not easy to remake the frame, > you said to me as below. > i can imagine that there might be so many changes was needed to > port snort to kernel layer. > but i wonder all of snort code was really needed to port to the > kernel layer? > if so, what is the main motive of this porting ? > is it for more better performance of checking network packet ? ( i > assume you might throw away > current libpcap(premiscuous) concerned code of snort then you must > have replaced that with > netfilter hook ) > > it's a good solution. but as i think, mbuf is better than libpcap. > some IDS were developed with > zero copy tech in Linux. > > TODO. > - intrusion detection point in kernel : preprocessor & pattern > matching engine > - packet drop by rule > - use conf file and rule file in user land. > - .... > > recently, i works for developing L2TP - LAC, LNS. there are some bugs > in rp-l2tp & zebra, > so i will catch the bugs. after fixing-maybe 4days, i will check the > current our project's source > codes. > i recommand this document. http://netadm.sourceforge.net/devel_netadm_ko.txt especially chapter 3,4, 5 i think you dont have to understand all of our code but the interface which let you make your cli command i know zebra interface is not bad.. and used globaly.. but our cli interface more simple, and easy to build and make your cli command exported GUI interface. check "include/confproc.h" and gwclib/conftab.c gwclib/confproc.c bye ~ > see you later~~ > > 2006/3/8, jeho-park <lin...@gm... > <mailto:lin...@gm...>>: > > hi il-eok > > > il-eok hwang wrote: > >> Hi, jeho park and everyone~~ >> >> first, sorry for my poor english. >> >> as i think, i quite agree with you and i hope to help our project >> about the field of IPS( DPI ). >> if my opinion will be established, i wll make a document about DPI. >> >> there are some problems in porting SNORT to kernel. see below. >> - memory >> - rule >> - log >> - etc >> > > that's great ! if you make it with korean, i will help to > translate this document into english. > > through reading your letter, i become excited ^--^ and have so > many question. > > i can imagine that there might be so many changes was needed to > port snort to kernel layer. > but i wonder all of snort code was really needed to port to the > kernel layer? > if so, what is the main motive of this porting ? > is it for more better performance of checking network packet ? ( i > assume you might throw away > current libpcap(premiscuous) concerned code of snort then you must > have replaced that with netfilter hook ) > > i think as you replaced libpcap with netfilter hook, you could > check all network packet without packet loss. > but i wonder as a result of that, how did you lost system > performance or network throughput > i want to know about this point because you already have done this > test. > >> >> 6 months ago, i did port to kernel with netfilter. >> recently, i make a new kernel hook, so i will port SNORT with a my >> hook instead of netfilter. >> >> have a nice day ^.^*~~ >> >> > > from my knowledge, current netfilter hook is ranged from ethernet > layer to IP layer.. > did you mean your hook covers TCP. UDP layer ? > i will wait your reply. > > if it is possible, please let us show the framework as a form of > figure which you had done 6 month ago, > and current design. they must be very interesting. and i am sure > everyone want to know about that ^---^ > > > p.s: > since i start this project, > i have thought that current pf.c will receive the last alarm from > snort or other IDS sensor, > so pf , as a result of receving alarm, will drop a specifed source > host or control traffic of suspicious host. > but during reading your letter, i think you already have done it. > isn't it ? > if so, i don't mind throwing away my design. then i can more > concentrate my energy only to "flow control" ^--^ > > regards > jeh park > > >> >> 2006/3/8, jeho-park <lin...@gm... >> <mailto:lin...@gm...>>: >> >> >> hi il-eok >> glad to meet you through this mailling list. >> >> i read your mail, so i thought you have good career about >> security >> i expect you to help our project about the field of QoS or IPS. >> >> most of all, i wonder how did you ported snort to the network >> stack of >> linux. >> >> todays, george and kwan-kyung is also researching about that. >> so i hope >> you to share your knowledge with them. >> >> regards >> jeho park >> >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking >> scripting language >> that extends applications into web and mobile media. Attend >> the live webcast >> and join the prime developer group breaking into this new >> coding territory! >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642> >> _______________________________________________ >> Netadm-devel mailing list >> Net...@li... >> <mailto:Net...@li...> >> https://lists.sourceforge.net/lists/listinfo/netadm-devel >> <https://lists.sourceforge.net/lists/listinfo/netadm-devel> >> >> > > |