<div dir="ltr"><div dir="ltr">
<i>alert ip any ![25,465,587] -> any any (msg:"SURICATA Applayer Detect protocol<br></i><div><i>
only one direction (non-SMTP)</i></div><div><br></div><div>Just make sure you double-check that traffic on those ports are actually SMTP; otherwise you just whitelisted them to SSH, TOR, Bitorrent, etc.</div><div><br></div><div>Saying this because most of my alerts from "
Applayer Detect protocol only one direction" are from BT traffic.</div><div><br></div><div>Cheers.</div><div><br></div><div>F.<br>

</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 25, 2019 at 1:44 PM Orion Poplawski <<a href="mailto:orion@nwra.com" target="_blank">orion@nwra.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 1/25/19 2:39 AM, Peter Manev wrote:<br>
> On Tue, Jan 22, 2019 at 9:50 PM Orion Poplawski <<a href="mailto:orion@nwra.com" target="_blank">orion@nwra.com</a>> wrote:<br>
>><br>
>> We're running suricata (4.1.2_1 and 4.0.13_6) on our pfSense boxes.  Recently<br>
>> (about the 12th or 13th it seems) we've started getting lots of "SURICATA<br>
>> Applayer Mismatch protocol both directions" and "SURICATA Applayer Detect<br>
>> protocol only one direction" alerts.<br>
>><br>
>> Most of the "one direction" alerts seem to be for SMTP traffic - which<br>
>> according to <a href="https://suricata.readthedocs.io/en/latest/rules/app-layer.html" rel="noreferrer" target="_blank">https://suricata.readthedocs.io/en/latest/rules/app-layer.html</a> is<br>
>> expected.  Any reason not to exclude ports 25, 465, 587 from these rules?<br>
>><br>
> <br>
> you can try excluding it and see/feedback how it goes?<br>
<br>
Okay, I'm trying with the following custom rule instead:<br>
<br>
alert ip any ![25,465,587] -> any any (msg:"SURICATA Applayer Detect protocol<br>
only one direction (non-SMTP)"; flow:established;<br>
app-layer-event:applayer_detect_protocol_only_one_direction;<br>
flowint:applayer.anomaly.count,+,1; classtype:protocol-command-decode;<br>
sid:324000010; rev:1;)<br>
<br>
it does look like it immediately dropped the detections.  I'll let it run for<br>
a while.<br>
<br>
>> Most of the "both directions" messages seem to be for SMB port 445 traffic.<br>
>> Did something change recently for this kind of traffic?<br>
>><br>
<br>
After looking at things a bit closer, it seems like these alerts are only<br>
coming from the suricata 4.0.13 machines - so perhaps there was an issue that<br>
was fixed later, or that this rule is not appropriate for that version of<br>
suricata.<br>
<br>
<br>
-- <br>
Orion Poplawski<br>
Manager of NWRA Technical Systems          720-772-5637<br>
NWRA, Boulder/CoRA Office             FAX: 303-415-9702<br>
3380 Mitchell Lane                       <a href="mailto:orion@nwra.com" target="_blank">orion@nwra.com</a><br>
Boulder, CO 80301                 <a href="https://www.nwra.com/" rel="noreferrer" target="_blank">https://www.nwra.com/</a><br>
<br>
_______________________________________________<br>
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">oisf-users@openinfosecfoundation.org</a><br>
Site: <a href="http://suricata-ids.org" rel="noreferrer" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/support/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
<br>
Conference: <a href="https://suricon.net" rel="noreferrer" target="_blank">https://suricon.net</a><br>
Trainings: <a href="https://suricata-ids.org/training/" rel="noreferrer" target="_blank">https://suricata-ids.org/training/</a></blockquote></div></div>