# Grok Filter Pattern Hostname OR IP

**URL:** <https://discuss.elastic.co/t/grok-filter-pattern-hostname-or-ip/200768>\
**Category:** Logstash\
**Created:** [September 23, 2019, 10:40pm UTC](https://discuss.elastic.co/t/grok-filter-pattern-hostname-or-ip/200768 "2019-09-23T22:40:49Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![mgotechlock](https://avatars.discourse-cdn.com/v4/letter/m/dc4da7/32.png) [@mgotechlock](https://discuss.elastic.co/u/mgotechlock)\
**Post date:** [September 23, 2019, 10:40pm UTC](https://discuss.elastic.co/t/grok-filter-pattern-hostname-or-ip/200768/1 "2019-09-23T22:40:50Z")

</div>

Newb question. Parsing a Cisco ASA log. I've noticed some of my logs don't match the built in parsers. Here is one in particular, 305011.  
This is the default pattern.  
CISCOFW305011 %{CISCO\_ACTION:action} %{CISCO\_XLATE\_TYPE:xlate\_type} %{WORD:protocol} translation from %{DATA:src\_interface}:%{IP:src\_ip}(/%{INT:src\_port})?((%{DATA:src\_fwuser}))? to %{DATA:src\_xlated\_interface}:%{IP:src\_xlated\_ip}/%{DATA:src\_xlated\_port}

My log that fails to parse looks like  
{"message":"\<166\>Sep 23 2019 16:14:47 xxx-fw-p01 : %ASA-6-305011: Built dynamic TCP translation from outside:10.1.1.27/49387(LOCAL\smeyer) to outside:outside-asa/49387\n","host":"99.99.99.51","@version":"1","tags":["\_grokparsefailure"],"@timestamp":"2019-09-23T21:16:07.514Z"}

From using [http://grokdebug.herokuapp.com/](http://grokdebug.herokuapp.com/), I deduced that it fails to match because, for example, the filter is looking for an IP when the log presents a hostname. I managed to get it to match if I change the end of the filter to %{WORD:src\_xlated\_interface}:%{DATA:src\_xlated\_ip}/%{INT:src\_xlated\_port} instead of %{DATA:src\_xlated\_interface}:%{IP:src\_xlated\_ip}/%{DATA:src\_xlated\_port}.

I would not have expected to need to edit the built in patterns. Plus, I have no idea if the second Cisco ASA I log to it might match the 1st or the 2nd pattern. I don't particularly want to manage multiple permutations of every possible pattern. Do other people have this problem? Are people editing the built in patterns?

---

<div class="post-metadata">

**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\
**Post date:** [September 23, 2019, 11:03pm UTC](https://discuss.elastic.co/t/grok-filter-pattern-hostname-or-ip/200768/2 "2019-09-23T23:03:47Z")

</div>

You can replace %{IP:someField} with %{IPORHOST:someField} so that it will match an IP first and if that fails a HOSTNAME.

That said, I am very, very, very surprised that a firewall would log a name in preference to an IP address, since it places a huge reliance on DNS working properly.

Thinking about that, is it possible you have the mapping configured with a name when the best practice is to use an IP? If you do not understand why mapping to a name might be a bad idea you should probably stop doing it.

---

<div class="post-metadata">

**Author:** ![mgotechlock](https://avatars.discourse-cdn.com/v4/letter/m/dc4da7/32.png) [@mgotechlock](https://discuss.elastic.co/u/mgotechlock)\
**Post date:** [September 24, 2019, 12:40am UTC](https://discuss.elastic.co/t/grok-filter-pattern-hostname-or-ip/200768/3 "2019-09-24T00:40:50Z")

</div>

IPORHOST would work for the IP or Hostname problem. But it doesnt solve the other fields that I had to change from DATA to WORD or DATA to INT. However, I didn't know about IPORHOST so that was helpful.

Unfortunately, I do not have control over the firewall conventions. I have to take the logs as I get them.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [October 22, 2019, 12:48am UTC](https://discuss.elastic.co/t/grok-filter-pattern-hostname-or-ip/200768/4 "2019-10-22T00:48:07Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
