Network topology/firewall question

[SpookyEddy]

Hi,

OK I would like to know if you think this is possible, I apologise for the bad diagram

{ INTERNET }<-->[ BRIDGE MODE PACKET FILTER ]<-->[ NAT ROUTER ]<-->{ DMZ }
							|
							|
							|-->{ INTERNAL NETWORK }

OK so this is what I want the different sections to do:

BRIDGE MODE PACKET FILTER

This would be a BSD based machine running ipfilter & running in bridge mode ie with 2 network cards (an external & an internal) & no ip address bound to either. The idea being that its almost completely transparent. This node would handle forwarding packets on to the NAT router if I want to allow them & blocking everything else coming in. Outgoing traffic would be handled using stateful inspection.

NAT ROUTER

Another BSD machine that handles NAT to masquarade the internal network & forward allowed incoming traffic into the DMZ (for webserver & email etc). Also additional filtering & logging would be added here to block everything coming into the internal network.


Ok so thats my basic idea but.....

would it even work in theory?
have I overlooked something stupid?
any suggestions for improvements?

Any suggestions & comments would be appreciated.

TIA

Eddy

[DVNT1]

If you have an ISP that filters on MAC addresses you may have a problem, otherwise it should work very well!

I do a very similar thing in one setup and it seems effective.

[SpookyEddy]

Thanks for the reply & its good to know it isn't a completely crazy plan.

With all the views & lack of replies I had started to worry that I had gone mad & was trying something stupid

If you get a minute could you possibly explain a bit more about the MAC address filtering issues?

TIA

Eddy

[DVNT1]

The MAC filtering... for example, Road Runner often prevents "unknown" MAC addresses from getting an IP address (and therefore service). This is to help reduce service theft.

If this happens, you can normally call the ISP and tell them your service quit working when you changed the NIC and they will enter the new MAC address into their system to restore your service.

With this box in bridged mode I'm not sure how the MAC address will come into play. The bridge may substitue it's MAC in the IP address request or it may just repeat the request with the original MAC address.

[SpookyEddy]

I understand now

Not a problem, our ISP doesn't care what NIC I hook up

Thanks

Eddy

[DVNT1]

I was just reading a little more on the iptables. It sounds a lot better than a common broadband router...

* stateful-inspection
* rate limiting
* Filtering of both inbound and outbound interfaces
* Filtering by the user or process initiating a connection


I'm going to setup a box just for this too; want to learn some more

[SpookyEddy]

iptables is nice but i would really suggest going with maybe ipfilter for BSD.

AFAIK its more powerful & it is easier to create rules for IMO. An added bonus is it has much better documentation.

Regards

Eddy

[mickwish]

Would a package like smoothwall do this? Maybe it's only a firewall, but it may do the iptables thing too. I have no idea, but smoothwall is kinda neato looking

[DVNT1]

Originally posted by SpookyEddy
iptables is nice but i would really suggest going with maybe ipfilter for BSD.

AFAIK its more powerful & it is easier to create rules for IMO. An added bonus is it has much better documentation.

Regards

Eddy

Ahh yes, there is a notable diff. between the two...iptables & ipfilter.

When searching around I started to confuse the names (along with ipchains).

So much to learn, so little time to devote for it.

[MDdan]

Originally posted by mickwish
Would a package like smoothwall do this? Maybe it's only a firewall, but it may do the iptables thing too. I have no idea, but smoothwall is kinda neato looking

Yeah, mickwish, I think it would, although smootwall uses Ipchains I believe.

I'm using it right now, and it's pretty much a 20 minute install. I'm not counting the 2 days of trying to figure out which NICs will work.

Maybe I'm missing something, but Spooky, can you explain why you don't just use one less box and have it do NAT and Ipfilter?

[AzKidd69]

bcause the bridge mode packet filter box is for running snort (NIDS) from http://www.snort.org which needs to see all traffic and is best applied if it's in a position to actively do somethign about the traffic it's seeing.. plus hey it's another machine to impress those who know less... LOL

[MDdan]

which needs to see all traffic and is best applied if it's in a position to actively do somethign about the traffic it's seeing

Err....that sounds like a bad idea. What exactely are you gonna do in response to the IDS warnings? You're setting yourself up for a denial of service if you start automatically blocking stuff based on the IDS.

Probably better to put it behind the firewall, so you're not dealing with all the chaff, and your logs are manageable.

It's a tradeoff, but too much info can be worse than not enough.

[SpookyEddy]

The reason for this config is that its way more secure than a single NAT box.

The bridge has no ip address so is completely transparent to the big bad world, meaning its very hard to hack it if you cant talk to it. The only way I know of to tell if a bridge is in place is to measure the latency on the line & thats not really feasible for a remote attacker. This machine can just sit on the line, invisible to all, quietly getting on with filtering traffic.

Also the snort sensor will be ideally placed to detect attempted attacks (like Az said). Why would this open me up for a DOS? If snort dettects an attempt to compromise the webserver in the DMZ (just as an example) the source of that can be blocked with a new ruleset.

Not really sure what you mean, can you elaborate in case I am doing something stupid

Regards

Eddy

[SpookyEddy]

Oh yeah, Smoothwall is really system but I would not use it for a project I wanted to really secure because....

1) It uses ipchains AFAIK so is stateless (big disadvantage)

2 ) Based on GNU/linux which lacks the code audit of openBSD

& I want to play with something new

Regards

Eddy

[DVNT1]

I don't see how the BSD box will make DOS more of a risk, it should make it better if anything because of the rate limiting ability.

To emphasis one of SpookyEddy's comments....Stateless inspection is much less secure than stateful inspection. Broadband routers typically do the weaker stateless insp. too.

[MDdan]

I should have explained the denial of service comment better. It was specifically a response to Azkidd's comment.

He referred to the IDS "actively doing something." If that doing something involves blocking IPs that are attacking, for example, then someone could forge attacks from the most critical sites you need to get to, and your setup would cheerfully respond by blocking legitimate traffic. An automatic response to IDS warnings could cause more trouble than it's worth, depending on what the response is.


As for having no IP address, if there's a way to get traffic to it, that wouldn't prevent all attacks.

For example:

If snort is running on the No IP box, then it's gonna read everything coming in. And if there's a vulnerability in Snort that can be exploited, your system will be compromised.

I would suggest that a hardened box(ie: almost everything turned off & all necessary patches) with an IP, doing NAT and IPfilter, with a second box behind it running snort would be a better solution. It's the IDS that's the risk, it's sucking in everything. That's not a good thing to be running on a box you don't want to be compromised.

I don't see the No IP trick adding much to the security. Better to use the second box as a dedicated IDS, that's a much better separation of duties than separting NAT and IPfilter.

[DVNT1]

Originally posted by MDdan
I should have explained the denial of service comment better. It was specifically a response to Azkidd's comment.

He referred to the IDS "actively doing something." If that doing something involves blocking IPs that are attacking, for example, then someone could forge attacks from the most critical sites you need to get to, and your setup would cheerfully respond by blocking legitimate traffic. An automatic response to IDS warnings could cause more trouble than it's worth, depending on what the response is.

very true possibility, should always be considered

As for having no IP address, if there's a way to get traffic to it, that wouldn't prevent all attacks.

For example:

If snort is running on the No IP box, then it's gonna read everything coming in. And if there's a vulnerability in Snort that can be exploited, your system will be compromised.

If the snort box doesn't have an IP address, doesn't have any network services running, that is very tough to exploit. All it should be doing is picking up all traffic, checking it, then passing it on to the other side.
Worse case...it is rooted, the next step is getting past the NAT device. Much easier now without stateful inspection, but still a second layer of defense.

I would suggest that a hardened box(ie: almost everything turned off & all necessary patches) with an IP, doing NAT and IPfilter, with a second box behind it running snort would be a better solution. It's the IDS that's the risk, it's sucking in everything. That's not a good thing to be running on a box you don't want to be compromised.

I don't see the No IP trick adding much to the security. Better to use the second box as a dedicated IDS, that's a much better separation of duties than separting NAT and IPfilter.

Hardened box is the best IMO too. No need for an IP address for if it all the services are disabled. Without the IP address, you help reduce the chance of accidently allowing some service to be accessible to the network.

Side notes:

An even better way is to have IDS outside and inside.

In gerneral, the two dominant IDS weaknesses are:
* false sense of security it can bring
* hackers creating excessive false positives which becomes like crying wolf syndrome

[SpookyEddy]

Some good points guys, thanks

If the snort box doesn't have an IP address, doesn't have any network services running, that is very tough to exploit.

I thought that as well, also if snort did get rooted I would rather it was outside the NAT box (which would also be stateful packet filter) instead of inside my DMZ

I have read around and the general feeling seems to be that adding a bridged machine outside the NAT router does help in a fairlly big way. Not only do you have an additional fallback firewall but the external firewall is running much simpler rules (no NAT) & can have much less functionality/services installed. Aslo the hacker is busy trying to compromise the visible router while not being aware that its actually a completely different machine that is intercepting the unwanted traffic.

someone could forge attacks from the most critical sites you need to get to, and your setup would cheerfully respond by blocking legitimate traffic.

luckily that is not the case thanks to stateful inspection all incoming connection attempts can safely be dropped & yet still allow connections initiated from within the network to carry on as normal

Thanks again.

Regards

Eddy

[MDdan]

If the snort box doesn't have an IP address, doesn't have any network services running, that is very tough to exploit. All it should be doing is picking up all traffic, checking it, then passing it on to the other side.

An IDS must read all the traffic in order to evaluate it. And as long as it's doing that, there is some risk that an attack could be directed at Snort itself. A box that is sucking in all traffic on the wire and reading it, is by very nature at risk.

I thought that as well, also if snort did get rooted I would rather it was outside the NAT box (which would also be stateful packet filter) instead of inside my DMZ

But if the snort box got rooted and it was sitting inside, behind the NAT machine, someone figured out how to get through the NAT machine. And that's the real issue, regardless of where snort is located. So I don't think I agree with your objection, once they get thru your NAT, who cares if they can compromise snort?

I suppose it has some relevence, but unless you check the IDS logs regularly, and you have a good ruleset, and the attacker is not clever enough to attack in ways that snort won't notice, the integrity of snort is not the main issue when someone is inside the boundary.

What if the user floods snort with 100,000 false attacks? How do you know what happened? All you know is that something happened, and buried in that log you might find it. But you might not. Have fun searching. There are probably more critical tasks at that point than going through the snort logs that are clogged with thousands of fake attacks.

The advantage to putting it inside is simply focusing on what got past your boundary, and ignoring all the chaff that gets dropped at the boundary.

You could improve the external snort situation by tweeking your snort rules to ignore irrelivent traffic. (if you're not running IIS anywhere, drop the rule that logs the attack, for example)

Whatever you do, I'd run Snort on a dedicated machine if you're really trying to be paranoid.

Having said that, I use smoothwall at home with Squid and Snort both enabled. Does it increase the risk? Probably, but it's still pway more effective than the risk I'm looking at on a home network hooked to a cable modem.

[SpookyEddy]

Again some interesting points.....

I like DVNT1's idea of having an internal IDS that just looks for when your LAN actually gets penetrated & an external sensor that can look for potential attacks by recognising scans etc.

While I agree that its very good to know when you have been compromised it is also essential to know what people are attempting to do IMO.

Also if you want any kinda IDS in your DMZ its still going to have to log data so be just as vulnerable as an external sensor.

What if the user floods snort with 100,000 false attacks?

True but atleast you know someone is playing bad & thats gotta be better than not knowing??? Also large amounts of storage are cheap & searching large files is not a really big deal under *nix.

Regards

Eddy