1. Chỉ có Console Server là có thể kết nối vào các server trong vùng Core thông qua các port quản lý như: SSH(22), VNC(3389), Telnet và Remote Desktop và một số port đặc biệt khác.
2. Tất cả các máy từ Internet hoặc Local muốn cấu hình chỉnh sửa quản trị các Server trong vùng Core đều phải thông qua Console Server.
3. Đồng thời cho đăng nhập nhiều user một lúc.
4. Mỗi User Được cấp một account riêng để đăng nhập vào Console Server, mỗi account chỉ có thể truy cập đến một Server nhất định. Cho dù có lấy được user và password của server trong vùng Core nhưng không được phép truy cập thì vẫn không vào được.
5. Các thao tác của User trên Console Server đều được log lại (Đăng nhập lúc nào? Thoát ra khi nào? Truy cập đến server nào? Truy cập qua phương thức gì? Truy cập với tài khoản nào? Chạy những lệnh gì? ....)

• Nếu người dùng chỉ dùng SSH để truy cập vào Console server thì có thể log lại như yêu cầu số 5. Nhưng do Console Server có thể truy cập bằng cách là VNC hoặc Remote Desktop over SSH. Chính vì thế giải pháp nào trong trường hợp này?
• Để thoả mãn yêu cầu số 4 thì có giải pháp nào hay không? Hiện tại phần này mình vẫn chưa có ý tưởng
• Nếu dùng giải pháp là triển khai trên Windows Server thì có giải pháp nào thoả mãn các yêu cầu trên hay không

Nếu dùng giải pháp là triển khai trên Windows Server thì có giải pháp nào thoả mãn các yêu cầu trên hay không
 

Nếu người dùng chỉ dùng SSH để truy cập vào Console server thì có thể log lại như yêu cầu số 5. Nhưng do Console Server có thể truy cập bằng cách là VNC hoặc Remote Desktop over SSH. Chính vì thế giải pháp nào trong trường hợp này?  

Nếu dùng giải pháp là triển khai trên Windows Server thì có giải pháp nào thoả mãn các yêu cầu trên hay không
 

Nếu người dùng chỉ dùng SSH để truy cập vào Console server thì có thể log lại như yêu cầu số 5. Nhưng do Console Server có thể truy cập bằng cách là VNC hoặc Remote Desktop over SSH. Chính vì thế giải pháp nào trong trường hợp này?  

---->trong trường hợp trên rất khó để biết được người dùng truy cập vào Console Server trong trường hợp windows server hay sử dụng VNC, Remote Desktop để thực hiện thao tác đối với các server core bên trong. Trừ trường hợp dùng các phần mềm giám sát, video, chụp hình, .... Vì lúc này chúng ta đang sử dụng giao diện đồ hoạ để kết nối.
 

Anh đề nghị là cái console server sẽ là cái Proxy cho SSH Tunneling, tức mọi kết nối vào và ra đều bằng SSH

Về vụ log lại như yêu cầu 5 thì mình cho chạy 1 script (python chẳng hạn) khi user thực hiện đăng nhập, script này làm nhiệm vụ ghi log và làm 1 mớ tác vụ linh tinh gì đó theo yêu cầu

tham khảo:
http://www.linuxquestions.org/questions/linux-general-1/ubuntu-how-to-run-python-script-on-login-352191/
 

Anh muốn hỏi tại sao có SSH rồi mà còn cần telnet?
 

Theo anh thấy, dạng "jump box" này nếu dùng để cung cấp phương tiện SSH vô bên trong các SSH servers trong "core" thì cách tốt nhất là dùng key-based authentication (có passphrase hẳn hòi). Trên mỗi target SSH server bên trong "core", nếu user có account thì drop cái authorized_keys của từng user vô trong thư mục .ssh của user đó cho họ và không cho login bằng password bình thường. Nếu mình không drop cái authorized_keys trong target servers thuộc core thì vô phương đăng nhập.

Với VNC thì khó hơn một chút. Cách tốt nhất là tạo script (read-execute only) để cho phép họ VNC vô một số servers nhất định và ở phía VNC servers cũng kiểm soát nội dung bên trong .vnc để giới hạn cho phép truy cập hay không.

Nếu là anh, anh không cho access trực tiếp VNC mà buộc họ phải VNC xuyên qua SSH tunnel. Nếu dùng key-based authentication cho các SSH servers như trên thì chỉ cần quản lý có 1 chỗ đó là sự hiện diện của "authorized_key" trong ~/.ssh của từng user account. 

xnohat wrote:

Anh đề nghị là cái console server sẽ là cái Proxy cho SSH Tunneling, tức mọi kết nối vào và ra đều bằng SSH

Về vụ log lại như yêu cầu 5 thì mình cho chạy 1 script (python chẳng hạn) khi user thực hiện đăng nhập, script này làm nhiệm vụ ghi log và làm 1 mớ tác vụ linh tinh gì đó theo yêu cầu

tham khảo:
http://www.linuxquestions.org/questions/linux-general-1/ubuntu-how-to-run-python-script-on-login-352191/
 

Em cũng tính là tất cả mọi kết nối ra vào Console server đều thực hiện qua SSH Tunnel.

conmale wrote:

Anh muốn hỏi tại sao có SSH rồi mà còn cần telnet?
 

Bởi vì một số thiệt bị không hỗ trợ SSH nên từ console server đôi lúc cũng cần dùng telnet. Bạn thân em cũng không tán thành việc sử dụng telnet vì nó bảo mật quá yếu.
Anh có tài liệu nào liên quan đến vụ script ghi log này không ạ?

conmale wrote:

Theo anh thấy, dạng "jump box" này nếu dùng để cung cấp phương tiện SSH vô bên trong các SSH servers trong "core" thì cách tốt nhất là dùng key-based authentication (có passphrase hẳn hòi). Trên mỗi target SSH server bên trong "core", nếu user có account thì drop cái authorized_keys của từng user vô trong thư mục .ssh của user đó cho họ và không cho login bằng password bình thường. Nếu mình không drop cái authorized_keys trong target servers thuộc core thì vô phương đăng nhập.

Với VNC thì khó hơn một chút. Cách tốt nhất là tạo script (read-execute only) để cho phép họ VNC vô một số servers nhất định và ở phía VNC servers cũng kiểm soát nội dung bên trong .vnc để giới hạn cho phép truy cập hay không.

Nếu là anh, anh không cho access trực tiếp VNC mà buộc họ phải VNC xuyên qua SSH tunnel. Nếu dùng key-based authentication cho các SSH servers như trên thì chỉ cần quản lý có 1 chỗ đó là sự hiện diện của "authorized_key" trong ~/.ssh của từng user account. 

Cám ơn anh vậy là yêu cầu số 4 thì giải pháp key-based authentication là tốt nhất.
Anh cho em hỏi thêm về phần log lại thao tác ngoài việc dùng script như anh xnohat để cập còn giải pháp nào khác không anh?


- Ky0 -

PS: Khi nào triển khai xong em sẽ viết một tut cho mọi người tham khảo
 

Anh nghĩ em nên tham khảo syslog-ng. Cái này cho phép em centralised trọn bộ logging từ clients đến servers. 

Cách bạn làm ra 1 Console server đó, về mặt bảo mật thì chính cái Console đó là mắt xích quan trọng nhất. Nếu nó share nhiều người dùng (nhiều admin), việc truy vết 1 ai đó vào Console server rồi ghi lại họ đã làm gì khác (ssh hay vnc, terminal vào server khác) sẽ rất khó khăn, tốn kém. Chưa kể nếu Console server bị compromised thì việc nhập mật khẩu xác thực bước kế tiếp vào đó ko ổn tí nào.
Tớ thấy end-to-end là an tâm nhất, tức là chỉ trust vào cái laptop và cái server, mọi thứ trung gian đều ko tin tưởng.
 

Mình chỉ áp dụng cái Console server khi cái kết nối thứ 2 là vật lý. Ví dụ console server có nhiều nối dây serial (com) với router trực tiếp, mình ssh vào console server rồi minicom vào tty nối với router thì mới hợp lý.

...

Mình cũng có các console server nhưng chỉ dùng để kết nối serial/khác với các thiết bị non-IP (ví dụ hệ thống cung cấp điện, hệ thống chữa cháy, hay là router, switch, tổng đài nội bộ), hoặc là dùng IP KVM nối console trực tiếp vào các server. Console server không bao giờ có thể truy cập tới nếu không vào cái private network đó và phải làm sao để phòng khi mạng chính bị đứt vẫn có kênh riêng vào private network hoặc có cổng dial-up vào được, hoặc có kênh 3G riêng. Do DC cách văn phòng làm việc cả mấy chục km ấy chứ, không phải lúc nào cũng chạy tới mà coi được.
 

Về cái mô hình bạn làm ấy, người ta có 1 cái tên gọi là out-of-band remote control hoặc out-of-band management.
Cách mình làm là dựng lên 1 hệ thống private network chỉ sử dụng để quản trị server, độc lập về mặt vật lý với mạng chính (có kênh Internet, VPN gateway riêng, và switch, UPS cấp nguồn... cũng độc lập, tách rời hoàn toàn), và các admin dùng laptop của mình VPN vào mạng private đó trước rồi mới vào được các IP của các server quản trị qua SSH hoặc VNC, RDP. Các máy chủ hầu hết là có 1 management ethernet port riêng cả (dùng để quản lý 1 số phần hardware trước khi boot OS), và server có nhiều ethernet port thì dùng tách riêng 1 interface chỉ để quản trị, phân biệt với các cổng khác chỉ là cung cấp dịch vụ.
 

Ky0 ơi, việc lưu date / time trên "history" của từng shell account thì dễ lắm em:

echo 'export HISTTIMEFORMAT="%d/%m/%y %T "' >> ~/.bash_profile

Ngoài ra, nếu thật sự muốn bảo mật thì áp dụng 2-factors authentication cho SSH. Cái này thì có rất nhiều giải pháp, từ việc dùng google token miễn phí cho đến sử dụng dịch vụ (khả rẻ tiền như http://www.wikidsystems.com/?htf_sshu) hoặc sử dụng USB key (như yubikey)...
 

hello anh Ky0

Vụ này anh triển khai sao rồi ? kết quả mỹ mãn không ?