'allow' 태그의 글 목록

'allow'에 해당되는 글 2건

2009.10.13 Restriction of the access with the help of Nginx
2009.08.05 서블릿 응답 헤더(Response Header)

2009. 10. 13. 09:53

Restriction of the access with the help of Nginx

2009. 10. 13. 09:53 in 서버구축 (WEB,DB)

			트윗하기

In this short post the point is how to protect your files and some part of your web site with a user password. With Nginx, a lot of options exist to protect your site with usernames and passwords. In Nginx the solution is not less attractive than in apache.

In the configuration file, set folder to close, it is only necessary to load the file with passwords.
There are two examples for closing of the folder with files:

        location ^~ /files/ {
            root   /path/to/server;
            autoindex    on;
            autoindex_exact_size  off;
            auth_basic "Hello, please login";
            auth_basic_user_file /usr/nginx/passwords;
            access_log   /usr/nginx/logs/files.log   download;
        }

and for closing of the admin-folder with the additional restriction on IP:

        location ^~ /admin/ {
            fastcgi_pass unix:/home/project/server.sock;
            include  conf/fastcgi.conf;
            allow 11.11.0.0/16;
            allow 22.22.22.22;
            deny all;
            auth_basic "Hello, Admin, please login";
            auth_basic_user_file /usr/nginx/adminpassword;
            access_log   /usr/nginx/logs/admin.log  main;
        }

The passwd program utility of Apache can be used to create and update usernames and passwords of new users:

htpasswd -b passwords NewUser NewPassword

In the file the writing with the encoded password looks like:

NewUser:P47ghZ4kloG78: Your Can Comment Here

The protection from cracking the password can be organized at the same time with two methods based on the use iptables:

Blocking IP temporarily if the amount of the requests per second exceeds any reasonable amount.
Write failed attempts in the log, check it with the script every minute, than pumps the IP addresses in iptables

For the first variant it is enough to create rules:

iptables -A INPUT -p tcp --syn --dport 80 -i eth0 -m state --state NEW
            -m recent --name bhttp --set
iptables -A INPUT -p tcp --syn --dport 80 -i eth0 -m state --state NEW
            -m recent --name bhttp --update --seconds 120 
            --hitcount 360 -j DROP
iptables -A INPUT -p tcp --syn --dport 80 -i eth0 -j ACCEPT

It is possible to use TARPIT instead of DROP to complicate the life of the crackers.

For the second variant it is necessary to add in config:

        location /401.html {
            root   /usr/nginx;
            access_log   /usr/nginx/logs/denied.log  error401;
        }

For example the format error 401 looks at me:

log_format error401  '$remote_addr - $remote_user [$time_local] '
                     '$status "$request"';

Now all wrong logins are saved in a separate log file, which is checked per cron job:

*/1 * * * * root /usr/nginx/parser401.pl >/dev/null 2>&1

For example this script: parser401.pl Скрипт проверяет лог, и если обнаруживает больше 4-х попыток неправильного набора пароля, блокирует этот IP. Script checks the log file and if it finds more than 4 attempts of the wrong password, it blocks this IP address.

NginxModules : http://wiki.nginx.org/NginxModules

저작자표시

Posted by 날으는물고기

ACCESS, allow, auth_basic, deny, hi.pe.kr, htpasswd, iptables, Nginx, proxy, 물고기, 서버구축, 웹서버, 접근제한, 프록시서버

Trackback 0 Comment 0

2009. 8. 5. 13:54

서블릿 응답 헤더(Response Header)

2009. 8. 5. 13:54 in 서버구축 (WEB,DB)

			트윗하기

서블릿에서 응답 헤더들을 설정하는 방법 - 응답헤더는 클라이언트에게 문서 내용을 한글자라도 보내기 전에 설정해야 한다.
- 일반적으로 setHeader("","") 로 사용한다.
- 서블릿 버전2.1에서는 헤더를 설정하면 바꿀수 없었다 같은 이름으로 헤더를 설정하더라도 이전것은 유지되면서 새로운 해더가 추가되는 형식이 였다. 하지만 서블릿 버전 2.2 에서는 setHeader를 같은 이름으로 하면 덮어쓰기 형식으로 지원하며, 같은 이름으로 추가는 addHeader("","")로 하면 된다.

Accept-Range	- HTTP1.1 에서 추가 - 클라이언트가 보낸 Range요청헤더를 받아들 일 수 있는지의 여부를 뜻한다. - 받아들 일 수 있다면 byte 단위 지정 아니면 none을 지정한다.
Age	- HTTP1.1에서 추가 - 프록시서버에서 사용하는 것으로 원래의서버가 문서를 만든 후 얼마만큼의 시간이 지났는지를 ... - Servlet에선 거의 사용하지 않는다.
Allow	- 서버가 지원하는 요청방법(GET,POST등)을 지정한다. - 상태코드가 405일 때에는 반드시 이 헤더를 설정해야 한다. - 서블릿의 기본 service메소드는 OPTIONS요청에 대해 이 헤더를 자동적으로 만든다.
Cache-Control	이것은 문서를 받은 클라이언트가 그 문서를 개시에 어떻게 저장해야 하는것인가를 지시하기 위한 헤더 1. public - 다른 일반적인 규칙들을 위배하더라도문서를 캐시해도 좋다는 뜻. 2. private - 문서를 한 명의 사용자에 대해서만 그리고 비공개(비공유)캐시에만 저장할 수 있다는 뜻. 3. no-cache - 문서를 캐시에 저장하지 말라는 뜻. - 브라우저는 일반적으로 양식데이터를 포함하는 요청에 대해서는 캐싱하지 않는다. 4. no-store - 문서를 캐시뿐만 아니라 다른 어떠한 임시적인 저장장소에도 저장해서는 안된다는 뜻. - 보안상 중요한 정보들을 이렇게 처리하자.! 5. must-revalidate - 클라이언트는 문서를 사용할 때마다 원래의 서버에 대해 문서의 유효성을 재확인해야 한다. 6. proxy-revalidate - 공유 캐시에만 적용된다는 점만 제외한다면 must-revalidate와 동일하다. 7. max-age=xxx - HTTP1.1 을 지원하는 클라이언트데서만 동작. - xxx초 이후에는 문서가 유효하지 않을 수 있다는 뜻. - 응답에 max-age왕 Expires모두 있다면 max-age가 우선 8.s-max-age=xxx - max-age와 동일하나 공유캐시에 적용되는 것이다.
Connection	- 연결방식에 대한 지시를 의미하는 헤더이다. - Connection: keep-alive 이면 영속적 연결이 쓰인다.(기본) 단 Content-Length 응답헤더를 반드시 포함시켜야 한다. - 영속적 HTTP연결을 사용하지 않으려면 Connection을 close로 하기보단 Content-Length를 지정하지 않으면 된다. - 영속적 연결 자세히 보기
Content-Encoding	- 전송 과정 도중에 페이지가 어떻게 인코딩되어야 하는지를 지정한다. - 여기서 MIME 정보가 쓰인다.
Content-Language	- 문서가 어떤 언어로 쓰여져 있는지를 지정한다.
Content-Length	- 응답의 크기(바이트 개수)를 의미한다. - 영속적 연결 자세히 보기 에서 ByteArrayOutStream으로 바이트 개수를 알아낸 후 response.setContentLength를 이용해서 헤더에 설정한 후 바이트 스트림으로 writeTo메소드를 호출하는 것이다. - 바이트 개수를 얻어보자!
Content-Location	- HTTP1.1 에서 추가 - 요청된 문서의 또 다른 주소를 제공하는데 쓰인다.
Content-MD5	Content-MD5 응답 헤더는 응답에 포함된 문서의 MD5 다이제스트를 제공한다. 다이제스트(Digest)란? 문서전체가 제대로 전송되었다는걸 확인하기 위한 용도로 쓰인다.
Content-Range	- HTTP1.1 에서 추가 - 문서의 일부분만을 전송할 때 어디서 어디까지의 문서가 전송되는 것인지를 알려주는 역할을 한다.
Content-Type	- 헤더의 응답 문서의 MIME형식을 의미한다.
Date	- 현재 일시를 GMT형식으로 지정한 것이다. - response.setHeader("Date"."xxx") 로 설정한다 - 대부분의 서버들은 이 헤더를 자동적으로 설정해 준다.!
ETag	- HTTP1.1 에서 추가 - 클라이언트가 나중에 참조할 때 사용할 이름을 문서에 부여하는 역할을 한다.
Expires	- 이 헤더는 문서가 캐시에 남아 있을 수 있는 유효 시간을 설정한다. - 10분이상 남아 있지 않도록 하는 예제 long currentTime = System.currentTimeMillis(); long termTime = 10006010 // 10분 밀리초 단위로 response.setDateHeader("Expires",currentTime+termTime); - Cache-Control 헤더의 max-age 와 동일한 기능
Last-Modified	- 문서가 마지막으로 수정된 일시를 의미한다. - getLastModified 를 이용해서 처리하자.!
Location	- 문서의 주소를 의미한다. - 상태코드가 300번 대이면 반드시 이 헤더를 포함시켜야 한다.
Pragma	- HTTP 1.0에서 no-cache로 설정하면, 브라우저는 문서를 캐시에 저장하지 않는다. 그러나 HTTP 1.0 브라우저에 따라서 이 헤더에 대한 반응 방식이 다를 수도 있다는 점을 주의해야 한다. - HTTP 1.1 에서는 Cache-Control:no-cache 쪽이 좀 더 신뢰할 수 있다.
Refresh	- 브라우저가 지정된 시간 이후에 문서를 자동적으로 다시 로딩하게 만드는데 쓰인다. - 반복적인 재요청이 아니다. - response.setHeader("Refresh","5;URL=http://host/path"); - 이 헤더는 HTTP 1.1의 공식 헤더가 아니지만, 넷스케이프와 익스플로러가 모두 지원하고 있어서 거의 공식적인 헤더라고 해도 무방하다.
Retry-After	- 응답 상태 코드 503과 함께 쓰이는 것으로 얼마 후에 문서 요청을 다시 시도해야 하는지 알려주는 역할을 한다.
Server	- 웹서버 종류를 알려주는 헤더로 서블릿이 직접 설정하는일은 거의없다.
Set-Cookie	- 응답에 담긴 페이지와 연관된 하나의 쿠키를 설정한다. - 쿠키가 여러개면 그 개수 만큼의 Set-Cookie들을 설정한다. - response.setHeader("Set-Cookie",...) 보다는 response.addCookie를 사용하자!
Trailer	- HTTP1.1 에서 추가 - "chunked" 전송 인코딩 방식으로 전송되는 메시지의 꼬리에 존재하는 헤더 필드들을 식별하기 위한 것이다. - 별로 사용되진 않는다.
Transfer-Encoding	- "chunked" 전송 코딩을 사용할 때에는 이 헤더의 값을 chunked로 설정
Upgrade	- 서버에게 몇 가지 새로운 프로토콜들 중 하나로 전환하자고 요청했을 때 사용한다. - 서블릿에서는 이 헤더를 사용하는 일이 거의 없다.
Vary	- HTTP1.1 에서 추가 - 클라이언트가 응답 문서의 캐시 여부를 결정할 때 사용할 헤더 이름을 알려주는 역할을 한다. - 거의 쓰이진 않는다.
Via	- HTTP1.1 에서 추가 - 게이트웨이나 프록시가 사용하는 것으로 요청이 통과한 중간 사이트들의 목록이 담긴다.
Waning	- 캐시나 내용전송 과정의 오류등을 클라이언트에게 경고하는 역할 - 거의 쓰이진 않는다.
WWW-Authenticate	- 상태코드가 401이면 반드시 포함되는 헤더