Slashdot Mirror

There should always be a router between any personal system and the Internet. Not a kludgy firewall/filter, mind you, but a simple NAT-translation router that puts your machine in a private address space. Hackers can't hack what they can't get to.

Actually, that's not quite correct; take a peek at rfc2663: http://www.faqs.org/rfcs/rfc2663.html. In a somewhat roundabout way in the security section (Section 9), it says not to use it as a "Firewall", but rather in conjunction with a firewall.

The reason for this is that if someone spoofs an address in your nat range, it pass through unfiltered. Bottom line is to not rely on NAT alone for a firewall; always use it in conjunction with real filtering. Thankfully most consumer boxes will do this already, so it's practically a moot point.

But C is actually even more subtle than that.

There is a special case for 0 and NULL pointers in the C standard.

Remembering off the top of my head it states something about any pointer with the value of 0 will be converted to NULL under test or comparison

From:
http://www.faqs.org/faqs/C-faq/abridged/

5.3: Is the abbreviated pointer comparison "if (p)" to test for non- null pointers valid?
A: Yes. The construction "if(p)" works, regardless of the internal representation of null pointers, because the compiler essentially rewrites it as "if(p != 0)" and goes on to convert 0 into the correct null pointer.

Regardless of this (or maybe becuase of it), I prefer
if (ptr != NULL)
It doesn't require somebody who is looking at the code to understand the minutia of the C standard.

Well an avian carrier protocol does exists, but they are working out some problems with "cat-in-the-middle" attacks.

Well, this is plain wrong... A constant zero in pointer context always *is* a null pointer, regardless of its bit pattern. The only reason NULL exists is for stylistic reasons, and is defined to a constant '0' or '0' cast to (void *). Questions 5.2 and 5.4 in the comp.lang.c FAQ are relevant... http://www.faqs.org/faqs/C-faq/faq/

This is by no means a "neo-Luddite" argument. It is instead a plea for the Unixish Approach (or Philosophy) to be implemented even with (x)html tools: a well-made, well-designed tool does its job and then another tool may take over from there. If you want a net-based application, fine. Make a program whose specific function is to serve as the container for such applications. Just don't try to shoehorn code into a space designed for data.

You are right that things are often appropriated for other uses, and that this is the way things often work. Yet, the fact that something does happen, or is the case, does not imply that it ought to happen; Hume made sure we could not dance around that conclusion.

This is not holding technology back. This is instead a reasoned approach to the problem, one which would likely prevent many of the security/performance/stability issues which currently do and which inevitably will pop up because of the tendency to appropriate one tool for another use. Coded tools do not have the same tolerances as do physical tools.

However, enlightenment is way too layered and has a million different little components...

From Basics of the Unix Philosophy:

(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.

Many little things is good, not bad.

Do they have the authority to regulate birds?

carrier pigeon

RFC 1149, man.

p

Uh, no. Just no.

DNS name records can (and often do) contain multiple IP addresses for that very reason - load balancing. Perhaps not true load-and-fault-sensitive balancing, but load distribution at the very least.

Try "host www.amazon.com" on different machines - you'll get any number of addresses back.

Look up RFC 1794 some time, which has been implemented in both Linux and NT systems for at least the last six years.

Dude, there's already an evil bit for this sort of thing. ;)

http://www.faqs.org/rfcs/rfc3514.html

That's only in indiana where they tried to get a law passed for a more sensible definition of pi. Every other american is WELL aware that man was made by aliens.

Could somebody please explain what the problem with DHCP is? There certainly seem to be plenty of documents to enable open implementations to me. Or are they talking about some proprietary Microsoft extension to DHCP that is rightly being ignored by everyone else?

The "something else" that was observed was most likely to be big ordinary vibrations which the experiments were trying to subtract to leave a small signal.

Does it use HyperText Coffee Pot Control Protocol, as defined in RFC 2324

Sure, for the original bits, but Luke Howard of PADL.com has done an incredible amount of work in putting XAD together. Luke is one of the best of the best when it comes to LDAP, as well.. he's the original author of RFC 2307, which standardizes how NIS style directory objects should be mapped onto LDAP. RFC 2307 is the basis of directory service offerings from Apple, Sun, and other UNIX vendors.

Luke also created the best solution for supporting legacy NIS clients in an LDAP network, and he created a lot of the pam_ldap stuff that major vendors ship today.

Now, may I say, if you're looking for programmable metadirectory services for mastering data into NIS, DNS, LDAP, AD, and etc., I can humbly recommend Ganymede.. the current version is pretty spotty in some ways, but wwe are looking to release 2.0 in a few months with a lot of new features that will make it suitable for a lot more uses than it is now. Scalability, localization, SSL encryption, delta-based message queuing channels for change transmission, and much more is on tap.

Wifi at a Coffee shop... Has there ever been a more compelling reason to push for an implementation of RFC2324?

The Unicode and ISO/IEC 10646 repertoires have many characters that
look similar. In many cases, users of security protocols might do
visual matching, such as when comparing the names of trusted third
parties. Because it is impossible to map similar-looking characters
without a great deal of context such as knowing the fonts used,
stringprep does nothing to map similar-looking characters together
nor to prohibit some characters because they look like others. User
applications can help disambiguate some similar-looking characters by
showing the user when a string changes between scripts.

..l..0..1..O..I

They did consider the implications, compared them to the security risks users were already exposed to, and suggested that the applications (this being an application-layer protocol) visually distinguish IDN or mixed IDN domains.

http://www.faqs.org/rfcs/rfc3490.html

Check out sections 1.2 and 10.

How does this relate to Kerberos? Included with most major Kerberos 5 distributions is a GSSAPI implementation. Thus, if a particular application or protocol says that it supports the GSSAPI, then that means that it supports Kerberos, by virtue of Kerberos including a GSSAPI implementation.

Wow, it's a good job you said Erich Mielke rather than Adolf Hitler, or you'd have Godwinned yourself.

shouldn't trust the hosts.

In "Routing in the Internet", Christian Huitma, when describing the Internet architecture, describes why hosts shouldn't trust the network to perform reliable delivery. Hosts have more of an interest in reliable communication than the network as ultimately they will suffer the most if the network isn't as reliable as it says it is; therefore hosts should take the primary interest in ensuring the network delivers data reliably. That leads to absolute reliablity mechanisms in the network being redundant, as the hosts will implement them anyway. This is why TCP is an end-to-end protocol, why the IP header checksum only covers the IP header, and why the network layer in the Internet is only "best-effort".

In a later chapter, regarding QoS, he makes the point that the network shouldn't trust the hosts. The network should provide generally equal service to all its "customers" - the hosts that are attached to the edge of the network. Therefore, if one host is misbehaving, the network should penalise it. That is what the default queuing algorithm (Random Early Dectection) for the Internet does. Some details are in Recommendations on Queue Management and Congestion Avoidance in the Internet.

The same model applies to security. Security should be end-to-end when the host has the most interest in the consequences of lack of security. Hosts shouldn't trust the network to deliver data securely, as the consequences of secure delivery are most felt by the hosts (and therefore the users sitting behind them).

The network's security needs aren't quite the same as the hosts; the main thing the network has to secure is availability and the ability to continue to provide equal service to all its customers (the hosts.) Authentication in routing protocols, secure administration tools such as SNMPv3 and SSH, and traffic rate limiting mechanisms like RED are network security mechanisms that protect the network's service.

Security problems come about when attempts are made to implement host security in the network, and network security in the hosts. For example, a firewall's purpose is really to protect the hosts. The current location for most firewalls is inside the network. Unfortunately that doesn't fully extend the host protection a firewall provides up to the host itself. With the current model, it is easy enough to "unprotect" the host by inserting a device, for example a wireless access point, between the firewall and the host. The firewall may still protect the host from Internet based attackers, however it doesn't protect the host from war drivers. Ideally, a firewall should reside on the host itself, to protect the host from attacks from all (network) directions. Interestingly, that is happening already through evolution - most host OSes are coming with firewalls out of the box. Administration of firewall security policy is a problem with this model, due to the increased number of firewalls to now administer, however, mechanisms are being developed to apply distributed security policy. Distributed Firewalls by Steven M. Bellovin describes this model further.

Any clues I could follow?

Linux Kernel 2.4 Internals. Subsection 1.6 points to a initialise console step in init/main.c:start_kernel()

Any clues I could follow?

Linux Kernel 2.4 Internals. Subsection 1.6 points to a initialise console step in init/main.c:start_kernel()

.. gives a good overview of the subject

http://www.faqs.org/docs/artu/

I can see it now..."Bugs deserve rights too!"

Well, ask the original bug at NSWC if it enjoys being taped to a cardboard note since 1947...

You still don't seem to get it.

URLs are case insignificant.

HTTPS only provides an encrypted channel so some other means of authentication can be used.

Same thing. Don't argue with me over semantics. HTTPS provides this. SMTP does not.

And what's wrong with SMTP?

There is no method of authentication.

Well now you've heard it from a fool who knows SMTP inside and out.

Really, though, to anyone who's played with compact representations, higher bases are obvious. I'm sure no one patented base 64, and I suspect several different people came up with it independantly.

What I want to know is why base 30? It's an awkward number, which will just make everything more difficult. Is it just about obfoscating their formats? Fooling the patent office?

There was plenty of evidence at the trial.

Let's pick .NET and Kerberos as areas where Microsoft either wanted to create it's own non-standard or didn't follow the standard.

I remember the whole DHTML war before there was a proper DOM, Microsoft didn't want standards then either (I think this was about the time they were shipping Microsoft not-jvm)

Expert doesn't mean correct.

Maybe PC/GEOS would have had a Chance!!

No nevermind, I was on crack for a second there. 8^0~

Linkage

Hitler? What are you trying to kill the conversation?

Googling for "FOCAL" turned up this interesting page on the taxonomy of computer languages

[1]
http://www.faqs.org/faqs/dec-faq/pdp8/section-11.h tml
http://hopl.murdoch.edu.au/showlanguage.prx?exp=40 6&language=FOCAL

[2] my school had use of a HP 9830 for half a term a year, and I was the one usually found in front of it after school.

That would be 2.2 in RFC2396

Is that not the purpose of shell scripting? ;)

The 65th bit is the evil one.

. . . and got caught by the fever.

postmaster is not optional. period. if you accept email, you are required to have a functioning postmaster address. this is a non negotiable point.

see: RFC 2821
section 3.1 paragraph 2
section 3.6 paragraph 3
section 4.5.1 paragraphs 2,3

the only case where it is even remotely close to "optional" is section 3.1 paragraph 3, in which case you would be rejecting all mail outright...

A finite universe has no center. It's analogous to the surface of the Earth (the surface, mind you, not the whole Earth) -- it's finite, unbounded (no edge), but there is no special "central" point on the surface of a globe.

Call/email your local ISP and tell them that you want SSM support. If enough people call, then they will turn it on (they already have all the equipment). Once turned on, I predict that there will be a flowering of software to exploit it -- this will include audio/video broadcasting, p2p applications, audio chatrooms etc.

Thanks for the info. While you did qualify this with "the C standard", I was mostly thinking of obscure systems when I qualified this. For example, on a system that predates prototypes, the value will generally get pushed onto the argument stack as an integer 0, but read off as an all-bits-zero pointer, which isn't necessarily a null pointer (but you already knew that).

"((void *) 0)" is tempting, and does occur in some C header files, but it's wrong!

Actually, it is allowable under ANSI C; see the comp.lang.c FAQ, sec 5.6, or the Rationale, sec 4.1.5.

Of course, in this case whether or not printf sees a null pointer here is academic anyway; the actual behavior of printf under these circumstances is, I believe, undefined.

And what may I ask makes a signed active-X control any less dangerous than an unsigned one?

The evil bit is not set on an signed control so you know it must be good!

Those mail sending agents that do not listen on port 587 aren't following the RFC, and they may eventually end up on the RFC-ignorant blocking list.

And how long until SBC blocks that too?

The stated excuse for blocking 25/tcp out is to stop the spread of e-mail viruses that use 25/tcp out. It'd be a lot harder for e-mail viruses to use 587/tcp out because most e-mail servers that listen on 587/tcp use SMTP AUTH and possibly TLS. Blocking 587/tcp out would raise red flags among members of Broadband Reports, possibly cutting into business.

Actually, it's quite simple to check if a packet is valid or not, just check if the evil bit is set.

I've set my firewall to drop all packets with the evil bit and I've never gotten a worm or a spam since! It's perfect. I can't imagine why everyone else isn't doing it yet ...

You must be new here. See Godwin's Law.

Unfortunately, you've just posted the same tired bundle of false assertions. Neither the transferred-from registrar (that's Dotster) nor Panix were actually notified prior to the transfer. In fact, if you actually read the relevant standards (in particular, the description of the TRANSFER message in RFC2832 you'd find that a change of registrar works like this: 1) The transferred-to registrar sends a TRANSFER message to VeriSign. VeriSign or the transferred-to registrar (the specification is extremely unclear) then uses an unspecified out-of-band method to contact the transferred-from registrar. 2) The transferred-from registrar sends an identical TRANSFER message to VeriSign, except that it has either Approved:yes or Approved:no in it. This is what actually causes the change to occur. 3) Since the recent ICANN change in policy, if no Approved: TRANSFER message is received in 5 days, the transfer occurs automatically. This points out some very, very odd things about this particular transfer. First, Dotster has no record of any TRANSFER request in their log file. Second, they have no record of sending any approval message -- in fact, their database still shows that Panix is their customer; they can't even try to grab the domain back without deleting the record, which would complicate the ongoing investigation. Yet VeriSign say that the domain was transferred with approval. With approval from whom, exactly? I have some strong hunches about how it might be possible to do this but I can't really go into them here and now.

One of the really depressing things about having been in the business for nigh on to 40 years now is that, along with the occasional new dumb idea, all the old dumb ideas keep coming back.

This is just a matter of being standards compliant, see #11 in http://www.faqs.org/rfcs/rfc1925.html.

... is it SNMP manageable?

Because I need something to go with my coffee maker.

Seems the simple solution is to cache "bad" addresses in your local DNS server for some specified period of time, probably in a LRU type cache to prevent Spammers from taking it down.

Congratulations, you've just invented negative caching! You'd better hurry back to 1987 and submit your patent application!

RFC 1925 - The Twelve Networking Truths:

(3) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.

http://www.faqs.org/rfcs/rfc1925.html