<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>What kernel are you running? I know there were some hash symmetry
issues with 4.4 and AF_PACKET (although I know you said PF_RING
didn't work either). What about the NIC and RSS queues?</p>
<p>Michal can speak more intelligently about these things than I can
but I thought I'd throw it out there; see also
<a class="moz-txt-link-freetext" href="https://suricata.readthedocs.io/en/latest/performance/packet-capture.html">https://suricata.readthedocs.io/en/latest/performance/packet-capture.html</a>.<br>
</p>
<p>-David<br>
</p>
<br>
<div class="moz-cite-prefix">On 10/05/2018 11:54 AM, fatema
bannatwala wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACX0rUQJ8EOGOc8NBHAYNvbN6sTm20zVZP3WRPZKyL5p+Qg58Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">I would also be out next
week, so just have today for doing some
more troubleshooting before I get back.
<div><br>
<div>I captured the traffic generated
from a wifi host hitting <a
href="http://cnn.com"
moz-do-not-send="true">cnn.com</a>
with "SearchProtect" as UA: $ curl -A
"SearchProtect" <a
href="http://cnn.com"
moz-do-not-send="true">http://cnn.com</a></div>
<div>on both Snort and suricata sensors.</div>
<div>Amazingly they both captured exact
same size of pcap for that traffic.
Then I ran those pcaps through snort
and suricata in offline mode on
corresponding boxes.</div>
<div>They both fired the alerts (with
sid:2022813) and logged them in
fast/eve.json, with http logging
enabled in suricata produced http.log
file as well. </div>
<div><br>
</div>
<div>But when I run both in online
packet sniffing mode, and was doing
curl to produce traffic, only snort
fired the alerts and not suricata.</div>
<div><br>
</div>
<div>I use PF_ring with snort and
AF_packet with suricata sensors. So I
though maybe it's AF_Packet messing
with the flow oriented packets on
suricata, and hence tested it with
PF_ring, but no positive results.</div>
<div><br>
</div>
<div>I am attaching the captured pcaps
from snort/suricata sensors if that
is helpful.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Fatema.</div>
<div><br>
</div>
<div>P.S: Suricata relevant config
settings in suricata.yaml (followed
SepTune):</div>
<div><br>
</div>
<div>### Local Bypass enabled ###</div>
<div>
<div>stream:</div>
<div> memcap: 64mb </div>
<div> checksum-validation: no </div>
<div> inline: no </div>
<div> bypass: yes</div>
<div> reassembly:</div>
<div> memcap: 256mb </div>
<div> depth: 1mb </div>
<div> toserver-chunk-size: 2560</div>
<div> toclient-chunk-size: 2560</div>
<div> randomize-chunk-size: yes</div>
</div>
<div><br>
</div>
<div>### Threading ###</div>
<div>threading:<br>
</div>
<div>
<div> set-cpu-affinity: yes</div>
<div> cpu-affinity:<br>
</div>
<div> - management-cpu-set:</div>
<div> cpu: [ 0 ] # include
only these cpus in affinity settings</div>
<div> mode: "balanced"</div>
<div> prio:</div>
<div> default: "low" </div>
<div> - worker-cpu-set:<br>
</div>
<div> cpu: [
4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38
] # cpu 2 is pinned to Interrupts
hence not included in workers</div>
<div> mode: "exclusive"</div>
<div> prio:<br>
</div>
<div> default: "high"<br>
</div>
</div>
<div><br>
</div>
<div>#### AF Packet ####</div>
</div>
<div>
<div>af-packet:</div>
<div> - interface: em1</div>
</div>
<div> threads: 18<br>
</div>
<div> cluster-id: 99<br>
</div>
<div> cluster-type: cluster_flow<br>
</div>
<div> defrag: yes<br>
</div>
<div> use-mmap: yes<br>
</div>
<div> tpacket-v3: yes<br>
</div>
<div> ring-size: 200000<br>
</div>
<div> block-size: 65536<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Oct 5, 2018 at 5:30 AM Michał Purzyński
<<a href="mailto:michalpurzynski1@gmail.com"
moz-do-not-send="true">michalpurzynski1@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div dir="ltr">I’ve been living airport life recently but as
soon as I’m somewhere more permanent I’ll run this sample
and see what it tells me.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">It might be a capture bug indeed. I’d assume
that you use the same capture method for both snort and
Suri?</div>
<div dir="ltr"><br>
On Oct 4, 2018, at 11:31 PM, fatema bannatwala <<a
href="mailto:fatema.bannatwala@gmail.com"
target="_blank" moz-do-not-send="true">fatema.bannatwala@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div>I was able to do some troubleshooting today,
what's weird is, for a user-agent alert
(sid:2022813) I was able to generate traffic using
curl from my desktop, and snort triggered the alerts
for that traffic but no alerts in suricata.</div>
<div>But when I captured the traffic using tcpdump and
ran snort and suricata in offline mode reading from
that pcap, both triggered the alerts, which makes me
think that might be there are issues with the
mutli-threading with suricata.</div>
<div><br>
</div>
<div>I followed the SepTune doc to pin the IRQs to
housekeeping core as well as pinning interrupts to
separate core, of the same Numa, and using rest for
workers in suricata, but no positive result so far.</div>
<div><br>
</div>
<div>The issue I think is with how the multi-threading
is handled in packet sniffing mode from the
interface in suricata, and reordering of packets
before it's reaching suricata's engine.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Fatema.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Thu, Oct 4, 2018 at 5:10 PM Travis
Green <<a href="mailto:travis@travisgreen.net"
target="_blank" moz-do-not-send="true">travis@travisgreen.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I
was able to locate an exe making the request shown
above<br>
(f59cb3abb8ae0fb0fd626f86a75adff2), and I've also
found a pcap for it<br>
which you can download here: <a
href="https://reep.io/d/xo0rdnswuv"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://reep.io/d/xo0rdnswuv</a>
(password is<br>
"oisf-users").<br>
<br>
I've run it against Suricata versions 4.0.0, 3.2,
and 2.0.1 but sadly<br>
was not able to reproduce the false negative.
Results can be viewed<br>
here: <a
href="http://autoids.net/output/58408e977582ade6ed1e1efee27c9628"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://autoids.net/output/58408e977582ade6ed1e1efee27c9628</a><br>
<br>
Hope that helps,<br>
-Travis<br>
On Thu, Oct 4, 2018 at 8:06 AM fatema bannatwala<br>
<<a href="mailto:fatema.bannatwala@gmail.com"
target="_blank" moz-do-not-send="true">fatema.bannatwala@gmail.com</a>>
wrote:<br>
><br>
> Hi Michal,<br>
><br>
> Thanks for the pointers, will try to get some
malware samples, and see if we are still seeing any
cnc traffic from that host and if that can be
captured.<br>
> Meanwhile I will also enable eve http logging
and will compare it with bro http connections.<br>
><br>
> I will keep you posted.<br>
><br>
> Thanks,<br>
> Fatema.<br>
><br>
> On Thu, Oct 4, 2018 at 6:24 AM Michał Purzyński
<<a href="mailto:michalpurzynski1@gmail.com"
target="_blank" moz-do-not-send="true">michalpurzynski1@gmail.com</a>>
wrote:<br>
>><br>
>> Looks like we might have a bug here. I
agree that it seems like Suricata does not recognize
some HTTP traffic as HTTP.<br>
>><br>
>> Can I get samples of this malware
somewhere? I’d love to run it here. I can run full
packet capture for a week no problem.<br>
>><br>
>> Can you enable eve log type http?<br>
>><br>
>> <a
href="https://suricata.readthedocs.io/en/suricata-4.0.5/output/eve/eve-json-output.html"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://suricata.readthedocs.io/en/suricata-4.0.5/output/eve/eve-json-output.html</a><br>
>><br>
>> This would let us know if suricata indeed
fails to recognize traffic as http. It’s kind of
like bro http.log<br>
>><br>
>> Do you have enough resources to capture
traffic from infected host to internet?<br>
>><br>
>> On Oct 4, 2018, at 4:46 AM, Amar <<a
href="mailto:amar@countersnipe.com"
target="_blank" moz-do-not-send="true">amar@countersnipe.com</a>>
wrote:<br>
>><br>
>> Hello Fatema<br>
>><br>
>> I see your comment about contuing to use
Snort! If Snort works for you anyway, may I ask what
factors are driving you to look at/use Suricata in
the first place?<br>
>><br>
>> Regards<br>
>> Amar Rathore<br>
>> CounterSnipe Systems LLC<br>
>><br>
>><br>
>> On Oct 3, 2018 at 6:57 PM, <fatema
bannatwala> wrote:<br>
>><br>
>> Yet another example where no alerts fired
in Suricata but in Snort for legit bad traffic for
"Andromeda" Trojan.<br>
>><br>
>> Both the suri and snort signatures for
sid:2809682 are same, and yet only snort triggered
the alert for an outbound POST request to a domain
related to Andromeda Trojan.<br>
>> Bro detected those connections as http,
hence the application should be recognized by
Suricata as http.<br>
>><br>
>> Bro http log for the connection that
triggered snort alert:<br>
>> 10/2/18 7:06:46.734 PM CGOaPc2Kyn0xd3eGkd
128.x.x.x 58299 184.105.192.2 80 1 POST <a
href="http://atomictrivia.ru" rel="noreferrer"
target="_blank" moz-do-not-send="true">atomictrivia.ru</a>
/atomic.php - 1.1 Mozilla/4.0 64 0 200 OK - -
(empty) - - - FUR4T54aQNbHsxbG84<br>
>><br>
>> Snort alert for the same:<br>
>> Oct 2 19:06:47 snort[3664]: [1:2809682:3]
ETPRO TROJAN Andromeda/Gamarue Checkin
[Classification: A Network Trojan was Detected]
[Priority: 1]: {TCP} 128.x.x.x:58299 -> <a
href="http://184.105.192.2:80" rel="noreferrer"
target="_blank" moz-do-not-send="true">184.105.192.2:80</a><br>
>><br>
>> No Suricata alerts fired for the same.<br>
>><br>
>> The notification of this activity was sent
by a third party to us today, hence we are sure that
the host is compromised as it was trying to resolve
Andromeda domains.<br>
>><br>
>> I can't capture the pcap for the traffic
that triggers snort alerts but not Suri, as it is
sporadic, and only couple of minutes of traffic
capture results in gigs of traffic, hence I can't
just keep running pcap capture for a long period of
time on the sensors.<br>
>> If I can't figure out what is going on with
Suri not firing the alerts, then we just might have
to drop Suricata deployment in prod and keep working
with Snort.<br>
>><br>
>> Any pointers/suggestions?<br>
>><br>
>> Thanks,<br>
>> Fatema.<br>
>> Event Actions<br>
>><br>
>> On Tue, Sep 25, 2018 at 12:05 PM fatema
bannatwala <<a
href="mailto:fatema.bannatwala@gmail.com"
target="_blank" moz-do-not-send="true">fatema.bannatwala@gmail.com</a>>
wrote:<br>
>>><br>
>>> I tried to capture some traffic, but
those pcaps aren't triggering any alerts in both
snort and suricata, have to work on getting some
pcap with some traffic that would be malicious and
could trigger alerts.<br>
>>> Meanwhile, was looking into the alerts
that were triggered in Snort and not in Suricata for
last 15 minutes on live servers, and did the
following analysis:<br>
>>><br>
>>> Example of few alerts triggered in
snort but not in suricata: sid: 2022813, 2008974,
2009714<br>
>>> when I looked at the above alert rules
defined in ET ruleset for snort and ET ruleset for
suricata,<br>
>>> the only major difference found is in
the protocol defined in both alerts, i.e. :<br>
>>><br>
>>> suricata alert 2022813 definition:<br>
>>> alert http $HOME_NET any ->
$EXTERNAL_NET any (msg:"ET MALWARE SearchProtect PUA
User-Agent Observed"; flow:established,to_server;
content:"SearchProtect|3b|";<br>
>>> depth:14; http_user_agent;
reference:md5,34e2350c2ed6a9a9e9d444102ae4dd87;
classtype:trojan-activity; sid:2022813; rev:2;
metadata:created_at 2016_05_17, updated_at
2016_05_17;)<br>
>>><br>
>>> snort alert 2022813 definition:<br>
>>> alert tcp $HOME_NET any ->
$EXTERNAL_NET $HTTP_PORTS (msg:"ET MALWARE
SearchProtect PUA User-Agent Observed";
flow:established,to_server; content:"User-Agent|3a
20|SearchProtect|3b|";<br>
>>> fast_pattern; http_header;
reference:md5,34e2350c2ed6a9a9e9d444102ae4dd87;
classtype:trojan-activity; sid:2022813; rev:1;
metadata:created_at 2016_05_17, updated_at
2016_05_17;)<br>
>>><br>
>>> And from snort alert logs, the packet
content that triggered that 2022813 alert:<br>
>>><br>
>>> [1:2022813:1] ET MALWARE SearchProtect
PUA User-Agent Observed<br>
>>> 2018-09-25 11:09:39.337000-04:00 <a
href="http://128.164.63.89:51872" rel="noreferrer"
target="_blank" moz-do-not-send="true">128.164.63.89:51872</a>
-> <a href="http://54.243.209.194:80"
rel="noreferrer" target="_blank"
moz-do-not-send="true">54.243.209.194:80</a><br>
>>> TCP: Data Triggering Snort Rule: POST /
HTTP/1.1::~~Content-Type:
application/json::~~Accept: */*::~~User-Agent:
SearchProtect;3.0.50.0;Microsoft Windows 7
Enterprise;SPC0AFF85F-9E31-44AC-8E1C-61C39CDE89DC::~~Host:
<a href="http://sp-alive-msg.databssint.com"
target="_blank" moz-do-not-send="true">sp-alive-msg.databssint.com</a>::~~Content-Length:
2157::~~Connection: Keep-Alive::~~Cache-Control:
no-cache::~~::~~<br>
>>> [Xref => md5
34e2350c2ed6a9a9e9d444102ae4dd87]<br>
>>><br>
>>> Hence, looking at the contents of the
above data triggering log, looks like it matches the
Suricata rule signature as well, except not sure if
the protocol detected was actually http or not, and
hence Suricata alert might not have trigged for the
same content.<br>
>>> Other alerts that weren't triggered in
Suricata were also having "http" in place of "tcp"
in the rule signatures, when compared with snort
rule signatures. Hence my guess is Suricata isn't
able to detect http protocol for the same traffic
and hence not triggering the alerts.<br>
>>><br>
>>> Thanks,<br>
>>> Fatema.<br>
>>><br>
>>><br>
>>> On Tue, Sep 25, 2018 at 12:13 AM Michał
Purzyński <<a
href="mailto:michalpurzynski1@gmail.com"
target="_blank" moz-do-not-send="true">michalpurzynski1@gmail.com</a>>
wrote:<br>
>>>><br>
>>>> It would be really useful to have
some data we could work on. You can always share
pcaps with developers only, subject to your
company's policy.<br>
>>>><br>
>>>> One more thing you could do without
sharing traffic is to verify if these cases when
snort matches a signature A and Suricata does not,
it is a false positive or a true positive.<br>
>>>><br>
>>>> That would be a great start.<br>
>>>><br>
>>>><br>
>>>> On Mon, Sep 24, 2018 at 2:59 PM
fatema bannatwala <<a
href="mailto:fatema.bannatwala@gmail.com"
target="_blank" moz-do-not-send="true">fatema.bannatwala@gmail.com</a>>
wrote:<br>
>>>>><br>
>>>>> Hmm, makes sense, was just
curious to know what happens when snort ruleset was
fed to Suricata,<br>
>>>>> and to produce a baseline for
the initial test environment to see if the important
alerts are not missed by Suricata once deployed in
prod.<br>
>>>>> Hence was trying to keep the
rulesets same for both for an even comparison..<br>
>>>>><br>
>>>>> Thanks!<br>
>>>>> Fatema.<br>
>>>>><br>
>>>>> On Mon, Sep 24, 2018 at 4:29 PM
Michael Shirk <<a
href="mailto:shirkdog.bsd@gmail.com"
target="_blank" moz-do-not-send="true">shirkdog.bsd@gmail.com</a>>
wrote:<br>
>>>>>><br>
>>>>>> The issue is that the
engines are different, so Snort signatures from<br>
>>>>>> VRT/Talos, even ET-Pro
written for the Snort detection engine are only<br>
>>>>>> tested with Snort. There
was a good presentation by Dave Wharton at<br>
>>>>>> SuriCon 2016 about the
subtle differences that can cause signatures<br>
>>>>>> written for either engine
to not work in the other. Digging into the<br>
>>>>>> specifics of a signature
that works in Snort but does not work in<br>
>>>>>> Suricata may highlight a
similar issue.<br>
>>>>>><br>
>>>>>> At least from what I have
seen, similar to the issue you had with<br>
>>>>>> pulledpork using a Snort
signature set with a Suricata signature set,<br>
>>>>>> I believe the user base
selects one detection engine over the other.<br>
>>>>>> The community will send
emails with new detections that can end up in<br>
>>>>>> the emerging threats
signatures, as well as the community based Snort<br>
>>>>>> rules, but specific to one
of the engines.<br>
>>>>>> On Mon, Sep 24, 2018 at
4:18 PM fatema bannatwala<br>
>>>>>> <<a
href="mailto:fatema.bannatwala@gmail.com"
target="_blank" moz-do-not-send="true">fatema.bannatwala@gmail.com</a>>
wrote:<br>
>>>>>> ><br>
>>>>>> > Hmm, don't want to
start Suricata in IPS mode, as it's configured to
sniff traffic through a tap and should really be
running as an IDS.<br>
>>>>>> > Not sure if the
triggering of alerts would depend on mode though,
but I might be wrong..<br>
>>>>>> ><br>
>>>>>> > On Mon, Sep 24, 2018
at 3:41 PM Albert Whale <<a
href="mailto:Albert.Whale@it-security-inc.com"
target="_blank" moz-do-not-send="true">Albert.Whale@it-security-inc.com</a>>
wrote:<br>
>>>>>> >><br>
>>>>>> >> So what happens if
you start Suricata in IPS Mode?<br>
>>>>>> >><br>
>>>>>> >><br>
>>>>>> >> On 9/24/18 2:17
PM, fatema bannatwala wrote:<br>
>>>>>> >><br>
>>>>>> >> Hi Albert,<br>
>>>>>> >><br>
>>>>>> >> I am running
Suricata in IDS mode.<br>
>>>>>> >><br>
>>>>>> >> Thanks,<br>
>>>>>> >> Fatema.<br>
>>>>>> >><br>
>>>>>> >> On Mon, Sep 24,
2018 at 2:11 PM Albert E Whale <<a
href="mailto:Albert.Whale@it-security-inc.com"
target="_blank" moz-do-not-send="true">Albert.Whale@it-security-inc.com</a>>
wrote:<br>
>>>>>> >>><br>
>>>>>> >>> Hi Fatema,<br>
>>>>>> >>><br>
>>>>>> >>> I’m curious,
are running Suricata in IDS or IPS mode?<br>
>>>>>> >>><br>
>>>>>> >>> I am
experiencing significant issues with IPS on a small
home office environment.<br>
>>>>>> >>><br>
>>>>>> >>> Sent from my
iPhone<br>
>>>>>> >>><br>
>>>>>> >>> > On Sep
24, 2018, at 1:26 PM, fatema bannatwala <<a
href="mailto:fatema.bannatwala@gmail.com"
target="_blank" moz-do-not-send="true">fatema.bannatwala@gmail.com</a>>
wrote:<br>
>>>>>> >>> ><br>
>>>>>> >>> > Hi All,<br>
>>>>>> >>> ><br>
>>>>>> >>> > I am
working on getting Suricata up and running with same
rulesets as we have for snort.<br>
>>>>>> >>> > Hence
running Suricata with both VRT open source free
ruleset from Cisco as well as with ET-PRO rule sets
from Proofpoint for suricatav4.0.4.<br>
>>>>>> >>> ><br>
>>>>>> >>> > When I
start Suricata it gives some errors for around 200
VRT rules concerning
Invalid_Signature/Unknown_Keyword, which make sense
as they are not designed to be run with Suricata.
But Suricata starts up correctly and works fine
inspite of those rule errors.<br>
>>>>>> >>> ><br>
>>>>>> >>> > My
concern is, the number of unique alerts that get
triggered in Snort are more than the unique alerts
triggered in Suricata, even though both are getting
same traffic flow. The difference is huge, i.e. 241
unique Snort alerts compared to only 94 unique
alerts in Suricata.<br>
>>>>>> >>> ><br>
>>>>>> >>> > When did
an analysis, the difference is between ETPRO alerts
as well as VRT alerts that are triggered in both.
And confirmed that the sids that are getting
triggered in snort are also enabled in suricata, but
still no suricata alerts for those sids.<br>
>>>>>> >>> ><br>
>>>>>> >>> > Hence, my
question is why there is this discrepancy in the
alerts that get triggered in snort and not in
suricata even when they both are seeing the same
traffic and have same sids enabled?<br>
>>>>>> >>> ><br>
>>>>>> >>> > P.S My
initial thought was, either it's because of capture
loss in suricata (which is <0.1%), or maybe
because of some of those incompatible VRT alerts
that are enabled in Suricata, and it is not able to
work correctly because of those.<br>
>>>>>> >>> ><br>
>>>>>> >>> > Has
anyone tried this kind on config before?<br>
>>>>>> >>> ><br>
>>>>>> >>> > Thanks,<br>
>>>>>> >>> > Fatema.<br>
>>>>>> >>> ><br>
>>>>>> >>> ><br>
>>>>>> >>> >
_______________________________________________<br>
>>>>>> >>> > Suricata
IDS Users mailing list: <a
href="mailto:oisf-users@openinfosecfoundation.org"
target="_blank" moz-do-not-send="true">oisf-users@openinfosecfoundation.org</a><br>
>>>>>> >>> > Site: <a
href="http://suricata-ids.org" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://suricata-ids.org</a>
| Support: <a
href="http://suricata-ids.org/support/"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://suricata-ids.org/support/</a><br>
>>>>>> >>> > List: <a
href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
>>>>>> >>> ><br>
>>>>>> >>> >
Conference: <a href="https://suricon.net"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://suricon.net</a><br>
>>>>>> >>> >
Trainings: <a
href="https://suricata-ids.org/training/"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://suricata-ids.org/training/</a><br>
>>>>>> >>><br>
>>>>>> >><br>
>>>>>> >> --<br>
>>>>>> >> --<br>
>>>>>> >><br>
>>>>>> >> Albert E. Whale,
CEH CHS CISA CISSP<br>
>>>>>> >> President - Chief
Security Officer<br>
>>>>>> >> IT Security, Inc.
- A Service Disabled Veteran Owned Company -
(SDVOSB)<br>
>>>>>> >> HUBZone Certified<br>
>>>>>> >> LinkedIn Profile<br>
>>>>>> >><br>
>>>>>> >><br>
>>>>>> >> Phone:
412-515-3010 | Email: <a
href="mailto:Albert.Whale@IT-Security-inc.com"
target="_blank" moz-do-not-send="true">Albert.Whale@IT-Security-inc.com</a><br>
>>>>>> >> Cell: 412-889-6870<br>
>>>>>> >><br>
>>>>>> >
_______________________________________________<br>
>>>>>> > Suricata IDS Users
mailing list: <a
href="mailto:oisf-users@openinfosecfoundation.org"
target="_blank" moz-do-not-send="true">oisf-users@openinfosecfoundation.org</a><br>
>>>>>> > Site: <a
href="http://suricata-ids.org" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://suricata-ids.org</a>
| Support: <a
href="http://suricata-ids.org/support/"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://suricata-ids.org/support/</a><br>
>>>>>> > List: <a
href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
>>>>>> ><br>
>>>>>> > Conference: <a
href="https://suricon.net" rel="noreferrer"
target="_blank" moz-do-not-send="true">https://suricon.net</a><br>
>>>>>> > Trainings: <a
href="https://suricata-ids.org/training/"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://suricata-ids.org/training/</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Michael Shirk<br>
>>>>>> Daemon Security, Inc.<br>
>>>>>> <a
href="https://www.daemon-security.com"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://www.daemon-security.com</a><br>
>>>>><br>
>>>>>
_______________________________________________<br>
>>>>> Suricata IDS Users mailing
list: <a
href="mailto:oisf-users@openinfosecfoundation.org"
target="_blank" moz-do-not-send="true">oisf-users@openinfosecfoundation.org</a><br>
>>>>> Site: <a
href="http://suricata-ids.org" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://suricata-ids.org</a>
| Support: <a
href="http://suricata-ids.org/support/"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://suricata-ids.org/support/</a><br>
>>>>> List: <a
href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
>>>>><br>
>>>>> Conference: <a
href="https://suricon.net" rel="noreferrer"
target="_blank" moz-do-not-send="true">https://suricon.net</a><br>
>>>>> Trainings: <a
href="https://suricata-ids.org/training/"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://suricata-ids.org/training/</a><br>
>><br>
>>
_______________________________________________<br>
>> Suricata IDS Users mailing list: <a
href="mailto:oisf-users@openinfosecfoundation.org"
target="_blank" moz-do-not-send="true">oisf-users@openinfosecfoundation.org</a><br>
>> Site: <a href="http://suricata-ids.org"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://suricata-ids.org</a>
| Support: <a
href="http://suricata-ids.org/support/"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://suricata-ids.org/support/</a><br>
>> List: <a
href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
>><br>
>> Conference: <a href="https://suricon.net"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://suricon.net</a><br>
>> Trainings: <a
href="https://suricata-ids.org/training/"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://suricata-ids.org/training/</a><br>
><br>
> _______________________________________________<br>
> Suricata IDS Users mailing list: <a
href="mailto:oisf-users@openinfosecfoundation.org"
target="_blank" moz-do-not-send="true">oisf-users@openinfosecfoundation.org</a><br>
> Site: <a href="http://suricata-ids.org"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://suricata-ids.org</a>
| Support: <a
href="http://suricata-ids.org/support/"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://suricata-ids.org/support/</a><br>
> List: <a
href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
><br>
> Conference: <a href="https://suricon.net"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://suricon.net</a><br>
> Trainings: <a
href="https://suricata-ids.org/training/"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://suricata-ids.org/training/</a><br>
<br>
<br>
<br>
-- <br>
PGP: ABE625E6<br>
<a href="http://keybase.io/travisbgreen"
rel="noreferrer" target="_blank"
moz-do-not-send="true">keybase.io/travisbgreen</a><br>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Suricata IDS Users mailing list: <a class="moz-txt-link-abbreviated" href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@openinfosecfoundation.org</a>
Site: <a class="moz-txt-link-freetext" href="http://suricata-ids.org">http://suricata-ids.org</a> | Support: <a class="moz-txt-link-freetext" href="http://suricata-ids.org/support/">http://suricata-ids.org/support/</a>
List: <a class="moz-txt-link-freetext" href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a>
Conference: <a class="moz-txt-link-freetext" href="https://suricon.net">https://suricon.net</a>
Trainings: <a class="moz-txt-link-freetext" href="https://suricata-ids.org/training/">https://suricata-ids.org/training/</a></pre>
</blockquote>
<br>
</body>
</html>