Softpanorama

May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Using deny directive in apache .htaccess

News  Apache .htaccess file Recommended Books Recommended Links Flags
mod rewrite mod_security Apache .htaccess file Using deny directive in apache .htaccess Blocking bad referrers
RewriteBase directive Perl Regular expressions Tips Humor Etc

You can also allow or deny by domain name rather than IP address. For example

deny from .poneytelecom.eu

works for 62-210-83-26.rev.poneytelecom.eu, 62-210-142-7.rev.poneytelecom.eu and 15 62.210.91.168 62-210-91-168.rev.poneytelecom.eu

The directives provided by mod_access are used in <Directory>, <Files>, and <Location> sections as well as .htaccess files to control access to particular parts of the server. Access can be controlled based on the client hostname, IP address, or other characteristics of the client request, as captured in environment variables. The Allow and Deny directives are used to specify which clients are or are not allowed access to the server, while the Order directive sets the default access state, and configures how the Allow and Deny directives interact with each other.

Both host-based access restrictions and password-based authentication may be implemented simultaneously. In that case, the Satisfy directive is used to determine how the two sets of restrictions interact.

In general, access restriction directives apply to all access methods (GET, PUT, POST, etc). This is the desired behavior in most cases. However, it is possible to restrict some methods, while leaving other methods unrestricted, by enclosing the directives in a <Limit> section.

Allow Directive

The Allow directive affects which hosts can access an area of the server. Access can be controlled by hostname, IP address, IP address range, or by other characteristics of the client request captured in environment variables.

The first argument to this directive is always from. The subsequent arguments can take three different forms. If Allow from all is specified, then all hosts are allowed access, subject to the configuration of the Deny and Order directives as discussed below. To allow only particular hosts or groups of hosts to access the server, the host can be specified in any of the following formats:

A (partial) domain-name

Example:

Allow from apache.org
Allow from .net example.edu

Hosts whose names match, or end in, this string are allowed access. Only complete components are matched, so the above example will match foo.apache.org but it will not match fooapache.org. This configuration will cause Apache to perform a double reverse DNS lookup on the client IP address, regardless of the setting of the HostnameLookups directive. It will do a reverse DNS lookup on the IP address to find the associated hostname, and then do a forward lookup on the hostname to assure that it matches the original IP address. Only if the forward and reverse DNS are consistent and the hostname matches will access be allowed.

A full IP address

Example:

Allow from 10.1.2.3
Allow from 192.168.1.104 192.168.1.205

An IP address of a host allowed access

A partial IP address

Example:

Allow from 10.1
Allow from 10 172.20 192.168.2

The first 1 to 3 bytes of an IP address, for subnet restriction.

A network/netmask pair

Example:

Allow from 10.1.0.0/255.255.0.0

A network a.b.c.d, and a netmask w.x.y.z. For more fine-grained subnet restriction.

A network/nnn CIDR specification

Example:

Allow from 10.1.0.0/16

Similar to the previous case, except the netmask consists of nnn high-order 1 bits.

Note that the last three examples above match exactly the same set of hosts.

IPv6 addresses and IPv6 subnets can be specified as shown below:

Allow from 2001:db8::a00:20ff:fea7:ccea
Allow from 2001:db8::a00:20ff:fea7:ccea/10

The third format of the arguments to the Allow directive allows access to the server to be controlled based on the existence of an environment variable. When Allow from env=env-variable is specified, then the request is allowed access if the environment variable env-variable exists. The server provides the ability to set environment variables in a flexible way based on characteristics of the client request using the directives provided by mod_setenvif. Therefore, this directive can be used to allow access based on such factors as the clients User-Agent (browser type), Referer, or other HTTP request header fields.

Example:

SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
<Directory /docroot>
Order Deny,Allow
Deny from all
Allow from env=let_me_in
</Directory>

In this case, browsers with a user-agent string beginning with KnockKnock/2.0 will be allowed access, and all others will be denied.

Deny Directive

This directive allows access to the server to be restricted based on hostname, IP address, or environment variables. The arguments for the Deny directive are identical to the arguments for the Allow directive.

Order Directive

The Order directive, along with the Allow and Deny directives, controls a three-pass access control system. The first pass processes either all Allow or all Deny directives, as specified by the Order directive. The second pass parses the rest of the directives (Deny or Allow). The third pass applies to all requests which do not match either of the first two.

Note that all Allow and Deny directives are processed, unlike a typical firewall, where only the first match is used. The last match is effective (also unlike a typical firewall). Additionally, the order in which lines appear in the configuration files is not significant -- all Allow lines are processed as one group, all Deny lines are considered as another, and the default state is considered by itself.

Ordering is one of:

Allow,Deny
First, all Allow directives are evaluated; at least one must match, or the request is rejected. Next, all Deny directives are evaluated. If any matches, the request is rejected. Last, any requests which do not match an Allow or a Deny directive are denied by default.
Deny,Allow
First, all Deny directives are evaluated; if any match, the request is denied unless it also matches an Allow directive. Any requests which do not match any Allow or Deny directives are permitted.
Mutual-failure
This order has the same effect as Order Allow,Deny and is deprecated in its favor.

Keywords may only be separated by a comma; no whitespace is allowed between them.

Match Allow,Deny result Deny,Allow result
Match Allow only Request allowed Request allowed
Match Deny only Request denied Request denied
No match Default to second directive: Denied Default to second directive: Allowed
Match both Allow & Deny Final match controls: Denied Final match controls: Allowed

In the following example, all hosts in the apache.org domain are allowed access; all other hosts are denied access.

Order Deny,Allow
Deny from all
Allow from apache.org

In the next example, all hosts in the apache.org domain are allowed access, except for the hosts which are in the foo.apache.org subdomain, who are denied access. All hosts not in the apache.org domain are denied access because the default state is to Deny access to the server.

Order Allow,Deny
Allow from apache.org
Deny from foo.apache.org

On the other hand, if the Order in the last example is changed to Deny,Allow, all hosts will be allowed access. This happens because, regardless of the actual ordering of the directives in the configuration file, the Allow from apache.org will be evaluated last and will override the Deny from foo.apache.org. All hosts not in the apache.org domain will also be allowed access because the default state is Allow.

The presence of an Order directive can affect access to a part of the server even in the absence of accompanying Allow and Deny directives because of its effect on the default access state. For example,

<Directory /www>
Order Allow,Deny
</Directory>

will Deny all access to the /www directory because the default access state is set to Deny.

The Order directive controls the order of access directive processing only within each phase of the server's configuration processing. This implies, for example, that an Allow or Deny directive occurring in a <Location> section will always be evaluated after an Allow or Deny directive occurring in a <Directory> section or .htaccess file, regardless of the setting of the Order directive. For details on the merging of configuration sections, see the documentation on How Directory, Location and Files sections work.


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

How To Block Bots, Ban IP Addresses With .htaccess

Blocking bots with .htaccess

This example, and all of the following examples, can be placed at the bottom of your .htaccess file. If you don't already have a file called .htaccess in your site's root directory, you can create a new one.

   #get rid of the bad bot
   RewriteEngine on
   RewriteCond %{HTTP_USER_AGENT} ^BadBot
   RewriteRule ^(.*)$ http://go.away/

So, what does this code do? It's simple: the above lines tell your webserver to check for any bot whose user-agent string starts with "BadBot". When it sees a bot that matches, it redirects them to a non-existent site called "go.away".

Now, that's great to start with, but what if you want to block more than one bot?

   #get rid of bad bots
   RewriteEngine on
   RewriteCond %{HTTP_USER_AGENT} ^BadBot [OR]
   RewriteCond %{HTTP_USER_AGENT} ^EvilScraper [OR]
   RewriteCond %{HTTP_USER_AGENT} ^FakeUser
   RewriteRule ^(.*)$ http://go.away/

The code above shows the same thing as before, but this time I'm blocking 3 different bots. Note the "[OR]" option after the first two bot names: this lets the server know there's more in the list.

Blocking Bandwidth Leeches

Say there's a certain forum that's always hotlinking your images, and it's eating up all your bandwidth. You could replace the image with something really gross, but in some countries that might get you sued! The best way to deal with this problem is simply to block the site, like so:

RewriteEngine on
RewriteCond %{HTTP_REFERER} ^http://.*somebadforum\.com [NC]
RewriteRule .* - [F] 

This code will return a 403 Forbidden error to anyone trying to hotlink your images on somebadforum.com. The end result: users on that site will see a broken image, and your bandwidth is no longer being stolen.

Here's the code for blocking more than one site:

RewriteEngine on
RewriteCond %{HTTP_REFERER} ^http://.*somebadforum\.com [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://.*example\.com [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://.*lastexample\.com [NC]
RewriteRule .* - [F] 

If you want to block hotlinking completely, so that no one can hotlink your files, take a look at my article on using .htaccess to block hotlinkers.

Banning An IP Address

Sometimes you just don't want a certain person (or bot) accessing your website at all. One simple way to block them is to ban their IP address:

order allow,deny
deny from 192.168.44.201
deny from 224.39.163.12
deny from 172.16.7.92
allow from all

The example above shows how to block 3 different IP addresses. Sometimes you might want to block a whole range of IP addresses:

order allow,deny
deny from 192.168.
deny from 10.0.0.
allow from all

The above code will block any IP address starting with "192.168." or "10.0.0." from accessing your site.

Finally, here's the code to block any specific ISP from getting access:

order allow,deny
deny from some-evil-isp.com
deny from subdomain.another-evil-isp.com
allow from all

Final notes on using .htaccess

As you can see, .htaccess is a very powerful tool for controlling who can do what on your website. Because it's so powerful, it's also fairly easy for things to go wrong. If you have any mistakes or typos in your .htaccess file, the server will spit out an Error 500 page instead of showing your site, so be sure to back up your .htaccess file before making any changes.

If you'd like to learn more about writing .htaccess files, I recommend checking out the Definitive Guide to Mod_Rewrite. This book covers everything you need to know about Apache's .htaccess rewrite system.

PS: If your webhost doesn't support .htaccess, it's time to get a better one! :)

.Htaccess IP Banning – Block Bad Visitors

Deny or Allow Domain Access for a Specified IP Address Range

There are several effective ways to block a range of IP addresses via htaccess. This first method blocks an IP range specified by their CIDR (Classless Inter-Domain Routing) number. This method is useful for blocking mega-spammers such as RIPE, Optinet, and many others. If, for example, you find yourself adding line after line of Apache deny directives for addresses beginning with the same first few numbers, choose one of them and try a whois lookup. Listed within the whois results will be the CIDR value representing every IP address associated with that particular network. Thus, blocking via CIDR is an effective way to eloquently prevent all IP instances of the offender from accessing your site. Here is a generalized example for blocking by CIDR (edit values to suit your needs):

# block IP range by CIDR number
<Files *>
order allow,deny
allow from all
deny from 10.1.0.0/16
deny from 80.0.0/8
</Files>

Conversely, to allow an IP range by CIDR number:

# allow IP range by CIDR number
<Files *>
order deny,allow
deny from all
allow from 10.1.0.0/16
allow from 80.0.0/8
</Files>

Blocking IP Addresses With .htaccess

Blocking IP Addresses With .htaccess


What is .htaccess

.htaccess is a file that Apache reads that allows configuration changes on a per-directory basis. One of the handy little tricks one can do with this configuration file is block visitors from viewing a web site.

The Basics – Blocking 1 IP Address
Order allow,deny
Deny from 192.168.0.101
Allow from all

This will refuse all access (GET & POST) to the web site for the IP address 192.168.0.101

The Multiple IP Approach
Order allow,deny
Deny from 192.168.0.101
Deny from 192.168.0.102
Deny from 192.168.0.103
Deny from 192.168.0.104
Allow from all

Blocking IP Ranges
Order allow,deny
Deny from 192.168.0 ßnotice there is no 101, 102, 103 (this affects a lot of users)
Allow from all

IP's range from 0 – 255 (ex -192.168.0.0 – 192.168.0.255)
You may also block ranges by way of calculating CIDR (Classless Inter-Domain Routing – pronounced "cider") IP ranges (8, 16, 24bits)
Order allow,deny
Deny from 192.168.0/16
Allow from all

Get Mean

You can also block host names instead of numeric addresses.
Order allow,deny
Deny from cox.net
Allow from all

This will block anyone in the Cox.net network. But beware; banning large isp companies such as Cox.net or Comcast.com will block all their users. Do your research when it comes to blocking hostnames. Think about who may be affected.

There are many other ways of blocking IPs, but using .htaccess is one of the more common requests we receive.

apache - Blocking multiple ip ranges using mod access in htaccess - Stack Overflow


Q: Blocking multiple ip ranges using mod access in htaccess
I read the guide from apache site but I'm a bit confused, I'm trying to ban some ranges using this syntax:
order allow,deny

deny from 127.0.55.0/127.0.75.255
deny from 127.0.235.0/127.0.255.255
allow from all

But I think it's not working properly, probably the syntax is wrong or I'm using it in the wrong way, where should I write this text in htaccess? before the other lines or after? in the same htaccess file there're some mod rewrite script too (for anti-hotlinking).

A: I've come to this answer using apache documentation. You can give an address range using ip/netmask pair :
deny from 127.0.55.0/24

However, since range 55 - 75 are not power of two, I don't see how to make a range out of them. I'd add several rules.

order allow,deny
deny from 127.0.55.0/24 // Matches 55
deny from 127.0.56.0/21 // Matches 56 to 64
deny from 127.0.64.0/21 // Matches 64 to 71
deny from 127.0.72.0/22 // Matches 72 to 75

deny from 127.0.235.0/24 // Matches 235
deny from 127.0.236.0/22 // Matches 236 to 239
deny from 127.0.240.0/21 // Matches 240 to 255
allow from all

should work.

NB: Remove the comments after // before pasting into htaccess

.htaccess IP Block Apache Web Server forum at WebmasterWorld

Hi All,
I normally block IPs or ranges of IPs like this:
deny from (IP number)

But I would like to know how to block an entire range:
##.136.0.0 - ##.191.255.255
with ## being the same number. Sorry - not sure if I'm allowed to post the full IP.

Would I simply add the line:
deny from ##.136.0.0 - ##.191.255.255

or is there another way?

These people are quite nasty and have been breaking in and planting their links on a friend's site. We're securing up the site's script by upgrading but I'd like to ban their entire IP range since they keep trying with several from this block.

Also, one other newbie question - I read somewhere online that I can ban the host these people are coming from. So if for instance, their host is "t-dialin.net" could I add
deny from t-dialin.net
and have all who come from that host blocked? I understand the ramifications of this kind of block. I am just curious if what I read is true. At this point, I only intend to ban the IP block assigned to the hackers but I have found 2 completely different IP addresses associated with these hackers and they belong to the same host.

Thanks,
Hope


jdMorgan


WebmasterWorld Senior Member jdmorgan us a WebmasterWorld Top Contributor of All Time 10+ Year Member

Msg#: 5169 posted 1:43 am on Dec 22, 2005 (gmt 0)

You may use a partial IP address, a network CIDR specification, or a network/netmask specification to block ranges, depending on your needs and the actual range to be blocked.
See the examples at [httpd.apache.org...]

Jim


EarleyGirl


5+ Year Member

Msg#: 5169 posted 1:53 am on Dec 22, 2005 (gmt 0)

Thanks Jim.
I'm sorry but I've read the apache info and I guess I'm such a newbie (or a little on the simple side) that I still don't understand how to block a range. Is the follwing acceptable in .htaccess?
order allow,deny
deny from ##.136.0.0 - ##.191.255.255
allow from all
Where ## is the same number - as in 84.


jdMorgan


WebmasterWorld Senior Member jdmorgan us a WebmasterWorld Top Contributor of All Time 10+ Year Member

Msg#: 5169 posted 2:14 am on Dec 22, 2005 (gmt 0)

No,
Changing your example to unroutable IP addresses for the sake of clarity in this thread, let's say you want to deny from 192.168.0.0 through 192.168.0.255

The documentation states that you may use:

deny from 192.168.0
or
deny from 192.168.0.0/24
or
deny from 192.168.0.0/255.255.255.0

All of which do the same thing.

The first example is a partial IP address. It is interpreted using 'prefix matching.' That is, any IP address that *starts with* 192.168.0 will be denied.

The second example is a network/CIDR spec, where the 'base' address is given, followed by the number of bits that must match, in this case 24. (Each 'group' of digits in an IP address is the decimal representation of an eight-bit octet, where eight bits can be used represent any decimal number from 0 through 255 [two raised to the eighth power, minus one]. Since your deny range comprises three octects, you'd use 24 bits.)

The third example is a network/netmask spec, as used in the network setting on Windoze, for example. The first part is again the 'base' IP address, and the second part is a decimal representation of a 'mask' to be applied to both the incoming IP address and the given base address before they are compared. In this case, 255.255.255.0 means that the last group of digits in the IP addresses are to be ignored.

Jim


EarleyGirl


5+ Year Member

Msg#: 5169 posted 2:26 am on Dec 22, 2005 (gmt 0)

My apologies. I guess I'm much slower than I first thought. I understand how to ban IPs from this type of IP:
deny from 192.168.0
What I can't figure out is how to deny from a range such as 192.136.0.0 - 192.191.255.255

You probably just explained it all to me but for some reason, I can't see it.
Edited to add:
Looks like I'll have to add them all in one by one such as:
deny from 192.136
deny from 192.137
deny from 192.138
all the way to
deny from 192.191

Hope


jdMorgan


WebmasterWorld Senior Member jdmorgan us a WebmasterWorld Top Contributor of All Time 10+ Year Member

Msg#: 5169 posted 3:11 am on Dec 22, 2005 (gmt 0)

Yes, sorry, I can't teach you about decimal to binary radix conversion in this constrained forum format, and that's what's needed to cover complex ranges. I'd suggest a search for 'CIDR calculators' or 'Netmask calculators' unless you want to take a semester course on Boolean logic and radix conversion... :( But, since I've already done so myself...
In order to deny only the exact range you've specified, three 'pieces' are needed. This is because the range is not an exact power of two in size:

# Deny 192.136.0.0 through 192.143.255.255 (first 52,4288 addresses):
deny from 192.136.0.0/13

# Deny 192.144.0.0 through 192.159.255.255 (next 1,048,576 addresses):
deny from 192.144.0.0/12

# Deny 192.160.0.0 through 192.191.255.255
deny from 192.160.0.0/11 (last 2,097,152 addresses):

There's yet another way to do it using SetEnvIf and regular expressions, though it's just as complex in another way:

# Deny 192.136.0.0 through 192.191.255.255
SetEnvIf Remote_Addr ^192\.1(3[6-9]¦[4-8][0-9]¦9[01])\. getout
Deny from getout

If you use this latter method, remember that you are doing a string compare --a lexical compare-- and not a numeric compare. The module does not understand the code to mean 'a range of numbers'; it is only looking at characters and character ranges.

Replace all broken pipe "¦" characters above with solid pipe characters before use; Posting on this board modifies them.

And yes, the sophisticated spammers pick oddball non-aligned and non-contiguous IP ranges to make this job difficult.

Jim


jdMorgan


WebmasterWorld Senior Member jdmorgan us a WebmasterWorld Top Contributor of All Time 10+ Year Member

Msg#: 5169 posted 3:18 am on Dec 22, 2005 (gmt 0)

And to top it off, I forgot the part about blocking by hostname...
Yes, you can block by hostname, as shown in the documentation I cited above.

Jim


EarleyGirl


5+ Year Member

Msg#: 5169 posted 3:24 am on Dec 22, 2005 (gmt 0)

And yes, the sophisticated spammers pick oddball non-aligned and non-contiguous IP ranges to make this job difficult.


Tricky little devils, aren't they? I just had no idea how tricky! We are having quite a time with these hackers/spammers. It's gotten to be quite a time consuming project - much I'm not getting paid for since this is my friend's site.
I do so appreciate the help and now can see why it is so complicated. You've helped me greatly. Thank you, Jim!

Hope


geekdogfl

Msg#: 5169 posted 3:37 pm on Jan 30, 2010 (gmt 0)

I know this is an old post but I'm newly-joined as a supporter of WebmasterWorld and I really need help with this topic once and for all. I read the documentation at Apache and it's a bit beyond me. I need plain English!
I'm having a serious intruder problem. The intruder's IP always starts with the same two parts: ##.###. BUT the rest of the numbers vary widely.

So if I understand this, I want to block by range -- given what I DO know for certain so far about the intruder's apparently-changing IPs?

If so, how? Would this work:

##.###./24


I would hate to block innocent people coming from ##.###.

Thanks for ANY help!


jdMorgan


WebmasterWorld Senior Member jdmorgan us a WebmasterWorld Top Contributor of All Time 10+ Year Member

Msg#: 5169 posted 10:12 pm on Jan 30, 2010 (gmt 0)

You must include 4 octets, separated by periods as described in previous posts. Your post only shows two octets, and you didn't mention the size of the range to be blocked, so I don't quite know what to make of it.
Jim


geekdogfl

Msg#: 5169 posted 10:11 pm on Jan 31, 2010 (gmt 0)

Sorry, Jim! Thanks for trying to help me. I wish I knew how to better explain what I mean.
I want to block a range ##.###.333.444 through ##.###.456.789. Does that make sense? I don't think I'm supposed to pot real IPs here. I made those up. If they are real, please delete. I'm trying to show that the first two "octets" I am concerned with are always the SAME IDENTICAL NUMBERS (first one has two numerals, second has three), but the last two octets change every time and vary widely. The intruder must not have a static IP, right? I am thinking I will just have to ban ##.###. and not bother with the last two octets being narrowed or specified. That is OK, if that is what it takes to keep this jerk off the sites.

Thanks for trying! I appreciate it very much.


jdMorgan


WebmasterWorld Senior Member jdmorgan us a WebmasterWorld Top Contributor of All Time 10+ Year Member

Msg#: 5169 posted 3:38 am on Feb 1, 2010 (gmt 0)

You might want to look at the Jerk's 'total profile' -- What IP address range, what user-agent(s), what referrer(s) (if any) and what request headers he sends with each request. The additional request headers typically don't appear in standard logs, but you can access them and save them using a script if this is something you'd feel comfortable doing (also meaning that writing this script is beyond the purview of this forum).
I don't know what you typed for the ranges above since the first two octets are obscured as "x" characters, making it a bit hard to give a specific answer. But in order to block
192.168.0.0 through 192.168.255.255 --the entire valid range of the last two octets-- you could use

Deny from 192.168.0.0/16 -or-
Deny from 192.168.0.0/255.255.0.0 -or-
Deny from 192.168

All of these do exactly the same thing, and which you choose is largely a matter of "style" and consistency within your own code. Otherwise, there is no difference.

When posting IP addresses here, it is only necessary to obscure one octet. The trick is to obscure an octet that won't change the code being discussed...

Jim


Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended

Top articles

Sites

Top articles

Sites

Comprehensive guide to .htaccess- intro

Blocking (part of) a web site for certain IP numbers



Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: September, 12, 2017