|
OpenBSD Security Functionally paranoid! |
|
Thread Tools | Display Modes |
|
|||
pf - controlling port forwarding inside the network
Hello in my network I only allow certian ports in and out however some users have figured out how too redirect port 80. How can I prevent this from happening?
I know one of the ways is though windows internet connection sharing. |
|
|||
Basically I have my isp. Which goes into a openbsd box on eth0. Then pf nats and filters everything and provides Internet for the internal computers on eth1. One of the users behind the eth1 has internet sharing enabled and is broadcasting wireless. I basically want to block everything except for his traffic to that one machine.... (static ip)
Isp --> openbsd --> his machine (with internet sharing turned on) --> other machines through his connectio I basically want to block the other machines through his computer |
|
||||
Congratulations. You have a user who is operating a NAT router, just like you are. Yours is OpenBSD with PF, his is Windows with ICS.
All of the traffic routed through his workstation will appear to come from it, or be destined for it. However, the Time-To-Live (TTL) value may be greater than 1. The TTL may be greater than 1 for traffic that isn't going to or coming from his private network, also. This is not a guaranteed way to differentiate. You would have to implement a Deep Packet Inspection facility, and even then, you may still have difficulty differentiating between workstation-specific traffic and traffic routed through it. For inspecting the contents of the packets, which PF does not do, OpenBSD has relayd(8). This might offer a partial solution. See reyk@'s paper from last year on recent advances in the tool, and the relayd.conf(5) man page for the scope of the analysis it can perform. You are entering an "arms race" with your user. If you make changes to attempt to block his private network but not his workstation -- such as setting TTL to 1 for all traffic destined to it -- he can circumvent those kinds of restrictions. All he needs is Google, or Bing, and a little time. If you cannot control your user -- such as having him agree to approved encryption and security on his wireless network, and approved devices to connect, you have two more options: 1. Block traffic between his workstation and the rest of the LAN by placing it in its own subnet, and do not permit traffic to route between the subnets. If you are sharing the same Ethernet segment, you can block IP packets on the LAN this way, however you cannot block non-IP Ethernet frames. With an alias address on your router's NIC, he and his network can reach the Internet but not any other IP device on your LAN.2. Block him entirely. Last edited by jggimi; 13th June 2014 at 10:14 PM. Reason: clarity |
|
||||
I would have done this first. When he came to me complaining that he couldn't get to the internet, I would have made the reason very clear why I blocked him...and why I would do so again should I suspect he is violating the rules of using my connection a second time =)
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice. |
|
||||
Here's an example configuration of a DMZ subnet sharing the same Ethernet segment as a LAN. The OpenBSD router has a NIC with two assigned addresses, one on each subnet. The additional address (and subnetting) is configured with the alias operand of ifconfig(8).
All devices use DHCP for address assignment. The isolated device is given its private subnet address by DHCP, assigned by MAC address. The DMZ device must be trusted to not alter the MAC. The DMZ is on 10.99.99.0/30, which is four addresses: the network address (10.99.99.0), the two endpoints (router 10.99.99.1 and DMZ device 10.99.99.2), and the broadcast address (10.99.99.3). The LAN is on 10.1.1.0/24, with the router at 10.1.1.1. The hostname.<nic> file for the router has both addresses and subnet sizes: Code:
inet 10.1.1.1/24 alias 10.99.99.1/30 Code:
option domain-name "<your domain>"; option domain-name-servers <my nameservers>; shared-network <my network name> { subnet 10.99.99.0 netmask 255.255.255.252 { option routers 10.99.99.1; host static-client { hardware ethernet <my DMZ device's MAC address>; fixed-address 10.99.99.2; } } subnet 10.1.1.0 netmask 255.255.255.0 { option routers 10.1.1.1; range 10.1.1.101 10.1.1.200; } } Code:
pass all block from 10.1.1.0/24 to 10.99.99.0/3 block from 10.99.99.0/3 to 10.1.1.0/24 pass on <my nic> proto {udp tcp} from any to any port {67 68} |
|
||||
Quote:
I didn't realize you could run a shared net like this. Very interesting.
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice. |
|
||||
Yes. I thought of this because a year or two ago, someone posted here recommending that we isolate Windows platforms each to its own /30. A little lightbulb went on. And I remembered it today when EverydayDiesel described his issue.
A DHCP "fixed" address assignment is no more secure than a static IP address. There must be trust by the admin that the user will use them. If the system cannot be trusted, then the admin must select one of these three options:
Last edited by jggimi; 14th June 2014 at 02:28 AM. Reason: typos. Sheesh. |
|
||||
I do recall the /30 discussion =)
This is probably the reason I never investigated shared-network, as I'd rather have a bit more control over my users (my wife would kill me for saying that heh). I have a vlan capable switch and a port-limited firewall, so vlans just made more sense for me, but deploying a separate segment (as you've mentioned) is another great option. And while certainly humorous, I don't think the user would agree with your interpretation of /30 as meaning "pounds of sledgehammer" required =P
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice. |
|
|||
i dont know if it helps at all but i did notice this in the tcpdump output last night.
Code:
rule2/(match) block in on xl1: 192.168.0.1.500 > 192.255.255.255.500: RIPv2-resp[items 1] : {192.168.1.0/255.255.255.9}(1) |
|
||||
1. It's not an "attack" - it's a broadcast of routing information from his router to any others in 192.*.*.* that might be interested in reaching the subnet he controls. If you were cooperating rather than in conflict, ripd(8) could be utilized to automatically update your routing table.
2. You're already blocking these packets, and without a running routing daemon such as ripd, you would have nothing "listening" to the data anyway. |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Port Forwarding with Dual WAN Connections | alpha202ej | OpenBSD Security | 0 | 14th December 2011 02:05 AM |
Controlling a RS-232 Serial Console from a Shell Script | ishikawanakano | Programming | 0 | 9th January 2009 10:00 PM |
port forwarding | ikevmowe | OpenBSD Security | 13 | 21st November 2008 06:03 PM |
VNC port forwarding help | revzalot | OpenBSD Security | 3 | 10th September 2008 06:59 AM |
A P2P controlling tool at last - ipfw-classifyd | s0xxx | FreeBSD Ports and Packages | 0 | 3rd August 2008 09:49 AM |