'Pentest' proofing / WAN / IPSEC
-
Our Head company is going to have an external company perform some pentesting on our networks. I don't believe they are a fan of pfsense sense...
Is there anything I can do that will highlight and flag any tests they might be performing on our networks (WAN) so as to increase their confidence in our setup?
They will be allowed access to the network via our VPN and then 'look around'
-
Snort would be the tool of choice to detect, log or even block for example portscans and other hijacking techniques. That would be a real pain in the ass for them.
But for Snort you need time and a lot of patience until you have found the right settings for your network.
-
They will come into the network on a known IP - could the filters/rules be restricted to an internal IP address on the network?
-
@timboau-0 said in 'Pentest' proofing / WAN / IPSEC:
They will come into the network on a known IP - could the filters/rules be restricted to an internal IP address on the network?
Why would you want to do that? Is your goal here to simply make the pen testers look incompetent by blocking everything they attempt from their IP address, or is your goal to improve the actual security of your network? I hope your goal is the latter (improving the overall security of your entire network).
If the testers are being allowed into your internal networks via the VPN, then 90% of your firewall's effectiveness is sort of bypassed from the get-go. You need to make sure you have plenty of internal controls on endpoints (such as anti-virus clients and perhaps also host firewalls on LAN workstations and servers), and that you have strong passwords on internal hosts. You also need some kind of IDS (intrusion detection) on your internal hosts to detect things like repeated login attempts for someone brute-forcing a password, for example. There are applications for Windows and Linux clients that scrape Event Viewer and other logs to find security issues and can generate alerts for them.
Sure you can install an IDS/IPS such as Snort or Suricata on the firewall, but it won't be able to examine the actual VPN traffic at all since it's encrypted. You would need to put the IDS/IPS on the LAN interfaces and any DMZ interfaces you may have on the firewall. If you have never used an IDS/IPS and are not experienced with setting one up, then now- right before a pen test- is NOT the time to learn. Configuring an IDS/IPS properly is a big job.
Back to your VPN configuration, you need to have that pathway locked down with firewall rules to severely limit the traffic allowed over the VPN. For instance, most companies would allow only RDP and maybe SSH across the VPN, but nothing else. And you would want 2-factor authentication for users logging in through the VPN if possible. And depending on your internal network configuration, it might be possible to limit the VPN access to a small number of internal hosts (i.e., don't give the VPN tunnel access to just any and all internal hosts if you don't have to).
I know it's hard to think of it this way when your network is being prodded and you feel your reputation is on the line, but the pen testers are your friend. They will help you find potential holes or weak spots in your network security and then help you patch them up.
-
@bmeeks Hi and thanks! Yes that is the considered response I was after :)
I'm thinking the Pentest is going to produce lots of areas we can improve the network.
Ideally what I was after is some visibility (not blocking) as to what they are doing so that I have a little evidence that we are able to monitor them successfully on the network.
I think the worse result for a self managed network is that they came they poked they tested and we didn't see a thing...
I don't currently have IDS or IPS enabled on the network - to date its not something that's really been considered. I can see there are plenty of commercial rules which could help simplify this if we were to move down this route later on.
Agreed letting them into the network does give anyone a great head start!
Restricting ports and IP ranges certainly wouldn't be a bad addition to the rule set and very easily achieved.
Do you have any recommendations for log scrapers (and a guide for configuring things to look for) Ive felt previously it was a little like IDS in that it takes a bunch of time to sort the goodness from the endless streams of data. In the IDS scenario you dont often get any time to train or know what to look for.
Thanks again
-
There are both paid and free open-source HIDS (Host Intrusion Detection Systems) out there. The paid versions frequently offer fancy central console software for installing the client on systems and reading and consolidating the logs and alerts produced by the HIDS.
Here is one open-source product: https://www.ossec.net/.
Here is a popular paid version: https://www.solarwinds.com/security-event-manager/use-cases/intrusion-detection-software.
And of course the veritable Tripwire platform. It is one of the oldest and is very good, but can be a challenge to administer without experience: https://www.tripwire.com/.
The links I included above are just a random sampling of what is out there. Google the term "hids software" for a more complete list. Typically HIDS consists of file integrity monitoring and some degree of log monitoring. So these tools can sense when a file is changed and log an alert about it. The log monitoring usually is looking for signs of nefarious activity such as repeated "bad password" messages that might indicate a brute-force password guessing attempt is happening.
Network security is more than just looking for things over the network or in logs. It is also vital that you keep tabs on the boring stuff like making sure access permissions are removed and/or logins are disabled for folks who leave the company or folks who might be temporarily restricted from the premises. My old company called these employee disciplinary periods "decision making leave" (or DML) where you were sent home for some period of time to contemplate your "sin" and get your head straight again. Unless your initial sin was egregious, you got one free DML. Your next "sin" would usually be fatal, though, and you would be terminated. Either way, during these DML periods, and certainly immediately upon termination, that employee's network credentials were suspended. In fact, certain IT guys were the very first folks Human Resources contacted when one of these actions was started. The IT Security team would know before the poor employee himself...
.In terms of monitoring what the pen tester guys are doing, you would need a way to send their unencrypted datastream to an IDS. To get the unencrypted data, you will need to grab it after it has come out of the VPN tunnel (from the point of view of inbound data into your LAN). Usually you would be able to see this on the LAN interface, so if you installed Snort or Suricata there, you should be able to see the traffic. My suggestion would be to use Snort in IDS mode and get yourself a Snort Subscriber Rules subscription. Then you can download the Snort rules and enable an IPS Policy such as "IPS - Balanced" in IDS mode. That means no blocking. You want to see what is happening and alert on it for now. Later, as you gained experience tuning the rules and administering the IDS, you could switch to IPS mode and start blocking things.
-
WOW lightening response!
I'll investigate those and have a look -
The VPN comes through pfsense (NAT'ed) to a SoftEther VPN server and from there I could see it coming back onto the LAN for monitoring (I think)
-
@timboau-0 said in 'Pentest' proofing / WAN / IPSEC:
WOW lightening response!
I'll investigate those and have a look -
The VPN comes through pfsense (NAT'ed) to a SoftEther VPN server and from there I could see it coming back onto the LAN for monitoring (I think)
Yes, or if you have a managed switch with port mirroring, just mirror the VPN server's port to a port where you have an IDS host. Some switches call them SPAN ports.
-
ummm both pfsense and the Virtual machine are on the same host (in a DC)
Does HyperV still have issues with promiscuous mode on vm's - think I might have run into problems with that previously..
(LOL after I switch the 2.4.5 back to 2.4.4 today so I can run more than one virtual processor!)
-
@timboau-0 said in 'Pentest' proofing / WAN / IPSEC:
ummm both pfsense and the Virtual machine are on the same host (in a DC)
Does HyperV still have issues with promiscuous mode on vm's - think I might have run into problems with that previously..
(LOL after I switch the 2.4.5 back to 2.4.4 today so I can run more than one virtual processor!)
Not sure about that. ESXi was what I used when I was active. Only experimented with Hyper-V once just for kicks.
