Security Appliance With 12 Network Segments

Dream on, encrypted payload within a https connection is not detectable, whatever magic product you're using it looks for all of those like a valid https connection. Deppends on the config of the IPS, but mostly you can escalate a false- positive to many IPS with a spoofed IP address which gets then blocked, in this case you might DOS yourself.

Cool, what is it? And why is it still possible to bypass AV products with packed and encrypted binaries? Did I miss something?

cheers

Reply to
Burkhard Ott
Loading thread data ...

Sadly, it can be straightforwardly detectable, using an intentional MITM approach.

Consider a corporate environment with many PCs. Further, consider all these PCs having a centrally managed internal certificate authority. Now because all these PCs trust the CA, it's possible for this CA to generate trusted certificates for any domain "out there". Now add in a firewall that can work with the CA to generate certificates dynamically (on the fly, if you will).

The scenario then presented is one where the firewall/proxy can act as an end point for an external https connection, and it can create a legimate https connection to the internal user, signed by its own CA as being valid for the external domain.

External -> Firewall [ Scan and A/V ] -> Internal user.

Unless the internal user thinks to check the CA for the https certificate, there is no way they can detect that the "secure" website they are viewing has been compromised by a deliberate MITM "attack". (My quotes.)

Chris

Reply to
Chris Davies

Yes and no.

Yes, for sure you can't send commands to the victim, but what if the victim calls a server to receive a command and execute it, as long as the data is encrypted (I don't mean the HTTPS encryption, I mean the data within the payload), the firewall will send the request to whatever server as long as the IP address for this specific server is not filtered.

But anyway good point, even if you find environments like that very rarely. cheers

Reply to
Burkhard Ott

We don't pass files that can't be inspected, we block executable files, zip files that are password protected, etc...

Reply to
Leythos

I see, so users can't download binaries in your network then, correct? So I would need to find a way that somebody within your company uses my prepared usb stick or something similar. Other than that, I like your setup :). cheers

Reply to
Burkhard Ott

We disable USB and CD/DVD drives except on select machines. We also have DHCP setup so that it only provides addresses based on MAC addresses.

We're not perfect, but we've gone decades with only 1 compromised machine.

Reply to
Leythos

What if I setup my own address including the mac address?

Yeah, nobody is perfect but you come close.

cheers

Reply to
Burkhard Ott

DHCP can limit itself to "MAC" numbers it has been given. "MAC" numbers are not really addresses at all, just ID numbers.

The DHCP limit is a fair security measure, except that various device can "clone" a "MAC" number, thus making this feature pretty useless. Programming in the MAC addresses is also an administrative nightmare (ok, maybe just a hassle).

Reply to
me again

I know, thats why I'm interested how he might prevent an attack like that.

OK, you can record those adresses easily that shouldn't be the issue, I just wonder if coworker a is on vacation and I can't access his computer (lets assume I would need a token), what happens if I connect a laptop to the network and use his MAC.

It's more a theoretical idea then a practical since I would have to try every possible combination and wait if the dhcpd sends me an address.

cheers

Reply to
Burkhard Ott

You're more than welcome to create a mac address, but if it's not in the approved list you will get a bogus IP that will show up in the firewall.

Just following the basic ideas behind security that have been around for more than a decade.

Reply to
Leythos

It is not clear to ME what 'attack' you are addressing.

DHCP would issue an IP address, possibly one that had been used before by someone else or maybe the same one previously issued to said coworker.

You'll have to have a lot of time available!

The easy way is to open co-worker's desk drawer and read their password :-)

Reply to
me again

For it to work you have to program your NIC with a MAC on the approved list. Sure, you can make them up, but if they don't match what's been approved it won't do you much good.

If you can't access his computer then you won't know what his MAC is.

Look around google, there are a few ways to implement it that provide basic blocking to unknown devices, it's not a nighmare at all, it's actually just a few minutes work.

Reply to
Leythos

I generate random mac adresses and send a dhcp request until I receive an AC, then I found a working mac address.

Yep, thats what I have in mind.

This can be done with a tiny programm, perhaps a script in a while loop, so I should see the first results after a couple of minutes.

Yeah hehe, but thats not technical, except the drawer has an electronic lock xD.

Seriously, I've seen desks there was the alarm code posted to disarm the it and guess what big capital RED letters on a sticker.

cheers

Reply to
Burkhard Ott

That shouldn't be that hard, the only problem might be the traffic on the switchport which might generate a trapmail. Assuming I have enough time for that, I could send the requests less frequently.

No, I would just 'brute force' them. Should take that long on todays hardware, only issue might be like I wrote above, that I generate traps on the switch and somebody is looking what is making that much noise in the network.

Yep, I know but as I wrote with the correct mac address I can pass the first stage and I would assume that there are 'privileged IP addresses' within the network which may are allowed to bypass a couple filter roules, just thinking.

cheers

Reply to
Burkhard Ott

I may would get a link local address (169.254.0.0/16), with a little programm easily detectable, therfore it would need to generate the next mac address until I get something !=169.254.0.0/16.

Maybe only every 30 seconds 1 mac address to avoid too much traffic, if link local received then drop the interface down. It's not invisible at all but should take a while until somebody find out.

cheers

Reply to
Burkhard Ott

MAC numbers (they were originally thought of as addresses, but they the routing guys wanted IP addresses) are assigned to Manufacturers. Sooo, if you guess that the 'target' has a NetGear or a Toshiba NIC you can narrow the search a lot. And if his or her computer has a serial number close to yours, you could get lucky.

Ok, so you have found the IP address formerly assigned to someone else. There is nothing you can do with it because :-) their computer is not on the network!

Reply to
me again

But I request a ip from that MAC, I should receive one and start to find more. Like unsecured services, networkshares, services everything you might be able to exploit. Arp poisening would also be a possiblity, depending on the network setup I might be able to redirect traffic through my machine to find usernames and passwords etc.

Just anything interresting, but this is far away from a remote attack but possible and used by serveral companies/organizations to 'steal' sensitive informations. I mean if you have the chance to steal the newest technologie plans for for something you can easily sell it, if nobody is interested I guess somebody in China is. Not that I'm thinking doing so, as I mentioned before it's more a theoretical construct.

cheers

Reply to
Burkhard Ott

Reasons to hate VLANS for a firewall:

1) They don't always work. I've seen VLANs allow arp or broadcast traffic slip past the VLAN to other VLANs. 2) They need to be implemented in a way that is totally orthogonal to the firewall security software and its rules, thereby creating two independent points of failure in the security design. 3) You have to carefully label which ports in the switch participate in the VLAN, which is a giant hassle. 4) It's very easy to make a mistake and plug a machine in a segment into a wrong port because different VLANs are all contiguous in a tightly crowded switch faceplate. 5) You have to continuously check for mistakes associated with 2) and 4), which creates ongoing work.

Not clear on what problem the person asking for 2 external IP addresses is trying to solve. A toyish DSL router isn't a good firewall. A good firewall rule allows traffic to the web server on port 80 incoming, but

*forbids* all outgoing traffic. If a trojan process gets started on your web server, it cannot get out.

Multiply the types of discrete services you are supporting by 12 and you have my original requirement.

Reply to
W

You are the victim of marketing if you believe those kinds of appliances stop a trojan.

Any trojan worth its salt will either go over SSL or HTTPS, or use its own encryption, and your anti virus program won't see the traffic.

And what if the trojan is just downloading more tools to extend its attack? None of those tools will present a signature that triggers an IPS violation.

Reply to
W

Theoretically man in the middle could be implemented at your proxy server. And the commercially supported products that do that are? And since 99% of commercial firewalls don't support the capability, why introduce this thread of reasoning into a conversation that is attempting to find real world products?

Further, if the man in the middle product existed, I still wouldn't trust any IPS or security appliance that sniffs for code signatures. There are dozens of ways to bypass that and it's a very poor substitute for thinking about security and implementing isolated network segments and appropriate firewall rules.

Reply to
W

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.