Route order management command?

[ulzgoroth]

It looks (in the f1 wiki and man route) like there's currently way to adjust the order of routes set in a router other than deleting them and re-adding them in the desired sequence.

It seems like it could be very, very desirable to be able to do that if you have a particularly complex routing strategy.

[Mercury Knuckle]

Does it route in order? I thought it picks greedily. Like for example, one port accepts '@a1' and another does '@a11.' Something addressed to @a11dc will take the @a11 port because it matches the most characters.

I have not tested this closely and I could be very wrong.

EDIT: After some testing, and looking at the list. It arranges the list in order of longest matching first, no matter what order you add the routes.

num|    traffic|    in.|    src.|    dest.|    out.
--------------------------------------------
      2       any     any    any  @a111   port9
      1       any     any    any   @a11   port4
      0       any     any    any    @a1   port1
      3       any     any    any    @b1   port5

[ulzgoroth]

There are several types of routing, not only destination name based routing. So it definitely can't have that as the only rule. Routing rules can also go by origin or traffic type, or any combination of address (physical or net), origin, and traffic type.

I think it runs through rules in order, but I'm not certain of that. (Firewalls definitely do rules in order, but I don't think routers expressly say so.)

EDIT: The wiki does talk about the longest matching. The wiki is completely unaware of non-destination-based routing rules.

[ulzgoroth]

Experiments so far suggest there are multiple classes of route rank with different impact on sorting.

I haven't done the length game in detail since you did. But I did experiment with traffic type routes and hardware address routes.

Network name routes are put in front of traffic type routes, whether they're added first or not. Hardware name routes are put in front of network name routes.

I think traffic type routes and hardware address routes maintain the order in which they're added.

From routes sort in front of destination routes

Haven't checked multi-factor routes.

(I am assuming that the routes are checked in the order they're displayed, top to bottom.)



Which means that routers are a bit less flexible than they look, and also that there may not be any cases where order of rule insertion matters. (Depending on how the multi-factor rules work.)

[SilentDaemon]

Originally posted by ulzgoroth:

Experiments so far suggest there are multiple classes of route rank with different impact on sorting.

I haven't done the length game in detail since you did. But I did experiment with traffic type routes and hardware address routes.

Network name routes are put in front of traffic type routes, whether they're added first or not. Hardware name routes are put in front of network name routes.

I think traffic type routes and hardware address routes maintain the order in which they're added.

From routes sort in front of destination routes

Haven't checked multi-factor routes.

(I am assuming that the routes are checked in the order they're displayed, top to bottom.)



Which means that routers are a bit less flexible than they look, and also that there may not be any cases where order of rule insertion matters. (Depending on how the multi-factor rules work.)

I would like to know an example of your multi-factor route. We could maybe try to set up the architecture then share the result here ?

[ulzgoroth]

Originally posted by HackDown:

I would like to know an example of your multi-factor route. We could maybe try to set up the architecture then share the result here ?

The closest thing to a multifactor route I actually tested was one specifying both the origin port and the origin address. According to the documentation you can make a routing rule that specifies everything at once - origin port, origin address, destination address, and traffic type. Or any combination, with the possible (not clear, not tested) exception of origin address without origin port.

I am not aware of any practical reason to create a hyper-specific rule.

However, you could probably manage to use a carefully tuned rule as a hackjob firewall. For instance, if you've used a packet sniffer to identify the origin and type of malicious packets, you could route them somewhere harmless or to a dead port. And that rule should sort above the main destination-based rules, so it would probably work. (Unlike a proper firewall, it wouldn't keep the packets from hitting the router and using up bandwidth.)

[Exsilium Games]

Dont know how the game works, but in RL there are routing protcols like RIP, RIPv2, EIGRP and OSPF for instance. There are also BGP and other protocols for WAN traffic. Usually youll use something like OSPF (in a non-cisco environment) to route in a LAN and something else on the WAN side with BGP to translate between the two protocols.

These routing protocols are split into types, hop-count and administrative distance are the main types. One just counts the number of hops to the destination and the other includes things like hop count as well as speed and type of connection as well as statically configured 'cost'.

[SilentDaemon]

Originally posted by Exsilium Games:

Dont know how the game works, but in RL there are routing protcols like RIP, RIPv2, EIGRP and OSPF for instance. There are also BGP and other protocols for WAN traffic. Usually youll use something like OSPF (in a non-cisco environment) to route in a LAN and something else on the WAN side with BGP to translate between the two protocols.

These routing protocols are split into types, hop-count and administrative distance are the main types. One just counts the number of hops to the destination and the other includes things like hop count as well as speed and type of connection as well as statically configured 'cost'.

The game is a way more easier than real life. We don't manage several routing protocol.

The command is quite simple.
route add [dest_addr] [traffic traffic_type] [from port:src_addr] via port_id

Originally posted by ulzgoroth:

Originally posted by HackDown:

I would like to know an example of your multi-factor route. We could maybe try to set up the architecture then share the result here ?

The closest thing to a multifactor route I actually tested was one specifying both the origin port and the origin address. According to the documentation you can make a routing rule that specifies everything at once - origin port, origin address, destination address, and traffic type. Or any combination, with the possible (not clear, not tested) exception of origin address without origin port.

I am not aware of any practical reason to create a hyper-specific rule.

However, you could probably manage to use a carefully tuned rule as a hackjob firewall. For instance, if you've used a packet sniffer to identify the origin and type of malicious packets, you could route them somewhere harmless or to a dead port. And that rule should sort above the main destination-based rules, so it would probably work. (Unlike a proper firewall, it wouldn't keep the packets from hitting the router and using up bandwidth.)

Well, I didn't manage to create hyper-specific routing roules as well. I wonder if the creation of a "honeypot" is possible at this stage of development. Once you track a hacker, you could route all its connections through a fake server or device.

To much real for being implemented, I guess like you said, a hyper-specific rules redirecting through a dead-end port.

[meRlinX_AT]

Originally posted by SilentDaemon:

Originally posted by Exsilium Games:

Dont know how the game works, but in RL there are routing protcols like RIP, RIPv2, EIGRP and OSPF for instance. There are also BGP and other protocols for WAN traffic. Usually youll use something like OSPF (in a non-cisco environment) to route in a LAN and something else on the WAN side with BGP to translate between the two protocols.

These routing protocols are split into types, hop-count and administrative distance are the main types. One just counts the number of hops to the destination and the other includes things like hop count as well as speed and type of connection as well as statically configured 'cost'.

The game is a way more easier than real life. We don't manage several routing protocol.

The command is quite simple.
route add [dest_addr] [traffic traffic_type] [from port:src_addr] via port_id

Originally posted by ulzgoroth:

The closest thing to a multifactor route I actually tested was one specifying both the origin port and the origin address. According to the documentation you can make a routing rule that specifies everything at once - origin port, origin address, destination address, and traffic type. Or any combination, with the possible (not clear, not tested) exception of origin address without origin port.

I am not aware of any practical reason to create a hyper-specific rule.

However, you could probably manage to use a carefully tuned rule as a hackjob firewall. For instance, if you've used a packet sniffer to identify the origin and type of malicious packets, you could route them somewhere harmless or to a dead port. And that rule should sort above the main destination-based rules, so it would probably work. (Unlike a proper firewall, it wouldn't keep the packets from hitting the router and using up bandwidth.)

Well, I didn't manage to create hyper-specific routing roules as well. I wonder if the creation of a "honeypot" is possible at this stage of development. Once you track a hacker, you could route all its connections through a fake server or device.

To much real for being implemented, I guess like you said, a hyper-specific rules redirecting through a dead-end port.

Blackhole on router is possible, but the router will get infected (my opinion - it's a bug).
pick an unused port on the router or create an port with vLan.

- alias: pr_Black
anchor: &pr_Black
Input: <NW_addr> <via_port(.666)>
Shell: alias pr_Black echo ’prov @Blackhole on <NW_addr> <via_port(.666)>’; route add traffic tcp/510 via $2 on $1; route add traffic tcp/511 via $2 on $1; route add traffic tcp/512 via $2 on $1; route add traffic tcp/513 via $2 on $1; route add traffic tcp/514 via $2 on $1; route add traffic tcp/515 via $2 on $1; route add traffic tcp/516 via $2 on $1; route add traffic tcp/517 via $2 on $1; route add traffic tcp/518 via $2 on $1; route add traffic tcp/519 via $2 on $1; route add traffic tcp/80* via $2 on $1; echo ’<END - prov Blackhole>’

After containment - find the path and name of morris

- alias: ds
anchor: &ds
Input: <NW_addr>
Shell: alias ds echo ’view stats on <NW_addr>’; dstat $1

then delete morris

- alias: delF
anchor: &delF
Input: <filepath> <NW_addr>
Shell: alias delF echo ’delete <filepath> on <NW_addr>’; sftp rm $1 on $2; echo ’<END - delF>’

[PaisleyKitten]

Originally posted by meRlinX_AT:

Blackhole on router is possible, but the router will get infected (my opinion - it's a bug).

If that's really possible at the moment than its definitively a bug. The Morris worm is not stoppable by routing at all. Gameplay-wise it ignores all routing information and turns every device it hits into a switch (broadcasting itself on all ports).

EDIT: The only exception are devices with firewall firmware of course. Those device have a chance to drop the package first.

So if your "Blackhole" is working _that_ is definitively a bug. Otherwise there would be no need for firewalls at all.

[meRlinX_AT]

Originally posted by PaisleyKitten:

Originally posted by meRlinX_AT:

Blackhole on router is possible, but the router will get infected (my opinion - it's a bug).

If that's really possible at the moment than its definitively a bug. The Morris worm is not stoppable by routing at all. Gameplay-wise it ignores all routing information and turns every device it hits into a switch (broadcasting itself on all ports).

EDIT: The only exception are devices with firewall firmware of course. Those device have a chance to drop the package first.

So if your "Blackhole" is working _that_ is definitively a bug. Otherwise there would be no need for firewalls at all.

it's a bug because of bad implementation of worms.. "magical traffic which defies all rules?"
also the use of FW's is ingame not good implemented (yet).
ALL network packets should ALWAYS follow the given route or vLan. - otherwise we would have no Internet and no fun ingame ;)

a Router/managed Switch can "irL" just be compromised if you hack it directly (ingame tcp/23) - with UNIcast on the management IP.
an unmanaged switch can just be "hacked" with physical access.

Worm traffic is BROADcast .. even hacking an tomato router (which you have maybe at home from your ISP) would not get hacked
--> the router/swich would just suffer in performance if the traffic is overwhelming
An router/switch will never read the data inside the packets - just the headers of the packets. only exception - the packets are for him self.

A Worm implementation should be more like:
- Worm traffic follows the rules of Networks ;)
- Worms should increase the traffic (in steps)
- Worms should infect over time other reachable consumers and producers which lead in even more traffic.

An FW would be useful for packet inspection --> a Worm hidden in "legit traffic on ex tcp/80, 443, ..."

But all beside - the best approach for Worms is the elevator ;)