# Suricata 5.0.1 in IPS mode

**URL:** <https://forum.suricata.io/t/suricata-5-0-1-in-ips-mode/94>\
**Category:** Help\
**Tags:** ips\
**Created:** [March 21, 2020, 6:10pm UTC](https://forum.suricata.io/t/suricata-5-0-1-in-ips-mode/94 "2020-03-21T18:10:19Z")\
**Posts on this page:** 10\
**Page:** 2

<div class="post-metadata">

**Author:** ![LazaroCruz](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/lazarocruz/32/44_2.png) [@LazaroCruz](https://forum.suricata.io/u/LazaroCruz)\
**Post date:** [March 26, 2020, 3:10pm UTC](https://forum.suricata.io/t/suricata-5-0-1-in-ips-mode/94/21 "2020-03-26T15:10:20Z")

</div>

Here I attach both the pcap of the ok case and the failed one, because I have noticed that for the ok case when retrying the download, this is completed.

[ok\_case.pcap](https://forum.suricata.io/uploads/short-url/3vcY0oUlgky5TJ3Da7En0XTkDJc.pcap) (104.4 KB)  
[failing\_case.pcap](https://forum.suricata.io/uploads/short-url/p6g7Vx6Ab1sYV8IN7NFQ8pLyZya.pcap) (250.4 KB)

---

<div class="post-metadata">

**Author:** ![vjulien](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/vjulien/32/4_2.png) [@vjulien](https://forum.suricata.io/u/vjulien)\
**Post date:** [March 26, 2020, 7:17pm UTC](https://forum.suricata.io/t/suricata-5-0-1-in-ips-mode/94/22 "2020-03-26T19:17:16Z")

</div>

This is interesting. The one that isn’t successfully blocked is blocked at first. You can see the retransmissions at the end of the stream here:

 ![Screenshot from 2020-03-26 20-10-12](https://canada1.discourse-cdn.com/flex030/uploads/suricata/original/1X/16105b42c543f52695541d2aa4f969896e3371a8.png)

Then Firefox finds that the stream timed out and retries, fetching only the missing data. For this it uses byte-ranges support. This is currently not supported by Suricata, but in development.

 ![Screenshot from 2020-03-26 20-10-42](https://canada1.discourse-cdn.com/flex030/uploads/suricata/original/1X/fba3f50f29f8956bdf2410b56570392bcac934a2.png)

See: [https://redmine.openinfosecfoundation.org/issues/1576](https://redmine.openinfosecfoundation.org/issues/1576)

---

<div class="post-metadata">

**Author:** ![LazaroCruz](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/lazarocruz/32/44_2.png) [@LazaroCruz](https://forum.suricata.io/u/LazaroCruz)\
**Post date:** [March 30, 2020, 3:03am UTC](https://forum.suricata.io/t/suricata-5-0-1-in-ips-mode/94/23 "2020-03-30T03:03:45Z")

</div>

I will momentarily use this option:

```
drop IP any any -> any any (msg:"Malicious file detected"; content:"GET"; http_method; content:"www.example.com"; uricontent:"/examples/malware_sample.exe"; priority:1; sid:1; rev:2;)
```

---

<div class="post-metadata">

**Author:** ![vjulien](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/vjulien/32/4_2.png) [@vjulien](https://forum.suricata.io/u/vjulien)\
**Post date:** [April 1, 2020, 3:03pm UTC](https://forum.suricata.io/t/suricata-5-0-1-in-ips-mode/94/24 "2020-04-01T15:03:48Z")

</div>

One other thing to try is to use `xbits` to drop the byte-range 206 response. This would look something like:

```auto
alert http any any -> any any (msg:"File stored: EXE"; fileext:"exe"; filestore; sid:1; rev:1;)

# Drop file based on hash and tag the IP-Pair for an hour.
drop http any any -> any any (msg:"Malicious file detected"; filesha256:/etc/suricata/blacklist.sha-2; xbits:set, blocked_http, track ip_pair, expire 3600; sid:2; rev:2;)

# drop 206 response for the IP-Pair in which we already dropped before.
drop http any any -> any any (msg:"Block 206 response for IPPair"; content:"206"; http_stat_code; xbits:isset, blocked_http, track ip_pair; priority:1; sid:3; rev:1;)

```

---

<div class="post-metadata">

**Author:** ![LazaroCruz](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/lazarocruz/32/44_2.png) [@LazaroCruz](https://forum.suricata.io/u/LazaroCruz)\
**Post date:** [April 2, 2020, 2:38am UTC](https://forum.suricata.io/t/suricata-5-0-1-in-ips-mode/94/25 "2020-04-02T02:38:44Z")

</div>

Yes, with this the file drop works perfectly after retry download. To perform this test, I had to pause the download the first time to give the filesha256 rule time to run, otherwise, as we already knew, the file ends up downloaded

---

<div class="post-metadata">

**Author:** ![vjulien](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/vjulien/32/4_2.png) [@vjulien](https://forum.suricata.io/u/vjulien)\
**Post date:** [April 3, 2020, 11:52am UTC](https://forum.suricata.io/t/suricata-5-0-1-in-ips-mode/94/26 "2020-04-03T11:52:07Z")

</div>

I don’t understand the pausing requirement. I thought before we had established that the initial download passes the file except for the last chunk of data. That is then dropped, but as firefox retries with byte-range support it is able to download the last missing part. Are you saying this is incorrect?

If so, can you share another pcap to show how it is passed through?

---

<div class="post-metadata">

**Author:** ![LazaroCruz](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/lazarocruz/32/44_2.png) [@LazaroCruz](https://forum.suricata.io/u/LazaroCruz)\
**Post date:** [April 3, 2020, 8:26pm UTC](https://forum.suricata.io/t/suricata-5-0-1-in-ips-mode/94/27 "2020-04-03T20:26:30Z")

</div>

No, what I’m trying to say is that in the pcap everything seems to be correct, but in practice, the rule “Block 206 Response for IPPair” works, but the “Malicious file detected” rule as I said previously only works with very small files (76K), and sometimes not even that, and it is that by the time the log of this rule is shown (in fast.log) the file has finished downloading a few seconds before, that is why the pause test, to allow time for rules to run.

---

<div class="post-metadata">

**Author:** ![vjulien](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/vjulien/32/4_2.png) [@vjulien](https://forum.suricata.io/u/vjulien)\
**Post date:** [April 4, 2020, 11:22am UTC](https://forum.suricata.io/t/suricata-5-0-1-in-ips-mode/94/28 "2020-04-04T11:22:50Z")

</div>

What do your libhtp settings look like in your `suricata.yaml`?

```auto
      libhtp:
         default-config:
           personality: IDS

           # Can be specified in kb, mb, gb. Just a number indicates
           # it's in bytes.
           request-body-limit: 100kb
           response-body-limit: 100kb

```

By default the body is tracked for max `100KiB`. Can you try setting it to `0` (unlimited)?

---

<div class="post-metadata">

**Author:** ![LazaroCruz](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/lazarocruz/32/44_2.png) [@LazaroCruz](https://forum.suricata.io/u/LazaroCruz)\
**Post date:** [April 4, 2020, 4:54pm UTC](https://forum.suricata.io/t/suricata-5-0-1-in-ips-mode/94/29 "2020-04-04T16:54:59Z")

</div>

😃 😃 😃 With this now if everything works !!! 😃 😃 😃

Thank you very much for everything.

Here I share the summary of all the elements present in the answers that were necessary for the solution:

(1) Suricata version: 5.0.2

(2) In the configuration file: suricata.yaml

```
file-store:
   version: 2
   enabled: yes
   #dir: filestore
   #write-fileinfo: no
   #force-filestore: no
   stream-depth: 0

```

* * *

```
libhtp:
   default-config:
      personality: IDS
      request-body-limit: 0
      response-body-limit: 0

```

(3) Rules:

```
alert http any any -> any any (msg:"File stored: EXE"; fileext:"exe"; filestore; sid:1; rev:1;)
drop http any any -> any any (msg:"Malicious file detected"; filesha256:/etc/suricata/blacklist.sha-2; xbits:set, blocked_http, track ip_pair, expire 3600; sid:2; rev:2;)
drop http any any -> any any (msg:"Block 206 response for IPPair"; content:"206"; http_stat_code; xbits:isset, blocked_http, track ip_pair; priority:1; sid:3; rev:1;)

```

Thanks for everything one more time.

---

<div class="post-metadata">

**Author:** ![vjulien](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/vjulien/32/4_2.png) [@vjulien](https://forum.suricata.io/u/vjulien)\
**Post date:** [April 4, 2020, 6:13pm UTC](https://forum.suricata.io/t/suricata-5-0-1-in-ips-mode/94/30 "2020-04-04T18:13:36Z")

</div>

Great, thanks for your patience and the nice summary 🙂

[Previous page](https://forum.suricata.io/t/suricata-5-0-1-in-ips-mode/94.md?page=1)
