Description

Added Testcases for Views and Models

Related issues

Fixes #21

Type of change

Please delete options that are not relevant.

• [ ] Bug fix (non-breaking change which fixes an issue).
• [ ] New feature (non-breaking change which adds functionality).
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist

• [ ] I have read and understood the rules about how to Contribute to this project
• [ ] The pull request is for the branch dev
• [ ] The tests gave 0 errors.
• [ ] Linters (Black, Flake, Isort) gave 0 errors. If you have correctly installed pre-commit, it does these checks and adjustments on your behalf.
• [ ] The commits were squashed into a single one (optional, they will be squashed anyway by the maintainer)

Important Rules

• If your changes decrease the overall tests coverage (you will know after the Codecov CI job is done), you should add the required tests to fix the problem
• Everytime you make changes to the PR and you think the work is done, you should explicitly ask for a review

We could provide a service that could be queried via API key. In this way, it would be possibile to understand if an IOC is in the database of Greedybear without having to download and manage all the feeds from Greedybear.

It would be a simple enrichment service.

We would need:

• a basic GUI (#11) to allow people register and get an API key.
• limit API usage to avoid abuse.
• allow different kind of API usage limits
• create new API endpoint (#17)
• Integrate it in IntelOwl (https://github.com/intelowlproject/IntelOwl/issues/817)

GreedyBear works by extracting the data from the T-Pot logs generated by the honeypots.

As a first alpha release we just integrated log4jpot + cowrie.

We should also integrate all the other available honeypots in the T-PoT. Glutton should be the first

Description

Added Enrichment Endpoint. To get details of an observable my it's name. Endpoint: /api/enrichment?query=<observable_name>

Please ignore the vague changes in settings.py regarding env vars. Did it because of #23 I'll revert them when my PR is good to go.

Added Fake data in DB through admin pannel for testing purpose

Related issues

Fixes and Closes #17

Type of change

Please delete options that are not relevant.

• [x] New feature (non-breaking change which adds functionality).

Checklist

• [x] I have read and understood the rules about how to Contribute to this project
• [x] The pull request is for the branch dev
• [ ] The tests gave 0 errors.
• [ ] Linters (Black, Flake, Isort) gave 0 errors. If you have correctly installed pre-commit, it does these checks and adjustments on your behalf.
• [ ] The commits were squashed into a single one (optional, they will be squashed anyway by the maintainer)

Screenshots

API Response

For a record that exist in DB

For a record that does not exist in DB

Details of the searched observable in DB

All Records in DB

Description

Configured Read the Docs

Changes I have done :

added .readthedocs.yaml file made some changes to docs/source/conf.py added documentation link in readme

Things to complete :

I created only the empty md files in docs but haven't added any documentation in them need to add doc of openapi and redoc.

Related issues

This PR partially solves issue #27

Type of change

• [x] New feature (non-breaking change which adds functionality).

Checklist

• [x] I have read and understood the rules about how to Contribute to this project
• [x] The pull request is for the branch dev
• [x] The tests gave 0 errors.
• [x] Linters (Black, Flake, Isort) gave 0 errors. If you have correctly installed pre-commit, it does these checks and adjustments on your behalf.
• [ ] The commits were squashed into a single one (optional, they will be squashed anyway by the maintainer)

Important Rules

• If your changes decrease the overall tests coverage (you will know after the Codecov CI job is done), you should add the required tests to fix the problem
• Everytime you make changes to the PR and you think the work is done, you should explicitly ask for a review

Description

Added elasticsearch container for development

Related issues

closes #23

Type of change

Please delete options that are not relevant.

• [ ] Bug fix (non-breaking change which fixes an issue).
• [X] New feature (non-breaking change which adds functionality).
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist

• [X] I have read and understood the rules about how to Contribute to this project
• [X] The pull request is for the branch dev
• [X] The tests gave 0 errors.
• [X] Linters (Black, Flake, Isort) gave 0 errors. If you have correctly installed pre-commit, it does these checks and adjustments on your behalf.
• [ ] The commits were squashed into a single one (optional, they will be squashed anyway by the maintainer)

Important Rules

• If your changes decrease the overall tests coverage (you will know after the Codecov CI job is done), you should add the required tests to fix the problem
• Everytime you make changes to the PR and you think the work is done, you should explicitly ask for a review

i'm encountering some error while setting up GreedyBear locally After doing the docker-compose -p greedybear up cmd. It originates from settings.py where Elasticsearch client is being initialized. The ELASTIC_ENDPOINT variable in my env file is empty

Description

• Made changes to feeds View to make use of DRF
• Added token authentication of django-rest-durin.

Related issues

This PR solves #26 issue.

Type of change

• [ ] New feature (non-breaking change which adds functionality).

Checklist

• [ ] I have read and understood the rules about how to Contribute to this project
• [ ] The pull request is for the branch dev
• [ ] The tests gave 0 errors.
• [ ] Linters (Black, Flake, Isort) gave 0 errors. If you have correctly installed pre-commit, it does these checks and adjustments on your behalf.
• [ ] The commits were squashed into a single one (optional, they will be squashed anyway by the maintainer)

Description

Rate limiting for admin and API

Related issues

#31

Type of change

Please delete options that are not relevant.

• [ ] Bug fix (non-breaking change which fixes an issue).
• [X] New feature (non-breaking change which adds functionality).
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist

• [X] I have read and understood the rules about how to Contribute to this project
• [X] The pull request is for the branch dev
• [X] The tests gave 0 errors.
• [X] Linters (Black, Flake, Isort) gave 0 errors. If you have correctly installed pre-commit, it does these checks and adjustments on your behalf.
• [X] The commits were squashed into a single one (optional, they will be squashed anyway by the maintainer)

Important Rules

• If your changes decrease the overall tests coverage (you will know after the Codecov CI job is done), you should add the required tests to fix the problem
• Everytime you make changes to the PR and you think the work is done, you should explicitly ask for a review

Can we please add or refer to the URL containing the guidelines for future contributors, I see there's nothing mentioned about it in the readme or docs for this repo.

This would require that all of these issues were solved first:

• #11 , #12 , #10 , #21 , #27

Plus, we would need to work with the T-Pot team to properly integrate the project there. The goal is to try to reduce the complexity of the overall application to allow an easy integration

We could add more ways to extract data feeds from GB other than "recent" and "persistent" which are free.

These new ways must be protected with authentication to avoid abuse.

We could give the users the chance to:

• download the data extracted in the last X hours (customization of "recent")
• download the data that was seen more than X times in the last X days (customization of "persistent")

We should periodically download this batch of data: https://raw.githubusercontent.com/stamparm/maltrail/master/trails/static/mass_scanner.txt and add those IP to whitelists to reduce number of false positives

Right now there is no chance to do that. GreedyBear would automatically extract data from all the configured honeypots.

We should allow the app administrator from the Django Admin to enable/disable honeypot extraction. In that way we can also filter logs which states that the honeypot is not running.