HEP 2: Network Security Structure

[safaorhan]

This PR adds a HEP that describes how we can manage the internal network on a fundamental level
to prevent unauthorized access to our network and internet-connected devices in
the space.

---

👉	HEP 2: Network Security Structure
Authors	@safaorhan
Status	Active
Related PRs	#4
Related HEPs	-

Summary

This HEP describes how we can manage the internal network on a fundamental level
to prevent unauthorized access to our network and internet-connected devices in
the space.

Rationale

Hackers of all kinds of backgrounds would be common guests of our space. The idea
of "hacking a hackerspace" might sound exciting for some of them. Also, motivated
by curiosity, some of our members might try to tinker, configure, and eventually
break things on our network, rendering other hackers frustrated. These precautions
would help us contain possible hostile attempts.

Securing Physical Access to the Router

One of the easiest and most frustrating attack vectors is to gain physical access
to the router, follow the factory reset sequence on the hardware, and hence disconnect
all connected devices from the network. This would let the attacker reconfigure
the network as he'd like and create many further attack vectors.

We must keep the router in a difficult-to-reach place, possibly locked in a hard
plastic enclosure to discourage tampering.

Another layer to prevent and remedy physical access would be to issue surveillance
to the proximity of the router, so if anybody attempts to tinker, the community admins
would get notified of the attempt, possibly with picture evidence.

Storing Router Admin Credentials Securely

We should ensure that the credentials for the router's admin dashboard are stored securely.
The fewer people who know it, the better. We shall use the password manager of hackerspace's
Google account aside with other critical passwords.

Creating Multiple Wireless Networks

We shall create different wireless networks serving different purposes:

#	Type	Hidden	Criticality	Purpose
1	Infrastructure	Hidden	Most Critical	Security systems, smart sensors, automation devices live in this network.
2	Member Network	Visible	Critical	Computers and smartphones of the members, printers, 3D printers, shared or interactive electronics live here.
3	Guest Network	Visible	Less critical	Guests are allowed, temporary projects and experiments are welcome.

We shall not provide LAN access to the router since it's not easy to
control who is connected to what, and nowadays, wireless is fast enough.
If the router supports it, we can also isolate the wired network from the wireless one.

1. Infrastructure Network

If a device is meant to help operate the space and doesn't need others to interact with it over
the network, it shall live within the infra network.

Good examples of these devices are:

• A Raspberry Pi with HaOS installed
• A connected LED-light controlled by a PIR sensor
• A security camera
• An RFID reader that opens the door
• A smart switch that publishes to SpaceAPI

Changing the password of this network would be the most troublesome. But for security purposes,
we can schedule yearly maintenance time to update the infrastructure password.

2. Member Network

The usual network a member would connect their laptop or smartphone to. Shared electronics
that members would access should be placed in this network.

Some examples would be:

• 3D printers, so that members can send jobs over the network
• Regular printers and scanners
• Other tools and devices controllable by members over the network

We can change the password for this network a couple of times a year
as a security measure. And only let current members know the new password.

3. Guest Network

When guests arrive at the space for events and one-off visits, they can connect to
this network. So that they won't have access to the internet-connected tools. Also,
when someone wants to experiment with something, share the password with the attendees in
a workshop, create a new IoT device, or similar, they can use this network.

The SSID and password of the guest network can be placed in NFC tags and placed
on the walls. A QR can be okay, but less safe, since we have a wall of glass on the
roadside.

Lastly, we can change the password of this network frequently to deal with free
loaders, and since it would be really effortless to do it.

[theilgaz]

Do we need to provide Guest network? Nowadays everyone has their own cellular data. Maybe it's much better to prevent before anything happens.

[mrabdullahsahin]

While I agree with what has been written, will we also carry out additional work or planning regarding the following points?

• Keeping records of the identities of people connecting to the network and maintaining the necessary logs, in case a legal situation arises in the future.
• In my opinion, there should be a Guest Network, because due to internet costs, some people may have very limited cellular data and therefore may not be able to connect and use their computers. For this reason, a guest network should exist; however, logs should also be kept on this network as well.
• Will we also do any work or planning regarding internet filtering? Because some people may try to access gambling or other prohibited websites.

[safaorhan]

Do we need to provide Guest network? Nowadays everyone has their own cellular data. Maybe it's much better to prevent before anything happens.

Vodafone connectivity was really bad inside the space.

[safaorhan]

Keeping records of the identities of people connecting to the network and maintaining the necessary logs, in case a legal situation arises in the future.

I haven't done something similar before, do you have any experience setting up enterprise networks?

Will we also do any work or planning regarding internet filtering? Because some people may try to access gambling or other prohibited websites.

We can take this measure for Guest Network, but I'll vote for no router-level filtering for Member Network. Those filters have a bad rate of false-positives.

[guness]

A few things to consider:

• Default DNS settings on Router Level: (ie: 1.1.1.1)
• Turning off ISP Access to Modem (Some routers have this capability, some not).
• Creating a VPN for remote access to office network for everyone if it helps in anyway.
• An internal server with an SSH exposed to outside for remote access and control of the network by the managers(even a Raspi should be sufficient).
• A WiFi with VPN integrated in office.
• Device isolation on Guest network (maybe also in Member network). (Comes with some problems, ADB over WiFi etc.)

[mrabdullahsahin]

I haven't done something similar before, do you have any experience setting up enterprise networks?

No, I don’t have any direct experience. I only know that at my workplace they use tools like pfSense and similar solutions.

We can take this measure for Guest Network, but I'll vote for no router-level filtering for Member Network. Those filters have a bad rate of false-positives.

You’re right. In the long run, we might run into a different problem or situation.

[safaorhan]

@mbrksntrk do you have anything to share here

[safaorhan]

It looks like turktelekom provides has time based logging as a service: https://kurumsal.turktelekom.com.tr/bilisim-teknolojileri/siber-guvenlik/yonetilen-guvenlik-hizmetleri/paylasimli-5651-loglama-hizmeti

But I couldn't find anything for turksat kablonet.

@theilgaz can you check if they offer such a thing?

[mbrksntrk]

Öncelikle selamlar, hayırlı uğurlu olsun inşallah gelip ziyaret etmek de nasip olur diyorum,
I would like to suggest several additions and best practices to enhance the current network security proposal:

1. Physical and Device-Level Security

Physical protection should not be limited to routers and access points. It is equally important to secure cameras, printers, and other devices connected via Ethernet.

• MAC-IP Binding: We should implement MAC-IP binding to prevent unauthorized devices from using existing cables. For example, if a user disconnects a PoE security camera and plugs in their own laptop, they should be automatically blocked from accessing the network.
• Restricted Access: Networks containing "critical" devices should be blocked from accessing the internet. Additionally, services like DHCP should be disabled in these networks since the number of devices is usually fixed.

2. Wireless Network and Client Isolation

While creating multiple wireless networks is a good start, isolating SSIDs is not enough.

• AP Isolation: We must enable "Client Isolation" within the Access Points. This ensures that users on the same network cannot access each other's computers, phones, or other devices directly. This is especially vital for the Member Network to prevent internal security threats and to make anomaly detection easier.

3. VLAN Expansion and Authentication (Captive Portal)

The number of VLANs can be increased based on our needs (e.g., Staff, Member, Guest, IoT).

• SSID Visibility: IoT and Staff networks should have hidden SSIDs, while Member and Guest networks remain visible.
• Captive Portal: A Captive Portal should be used to authenticate all clients. By matching a device’s MAC address with verifiable user data (such as a phone number, member ID, or national ID), we can manage IP leasing and ensure compliance with local logging regulations (e.g., Law No. 5651).
• Access Methods: Members and staff can use username/password credentials for monthly IP leasing, while guests can log in via GSM OTP (One-Time Password) or a guest ID provided by management.

4. Firewall and Inter-VLAN Routing

A dedicated firewall is necessary to manage and define rules for traffic between different VLANs (IoT, Guest, Member, Staff, Management, etc.).

• Access Control Lists (ACLs): We can define specific rules such as: "Users can access printers on TCP port 9100, but they cannot access the printer’s web management interface on TCP port 80."
• Logging: The firewall must be configured correctly to provide logs. Keeping these logs for the legally required duration is essential for analyzing and resolving potential security incidents.

5. Configuration and Log Backups

A final point to consider is the backup of configurations and logs.

• Automated Backups: Configurations for the firewall, APs, IoT devices, and printers should be backed up automatically. These backups must be stored in an off-site location accessible only to hackerspace admins.
• Data Integrity: Critical logs and registries should also be mirrored to an off-site location to prevent data loss in case of a local system failure.

[mhalikosen]

I'd like to share some thoughts on how we can implement this ourselves.

Beyond internal network security, there's also a legal requirement: in publicly accessible internet networks, user access logs must be stored for two years.

We can either purchase a ready-made logging solution, or build our own using open-source tools. I've previously set up such a system using pfSense in a student dormitory.

There are open-source operating systems that turn computers into routers. The most popular ones are pfSense and OPNsense.

We need a physical machine with at least 2 network ports. It doesn't matter what it looks like. It could be a regular PC with a second NIC added, a Raspberry Pi, or a purpose-built 1U rack-mount appliance.

One port will be the WAN port, connected to the modem. This way, the system can access the internet, and there will be no other direct wired or wireless access to the modem besides this system.

The other port(s) will serve internal users and devices. A switch or wireless AP would be added here, but I'm not going into that since it doesn't affect how the core system works.

By default, every user connecting to the network will have no access to the internal network or internet. When they connect, a window will appear on their screen (this is called a Captive Portal) where they verify their identity via SMS using their phone number. Once verified, internet access is granted, and in the background, access logs will start being recorded along with identifying information, in our case the phone number.

For always-connected internal devices, we can create a MAC-based whitelist. To prevent MAC spoofing, we could ideally have internal devices connect through a separate physical port. (Of course, we also need to prevent unauthorized physical access to this network.) For people who are regularly at the space, the "remember me" feature on the captive portal can be used.

I haven't gone into too much technical detail. This system can be extended further based on our needs. Since we'd be using open-source, Linux-based operating systems, we can build custom solutions tailored to our requirements, for example integrating with other systems like a card-based entry system.