|
|
bino1810 wrote:
Một cách ngắn gọn:
- sh file.sh tạo tiến trình mới, thực thi trong một "shell environment" mới. Biến EXTIF chỉ tồn tại trong lúc tiến trình chạy. Khi tiến trình kết thúc, EXTIF không tồn tại.
- . file.sh hay là source file.sh đọc và thực thi các câu lệnh từ file.sh trong "shell environment" hiện tại.
À, ra là vậy. Cám ơn anh rất nhiều
|
|
|
SOLVED.
Thay vì dùng sh file.sh thì mình dùng
Code:
thì lại được
mặc dù không hiểu tại sao câu lệnh sh lại không có tác dụng
|
|
|
Mình xin vào thằng vấn đề luôn. Mình đã cố gắng thử gán biến trong file.sh và cho chạy file.sh, nhưng sau đó echo biến thì không có kết quả trả về. Cụ thể là:
Bình thường khi gán biến trên console thì mình gõ
Code:
[root@firewall ~]# EXTIF=`/sbin/route | grep -i 'default' | awk '{print$8}'`
[root@firewall ~]# echo $EXTIF
eth0
OK, câu lệnh hoạt động như mong muốn
Nhưng nếu mình ném câu lệnh gán biến trên vào trong file.sh và chạy
Code:
[root@firewall ~]# sh file.sh
[root@firewall ~]# echo $EXTIF
[root@firewall ~]
echo trả về kết quả là trống hoặc là kết quả cũ của phép gán trước đó (trên console) chứ không phải phép gán trong file.sh
Mình đang dùng CentOS 6.5. Mong được mọi người giúp đỡ về vấn đề này (mình đã chmod +x file.sh)
|
|
|
Đọc trên redhat documentation có cái hình này khá là dễ hiểu. Firewalld là một trong nhiều cách để cấu hình Iptables. Một số ưu điểm có thể nói đến là (mình đọc dịch thôi):
1- Các file cấu hình được lưu trong các file XML => thuận tiện cho chỉnh sửa, backup hay sử dụng như là một template cho các hệ thống firewall khác.
2- Khi cấu hình trong /etc/sysconfig/iptables thì mỗi một thay đổi nhỏ sẽ FLUSH toàn bộ các luật cũ. Trong khi Firewalld thì không, những luật nào bị thay đổi thì mới ảnh hưởng => các kết nối đang tồn tại sẽ không bị disconnect.
3- Firewalld quản lý bằng các zone (như block, drop, public, external, trust...). Các dịch vụ được phép sẽ được cho vào zone cụ thể.
Bạn có thể đọc thêm tại link này
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html
|
|
|
Cái rule đó vẫn đúng vì 1194 nằm trong dải port 1024:65535 nhưng nếu giả dụ có dịch vụ nào chạy port không nằm trong dải 1024:65535 thì sẽ không đúng -> bị block
Hix mình có giúp được gì đâu, toàn nhầm nhọt linh tinh . Bạn add fb mình để tiện liên lạc trao đổi sau này nhé
https://www.facebook.com/tuhoanganh11
|
|
|
EDIT!
sr mod, mình lỡ double post
|
|
|
Voyage146 wrote:
Xin lỗi vì trả lời muộn, mình hơi bận trong thời gian rồi.
2 command đầu mình không nói, vì nó cần thiết để tạo kết nối VPN giữa 2 site. Còn lúc đầu khi mới cấu hình mình cũng dùng các command dưới này để cấu hình cho kết nối VPN:
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A OUTPUT -o tun+ -j ACCEPT
iptables -A FORWARD -o tun+ -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
Nhưng khi thay bằng các command như post trước của mình thì mọi thứ vẫn hoạt động bình thường mặc dù là INPUT DROP (k permit tun+) ?
Mình cũng đang làm về OpenVPN, ae có vấn đề j thì post trong đây luôn nhé.
- Đúng vậy, có lẽ mình hơi hiểu nhầm chút, mình đã thử lại là INPUT -i eth0 cũng như là INPUT -i tun0, không khác nhau. Vì openvpn kết nối với bên ngoài bằng eth0 mà => các gói tin đi vào eth0
=> không có vấn đề gì ở INPUT
- Quay lại vấn đề với OUTPUT của bạn, Hình như câu lệnh này có vấn đề:
-A OUTPUT -o eth0 -p tcp -m state --state NEW,RELATED,ESTABLISHED -m tcp --sport 1024:65535 --dport 1194 -j ACCEPT
Mình nghĩ --sport phải là 1194 chứ nhỉ. Openvpn lắng nghe và trả lời trên port 1194.
Bạn thử bỏ phần --sport 1024:65535 đi, sau đó --dport 1194 xem sao
|
|
|
Voyage146 wrote:
Theo mình nghĩ thì khi host đi từ bên A qua vpn để sử dụng các dịch vụ ở sau server B (do các server sau B cung cấp) thì chỉ luật trong FORWARD điều khiển các luồng traffic này thôi chứ nhỉ? Vậy tại sao khi mình chuyển OUTPUT từ ACCEPT sang DROP thì kết nối lại mất từ cả 2 bên??? Rất mong ae giúp mình lần nữa, mình xin cảm ơn nhiều
Mình cũng vừa tự nghịch cái lab như bạn. Tạm hiểu B như là một con firewall và đóng vai trò như một router cho "dải mạng sau B". Khi bạn cài openvpn trên B, thì sẽ có một NIC tun0 được tạo trên B
Bên A sử dụng VPN sẽ được VPN cấp dải mạng 10.8.0.x (mặc định và bạn có thể thay đổi trong cấu hình openvpn) để truyền gói tin vào tun0 của B. Vì thế bạn cần phải viết luật INPUT và OUTPUT các packet vào NIC này + FORWARD từ tun0 vào đến dải mạng "đằng sau B" nếu cần.
Ví dụ:
Code:
iptables -A INPUT -i $EXTIF -s $EXTNET -p udp --dport 1723 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $EXTIF -d $EXTNET -p udp --sport 1723 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i tun0 -s $VPNNET -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o tun0 -d $VPNNET -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i tun0 -s $VPNNET -o $INTIF -d $INTNET -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $INTIF -s $INTNET -o tun0 -d $VPNNET -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
trong đó:
$VPNNET Dải mạng mà VPN server của B cung cấp cho bên A
$EXTIF Interface ra internet của B
$EXTNET Dải mạng bên ngoài local network
$INTIF Interface của B đi vào mạng bên trong
tun0 Interface được tạo bởi openvpn
Dòng lệnh 1,2 là mở port cho VPN
Dòng lệnh 3,4 là cho phép mọi gọi tin đi từ VPNNET đi vào,ra Card mạng tun0 đều được chấp nhận
Dòng lệnh 5,6 Forward gói tin từ VPNNET đi vào "dải mạng sau B" và ngược lại (trường hợp dải mạng B và dải mạng sau B khác nhau. Nếu cùng dải mạng thì không cần)
Giải thích: Các gói tin tại A sẽ đi trong tunnel giữa được tạo ra bới VPN clients và tun0. Nếu bạn không thiết lập INPUT và OUTPUT chain cho tun0 thì mặc định nó sẽ chặn hết
|
|
|
Sau vài tuần tự tìm hiểu thì mình cũng rút ra được một mẹo nhỏ là mỗi khi có một vấn đề gì về các policy gì thì mình toàn dò lỗi thiếu trong từng chain bằng cách
ví dụ:
-P INPUT DROP
-P OUTPUT DROP
-P FORWARD DROP
(và một đống luật INPUT, OUTPUT, FORWARD, POSTROUTING, PREROUTING... đằng sau đó)
=> kết quả không ping được internet chả hạn. Mình liền thử ACCEPT cho 1 trong 3 chain trên. nếu chain nào bật ACCEPT mà ping được kết nối mạng => mình thiếu luật chain đó => khắc phục
mình hay dùng cách này cho firewall iptables mình làm lab ở nhà.
|
|
|
qwerty13 wrote:
Mình cũng nghĩ là phải -o -s. Mình đã đọc bài này, nhưng trước đấy có tự viết 1 cái script kiểu thế này nên lúc đọc bài phần này qua loa k để ý lắm, chỉ để ý mấy ý chính
Em mới tóm đc cái Cleaup Rules ở Case 3 /hvaonline/posts/list/25676.html. Có lẽ cái ở case 1 sai sót.
Code:
88 $IPT -A OUTPUT -o $EXTIF -j LOG --log-prefix "BAD_OUTPUTS: "
89 $IPT -A OUTPUT -o $EXTIF -j DROP
|
|
|
Em đang nghiền ngẫm iptables trong phòng đọc thì có 1 vấn đề thắc mắc sau khi đọc xong mà cần sự giúp đỡ của mọi người ạ: /hvaonline/readingRoom/item/413.html
Bài 1: Ở Cleanup Rules cho chain OUTPUT
Code:
14. $IPT -A OUTPUT -i $IF -d $IP -m limit --limit 1/s -j LOG --log-level 5 --log-prefix "BAD_OUTPUT: "
15. $IPT -A OUTPUT -o $IF -d $IP-j DROP
em nghĩ là ở phần -i và -d phải thay lại là -o -s đúng không ạ? Vì em hiểu là chain OUTPUT luôn(thường?!) sử dụng -o -s
Nếu cứ dịch đoạn 14 mà không thay đổi thì em hiểu là: tất cả mọi packet ĐI RA (-i ?!?!) IF có địa chỉ ĐÍCH(?!) là IP sẽ bị log... <-- như thế thì em thấy hơi bất hợp lý trong trường hợp này (IP là địa chỉ của chính máy đơn chạy iptables này).
Do mới tìm hiểu nên còn nông cạn mong mọi người chỉ dạy
|
|
|
Đã tìm ra vấn đề. Forwarders đến gateway hoặc DNS public. Cộng với tắt dnssec
options {
# listen-on port 53 { 192.168.1.5; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { localhost;192.168.1.0/24; };
allow-query-cache {192.168.1.0/24;localhost;};
recursion yes;
forwarders {192.168.1.1;8.8.8.8;};
dnssec-enable no;
dnssec-validation no;
dnssec-lookaside auto;
Cám ơn bác quangteospk đã quan tâm giúp đỡ ạ. Cám ơn mọi người
|
|
|
quangteospk wrote:
E rằng là sao nhỉ, sao bạn ko thử lookup domain đó và gửi kết quả lên đây:
Cấu hình của bạn post thiếu file phân giải nghịch rồi. Thêm nữa trong cấu hình của bạn có đoạn
Code:
forwarders {8.8.8.8;8.8.4.4;};
Nghĩa là khi các máy client của bạn tìm tới 192.168.1.5 để phân giải, nếu ko tìm thấy nó sẽ nhờ một DNS server khác ở bên ngoài tìm kiếm dùm, ở đây là DNS của Google. Thế nên có thể nó trả về một ip public
Dạ cám ơn bác đã giúp đỡ cho câu hỏi của em
- Bình thường em cấu hình thì không có mấy dòng forwarders đó đâu ạ. Và khi đó thì mọi thứ OK. NHƯNG Client sẽ không kết nối được vào được web or ping ra internet (Client nhận DHCP như em đã nói ở post 1 và đã tắt IPTABLES)
Nếu thêm mấy dòng forwarders đó thì nó không trả về địa chỉ 192.168.1.5 nữa ạ. Mà trả về
C:\Users\NyHaJ>nslookup server.com
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.1.5
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out
- Dạ do file phân giải ngược em không khác gì nhiều ngoài thêm 2 dòng PTR nên em không post ở trên. Và nó đây ạ
$TTL 1D
@ IN SOA root.server.com. server.com. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
NS server.com.
A 192.168.1.5
www CNAME server.com.
www.server.com A 192.168.1.5
mail A 192.168.1.5
@ MX 10 mail
5 PTR server.com.
5 PTR www.server.com.
|
|
|
Hiện tại em đang tìm hiểu về DNS. với cấu hình đã làm như sau:
DHCP: 192.168.1.10 ->20
option subnet-mask 255.255.255.0
option domain-name "server.com";
option domain-name-server 192.168.1.5;
option routers 192.168.1.1;
*(em không muốn thêm dns 8.8.8.8)*
DNS: 2 file zone thuận và zone nghịch (type master) chỉ phân giải tên miền server.com và www.server.com về 192.168.1.5.
Các bước ở trên thì hoàn toàn không gặp vấn đề gì (ping client ->server hay nslookup server.com OK hết)
Nhưng chẳng là em muốn các máy Clients trong domain chuyển các queries đến DNS server.com (192.168.1.5) và DNS này sẽ queries tới DNS ở trên mạng trả về các record cho Clients => Clients vào được mạng.
Em đã tìm hiểu về type forward ở zone nhưng em e rằng nếu làm vậy khi nslookup server.com nó sẽ trả về địa chỉ IP public chứ không trả về 192.168.1.5.
Và trong thực tế thì mọi người sẽ cấu hình DNS này như thế nào cho công ty để đáp ứng nhu cầu này ạ. Do em tự học nên thiếu sót thực tế nhiều về CentOS
Ở dưới đây là cấu hình DNS của em.
options {
forwarders {8.8.8.8;8.8.4.4;};
listen-on port 53 { 192.168.1.5; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { 192.168.1.0/24; };
recursion yes;
zone "server.com" IN {
type master;
file "internal.f";
allow-update { none; };
};
zone "1.168.192.in-addr.arpa" IN {
type master;
file "internal.r";
allow-update { none; };
};
$TTL 1D
@ IN SOA root.server.com. server.com. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
NS server.com.
A 192.168.1.5
www CNAME server.com.
www.server.com A 192.168.1.5
mail A 192.168.1.5
@ MX 10 mail
*Đã tắt iptables*
|
|
|
edit!! mạng em bị lag nên bi post trùng sr mod
|
|
|
Dạ h thì em hiểu ra vấn đề rồi ạ =.=.
Option hide unreadable = yes -> hệ thống sẽ hide các file/folder nằm trong folder share mà người dùng không có quyền chứ không có tác dụng hide folder share gốc đó.
Option browseable = no -> hide folder tuyệt đối không cần biết có quyền truy cập hay không.
vậy nên thiết nghĩ để bảo mật cho dữ liệu thì tốt nhất là xây dựng cấu trúc share folder theo kiểu.
_ Nên để browseable =no cho thư mục dulieu. dulieu là folder gốc để chứa toàn bộ folder share cho các group khác. Kết hợp với option hide unreadable =yes thì các folder không thuộc group nào sẽ bị hide đối với group đó, chỉ group có quyền hạn thì mới nhìn thấy được.
_Khi người dùng muốn vào dữ liệu chung thì phải gõ đầy đủ : //server/dulieu thay vì //server ( sẽ không thấy gì ngoài máy in).
Dạ, đây là cách nghĩ của em. Không biết là liệu có ổn thoả không. Nhưng để tất cả vào 1 folder gốc. Lỡ có chuyện gì cũng méo mồm =.='. Liệu chăng có nên mount một số folder vào folder dulieu hoặc sự dụng liên kết mềm cho các folder ? Có ai có kinh nghiệm tư vấn cho em được không ạ
|
|
|
Dạ chẳng là em đang học về linux và đang làm lab về samba. Lab em tự nghĩ ra với trường hợp sau
_Share folder "dulieu" chỉ cho group nhanvien có quyền truy cập. Add user nhanvien1 vào group nhanvien
và ngoài ra còn 1 user guest.
_H nếu em login bằng user guest nó sẽ hiện cả folder "dulieu" mặc dù không access vào được. Giờ em muốn hide không cho cái guest không nhìn thấy folder "dulieu" kia thì phải làm ntn ạ.
Em đã search google nhiều phương án nhưng vẫn không được.
[du lieu chung]
comment= du lieu chung
path=/dulieu
guest ok=no
writable =yes
browseable =no
create mode =0770
directory mode = 0770
share modes= Yes
valid users=@nhanvien
-> hide luôn cả folder "dulieu" với user nhanvien1
hoặc
[du lieu chung]
comment= du lieu chung
path=/dulieu
guest ok=no
writable =yes
hide unreadable =yes
create mode =0770
directory mode = 0770
share modes= Yes
valid users=@nhanvien
=> không có tác dụng =.=, em thiết lập các option sai?
mọi người có thể giúp em được không ạ . Em xin cám ơn trước
|
|