difference between a firewall and a proxy server

rono

I'm preparing for my Sec401 and I'm wondering what is the real difference between a firewall which filter traffic and a proxy which redirect/forward traffic?

Is there any security gains implementering a proxy server ...let's say for instance if you have a webserver residing in your DMZ, hosting your website with an API which connects to a DB server in your internal network which registers users info inputed on your website? Webserver is connected directly to the firewall (192.168.200.xxx) and the DB server(192.168.222.xxx) resides "behind" the firewall. Not using vlans and the web api from webserver to db server use dynamic ports and http(80)?

I'm arguing with my boss and 3rd party developers firm who are stating that is no security gain implementing a proxy server. I'm thinking that the proxy is "hidding" my 192.168.222.xxx network from beeing seen from the internet...or i'm ...how they (boss+developers) call me: paranoic, overengineering and so on...?

McxRisley

I believe this article has everything that you are looking for, the google search term was "proxy server vs firewall". Remember folks, Google is your friend.

https://yourbusiness.azcentral.com/difference-between-firewall-proxy-server-20024.html

rono

thanks for you recommandation. I will appreciate more input from experienced people.

McxRisley

The article above answers all of the questions you asked. If you would like a more "experienced" answer, we need more questions and specifics.

rono

is there any security gains implementing a proxy or it holds with a traffic filtering rules on the firewall?

McxRisley

Man I really I am trying to be helpful here, please read the above article. It answers your question.

LonerVamp

The firewall is the one that will be doing NAT, which is effectively "hiding" your internal IP address from the Internet.

You might be over-engineering this.

You can realize some benefits by putting a proxy between the firewall and your web server, but you have to be specific with what you want to do, for instance inspecting and blocking/munging traffic as it comes or goes.

Some confusion comes up these days, because firewalls have many other functions tacked onto the traditional set of firewall features, such as inspection and such. Same goes for traditional load balancers, which often include SSL termination and inspection, quite like the way a proxy can be leveraged.

(Have to say, that link is painful to read.)

rono

LonerVamp wrote: »

The firewall is the one that will be doing NAT, which is effectively "hiding" your internal IP address from the Internet.You might be over-engineering this. :)You can realize some benefits by putting a proxy between the firewall and your web server, but you have to be specific with what you want to do, for instance inspecting and blocking/munging traffic as it comes or goes.Some confusion comes up these days, because firewalls have many other functions tacked onto the traditional set of firewall features, such as inspection and such. Same goes for traditional load balancers, which often include SSL termination and inspection, quite like the way a proxy can be leveraged.(Have to say, that link is painful to read.)

Thanks for not re-routing me to another poor article on the Internet! I hate to realize that I'm over-engineering this but my main concern is security.The portal(DMZ) is running the on http and customers just register their names and other not sensitive information, data, which it is then transmitted to our internal DB server via a API which communicates again on port 80. The developers are saying that is not necessary with implementering https(443) since the customers data is not sensitive and (no need for proxy). The firewall rule allows traffic from DMZ network to our internal network where all servers are residing not only the DB server. The AD DC, DNS,Exchange, servers all resides in the same network as DB server which is "just" receiving data on port 80.My main concern is the possibility for potential bad guys using port 80 from dmz webserver to our internal network as a channel?

McxRisley

So that article would only be painful to read if you truly don't understand the concepts it talks about. The answer to your question of whether or not there are any security gains from implementing a proxy is YES, BUT how much security you gain depends on the type of proxy you are implementing and the type of firewall that you already have in place. For example:


A proxy understands the protocol it is designed for. This means that some proxy software can allow or disallow traffic based on elements of the protocol, meaning they can look at the content. A proxy can also require authentication before sending the request along.


A network firewall on the other hand doesn't understand the HTTP protocol and can't allow or deny traffic based on elements of the protocol. It can only allow or deny based on lower level protocols such as IP, TCP and UDP. Network firewalls also can't do authentication because that is not part of the lower levels of the stack.

GirlyGirl

rono wrote: »

I'm preparing for my Sec401 and I'm wondering what is the real difference between a firewall which filter traffic and a proxy which redirect/forward traffic?

Is there any security gains implementering a proxy server ...let's say for instance if you have a webserver residing in your DMZ, hosting your website with an API which connects to a DB server in your internal network which registers users info inputed on your website? Webserver is connected directly to the firewall (192.168.200.xxx) and the DB server(192.168.222.xxx) resides "behind" the firewall. Not using vlans and the web api from webserver to db server use dynamic ports and http(80)?

I'm arguing with my boss and 3rd party developers firm who are stating that is no security gain implementing a proxy server. I'm thinking that the proxy is "hidding" my 192.168.222.xxx network from beeing seen from the internet...or i'm ...how they (boss+developers) call me: paranoic, overengineering and so on...?

Well go to Book 401.5 page 216-223 and it'll help you out a bit.

If you don't have the books....that is a different story. You need to define "preparing".

GirlyGirl

rono wrote: »

thanks for you recommandation. I will appreciate more input from experienced people.

That was funny

rono

GirlyGirl wrote: »

Well go to Book 401.5 page 216-223 and it'll help you out a bit.

If you don't have the books....that is a different story. You need to define "preparing".

Who said that I run my webserver on Windows? or do you run "at least IIS 8.5" on your Linux webserver?

rono

GirlyGirl wrote: »

That was funny

I ment that input from people who are "sending" traffic in port 77 777 (even they are only 65 536) is appreciated. those people!

yoba222

Symantec has a product that does reverse proxy. I've never used it. I kind of get the impression that it's a solution looking for a problem, with the problem being, "How can Symantec make more business use cases in scanning for malware?" The reverse proxy happens to let Symantec scan for signatures in the upload direction going from the internet to the web server.

https://www.symantec.com/products/web-application-firewall-reverse-proxy

They make some points, but I think a WAF on a reverse proxy is better suited for environments that already have a reverse proxy in place because of mandates (e.g. US DoD). It seems like adding a reverse proxy to protect from the outside-in adds a lot of complexity where a plain old WAF could do just fine.

MitM

rono wrote: »

The firewall rule allows traffic from DMZ network to our internal network where all servers are residing not only the DB server. The AD DC, DNS,Exchange, servers all resides in the same network as DB server which is "just" receiving data on port 80.My main concern is the possibility for potential bad guys using port 80 from dmz webserver to our internal network as a channel?

Maybe I'm reading this response wrong, but it doesn't sound like much of a DMZ to me. The firewall rule should only be allowing traffic from the web server to the back end database server.

McxRisley

LMGTFY

cyberguypr

McxRisley, stop offering solutions. You are obvisouly intentionally keeping your amateur status and the OP is looking for someone with more experience. LOL!!!

MitM

McxRisley wrote: »

LMGTFY

lol funny

rono

cyberguypr wrote: »

McxRisley, stop offering solutions. You are obvisouly intentionally keeping your amateur status and the OP is looking for someone with more experience. LOL!!!

yeah looking for cool pen testers who had test this kind of DMZ->internal network communication before not certs collectors who are Google-ing every lab.

time to set up a lab again!

Techexams was cool back in 2002 when started...

johndoee

rono wrote: »

yeah looking for cool pen testers who had test this kind of DMZ->internal network communication before not certs collectors who are Google-ing every lab.

time to set up a lab again!

Techexams was cool back in 2002 when started...

Did you need us to tell you to do that ?

Hold on. Did you brush your teeth before bed? Make sure you wash your hands coming out of the bathroom.

LonerVamp

McxRisley wrote: »

So that article would only be painful to read if you truly don't understand the concepts it talks about.

The article in question has such gems (out of about 25 total sentences) as:

"A firewall can prevent programs from running on your computer. A proxy server cannot do this. "

"You can block websites through a firewall, but you may bring your Internet access down."

And then completely ignores all the NGFW/UTM features in many of today's firewalls.

It has otherwise decent information, but I had to wince. It creates almost as much confusion as it tries to dispel.

McxRisley

I know it didn't cover NGFW/UTM but he didn't ask about those, he specifically asked if there were any security gains from implementing a proxy, the article I provided answers all of the questions and provides the basic concepts that he was asking about.

I'm not to sure what your last response means but I was legitimately trying to help you better understand the concepts until you asked for "experienced" people LOL

rono

Any externally facing system that is connected to internal system will potentially be used as 'jump point' to internal network. Based on my example below, if the DB has a connection back to internal AD or internal network, then yes - an attacker could get access to my internal network.(using nc backdoor - "nc -l -p (port) -e /bin/sh" - in Linux and "nc -l -p (port) -e cmd.exe" in Windows)


One of the best practice I can use is "multiple segmented network." In this model, I need a few layers of Firewalls. For example:


Internet <-> FW1 <-> Webserver <-> FW2 <-> Application Engine <-> FW3 <-> DB <- FW <- Internal network


i can narrow down the attack surface by employing multiple firewalls. I think this can be a viable solution because there is only one way connection from internal network to DB and all other DMZ/Public segment. This way, the probability of any of these system used as jump-point will be mitigated.

Remember ! Security is not a product, is architecture!

Thank you all for input! Everyone!

JollyFrogs

The primary practical difference between a firewall and a proxy is that a firewall is optimized for packet speed and works mostly on layer 4 (TCP/UDP). The proxy server operates at layer 7, and whilst speed is always an important factor, useful filtering is its main purpose. In practical terms, this means that you will most likely need both in a modern organizations - you want to block as much as possible using a firewall at the IP or TCP/UDP layer. However, with the advent of cloud services and distributed content networks like akamai and floating IP addresses like Amazon AWS uses, it is becoming increasingly difficult to filter purely on IP layer. Many SaaS vendors cannot provide you with their external IP address because they simply do not know that IP address, and every reboot of their servers will cause the IP address to change so a proxy server is typically used to filter based on DNS names rather than IP addresses.