Check IP Information via Web Service
Robert Ullrich31. Jul 2018 | Case studyConsultingCyber SecurityUse cases
The practical examples presented in our technical blog (blog.otrs.com) and now in the expert category in our FAQ blog section serve as a source of ideas and documentation to show what is theoretically possible with OTRS in concrete scenarios or sometimes even for more exotic configurations. All configurations presented here were developed under laboratory conditions as a proof of concept.
We can only guarantee testing and implementation of these concepts to be error-free and productive if implemented in a workshop with one of our OTRS consultants. Without this, the responsibility lies with the customer himself. Please note that configurations from older OTRS versions may not work in the newer ones.
“STORM powered by OTRS” is used in IT security departments and companies for a long time due to the well-documented code of OTRS and a huge background in the CERT area.
In one of my recent projects, the team wanted to simplify their investigation activities. We decided to use an external API to request information for specific data we send. Until now they’re copying this information manually into STORM.
In part 1 of this small blog article series, I want to show you how to request additional information for an IP which triggered a security incident in an external system. Because I’m using the NeutrinoAPI, I’m calling this web service NeutrinoAPIConnector.
We have some pre-requirements:
- Go to https://www.neutrinoapi.com/ and register a new account
- Choose a plan. I’m using the “Free” plan for this example
- Note your API key. You can also change it later if you’ve forgotten to note it.
My customer is using “STORM powered by OTRS” with the OTRS Feature Add-On “OTRSTicketInvoker”.
In addition, we need two dynamic fields in OTRS:
- IPAddress – Text – used to specify which IP should be checked
- IPAddressInformation – TextArea – to store the response of NeutrinoAPI
Configuring the NeutrinoAPIConnector in STORM
As always we need a new web service in STORM. Call it “NeutrinoAPIConnector”:
Now we need a new invoker, to send requests to NeutrinoAPI:
As you can see I removed everything, except the dynamic field “IPAddress” from my outgoing request data, because I want to keep my payload small.
The next point is the XSLT mapping for our outgoing request and incoming response data:
Outgoing XSLT mapping:
Incoming XSLT mapping:
We should define the dynamic field “IPAddressInformation” to store the NeutrinoAPI response. The last point for the invoker is the used event trigger. I’m using the event “TicketDynamicFieldUpdate_IPAddress” because it makes the most sense in my scenario:
Next point is to configure the network transport. It’s an easy job:
The used endpoint is “https://neutrinoapi.com”, the controller mapping “/ip-info” and the request method is “POST”. You’ll also find this information in the NeutrinoAPI API documentation.
Testing the NeutrinoAPIConnector
Depending on your configured event trigger for the invoker, use a valid IP address in the dynamic field “IPAddress”. You should now see something similar in the web service debug log:
In the ticket history, we can now see that the value was stored in the dynamic field “IPAddressInformation”:
More information about the Language Detection API
Please go to the following website, if you need more information: NeutrinoAPI API documentation.