Bring him back
I can't think of a better article for which Eadon should be given a temporary comeback ...
Brace yourself for an almighty burst of self-congratulation from Microsoft, which is poised to take the crown for the world's most-used Web server. So says Netcraft's new monthly report on the state of the web, which offers the following data: Developer May 2014 Percent June 2014 Percent Change Apache 366,262,346 …
This post has been deleted by its author
". . . for parked domains."
Is that true? I figured parked domains were mostly on cheap services running Apache - not that it is a poor option of course, just that the kind of no-frills, default hosting I have seen used for parked domains is, without exception, running Apache.
Apparently MS has been throwing money or other arm-twisting tricks to persuade large hosters of parked pages to switch to IIS. AFAICS the only benefit of this is incomplete articles in the press about how IIS is set to become (/will become) the most popular web server, which is a useless metric. As mentioned, the picture for Active sites is very different, and the Top Million even more so .. which somehow does not get mentioned in the news reports.
I figured parked domains were mostly on cheap services running Apache - not that it is a poor option of course, just that the kind of no-frills, default hosting I have seen used for parked domains is, without exception, running Apache.
For the web design class I taught last semester, students had to obtain a basic web-hosting package where they could host their site. I gave them a short list of providers, but they were also free to find their own. From the server banners and other info I saw, I'd guess they were about evenly divided between IIS and Apache.
The hosting companies I researched when I created the list for them all offered both IIS and Apache hosting, at the same price points, at least for the first couple of tiers. Sometimes their fancier offerings diverged after that.
(My own site is currently served by Apache running on a shared Linux image. Previously it ran under Tomcat in an individual Linux VM, but I switched to the cheaper shared Apache setup when I dropped the one J2EE-based app I was hosting.)
Interestingly though we found the "AMP" parts of LAMP easy to install on Win2K server and Win2003 server and ran Linux PHP apps unchanged. Easier than IIS + MSSQL.
Obviously this is a nonsense metric. Only "real" web sites not part funded by Microsoft count.
Companies with Sharepoint / Exchange are not representative either as they are locked into MS forever (effectively, in reality it's possible to switch) and often get special volume discounts.
Interestingly though we found the "AMP" parts of LAMP easy to install on Win2K server and Win2003 server and ran Linux PHP apps unchanged.
Yup. There are various bundles (WAMP, etc), and you can also just install the individual components with very little effort. While my site runs on Linux, my local development is on Windows1 with Apache, PHP, and MySQL.2 I develop and test locally, then run a build that scp's the changed files up to the server.
1Because that's what came preinstalled on the laptop, and with Cygwin and Vim it's close enough to a UNIX-style environment that I can't be bothered to replace it with Linux. I have Linux VMs but to be honest I rarely spin them up. Just run a whole bunch o' bash shells.
2My personal site is all research and academic stuff, and I need PHP and MySQL for the class I occasionally teach, so I don't bother with anything less rubbishy. And there's something to be said for writing PHP code - every other language looks so much better when I'm doing my real work.
> Obviously this is a nonsense metric
Yes. Agreed, but nonsensical in another sense, too [1]. Market share is just a number. There is no reason to suppose that it correlates with any quality measure at all, especially when the offerings, as here, are both free (as in beer), so there is no financial investment appraisal being made. If I was in the position where I was selecting a web server, the very last question on my mind would be "Am I going with the herd?"
[1] If you see what I mean. I think I do!
"As the Microsoft offering doesn't run on Linux etc. it's self-evident that it isn't going to be a major part of the public web"
But that's a good part of the reason people are moving. We switched all of our public websites to IIS about a year ago after repeatedly having our Linux / Apache servers hacked and defaced - and zero issues since - it's just so much effort to evaluate all the security patches and keep them updated for a LAMP based solution. The Microsoft stack has had far fewer holes to patch in recent years - and it's much easier to do so.
"""it's just so much effort to evaluate all the security patches and keep them updated for a LAMP based solution. The Microsoft stack has had far fewer holes to patch in recent years - and it's much easier to do so."""
Bull****!
Bull****! of the highest magnitude.
"Good point, I don't see either how IIS is not all that bad."
I don't think IIS is all that bad, but the real question is why would you use it when there are free alternatives that are at least as good, and arguably better?
"I don't see either how IIS is not all that bad."
I can give you a few reasons - Far fewer security holes in recent years than Apache for a start. IIS 8.5 is also significantly faster than Apache for multithreaded applications - primarily due to it's more optimal model of shared static variables. And a much more powerful and extensible security model - for instance expression based ACLs are possible.
From the Netcraft report:
"... most of this [IIS] growth is attributable to new sites hosted by Nobis Technology Group."
That's a company that hosts TeamSpeak servers - one per team. Not much of a win for MicroSoft then if the vast majority of the growth is inactive Teamspeak servers, and the Netcraft figures also show a drop in active IIS sites.
You could say exactly the same thing about the large number of (insecure) Linux servers I see with Apache installed and advertising itself by default. Each one of those is no doubt counted as an 'Apache server' by Netcraft even though they are rarely doing anything other than exposing holes like SAMBA configuration files.
I said nothing about the security of a typical installation, regardless of the HTTP server or operating system it's running on. I commented on the figures and caveats from Netcraft's report. Although I doubt that a monumental pr*t like you even clicked through to read the report before submitting your typical trollish comment.
You could say exactly the same thing about the large number of (insecure) Linux servers I see with Apache installed and advertising itself by default.
So ...
a) how do you know about their apparent "Insecurity"?
b) what's wrong with proud advertising? It's not like IIS says "I'm a trolling dog" either.
holes like SAMBA configuration files
WTF are you talking about?
"Umm... what?" On SAMBA (Linux and UNIX) the smb.conf file is presented out to the World as a web page on TCP port 901 via the SWAT without any protecting login mechanism and with permissions allowing anyone to edit the file. Many admins do not realise that leaving the default Apache install running allows anyone with the IP address of the system the ability to go directly to that configuration file, which can allow them to alter access to shared folders and from there compromise the system and others using CIFS shares. We used to have fun sending messages like "You've been hacked!" to the print queues of such vulnerable servers. The workaround is, as soon as you have configured SAMBA, is to hide the smb.conf or use chmod to change the permissions so only admins can read or write to it, and to edit your services file to disable SWAT's use of port 901 (added by default on many installs). I still come across Linux webservers with this security hole unplugged in the wild, especially on Ubuntu (maybe due to admins not setting a root password or not knowing it?). I'm guessing by your response you did not realise what toys get exposed as soon as you turn on Apache?
> SWAT without any protecting login mechanism
SWAT requires logging in.
"""Access to SWAT will prompt for a logon. If you log onto SWAT as any non-root user, the only permission allowed is to view certain aspects of configuration """
> leaving the default Apache install running ... as soon as you turn on Apache?
SWAT has little to do with Apache. It does not need to use Apache or vice versa. It is possible to configure Apache to run SWAT as a cgi but this is unnecessary and is not normal on Linux or Unix. If this is done then it doesn't use port 901.
".....SWAT requires logging in....." Only if you configure it to. It also passes the login in clear text, leaving you vulnerable even when you think it is 'secure'. In many instances the 'secure' configurations I have seen commit the admin to using the root password, in clear text. If a Microsoft product did the same you'd be shrieking about it being insecure. There are plenty of sites out there that will go through the extensive configuration required to make SWAT more secure, but in really secure environments it will not be allowed.
".....SWAT has little to do with Apache....." True, it is just the two are often bundled into distros and installed (and enabled) by default. Of course, MS build their whole stack, so choosing IIS means you integrate into a stack with security built in from the start. I use Linux a lot but it doesn't make me blind either to its problems or to MS's virtues.
> ".....SWAT requires logging in....." Only if you configure it to.
I just did a clean install from the repo and this is the config file as installed. First SWAT is disabled by default, then it will only run from the localhost, it will not allow connection from any other machine.
The only way to avoid it asking for a logon is to change to demo mode using a runtime option:
Usage: swat [OPTION...]
-a, --disable-authentication Disable authentication (demo mode)
# default: off
# description: SWAT is the Samba Web Admin Tool. Use swat \
# to configure your Samba server. To use SWAT, \
# connect to port 901 with your favorite web browser.
service swat
{
port = 901
socket_type = stream
wait = no
only_from = 127.0.0.1
user = root
server = /usr/sbin/swat
log_on_failure += USERID
disable = yes
}
> ".....SWAT has little to do with Apache....." True, it is just the two are often bundled into distros and installed (and enabled) by default.
So are some games "bundled into distros". Show me the distros that install SAMBA and SWAT "by default". Show me which distros enable these "by default".
The Ubuntu documentation shows that neither SAMBA nor SWAT are installed by default and must be installed by sudo apt-get. SWAT is not enabled and must, at least, have the 'disable = yes' changed to 'no'.
".....Show me the distros that install SAMBA and SWAT "by default"....." Oh dear, the denial is strong with this one. Apart from the fact there are plenty of distros still containing both by default (try a Yahoogle of "linux distro swat samba" to get an idea), you can go and look - as I already suggested - at the copious number of Linux advisories on exactly the issue I pointed out. YOU may know how to configure it, that does NOT mean the rest of the World does. And if I recall correctly, both SAMBA and SWAT were bundled in and active when deployed in even enterprise distros at least as late as RHEL AS 4 (which also means CentOS and Fedora of the same period). Sure, the Penguinistas have cleaned up their act a lot since and improved their SAMBA and SWAT modules, but trying to deny the problem ever existed or does not affect old Linux servers still out there in operation is not being a Penguinista, it's being a fanboi ostrich. Don't fret too much, I'm pretty sure it was also an issue for the Apple fanbois, indeed I think it was still bundled as late as with Mac OS X.
>> ".....Show me the distros that install SAMBA and SWAT "by default"....
> there are plenty of distros still containing both by default
Many distros have Samba and SWAT in their repos, your claim was that they _installed_ and _enabled_ these "by default", and that this allowed them to be accessed from the internet without a login.
> Yahoogle of "linux distro swat samba"
And if you had done that you would not have found anything to back up your claims. For example for Ubuntu Server is tells you that to get Samba and SWAT it is necessary to:
sudo apt-get instal samba smbfs samba-doc swat xinetd
sudo update-inetd --enable 'swat'
sudo dpkg-reconfigure xinetd
and then enter of change the configuration. How does this match your _bogus_ "by default" ?
> And if I recall correctly, both SAMBA and SWAT were bundled in and active when deployed in even enterprise distros at least as late as RHEL AS 4
As it happens I have a client that still runs a RHEL4 box or two that I can access from my desk. They do not use Samba or SWAT but it is installed. Whether this was 'by default' or was selected from the installation list I can't say but it definitely is _not_ active. The xinet.d config file is exactly as installed and has 'disable = yes' and 'only_from = localhost' so it is _not_ active and even if it was activated it is not accessible from outside that machine. Your uninformed claims are completely bogus.
You may also note, if you read anything about the product, that logging in as anything other than root will limit the facilities and _prevent_ updating the Samba configuration. The plain text password issue is easily overcome by using stunnel (or running under Apache with https). As the default is localhost only then this is not an issue.
>>> Many admins do not realise that leaving the default Apache install running allows anyone with the IP address of the system the ability to go directly to that configuration file
That is completely uninformed and bogus. Apache does _not_ install SWAT or v.v. they are completely independent unless deliberately configured.
>>> you did not realise what toys get exposed as soon as you turn on Apache?
Not only bogus and misleading, but also a bare-faced lie.
"....Many distros have Samba and SWAT in their repos...." So first you admit SWAT and SAMBA are in the distros, even though you said they never were....
".... For example for Ubuntu Server is tells you that to get Samba and SWAT...." For which version? The latest? As I stated, I have come across Ubuntu servers in the wild with this security hole wide open, so either they came with it by default OR their admins were not as skilled as you the Linux community likes to think they are, and left their systems with incorrect and insecure configurations, which is easily possible because too many distros are NOT integrated stacks but bundles of disparate software modules, whereas IIS is built to integrate with the security in the MS stack. If you want to pretend the hole never occurs then please go back and look at the large number of websites with pages detailing how to avoid leaving the SAMBA/SWAT hole wide open - they are there for a reason.
"....I have a client that still runs a RHEL4 box or two that I can access from my desk. They do not use Samba or SWAT but it is installed. Whether this was 'by default' or was selected from the installation list I can't say but it definitely is _not_ active.....Your uninformed claims are completely bogus....." So you can't say if it was bundled and enabled by default, but then you can say xinetd.conf hasn't been configured since install (how?) - more than a little denial going on, it seems. Either way, as I stated I remembered, and you cannot disprove, RHEL AS4 had it bundled. You enjoy your denial, you're just adding to my argument that (a) the Apache webserver exposes security holes many Linux admins don't even know about (you yourself don't even know if your RHEL4 client was so configured, you had to go check - not good security practice), and (b) far to many Linux users are far too fast to think "it's Linux, it must be better than COTS software".
"....You may also note, if you read anything about the product, that logging in as anything other than root will limit the facilities and _prevent_ updating the Samba configuration...." I'd argue maybe on a modern release, definitely NOT true on older versions. I suggest YOU go do some Web reading on SAMBA security holes and how SAMBA is viewed as a "gift" by the hackers even with modern releases of SAMBA. Being an ostrich is not a good security policy.
> So first you admit SWAT and SAMBA are in the distros, even though you said they never were....
You appear to be unable to distinguish between your claim of "being installed and enabled by default" (which I said didn't happen) and being "in the distros".
> so either they came with it by default OR their admins were not as skilled as you the Linux community likes to think they are,
It is entirely possible that an admin (probably a click and pray Windows admin) could incompetently configure SWAT and/or deliberately put it into demo mode. That is whole lot different than your bogus claim that merely having Apache installed opens port 901 so that anyone on the net can change the Samba configuration - which is several layers completely wrong.
> So you can't say if it was bundled and enabled by default,
Your reading skills are lacking. I _did_ say it wasn't enabled by default.
> but then you can say xinetd.conf hasn't been configured since install (how?) - more than a little denial going on, it seems.
The /etc/xinetd.d/swat file - which is the appropriate configuration file has the date and time of the install, and is the same as all the other config files created during install and not edited since.
> more than a little denial going on, it seems.
There may be denial going on, but it is on your part, you seem unable to accept that your are clueless about the subject even to the point of mixing up Apache and SWAT.
> you're just adding to my argument that (a) the Apache webserver exposes security holes many Linux admins don't even know about
SWAT is _not_ part of Apache, nor does it normally run under Apache, they are completely products with different installs and different configurations. If you cant even get this right then you shouldn't be allowed near a computer.
> (you yourself don't even know if your RHEL4 client was so configured, you had to go check - not good security practice),
The Red Mist is blocking your reading skills. It is my client's RHEL4 server, not my machine. I always look for _evidence_ to back up my statements which you seem to fail to do, merely saying 'Google for it' or claiming 'denial' for not accepting your unsupported assertions.
As for claiming that 'checking is not good security practice' I am sure that the rest of the forum will have a good laugh over that one.
> I suggest YOU go do some Web reading on SAMBA
And once again you merely wave the 'go and search' because, presumably, you can't actually find an actual reference that supports your claims yet again.
The layers that you have to show are your bogus claims:
* SWAT is related to Apache (not true, but you continue to claim it)
* SWAT is installed _and_enabled_ by default (not true)
* SWAT, by default, requires no logging in (not true)
* SWAT, by default, can be accessed from other machines (not true)
* SWAT allows non-root login to change the Samba config (it does not)
"....You appear to be unable to distinguish between your claim of "being installed and enabled by default" (which I said didn't happen) and being "in the distros"....." Nope. You asked for distros with it bundled. And it was both bundled and active by default in older versions, as I showed with RHEL AS4, which you were unable to disprove (on a client's box you admit you didn't even know the security profile of for a very well-known security issue - not reassuring as to your admin credentials). Yet you want to insist you have disproven the point? Male bovine manure.
".....probably a click and pray Windows admin...." More Penguinista denial - so how do you define a 'Linux admin'? If they have even used Windows once are they somehow disqualified? I suggest you get over your prejudices before you try posting again.
".....even to the point of mixing up Apache and SWAT......" I pointed out SAMBA and SWAT was the hole, it's just that many Linux admins don't know that activating Apache exposes such holes. As you admitted, you had to go check a server you set up for a client as you didn't know if the proper security for SWAT had been set - not exactly a ringing endorsement. And you're still trying to deny (a) it is an extensively documented issue, and (b) turning on Apache without checking DOES leave port 901 open for an attack if the right SWAT security steps have not been taken.
".....SWAT is _not_ part of Apache...." I never said it was, I said it was common for admins to leave the Apache web service running without realising the possible security holes, including the SWAT/SAMBA issue. You are just trying to state something I did not say to avoid admitting you wre wrong. In short, you are a liar.
"....The Red Mist is blocking your reading skills...." The penguin feathers are blocking yours. Wise up - no OS is free of security issues, not even Linux. Blind denial only helps those trying to crack your systems.
".....SWAT is related to Apache (not true, but you continue to claim it)...." Stop lying just because you lost the argument. I never said that at all, if you want to claim I did then please point to my post where I did or just admit you were (a) wrong, and (b) lying.
"....* SWAT is installed _and_enabled_ by default (not true)...." You couldn't even prove this for RH AS4, let alone all the other even older distros, but you want to claim you have proven otherwise? Again, you're just lying, you have disproven nothing. All you proved was you didn't even know the security policy for a client's server, which means you admitted YOU ARE NOT A GOOD SECUITY ADMIN as well as a liar. Quit wasting your time lying and go get some training instead.
"....* SWAT, by default, requires no logging in (not true)...." Another lie, please post to where I said that. It mos certainly did not in many older distros and even on commercial UNIX versions. Once again, blind denial is not proof, no matter how many lies you make up.
"......SWAT, by default, can be accessed from other machines (not true)...." Not what I said, not even close. What I said was an insecure configuration of SWAT would allow any system with LAN access to the target server to go to the SWAT web page on port 901 and edit the SAMBA config. You're just making stuff up. And you even failed to show that wasn't the case for RH AS4 yet want to claim you did! What kind of fantasy world are you living in, where only Windows admins screw up Linux security and well-known issues magically don't matter just because you don't want the too? People like you just give Linux a bad name.
> You asked for distros with it bundled. And it was both bundled and active by default in older versions, as I showed with RHEL AS4, which you were unable to disprove
You do not seem to understand that there is a distinction between 'in the repository' and 'installed and active by default'. Here is actually what I asked:
"""So are some games "bundled into distros". Show me the distros that install SAMBA and SWAT "by default". Show me which distros enable these "by default"."""
I did disprove your claim that it was 'active by default'. More to the point you have not established _any_ of your claims at all, especially where you conflate Apache and SWAT. The configuration file was 'as installed' as shown by the file date/time. Whether the selection box for installing it was clicked by the installer or was already clicked would require me to go through the install process, which you obviously have never done.
> (on a client's box you admit you didn't even know the security profile of for a very well-known security issue - not reassuring as to your admin credentials). Yet you want to insist you have disproven the point? Male bovine manure.
It is not a machine that I administer, nor do I administer _any_ Samba sites , nor is Samba active on any machine that I do administer, so the 'issue' is of no concern to me or the client.
> ".....SWAT is _not_ part of Apache...." I never said it was,
Yes you did, you frequently conflated Apache and SWAT: you claimed: """ and the fact that activating Apache exposes port 901 """. Port 901 is the port for SWAT. AND """(b) turning on Apache without checking DOES leave port 901 open for an attack if the right SWAT security steps have not been taken. """ AND """ Many admins do not realise that leaving the default Apache install running allows anyone with the IP address of the system the ability to go directly to that [Samba] configuration file,"""
> As you admitted, you had to go check a server you set up for a client as you didn't know if the proper security for SWAT had been set - not exactly a ringing endorsement.
It is called 'gathering evidence', something that you seem unfamiliar with.
> And you're still trying to deny (a) it is an extensively documented issue,
What _is_ 'extensively documented', even in the one link that you supplied, is that SWAT is _NOT_ activated by default, despite your repeated bogus claims.
> and (b) turning on Apache without checking DOES leave port 901 open for an attack if the right SWAT security steps have not been taken.
Once again you conflate Apache with SWAT when they have no connection. Apache _never_ opens port 901 (unless explicitly configured for some unknown reason).
> I said it was common for admins to leave the Apache web service running without realising the possible security holes, including the SWAT/SAMBA issue.
And again your attribute Apache as somehow installing and activating Samba and SWAT when they are unrelated products (that both happen to be independently accessed by a browser).
> ".....SWAT is related to Apache (not true, but you continue to claim it)...." Stop lying just because you lost the argument. I never said that at all,
Yes you did, and repeatedly claimed it again, see your (b) above.
> You couldn't even prove this for RH AS4, let alone all the other even older distros, but you want to claim you have proven otherwise?
You have repeatedly made the claim, it is for you to prove. You are just waving aside the evidence, even the evidence in the link that you did provide.
> "....* SWAT, by default, requires no logging in (not true)...." Another lie, please post to where I said that.
Here it is: """ ".....SWAT requires logging in....." Only if you configure it to. """ and here: """On SAMBA (Linux and UNIX) the smb.conf file is presented out to the World as a web page on TCP port 901 via the SWAT without any protecting login mechanism and with permissions allowing anyone to edit the file."""
> "......SWAT, by default, can be accessed from other machines (not true)...." Not what I said, not even close. What I said was an insecure configuration of SWAT would allow any system with LAN access to the target server to go to the SWAT web page on port 901 and edit the SAMBA config.
What you said was: """the smb.conf file is presented out to the World as a web page on TCP port 901 via the SWAT without any protecting login mechanism and with permissions allowing anyone to edit the file.""". Which is and always was completely untrue.
And here, from that message, is another example of your conflating Apache and SWAT: """ I'm guessing by your response you did not realise what toys get exposed as soon as you turn on Apache?"""
If you want your rantings to be accepted then you need to _prove_ that in some distant past SWAT was installed by default, activate by default, in demo mode by default, was accessible beyond the localhost by default, and in any way was part of Apache. Good luck with _any_ of that.
Dear Little Dick,
Please see my previous post that blew a massive hole in your drivel. Enjoy!
Yours ROFLingly,
Matt.
PS: You probably should spend some time on the SAMBA.org site, amongst others, actually learning some web security.
> "....The Red Mist is blocking your reading skills...." The penguin feathers are blocking yours. Wise up - no OS is free of security issues, not even Linux. Blind denial only helps those trying to crack your systems.
I have never denied that OSes have security issues. I am denying that your claims about Apache and port 901, about 'SWAT active by default', about 'no password login by default', are completely untrue.
>As you admitted, you had to go check a server you set up for a client
I did check the server, but it was _not_ one that I set up, there was never the implication that I had done so. In fact I mentioned 'the installer' as a third party.
> as you didn't know if the proper security for SWAT had been set - not exactly a ringing endorsement.
It did not need to be 'set'. It was inactive by default in spite of your bogus claims.
@Matt Bryant
I doubt you have much experience with Unix/Linux beyond looking after a couple of servers for which you from time to time used to login into the terminal and type a few commands, praying that something strange does not happen so it doesn't ruin your weekend, due to your very limited knowledge of the subject.
That is the feeling most Windows users and occasional Unix administrators have when they deal with Unix/Linux servers.
At some point in time in the distant past SWAT used to be part of the Samba download, but it was never enabled by default, and certainly not without a password unless the user configured it manually that way.
SWAT and Samba although related have been separated as individual components by most distros since I can remember.
".....I doubt you have much experience with Unix/Linux beyond looking after a couple of servers...." The fanboism is strong with this one! Your assumption would be fine if it weren't for the many, many websites detailing the problem with SWAT and SAMBA, the numerous sites explaining how to crack servers using SAMBA, and the fact that activating Apache exposes port 901 if you don't go tighten up the security. So, in short, your're talking male bovine manure almost as much as Dick Plinston.
".....At some point in time in the distant past SWAT used to be part of the Samba download, but it was never enabled by default, and certainly not without a password unless the user configured it manually that way....." Except RH AS4, maybe? Or are you going to admit you simply haven't a clue to anything predating last year's Ubuntu release because it is you that has an experience going back five minutes. Face facts - denying security holes does not make them disappear! I suggest you STFU and go read the samba.org security history page to LEARN SOMETHING (http://www.samba.org/samba/history/security.html).
> and the fact that activating Apache exposes port 901
Apache _never_ exposes port 901 (unless someone explicity adds it to the config). You appear to be unable to distinguish between the http protocol and Apache as a web server for ports 80 and 443. There are many ports and each may have its own distinct server program.
> (http://www.samba.org/samba/history/security.html).
An actual link. Wonder of wonders!!
However, NONE of that support _any_ of your claims. They do refer to 'Clickjacking' and 'Cross-Site Request Forgery' which are the result of security issues in the _browser_client_, such as Internet Explorer.
If you had actually read any of the reports you may have LEARNED SOMETHING because you would have found:
""" Note that SWAT must be enabled in order for this
== vulnerability to be exploitable. By default, SWAT
== is *not* enabled on a Samba install.
"""
So even the links that you offer as support show your claims are wrong.
".....Apache _never_ exposes port 901...." No, web requests via http are never handled by Apache.... DUH! If you go read the Linux (and many UNIX) pages on setting up SWAT you will often see a line 'add and entry for swat in /etc/services if it is not there already', as in added during SWAT installation. BTW, this was added as default in RH AS4, as you admitted were unable to prove otherwise. I'm also pretty sure it used to get added into /etc/services or /etc/xinetd on hp-ux by default (at least up to 11.0) and Solaris 10, though I can't recall what happens with AIX.
"......An actual link. Wonder of wonders!!......" You like that link? Bet you'll really like the line "...,The very first step that should be taken before attempting to configure a host system for SWAT operation is to check that it is installed. This may seem a trivial point to some, but several Linux distributions do not install SWAT by default...." (http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html#id2681073). Oh dear, do you now want to try and pretend that does not imply several Linux distros DO install it by default? Want to argue with the actual SAMBA official documentation? Because if you do then you're an even more stupid and blind Penguinista than I thought. Enjoy!
> ".....Apache _never_ exposes port 901...." No, web requests via http are never handled by Apache.... DUH! If you go read the Linux (and many UNIX) pages on setting up SWAT you will often see a line 'add and entry for swat in /etc/services
You are obviously unaware that different services are handled by different programs and you have never even looked at /etc/services. Connections on ports 80 and 443 are passed to Apache (if installed and activated), port 21 is passed to the ftp server (if installed and activated), port 3306 goes to MySQL, etc.
That is _why_ there are different ports, because there are different services provided by different programs. inetd is the program that receives the connections and passes them to the services based on the /etc/services configuration and on the various matching xinetd.d configuration files.
It happens that connections on port 901 are _not_ passed to Apache but go to SWAT if it has been installed _and_enabled_.
If you can't even understand this fundamental level of networking then you should not be posting at all.
> but several Linux distributions do not install SWAT by default ... several Linux distros DO install it by default?
1) SWAT is only ever installed _if_Samba_is_installed_. So when Samba is installed if may, or may not, install SWAT as well (which is the point made by the Samba team). So to prove your point you need to find out if Samba is installed _by_default_ and then determine if this also installs SWAT _by_default_.
2) NONE of them _activate_ it by default, which was your claim.
3-5) NONE of them configure it in demo-mode, open to the web, or able to write without a non-root login, which were also your claims.
You are _way_ out of your depth.
".....You are obviously unaware that different services are handled by different programs ....." Take a look at the URL you type into the browser to get to SWAT, probably something along the lines of http://www.dickthethick.com:901. You may note the bit at the start with 'http'? You do realise that all webservers, by default, listen on port 80 for http requests and then pass the request to any port you add on the end if the URL? Oh, you didn't? Please do point out the process you think is able to handle the http requests other than the process httpd? As a clue, it is not smbd. A socket connection is not the same as a webservice, if I turn off my webserver it doesn't matter what port you add on the end of the URL in a browser, you will not see any webpages, because there is nothing on port 80 to answer the request and push the connection to port 901.
".....port 21 is passed to the ftp server...." A good example - if you don't have the FTP server, the process ftpd, running, you will get SFA if you try connecting to port 21.
".....If you can't even understand this fundamental level of networking then you should not be posting at all....." You don't know how a webserver to handles port number requests on the end of an URL for a web service. It is different to ordinary TCP socket connections. You seem very confused and angry, TBH.
"You do realise that all webservers, by default, listen on port 80 for http requests and then pass the request to any port you add on the end if the URL? "
Do they though. Wiki here https://en.wikipedia.org/wiki/Uniform_Resource_Locator#Syntax says this-
.
The port number, given in decimal, is optional; if omitted, the default for the scheme is used.
For example, http://vnc.example.com:5800 connects to port 5800 of vnc.example.com, which may be appropriate for a VNC remote control session. If the port number is omitted for an http: URL, the browser will connect on port 80,
.
So the trailing port number if specified is used to connect to the port before (note: before) the webserver even sees it. It doesn't "pass on" the request to the port given in the URL. The webserver has to be listening on the port given in the URL to see it at all. That's why you can configure web servers to listen for http on port 9999 if you wanted to, and nothing on port 80, and if you specify http://domain.org:9999 then you'll get web pages.
".....The port number, given in decimal, is optional; if omitted, the default for the scheme is used....." Oh, if only you had bothered to try reading a few lines more:
".....The scheme, often referred to as protocol, defines how the resource will be obtained. Examples include http, https, ftp, file and many others. ..." In this case, the scheme is http, therefore it is an http request handled by httpd, that being the webserver, which listens on port 80. If you had sent the request to ftp://www.thickiedick.com then ftpd, the ftpserver, would attempt to handle your request on port 21. No webserver means no httpd means nothing to handle requests to that scheme.
"....That's why you can configure web servers to listen for http on port 9999 if you wanted to, and nothing on port 80, and if you specify http://domain.org:9999 then you'll get web pages." Only if your web service is running, you moron. No httpd and it doesn't matter what port you have specified.
"In this case, the scheme is http, therefore it is an http request handled by httpd, that being the webserver, which listens on port 80"
*by default* port 80. If you configure it to run on 9999 then nothing will be listening on port 80 because it isn't a default. If you then try to contact the webserver then just putting in a URL like http://domain.com will get you nothing as nothing is listening on port 80. You have to add the port suffix so http://domain.com:9999 and then you will get results.
This is my understanding anyway. Please post a citation showing that a web server is ALWAYS listening on port 80 so as to redirect incoming connnections to any port that's in that URL
"Only if your web service is running, you moron"
and only if the computer is switched on too.
"....*by default* port 80. If you configure it to run on 9999 then nothing will be listening on port 80 because it isn't a default....." Which ignores the fact you need the http process running and listening to a port, whether the default or one you have configured.
".....Please post a citation showing that a web server is ALWAYS listening on port 80 so as to redirect incoming connnections to any port that's in that URL...." FAIL! I never said that http had to be tied to port 80 only, just that it has to be listening on a port to answer http requests.
".....and only if the computer is switched on too." OMG, that's the closest you've been to posting anything even vaguely correct.
"FAIL! I never said that http had to be tied to port 80 only, just that it has to be listening on a port to answer http requests."
Oh really. Well then
"In this case, the scheme is http, therefore it is an http request handled by httpd, that being the webserver, which listens on port 80. "
further " "....*by default* port 80. If you configure it to run on 9999 then nothing will be listening on port 80 because it isn't a default....." Which ignores the fact you need the http process running and listening to a port, whether the default or one you have configured. ""
You appear to be confusing IP ports with the presence of the httpd process. They are not the same thing.
> "....That's why you can configure web servers to listen for http on port 9999 if you wanted to, and nothing on port 80, and if you specify http://domain.org:9999 then you'll get web pages." Only if your web service is running, you moron. No httpd and it doesn't matter what port you have specified.
No. You are completely _wrong_. You do not need anything listening on port 80, nor do you need 'httpd' nor Apache. I can write a program, or configure one, to listen on port 9999 and have that serve 'web pages' (or anything else that I wish) in response to http requests made on port 9999 _without_ there being any httpd program in the system.
And that is because xinetd does the work, not Apache.
> You do realise that all webservers, by default, listen on port 80 for http requests and then pass the request to any port you add on the end if the URL? Oh, you didn't? Please do point out the process you think is able to handle the http requests other than the process httpd?
Yes, a webserver, such as Apache or Nginx or many others, will listen on port 80 and usually also on port 443. You then confuse this with _all_ possible http servers. CUPS will listen on port 631 for http requests, Webmin will listen on port 10000 for http requests. These are all servers and will respond to http requests on the ports they listen to.
If a port number is added to an http request (such as https://localhost:10000) is _DOES_NOT_ go to port 80, nor to Apache, it goes to Webmin server directly (if it is running) or goes nowhere (if no server is listening on port 10000), it does not go to Apache or Nginx.
You have a fundamental misunderstanding of how http works. It is not 'http' that directs connections to a particular webserver, it is the port number. It is the browser that adds the default port numbers of 80 and 443 (for http and https) if no port is added. If a port number is added to the URL and Apache is not listening on that port then Apache does not see it. Apache is _not_ doing the routing.
If you were to actually look at an /etc/service file (which apparently you had not even heard of before) you would see the list of possible services where the port number is matched to service. This is _not_ handled by Apache, but by a lower level service: inetd or xinetd.
https://en.wikipedia.org/wiki/Xinetd.
> Please do point out the process you think is able to handle the http requests other than the process httpd?
Xinetd handles all connection requests and passes them out, as defined in the /etc/services and xinetd.d files to the appropriate server. This may be Apache for port 80 or CUPS for port 631 or ftpd for port 21.
How hard is that ?
".....Webmin will listen on port 10000 for http requests...." Webmin? LOL! Go have a look, buried in the menus of Webmin you will find - tada! - SWAT!
".....These are all servers and will respond to http requests on the ports they listen to....." <Yawn>. Yes, you're just dancing around the fact you still need a webserver of some form to handle the http requests, and for Linux it is Apache that is the most popular choice, therefore it is Apache which will unquestioningly send requests on to port 901 and the potential security hole of SWAT if you haven't got your security sorted.
"....If a port number is added to an http request (such as https://localhost:10000) is _DOES_NOT_ go to port 80, nor to Apache, it goes to Webmin...." Apart from the fact Webmin isn't bundled by default with many Linux distros, it is just a web front end to SWAT and other tools, so still uses SWAT and therefore offers the same security issues. The fact it takes over the http handling does not change anything at all. Your failure to understand this is just in addition to all your other failings.
".....You have a fundamental misunderstanding of how http works...." You have a fundamental inability to read and comprehend. Your own AC buddy posted a link to an explanation of how different schemes such as http, https and FTP were handled.
".....If you were to actually look at an /etc/service file (which apparently you had not even heard of before) you would see the list of possible services where the port number is matched to service. This is _not_ handled by Apache, but by a lower level service: inetd or xinetd....." Your denial is getting very boring. Yes, /etc/services lists the ports that particular processes are allowed to connect on. Included should be an entry for swat on port 901. But all the services file does is list the files connections are allowed on, it does not handle the protocol of the connection. That is handled by the protocol concerned, and in SWAT's case that is httpd. That is handled at the setup stage by http, on port 80 (or whatever port your deluded AC buddy wants to set for http) and THEN handed over to port 901 for the transfer of data. The whole process is run as a webpage (<= big hint there) over http by httpd. If it was not the it would have to open some form of GUI windows such as an x11 one. Do you really think the GUI page presented just manifests by itself? Other services, such as telnet, which does not automatically have a GUI but run as CLI processes, do just use the port in /etc/services and don't need the httpd process because they are not presenting a webservice. The route to SWAT is through a webserver be it Apache or Webmin or whatever other webserver you want, and Apache is the most common on Linux.
".....How hard is that ?" Obviously too hard for you to comprehend, Dick.
> ".....Webmin will listen on port 10000 for http requests...." Webmin? LOL! Go have a look, buried in the menus of Webmin you will find - tada! - SWAT!
You will find a _link_ to swat, if it is installed. That link will contain the swat port number. so when that link is clicked in the browser the connection goes directly to swat (via xinetd and given the config allows it). It does _NOT_ go via port 80, 'httpd' or webmin.
> you still need a webserver of some form to handle the http requests,
SWAT _is_ a webserver (on port 901)
Webmin _is_ a webserver (on port 10000)
CUPS _is_ a webserver (on port 631)
You _do_not_need_ a webserver on port 80, nor 'httpd', to access those webservers. There is no need to run a general purpose webserver, such as Apache, in order to run those specialised webservers.
> and for Linux it is Apache that is the most popular choice, therefore it is Apache which will unquestioningly send requests on to port 901
_NO_IT_DOES_NOT_. Xinetd sends the requests to swat on port 901.
> and the potential security hole of SWAT if you haven't got your security sorted.
Only if is _deliberately_ installed AND _deliberately_ configured to be a) active, b) open to other machines, c) set so non-root users logins can write (if that is actually possible).
> That is handled at the setup stage by http, on port 80 (or whatever port your deluded AC buddy wants to set for http) and THEN handed over to port 901 for the transfer of data.
_NO_IT_IS_NOT_. An http request on port 901 _DOES_NOT_ go to port 80. Xinetd sends it to the webserver configured on port 901, swat is that webserver.
What you are confused by is that any webserver, or indeed any server, on any port will respond to a *connection request* by assigning an _unused_ port number to continue the conversation on until the request is completed.
So, for example, Apache will get a *connection request* on port 80 and then may assign, say, port 56382 to that conversation which will then be used while all the parts of the web pages are sent.
Swat will get *connection requests* on port 901 (without Apache, httpd, or port 80 involved at all) and will also assign an unused port to the conversation, maybe 41307.
> The whole process is run as a webpage (<= big hint there) over http by httpd.
The whole process is run as a webpage over http by WHICHEVER WEBSERVER you connect to. SWAT _is_ a webserver and does not need, nor use, any other httpd server or webserver.
@Richard Plinston
Matt and I have met before and from too much experience I can say it is unproductive for all concerned. He is blatantly wrong and ill informed about ports on URLs but he can't admit defeat and will duck and dive and misconstrue in a pointless but superhuman effort to save face. I advise you to please give up and get on with yoru life or he will suck you dry of goodwill, good humour and free time.
"Matt and I have met before...." Unlikely, I haven't been near a kindergarten for many, many years.
".....He is blatantly wrong and ill informed....." I'm guessing you had just as much failure in proving me wrong in another thread as Dick is here, hence your sulky forum stalking. LOL! How sad you are.
".....SWAT _is_ a webserver ....." No it is not. Create an HTML page such as index.html in the same path as the SWAT executable, kill your webserver, then go to your client and try accessing it with say http://servername:901/usr/local/samba/swat/index.html - it will not work.
> ".....SWAT _is_ a webserver ....." No it is not. Create an HTML page such as index.html in the same path as the SWAT executable, kill your webserver, then go to your client and try accessing it with say http://servername:901/usr/local/samba/swat/index.html - it will not work.
You are a complete fuckwit.
SWAT does not send static html pages (such as files containing html), it sends dynamic html pages that it generates itself. It does not need to be a general purpose webserver to be an actual webserver.
".... it sends dynamic html pages that it generates itself...." It generates dynamic HTML pages, that is all. The webserver serves them.
".....It does not need to be a general purpose webserver to be an actual webserver." So, it's a webserver, just not an ordinary 'general purpose' webserver. And you said that before? No. You claimed it was a webserver. So now it's a special webserver that doesn't serve webpages unless it generates them itself? And doesn't answer http requests like a webserver.... But it is a webserver. BTW, you do realise that DHTML is a group of technologies that produces the dynamic webpages, usually by scripting in something like JavaScript, but doesn't include the tech to serve them to clients. That is done by a webserver in a client-server http- or https-based communication. No webserver and no presentation of the dynamic pages. Are you now going to claim they are not 'general purpose' dynamic HTML pages but 'special' ones to go with the 'special' webserver?
> So, it's a webserver, just not an ordinary 'general purpose' webserver. And you said that before? No. You claimed it was a webserver. So now it's a special webserver that doesn't serve webpages unless it generates them itself?
That is correct, it serves webpages that it generates all by itself, it serves them directly back to the client. It is a 'specialized' webserver. One that does one particular job with a particular set of pages that it does not allow to be changed, such as may occur if they were disk files that could be edited. It does not do anything that is unrelated to Samba, it leaves that to other programs.
It is not "special". Your misreading and misrepresentation shows up your lack of language skills, or perhaps you just don't know the difference. It is not 'special' (it is specialized) because there are dozens or hundreds of programs that are webservers in their own right and don't need Apache or port 80 to serve web pages. I can write one in a few minutes.
> BTW, you do realise that DHTML is a group of technologies that produces the dynamic webpages,
"DHTML" is merely a collection of languages and ways of using them, it is not a server. It is not the _only_ way of having dynamic webpages, it can be dynamic _without_ specifically being DHTML.
From : https://en.wikipedia.org/wiki/Dynamic_HTML
"""By contrast, a dynamic web page is a broader concept, covering any web page generated differently for each user, load occurrence, or specific variable values."""
> usually by scripting in something like JavaScript, but doesn't include the tech to serve them to clients.
SWAT is probably written in C. Javascript is usually on the client side rather than the server. SWAT _does_ include the program code to send the pages to the client, it is not hard to do. It does not require any other program to do that for it. But then I doubt that you could recognise the difference.
> No webserver and no presentation of the dynamic pages.
It is a webserver. It does present the pages to the user.
> 'special' ones to go with the 'special' webserver?
'Specialised', do try and learn something, even if it just the ability to read some words without changing them.
"....That is correct, it serves webpages that it generates all by itself, it serves them directly back to the client. It is a 'specialized' webserver....." I suggest you go to http://ftp.samba.org/pub/samba/ and download the source for SAMBA 3, have a look in samba-3.0.37.tar\samba-3.0.37\source\web\swat.c and see if you can find any webserver code or libraries in there, stuff like including httpd.h or ap_listen.h. There's plenty of page formatting and click action processes, but no webserver code. So, it's a specialised webserver that has no actual webserver parts? If you want to compare it to an actual webserver that can serve up dynamic HTML files, the Apache HTTP server source code is at http://httpd.apache.org/download.cgi#apache24. It should be an easy compare for you seeing as how you said ".....I can write one in a few minutes....."
"....Your misreading and misrepresentation shows up your lack of language skills..." So, you called it a 'webserver', not me, then you called it a 'specialised webserver', and now it turns out the source code shows it is nothing of the type. Hmmm, you sure English is your native language, Dick?
"....But then I doubt that you could recognise the difference...." Well, I could see plenty of differences between the C code for SWAT and the C for Apache's HTTP server. Like the fact the latter has code for webserving and the former doesn't.
"....even if it just the ability to read some words without changing them." So you wriggled from 'websever' to 'specialised webserver' and it's me that's changing words? ROFL! I do so enjoy your rants, Dick.
@Matt Bryant
http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html
Find any mention of apache or httpd?
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch10_:_Windows,_Linux,_and_Samba
Find any mention of apache or httpd?
(see in particular http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch10_:_Windows,_Linux,_and_Samba#Basic_SWAT_Setup)
or here http://theurbanpenguin.com/wp/?p=1939
Find any mention of apache or httpd?
or here http://ubuntuserverguide.com/2012/10/how-to-install-and-configure-swat-samba-web-administration-tool-on-ubuntu-server-12-04.html
Find any mention of apache or httpd?
or here http://ktaraghi.blogspot.co.uk/2013/01/the-samba-web-administration-tool-swat.html
Find any mention of apache or httpd?
How about more specific comments from http://forums.justlinux.com/showthread.php?86698-Can-t-quot-see-quot-SWAT&p=482646
Look for line "I haven't used SWAT, but I'm pretty sure you have to have apache web server running."
responses are
"I'm following a book called "Samba Essentials for Windows Adminstrators" by Gary Wilson. This book says that SWAT includes it's own "mini-web server" so I shouldn't need Apache."
and
" >haven't used SWAT, but I'm pretty sure you have to have apache web server running.
The answer to this is NO.
Try opening konqueror/mozilla or any web browser and enter
http://localhost:901
This should take you to swat. "
edit: Richard Plinston, like I said don't argue with Matt, it'll suck up all your free time and get him and you nowhere.
"....Find any mention of apache or httpd?...." LOL, shouldn't you be helping Dick with the source code and finding the hidden 'specialised webserver' in swat.c? ROFL!
"....don't argue with Matt, it'll suck up all your free time and get him and you nowhere." What, like when you fail to find any evidence to back up Dickie's claim? I do so enjoy watching you forum-stalkers wade in and then high-tail it out again when you get another intellectual beating.
>> ".....SWAT _is_ a webserver ....." No it is not. Create an HTML page such as index.html in the same path as the SWAT executable, kill your webserver, then go to your client and try accessing it with say http://servername:901/usr/local/samba/swat/index.html - it will not work.
Matt: You are clown. Totally an idiot. Witless.
>You are a complete fuckwit.
yup
> if I turn off my webserver it doesn't matter what port you add on the end of the URL in a browser, you will not see any webpages, because there is nothing on port 80 to answer the request and push the connection to port 901.
That is completely and absolutely untrue. SWAT, for example, will listen on port 901 and respond to that regardless of the presence or absence of 'httpd'. Putting the port number on the URL _DOES_NOT_ send the request on port 80, nor does it send it to 'httpd', Xinetd routes it based on /etc/services (and depending on limitations in the appropriate firewall and config files) directly to the service, which in this case is swat.
Yes, I have been confused by your claims, but that is because I understand how it actually works, and not some mish-mash of your half-learned misunderstandings.
> http://www.dickthethick.com:901. You may note the bit at the start with 'http'? You do realise that all webservers, by default, listen on port 80 for http requests and then pass the request to any port you add on the end if the URL?
Deliciously wrong, Matt.
The port number given at the end, in this case 901, is where the http request goes to directly. It does not go to port 80 first to be handed over by Apache or some other webserver, it goes straight to 901.
You can fairly easily try this out yourself. E.g. by installing and configuring SWAT in a VM.
"....Deliciously wrong, Matt....." And your proof of this is.... Oh, you don't have any. Not really a surprise, TBH.
".....The port number given at the end, in this case 901, is where the http request goes to directly....." And the httpd service to answer the http request is.... Oh, it's in a webserver, which SWAT is not (see earlier in the thread and feel free to go look in swat.c for the mythical webserving code).
"Oh, it's in a webserver, which SWAT is not "
Still a moron, Matt?
http://www.samba.org/samba/docs/man/manpages/swat.8.html says
"swat is run from inetd"
and with a bit more detail
.
Inetd Installation
You need to edit your /etc/inetd.conf and /etc/services to enable SWAT to be launched via inetd.
In /etc/services you need to add a line like this:
swat 901/tcp
Note for NIS/YP and LDAP users - you may need to rebuild the NIS service maps rather than alter your local /etc/services file.
the choice of port number isn't really important except that it should be less than 1024 and not currently used (using a number above 1024 presents an obscure security hole depending on the implementation details of your inetd daemon).
In /etc/inetd.conf you should add a line like this:
swat stream tcp nowait.400 root /usr/local/samba/sbin/swat swat
Once you have edited /etc/services and /etc/inetd.conf you need to send a HUP signal to inetd. To do this use kill -1 PID where PID is the process ID of the inetd daemon.
LAUNCHING
To launch SWAT just run your favorite web browser and point it at "http://localhost:901/".
.
Not apache/httpd. Nor do you need apache running to 'redirect' incoming urls from port 80 to 901.
Yes you are. You are a moron.
Dear fellow AC, he's not gonna admit to having it wrong. That's the fun bit. He just can't.
And as for proof, Matt, I invited you to try it out by setting this up yourself. Spin up a VM, install swat, check while it's installing that it doesn't pull in apache as a dependency, configure it to allow login from other machines, log in from another machine's browser with :901 at the end of the URL to see it work. telnet port 901 of the swat-machine and telnet port 80, you'll see (provided you haven't installed something else to listen to port 80) that port 80 doesn't respond but 901 does. If you get a response on port 80, you can e.g. lock that down in the firewall and then try connecting with a browser to port 901. You'll see it still works because the traffic just does not go to port 80 first to then be forwarded to 901.
Dear Johnnie Fail Lately,
We covered all the inetd and services bit nine days ago, is that too long a period for you to remember? In short, the scheme of the request is http, therefore - regardless of the port on the end of the URL - the request goes to the default port you have set as your httpd listener (usually port 80). If there is no webservice to handle the http request then nothing happens.
We also covered the fact that swat.c just produces dynamic HTML content and has no code for serving webpages or forming TCp connections. Go back and read the thread, moron.
> In short, the scheme of the request is http, therefore - regardless of the port on the end of the URL - the request goes to the default port you have set as your httpd listener (usually port 80).
You're getting ever more confused, Matt. It's the client, in the case of http usually a web browser that determines the port it sends the request to. It will always send to port 80 for http if nothing else is specified, and if some other port is specified (e.g. :901 at the end of the URL) it will go straight to that port without going first to 80 or some other made up default port.
If you don't want to spin up a VM just make the request with a browser and have tcpdump show you it's going straight to the designated port. Just try it out FFS.
Dear Matt, *we* covered inetd, you kept on insisting on apache/httpd. We said it didn't need apache, you said it did. You are wrong. Do you now acknowledge that apache isn't necessary?
"In short, the scheme of the request is http, therefore - regardless of the port on the end of the URL - the request goes to the default port you have set as your httpd listener (usually port 80). "
No, as someone much, much, much, much, much, much, much, much, much smarter than you pointed out, it's handled by inetd or similar. You don't know what inetd does, do you, you prat.
"We also covered the fact that swat.c just produces dynamic HTML content and has no code for serving webpages or forming TCp connections"
The rest of the internet says you are wrong. The samba docs I linked to say you are wrong. forums say you are wrong. Reading the inetd wiki page would explain why you are wrong. You are very, very, very, very, very, very, very stupid.
Why not try out what the other AC suggested, namely, try it out by trying it out. Yes, try it. You are stupid.
"the large number of (insecure) Linux servers I see with Apache installed and advertising itself by default."
As opposed to the not-as-high-but-still-significant umber of IIS servers where the default "IIS <x>" page has been left sitting there? In my experience, port scanning such a server is far more interesting than port scanning an Apache "It Works" server (not that my sample size is very big).
Until one good day you apply an official patch to one of the components of your server stack, and it breaks the entire thing, and MS's answer is for you to migrate the entire stack to Windows 20XX (whatever the last version is) where you discover that some component you rely on has been deprecated.
Exchange 2003/2007 comes to mind somehow.
People here talk about having difficulty about tracking fixes on Linux, as if in Linux is not the norm that the distribution (specially RH and Debian) is the one that publishes the patches for you, and being able to patch even without having to restart services wasn't common.
While in Windows the norm is not only having to reboot the entire server, but also the fact that functionality may break with updates.
You really need to take the fantard blinkers off and go read a bit of history. Linux has definitely not been free of security issues. Since you have a hard-on for Apache, maybe you should go read up on the old apache-scalp.c crack, probably from long before you first used a keyboard.
Last time was at the dawn of the millenium, before all the "on by default" options meant it was trivial to hijack. Back then, even the Apache sites didn't report the real server name (e.g. Rapidsite).
what is incredible, is that _after_ that debacle, IIS can claw its way back as a brand (not as if there is anything of the original code left in IIS)
Dammit, I recollect writing about this before. Aha, here[1] it is, from February 2007. That'll be around the era when I was also writing a column in El Reg.
I think the points made there still stand. If anything's changed it'll be that nginx users might've started to join apache users in following security checklists that tell them to lie about themselves. The most popular Apache security recipes still suggest (as an example) that the server identify itself as IIS.
[1] http://bahumbug.wordpress.com/2007/02/09/numbers-games/
"....The most popular Apache security recipes still suggest (as an example) that the server identify itself as IIS....." Which ignores the fact many IIS server admins also try to hide their servers' identities as well. Indeed, many IIS servers run on corporate intranets and therefore are not visible on the Web at all, making IIS's real share of the webserver market even larger than the Netcraft survey suggest.
Indeed, many IIS servers run on corporate intranets and therefore are not visible on the Web at all, making IIS's real share of the webserver market even larger
Clearly the word WEBserver (shorthand for WORLD WIDE Web) is lost on you if you're counting private Intranet servers.
Which ignores the fact many IIS server admins also try to hide their servers' identities as well
RESPECT THEIR SECURITY-FU! No wait. Why lose time with inanities like that? Oh well...
Indeed, many IIS servers run on corporate intranets and therefore are not visible on the Web at all, making IIS's real share of the webserver market even larger than the Netcraft survey suggest.
"Please find the various problems with this statement for 15 points."
> many IIS servers run on corporate intranets and therefore are not visible on the Web at all, making IIS's real share of the webserver market even larger than the Netcraft survey suggest.
All my corporate clients run Apache on Red Hat for their internal web servers and for the web facing server.
"All my corporate clients run Apache on Red Hat for their internal web servers and for the web facing server."
I have worked in many very large companies and I havnt yet been to one that doesnt run at least some of it's internal sites on IIS - it's a requirement for Sharepoint for instance which pretty much every large company uses. And I am seeing that companies are increasing moving their external sites to IIS too.
"making IIS's real share of the webserver market even larger"
If we're playing games like this, then let's consider all the embedded web servers in printers and ADSL routers etc. None of those are running IIS or Apache.
These will outnumber all Apache + IIS web servers by a large margin.
Even Drupal and many other PHP/Python softwares run flawlessy in a WAMP setup. Although apache.org no longer delivers precompiled Windows binaries (a mistake, IMHO), Apache Lounge does s good job in delivering them.
As long as you don't need the deep intergration with the whole Windows OS - something usually more needed in intranet sites than in public ones - Apache on Windows in not a second citizen since release 2.0.
I mean, if you want to run Windows then that is fine, but why not just use IIS as well and be done with it?
If you want to run apache + mysql + php then why not host that on Linux?
After all it's not like the Windows versions of AMP have the nice gui based administration tools that are so beloved by Windows admins. You still have to edit the same configuration files on both platforms.
It makes no sense to me.
Errm - you mean like the market #1 - Sharepoint Server?
No, that would be WordPress with over 60 million installations on the web alone (figures from 2012). MicroSoft sold just 35 million licenses 2006 - 2012, but I suspect that not all of those licenses are still in use. As to the question from the original poster, I've yet to meet someone who regards SharePoint as "popular" in the sense that people like it. It's an absolute dog, with content disappearing into it never to be found again, mainly due to the piss poor indexing (that's when it actually bothers to index things - often it doesn't).
>>>>Errm - you mean like the market #1 - Sharepoint Server?
>>No, that would be WordPress with over 60 million installations
Ah, that would be WordPress which you can run on IIS. So in answer to the original question of someone saying "can you name a CMS that runs on IIS / Windows", what you're saying is that both first and second most popular CMSs in the world can.
It's rare to see you supporting MS as a viable platform. Glad to see you're becoming more open-minded. ;)
(Now where the gun-foot icon? :D )
To quote the report "However, Apache continues to dominate in terms of active sites, i.e. sites which are actively managed by humans rather than being automatically generated for use in activities such as link farming and domain squatting."
Yeah, if Microsoft do shout about their wins you can bet they miss out the bit about being the preferred choice for link farming and domain squatting.
"How many of these so called active websites are in fact OWA portals / SBS remote access gateways / ActiveSync gateways?"
Quite a lot if they just did a crawl of the internet.
To be fair though, similar things could be said about how many Apache servers are just a webmail interface or some other locked out staff only business convenience. Probably less common, but still some out there.
IIS used to be terrible, and now it isn't. Apache has had it's moments too, but as of 2014, both servers are excellent and plenty capable of hosting sites. Even the CFO at MegaCorp Inc is likely to understand now that choosing between IIS and Apache is a fair comparison as opposed to Corporate IIS vs Hippie Apache, or Free Apache vs. Expensive IIS.
Net - does it matter?
If Microsoft crow about this win, that's their right, but it seems a bit pathetic. They always had a weakness for being seen as one of the cool kids, but they never were.
Well, it sure brings back memories from before the Global War On Stuff -- struggling with getting servlet engines to work via ajp while random people told me how cool and easy asp and ActiveX were only to be hacked up the wazoo a bit later, so .... yeah.
Horses for courses. Hardware resources are cheap; only sites with very heavy load, or artificially limited hardware, need nginx's performance advantage. And Apache has a lot of features which nginx lacks, and which are important for some applications.
You'd have to be pretty naive to think one web server will suit everyone's needs.
The commercial multiprotocol (including HTTP) communications server component that I designed, implemented, and maintain, which is included in a number of our products, uses a single-process thread-pool async-I/O approach1, so much more like nginx than Apache. But I recognize that it's often useful to have process-per-conversation isolation (as in Apache 1, and in some Apache 2 configurations) or process partitioning (as in Apache 2 hybrid configurations).
1That's in the latest incarnations, for the past year or two. The previous incarnations were single-process, thread-per-conversation, blocking-I/O, which in theory is far too resource-intensive but in practice had negligible performance or capacity issues for any of the actual customer workloads it handled. The move to thread pooling and async I/O was an incremental improvement, primarily for capacity. With thread-per-conversation you might expect scheduling would have significant cost, but it disappears into the vast gulf of network I/O time.
Who owns these parked websites, it wouldn't be Microsoft by any chance ..
"Microsoft’s recent gain which gives them 32.8% of the market came solely from one player Nobis. Since it’s not a gradual market shift from Apache to IIS, we can’t call it new trend. Last year Microsoft made similar gain when GoDaddy moved around 9 million sites to Microsoft server." ref
So.. They are going to release IIS as a standalone app? And I can install it on top of Linux? No? Then I don't think so.
Have you seen Server 2012? Who in their right mind (beside a project manager, or CEO, or other low-information plod) would want to run a touchscreen OS as their server.
This isn't Minority Report, this is real life.
"Who in their right mind (beside a project manager, or CEO, or other low-information plod) would want to run a touchscreen OS as their server."
Someone who undersatands that touch and gesture based computing is the clearly the future so to use an OS that's ahead of the curve makes sense? I guess you are to poorly informed to know - but Windows Server doesnt even install a GUI by default...
Besides, it's cheaper to license and has a lower TCO in most uses than say Red Hat or SUSE.
A) Prove "Besides, it's cheaper to license and has a lower TCO in most uses than say Red Hat or SUSE" is true.
B) Prove it's cheaper than using instances of RedHat for Dev/Test but CentOS for production
C) Prove it's cheaper than CentOS front to back.
Don't rush, I'll wait...
".....Who in their right mind (beside a project manager, or CEO, or other low-information plod) would want to run a touchscreen OS as their server....." Someone that actually knows enough to know you can install WS2012 without the GUI, maybe?