Firewall Rules for second network
-
I'm trying to setup our network so it can pull this one shared folder off of another network. The two networks are connected via cat5e from our pfsense firewall to the other network's switch. Our network needs to be able to access \192.168.0.10\FOLDER . It seems I am able to access anything on that other network as long as I have valid credentials.
What I'm trying to do is prevent the other network from accessing any of our files. Is there a way to do this with the firewall? TCP is blocked on the firewall, but UDP is not. Thats the only restrictions I have in place.
I had asked the question above on another forum and they gave me the following:
OPT1 Firewall
Rule 1:
Action: Pass
Interface: Opt1
Protocol: TCP
Source: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
Source Port Range: FROM = 135 ; TO = 135
Destination: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
Destination Port Range: ANY
Description: Allow My Network to Access files on other networkRule 2:
Action: Pass
Interface: Opt1
Protocol: UDP
Source: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
Source Port Range: FROM = 137 ; TO = 138
Destination: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
Destination Port Range: ANY
Description: Allow My Network to Access files on other networkRule 3:
Action: Pass
Interface: Opt1
Protocol: TCP
Source: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
Source Port Range: FROM = 139 ; TO = 139
Destination: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
Destination Port Range: ANY
Description: Allow My Network to Access files on other networkRule 4:
Action: Pass
Interface: Opt1
Protocol: TCP
Destination: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
Destination Port Range: FROM = 135 ; TO = 135
Source: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
Source Port Range: ANY
Description: Allow My Network to Access files on other networkRule 5:
Action: Pass
Interface: Opt1
Protocol: UDP
Source: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
Source Port Range: ANY
Destination: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
Destination Port Range: FROM = 137 ; TO = 138
Description: Allow My Network to Access files on other networkRule 6:
Action: Pass
Interface: Opt1
Protocol: TCP
Source: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
Source Port Range: ANY
Destination: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
Destination Port Range: FROM = 139 ; TO = 139
Description: Allow My Network to Access files on other networkRule 7:
Action: Reject
Interface: Opt1
Protocol: UDP/TCP
Source: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
Source Port Range: ANY
Destination: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
Destination Port Range: ANY
Description: Reject anything else but allowed traffic between explicit src & DestRule 8:
Action: Reject
Interface: Opt1
Protocol: UDP/TCP
Destination: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
Destination Port Range: ANY
Source: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
Source Port Range: ANY
Description: Reject anything else but allowed traffic between explicit src & DestRule 9:
Action: BLOCK
Interface: Opt1
Protocol: UDP/TCP
Destination: TYPE = ANY
Destination Port Range: ANY
Source: TYPE = ANY
Source Port Range: ANY
Description: DROP Remaining packetWAN FIREWALL:
Action: Pass
Interface: WAN
Protocol: TCP
Source: TYPE = ANY
Source Port Range: 1723 (PPTP)
Destination: TYPE = ANY
Destination Port Range: ANY
Description: Allow PPTP connectionsAction: Pass
Interface: WAN
Protocol: TCP
Source: TYPE = ANY
Source Port Range: 443 (HTTPS)
Destination: TYPE = ANY
Destination Port Range: 443 (HTTPS)
Description: Allow HTTPS connectionsAction: Pass
Interface: WAN
Protocol: TCP
Source: TYPE = ANY
Source Port Range: 80 (HTTP)
Destination: TYPE = ANY
Destination Port Range: 80 (HTTP)
Description: Allow HTTP connectionsAction: Pass
Interface: WAN
Protocol: TCP/UDP
Source: TYPE = ANY
Source Port Range: 53 (DNS)
Destination: TYPE = ANY
Destination Port Range: 53 (DNS)
Description: Allow DNS lookupAction: REJECT
Interface: WAN
Protocol: ANY
Source: TYPE = ANY
Source Port Range: ANY
Destination: TYPE = ANY
Destination Port Range: ANY
Description: Rejects all portsLAN FIREWALL:
Action: Pass
Interface: WAN
Protocol: TCP
Source: TYPE = ANY
Source Port Range: 443 (HTTPS)
Destination: TYPE = ANY
Destination Port Range: 443 (HTTPS)
Description: Allow HTTPS connectionsAction: Pass
Interface: WAN
Protocol: TCP
Source: TYPE = ANY
Source Port Range: 80 (HTTP)
Destination: TYPE = ANY
Destination Port Range: 80 (HTTP)
Description: Allow HTTP connectionsAction: Pass
Interface: WAN
Protocol: TCP/UDP
Source: TYPE = ANY
Source Port Range: 53 (DNS)
Destination: TYPE = ANY
Destination Port Range: 53 (DNS)
Description: Allow DNS lookupAction: REJECT
Interface: WAN
Protocol: ANY
Source: TYPE = ANY
Source Port Range: ANY
Destination: TYPE = ANY
Destination Port Range: ANY
Description: Rejects all portsDoes this look right?
-
You need to choose either source port or destination port for the rules. Not both at the same time due to how NAT works.
e.g.
On LAN:
Action: Pass
Interface: WAN
Protocol: TCP
Source: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
Source Port Range: ANY
Destination: TYPE = ANY
Destination Port Range: 443 (HTTPS)
Description: Allow HTTPS requestsOn WAN:
Action: Pass
Interface: WAN
Protocol: TCP
Source: TYPE = ANY
Source Port Range: 443 (HTTPS)
Destination: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
Destination Port Range: ANY
Description: Allow HTTPS connectionsAs to the sharing thing, you can simply restrict access between the 2 networks to only the specific file share host's IP. However, I highly recommend that you actually work on Systems security to begin with.
-
What would you recommend system security wise? I just changed the way the firewall was, which fixed the wan issue. There really isn't more I can see that has to be done. Ports are closed from the outside other than HTTP, HTTPS, and DNS. Any other recommendations?
Also, do I need to have the PPTP port open on the WAN firewall if I'm using the built in PPTP with pfSense or is that automatically opened?
-
Right now I have this on the PPTP VPN firewall rules, so would I need that for the WAN also?
Action: Pass
Interface: PPTP VPN
Protocol: *
Source: TYPE = PPTP Clients
Source Port Range: *
Destination: TYPE = LAN Subnet ; ADDRESS = 10.1.10.0 / 24
Destination Port Range: *
Gateway: 10.1.11.1
Description: Allow PPTP Connections -
Lets forget about the second network issue for now. I thought I had this firewall setup correctly, but its not working fully. I'm trying to check email, ex. pop.comcast.net via Outlook … Thunderbird... Doesn't matter what client. Comcast is an example of the email server. It uses Port 110. I have 110 listed in the LAN and WAN, but its not letting me check it. Same for FTP. The FTP port 21 isn't in the screen shots because I added it after, but its the same settings as the others with the exception of the port... should be 21.
Here is screen shots of the following rules I have set in place:
LAN - http://delranems.org/chris/pfSense/LAN.png
WAN - http://delranems.org/chris/pfSense/WAN.png
PPTP VPN - http://delranems.org/chris/pfSense/PPTPVPN.png -
What would you recommend system security wise? I just changed the way the firewall was, which fixed the wan issue. There really isn't more I can see that has to be done. Ports are closed from the outside other than HTTP, HTTPS, and DNS. Any other recommendations?
Also, do I need to have the PPTP port open on the WAN firewall if I'm using the built in PPTP with pfSense or is that automatically opened?
On PPTP, yes, you need to allow PPTP port on WAN. Also, the appropriate subnet assigned to PPTP clients need to have another set of rules to allow it access to your LAN(s).
As for systems security, you can start by disable automatic file shares in windows. Make sure all file shares require a username & password to mount. Also, this means that all computer user accounts should have unique passwords assigned.
Even common fileshares should have a fixed password/ username to ensure that unauthorized users don't gain access. Only users who need access to the fileshares will hold the password.
Alternatively, if you had set unique usernames and passwords for all clients, set the explicit sharing permissions and add each user account manually to be allowed to read/ write/ execute on the share.
If you have a Domain and AD server, customized security can be loaded upon logon. If not, registry scripts and vbscripts are a good way to securing the systems by blacklisting what the clients can access.Edit:
Your PPTP rule on WAN is incorrect. In this instance, the remote computer is the client. Hence, the rule should have the destination port as PPTP. Not the source port.You need to understand some basic networking concepts. Basically, if you have a client and server hosting certain services, this is how the data flow occurs:
Source –--> Destination format
client (random port: 49152) –sends request for data--> server (service port: 80)
server (service port: 80) --returns requested data--> client (random port: 49152)So you see, the server's port doesn't change.
Data returns from the same port that it is requested from. Since your PPTP server is the pfsense box, then remote clients will connect to the pfsense as the destination and the service port of 1723. Similarly, your pfsense to send data back to the clients with the source port of 1723. -
On the FTP issue, search the forums for "FTP helper". The main issue is that port 21 is used to establish a connection. Once that connection is established, the server & client negotiate to open up more ports for data transfer.
Unfortunately, since you only allowed 21, the data packets coming in on other ports are dropped by pfsense (it wasn't involved in the negotiation process and doesn't know what additional ports to allow through).To help solve this, there is a ftp proxy which helps the firewall get involved in the negotiation process. TBH, you seem like you need a real full UTM appliance with working Layer 7 more than a pfsense box if you want to be that anal on clamping down the connections.
IMO, you don't need such an anal WAN side ACL. By default, due to how NAT works, the WAN already rejects incoming connections that are not initiated by a client on the internal network.
You can simply ditch the deny all rule on the WAN rules. Your clients are already restricted in what connections are allowed to be initiated due to the LAN side rules.Basically, you only need:
Allow source any, destination WAN address w/ port PPTP on the WAN rules list to allow the PPTP connections to be established. If you need web access to the firewall, duplicate the rule for HTTP(s) instead of PPTP. Ditto for SSH.
-
As for the PPTP issue, I already had seen that last night and changed it. The other issue with the PPTP clients connecting but not being able to see anythign on the network, I had the PPTP server address the same IP as pfSense was. Once I changed the IP to an unused IP and the network, everything went fine.
As for systems security, you can start by disable automatic file shares in windows. Make sure all file shares require a username & password to mount. Also, this means that all computer user accounts should have unique passwords assigned.
Even common fileshares should have a fixed password/ username to ensure that unauthorized users don't gain access. Only users who need access to the fileshares will hold the password.
Alternatively, if you had set unique usernames and passwords for all clients, set the explicit sharing permissions and add each user account manually to be allowed to read/ write/ execute on the share.
If you have a Domain and AD server, customized security can be loaded upon logon. If not, registry scripts and vbscripts are a good way to securing the systems by blacklisting what the clients can access.As for the system security, all of that has already been done a while ago when I first setup this network. Security is setup on each folder that is shared out. It goes by the username that the person is logged in with. If they don't have access to that folder, it will just deny their access, it won't let them try to use a different username and password unless they log off and log back in as another user. Even the printers require certain usernames to print to them. I think security wise as for file sharing and internal networking, I am good. The only time a user will be prompted with a username nad password is if they are connected via PPTP and are not on the domain, or they are connected to our network via wireless or wired and are not on the domain.
Now for the FTP issue, I'm not trying to be anal with the firewall. I just don't want users playing games such as WoW or any type of high bandwidth usage game. So I figured if I block all incoming connections other than what I allow, it will prevent them from doing so unless the game uses port 80 as a fallback such as AIM or Skype or Yahoo do.
-
Right. That all looks fine. The thing is, if you block the outgoing connections on other ports, then it follows that the games will be blocked. By virtue of the NAT, a client must open an outbound connection before a remote host can pass through on the WAN.
Since you're already blocking the "illegitimate" connections going out (on your LAN side block all), it follows that you don't need to restrict on the WAN side. You just need to remember that connections are a two-way thing.
The restricting on the WAN side is more useful for PBR and perhaps, to stop attacks on the WAN. For the latter, using an IDS like SNORT with accompanying rules as a IPS is probably more useful. -
So what you are trying to say is just remove all of the rules on the WAN side, including the block all? Then, in theory, I wouldn't have to open a port on the WAN side since there is no block and just manage the firewall mostly on the LAN side?
-
I also can't seem to ping … ex. DES-DC4, but I can ping its ip. Am I missing a port? I don't see any that I could be missing..
-
So what you are trying to say is just remove all of the rules on the WAN side, including the block all? Then, in theory, I wouldn't have to open a port on the WAN side since there is no block and just manage the firewall mostly on the LAN side?
Yes. In effect, you remove all the WAN side rules including the block all except for services you need to specifically allow on WAN.
Such rules that need to be there would be OVPN allow rule and port forwards (NAT) rules.
Also, if you need to allow WebGUI access remotely, then you need to allow HTTP/ HTTPS (depending on which you use) destined for the WAN address as well.What can't you ping? If you want to ping the WAN address, you need to add an allow rule on WAN for ICMP.
-
Sorry, I forgot to finish that statement. I connected via PPTP and I'm able to ping an ip (10.1.10.4) but when I try to ping des-dc3 or any other name, its unable to reach the destination. I thought maybe I'm missing a rule somewhere? Or maybe my dns forward isn't right?
-
Sorry, I forgot to finish that statement. I connected via PPTP and I'm able to ping an ip (10.1.10.4) but when I try to ping des-dc3 or any other name, its unable to reach the destination. I thought maybe I'm missing a rule somewhere? Or maybe my dns forward isn't right?
Did you add an allow rule for the OpenVPN subnet to ping any destination? Presumably, you did not include an allow all due to security.
-
I have to allow OpenVPN even though I'm using the PPTP on pfSense and not OpenVPN? Also, I can't seem to make an ftp connection to any ftp. I tried ports 21, 20, 1023, 1026, 1027. Should I just remove the block on the LAN and move it to the WAN?