Året er 1942, og Ferdinand Porsche har nettopp tapt anbudet for å produsere den nye Panzerkampfwagen VI “Tiger” med sitt uortodokse valg å bruke bensin elektriske motorer.
Dette var ikke en enorm suksess, og prototypen tok visstnok fyr under demonstrasjonen pga for mye vekt.
Men Ferdinand Porsche var en optimist, og hadde såpass stor tro på sitt design at han allerede produsert 90 chassier når han fikk beskjeden at kontrakten gikk til konkurrenten Henschel.
Dette var et problem, for ett land som nå var på defensiven, da kunne man ikke kaste bort så mye metall på noe som ikke bidro til å bedre situasjonen de var i mot slutten av 1942.
Albert Speer, minister for produksjon av krigsmateriell tok derfor kontakt med Porsche, og spurte om de hadde mulighet til å konvertere sin prototype til en PanzerJeger.
Det betyr i praksis at man finner det mest effektive kanonen for å ta ut andre tanks, og deretter monterer denne på toppen i et tårn som ikke lar seg rotere. Dette kostet mindre, og ga dem mye mer plass til å montere større kanoner enn de ellers kunne.
Porsche sa ja til dette, og slik ble Panzerjäger Tiger (P) Elefant født.
Spesifikasjoner:
Beskyttelse
20 cm armor
Kanon
8.8 cm PaK 43/2 L/71
Motor
2x Maybach HL120 592 hk
Max hastighet
30 km/t
Vekt
65 tonn
Besetning
6 stk
Om man ser på spesifikasjonene, så var dette en svært kapabelt Panzer Jeger. Den hadde en av de beste kanonene produsert til da, og kunne slå ut alt av motstandere.
Beskyttelse var enorm, og man kunne motstå nesten alt forfra.
Og når man måtte, så kunne man forflytte seg svært raskt på den tiden med 30 km/t toppfart på vei.
Problemet er at spesifikasjoner på et papir betyr ingenting, om det ikke fungerer slik i den virkelige verden.
Og det var her Elefanten fant sin skjebne.
Ved å legge på mer beskyttelse, større kanon og samtidig blokkert mye av luftkjølingen til
motorene samtidig, så ble det en katastrofe når de ble satt i drift under Kursk offensiven juli 1943.
Svært mange av de originale 90 tok fyr før de kom frem, og det var flere rapporter fra tyske og russiske offiserer at de ikke engang klarte å kjøre opp mindre åser for å komme i skuddposisjon.
Dette førte til at svært mange ble etterlatt av sin besetning, da de ikke kom seg noen steder.
Mye av dette kunne vært unngått med skikkelig testing, men Albert Speer lot seg overbevise av gode spesifikasjoner.
Den samme feilen gjør vi også den dag i dag, vi henger oss altfor mye opp i hva det står på ett produktark, fremfor å faktisk teste realiteten.
Jeg som jobber med sikkerhet har slike samtaler ofte med kunder. Man vil ha høyest throughput, med flest mulige sesjoner per sekund, samtidig som den skal inspisere alt, og stoppe det som var farlig.
Det gjør at vi produsenter blir smarte i hvordan vi setter opp våre produktark. Vi vil gjerne at det skal fremstå at vi kan levere på alle disse punktene samtidig, og gjerne til en lavere pris enn hva konkurrentene klarer.
Dette fører til situasjoner der kunder ender opp med løsninger som langt på nær er kraftig nok til å håndtere det de ønsker. Men når kjøpet er gjort, så må man jobbe med det man har, og enden på visa er ofte at man deaktiverer en eller flere sikkerhetsfunksjoner for å oppnå det throughput tallet man ønsker.
Det er ikke gøy å ende opp med en Elefant i server-racket sitt.
Derfor mener jeg det er svært viktig at man gjennomfører en Proof-of-consept, la oss produsenter vise hva vi er gode for. La oss demonstrere at det vi sier faktisk er sant.
Det er forskjeller, og de finner man i den virkelige verden, og ikke på glossy PDFer med store fine tall.
If you work with Palo Alto Networks firewalls, then this view is not new to you.
If not, then this is how the Detailed Log View from a standard Traffic log-line looks like. It contains a lot of information and helps you to figure out what has or has not happened.
But how many times have you not copy & pasted IPs, Domain-names or Threat-names/IDs to get more information from external sources?
For me, it’s plenty of times.
So let’s explore a cool feature of PanOS that has been around since the early beginning, and is not getting the recognition it should!
It’s simply called Log-links and is a feature where you can embed links directly into the Detailed Log View to attain information fast from external sources.
Here are the log-links I am showcasing today:
set deviceconfig system log-link ThreatVault.Src url "https://threatvault.paloaltonetworks.com/?query={src}"set deviceconfig system log-link ThreatVault.Dst url "https://threatvault.paloaltonetworks.com/?query={dst}"set deviceconfig system log-link VirusTotal.Src url "https://www.virustotal.com/en/ip-address/{src}/information"set deviceconfig system log-link VirusTotal.Dst url "https://www.virustotal.com/en/ip-address/{dst}/information"set deviceconfig system log-link Ping.Src url "https://centralops.net/co/Ping.aspx?addr={src}&count=5&timeout=1000&size=32&ttl=255&ip-version=auto"set deviceconfig system log-link Ping.Dst url "https://centralops.net/co/Ping.aspx?addr={dst}&count=5&timeout=1000&size=32&ttl=255&ip-version=auto"set deviceconfig system log-link NSlookup.Src url "https://centralops.net/co/NsLookup.aspx?domain={src}&type=255&server=8.8.8.8&class=1&port=53&timeout=5000"set deviceconfig system log-link NSlookup.Dst url "https://centralops.net/co/NsLookup.aspx?domain={dst}&type=255&server=8.8.8.8&class=1&port=53&timeout=5000"set deviceconfig system log-link DomainDossier.Src url "https://centralops.net/co/DomainDossier.aspx?addr={src}&dom_whois=true&dom_dns=true&net_whois=true"set deviceconfig system log-link DomainDossier.Dst url "https://centralops.net/co/DomainDossier.aspx?addr={dst}&dom_whois=true&dom_dns=true&net_whois=true"
This is just example log-links, and as you can see from the formatting, it’s easy to implement other sites as well. The {src} and {dst} are just pointers to the Source and Destination address in the Logs.
You need to use CLI to get this to work, so simply fire up Putty or any other SSH tool to get started:
Remember that you need to be in “configure” mode to do this. Then simply copy-paste the above paragraph and commit after it is done.
NB: The links show from first to last, so try to add log-links for the same site right after each other to avoid it looking really messy.
After it’s done committing you should see the following in the Detailed Log view(Remember to do a complete refresh of the GUI first.):
You have now a set of handy tools to check the IPs against Palo Alto Networks Threat Vault, VirusTotal, Ping from external destination, NSlookup from external source and Domain information.
When you press a link it will open a new window.
Here is a couple of expamples on how it looks:
And this is how it looks in CLI afterward:
It’s only your imagination that sets the limit on this feature, maybe you have internal tools as well you can now leverage directly into the log-links?
Have fun with it.
EDIT: Was a small typo in the first log-link.. this is now fixed. Sorry for everyone that was affected! 🙂
But even better if you also could remote control servers and desktops?
We can do that as well, but then we need a 3rd party to help us out! We are going to use Guacamole.
Let’s get started!
Step 1:
Login to PanOS, and locate the “Network” tab.
Choose portals, and “Add” or edit a previous you have already enabled.
You will then get this configuration screen, and I have highlighted the most important information.
Interface: I am using a loopback interface that is NATed behind my external DHCP address from my ISP. If I had a static external address then I would have used it here. This is the Interface that is needed to be reachable on port https/port 443. IP Address Type: Choose between Ip4, Ipv6 or both. IP4 Address: Here you get the choice of IP’s attached to the chosen interface. I just used 10.0.0.1.
Next is the Authentication tab, and here we need to enable an SSL/TLS Service Profile, and this is simply the certificate we will present the user connecting to the portal.
Let’s create one.
First, choose the Device tab on the top menu.
Then SSL/TLS Service Profile, and choose “Add”.
Here you simply define a name, and add a certificate of your choice. If you don’t have any certificates generated or imported, you can do it directly from this menu.
You can also choose the Min and Max version of SSL/TLS that can communicate with the firewall. I just leave the standard, since that does not include SSLv3 by default.
This is the certificate I am using, I generated it directly on the firewall.
Now that we have an SSL/TLS Service Profile in place, the next step is then to actually define who can log in and access our portal.
Just push “Add” in the Client Authentication frame to add a new rule. We have the possibility to tune the rules for individual operating systems as well.
But the most important part here is the Authentication Profile, which is outlined.
Let’s create one of those as well if you don’t already have one.
Back to the “Device” tab on the top menu.
Select Authentication Profile, and push “Add”.
Here you can configure the Authentication profile, I am just using the Local Database on the PA-220, but here you can choose between several types of user catalogs. You can also add 2-factor via the “Factors” tab as well. Look at my previous post to see how that works!
As you can see, we have many ways to authenticate users. Local as said is the simplest one to get started.
When you have configured the Authentication part of the portal, then we jump down to the “Clientless VPN” tab, and everything here is new in PanOS 8.0.
First, you need to check the “Clientless VPN” frame, to enable the settings.
Hostname: I use a dynamic DNS provider called DuckDNS, so I entered the full hostname here for the portal. IP will also work just fine. Security Zones: This one is important. Cause all traffic coming from the Clientless VPN will originate from this Zone. So if you create a Zone just for this, then you need to make sure you have a security policy that gives access to the features you want. DNS Proxy: We need to have a DNS Proxy in place on the firewall, so the firewall is able to process and redirect traffic as needed via the Clientless VPN.
The rest of the settings are self-explanatory. Let’s create a DNS Proxy!
Make sure you are on the “Network” tab on the top menu.
Choose DNS Proxy and press “Add”.
Make sure you check off Enable and give it a name. Next is to either choose an interface to inheritance the DNS servers from or enter them yourself directly into the Primary and Secondary fields.
The rest is not needed at the moment, but you can make DNS Proxy rules on how to forward DNS traffic. As an example, you can forward all DNS request for your domain to the internal DNS server, and the rest is forwarded to external DNS servers like googles.
Add it to the configuration and jump to the next part.
Since we still are under the “Network” tab, just jump to the Clientless Apps section, and press “Add”.
We will then get this simple configuration pane.
Name: What the application will be named when logged into Clientless VPN Application Home URL: FQDN or IP will work here. But remember to put HTTP or HTTPS in front. This will help as redirects are not always working perfectly. Application Description: A simple description of what the app does, will show when you hover the mouse over the Icon on Clientless VPN. Application Icon: You can upload customized icons if you want.
This is the apps I currently have live on my PA-220. Out of those, it’s the one on the top that is used the most.
Next is to add them to the Clientless VPN configuration.
Back to the Portal->Clientless VPN configuration, but now we jump to the “Applications” tab.
Here you just add apps via “Add”, and you can give different users/groups different apps.
So if this was in production in a large company, maybe IT-admins would get one set of apps, while HR another etc etc..
Next is the “Crypto Settings” tab, and this is just rules on what kind of protocols the PA-220 is allowed to use to communicate with the Clientless Applications you have defined.
So if you have an application that doesn’t support any of these, then PanOS will not be able to establish a connection. Here you can depreciate down to SSLv3 if you want.
We now have a working portal with Clientless VPN!
Step 2:
Clientless VPN is up and running, but we need Guacamole as well to be able to use Clientless VPN as a Remote Desktop tool!
I ran the script with “sudo root <script.sh>” and it gives you steps to follow. It will take around 10-20 min.
It will install Guacamole and all needed dependencies like TomCat, Java etc.
Done! Now the only thing you need is to log in and add the RDP connections you need.
Guacamole supports RDP, VNC, Telnet, and SSH.
When you have added some connections, then it’s time to test it out!
Step 3:
Log in!
The login screen is the same as before to get the GlobalProtect-client from the firewall.
Use a username and password that will authenticate, and you will get to this screen:
Notice in the right corner, that we are able to enter an Application URL directly as well, and that we also can retrieve the GlobalProtect Agent as well if needed.
I choose the “RDP Guacamole” application.
And it sends me to the internal login of Guacamole.
This is the URL String using Clientless VPN: https://clientless.duckdns.org/http-8080/192.168.1.165/guacamole/#/
Lets login.
I am greeted by my Recent connections on the top, and the list with all available connections.
As you can see, I have 4 RDP and 2 SSH connections.
It’s really nice to have SSH access to both the Raspberry Pi and PA-220. Makes it much easier to work and test anything from anywhere.
Midas and Midas1 are my cryptocurrency miners, and it’s nice to be able to maintain them from any device. I have more than once logged into them from my phone to verify that everything is running smoothly.
Let’s see how it looks.
There you have it, a full desktop experience via the browser. It behaves just like a regular RDP session would.
One of the new cool features on PanOS 8.0 is the fact that we now can enforce Multi-Factor Authentication on the Network.
Some might think that this is not a big thing but consider the fact that you now can enforce MFA on all internal applications without having to make any changes to the application itself. You can now add an extra layer of security on what matters the most, and stop credential theft, as long as nobody has stolen the phone from the user as well!
So let’s see how we go about testing it!
Created a fast workflow for my testing, to visualize how it will work internally on PanOS 8.0. As you can see we are able to intercept the requests coming to the gateway and enforce a Multi-Factor Authentication before we are allowed to connect to the application via the network.
Now let’s start to configure it!
Step 1:
Choose an MFA provider. PanOS 8.0 natively integrate with 3 out of the box:
Duo v2
Okta Adaptive
PingID
PanOS 8.0 can also integrate with other providers via Radius integration as well. But we will use Duo v2 since they are easy to setup and also free for personal use!
Step 2:
Create an account on Duo, and enroll your admin device.
Just download the Application, and scan the barcode!
You should get this screen when its done.
Step 3:
We now need to create users, you can either import from AD or do as I, and just create users that match up with the local users in the local database on the PA device.
I created the user “Glenn”, and installed the Duo application on my android phone and added the users there in the same way as you did with the admin user in step 2.
We are now ready to configure the firewall!
Step 4:
Go to Device-> Multi Factor Authentication-> Add.
Create a Certificate Profile if you don’t already have one, this is the certificate that the firewall presents to the chosen MFA vendor. If you don’t configure it on the MFA side, then this is mostly a cosmetic step.
Remember to select “Certificate Authority”, since I forgot on this screenshot.. the rest is not that important, as long as you fill something in.
Then you add the new certificate to the Certificate Profile, give it a name and keep all settings default.
Step 5:
When you have certificate profile, you are ready to fill in the rest to setup the MFA connection to Duo v2.
All the information you need is on the Duo page, just go to “Applications” and browse to “Palo Alto SSL VPN”, and just fill it in on the firewall. Leave the Timeout and Base URI as defaults and press OK.
After a commit, you will now have a working connection to Duo v2 for MFA, next is to use it for something.
Step 6:
Device -> Authentication Profile -> Add
Next is to connect the MFA profile to an Authentication Profile. The Authentication Profile is what decides what is the first authentication factor before we get to the MFA.
I chose “Local Database” since this is a home lab, and I have created my own users directly on the firewall. You could choose AD or other Catalog services we support. This is the first authentication factor.
Next is the “Factors” tab, and here you have to enable “Enable Additional Authentication Factors”, and then push “Add” and chose the MFA profile we created earlier.
Press Ok, and we have created an Authentication Profile.
Step 7:
After completing the connection to the MFA vendor, and creating an authentication profile we need to configure the firewall to be able to intercept and present the MFA page to the users.
First, we need to figure out what interface on the firewall that will present the page, and then assign an Interface Management profile to that interface that allows Response Pages, so the firewall can intercept and present MFA page.
After that, you need to ensure that the Zone that the interface is in has Enabled “User-Identification”, so we are able to process User information.
Go to Device -> User Identification -> Captive Portal Settings
The last point of this step is to enable Captive Portal and chose the Authentication Profile we made in Step 6. This ensures that we can present a captive portal page to the user that will forward the credentials to the right Authentication broker.
You can also select if Captive Portal will intercept in Transparent or Redirect mode. To make it short, Transparent is used if the firewall is deployed in Virtual-wire, and Redirect is used if you are in Layer 3 mode.
I just used the IP of the internal interface for Redirect, but you could also use a Loopback interface for example.
Step 8:
We have now done all the preparation on the firewall, and we should now have a working MFA connection and interface ready to intercept with Captive Portal.
Next is to actually use this configuration.
Policy -> Authentication -> Add
We then get a typical pop-up to create a new policy. For the test, I chose to just use the “news” URL Category as a match criteria.
It’s when we get to the action tab that we can see some difference, here we chose “Authentication Enforcement” and “New”.
Here we give it a name, chose “web-form” and the authentication profile from earlier to get the captive portal to work. We have other options like browser-challenge as well. But that is for another post.
Now we have a working Authentication policy, just as simple as creating a Security policy.
Step 9:
After a commit, we are ready to test.
As you can see we tried to go to www.cnn.com but was intercepted by the firewall.
We enter username and password, and the next phase is to approve the Secondary Authentication on the phone.
(This is not from my test.. just for a visual reference).
If you approve, you will be sent to the page you requested.
Conclusion:
Sure, it takes a little effort getting MFA up and running in the beginning.
But when you are done, you will be able to add MFA on any application that has to traverse the firewall. And with integration with other new features in PanOS 8.0, you will be able to automatically move clients, servers or whole zones that might have been infected, to require MFA to move around the network.
This will effectively stop the movement of threats or hackers using stolen legitimate credentials, since they will most likely not have access to your users phone.
You will also be able to add an extra layer of security of the web-app that that one guy made in 2001, and never updated before he left a year later..! Finally!
Short post. But I have created a small App-ID to identify BankID traffic in your network.
It’s based on identifying the Certificate used in the transaction.
Zone protection is a really important profile to configure on your Palo Alto Networks firewall, since you can stop many network based attacks and reconnaissance of your network.
Many of the settings are just toggle on/off, but the one that give the most value is the Flood Protection tab, and here you need to data from your environment to have any value.
No need to allow 40000 CPS when you never see more than 2000 CPS during peak hours.
But the problem has been that this information is not that easy to obtain without the right tools, but this have now changed with the release of cpsmine.py!
This is a small python script that can give you a good recommendation on what to fill into the Flood protection tab!
Download the script: cpsmine-py
MD5-hash: 0F290DD81231FFB4CE897956810EABD6
As the extension indicates, this is a python script, and thus you need to install python to be able to run it.
Linux: You guys probably already have it installed. 🙂
The script work by going trough logs that you have exported from the firewall, so there is no need for a connection to the API or Management interface of the firewall in any way.
Step 1 – Gather Logs!
Considerations:
Filter down to peak hours, so you don’t skew the data with off-hours CPS.
Turn on log at session start if possible, so you get the most accurate data.
Log all traffic, or the recommendation will be off.
500mb of log takes about 1 hour to analyze
You can export the whole log, and then specify what zone or interface the script should filter on. But to save time, I just filter out the data I need directly on the firwall, so the script don’t have to go trough unnecessary log lines.
My filter is on my internal “Trust-VW” zone, and the reason is that I dont host anything, so there should be no connections originating from my “Untrust-VW” zone.
But if you are hosting something, I suggest starting to analyze CPS on the external zone, since Zone protection will give you the biggest benefit there from outside Flood attacks.
After you are happy with your filter, then export it to CSV:
Download the file to a location where you can reach it with the script.
Step 2 – Running the script!
I installed python on Windows, so I am running the commands directly in CMD.
Here you can see the “–help” trigger, and you have several ways to customize the script.
The LOWCPS and HIGHCPS triggers are used to filter out off-peak CPS and abnormal-high CPS so the calculation get the most accurate data that resemble an ordinary day.
The rest is rather self explanatory.
Now let’s run the script!
python cpsmine.py -f log_blog.csv -z Trust-VW -s no
-f = log-file you exported
-z = Zone you want to know CPS
-s = Suppress output or not
Note that “**” indicates that it’s considered in the calculations.
After about 15 min, I get the following output:
And there you have Alert, Activate and Max recommendations based on the log data, which give you a really nice baseline to work with!
Only thing left to do is to put the data into the Zone protection profile!
Good luck!
Note: You can also run the script on specify protocols as well, if you really want to make a granular Flood protection profile.
Did you know that you can auto-populate the log-forwarding and security profile by just calling it “default”?
I for sure did not know it, and I am paid to know everything there is about PanOS.. so maybe this is new for some of you as well?
So how does it work?
Problem/Issue:
You add a new security policy, and you have to manually select the log forwarding and security profiles, on every rule.
We are all human, so accidents will happen where we forget one or both on a rule.
But there is a way to solve that!
Step 1:
Rename or create a new log forwarding profile, and call it “default”.
Step 2:
Rename or create a new security profile group, add the profiles into the group and call it “default”.
Step 3:
Voila! Every new security rule will now auto-fill in the “default” groups!
Now you don’t need to remember the log forwarding, or security profiles!
For most readers, I guess the log forwarding profile will be the most usable one. Since I can’t see any real reason why that should not be enabled on every rule.
Let’s say you want to block YouTube, and you started making a rule, it would probably look something like this:
Block Youtube and Youtube-base and set it to deny, but this will not work if you are not running SSL-decryption:
The application signatures is not able to identify the traffic correctly, since it’s inside an ssl-tunnel, and in the logs we can see this instead:
This gives us little to no information, so we need another way to do it..
First some recon on the traffic:
This gives us some context we can work with, that are not encrypted.
So what do we do with it?
First we need to create a new custom application:
Objects -> Applications -> Add
Put in some information on what the application is doing and what the characteristics are, don’t just throw this together because it can end up matching an Application filter you don’t want it to match. Mine is a good example to start out with.
Next step is to add a new signature to actually identify Youtube traffic, and then add the conditions, so it matches the picture.
The signature is based on identifying the word youtube and googlevideo in both the SSL Client Hello and in the Certificate, this makes it possible for us to find and stop traffic to and from servers affiliated with Youtube.
We then changes the application in our “Block Youtube” rule, and see what happens..
Chrome:
We still get into Youtube, due to how Chrome works, but we are able to block the videos.
Firefox:
Totally blocked.
Internet Explorer:
So, we are able to block it, and we can see the result in the logs:
Disclaimer:
I don’t take any responsibility if this custom application breaks anything else except youtube. The signature is based on names in the certificate and client hello, so if you have other services using googlevideo or youtube, then they will also be blocked.
I have worked with SSL-decryption for several years, and one of my biggest issues during that time was the abundance of browsers that people use.
We have IE, Chrome, Firefox, Safari, Opera and many more, and they all have their own ideas on how things should work.
But the biggest issue I had was Firefox.
All the other browsers uses the built in certificate stores of both Mac OS X and Windows, this made it trivial to push out Certificates that would be used for SSL-decryption via GPO.
But not Firefox, they uses their own internal certificate store, that is not that trivial to push certificates to in an enterprise environment. This lead to companies to just discontinue any support for Firefox, why waste time on complex scripts or 3rd party products to manage at free browser, when both IE and Chrome just works?
A lot of users was not happy about this, old habits are hard to change, and browsers are one of the hardest it seems based on all the complaints I saw..
But finally, Mozilla has made some recent changes that will finally enable enterprises to support Firefox in environments with SSL-decryption! Let’s see how it works:
Lets start with my current decrypt policy:
Rule based on data from MineMeld that updates my PA-200 with IP’s that Office365 runs on.
Can’t decrypt my XboxOne traffic.. what if I disconnect in a FIFA 17 game? Would be devastating!
My own list of IP’s based on applications that won’t work with SSL-decryption
Catch all rule on port 443, even my online bank is being decrypted. You can never be to safe! 🙂
This policy works without any issues on Chrome and IE, since I have imported the “ssl.test.no” certificate into my Trusted Root Certificate Store. But let’s see what happens when I put Firefox to the test?:
Yeah, just as expected. Firefox have no knowledge of the imported certificate, so it stops me from even getting to the site, since it’s clearly a man-in-the-middle(MitM) attack!
The next step in the old days would to import the certificate manually, or get some 3rd party product installed in your domain to do it via GPO..
But now in version 49 and upwards, we have a new cool feature!
Browse to about:config in the search bar:
Right click anywhere in the list, and choose “New -> Boolean”
Enter the following text into the popup:
security.enterprise_roots.enabled
Then set it to “true”, and it should look like this:
This setting will make Firefox actually go and check the Windows\Mac OSX certificate store for any Root certificates that it does not have. So basically, it will work like IE and Chrome does!
Restart Firefox, and then browse to a https:// site to see if it works!
And behold, it worked like a charm. I did not have to import anything into Firefox, so it just works! The only downside is that you are not able to see any of the imported certificates in Firefox. This is something that will be added down the line.
But this is one BIG step in the right direction to get Firefox easier to work in environments where SSL-decryption is active. Just remember this is for version 49 and newer!
If you want more information about how to tune Firefox for your enterprise look here:
Reducing the attack surface is something I have read, heard and said myself plenty of times.
It’s the strategy I belive in when it comes to security in both business and home networks.
I am also a visual guy that likes to use pictures to show what I mean:
This is a picture I got made from a cartoonist, and its a good representation on how I visualize IT-security looks from an attackers perspective.
Which one do you think an attacker will focus on? They are people just like me and you, they work on the clock and have lives as well. So they will of course go for the one requiring least effort! Why waste time?
This is why I mean that reducing the Attack surface is so important, and the only way to achieve this goal is to have total control on your network! Cause, how can you reduce something you don’t know everything about?
How many web-serveres do you have? On what ports?
Do we have any FTP traffic in or out of our network?
What kind of traffic are we seeing over Port 443? Is it only SSL? If yes, what’s inside that SSL-traffic?
DNS. Can clients use whatever DNS server they want?
Web-browsing. Is it controlled in any way? URL-filter?
Applications. What kind of applications are people using, is everyone work related and safe?
SaaS. Are people using Dropbox? Google Drive? Outlook 365 private?
Remote Access. Do people use remote access tools like TeamViewer?
Internet of Things. What is connected or not? Is the Coffee machine connected? And if yes, what does it do?
This is just some examples you need to know about your network to actually be able to reduce the attack surface. Take control, and find out what is actually happening. And then activate enforcement and control on what you want to go in and out of your network!
You don’t let everyone in to your office!? That’s why we have physical barriers with a receptionist checking who you are before you can get in! Why should you not do the same with your network traffic?
The higher level of control and enforcement you have in your network, the bigger the cost to the attacker to actually be able to breach you! And if the cost is to high, then he will just move over to an easier target.
My point is simple, and can be summarized in one joke:
