# Malicious activities

*Malicious activities* are special User Activities which consume a lot of bandwidth and reduce the Satiety of any Provider they target. These Activities are not displayed in Surveyor, so it's not easy to identify the offending Users.

There are two possible Maliciouis activities which can spawn:

* *Text Scraping*, which targets the same Provider each time, being any host of `read-text`
* *Pirating Video Content*, which targets random Providers, being any host of `stream-video`

You can tell when a Provider is being affected by a message in the Surveyor log, which will state:

> <span style="color: red;">Our content is being scraped over tcp/80xx</span>

or

> <span style="color: white;">We're seeing illegal downloads of our content over tcp/80xx</span>

Where `xx` is any number between 00 and 99. This will match the Traffic Type of the malicious requests in question, which are fixed for a given Consumer-Provider pair.

## User Types

The Users tab in the Tower Catalogue identifies which User Types might spawn with Malicious activities:

Type|Activity|Probability
-|-|-:
Exclusive Coder(1)|Text Scraping |50%
Exclusive Coder(2)|Text Scraping |80%
Digital Salesman |Text Scraping |30%
Greedy Dweller |Text Scraping |20%
Tech Adopter |Text Scraping |30%
Digital Hoarder |Pirating Video Content|50%
Minimum Spender |Pirating Video Content|80%

Malicious activities do not affect the Satiety of the offending User; they are entirely negative on the network.

## Mitigations

> [!NOTE]
> This guide presumes that Firewalls do not exist. While available in the Lab, they are not currently purchasable in the game proper.
> In any case, the solutions below apply equally to Firewalls, with the additional benefit being that device bandwidth is not consumed for dropped traffic.

### Disconnecting

While simply disconnecting all User Types that might generate Malicious traffic is an option, many of these Users will have SLAs making this impossible; and in any case this will somewhat reduce your income as their payment will be zero.

### Blacklisting

We can use `traffic` routing rules to block malicious traffic directed at a particular Provider as soon as we notice it in the Surveyor log.

> `route add @provider traffic tcp/8056 via port9 on @router`

Since this route specifies both a destination address (`@provider`) and a traffic type (`tcp/8056`) it will have a higher priority than a route that *only* specifies the address.

While it isn't possible to explicitly drop traffic with a Router, we can direct it to an unused port, or back in the direction it most likely came from, which has a similar effect. So in the above example, we would ensure that Port 9 is either disconnected, or points back up-stream, or links to a different client. This has the effect of blocking traffic of that type, and is colloquially known as 'black-holing'.

Note, however, that Bandwidth is still consumed by the Router and any other Devices/Links beforehand. If the target Port is disconnected (or is the same as the origin Port) then only half of the usual Bandwidth is consumed at the final Router, as it does not perform a full 'traversal'.

**Pros:**
* Quick to implement, just one command
* Straightforward, as you can react directly to a given Provider and Traffic type
* Safe, as you are unlikely to block any legitimate requests

**Cons:**
* Bandwidth is still consumed by every link on the chain before the Provider, so it's less efficient
* This is a reactive strategy: you have to watch out for malicious activities and add a rule for each of them when they occur. You can't prepare this in advance as you don't know which Providers will be affected, or what Traffic Type will be used.

### Provider-side Whitelisting

We can go the other way, and only allow Traffic of specific types that we know cannot be Malicious. This is possible because Malicious traffic can *only* use the `tcp/80xx` range, which does not include any legitimate requests.

For example:
> `route add @provider traffic tcp/80 via port1 on @router`
> `route add @provider traffic tcp/443 via port1 on @router`

(Make sure to remove any existing rules that don't specify a Traffic type.)

The above rules will allow legitimate requests to a particular Provider while blocking everything else by default.

The set of Traffic Types to include might change for certain Providers: for example `tcp/8333` for P2P activities, or `tcp/23` if you need to send Debugger requests like `net dns set`.

It's worthwhile to set an `alias` for commonly used configurations, for example:
> `alias my_routes route add $1 traffic tcp/80 via $2 on $3; route add $1 traffic tcp/443 via $2 on $3`
> `my_routes @provider port1 @router`

**Pros:**
* Both reactive and proactive: you can apply these rules for a Provider when you notice them suffering, and from that point onward they will be protected.

**Cons:**
* Bandwidth is still consumed by every link on the chain before the Provider, so it's less efficient
* Slightly more complex setup: you need to remove existing rules, then apply the new ones based on the Provider type.

### Consumer-side Whitelisting

We can use the same Whitelisting technique, but on the Router that's close to the potentially malicious users instead.

For example, supposing that `@/` matches all possible Providers:
> `route add @/ traffic tcp/80 via port1 on @router`
> `route add @/ traffic tcp/443 via port1 on @router`
> `route add @/ traffic tcp/554 via port1 on @router`
> `route add @/ traffic tcp/8333 via port1 on @router`
> `route add @/ traffic tcp/3306 via port1 on @router`
> `route add @/ traffic udp/5060 via port1 on @router`

Since the number of [legitimate Traffic types](/@tower-network/network-traffic-types) is quite large, it will certainly be worth setting an `alias` for this command sequence! You will need to apply these rules to any Router that might connect to a potentially-malicious user.

Once in place, however, the benefits are significant: you don't need to keep an open port for 'black-holing', and no extra Bandwidth is consumed by any device other than the Router closest to the malicious users.

**Pros:**
* Highly bandwidth-efficient
* Proactive: once in place, there's no risk of malicious traffic slipping through

**Cons:**
* Bandwidth benefits require a direct connection from the User to the Router
* Requires awareness of potentially-malicious user types
* Requires a common prefix for all Providers
* Complex configuration leading to a risk of blocking legitimate requests

### Consumer-side Blacklisting

> [!NOTE]
> Ethernet Tappers and the `pcap` command are currently not available in the game proper. When released, they will make this technique more viable as it will be possible to see the source of malicious traffic directly in the terminal.

It's normally quite difficult to identify exactly which User is responsible for a given set of Malicious requests, but if you're able to do so then you can apply the Blacklisting technique on the Consumer side like so:

> `route add from 12345 traffic tcp/8056 via port3 on @router`

In this case `12345` is the User's hardware address, and Port 3 is their connected port on `@router`. Rules of this format will have extremely high priority, and since we know which Port the user is connected to, we can direct traffic back the way it came which will always drop it; no need to leave a port open.

**Pros:**
* Highly bandwidth-efficient
* Does not require a common prefix for Providers
* Only a single command per instance

**Cons:**
* Can be difficult to identify the offending User
* Needs configuration for each Consumer rather than each Provider, and there are typically more Consumers than Providers
* Purely reactive, as with other Blacklisting techniques