Question How to tie traffic from one ethernet port to another? (newbie security)

[onepointbrewing]

Hi everyone, I have basic networking knowledge, but this is stepping out of my knowledge base.

Am happy to educate myself through the wonders of youtube - I just need to know if its possible and what the terminology would be.

I have a server plugged into a managed switch (say eth:1). The server serves multiple clients on the same switch. I have ONE client plugged into another ethernet port (say eth:15) on the same switch. Is it possible to force eth:15 (the client) to only accept rx/tx data to/from eth:1 and block all access from all the other ports at a switch hardware level?

Essentially, I have some legacy hardware that only accepts pure TCP data using http: and not https: and it has ZERO authentication.

Obviously this is a real easy target for a 12 year old with a packet sniffer, so I want to mitigate as much as I can. I dont actually care if the packets themselves get sniffed as the data in the packets is not important, but by isolating one port (eth1 to eth15) at the switch hardware level it would appear like a hard cabled connection (server to client). I DONT want to use mac addresses of the server/client as a 14 year old would know how to spoof the mac address of the server. Using this idea would also mitigate a MiM attack.

As I said, Im happy to educate myself. I just dont know what I need to be researching

 

[kanewolf]

Hi everyone, I have basic networking knowledge, but this is stepping out of my knowledge base.

Am happy to educate myself through the wonders of youtube - I just need to know if its possible and what the terminology would be.

I have a server plugged into a managed switch (say eth:1). The server serves multiple clients on the same switch. I have ONE client plugged into another ethernet port (say eth:15) on the same switch. Is it possible to force eth:15 (the client) to only accept rx/tx data to/from eth:1 and block all access from all the other ports at a switch hardware level?

Essentially, I have some legacy hardware that only accepts pure TCP data using http: and not https: and it has ZERO authentication.

Obviously this is a real easy target for a 12 year old with a packet sniffer, so I want to mitigate as much as I can. I dont actually care if the packets themselves get sniffed as the data in the packets is not important, but by isolating one port (eth1 to eth15) at the switch hardware level it would appear like a hard cabled connection (server to client). I DONT want to use mac addresses of the server/client as a 14 year old would know how to spoof the mac address of the server. Using this idea would also mitigate a MiM attack.

As I said, Im happy to educate myself. I just dont know what I need to be researching

It depends on the switch capabilities. Some managed switches could have ACL (access control lists) which could restrict to the server MAC maybe from the specific switch port.

 

[Ralston18]

You have, per your post, stepped out of your knowledge base.

I am, likewise, stepping outside of my knowledge base.

However, as I understand your post and requirements, you may have also stepped outside of Forum rules.

Requiring that eth15 be forced to only accept rx/tx data intended for eth1 and block other ports is not what I would consider standard SOPs.

What is the reason and/or justification for that requirement forcing eth15?

What is the environment that makes you concerned about what "12/14 year olds" (AKA unskilled hackers perhaps) might do?

Or cause you to explicity post about not wanting to use mac addresses.

Where and how does that legacy hardware fit in?

What legacy hardware? Details?

For the moment, I will defer to others who chose to post additional questions, comments, and solutions.

Just my thoughts on the matter.

 

[bill001g]

So your problem is you have a client machines that is not secure for some reason and are afraid another client on the same switch might attack you ?

So very basic stuff will prevent this. First just by design a switch prevent anyone from seeing the traffic that is not sent to their port, you need special features in the switch to be able to do this. Next TCP connection have the concept of "established".
In the simple way your client machine always send the very first packet to open the session to the server. The client machine will not accept a incoming connection from the server to start the connection. In addition you can set the windows firewall on the client to block all incoming sessions.

If someone where to attempt to spoof the server mac address it would cause massive problems for every other client attempting to access the server. It to a point is technically possible to try to main in the middle attacks against all users using the server but most times the server will detect it and put out error/warnings. It will cause massive performance issues.

There really is no way to prevent this kind of attack on a lan. You generally have physical security to prevent unknown people from hooking stuff up. It is likely well outside your abilities but the way this is commonly done in large enterprise installs is to use 802.1x. There are many levels you can implement. Simple one is a userid and password to connect to the switch. It can be very advanced, it can use a microsoft domain controller. In this case you can use things like certificates to ensure only machine that are authorized and maybe even have correct patch levels can access the system.

This though would not prevent a authorized user from hacking on your network. You to a point might be able to limit what software is installed on a company machine but this is of limited value.

You are back to you have to be able to trust the people you let in your building and connect directly to your network.