Home

handle organisations <=> ip,asn via fody schema

fody-implementation

settings-implementation

---

Topics

• onboarding: who will be allowed to log in and edit his/her org-data?
• reality-checker: be able to handle reality versus previous stored data: measure or import for example the RIPE DB. Show diffs when not resolvable. Ask / inform user on diffs.
• abuse_c finder: for automation. Need to supply an IP addr/netblock and get the abuse_c for it
• stats-machine: be able to generate stats of the eventDB via netblocks aggregation

Implementation steps

1. Import the RIPE DB into do-portal
   1. Harmonize DB structure with CERT-eu.
   2. Import script which throws away previous RIPE DB import (but not manual data)
2. Implement abuse_c finder via a RESTful API
3. Possibility to enter manual data (orgs, contacts, associations to netblock) - for admin accounts
4. Add functionality that a (non-admin) user can edit and change her contact infos as well as network infos (careful: only sub-netblocks of the netblocks which are assigned to the org of the user).
5. Manual onboarding: send account logins to the top 10% of the country's IP space which (usually ) hold 90% of the addresses. Make sure they can log in, also use friendly beta-testers.

abuse_finder API

who is allowed to access this API endpoint? => everybody who has the access rights to the underlying objects

as soon a ripe handle is associated with an organization, the abusec of the org has prority. A local abusec (if defined) is returned otherwise the abusec from the ripe handle is returned The default setting are returned (config tbd) unless more specific setting are defined.

GET <api-url>/ripe/contact/ripe/contact?cidr=195.245.92.0/23  
returns

{
  "abusecs": [
    "[email protected]"
  ],
  "notification_setting": {
    "cidr": "195.245.92.0/23",
    "delivery_format": "CSV",
    "delivery_protocol": "Mail",
    "notification_interval": 604800,
    "organization_id": null,
    "ripe_org_hdl": null
  }
}

Get the direct abuse_c which holds the netblock 1.2.3.0/24 and only this abuse_c

GET <api-url>/ripe/contact/1.2.3.0/24?level_up=1

Return 1.2.3.0/24 and 1.2.3.0/23 org's abuse_c

GET <api-url>/ripe/contact/1.2.3.0/24?level_up_to_higher_netowner=1

TBD...

OLD --- old scratch info ---

Use cases

use case 1:

• import ripe db see https://github.com/Intevation/intelmq/blob/certbund-contact/intelmq/bots/experts/certbund_contact/ripe_import.py
• has to be similar to the intevation model
• update
• history(?)

use case 2:

• manuall inserts, have to be kept - history is important

use case 3:

• define API to be compatible with Intevation API

Test cases

test cases for 1:

• for a given IP (range) return the correct org

test cases for 2:

• insert a more specific entry => return the same org + more specific depending on the rules, with information that the entry is not from ripe but manually inserted

test cases for 3:

• integrate with infrastructure