# Product Updates
Source: https://docs.repacket.com/changelog/overview
New updates and improvements
## Design Overhaul
![New Repacket Dashboard]()
Repacket has fully overhauled it's UI / UX, replacing old toggles with full dynamic rule builders, as well as leveling up the UI overall!
# Advanced Schema
Source: https://docs.repacket.com/config/advanced
An dive into our proto under the hood
Repacket offers a robust rule configuration system that lets you heavily customize its features. Configuration is defined by writing Protocol Buffers defining specific rules.
## Rules
The most important part of the `Config` is its list of `Rule`s.
Each rule is composed of two parts: a "matching spec" and an "action spec". The matching spec says whether a rule applies, the "action spec" says what it does.
Here's an example configuration:
```
rules {
# The matching spec
domain: "*.google.com"
ipv4_mask: 10.0.0.0/24
ipv6_mask: fd00::2000::/56
# The action spec
block_mode: BLOCK_MODE_BLOCK
}
```
This rule says to block traffic (`BLOCK_MODE_BLOCK`) to google.com and its subdomains (`*.google.com`).
### The matching spec
A rule will be applied if *all* of the items in its matching spec match.
Example:
```
rules {
domain: "google.com"
acl: 1234
block_mode: BLOCK_MODE_BLOCK
}
```
This rule will block access to `google.com`, but only for user/group with ID `1234`.
If a rule's matching spec is empty, it always applies. Example:
```
rules {
block_mode: BLOCK_MODE_BLOCK
}
```
Since this rule doesn't have any fields from the matching spec, it always applies. Thus, this (extremely useless) rule means that *all* websites are blocked.
### Multiple Rules
Each rule overrides the previous rule, if it matches.
Example:
```
rules {
domain: "*.google.com"
block_mode: BLOCK_MODE_BLOCK
}
rules {
domain: "images.google.com"
block_mode: BLOCK_MODE_ALLOW
}
```
This configuration will normally block access to `google.com` and its subdomains, but it allows access to `images.google.com`.
Rules can also have nested rules, which override their parent if they match. Nested rules are only applied if their parent rule also matched.
Example:
```
rules {
domain: "*.amazon.com"
block_mode: BLOCK_MODE_BLOCK
}
rules {
domain: "*.google.com"
block_mode: BLOCK_MODE_BLOCK
rules {
acl: 1234
block_mode: BLOCK_MODE_ALLOW
}
}
```
This blocks access for everyone to `*.amazon.com`, and normally blocks access to `*.google.com`. However, access to `*.google.com` is permitted for user/group `1234`. That user/group is still not allowed to access `*.amazon.com`.
Action specs only override the fields they specify; any unspecified fields are inherited.
Example:
```
rules {
domain: "*.google.com"
block_mode: BLOCK_MODE_WARN
warn_dismiss_duration: 3600 # 1 hour
}
rules {
domain: "maps.google.com"
warn_template: "pirate"
warn_dismiss_duration: 60 # 1 minute
}
```
The first rule says users should be served a warning page (`BLOCK_MODE_WARN`) for `google.com` and its subdomains, and users need to re-accept the warning every hour (`warn_dismiss_duration`). The second rule overrides the `warn_dismiss_duration` and says what warning page to show for `maps.google.com` (`warn_template`), but it still inherits the `block_mode` value from the previous rule.
### Cookies
Each `Rule` can contain any number of `CookieRule`s. These specify things like whether a cookie should be encrypted, blocked, or allowed through. Just like regular `Rule`s, each `CookieRule` has its own matching spec and action spec. All the same inheritance, matching, and override rules apply to `CookieRule`s as they do to regular `Rule`s. Note that since `CookieRule`s are nested inside of `Rule`s, they only apply if their parent `Rule` applies.
Example:
```
rules {
cookies {
# Matching spec
http_only: true
# action spec
transform: true
}
}
```
The outer `Rule` has no matching spec, so this applies to all domains. The inner `CookieRule` says that cookies should be encrypted (`transform: true`) if they are HttpOnly cookies.
## Field Reference
Documentation about the specific fields of matching specs and action specs lives in the `config.proto` file itself.
## Templates
Warn and block pages can be customized via templates. These templates are evaluated with the C++ `inja` library.
At the most basic, templates can just be regular HTML. Example:
```
templates {
name: "pirate"
template: "Blocked by ye captain, me hearties."
}
```
This template can then be used by setting `block_template: "pirate"` in the `Rule`s.
### Inja Templating
Because we use `inja`, templates include or extend other templates.
Consider the following template:
```
{% include "styles" %}
Blocked by ye captain, me hearties.
```
This requires there to also be a template with name `styles` defined. The contents of the `styles` template will be included in this template, replacing the `{% ... %}` directive.
A template can also extend another template, replacing specific fields.
### Built-in templates
We provide a few built-in templates that can be `%{ include %}`d or extended. They are:
* `__default__`: The default template, used if the config doesn't specify a `warn_template` or `block_template`.
* `__default_styles__`: Some default styles. Used in the default template.
* `__continue__`: The "Continue" button for warning pages, which dismisses the warning and allows the user to proceed.
* `__missing__`: Fallback, used if the config tries to include or extend a template that doesn't exist.
* `__error__`: Fallback, used if there's some other error in the template syntax.
*Any template used for warnings MUST contain `{% include "__continue__" %}` somewhere. If not, users will be unable to continue past the warning.*
### Inja Inheritance
As an example, this is the `__error__` template, displayed to users if there's an error in rendering the user-supplied template:
```
{% extends "__default__" %}
{% block error %}
Error in template {{ template_name }} for domain {{ host }}
{{ error_message }}
{% endblock %}
{% block blocked_title %} {{ super() }} {% endblock %}
{% block blocked_message %} {{ super() }} {% endblock %}
{% block warning_title %} {{ super() }} {% endblock %}
{% block warning_message %} {{ super() }} {% endblock %}
```
This extends the `__default__` template. It overrides a block in the default template called `error`. The other blocks, like `warning_title`, are not overridden.
If a block is not explicitly mentioned when extending a template, that block will be empty. To avoid this, call `super()` like this:
```
{% block blocked_title %} {{ super() }} {% endblock %}
```
The `__default__` template contains the following overrideable blocks:
* `blocked_title`: The title to display if a page is blocked.
* `blocked_messaage`: The message to display if a page is blocked.
* `warning_title` The title to display if a page should show a warning.
* `warning_message`: The message to display if a page should show a warning.
* `error`: A block for displaying an error.
### Variable substitution
We provide variables that templates can use to provide more useful information when a page is blocked. These can be substituted by writing `{{ var_name }}` in the template. The variables provided are defined in `config.proto`'s `message TemplateFields`.
## Categories
In addition to matching against single domains or domains with wildcards, `Rule`s can match against whole [categories](/config/categories) of domains. A collection of default [categories](/config/categories) is provided, and custom [categories](/config/categories) can be created. See the [Categories](/config/categories) page for more information.
Each custom [category](/config/categories) contains a list of domains - literal or wildcard. If a custom [category](/config/categories) has the same name as a previous [category](/config/categories), it overrides it. This works for overriding the built-in [categories](/config/categories) too.
# Categories
Source: https://docs.repacket.com/config/categories
A list of Repacket's default categories.
To simplify configuration, domains are grouped into categories. Categories contain lists of domains or wildcard domains (i.e. `*.google.com`). A website may belong to more than one category.
## Overview
To simplify configuration, domains are grouped into categories.
Categories contain lists of domains or wildcard domains (i.e. `*.google.com`).
A website may belong to more than one category.
Repacket ships with over 80 pre-defined categories to help you get started quickly.
Includes movie, TV, and entertainment websites.
Video streaming services and platforms.
Music streaming and download services.
News outlets, magazines, and media sites.
Sites for finding and viewing images and videos.
Social media platforms and community sites.
Dating websites and relationship services.
Individual websites, blogs, and personal journals.
E-card and digital greeting services.
Messaging platforms and communication tools.
Browser-based email services and webmail.
Banking, investment, and financial management sites.
Corporate websites and business services.
Online auction and bidding websites.
E-commerce and retail websites.
Employment websites and career resources.
Security tools, antivirus, and protection services.
Tech news, guides, and computing resources.
Free and trial software download sites.
Often used for file sharing.
Web search and discovery tools.
Hosting providers and server management services.
Research databases and reference materials.
Schools, universities, and learning platforms.
Child-friendly websites and educational content.
Scientific resources and technology publications.
Medical information and healthcare resources.
Below is the complete list of all built-in categories with their IDs. You can reference these IDs when using the API or in configuration files.
```
0. Uncategorized
1. Real Estate
2. Computer and Internet Security
3. Financial Services
4. Business and Economy
5. Computer and Internet Info
6. Auctions
7. Shopping
8. Cult and Occult
9. Travel
10. Abused Drugs
11. Adult and Pornography
12. Home and Garden
13. Military
14. Social Networking
15. Dead Sites
16. Individual Stock Advice and Tools
17. Training and Tools
18. Dating
19. Sex Education
20. Religion
21. Entertainment and Arts
22. Personal sites and Blogs
23. Legal
24. Local Information
25. Streaming Media
26. Job Search
27. Gambling
28. Translation
29. Reference and Research
30. Shareware and Freeware
31. Peer to Peer
32. Marijuana
33. Hacking
34. Games
35. Philosophy and Political Advocacy
36. Weapons
37. Pay to Surf
38. Hunting and Fishing
39. Society
40. Educational Institutions
41. Online Greeting Cards
42. Sports
43. Swimsuits and Intimate Apparel
44. Questionable
45. Kids
46. Hate and Racism
47. Personal Storage
48. Violence
49. Keyloggers and Monitoring
50. Search Engines
51. Internet Portals
52. Web Advertisements
53. Cheating
54. Gross
55. Web-based Email
56. Malware Sites
57. Phishing and Other Frauds
58. Proxy Avoidance and Anonymizers
59. Spyware and Adware
60. Music
61. Government
62. Nudity
63. News and Media
64. Illegal
65. Content Delivery Networks
66. Internet Communications
67. Bot Nets
69. Health and Medicine
70. Confirmed SPAM Sources
71. SPAM URLs
72. Unconfirmed SPAM Sources
73. Open HTTP Proxies
74. Dynamically Generated Content
75. Parked Domains
76. Alcohol and Tobacco
77. Private IP Addresses
78. Image and Video Search
79. Fashion and Beauty
80. Recreation and Hobbies
81. Motor Vehicles
82. Web Hosting
83. Food and Dining
85. Self Harm
87. Low-THC Cannabis Products
```
Custom categories allow you to define your own domain groups to use in security and policy rules. This makes it easy to group internal domains and apply consistent rules.
### Creating Custom Categories
You can create custom categories by visiting the [Entities](https://app.repacket.com/entities) page on your dashboard.
Below is an example of how to create a custom category.
![Custom category example]()
Feel free to read our [Entities documentation](/config/entities) for more info about creating custom entities.
# Domain Information
Source: https://docs.repacket.com/config/domain-info
Look up domain reputation scores to assess trustworthiness and risk levels
The Domain Information feature allows you to look up any domain and receive a reputation score that indicates the trustworthiness and risk level of an IP address or URL. This helps you make informed decisions about which domains to allow or block in your security policies.
## Overview
The Domain Information feature allows you to look up any domain and receive a reputation score that indicates the trustworthiness and risk level of an IP address or URL. This helps you make informed decisions about which domains to allow or block in your security policies.
![Domain Information lookup]()
## How It Works
You can access the Domain Information tool by navigating to the [Entities page](https://app.repacket.com/entities#domain-info) in your Repacket dashboard. Simply enter a domain name or URL, and the system will analyze it and provide a reputation score.
## Reputation Score
The reputation score indicates the trustworthiness and risk level of an IP address or URL.
## Related Features
Learn about entities and how to configure them
Set up protection rules using domain information
# Entities
Source: https://docs.repacket.com/config/entities
Targets for applying security and policy features within Repacket
Entities are the traffic targets for configuration in Repacket. They let you define what properties we should match against to enforce your rules, including custom categories and IP ranges.
## Creating Entities
To create a new entity, navigate to the [Entities page](https://app.repacket.com/entities#entities) in your Repacket dashboard and click the "Create" button.
![Creating an entity]()
## Entity types
Today, Repacket allows you to configure custom categories and IP ranges.
### Categories
Categories represent a group of domains. These can include wildcards, *and often should*.
Repacket ships with nearly [80 default categories](/config/categories).
![]()
### IP Ranges
IP ranges allow you to target traffic based on the destination IP address.
These use CIDR notation and are generally used to exclude your internal websites from Repacket features.
# Modules
Source: https://docs.repacket.com/config/modules
Core features of Repacket
## What are modules?
Modules are the core features of Repacket, each designed to provide targeted protection and control over network traffic. Modules interact with Entities such as [categories](/config/categories), domains,
IP ranges, and applications enabling precise policy enforcement to defend against a variety of threats.
Modules generally use a "rule builder" system, which you will see referenced through the rest of our pages.
![]()
## Module Types
### App Discovery
App Discovery provides comprehensive visibility into your organization's web application usage by analyzing network traffic patterns. This feature automatically identifies applications being accessed by users, tracks usage patterns, and monitors file upload activities.
You can use this to discover shadow IT, monitor data exfiltration risks, and optimize your software portfolio based on actual usage data.
Read more on our [App Discovery docs](/modules/app-discovery) or [visit your Apps dashboard](https://app.repacket.com/apps).
### Firewall
Firewall allows you to configure Repacket for content filtering, as well as use us as a generic web firewall.
You can use this to block entire [categories](/config/categories), specific websites, or direct users about company-approved alternatives.
Read more on our [Firewall docs](/modules/firewall) or [visit your Firewall config](https://app.repacket.com/gateway#firewall).
### Protections
Protections allow you to apply enhanced security controls on top of specific forms of traffic.
You can use this to run advanced phishing protection scripts on Uncategorized websites for example - a common Repacket use-case.
Read more on our [Protections docs](/modules/protections) or [visit your Protections config](https://app.repacket.com/gateway#protections).
### Data Loss Prevention (DLP)
Our DLP allows you to analyze uploads and website submissions for sensitive data, like PHI, PII, Corporate Contracts, and more.
Today this is targeted at LLMs, but can technically be applied on most websites or apps. We also support Slack.
For example, Repacket can detect PHI being uploaded to ChatGPT, and warn users in advance.
Read more on our [DLP docs](/modules/dlp) or [visit your DLP config](https://app.repacket.com/dlp).
# repacket.proto
Source: https://docs.repacket.com/config/schema
The raw Repacket proto
```
syntax = "proto3";
// This defines rules for how to handle traffic.
// Each rule has 0 or more "match"
// Rules are applied first to last, with later rules
// overriding previous rules. Any action not specified in a rule
// is unchanged from its previous rule.
// Rules can optionally contain nested rules:
// a) a nested rule is applied after its parent rule but before
// the rule following the parent rule.
// b) a nested rule matches only if both the parent rule and the
// nested rules match.
message CookieRule {
/// Matching spec.
// A regular expression for the name of the cookie.
optional string name = 3;
// Whether this cookie is marked http_only.
optional bool http_only = 4;
// Whether this cookie is marked secure.
optional bool secure = 5;
// Action spec.
// Cookie configs on subdomains override those on parent domains,
// and cookie configs later in the list override those earlier
// in the list. In both cases, unspecified values are inherited.
// Whether this cookie should be protected through
// transformation.
optional bool transform = 1;
// Whether this cookie should be blocked altogether.
optional bool block = 2;
}
message HeaderControl {
// An ID.
// If two directives have the same ID, the second directive
// overrides the first. If two directives have different IDs,
// both headers are attached.
// If this ID is not present, the id defaults to `name`, giving a sensible
// default behavior: adding a new HeaderControl with the same
// name overrides the previous one.
optional string id = 3;
// The name of the header to be attached.
string name = 1;
// The value of the header to be attached.
string value = 2;
// If true, the header is removed rather than being added.
// The fields `name` and `value` are ignored (except for the
// default `id` computation).
bool remove = 4;
};
message InjectControl {
// An ID.
// If two directives have the same ID, the second directive
// overrides the first. If two directives have different IDs,
// both templates are injected.
// If this ID is not present, the id defaults to `template_name`.
optional string id = 2;
string name = 1;
// If true, the template is removed rather than being added.
// The field `template_name` is ignored (except for the
// default `id` computation).
bool remove = 3;
}
message Rule {
// Matching spec.
optional string domain = 5;
optional string category = 6;
optional int32 acl = 7; // User or group this applies to
optional string ipv4_mask = 13;
optional string ipv4_wildcard = 14;
optional string ipv6_mask = 15;
// uri filtering
optional string url_path = 17;
/// Action spec.
// Whether or not to intercept traffic for this domain.
// If false, other settings on this domain are ignored.
optional bool intercept = 3;
enum BlockMode {
// Inherit from the previous / parent rule.
BLOCK_MODE_INHERIT = 0;
// Allow the user to access this.
BLOCK_MODE_ALLOW = 1;
// Warn the user if they try to access this, but allow them to dismiss the warning.
BLOCK_MODE_WARN = 2;
// Block the user from accessing this.
BLOCK_MODE_BLOCK = 3;
}
BlockMode block_mode = 4;
// How long to hide a warning after
// it has been dismissed.
// Seconds.
optional float warn_dismiss_duration = 11;
// Name of template to be displayed when a page is blocked.
optional string block_template = 9;
// Name of template to be displayed when a page
// shows a warning.
optional string warn_template = 10;
// Cookie-specific settings.
repeated CookieRule cookies = 1;
// Headers to attach to requests.
repeated HeaderControl request_headers = 16;
// HTML templates to inject into the page.
repeated InjectControl injects = 18;
/// Sub-configs.
repeated Rule rules = 2;
enum StructuredLogLevel {
// Inherit from the previous / parent rule.
LOG_LEVEL_INHERIT = 0;
// Log all visits.
LOG_LEVEL_ALL = 1;
// Log only alerts - warnings, errors, malware detection, etc.
LOG_LEVEL_ALERT = 2;
// Don't log anything.
LOG_LEVEL_NONE = 3;
}
// Set what should be logged over the network to the structured log.
// The default of this value if no other rules match is LOG_LEVEL_ALERT.
StructuredLogLevel structured_log_level = 19;
}
// custom Category data representation
// Categories have a list of domains in that category.
// If a Category has the same name as a BrightCloud category,
// that acts as an override: any domains in the `domains` list
// are added to the category. Any domains prefixed with a - are
// instead removed from the category.
// Note that this `-` can be used for non-brightcloud categories
// as well, to remove domains from wildcard sets. Example to include
// google.com and its subdomains, but not mail.google.com:
// domains: "*.google.com"
// domains: "-mail.google.com"
message Category {
string name = 1;
repeated string domains = 2;
}
message Template {
string name = 1;
string template = 2;
}
message Config {
repeated Rule rules = 1;
repeated Category categories = 2;
repeated Template templates = 3;
optional float refresh_period = 4;
}
// all the fields available for a template
// to use.
message TemplateFields {
string host = 1;
string uri = 2;
string ip = 6;
repeated string categories = 7;
optional bool blocked = 3; // True if this is being used to block, false if being used to warn.
string template_name = 4; // The name of the template being used.
bool standalone = 8; // True if the proxy is in standalone mode.
string web_url = 5; // The URL of the repacket server, to which exception requests can be sent.
bytes restricted_credential = 9; // A credential restricted to both the current user and domain.
// Used for diagnostics if a template fails to render.
// Will be the empty string if the template renders successfully.
string error_message = 100;
string nonce = 101; // A CSP nonce for