OK so this is a couple days combined. We left off with getting access to the WebGUI and making sure everything was good to go for connectivity. I put a hold on configuring additional firewall rules for OpenVPN but will look to getting that up in the next day. I spent some time checking out the new data I was logging for external access attempts. Eventually this information will be sent to a log management solution for better data gathering, more on that later.
Over the last couple days I worked on getting Snort installed and configured as well as setting up the Dynamic DNS service I use. DynDNS (dyn.com) is a nifty service that allows you to have a dynamic public facing IP address (typical for residential ISP customers) but you can assign a static DNS record to that interface. The service utilizes an agent based, manual, and/or account based method to update the host information. Most broadband routers and SOHO style firewall services have the ability to communicate with Dynamic DNS services. The typical free solutions give you some pre-defined domains to use, but if you want to get fancy, you can just create a CNAME with your current DNS host and point it to the DynDNS domain for example: remote.mydomain.com --> remote.dyndnsdomain.com.
Now that all that is settled, we can proceed to getting the IDS/IPS up and running. For that we add the snort package. If you are following the guide from SmallNetBuilder, then you see it is pretty simple. Always remember when configuring your IDS/IPS, only turn up the rules/Categories related to your network. For example, if you do not have Oracle Servers, then don't turn on the Oracle rules. This cuts down on the amount of alerts you will receive from the IPS. If this is your first IPS solution on your network, you may also just want to enable the IDS portion first just to see what is going on. If you see immediate activity that you know should not be occurring, then enable the IPS portion for that specific activity. Upper management tends to frown on bringing the business to a screeching halt because your custom application looked like bad network activity to Snort. For a home network straight Snort is good enough, but for business you may want to consider the SourceFire appliance. It is much easier to call support to fix something ASAP rather than scouring Google.
I initially turned up the block rules for the WAN and left them off for LAN. I had some issues though with the blocking on the WAN since it was blocking the pfsense package management traffic. I am currently just in IDS mode on both interfaces since my main goal here was to see what is happening on the home network. Later I may build up some suppression/whitelist rules,
The final part of the guide instructs you to install IP-Blocklist. The application is basically a managed blackhole solution for the firewall side of pfsense. You configure it to look at some blacklists and it will drop packets for IP addresses on those lists. This is great if you want to block traffic from specific countries. The IP-Blocklist is no longer fully supported by pfsense, they offer pfblocker which works much the same way and is added to your Firewall controls. I did not do much to configure this yet. Again I want to see where traffic is coming from then I will look at initiating some blocks.
Once Snort was running I did notice some errors popping up repeatedly on the console. Many where due to ACPI errors. I found some discussions pointing to a variety of items for FreeBSD and hardware issues. The one that the issue may be related to was with the onboard Realtek NIC. Disabling the NIC in the BIOS and rebooting seemed to stop the errors. Of course that angered pfSense and forced me through the config prompts. After fixing all that, re-enabled the onboard NIC and received the ACPI errors again. Rebooted using Safemode and a number of errors were auto-corrected. Unlike a Windows Safemode reboot, no services were disabled.
This is where I pretty much called it a day. Next up is adding this new found information to Splunk.
No comments:
Post a Comment