Introduction

Today, the time has come to enable routing between your networks and your classmate’s networks using dynamic routing. We will simulate a small Internet exchange point, so imagine you’re a small ISP (and so your classmates) and you want to establish a BGP peering with each other in order to be able to reach each other’s networks from your networks.

Also we will secure our networks using nftables firewall.

Materials

BGP routing

  • Install BIRD routing daemon on your router.
  • Configure BIRD:
    • There is a BIRD instance running on the backbone router 10.0.0.1. It acts as a route-server and has ASN 65000 assigned.
    • Configure your router to establish a BGP session with the backbone router. Pick your own ASN 650nn, where nn is $repo/meta/n (if you have only a single-digit n, write a leading zero in front).
    • Import routes from the route-server to your kernel routing table.
    • Export connected routes from your router to the route-server to share this routing information with others.
    • Make sure you’ve set a router ID of your router.
    • Try to restrict the imports for a private IP range 10.0.0.0/16. But we recommend to start with import all and export all.
  • Enable and run BIRD. After the BGP converges (max in a minute), you should see routes for other’s networks in your kernel routing table.
  • Make sure you’re able to ping the other student’s machines (router, ns1 and ns2).
  • Traffic destined to the other’s networks should go directly through the backbone switch. Other traffic (e.g. to the Internet) should go through the backbone router.
  • Disable NAT masquarading on your router, you have configured on the 4th lab. You should still be able to ping others and also the Internet. Think about why it was needed so far, and why it is not necessary anymore.
  • (65+0 points)

Firewall

  • Install nftables on the router.
  • Create a filter table and name it as you wish.
  • Create two chains in the table: one for restricting traffic destined to the router (subscribe the chain to the input hook), and second for restricting traffic forwarded through the router (subscribe the chain to the forward hook).
  • The default policy for the chains should be to drop the traffic (unless allowed by a selective rules in the chains). The selective rules should cover:
    • ICMP traffic should be allowed from everywhere to everywhere.
    • Connections established from the router or from any of your internal networks should be allowed in reverse direction. I.e. if your router (or e.g. ns1) does a DNS request to the Internet, the response to the original request should be allowed to pass the firewall. On the other hand, connections established from the outside should be dropped (except exceptions, see below)—this is already done by the defauly policy, so only a rule allowing the first use-case should be necessary.
    • SSH connections to your machines should be allowed from outside (selectively for each machine). Be carefull – you’re most likely connected through SSH right now, don’t you? ;)
    • BGP traffic from the outside to the router should be allowed.
  • Rules for both chains must be configured separatelly (due to the architecture of nftables) but you might use variables to avoid duplication. Think about which restrictions should go to which chain.
  • Make your firewall configuration persistent; it should survive reboots of the router.
  • Your firewall should be as restrictive as possible but at the same time it should not break services (SSH, BGP, etc.) configured so far.
  • Make sure, that if you run a new service in the future (e.g. DNS), you also adjust the firewall rules accordingly.
  • Don’t forget to allow access to the Twytter container from previous lab (gateway port 8000).
  • (35+0 points)

Bonus task

Bonus task will be announced soon. It will be about VLANs (which were not presented on the lecture, so it will require some self-study). Stay tuned!

hw/08/01-feedback

  • If you have any valuable feedback, please do provide it here.
  • Points are only awarded for feedback which is actionable and can be used to improve the quality of the course.
  • Any constructive criticism is appreciated (and won’t be weaponized).

(Total = 100+0 points)

Don’t forget to git push all your changes! Also, make sure that VM still works by the deadline—otherwise we have no way of grading your work.