OK - an attacker is characterized by being an anonymus. What if somebody registers regularly, then turns into an attacker? This happens quite often, e.g. if an employee is fired or feels treated badly, and he wants to damage his employer. Then, the attacker is not anonymus - we might be able to use some machine learning algorithms to finde that out - e.g. classification.
Best regards, Frank Am Mo., 13. Mai 2019 um 08:44 Uhr schrieb Nadee Poornima <nad...@wso2.com>: > Hi Frank, > > Sure, you get information *about* the attacker from such headers. But how >> do we *detect* (!) an attack - also from headers? Or do you have a >> catalogue of IP addresses that are allowed to use the API (then, detection >> would be simple)... >> >> > In here we have deployed an API in GW but that doesn't see in Publisher or > Store UI. Then once arrived a hacker, they could able to see this API also > (as a service) and they will try to invoke that API also. Then that > invocation will detect by us an anonymous invocation and provide an alert > to system admins. That's how to detect anonymous users arrived in APIM. > > Thank you & regards, > Nadee > > On Sat, May 11, 2019 at 5:35 PM Frank Leymann <fr...@wso2.com> wrote: > >> Sure, you get information *about* the attacker from such headers. But >> how do we *detect* (!) an attack - also from headers? Or do you have a >> catalogue of IP addresses that are allowed to use the API (then, detection >> would be simple)... >> >> >> Best regards, >> Frank >> >> >> >> >> Am Fr., 10. Mai 2019 um 07:37 Uhr schrieb Nadee Poornima <nad...@wso2.com >> >: >> >>> Hi Frank, >>> >>> In deed: very nice idea, valuable feature! Which attributes should be >>>> used to detect an attack? >>>> >>> >>> Thank you very much for the feedback. >>> >>> In here, if anyone invokes this Honeypot API, it will detect as an >>> anonymous attack. We are getting the headers (IP, if have access tokens) in >>> order to identify the attacker. Currently, we are implementing to detect >>> and alert this to the system admin. We hope to implement the blocking part >>> also in future time. >>> >>> Thank you & regards, >>> Nadee >>> >>> >>> On Thu, May 9, 2019 at 10:47 PM Frank Leymann <fr...@wso2.com> wrote: >>> >>>> In deed: very nice idea, valuable feature! Which attributes should be >>>> used to detect an attack? >>>> >>>> Best regards, >>>> Frank >>>> >>>> >>>> >>>> >>>> Am Do., 9. Mai 2019 um 11:09 Uhr schrieb Sanjeewa Malalgoda < >>>> sanje...@wso2.com>: >>>> >>>>> Tracing and logging problematic API calls definitely add value to >>>>> product. This is kind of alerting mechanism. But we should not stop from >>>>> there. We can go one step ahead and block calls with similar attributes. >>>>> We >>>>> can block API calls temporary based on the API context, application id, >>>>> user and IP address. Then users who accessed honeypot APIs will not be >>>>> able >>>>> to use other APIs. >>>>> >>>>> Blocking condition related updates we can put into topic from traffic >>>>> manager. So we can use same mechanism here as well. >>>>> >>>>> Thanks, >>>>> sanjeewa. >>>>> >>>>> On Thu, May 9, 2019 at 12:18 PM Nadee Poornima <nad...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> If published APIs in the store, they could invoke by the Hackers by >>>>>> scanning the open ports of a system. Therefore in order to prevent such >>>>>> attacks, the user needs to use different tools or mechanism. The >>>>>> Honeypots[1] is such a system, user can use in their environment to >>>>>> detect >>>>>> such anonymous attacks. >>>>>> >>>>>> Instead of using such out of box tools or mechanism, we are trying to >>>>>> implement a mechanism to detect such anonymous invocation of APIs within >>>>>> the APIM product. >>>>>> >>>>>> *The suggested Approach:* >>>>>> There is a deployed API in the gateway(not showing the API in >>>>>> publisher or store), once invoked that API by an anonymous user, it will >>>>>> identify it as anonymous invocation and trigger an Alert (send an email) >>>>>> to >>>>>> admin user of the system. Request Data will publish to the Trafic Manager >>>>>> and they will persist to DB as well. >>>>>> Those invocations will appear as a list in the Admin portal and admin >>>>>> user could remove or persist them through the UI after reviewing them. >>>>>> Further, we will implement an Admin UI part to configure that Alert(like >>>>>> configuring email). >>>>>> >>>>>> [image: HoneyPotAPIAlertApproach.png] >>>>>> >>>>>> [1]. https://blog.rapid7.com/2016/12/06/introduction-to-honeypots/ >>>>>> >>>>>> Thank you and regards, >>>>>> *Nadee Poornima* >>>>>> Software Engineer - Support Team | WSO2 >>>>>> >>>>>> Email : nad...@wso2.com >>>>>> Mobile : +94713441341 >>>>>> MyBlog: https://medium.com/nadees-tech-stories >>>>>> >>>>>> <https://wso2.com/signature> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Sanjeewa Malalgoda* >>>>> Software Architect | Associate Director, Engineering - WSO2 Inc. >>>>> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger >>>>> <http://sanjeewamalalgoda.blogspot.com>, Medium >>>>> <https://medium.com/@sanjeewa190> >>>>> >>>>> GET INTEGRATION AGILE <https://wso2.com/signature> >>>>> Integration Agility for Digitally Driven Business >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>> >>> >>> -- >>> *Nadee Poornima* >>> Software Engineer - Support Team | WSO2 >>> >>> Email : nad...@wso2.com >>> Mobile : +94713441341 >>> MyBlog: https://medium.com/nadees-tech-stories >>> >>> <https://wso2.com/signature> >>> >> > > -- > *Nadee Poornima* > Software Engineer - Support Team | WSO2 > > Email : nad...@wso2.com > Mobile : +94713441341 > MyBlog: https://medium.com/nadees-tech-stories > > <https://wso2.com/signature> >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
