How safe for firewall rule using 127.0.0.0/8

So you agree that the problem is users installing stuff?

But the stuff they install will disable your security measures, circumvent your policies, etc... sure, it's easy to put on a software firewall, but it doesn't help with the actual problem.

Juergen Nieveler

Reply to
Juergen Nieveler
Loading thread data ...

He'd think that he is protected. But the malware that he just started simply disables the block, and that was that.

Juergen Nieveler

Reply to
Juergen Nieveler

Must be nice.

Around here, the *products* run on windoze, and upper management loves to say "we eat our own dog food". (Yes, the predictable misquote is frequently heard)

When management won't support policies such as you espouse, one frequently has little choice but to resort to stoop'n'scoop mode.

Security is PPPT. One might debate the P ordering, but T is indisputably last.

Triffid

Reply to
Triffid

Yes. Does that mean we can't discuss other areas of security?

Ok, I guess we can't talk about the idea here, since users can install stuff.

-Russ.

Reply to
Somebody.

If it can.

What I described is completely normal behaviour for many fortune 500 companie's SSL VPN servers. But you guys refuse to talk about the details of it.

Fine, I give up.

-Russ.

Reply to
Somebody.

I said that in an example, of course you can look at whitelisted destinations only. This is intended to be a discussion about a concept, not a roadmap for a total security package.

There are huge, huge companies using SSL VPN servers for remote access. IE,

7-figure projects with tens of thousands of users. That's the client that I'm talking about. So I'm imagining a nefarious use of the same technology.

Ok, thanks.

-Russ.

Reply to
Somebody.

I understand some need to be open. These clients tend to use upper ranges of that subnet that aren't used by much else.

That's great security. Well done. Nothing near what the OP was dealing with when I posed this answer to his query about 127.0.0.0/8. Yes, there are a hundred other things one can do. He asked about that, because he could enforce firewall policy but little else. I tried to discuss it in this vein. But you know, it really truly doesn' t matter to me, I'm not the OP, I run a much tighter ship than the one I'm hypothesising, and I tire of the discussion.

Thanks though, for the first answer that actually discussed the subject itself rather than all the other ways to lock down users.

-Russ.

Reply to
Somebody.

That is an advantage we have - I don't know of any product that even needs to know about windoze, but then we're an R&D facility.

THAT is an example of short sightedness. Cleanup invariably is more expensive and time consuming. Corporate got the message over years ago when someone did something stupid, and there was a serious monetary cost, and several reputations on mahogany row went up in flames. 'nuff said.

Old guy

Reply to
Moe Trin

You need to look at users being able to install stuff. This usually means they can do anything they want on the system - including bypassing all security features.

People hate the word, but "Why?"

Old guy

Reply to
Moe Trin

No Sir - Not the point I was making. Go get a sniffer and find out. There really are fundamental differences that are quite obvious without even knowing who the remote IP belongs to.

There's a difference between your employees needing an extra piece of software to work with companies (which should be installed by your IT folks, not the user), and them needing to install software so they can collect their winnings from the Nigerian Hospital Lottery. If a company (supplier, sales/marketing, delivery, after-market service) that your company is doing business with, there should be lots of juicy legal agreements (contracts) in place. Pass the word up the chain, and let corporate legal handle the mess.

Old guy

Reply to
Moe Trin

Remember, I don't use windoze. Microsoft sorta copied a number of UNIX commands, though putting their own "improvements" which makes them incompatible. 'netstat' is one of these. In UNIX, I can say

[compton ~]$ netstat -antu Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:ssh 192.0.2.:* LISTEN tcp 0 0 *:smtp 127.0.0.1:* LISTEN tcp 0 0 *:x11 192.0.2.:* LISTEN [compton ~]$

This system is listening on a grand total of just three ports, and it's restricted as to what addresses it will accept connections from. Both SSH and X11 (the display server) are accepting connections from the LAN only (and not the world, which would be shown by a *:* in the fifth column). It's also accepting mail - from itself only (UNIX tends to use mail as an alternative when providing status information on background tasks like cron.).

["public" PCs in the break areas]

The systems are on tables with privacy screens (prevent casual shoulder surfing - about 16 inches tall) with the user's back to the wall for the same reason. They are recycled workstations sharing a 3 MB/sec connection that goes no where near our network. They're available 24/7, on the 'honor' system. We've had virtually no problems with them. This way, the employee has a viable alternative to using the company PC for personal business.

Old guy

Reply to
Moe Trin

It is only safe to do this with a host based packet filter. On any firewall implementation there may be no such rule. The opposite, filtering this traffic, should be true.

Yours, VB.

Reply to
Volker Birk

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.