Microsoft poised to take Web server crown from Apache 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 Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
