'포트포워딩'에 해당되는 글 4건

  1. 2012.10.25 iptables 방화벽 및 라우팅, 트래픽 분산 (2)
  2. 2011.07.04 DNS Port Forwarding con Meterpreter (Spanish)
  3. 2011.04.24 방화벽 우회 ssh 터널링 (포트포워딩)
2012.10.25 16:04

iptables 방화벽 및 라우팅, 트래픽 분산

 

 



1.iptables 개요 
2.패킷의 흐름 
3.NAT 구성 방법 
4. PORT 포워딩 
5.iptables를 이용한 방화벽 구축 
6.Routing 분석 
7.트래픽 분산 


1.iptables 개요 
iptables은TABLE, CHAIN, TARGET의 요소를 가지고 있다. 
TABLE 분석--------------------------------------------- 
- mangle, nat , filter 3개의 테이블이 있으며, 테이블을 명시하지 않고 사용할 경우에는 filter가 기본값이 된다. 
- 3개의 테이블은 고유한 특성을 가지고 있으며, 정리하면 다음과 같다. 
mangle : 패킷이 맨처음 들어왔을 경우에 제어가 가능하며, 패킷의 차단과 허용을 포함하 
라우팅 전,후에 규칙을 적용할 수 있다. 
nat : 패킷의 해더를 검사하여 소스와 목적지의 아이피 변환을 목적으로 한다. 
filter : mangle과 비슷하나, nat로 나가는 패킷을 제외한 것의 차단과 허용을 목적으로 
한다. 

CHAIN 분석--------------------------------------------------------- 
- 각 테이블마다 체인이 구성되어 있으며, 기본적으로 INPUT, FORWARD, OUTPUT이 있고, nat, mangle에는 PREROUTING, POSTROUTING의 체인이 추가되어 있다. 
- Iptables –L명령어로 체인 리스트를 확인할 수 있으며, 괄호 안에 기본 정책이 명시되어 있다. 

코드:
[admin@router admin]$ iptables -L 
Chain INPUT (policy ACCEPT) 
target     prot opt source               destination 

Chain FORWARD (policy ACCEPT) 
target     prot opt source               destination 
TCPMSS     tcp  --  anywhere             anywhere           tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU 

Chain OUTPUT (policy ACCEPT) 
target     prot opt source               destination


- 각 체인은 한줄로 한가지씩 규칙을 가지고 있으며, 규칙은 무조건적으로 정할 수 있는 것이 아니라 각 체인의 특성에 따라 정할 수 있다. 
체인의 흐름을 보면 
PREROUTING -> INPUT( FORWARD) -> OUTPUT -> POSTROUTING의 순서로 패킷이 이동하면서 규칙에 적용된다. 
FORWARD 체인을 중심으로 왼쪽은 들어오는 패킷을 제어할 수 있으며, 오른쪽은 나가는 패킷을 제어한다. 
만약에 PREROUTING 체인에서 나가는 패킷을 제어하고자 규칙을 작성한다고 해도 규칙이 적용되지 않는다. 
코드:
iptables  -t mangle -A PREROUTING -o eth0 -s 192.168.1.1 -j DROP 
iptables v1.2.7: Can't use -o with PREROUTING

에러가 나면서 적용되지 않는다. 
또한, 체인은 –N옵션을 이용하여 새로 만들고 –X옵션을 이용하여 삭제할 수 있다. 
코드:
iptables -t manlge -N
(일반적으로 대문자를 사용) 

TARGET 분석------------------------------------------------------- 
Chain INPUT (policy ACCEPT) 
target prot opt source destination (빈칸) 

각체인의 규칙은 target을 어떻게 정하는 가가 기본이며, 각 타켓의 특성을 보면 
ACCEPT : 패킷을 허용한다.

DROP : 패킷을 차단한다.
REJECT : 패킷을 거부한다. 
RETURN : 패킷을 맨 아래 규칙으로 내린다. 
MARK : 패킷에 마크를 표시한다. 
LOG : 로그를 남긴다.(/var/log/messages) 
MASQUERADE : 패킷의 출발지를 나가는 장치의 아이피로 바꾼다. 
SNAT : 패킷의 출발지를 지정한 아이피로 바꾼다. 
DNAT : 패킷의 도착지를 지정한 아이피로 바꾼다. 

***타겟은 사용할 수 있는 테이블이 다르며, 테이블에 맞게 사용하여야 한다. 

기타 --------------------------------------------------------------- 
prot : ip 프로토콜( -p) tcp,udp 
opt : 장치 (-o 나가는 장치, -i 들어오는 장치) eth0, ppp0 
source : 출발지 주소 ( -s ) 
destination : 도착지 주소 (-d) 




2. 패킷의 흐름 (그림참조) 


3. NAT 구성방법 

- NAT 구성이라고 함은 일반적으로 아이피를 공유하는 방법이다. 

NAT를 구성하기 전에는 linux 의 시스템 셋팅중에 ip_forward를 활성화 시켜주어야 한다. 
코드:
 echo 1 > /proc/sys/net/ipv4/ip_forward


WAN구간이 eth1 이라고 가정할 때 , 

-- 고정된 아이피가 있는 경우 
코드:
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 111.111.111.111


-- 유동 아이피인 경우 
코드:
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE







4. PORT 포워딩 

사설대역에서 외부로 서비스를 하고 싶을 때 라우터에서 특정 포트를 정해진 사설아이피로 보내주어 서비스가 가능하도록 한다. 
또한, 특정포트를 숨기고 싶을 때, 라우터의 loop 아이피로 패킷을 보내 속일수도 있다. 

예) 172.16.100.1 에서 MSSQL 서비스를 하고 싶은 경우 

코드:
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 1433 -j DNAT --to 172.16.100.1



5. iptables를 이용한 방화벽 구축 

POLICY-------------------------------------------------------- 
-각 체인은 정책을 가지고 있으며, 정책에 따라서 적절한 규칙을 적용시켜야 한다. 
(임의로 만든 체인은 정책을 가질 수 없다.) 

-기본적으로 모든 체인은 ACCEPT 를 정책으로 가지고 있으며, 
iptables -P 의 명령으로 정책을 변경시킬 수 있다. 
코드:
iptables -P INPUT DROP


-패킷이 들어와서 각 테이블을 지나가게 되며, 체인규칙을 적용받는다. 

만약 정책이 ACCEPT 이고 특별한 규칙이 정해져있지 않다면, 다음 테이블로 이동하게 된다. 
ACCEPT는 패킷을 허용한다는 의미 보다는 다음 테이블로 이동시킨다는 표현이 더 적절하다. 
DROP 은 다음 테이블로 가는 것을 차단한다. 

예를 들어 우선순위가 먼저인 INPUT의 정책을 DROP 으로 하고 OUTPUT에서 아무리 ACCEP를 한다고 하여도 INPUT에 허용할 예외규칙을 정하지 않는다면 패킷은 DROP 된다. 
예1) 소스가 192.168.1.1을 제외한 모든 패킷은 DROP 된다. 
코드:
iptables -P INPUT DROP 
iptables -A INPUT -s 192.168.1.1 -j ACCEPT


예2) 소스가 192.168.1.1을 제외한 모든 패킷은 ACCEPT 된다. 
코드:
iptables -P INPUT ACCEPT 
iptables -A INPUT -s 192.168.1.1 -j DROP


정책을 DROP으로 하는 경우는 드물며, 특별한 상황하에서 사용할 수 있다. 
예를 들어 DNS서버로만 운영하고 싶을경우 포트 53번 만을 허용하고 나머지는 모두 DROP시켜 불필요한 패킷이 들어오는 것을 막을 수 있다. 

필터링 순서------------------------------------------------------- 
패킷이 체인의 규칙에서 필터링 되는 과정은 맨위의 규칙부터 적용을 받는다. 
- 규칙 중간에 타켓을 ACCEPT, DROP, REJECT 를 만나면, 다음 규칙에 필터링되지 않고 다음 테이블로 건너 뛰게 된다. 

- 규칙 중간에 타켓을 신규로 만든 체인으로 만나면, 그 체인으로 이동하여 필터링 된 다음 다시 점프전의 체인내의 규칙으로 가서 순서대로 필터링 된다. 
- 신규로 만든 체인 내에서 타겟을 ACCEPT, DROP, REJECT를 만나면 다음 규칙에 필터링 되지 않고 , 다음 테이블로 건너뛰게 된다. 
- 규칙중에 MARK 가 중복되어 있을 경우에는 맨 마지막의 MARK 가 적용된다.(주의) 


6. 라우팅 분석 
코드:
root#route 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
210.222.17.176  *                 255.255.255.240     U     0      0        0 eth0 
192.168.100.0    *                255.255.255.0        U     0      0        0 eth1 
127.0.0.0          *                255.0.0.0              U     0      0        0 lo 
default         210.222.17.177  0.0.0.0                UG    0      0        0 eth0


패킷은 위에서 아래로 이동 하면서 규칙에 맞는 라우팅이 있을 경우 바로 이동하여, 
다음 라우팅 룰을 적용받지 않는다. 
만약 맞는 라우팅이 없다면 default 라우팅이 적용되어 이동하게 된다. 

위에서 게이트웨이가 없는 것은 라우터 자신의 인터페이스가 이미 대역을 가지고 있는 경우이며, 라우터의 인터페이스가 가지고 있지 않는 대역을 라우팅 할 경우에는 게이트웨이를 반드시 입력하여야 한다.(gw) 

(네트워크 대역을 추가) 
코드:
route add -net 172.16.100.0/24 gw 210.222.17.177 dev eth1

(172.16.100.1/24 로 네트워크 대역을 다르게 입력하면 라우팅이 올라가지 않는다.) 

(특정 호스트를 추가) 
코드:
route add -host 172.16.100.100 gw 210.222.17.177 dev eth1


route add -net 172.16.100.100/32 gw 210.222.17.177 dev eth1(될까요?) 
(default 라우팅의 추가) 
코드:
route add default gw 210.222.17.177 dev eth0


같은 네트워크 대역이 있을 경우에는 메트릭이 낮은 룰이 적용된다. 
코드:
route add -net 192.168.1.0/24  gw 211.197.13.1 dev ppp0 metric 1 
route add -net 192.168.1.0/24  gw 211.197.13.1 dev ppp0 metric 3

(메트릭을 적용하지 않을 경우 기본 메트릭은 0 이다.) 


7. 트래픽 분산 

route 를 이용한 분산 
WAN 장치가 ppp0, ppp1이 있을 경우에 
코드:
route add -net 0.0.0.0/2 gw 211.211.211.211 dev ppp0 
route add -net 128.0.0.0/2 gw 222.222.222.222 dev ppp1

이라고 했을 경우에 A 클래스 절반은 ppp0, 나머지 절반은 ppp1으로 나가게 된다. 
(실제로는 더 세부적으로 하겠지만,,) 

route 를 이용한 분산은 특정 대역으로 가는 트랙픽을 보장받고 싶을 때 가능하지만, 아이피대역만을 가지고 트래픽을 분산하는 룰을 정교하게 나누가 힘들며, 비효율적이다. 

ip rule 과 MARK 를 이용한 트래픽 분산 

MARK 는 iptables의 타겟으로 프로토콜, 아이피 대역, 장치, 포트, 타입 등을 정교하게 
구상하여 트래픽을 효과적으로 분산시킬 수 있다. 
구성 순서 
ex) 
WAN1 = ppp0 , gw 111.111.111.111 
WAN2 = ppp1 , gw 222.222.222.222 

1) 각각의 WAN 구간의 table을 추가한다. 
코드:
echo "201       ppp0_Rule"        >> /etc/iproute2/rt_tables 
echo "202       ppp1_Rule"        >> /etc/iproute2/rt_tables

2) table에 MARK를 어떤것으로 할지 정한다.(경험적으로 1 ~ 9 까지 마크가 유효하다) 
코드:
ip rule add fwmark 1 table ppp0_Rule priority 98 
ip rule add fwmark 2 table ppp1_Rule priority 99

## priority 는 숫자가 낮을수록 우선순위가 높다 

마크 확인 
root# ip rule ls 
3) table에 라우팅 룰을 추가한다. 
코드:
ip route add default via 111.111.111.111 dev ppp0 table ppp0_Rule 
ip route add default via 222.222.222.222 dev ppp1 table ppp1_Rule 
ip route show table ppp0_Rule


4) iptables의 mangle 테이블에 MARK를 추가하면 완료 
--아이피 대역을 이용한 분산 
코드:
iptables -t mangle -A PREROUTING -s 192.168.0.0/24 -j MARK --set-mark 1 
iptables -t mangle -A PREROUTING -s 172.16.0.0/16 -j MARK --set-mark 2

( 출발지가 192.168.0.0/24 인것은 ppp0 으로 나가라) 
( 출발지가 172.16.0.0/16 인것은 ppp1 로 나가라) 

-- 포트를 이용한 분산 
코드:
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j MARK --set-mark 1 
iptables -t mangle -A PREROUTING -p tcp --dport 20:21 -j MARK --set-mark 2

(웹서비스에 접속하는 것은 ppp0으로 나가라) 
(ftp서비스에 접속하는 것은 ppp1로 나가라) 

--아이피 대역과 포트를 동시에 분산 
코드:
iptables -t mangle -A PREROUTING -s 192.168.1.0/24 -p tcp --dport 80 -j MARK --set-mark 1 
iptables -t mangle -A PREROUTING -s 192.168.1.0/24 -p tcp --dport 20:21 -j MARK --set-mark 2

(출발지가 192.168.1.0/24 이고 웹서비스에 접속하는 것은 ppp0으로 나가라) 
(출발지가 192.168.1.0/24 이고 ftp서비스에 접속하는 것은 ppp1으로 나가라) 

-- 기타 iptables로 제어할수 있는 옵션들을 모두 활용하여 분산이 가능하다. 
### MARK를 할 경우에 알아두어야 할 점 
-route 보다 ip route 가 우선이다. (즉 MARK가 우선이다.) 
-MARK 표시가 없는 것은 route 에 의해 경로가 결정된다. 
-하나의 패킷에 MARK 가 중복되면, 맨 마지막의 MARK에 의해 경로가 결정된다. 
- MARK를 한뒤 다음 MARK에 걸리지 않게 하고 싶을 경우에는 그 패킷을 
ACCEPT 하면 된다. 
ex) 
코드:
iptables -t mangle -A PREROUTING -s 192.168.0.0/24 -p tcp 80 -j MARK --set-mark 1 
iptables -t mangle -A PREROUTING -s 192.168.0.0/24 -j MARK --set-mark 2

위에서 보면 웹서비스로 가는 패킷은 두 규칙에 모두 적용되기 때문에 결국 마지막 규칙에 의해 ppp2로 나가게 된다. 

그러나, 웹서비스를 이용할 경우 ppp0로 보내고 싶다면? 
코드:
iptables -t mangle -A PREROUTING -s 192.168.0.0/24 -p tcp 80 -j MARK --set-mark 1 
iptables -t mangle -A PREROUTING -s 192.168.0.0/24 -p tcp 80 -j ACCEPT 
iptables -t mangle -A PREROUTING -s 192.168.0.0/24 -j MARK --set-mark 2



출처 : yahon.tistory.com



Trackback 0 Comment 2
  1. 2012.10.25 16:07 address edit & del reply

    비밀댓글입니다

  2. Favicon of https://leeyj7141blog.wordpress.com 챠리 2016.06.01 01:12 address edit & del reply

    와! 잘봣습니다.
    설명도 함께 정말 잘해두셧네요 ㅎㅎ
    mark 이해가 잘 안됏는데 여기서 배우고 갑니다.

2011.07.04 19:09

DNS Port Forwarding con Meterpreter (Spanish)

La entrada de hoy corre a cargo de Borja Merino, ingeniero informático y empleado de Isdefe, al que pueden seguir en su Twitter http://twitter.com/borjamerino. Esperamos que el post les guste tanto como a nosotros.

A diferencia de la versión Pro de Metasploit, una de las limitaciones a la hora de “pivotear” conexiones desde Meterpreter por medio de route es el tipo de herramientas que podemos usar a través del pívot. Esto es debido a que cualquier herramienta que use raw sockets no funcionará a través del túnel, estando limitados a conexiones TCP y UDP que realicen una “conexión completa” (connected sockets). En el caso de Nmap, por ejemplo, implica que únicamente podemos realizar escaneos de tipo TCP connect (-sT) por medio de socks4 y proxychains, pero será inútil utilizar switches como -sS (syn scan), -O (OS detection) o similares. Aunque otra opción es utilizar portforwarding (portfwd) mediante el cual mapear puertos locales con los de la víctima, estamos limitados a conexiones TCP, por lo que esto también reduce opciones a la hora de elegir herramientas que empleen UDP. En nuestro caso lo que haremos será preparar un entorno que nos ayude a “forwardear” peticiones DNS desde herramientas que hagan uso de UDP (nmap, dnsenum, etc) a través de Meterpreter.

Para ello configuraremos un Proxy DNS que intercepte peticiones DNS UDP y las redirija, en su “versión TCP”, al puerto configurado con portfwd. Ya que la mayoría de servidores DNS soportan TCP, no solamente para realizar transferencias de zona, sino para aceptar también queries en el puerto 53 (así lo especifica el protocolo DNS), podremos realizar consultas DNS con prácticamente cualquier herramienta. Lógicamente clientes DNS que empleen o soporten TCP (ej: dig +tcp) no requerirán de dicho Proxy y podrán lanzarse directamente a través de Meterpreter Lo mismo ocurre con clientes DNS que usen UDP y que utilizen la API adecuada, en cuyo caso podrá redirigir paquetes a través de Meterpreter utilizando route.

Partamos del siguiente escenario. Conseguimos una sesión de Meterpreter en el equipo víctima con IP 192.168.100.1/24, y queremos hacer un Reverse Dns Lookup de dicha red preguntando directamente al servidor DNS interno (192.168.100.10) con el objetivo de obtener nombres de máquinas sugerentes a los que posteriormente podamos escalar el ataque. De forma gráfica podemos verlo de la siguiente forma:


Empezaremos configurando nuestro proxy DNS. En nuestro caso usaremos el proxy caché pdnsd por su facilidad de configuración e instalación. Únicamente necesitaremos modificar el fichero /etc/init.d/pdnsd con las siguientes directivas:

global {
        perm_cache=1024;
        cache_dir="/var/cache/pdnsd";
        run_as="pdnsd";
        server_ip = 127.0.0.1; // Use eth0 here if you want to allow other
		               // machines on your network to query pdnsd.
       status_ctl = on;
       paranoid=on;
       query_method=tcp_only; // pdnsd must be compiled with tcp
                              // query support for this to work.
       min_ttl=15m;       // Retain cached entries at least 15 minutes.
       max_ttl=1w;        // One week.
       Timeout=10;        // Global timeout option (10 seconds).

       // Don't enable if you don't recurse yourself, can lead to problems
       // delegation_only="com","net";
}

/* with status_ctl=on and resolvconf installed, this will work out from the box
   this is the recommended setup for mobile machines */
server {
    label="resolvconf";
    ip=127.0.0.1;
    port=7777;
    timeout=4;
    interface=eth0;
    interval=19m;
    purge_cache=off;
}

Tras guardar el fichero actualizamos los cambios en pdnsd mediante:

root@bt:~# pdnsd-ctl config /etc/pdnsd.conf 
Opening socket /var/cache/pdnsd/pdnsd.status
Succeeded

Lo que hemos hecho es configurar un daemon DNS (pdnsd) en 127.0.0.1:53 que escuchará y reenviará peticiones DNS al socket 127.0.0.1:7777, que será donde configuraremos el forwarding con Meterpreter. La directiva query_method=tcp_only obligará a utilizar queries TCP; otras opciones son tcp_udp donde intentaría primero con tcp y en caso de vencer el timeout con udp, udp_tcp y udp_only. El siguiente paso es configurar el port forwarding desde Meterpreter:

meterpreter > portfwd add -l 7777 -L 127.0.0.1 -r 192.168.100.10 -p 53
[*] Local TCP relay created: 127.0.0.1:7777 < -> 192.168.100.10:53
meterpreter > portfwd list
0: 127.0.0.1:7777 -> 192.168.100.10:53

Nos aseguramos que nuestros daemons están escuchando correctamente:

root@bt:~# netstat  -putna | grep ":53\|:7777"
tcp     0    0 127.0.0.1:53          0.0.0.0:*           LISTEN      13717/pdnsd
tcp     0    0 127.0.0.1:7777        0.0.0.0:*           LISTEN      1533/.ruby.bin
udp     0    0 127.0.0.1:53          0.0.0.0:*                       13717/pdnsd
root@bt:~#

Y por último ya podemos lanzar consultas DNS con nmap (list scan) apuntando a localhost:

root@bt:~# nmap -sL 192.168.100.1-254  --dns-servers 127.0.0.1 | grep -i domainowned
Nmap scan report for rat.internal.pro.domainowned.es (192.168.100.1)
Nmap scan report for ftp.pro.domainowned.es (192.168.100.2)
Nmap scan report for felix.internal.pro.domainowned.es (192.168.100.8)
Nmap scan report for dns.internal.pro.domainowned.es (192.168.100.10)
Nmap scan report for calipso.lab.pre.domainowned.es (192.168.100.12)
Nmap scan report for ficheros.internal.pro.domainowned.es (192.168.100.13)
Nmap scan report for repo.lab.pre.domainowned.es (192.168.100.15)

En el caso de no usar –dns-servers tendríamos que apuntar a localhost desde /etc/resolv.conf. También podemos usar otras tools dentro de /pentest/enumeration/dns o directamente realizar consultas a mano con un poco de bash:

root@bt:~# for ip in 192.168.100.{1..254}; do ( host $ip 127.0.0.1) done |
           grep domainowned | cut -d" " -f1,5
1.100.168.192.in-addr.arpa rat.internal.pro.domainowned.es.
2.100.168.192.in-addr.arpa ftp.pro.domainowned.es.
8.100.168.192.in-addr.arpa felix.internal.pro.domainowned.es.
10.100.168.192.in-addr.arpa dns.internal.pro.domainowned.es.
12.100.168.192.in-addr.arpa calipso.lab.pre.domainowned.es.
13.100.168.192.in-addr.arpa ficheros.internal.pro.domainowned.es.

Aunque Metasploit ya contiene módulos y scripts que nos permiten hacer queries DNS (ej: netenum de Carlos Perez) puede que en ciertos entornos, donde necesitamos afinar o ajustar en mayor medida consultas DNS, resulte práctico y rápido implementar dicho proxy con el cual utilizar nuestras propias herramientas.


출처 : http://hi.baidu.com/p3rlish/

Trackback 0 Comment 0
2011.04.24 23:24

방화벽 우회 ssh 터널링 (포트포워딩)

1. 방화벽으로 ssh를 제외한 다른 모든 포트가 막혀있는 경우 ssh 터널링(포트 포워딩) 을 이용하여 해당 서버의 다른 포트로 우회하여 접근하는 방법

 -  로컬 머신에서 다음과 같은 명령으로 방화벽이 설정되어있는 서버로 접속한다.

ssh -L 8080:remoteServer:8181 user@remoteServer

    이 명령은 로컬 8080번 포트를 접속한 서버의 8181번 포트로 포워딩한다
    이후 localhost:8080 번으로 접속하여 해당서버의 8181번 포트로 접근 가능하다

    putty를 사용한다면 다음과 같이 세션 설정에 Source port 를 8080으로 Destination 을 remoteServer:8181로 하고 추가한다. 

* 만일 터미널에서 다음과 같은 에러 메세지와 함께 포트 포워딩이 동작하지 않는다면 /etc/ssh/sshd_config 파일의  AllowTcpForwarding  셋팅이 no 인지 확인한다  (no  로 설정되어있다면 yes로 바꾸도록 한다)

[channel 3: open failed: administratively prohibited: open failed ]




2.방화벽으로 막혀있는 어떤 서버가 우리쪽 일부 IP에게만 접근을 허용했을때 접근이 허용된 서버를 경유하여 접근하는 방법

  - 접근이 허용된 머신에서 다음과 같은 명령으로 해당 포트로의 접근을 방화벽으로 막혀있는 서버의 포트로 redirect 시킨다

ssh -gR 8080:remoteServer:8181 user@localhost (또는 로컬 머신에서 ssh -gR 8080:remoteServer:8181 user@[접근이 허용된 서버] ...)

   이 명령은 로컬포트 8080으로의 접근을 remoteServer 8181번 포트로 redirect 시킨다 ( -g 옵션을 사용하지 않는 경우 외부접근을 허용하지 않고 local 에서의 접근만을 허용하게 된다)

* 만일 -g 옵션을 주었는데도 외부에서 해당 서버의 8080 포트를 이용하여 방화벽으로 막혀있는 서버의 8181번 포트로 접근할 수 없다면 /etc/ssh/sshd_config 파일의 GatewayPorts 옵션이 no 인지 확인한다(디폴트는 no 이다) .. yes로 바꾼다


출처 : schatzt.springnote.com

Trackback 1 Comment 0