Kids bypassing firewall via web proxy sites

If you read it carefully, you would have already noticed that any client-side system safely ignoring the EVIL bit is fully RFC3514 compliant.

It's more about "unwilling". Why should one do so?

Why don't you? Especially 3.4.

So, what's wrong with that? Better re-read section 2.4.

Yeah, those are dumb. Way worse are those who're using Symantec's software, even treating the well-known begin-end-signature as a real ILOVEYOU worm.

Because the domain doesn't exist today, but could exist tomorrow? .invalid is normally rejected.

If I control the authoritative DNS server for the domain I'm trying to resolve it's up to me what content is inside the DNS request/reply. Besides, for DNS you need TCP as well (no, not only for zone transfers).

Send/poll from the client side. Please have a look at the "wwwsh" section of [1]. We didn't use DNS there, but I suppose you'll get the idea.

You are not limited to one UDP packet. And of course it's no problem to encapsulate the download in DNS replies and re-assemble the file on the client side.

[1] cu 59cobalt

You put "I'm an idiot" into a great many words, y'know.

In case you failed to notice: THIS IS USENET, so please re-read section

2.1.1 of RFC 1036 to learn why you're supposed to have your actual mail address in the From line of any message you send.

Ummmm. So, which part of that section did you fail to understand? The fact that this applies to relays (which in the case discussed here are run by clueless morons who won't bother to implement sensible filtering)? Or are you suggesting that one should filter (perfectly valid) NDNs? You gotta be kidding me.

Which is perfectly valid for a relay. Please have a look at D.3 in the scenarios section. That's of course why nobody (except for spammers) wants open relays.

Which is utterly stupid. But nonetheless keeps happening.

Good for you. However, some of us can't do that as easily without violating local laws. Blacklisting is a *very* two-edged sword.

cu

59cobalt

Nothing new here. I'm quite aware of tunneling to dump files, any clown with netcat can do that quite easily. In fact i've used it myself. Very handy ;-) Your reply also ignores the fact that a properly set up system uses firewalls, policies and lockdowns, not just content filters.

As the admin, *I* will decide what DNS queries (and all other traffic) will leave the network, and also occur between network segments. Lets look at tour example of DNS, and what rules would be put in place.

1. Only server's would be allowed to send DNS requests out.
2. Only certain DNS server's would be allowed to query. Would these rules allow *your* wkstn's DNS queries out? No. Would they be blocked and logged? Yes Would the admin be asking you some questions about you intentionally violating AUP? Would you enjoy being fired? Goto 1, and repeat for most, if not all traffic. The obvious exception here is SSL tunnelling, but there are such things as SSL whitelists.

This assumes you got the tool to send the packet on the PC in the first place, which is another matter and another violation of AUP.

While everything you and others have stated is *possible*, you are looking at each technique in isolation of a total setup, and ignoring a properly layered approach. I'm yet to see a properly set up enterprise that allows the end user to initiate a direct connection with the outside world. With internal servers/units that allow/disallow certain traffic types, yes; letting Joe User have a direct SMTP, HTTP, DNS(or whatever) connection with anywhere external, NO.

In theory you could bring in tools, then clink away trying to find a weakness in the setup, but the chances of doing it undetected are very,very slim. If you would like to take the risk and think you can get away with it, please keep your cubicle tidy so your replacement doesn't trip over the junk you leave behind when you get terminated and escorted off the premises. Cheers, E.

See my above post. Cheers, E.

Unfortunately, this is wrong. I wish you were right here :-/

Yours, VB.

That means "this browser is unusable for Websites".

Yours, VB.

Please explain. Can you citate?

Yours, VB.

Click on the sender toolbat item. Go up a couple of posts. She who must be obeyed is calling...... E.

And i.e. with a DNS tunnel, this isn't true.

*sigh* - really want to talk about Microsoft Office?

Yours, VB.

Because while Usenet remains, there are no class A networks any more.

Yes, and?

Yes, and?

Yes. This is the problem exactly as I explained.

Yours, VB.

In tin? ;-)

;-) OK, this I can understand.

I'm waiting for your posting.

Yours, VB.

The HTML page is the download.

HTTP traffic allowed outbound is to port 80 and HTTPS allowed outbound is to specific IP's that are known. No other ports are allowed outbound and the proxying of traffic is not allowed. For what HTTP traffic is allowed the GET requests are inspected/filtered to immediately block known objectionable sites by either IP address and domain name. Blocking is accomplished by spoofing the content that would have been returned from the website to the client and injecting this back onto the wire. Of the HTTP GET requests inspected and allowed, such must be to a single site and this request is logged. Anything that deviates from this format is blocked. With reports reflecting IP addresses/site names, by requests made, by volume, etc. traffic patterns may be discerned. If something doesn't look right, the IP address or domain name can be added to a block list to prevent further access.

If there is any tunneling going on in the above I'd like to see it, then again if you're correct. I guess I won't.

The browser works just fine. I am able to attempt to visit any website I want to. Those which have been previously approved are capable of being displayed in their entirety. Those which have not been approved, are not allowed to display anything outside of basic text. Nothing is allowed from unknown websites. Hence when I attempted to visit the link you offered and because it was 'unknown' and therefore nothing was retrieved. If you ask me, I think that's a pretty secure configuration.

"Nothing is allowed from unknown websites."

Should read "Nothing is allowed outside of simple text. This includes scripts, cookies, etc."

Mine does even better, nothing is permitted from unapproved sites, and the users are given a error message stating that the site is blocked.

Exactly! Like myself, I'm sure that the block message to which you are referring is the result of some sort of filtering solution you've put in place. I glad to know that you and I are on the same page (no pun intended).

There are two methods for the warning/message - one is based on just a simple message that the proxy service in the firewall sends in place of the page, it's just a "Firewall has blocked access to this website, please contact the administrator if this page was blocked in error", the other actually redirects them to a internal website to request that the page be added to the white list, neither allow the user to permit it.