Page not found – ShopingServer Wiki

Providing a high degree of security by types of Encryption

msrxp — Sun, 10 Feb 2019 18:58:14 +0000

Filetopia uses many encryption components which provide a high degree of security.
For the “Public Key” (PK) functionality, it uses an asymmetric cipher based on “Elliptic Curves” and for symmetric encryption it can use several different ciphers. The rule is very simple: for all Client/Server connections, the Client is the one to choose the cipher’s algorithm to use.

For the chat, it uses a complex protocol in which each user creates two encryption objects for every other user in the channel, encrypting with the user’s own cipher choice and using the other user’s choice to decrypt. Of course, to exchange the session keys, it uses Public Key techniques.

There is also a Hash component: SHA1 is used to protect the user’s password, so that not even the server knows it.

Symmetric ciphers

If you want to have an overview of basic concepts used in cryptography you can check this page.

Rijndael (AES)

Rijndael is the AES winner and the default cipher used in Filetopia, it is written by Joan Daemen and Vincent Rijmen. The cipher has a variable block and key length, and the authors have demonstrated how to extend the block length and key length by muliples of 32 bits.

The design of Rijndael influences by the SQUARE algorithm. The authors provide a Rijndael specification and a more theoretical paper on their design prinicples. The authors have vowed to never patent Rijndael

RC6

RC6 is Ronald Rivest’s AES submission. Like all AES ciphers, RC6 works on 128 bit blocks. It can accept variable length keys. It is very similar to RC5, incorporating the results of various studies on RC5 to improve the algorithm. The studies of RC5 that not all bits of data are using to determine the rotation amount (rotation is using extensively in RC5); RC6 uses multiplication to determine the rotation amount and uses all bits of input data to determine the rotation amount, strengthening the avalanche effect.

TwoFish

Twofish is Counterpane Systems’ AES submission. Designed by the Counterpane Team (Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall, and Niels Ferguson), Twofish has undergone extensive analysis by the Counterpane Team. There is a paper available from the Twofish web page and the source code is provided in optimized C and assembly.

Mars

MARS is IBM’s AES submission. There is a MARS web page, but it provides little more than a link to the MARS paper. MARS uses 128 bit blocks and supports variable key sizes (from 128 to 1248 bits). MARS is unique in that it combines virtually every design technique to cryptographers in one algorithm. It uses addition and subtractions, S-boxes, fixed and data dependent rotations, and multiplications.

Blowfish

Blowfish is a block cipher designed by Bruce Schneier, author of Applied Cryptography. It combines a Feistel network, key-dependent S-Boxes, and a non-invertible F function to create what is perhaps one of the most secure algorithms available. There are no known attacks against it. Schneier’s paper is available here.

Idea

IDEA, develop in Zurich, Switzerland by Xuejia Lai and James Massey, is generally regard to be the best and most secure block algorithm available to the public today. It utilizes a 128-bit key and is designed to be resistant to differential cryptanalysis. Some attacks have been made against reduced round IDEA.

Gost

GOST is a cryptographic algorithm from Russia that appears to be the Russian analog to DES both politically and technologically. Its designers took no chances, iterating the GOST algorithm for 32 rounds and using a 256 bit key. Although GOST’s conservative design inspires confidence, John Kelsey has discovered a key-relation attack on GOST, described in a post to sci.crypt on 10 February 1996.

There are also weak keys in GOST, but there are too few to be a problem when GOST is used with its standard set of S-boxes. You can read the official GOST algorithm description (translated from Russian) here. There is also a description of the GOST algorithm here.

Cast

CAST, designed by Carlisle Adams and Stafford Taveres, is shaping up to be a solid algorithm. Its design is very similar to Blowfish’s, with key-dependent S-Boxes, a non-invertible f function, and a Feistel network-like structure (called a substitution-permutation network).

David Wagner, John Kelsey, and Bruce Schneier have discovered a related-key attack on the 64-bit version of CAST that requires approximately 2¹⁷ chosen plaintexts, one related query, and 2⁴⁸ offline computations (described in this paper). The attack is infeasible at best.

CAST is patented by Entrust Technologies, which has generously released it for free use. The CAST cipher design process is described in this paper and the 128-bit version is described in this addendum. Carlisle Adams has submitted a version of CAST (CAST-256) as an AES candidate.

Misty1

Misty is a cryptographic algorithm develope by Mitsubishi Electric after they broke DES in 1994. It is design to withstand linear and differential cryptanalysis,

but has not yet been cryptanalys. As it has not undergone intensive peer review, the usual caution is recommend. It is being consider for inclusion into the SET 2.0 standard. Visit the MISTY web page or read the author’s paper on MISTY.

Hash Algorithm

SHA1

SHA1 was developed by the NSA for NIST as part of the Secure Hash Standard (SHS). it is similar in design to MD4. The original publish algorithm, known as SHA, was modify by NSA to protect against an unspecific attack; the update algorithm is name it.

It produces a 160-bit digest — large enough to protect against “birthday” attacks,

where two different messages are selecting to produce the same signature, for the next decade. The official FIPS description of it can be found here.

Source Code

The source code of all the symmetric ciphers and hash component can be found at the Scramdisk Delphi site. The author of this implementation is David Barton, to whom I wish to express my gratitude.

Site Security in HTML Creating Commercial Websites

msrxp — Sat, 09 Feb 2019 05:06:32 +0000

Site Security in Creating Commercial Websites, Here’s a good way to look at total site security: It’s a myth. We always arrange our clients’ sites with this point in mind:

Anything you put on the Internet is not truly secure. Yes, there are things you can do to protect your information, or to let only certain viewers on to your site, but no matter what you do, there are ways to break in.

In fact, we have often unintentionally ended up at “secure” sites by following hypertext links or even just by hitting the wrong buttons—and we in no way consider ourselves hackers.

Actually, the reason most security protocols are enacted are simply because many problems stem from inexperienced users inadvertently messing with systems. Which brings us to another good point: everyone’s not out to get you—really. There are probably very few hackers who will ever be interested in anything on your site.

This is not to say that you should ignore security, or write off any security efforts as futile. Skilled car thieves can easily disarm an alarm system, but likely they will move on to a car without an alarm. Providing some sort of site security will accomplish this same effect (though few car thieves break into a car just for the sense of accomplishment).

Note
This chapter does not deal with encryption security. This is covered in the preceding chapter, “Taking Payment Online.”

Public Versus Private Sites

In general, a public site can be accessed by any individual who knows the address. A private site, on the other hand, usually requires a Password Authentication Protocol (PAP). Most servers and browsers have the capability to handle password authentication, and it is generally a case of either setting this up on the server yourself (if you are using your own server), or having your administrator set this up for you (if you are using a virtual host).

In most cases, the server will keep a database of the users and their passwords, and will check the input against the recorded file. Upon requesting information from a secure address (which can be the entire server, or just a directory), the viewer is confronted with a login/password interface. This can either be an input box generated as a function of the browser, or an HTML page that links out to a CGI file (see Figures 17.1 and 17.2).

Uses for Private Sites

Some uses for a private Web site are

provide a place for sensitive material (financial, proprietary, or medical records).
use in conjunction with a payment system on a “charge for access” site.
provide a premium site (a site that perhaps is only available to clients, past customers, sales staff, and so on).
build a sense of exclusivity.
track sales and marketing. By asking viewers to fill out information before receiving a password into the site (such as the popular HotWired site,), you can track who is visiting and collect sales information at your virtual front-door. (Be really careful of this—if not given enough incentive, viewers may never enter at all.)

Setting Up a Private Site

How you set up your PAP will depend on your individual server. This book does not go into the actual mechanics of setting up private sites, as most server documentation will give you detailed instructions. If you are deciding whether or not to make a site private, there are three major questions you need to ask yourself:

What do you want to accomplish?
Who do you want to keep out?
What are you keeping secret?

What Is the Point?

Previously, we listed some reasons for site security. Whatever reasons you have, consider the risks and benefits of putting any private information online. Putting private medical information online, for instance, can put you in a position of high liability. Putting your secret R&D files online may compromise your business future. Your question should be “Why?” If you can avoid compromising your security by keeping files offline, do so!

Who Wants to Know?

If you are storing information that could be profitable to your competition, you have something to protect. If, however, you are designing a secure site just to track leads, or to restrict access to dirty pictures, or for some other noncrucial security issue, you can afford to be a bit more blasé about your security.

A good exercise (to feed your paranoia) is to sit down and think about the worst things that could happen if someone broke into your server. This will be your best tool in assessing your risks and benefits, and in deciding how to approach your security issues.

What Ya Hiding?

Obviously, this goes hand-in-hand with the other issues, but it’s important to look at the raw information. To go back to the example of medical records, you could ask yourself if there might be a way to encrypt the records themselves, or to remove the most damaging information. In many cases, you can at least minimize your worst case scenario by simply reducing the quantity or quality of information available.

Dangers

There are at least four ways someone can break into your system. The first is to simply set up a program that will bang away at the front door, trying random usernames and/or passwords until a match is made. People who always use the same username and password are a great help to hackers, because once a username/password combination is found on one site, it will usually go to the top of the list to be tried at another site.

Note

While not common, some PAP applications have a dummy login. This was usually set up so that either the programmer or the end user would have quick access. By all means, remove any username/password data that you have not entered yourself, prior to going online. A very common dummy login is to use “guest” as both the username and password.

The second way to break in to a site is to access the server through a route other than HTTP (Telnet, Gopher, Finger, FTP, and so on). This is an operating system problem and must be dealt with as it pertains to each OS. This can usually be fixed by setting appropriate file permissions on the server system

(as well as by just eliminating these other services, if unused).

The third way to gain access to a server is by getting shell access. This should not be possible on a Web server, but certain bugs can allow this to happen. Luckily,

most companies who offer Web server software make protection from this a priority, and it’s extremely rare for someone to break in this way.

The most likely (and dangerous) way for someone to break into a system is through CGI. Remember, the “G” stands for gateway. Sloppy CGI protocols can allow someone to walk right into your system. This is because of the power that CGI allows (it’s a trade-off). There has also been concern expressed over scripting languages like Java. Always be aware that when you are running a script,

you are providing a way for someone to get into your system. While the risk is very small, it does exist.

Intellectual Property

What do you do if a viewer copies something from your Web page to use as his or her own? Is there a legal remedy against this thief? Well, unfortunately that point is quite unclear. If the person did not use your work under a “fair use” provision,

if the work copied was protected under copyright law, and if you find out about the thievery, then you may take action. Whether you can be successful in the litigation is where things become unclear. There have actually been cases where entire copyrighted books have been posted on the newsgroups,

yet no action could be taken since the files were posted anonymously.

This subject is being heatedly debated, and there are many issues involved. Hopefully, we soon will have foolproof protection measures against this (but don’t hold your breath). In the meantime, there are steps you can take to protect yourself.

Some we have used are

Include copyright notices on each Web document.
Make all your graphics as site-specific as possible (for example, incorporate your logo or something specific to your company into all graphics). They may steal your graphic, but they’ll be advertising your company in the meantime. (Go ahead, make our day, punk.)
Put sensitive information beneath a password-protected site, or don’t post it at all.
For information people may steal and claim as their own, you may want to use something like MD5 (freeware including documentation available at ftp://ftp.cert.org/pub/tools/md5/). MD5 shows that you had a certain file at a certain date. By using an MD5 hash code, and then publishing that code (in a newspaper, for example), you will have a record of your ownership. These hash codes cannot be inverted—meaning you can’t start with a hash code and work backwards to create the text to produce that code. Furthermore, changing even one letter in a huge document will completely change the code.

Summary

In this chapter, we have briefly discussed site security and Password authentication protocol. A few key things to remember are

No site is ever completely secure, unless it’s offline.
When providing sensitive information, you must weigh the risks against the benefits.
You can take steps to help protect your intellectual property.

Server Security Issues

msrxp — Mon, 28 Jan 2019 20:06:50 +0000

writing this section scares the britches off us, so we want to start with a warning: There are many security measures you can

(and should) take when setting up your own server.

However, the only way to make your server truly secure is to never connect it to the Internet in the first place. Of course, if you want to reach the public,

this is not an option. We will also put ourselves on the line here by saying: No matter what precautions you take,

there is always the possibility that a hacker will find a way into your system.

Keep this in the forefront of your mind when connecting your server to any of your internal systems. Though it is very handy to make certain up-to-date information available from your mainframe,

it can leave you wide open to security breaches. If you are planning this route, and have sensitive information you wish to protect,

we suggest you enlist the aid of a top-notch network security specialist.

there is some information you should know now,

while setting up your server, which we discuss here. Keep in mind that in dealing with site security,

you are not only trying to guard your system from hackers,

but also from innocent users accidentally messing with your system.

Firewalls

A firewall is a damage prevention and security system usually used by companies connecting to the Internet and Wide Area Networks (WANs). A firewall consists of code that aliases, blocks, or hides the firewalled computer from being identified by any other computer on the network. Well-constructed firewalls discourage hackers and help to prevent industrial espionage and sabotage. Firewalls are also used to prevent novice users from accessing commands and services that could jeopardize the integrity of the system.

There are basically three distinct firewall strategies: embedded systems, router-based packet filtering, and proxy servers.

Embedded Systems

This is a real-time firewall that supplies the security of a proxy server while at the same time delivering the added bonus of high-performance packet filtering. This means a real-time firewall system can provide the performance to support up to 100 times more users than a proxy server. In addition, it has no operating system or disk for hackers to mess with, requires no maintenance, and can be very simple to install. The down side is that these systems can be very expensive and serve only this very specific function.

Router-Based Packet Filtering

Most commercial routers (such as the Cisco we mentioned earlier) have packet-filtering capabilities. Based on rules defined by the administrator, packet filtering enables the router to permit and deny traffic. After a packet is passed through the router, the packet filter forgets the information, as well as the connection associated with it. Think of them as traffic cops with Alzheimer’s. These systems are usually the least expensive; they are also high-performance and transparent. Some people do, however, say that they can be very complex and difficult to work with.

Proxy Servers

A proxy server is a single point of contact for Internet access for the client. The proxy server generally resides on a specific port, waiting for connections from clients on the network. When a client sends a message to the proxy server indicating where he or she wishes to connect, the proxy proceeds by making the connection to the specified destination. Since the proxy uses the proxy host’s TCP/IP, it is aware of every connection in process and will drop packets that don’t meet its high standards.

You see, a proxy spends its life doing the very basic job of reading from one side and writing to the other. Think of it as a voyeur with an attitude. A proxy server is also multifunctional, since it runs on a general-purpose operating system, so it can provide many additional services to your internal network. The main disadvantages of these systems are that they’re difficult to set up, and that the speed of the system suffers under heavy usage.

Separating Your Systems

The simplest way to deal with these security issues is to use separate servers for your internal and external communications, and to never connect the two. You will lose the advantage of interconnecting your systems, but this challenge can often be overcome by manually updating the external server on a regular basis. Consider doing this if security is a major concern.

Quick and Dirty Guide: Turn-key Server Packages

Knowing the confusion many face in setting up servers, some astute companies offer “complete” server packages. One such product is WebCube (http://www.pacnet.com/pacnet/wcube/home.html). WebCube (see Figure 6.8) includes most of what you need for your own server (besides the actual connections).

There are also companies that offer turn-key server packages and promise total setup of your server. If you are looking to set up a server under a time constraint, and your budget is not a major concern, one of these solutions may be your answer. Some of these are listed at http://www.yahoo.com/Business_and_Economy/Companies/Computers/Networking/Consulting/.

Summary

In this chapter we have discussed various server issues and how you can choose to develop your own server or purchase a turn-key server package.

We have also covered some of the different software, hardware, and connection choices you will need to make,

as well as the security issues involved in running your very own server.

Now it’s time to move on to Part II of this book,

“Designing a Site that Succeeds.” Roll up your shirt sleeves, and let’s get started!

Ubuntu Linux: Turn On Exec-Shield Buffer Overflow Protection

msrxp — Sat, 06 Jan 2018 10:25:09 +0000

am trying to set exec-shield protection on Linux as described here but getting the following error on Ubuntu Linux server version 12.04 LTS:

sysctl -w kernel.exec-shield=1

error: “kernel.exec-shield” is an unknown key

How do I fix this problem and make sure exec-shield buffer overflow protection security feature turned on Ubuntu Linux?

Linux kernel (or patch to kernel) provides ExecShield feature to protect against buffer overflows such as:

Random placement of the stack

Random placement of memory regions

Prevention of execution in memory that should only hold data

Handling of text buffers with care and more.

Ubuntu kernel has No Execute (NX) or Execute Disable (XD) support. This does exactly the same thing to prevent code execution on a per memory page basis. If you are using Intel processors you should see the following message when system boots:

dmesg | grep –color [NX|DX]*protection

Sample outputs:

Fig.01: Intel CPU NX protection for buffer overflow enabled on Ubuntu kernel

This is the equivalent of the CentOS or SL or RHEL (Red Hat) Exec Shield kernel security feature. If you do not see the message, reboot the server and set XD/NX protection using BIOS setup.

Make sure kernel.randomize_va_space enabled

Type the following command:

sysctl -w kernel.randomize_va_space=1

OR, edit the file /etc/sysctl.conf and append/modify as follows:

kernel.randomize_va_space = 1

The randomize_va_space can have any one of the following values:

0 – Do not randomize stack and vdso page.

1 – Turn on protection and randomize stack, vdso page and mmap.

2 – Turn on protection and randomize stack, vdso page and mmap + randomize brk base address.

I highly recommend that you read our faq “Linux Kernel /etc/sysctl.conf Security Hardening Via Sysctl” for more information.

Nginx: Allow All But Block Certain POST Request URLS For Selected Spammer IP Address/CIDR

omid — Sat, 06 Jan 2018 09:02:02 +0000

am a small business and ecom site owner. I also run a WordPress based blog to connect with my customers. However, I get too much spam from certain IPs and net-blocks. How do I block access to certain url(s) such as example.com/blog/wp-comments-post.php for selected IP address and CIDRs? How do I allow everyone including IP address 1.2.3.4 to access my blog but block IP address 1.2.3.4 accessing only example.com/blog/wp-comments-post.php? How do I block POST requests for selected IPs/CIDR on nginx?

Nginx comes with a simple module called ngx_http_access_module to allow or deny access to IP address. You can also create a config file and block certain urls using the following method.

Step #1: Create spammers.conf file

Create a file called /etc/nginx/spammers.conf, enter:

# vi /etc/nginx/spammers.conf

You need to use the ngx_http_geo_module. This modile creates variables with values depending on the client IP address or CIDR. The syntax is:

geo $var_name {

default value1;

ip value2;

cidr value2;

}

In this example, block IPs/CIDRs – 101.0.71.27, 101.0.79.181, 101.0.79.27, 100.42.192.0/20, 101.192.0.0/14, and 148.248.0.0/16:

# spammers.conf #

geo $spammers_ip_cidrs {

## allow all ##

default no;

## block these bad ips/cidrs/spammers ##

101.0.71.27 yes;

101.0.79.181 yes;

101.0.79.27 yes;

100.42.192.0/20 yes;

101.192.0.0/14 yes;

148.248.0.0/16 yes;

}

Step #2: Update nginx.conf

Edit nginx.conf, enter:

# vi /etc/nginx/nginx.conf

Add the following in http section:

include /etc/nginx/spammers.conf;

Find your server section and add the following to match your POST request url:

location ~* /blog/wp-comments-post\.php$ {

if ( $spammers_ip_cidrs = yes ) {

## show default or custom forbidden page. To create black-hole use 444 code

return 403;

}

Here is a sample config directive for reverse proxy server:

server {

listen 75.126.153.206:80;

server_name www.cyberciti.biz;

access_log /var/log/nginx/access.log main;

error_log /var/log/nginx/error.log;

root /nfs/ha/root/nginx;

index index.html;

custom error pages put them at /nfs/ha/root/nginx location ##

error_page 404 /error-page-404.html;

location /error-page-404.html {

internal;

}

error_page 403 /error-page-403.html;

location = /error-page-403.html {

internal;

}

location section ##

location / {

proxy_pass http://backendapache;

proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;

proxy_set_header Host www.cyberciti.biz;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

location ~* /blog/wp-comments-post\.php$ {

if ( $spammers_ip_cidrs = yes ) {

return 403;

}

## add rest of config for matching url here ##

}

Save and close the file. Restart / reload nginx server, enter:

# service nginx reload

A visitor with an IP address 75.126.153.206 can browser your entire blog but will not able to post any comments. He/she (most likely a bot) will get an error code forbidden 403. A sample 403 error page:

Fig. 01: Custom nginx 403 page for www.cyberciti.biz

See how to create a custom 403/404 page using nginx for more information.

How do I find out spammers IP address?

Use the grep command as follows:

grep /blog/wp-comments-post.php access_1.log

Find all url /blog/wp-comments-post.php accessed on 30/Nov/2013 ##

last sort is bad ##

grep 30/Nov/2013 | grep /blog/wp-comments-post.php /path/to/archives/access_1.log | awk { print $1} | sort | uniq -c | sort -nr > spam.txt

Sample outputs:

$ cat spam.txt

22304 221.234.211.192

22133 221.235.67.111

11174 142.4.113.57

11110 192.184.37.126

4235 37.0.122.237

…

No sane person will try to submit comment 22304 times. So you can block all those IPs. You can automate the entire procedure by writing a shell/python/perl script. The writing of such script is left as an exercise to the readers.

Increase NFS Client Mount Point Security For a Web-Server noexec, nosuid, nodev Options

omid — Sat, 06 Jan 2018 08:32:55 +0000

am using NFS server version 4.x on a CentOS/RHEL based system. I’m mounting my shared /var/www/ directory on five Apache based nodes using the following syntax:

mount -t nfs4 -o rw,intr,hard,proto=tcp rocknas02:/httproot/www /var/www/

I noticed that due to bug in my app user can sometime upload executable or other device files to get out of chrooted Apache server. How can I prevent such security issues on a CentOS or RHEL based NFS client and sever setup?

First, you need to fix your application. Next, you can pass the following three options to mount command to increase overall security on Apache/Nginx/Lighttpd nfs based client:

noexec – Prevents execution of binaries on mounted file systems. This prevents remote users from executing unwanted binaries on your system.

nosuid – Disables set-user-identifier or set-group-identifier bits. This prevents remote users from gaining higher privileges by running a setuid program.

nodev – Prevents character and block special devices from being defined, or if they exist, from being used as character and block special devices. This prevents remote users from getting out of chrooted server jails.

Modify your mount command as follows:

# mount -t nfs4 -o rw,intr,hard,proto=tcp,nodev,noexec,nosuid rocknas02:/httproot/www /var/www/

OR attempt to remount an already-mounted nfsv4.0 filesystem:

# mount -t nfs4 -o remount,rw,intr,hard,proto=tcp,nodev,noexec,nosuid rocknas02:/httproot/www /var/www/

Test it

To verify new settings, enter:

# mount

# mount | grep rocknas02

Sample outputs:

rocknas02:/httproot/www on /var/www type nfs4 (rw,noexec,nosuid,nodev,sync,intr,hard,proto=tcp,addr=192.168.1.10,clientaddr=192.168.1.100)

Copy /bin/ls to rocknas02:/httproot/www i.e. type the following on your nfsv4.0 server called rocknas02

# cp /bin/ls /httproot/www

On client, type:

cd /var/www

run /bin/ls

ls -l

# Run uploaded ls

./ls

Sample outputs:

Fig. 01: Running ls command on nfs client

Updating /etc/fstab is left as an exercise for the reader.

Mount the filesystem read-only

If possible mount the filesystem in read-only mode. Modify your mount command as follows:

# mount -t nfs4 -o ro,intr,hard,proto=tcp,nodev,noexec,nosuid rocknas02:/httproot/www /var/www/

OR attempt to remount an already-mounted nfsv4.0 filesystem:

# mount -t nfs4 -o remount,ro,intr,hard,proto=tcp,nodev,noexec,nosuid rocknas02:/httproot/www /var/www/

Recommend file/directory permission for Apache

I suggest the following schema:

Run Apache as apache user and group

You must run httpd as root initially and it will switch to apache user and group:

# egrep -i ^(User|Group) /etc/httpd/conf/httpd.conf

Sample outputs:

User apache

Group apache

NFS server file/directory permission for /var/www/

Create a user called www-files using useradd command:

# useradd -d /var/www -M -s /sbin/nologin www-files

Make sure you lock www-files account using passwd command:

# passwd -l www-files

Change file owner and group to www-files for /var/www directory use the following passwd command:

# chown -R www-files:www-files /var/www/

Finally changes the file mode bits of each given file and directory according to mode:

By default all files & dirs permissions are set to read-only ###

chmod -R 0444 /var/www

Allow, apache/nginx/lighttpd to serve files from directory by settings others to x bit ###

find /var/www -type d -print0 | xargs -0 -I {} chmod 0445 {}

Optional certain directory may need additional permissions such as /var/www/uploads ###

#chmod 0777 -R /var/www/uploads

Use ls -l command to verify file permissions:

# cd /var/www

# ls -l

Sample outputs:

total 32

-r–r–r–. 1 www-files www-files 606 Dec 21 2011 best_resources.php

-r–r–r–. 1 www-files www-files 1068 Sep 4 2011 cdn_info_linux_unix_setup.php

dr–r–r-x. 2 www-files www-files 4096 Aug 5 2012 data

….

…

-r–r–r–. 1 www-files www-files 1550 Jun 22 2012 service-per-vm-guide.php

Linux: Log Suspicious Martian Packets / Un-routable Source Addresses

omid — Sat, 06 Jan 2018 08:31:07 +0000

run a web-server and I would like to log packets with un-routable source addresses on Linux operating system. How can I log spoofed packets on Debian / Ubuntu / CentOS / RHEL / Linux based server? How can I log a Martian packet (packet from Mars) on Linux operating systems?

A Martian packet is nothing but an IP packet which specifies a source or destination address that is reserved for special-use by Internet Assigned Numbers Authority (IANA). Here are examples of such address blocks:

10.0.0.0/8

127.0.0.0/8

224.0.0.0/4

240.0.0.0/4

::/128

::/96

::1/128

How can I log Martian packets on Linux?

You need to use sysctl command command to view or set Linux kernel variables that can logs packets with un-routable source addresses to the kernel log file such as /var/log/messages.

See current settings

Type the following command:

# sysctl -a| grep martians

Sample outputs:

Fig. 01: Find out if suspicious packets are logged or not on Linux

Value 0 indicates that the suspicious martian packets are not logged on the system.

How do I log suspicious martian packets on Linux?

You need to set the following variables to 1 in /etc/sysctl.conf file:

net.ipv4.conf.all.log_martians

net.ipv4.conf.default.log_martians

Edit file /etc/sysctl.conf, enter:

# vi /etc/sysctl.conf

Append/edit as follows:

net.ipv4.conf.all.log_martians=1

net.ipv4.conf.default.log_martians=1

Save and close the file. To load changes, type:

# sysctl -p

How can I modify active kernel parameters on command line?

Alternatively, you can toggle active kernel parameters using the following bash for loop syntax:

Grab all Linux kernel vars in $x ##

x=$(sysctl -a| grep martians | awk { print $1} )

Just display it on screen ##

echo $x

Alright, toggle all vars to 1 or 0 as per your requirements ##

for i in $x

/sbin/sysctl -w ${i}=1

done

Verify settings ##

sysctl -a| grep martians

Sample outputs:

Fig.02: Bash for loop to log suspicious packets

How can I see logged suspicious martian packets logs on Linux?

Use the grep command as follows:

cd /var/log

grep -i –color martian messages*

Sample outputs:

messages-20120101:Dec 31 09:25:45 nixcraft-router kernel: martian source 74.xx.47.yy from 10.13.106.25, on dev eth1

messages-20120101:Dec 31 09:25:53 nixcraft-router kernel: martian source 74.xx.47.yy from 10.13.106.25, on dev eth1

messages-20120101:Dec 31 09:26:10 nixcraft-router kernel: martian source 74.xx.47.yy from 10.13.106.25, on dev eth1

messages-20120101:Dec 31 14:04:12 nixcraft-router kernel: martian source 74.xx.47.yy from 10.1.97.141, on dev eth1

messages-20120101:Dec 31 14:04:14 nixcraft-router kernel: martian source 74.xx.47.yy from 10.1.97.141, on dev eth1

messages-20120101:Dec 31 14:04:18 nixcraft-router kernel: martian source 74.xx.47.yy from 10.1.97.141, on dev eth1

messages-20120101:Dec 31 14:04:22 nixcraft-router kernel: martian source 74.xx.47.yy from 10.1.97.141, on dev eth1

messages-20120101:Dec 31 14:04:26 nixcraft-router kernel: martian source 74.xx.47.yy from 10.1.97.141, on dev eth1

messages-20120101:Dec 31 14:04:34 nixcraft-router kernel: martian source 74.xx.47.yy from 10.1.97.141, on dev eth1

messages-20120101:Dec 31 14:04:50 nixcraft-router kernel: martian source 74.xx.47.yy from 10.1.97.141, on dev eth1

messages-20120101:Jan 1 00:01:59 nixcraft-router kernel: martian source 74.xx.47.yy from 10.13.105.141, on dev eth1

messages-20120101:Jan 1 00:02:00 nixcraft-router kernel: martian source 74.xx.47.yy from 10.13.105.141, on dev eth1

messages-20120101:Jan 1 00:02:02 nixcraft-router kernel: martian source 74.xx.47.yy from 10.13.105.141, on dev eth1

messages-20120101:Jan 1 00:02:06 nixcraft-router kernel: martian source 74.xx.47.yy from 10.13.105.141, on dev eth1

messages-20120101:Jan 1 00:02:10 nixcraft-router kernel: martian source 74.xx.47.yy from 10.13.105.141, on dev eth1

messages-20120101:Jan 1 00:02:14 nixcraft-router kernel: martian source 74.xx.47.yy from 10.13.105.141, on dev eth1

messages-20120101:Jan 1 00:02:22 nixcraft-router kernel: martian source 74.xx.47.yy from 10.13.105.141, on dev eth1

messages-20120101:Jan 1 00:02:38 nixcraft-router kernel: martian source 74.xx.47.yy from 10.13.105.141, on dev eth1

How do I block martian packets using firewall?

See how to use iptables to block spoofing and bad address attack that tries to fool the server and try to claim that packets had come from local address/network.

Log and drop packets with suspicious source addresses

eth1 is wan port on server ##

/sbin/iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j LOG –log-prefix IP DROP SPOOF A:

/sbin/iptables -A INPUT -i eth1 -s 172.16.0.0/12 -j LOG –log-prefix IP DROP SPOOF B:

/sbin/iptables -A INPUT -i eth1 -s 192.168.0.0/16 -j LOG –log-prefix IP DROP SPOOF C:

/sbin/iptables -A INPUT -i eth1 -s 224.0.0.0/4 -j LOG –log-prefix IP DROP MULTICAST D:

/sbin/iptables -A INPUT -i eth1 -s 240.0.0.0/5 -j LOG –log-prefix IP DROP SPOOF E:

/sbin/iptables -A INPUT -i eth1 -d 127.0.0.0/8 -j LOG –log-prefix IP DROP LOOPBACK:

/sbin/iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP

/sbin/iptables -A INPUT -i eth1 -s 172.16.0.0/12 -j DROP

/sbin/iptables -A INPUT -i eth1 -s 192.168.0.0/16 -j DROP

/sbin/iptables -A INPUT -i eth1 -s 224.0.0.0/4 -j DROP

/sbin/iptables -A INPUT -i eth1 -s 240.0.0.0/5 -j DROP

/sbin/iptables -A INPUT -i eth1 -d 127.0.0.0/8 -j DROP

/sbin/iptables-save > /root/my-iptables.rules

Linux: Hide Processes From Other Users

msrxp — Fri, 05 Jan 2018 16:22:20 +0000

run a multi-user system. Most users access resources using ssh client. How can I stop leaking process information to all users on Linux operating systems? How do I prevent users from seeing processes that do not belong to them on a Debian/Ubuntu/RHEL/CentOS Linux server?

If you are using Linux kernel version 3.2+ (or RHEL/CentOS v6.5+ above) you can hide process from other users. Only root can see all process and user only see their own process. All you have to do is remount the /proc filesystem with the Linux kernel hardening hidepid option.

Say hello to hidepid option

This option defines how much info about processes we want to be available for non-owners. The values are as follows:

hidepid=0 – The old behavior – anybody may read all world-readable /proc/PID/* files (default).

hidepid=1 – It means users may not access any /proc// directories, but their own. Sensitive files like cmdline, sched*, status are now protected against other users.

hidepid=2 It means hidepid=1 plus all /proc/PID/ will be invisible to other users. It compicates intruder’s task of gathering info about running processes, whether some daemon runs with elevated privileges, whether another user runs some sensitive program, whether other users run any program at all, etc.

Linux kernel protection: Hiding processes from other users

Type the following mount command:

# mount -o remount,rw,hidepid=2 /proc

Edit /etc/fstab, enter:

# vi /etc/fstab

Update/append/modify proc entry as follows so that protection get enabled automatically at server boot-time:

proc /proc proc defaults,hidepid=2 0 0

Save and close the file.

Linux demo: Prevent users from seeing processes that do not belong to them

In this example, I’m login as vivek@cbz-test:

$ ssh vivek@cbz-test

$ ps -ef

$ sudo -s

# mount -o remount,rw,hidepid=2 /proc

$ ps -ef

$ top

$ htop

Sample outputs:

Animated gif 01: hidepid in action

Tip: Dealing with apps that breaks when you implement this technique

You need to use gid=VALUE_HERE option:

gid=XXX defines a group that will be able to gather all processes’ info (as in hidepid=0 mode). This group should be used instead of putting nonroot user in sudoers file or something. However, untrusted users (like daemons, etc.) which are not supposed to monitor the tasks in the whole system should not be added to the group.

So add the user called monapp to group (say admin) that want to see process information and mount /proc as follows in /etc/fstab:

proc /proc proc defaults,hidepid=2,gid=admin 0 0

References

procfs: add hidepid= and gid= mount options

How To PFSense Configure Network Interface As A Bridge / Network Switch

omid — Fri, 05 Jan 2018 15:59:41 +0000

have Soekris single board communication embedded computers which is optimized for low power and network usage. The server has four Ethernet ports. I’ve installed PFSense firewall on it and configure WAN + LAN ports. How do I setup IPv4 software bridge using PFSense so that the rest of ports act as a network switch?

pfSense is an open source firewall/router computer software distribution based on FreeBSD. FreeBSD supports the bridge device. A bridge interface device can be created using pfSense. A bridge interface creates a logical link between two or more Ethernet interfaces or encapsulation interfaces. This link between the interfaces selectively forwards frames from each interface on the bridge to every other interface on the bridge. A bridge can serve several services, including isolation of traffic between sets of machines so that traffic local to one set of machines is not available on the wire of another set of machines, and it can act as a transparent filter for ip datagrams. This will work at layer 2 broadcast/collision domain.

Our sample setup

The setup is as follows:

+————+

| NAS | 192.168.1.254 (lan)

| Server 01 +——>——–+ +———-+

+————+ | | |

192.168.1.10 lan -+ +- wan (rl0) ISP/Internet

+———+ | | Public IP: 202.54.1.1

| Desktop | | PFSense |

+———+——->———-+ | Host |

192.168.1.11 opt1-+ |

+————+ | |

| HP | | |

| Printer 01 +————->opt2-+ |

+————+ +———-+

192.168.1.12

Bridge0 includes following (note only lan interface needs an IP address)

lan = vr0 = IP: 192.168.1.254

opt1 = vr1 = IP: none

opt2 = vr2 = IP: none

I’m going to assume that you’ve already assigned and configured wan and lan interfaces.

Step #1: Assign opt1 and opt2 interfaces

First, assign and enable all the additional interfaces such as opt1, opt2 and so on by visiting Interfaces > (assign) option:

Fig.01: Assign network ports

Click on each interface name such as opt1, opt2, opt3 and select “Enable Interface“. Make sure IPv4/IPv6 Configuration Type set to “None“. Finally click on the “Save” button:

Fig.02: Setting up opt2 interface

Warning: Only one interface on a bridge should have an IP address. In this example, I’ve assigned IP address to lan interface (192.168.1.254). Do not add multiple IP addresses in the same subnet on different bridge member interfaces. Other interfaces on the bridge should remain with an IP type of None.

Step #2: Create a bridge interface

Visit Interfaces > (assign > Bridges option. Click on + symbol to add bridge0 and select member interfaces such as LAN, OPT1, OPT2 and so on. In this example, I’m only selecting LAN and OPT3 as member interfaces for bridge0:

Fig.03: Configure bridging of interfaces (lan and opt3)

My final bridge0 interface will look as follows:

Fig.04: Interfaces: Bridge

Step #3: Adding a firewall rule

You need to add a firewall rule to allow traffic between each interface of the bridge. Click on Firewall > Rules > Select Lan interface. You need to select opt1, opt3 and so on. I suggest that you add a simple rule like “Default allow interface to any rule” i.e. set Protocol: any, Source: any, Destination: any > and click on the “Save” button:

Fig.05: Add a firewall rule

Feel free to adjust firewall rules as per your needs and setup.

Step #4: Test it

Open the Terminal app and try to ping between nas server, printer and desktop using ping command:

ping 192.168.1.10

ping 192.168.1.254

This entry is 3 of 7 in the Linux and Unix Network Bridging Tutorial series. Keep reading the rest of the series:

Debian Linux: Configure Network Interfaces As A Bridge / Network Switch

OpenBSD: Configure Network Interface As A Bridge / Network Switch

How To PFSense Configure Network Interface As A Bridge / Network Switch

FreeBSD: NIC Bonding / Link Aggregation / Trunking / Link Failover

Setup Bridge (br0) Network on Ubuntu Linux

Ubuntu setup a bonding device and enslave eth0+eth2

Setup Bonded (bond0) and Bridged (br0) Networking On Ubuntu

How To Patch and Protect Linux Server Against the Glibc GHOST Vulnerability # CVE-2015-0235

omid — Fri, 05 Jan 2018 15:56:16 +0000

very serious security problem has been found in the GNU C Library (Glibc) called GHOST. How can I fix GHOST vulnerability and protect my Linux server against the attack? How do I verify that my server has been fixed against the Glibc GHOST vulnerability?

A very serious security problem has been found and patched in the GNU C Library called Glibc. It was announced on 27th January 2015.

What is the GHOST security bug?

From the RHEL bugzilla:

A heap-based buffer overflow was found in __nss_hostname_digits_dots(), which is used by the gethostbyname() and gethostbyname2() glibc function call. A remote attacker could use this flaw to execute arbitary code with the permissions of the user running the application.

A mailing list entry with more details, including in-depth analysis and exploit vectors is here.

What C library (Glibc) version does my Linux system use?

The easiest way to check the version number is to run the following command:

ldd –version

Sample outputs from RHEL/CentOS Linux v6.6:

ldd (GNU libc) 2.12

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Written by Roland McGrath and Ulrich Drepper.

Sample outputs from Ubuntu Linux 12.04.5 LTS:

ldd (Ubuntu EGLIBC 2.15-0ubuntu10.9) 2.15

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Written by Roland McGrath and Ulrich Drepper.

Sample outputs from Debian Linux v7.8:

ldd (Debian EGLIBC 2.13-38+deb7u6) 2.13

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Written by Roland McGrath and Ulrich Drepper.

A list of affected Linux distros

RHEL (Red Hat Enterprise Linux) version 5.x, 6.x and 7.x

CentOS Linux version 5.x, 6.x & 7.x

Ubuntu Linux version 10.04, 12.04 LTS

Debian Linux version 7.x

Linux Mint version 13.0

Fedora Linux version 19 or older

SUSE Linux Enterprise 11 and older (also OpenSuse Linux 11 or older versions).

SUSE Linux Enterprise Software Development Kit 11 SP3

SUSE Linux Enterprise Server 11 SP3 for VMware

SUSE Linux Enterprise Server 11 SP3

SUSE Linux Enterprise Server 11 SP2 LTSS

SUSE Linux Enterprise Server 11 SP1 LTSS

SUSE Linux Enterprise Server 10 SP4 LTSS

SUSE Linux Enterprise Desktop 11 SP3

Arch Linux glibc version <= 2.18-1

GHOST vulnerability check

You can test or reproduce the bug using the following C code:

/* ghosttest.c: GHOST vulnerability tester */

/* Credit: http://www.openwall.com/lists/oss-security/2015/01/27/9 */

#include

#define CANARY in_the_coal_mine

struct {

char buffer[1024];

char canary[sizeof(CANARY)];

} temp = { buffer , CANARY };

int main(void) {

struct hostent resbuf;

struct hostent *result;

int herrno;

int retval;

/*** strlen (name) = size_needed – sizeof (*host_addr) – sizeof (*h_addr_ptrs) – 1; ***/

size_t len = sizeof(temp.buffer) – 16*sizeof(unsigned char) – 2*sizeof(char *) – 1;

char name[sizeof(temp.buffer)];

memset(name, 0 , len);

name[len] = \0 ;

retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);

if (strcmp(temp.canary, CANARY) != 0) {

puts( vulnerable );

exit(EXIT_SUCCESS);

}

if (retval == ERANGE) {

puts( not vulnerable );

exit(EXIT_SUCCESS);

}

puts( should not happen );

exit(EXIT_FAILURE);

}

Compile and run it as follows:

$ gcc ghosttest.c -o ghosttest

$ ./ghosttest

Sample outputs from patched Debian v7.8 server:

not vulnerable

Sample outputs from unpatched Ubuntu 12.04 LTS server:

vulnerable

How do list packages/applications depends upon vulnerable Glibc?

Type the following lsof command:

lsof | grep libc | awk {print $1} | sort | uniq

Sample outputs from my Debian Linux v7.x nas:

Fig.01: Linux find all the services/applications that rely on the GNU C libraries (Glibc) command

Fix the GHOST vulnerability on a CentOS/RHEL/Fedora/Scientific Linux

Type the following yum command as the root user:

sudo yum clean all

sudo yum update

Finally, reboot RHEL/SL/Fedora/CentOS Linux server by typing the following command:

Sysadmin should plan on updating as soon as possible or use maintenance reboot window ##

sudo reboot

Sample outputs:

Fig.02 Fix the GHOST vulnerability on a CentOS/RHEL/Fedora/Scientific Linux

Fix the GHOST vulnerability on a Ubuntu Linux

Type the following apt-get command as the root user:

sudo apt-get clean

sudo apt-get update

sudo apt-get upgrade

only run dist-upgrade on a Ubuntu if you want to upgrade kernel too

sudo apt-get dist-upgrade

Finally, reboot Ubuntu Linux server by typing the following command:

sudo reboot

Sample outputs:

Fig.03: Fix the GHOST vulnerability on a Ubuntu Linux LTS

Fix the GHOST vulnerability on a Debian Linux

Type the following apt-get command as the root user:

sudo apt-get clean

sudo apt-get update

sudo apt-get upgrade

No need to do dist-upgrade (see man page: man apt-get)

sudo apt-get dist-upgrade

Finally, reboot Debian Linux server by typing the following command:

sudo reboot

Sample session:

Gif 01: Fix the GHOST vulnerability on a Debian Linux server

Fix the GHOST vulnerability on a SUSE Linux Enterprise

To install this SUSE Security Update use YaST online_update. Or use the following commands as per your version:

SUSE Linux Enterprise Software Development Kit 11 SP3

zypper in -t patch sdksp3-glibc-10206

SUSE Linux Enterprise Server 11 SP3 for VMware

zypper in -t patch slessp3-glibc-10206

SUSE Linux Enterprise Server 11 SP3

zypper in -t patch slessp3-glibc-10206

SUSE Linux Enterprise Server 11 SP2 LTSS

zypper in -t patch slessp2-glibc-10204

SUSE Linux Enterprise Server 11 SP1 LTSS

zypper in -t patch slessp1-glibc-10202

SUSE Linux Enterprise Desktop 11 SP3

zypper in -t patch sledsp3-glibc-10206

Finally run for all SUSE linux version to bring your system up-to-date:

zypper patch

Fix the GHOST vulnerability on a OpenSUSE Linux

To see a list of available updates including glibc on a OpenSUSE Linux, enter:

# zypper lu

To simply update installed glibc packages with their newer available versions, run:

# zypper up

How can I verify that my Linux system no longer vulnerable after the reboot?

Method #1: The easiest way to check vulnerability and/or confirm remediation is to run the following command to verify that you are running an updated version of Glibc:

$ ldd –version

Method #2: Run the instructions given in the previous section called GHOST vulnerability check (generic method for all Linux based systems).

Method #3: If you are RHN subscriber see the Red Hat Access Lab: GHOST tool (only for RHEL/CentOS/SL systems – download link):

#!/bin/bash

# rhel-GHOST-test.sh – GHOST vulnerability tester. Only for CentOS/RHEL based servers. #

# Version 3

# Credit : Red Hat, Inc – https://access.redhat.com/labs/ghost/ #

echo Installed glibc version(s)

rv=0

for glibc_nvr in $( rpm -q –qf %{name}-%{version}-%{release}.%{arch}\n glibc ); do

glibc_ver=$( echo $glibc_nvr | awk -F- { print $2 } )

glibc_maj=$( echo $glibc_ver | awk -F. { print $1 } )

glibc_min=$( echo $glibc_ver | awk -F. { print $2 } )

echo -n – $glibc_nvr:

if [ $glibc_maj -gt 2 -o \

$ $glibc_maj -eq 2 -a $glibc_min -ge 18 $ ]; then

# fixed upstream version

echo not vulnerable

else

# all RHEL updates include CVE in rpm %changelog

if rpm -q –changelog $glibc_nvr | grep -q CVE-2015-0235 ; then

echo not vulnerable

else

echo vulnerable

rv=1

done

if [ $rv -ne 0 ]; then

cat <

This system is vulnerable to CVE-2015-0235.

Please refer to for remediation steps

EOF

exit $rv

Sample outputs from patched RHEL v6.8 server:

bash rhel-GHOST-test.sh

Installed glibc version(s)

glibc-2.12-1.149.el6_6.5.x86_64: not vulnerable
– glibc-2.12-1.149.el6_6.5.i686: not vulnerable
This entry is 2 of 2 in the Linux GHOST Glibc Critical Security Vulnerability series. Keep reading the rest of the series:
Check Ghost Vulnerability Test Programs
Secure and Patch Your Linux Server For Ghost Bug