[Oisf-users] Recommend communication mechanism between Suricata engine and another process

[Andreas Herz]

Hi,

On 25/03/17 at 23:07, tidy at holonetsecurity.com wrote:
> Hi  Andreas,
> 
> 	The SSL Proxy working as Transparent proxy(using iptables TPROXY) plus Bridge mode, the bridge interfaces say eth1 are using to receive  and lo to forward the packets.
>        Another side,  since the SSL Proxy works based on application layer data, the SSL proxy needs fake L2 + L3 packet heads if choosing  Unix Sockets as communication channel. so I am not sure which one is more suitable to solve this.
> 	Very appreciate your kind help!

I'm not familiar with such a setup, so would need to create one.
You could try to make a test setup within that you activate pcap log of
suricata and could send us a test traffic so we might see anything
special that suricata receives.
You could also take a look into the NFQUEUE netfilter target, maybe you
can reroute the traffic within iptables to suricata in a more sane way.
But that's just a guess.

> -Tidy
> 
> > On Mar 25, 2017, at 7:56 AM, Andreas Herz <andi at geekosphere.org> wrote:
> > 
> > On 24/03/17 at 10:01, tidy at holonetsecurity.com wrote:
> >> I’m trying copy packets from an SSL decrypting process to Suricata on
> >> the same machine, could you help to recommend mechanism to talk
> >> between the SSL decrypting process and Suricata. 1) virtual network
> >> card interface 2) Unix Sockets (Suricata only support pcap files using
> >> command). 3)?
> > 
> > Well what process are you using and how does it receive and forward the
> > packets?
> > 
> > -- 
> > Andreas Herz
> > _______________________________________________
> > Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> > Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
> > List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> 

-- 
Andreas Herz