Ошибка 403 ubuntu

1. You should configure your /etc/hosts file like that:

127.0.0.1   localhost
127.0.0.1   test-site
127.0.1.1   my-hostname
# The following lines are desirable for IPv6 capable hosts. etc...

Where test-site is the second «localhost». And my-hostname is the «System hostname» defined in /etc/hostname.

2. You should define and enable a Virtual Host (VH):

There is a default HTTP VH. It’s placed in /etc/apache2/sites-available/. The filename is 000-default.conf. You have to edit it (you can rename it, if you want, or make some other .conf files, based on it) and after that you have to enable it.

You can enable it manually through creation of «soft, symbolic link»:

sudo ln -s /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-enabled/

Or you can use Apache2 tool called a2ensite, which make the same:

sudo a2ensite 000-default.conf

Let’s assume there has 3 Virtual Hosts, enabled SSL, and registered private domain (SOS.info for an example):

/etc/apache2/sites-available/http.SOS.info.conf
/etc/apache2/sites-available/https.SOS.info.conf

And one which is created for the purposes of this topic:

/etc/apache2/sites-available/http.test-site.conf

The content of First 2 VHs is:

$ cat /etc/apache2/sites-available/http.SOS.info.conf

<VirtualHost *:80>    
    ServerName SOS.info
    ServerAlias www.SOS.info
    ServerAdmin admin@SOS.info

    # Redirect Requests to SSL
    Redirect permanent "/" "https://SOS.info/"

    ErrorLog ${APACHE_LOG_DIR}/http.SOS.info.error.log
    CustomLog ${APACHE_LOG_DIR}/http.SOS.info.access.log combined       
</VirtualHost>

^{This one redirects all HTTP requests to HTTPS.}

$ cat /etc/apache2/sites-available/https.SOS.info.conf

<IfModule mod_ssl.c>    
    <VirtualHost _default_:443>    
        ServerName SOS.info
        ServerAlias www.SOS.info
        ServerAdmin admin@SOS.info

        DocumentRoot /var/www/html  

        SSLEngine on    
        SSLCertificateFile /etc/ssl/certs/SOS.info.crt
        SSLCertificateKeyFile /etc/ssl/private/SOS.info.key
        SSLCertificateChainFile /etc/ssl/certs/SOS.info.root-bundle.crt
        #etc..
    </VirtualHost>    
</IfModule>

^{This is the HTTPS VH.}

The content of these two files can be posted in one file, but in this case their management (a2ensite/a2dissite)will be more difficult.

The third Virtual Host is that, which is created for our purposes:

$ cat /etc/apache2/sites-available/http.test-site.conf

<VirtualHost *:80>
    ServerName test-site
    ServerAlias test-site.SOS.info

    DocumentRoot /var/www/test-site
    DirectoryIndex index.html

    ErrorLog ${APACHE_LOG_DIR}/test-site.error.log
    CustomLog ${APACHE_LOG_DIR}/test-site.access.log combined

    <Directory /var/www/test-site>
        # Allow .htaccess 
        AllowOverride All
        Allow from All
    </Directory>    
</VirtualHost>

3. With this configuration you should access:

http://localhost     # pointed to the directory of the mine Domain 
https://localhost    # iin our case: /var/www/html (SOS.info), but you should get an error, because the SSL certificate

http://SOS.info      # which redirects to https://SOS.info
https://SOS.info     # you should have valid SSL certificate

http://www.SOS.info  # which is allied to http://SOS.info and redirects to https://SOS.info
https://www.SOS.info # which is allied to https://SOS.info

On the main example you should access and:

http://test-site           # pointed to the directory /var/www/test-site
http://test-site.SOS.info  # which is allied to http://test-site

Try to open the site in the web browser or just try (in the terminal) with next commands:

$ curl -L http://test-site/index.html
$ curl -L http://test-site.SOS.info/index.html

^{Of course, you need to have some index.html pages in their DocumentRoot}

I will leave next notes by reason of pedantry

4. You need properly configured `/etc/apache2/apache2.conf`.

Ii is good idea to spend some time to improve your server’s security. These manuals are about the security configuration: 1st and 2nd. Here you can get free SSL certificate. These sites will help you to check your progress: 1st and 2nd.

According to above security manuals /etc/apache2/apache2.conf file must looks like:

Mutex file:${APACHE_LOCK_DIR} default

PidFile ${APACHE_PID_FILE}

Timeout 60

#KeepAlive Off
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

HostnameLookups Off

ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn

IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf

Include ports.conf

<Directory />
    Options None FollowSymLinks 
    AllowOverride None
    Require all denied
</Directory>

<Directory /var/www/>
    Options None FollowSymLinks 
    AllowOverride None
    Require all granted
</Directory>

AccessFileName .htaccess
<FilesMatch "^.ht">
    Require all denied
</FilesMatch>

LogFormat "%v:%p %h %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" vhost_combined
LogFormat "%h %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" combined
LogFormat "%h %l %u %t "%r" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

IncludeOptional conf-enabled/*.conf
IncludeOptional sites-enabled/*.conf

# Hide Server type in the http error-pages 
ServerSignature Off
ServerTokens Prod

# Etag allows remote attackers to obtain sensitive information 
FileETag None

# Disable Trace HTTP Request
TraceEnable off

# Set cookie with HttpOnly and Secure flag.
# a2enmod headers
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

# Clickjacking Attack
Header always append X-Frame-Options SAMEORIGIN

# CX-XSS Protection
Header set X-XSS-Protection "1; mode=block"

# Disable HTTP 1.0 Protocol
RewriteEngine On
RewriteCond %{THE_REQUEST} !HTTP/1.1$
RewriteRule .* - [F]

# Change the server banner @ ModSecurity 
# Send full server signature so ModSecurity can alter it
ServerTokens Full
# Alter the web server signature sent by Apache
<IfModule security2_module>
    SecServerSignature "Apache 1.3.26"
</IfModule>
Header set Server "Apache 1.3.26"
Header unset X-Powered-By

# Hde TCP Timestamp
#   gksu gedit /etc/sysctl.conf
#   >> net.ipv4.tcp_timestamps = 0
# Test: sudo hping3 SOS.info -p 443 -S --tcp-timestamp -c 1

# Disable -SSLv2 -SSLv3 and weak Ciphers
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA EECDH EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"

5. Set up the Firewall.

To allow/deny external access to your web server you can use UFW (Uncomplicated Firewall):

sudo ufw allow http
sudo ufw allow https

To allow only tcp protocol use:

sudo ufw allow http/tcp
sudo ufw allow https/tcp

You can use and the port number directly:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Just in case you can reload the «rules table»:

sudo ufw reload

You can use and UFW’s GUI interface, called gufw.

sudo apt update
sudo apt install gufw
gufw &

_{Choice the Office profile. It will set: Status:ON, Incoming:Deny and Outgoing:Allow and add your rules.}

6. If you have a router don’t forget to forward some ports:

If you have a router and you want your web server to be accessible from Internet, don’t forget to add some port forwarding. Something like this.

При работе с серверами и веб-ресурсами мы сталкиваемся с ошибками, которые вызываем при обслуживании и настройке. Когда вы сталкиваетесь с такими ошибками, вам необходимо как можно быстрее диагностировать и устранить проблему, чтобы избежать простоев и потери данных.

В этой краткой статье рассматривается типичная ошибка при работе с серверами (403 Forbidden), ее причины и способы ее устранения.

Ошибка Nginx 403 Forbidden – это код состояния, сгенерированный и отображаемый пользователю, когда клиент пытается получить доступ к части веб-сервера с недостаточными разрешениями. Например, NGINX защищает список каталогов и приведет к ошибке 403.

Причины ошибки Nginx 403 на стороне сервера

Прежде чем мы начнем, стоит отметить, что ошибка может исходить от клиента, а не от самого сервера. Сначала мы рассмотрим ошибки на стороне сервера, а затем ошибки на стороне клиента.

Причина 1: неправильный индексный файл

Самая первая и частая причина ошибки NGINX 403 Forbidden – это неправильная конфигурация индексного файла.

Файл конфигурации Nginx указывает, какие индексные файлы загружать и в каком порядке их загружать. Однако, если указанные индексные файлы отсутствуют в каталоге, Nginx вернет ошибку 403 Forbidden.

Например, конфигурация ниже определяет индексные файлы и способ их загрузки.

location / {
index index.html index.htm index.html inde.php;
}

Один из способов решения этой проблемы – добавить индексный файл, указанный в файле конфигурации, или добавить доступный индексный файл в файл конфигурации.

Другой способ решить эту проблему – разрешить Nginx отображать каталоги, если индексный файл недоступен. Включите этот модуль, добавив следующую запись в файл конфигурации.

location / {
autoindex on;
autoindex_exact_size on;
}

Для получения дополнительной информации о том, как обслуживать статический контент, рассмотрите ресурс документации Nginx, представленный ниже:

https://docs.nginx.com/nginx/admin-guide/web-server/serving-static-content/

Причина 2: неправильно настроенные разрешения

ошибка Nginx 403Forbidden также может возникать из-за неверно установленных разрешений для файлов и каталогов. Чтобы Nginx мог успешно передать клиенту определенный файл и ресурс, Nginx должен иметь разрешения RWX – чтение, запись и выполнение – на всем пути.

Чтобы устранить эту ошибку, измените разрешение каталогов на 755 и разрешение файла на 644. Убедитесь, что пользователь, запускающий процесс Nginx, владеет файлами. Например, установите пользователя на www-data:

sudo chown -R www-data:www-data *

Наконец, установите права доступа к каталогу и файлу как:

sudo chmod 755 {dir}
sudo chmod 644 {files}

Как уже упоминалось, в других случаях ошибка 403 может быть вызвана пользователем, а не на стороне сервера. Чтобы решить такие проблемы на стороне клиента, выполните следующие операции.

• Убедитесь, что вы получаете доступ к правильному веб-адресу
• Очистить кеш браузера
• Убедитесь, что брандмауэр или прокси-сервер разрешает вам доступ к веб-ресурсу.

Заключение

В этой краткой статье обсуждаются причины ошибки NGIX 403 Forbidden и различные способы ее устранения. Прежде чем пытаться использовать какие-либо методы устранения неполадок, рекомендуется просмотреть журналы сервера.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Ошибка 403 forbidden nginx означает что вы запросили ресурс у сервера, который он не может отправить, потому что у вас недостаточно прав для его просмотра. Фактически, это даже не ошибка, это сообщение HTTP 4xx, которое всего лишь сообщает, что у вас нет доступа к определенному контенту.

Достаточно часто такие сообщения показывается пользователям, потому что они были заблокированы на сайте или попытались получить доступ к файлу, который доступен только локально. В этой статье мы попытаемся разобраться со случаями, когда появление 403 forbidden nginx 1.4 6 Ubuntu не желательно и представляет из себя ошибку, которую веб-мастер или системный администратор должен решить. Но сначала рассмотрим основные причины почему вы можете видеть это сообщение.

Итак, ошибка 403 forbidden nginx 1.4 6 Ubuntu может возникать в таких случаях:

• Пользователь заблокирован на сервере с помощью директивы deny в конфигурации nginx;
• Доступ к данному ресурсу разрешен только с определенного IP адреса;
• Пользователь пытается получить доступ к папке, отображение содержимого которой запрещено;
• Nginx не может прочитать содержимое запрашиваемого файла в файловой системе;
• Файл index не найден в каталоге.

Это основные причины, которые встречаются наиболее часто. Как видите, две последние из них представляют из себя проблему. Рассмотрим как ее решить.

Неверно выставлены права

Если права на файл, который пытается получить пользователь выставлены неправильно, то будет выдана такая ошибка. Необходимо, чтобы у Nginx были права не только на чтение этого файла, но и на чтение все родительских каталогов. Это можно проверить командой:

$ namei -l /var/www/public_html/index.html

Для всех элементов пути должен быть установлен флаг «r», чаще всего лучше подходят права 644, то есть, владелец может все, а группа и остальные только читать. Если права не соответствуют, то вы нашли проблему и осталось только исправить права с помощью chmod. Например:

$ chmod 644 /var/www/public_html/index.html

Вот так должно быть:

Также обратите внимание на владельца файлов и папок. Если nginx должен иметь возможность выполнять туда запись, то, возможно есть смысл сделать владельцем пользователя nginx или позже получите другую ошибку. Также, если с правами все хорошо, но ошибка не решена попробуйте отключить SELinux, возможно, эта служба мешает Nginx получить доступ к файлам.

Если вы используете PHP и получаете такую ошибку, то еще нужно проверить может ли Nginx получить доступ к сокету обработчика PHP. Желательно, чтобы php-fpm запускался с той же группой, что и nginx, потому что права, по умолчанию, для доступа к сокету 660 (для группы и для владельца). Поэтому проверьте поля listen.owner и listen.group в файле  /etc/php5/fpm/php-fpm.conf.

Также можно попытаться использовать сетевой сокет и подключаться к порту, а не файлу.

Неверно настроен index

Файл index открывается по умолчанию при запросе папки на сервере, в которой он находится. Если такого файла в папке нет или он настроен неправильно в конфигурационном файле nginx, то программа попытается отобразить содержимое папки, а это по умолчанию запрещено, поэтому вы получите 403 Foribden.

Чтобы решить проблему убедитесь, что файл index.html, index.php или как он у вас называется, находится в нужно папке, в той, которую вы запрашиваете. Проверьте конфигурационный файл и убедитесь, что в нем указана директива Index с правильным именем и расширением файла:

Если в директиве указаны только файлы html, а вы используете php, то уже понятно почему программа не может найти то, что нужно. Просто добавьте имя файла в директиву:

index index.html index.htm index.php;

I’m running Ubuntu 14.04 and havent run sudo apt-get update for many months.
When I try to update local /etc/apt/sources.list apt-get can connect to many repos no problem, but many (maybe 15% of total) return errors like this

W: Failed to fetch http://nz.archive.ubuntu.com/ubuntu/dists/trusty-backports/multiverse/binary-i386/Packages  403  Forbidden

W: Some index files failed to download. They have been ignored, or old ones used instead.

I’m wondering if the repo addresses or configurations have changed since my machine last made contact, and therefore I need to go through some process to completely flush and then re-establish the /etc/apt/sources.list?
I’m thinking something like

sudo apt-cache clean

But I don’t want to bork my system any more than it already is.
How can I resolve this 403 Forbidden error?

Current state of /etc/apt/sources.list

# deb cdrom:[Ubuntu 14.04 LTS _Trusty Tahr_ - Release amd64 (20140417)]/ trusty main restricted

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://nz.archive.ubuntu.com/ubuntu/ trusty main restricted
deb-src http://nz.archive.ubuntu.com/ubuntu/ trusty main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb http://nz.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
deb-src http://nz.archive.ubuntu.com/ubuntu/ trusty-updates main restricted

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb http://nz.archive.ubuntu.com/ubuntu/ trusty universe
deb-src http://nz.archive.ubuntu.com/ubuntu/ trusty universe
deb http://nz.archive.ubuntu.com/ubuntu/ trusty-updates universe
deb-src http://nz.archive.ubuntu.com/ubuntu/ trusty-updates universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu 
## team, and may not be under a free licence. Please satisfy yourself as to 
## your rights to use the software. Also, please note that software in 
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb http://nz.archive.ubuntu.com/ubuntu/ trusty multiverse
deb-src http://nz.archive.ubuntu.com/ubuntu/ trusty multiverse
deb http://nz.archive.ubuntu.com/ubuntu/ trusty-updates multiverse
deb-src http://nz.archive.ubuntu.com/ubuntu/ trusty-updates multiverse

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb http://nz.archive.ubuntu.com/ubuntu/ trusty-backports main restricted universe multiverse
deb-src http://nz.archive.ubuntu.com/ubuntu/ trusty-backports main restricted universe multiverse

deb http://security.ubuntu.com/ubuntu trusty-security main restricted
deb-src http://security.ubuntu.com/ubuntu trusty-security main restricted
deb http://security.ubuntu.com/ubuntu trusty-security universe
deb-src http://security.ubuntu.com/ubuntu trusty-security universe
deb http://security.ubuntu.com/ubuntu trusty-security multiverse
deb-src http://security.ubuntu.com/ubuntu trusty-security multiverse

## Uncomment the following two lines to add software from Canonical's
## 'partner' repository.
## This software is not part of Ubuntu, but is offered by Canonical and the
## respective vendors as a service to Ubuntu users.
# deb http://archive.canonical.com/ubuntu trusty partner
# deb-src http://archive.canonical.com/ubuntu trusty partner

## This software is not part of Ubuntu, but is offered by third-party
## developers who want to ship their latest software.
deb http://extras.ubuntu.com/ubuntu trusty main
deb-src http://extras.ubuntu.com/ubuntu trusty main