1. Nắm vững giao thức mạng: Cần nắm vững TCP/IP suite và tính chất + đặc điểm của gói tin ở mỗi tầng
2. Nắm vững hệ điều hành và cơ chế vận hành của hệ thống mình đang bảo vệ
3. Có khả năng đọc logs và phân tích các biến cố xảy ra trên các dạng logs của hệ thống mình muốn bảo vệ
4. Có khả năng sniff packets và phân tích packets
5. Nắm vững ứng dụng firewall mình đang dùng
Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts
Wednesday, March 21, 2012
Sunday, January 1, 2012
Two-factor authentication through Windows Server 2008 NPS
http://www.networkworld.com/news/2010/050710-two-factor-authentication-through-windows-server.html?page=2
Two-factor SSH authentication via Google secures Linux logins
Takeaway: Vincent Danen details the steps of setting up Google two-factor authentication for SSH.
When Google introduced two-factor authentication for the Google and Google Apps accounts, they also created a pluggable authentication module (PAM) for Linux. This is great news for people running Linux servers who want to protect their remotely-accessible SSH accounts with two-factor authentication. For free.
Two-factor authentication is where you authenticate to a service with two pieces of information: one you know, and one you don’t. The information you know is your password (which can be stolen) while the information you don’t know is a randomly-generated PIN number that changes every 60 seconds. So even if your password is stolen or discovered, unless an attacker has the means to get the right PIN (tied to a hardware device), they cannot log into the protected service.
Google has created the Google Authenticator application for iPhone, Android, and Blackberry — effectively turning your phone into your hardware token device. Before you can make use of two-factor authentication to secure your Linux logins, you will need to enable it in your Google account (I also wrote a tip on setting up Google two-factor authentication for users of Mac/iPhone).
Once two-factor authentication is enabled and working with your Google or Google Apps account, you can begin setting up the same for your Linux server. To do so, you will need to download and compile the PAM module for your system. The examples here will be based on Fedora 14, but it should be easy enough to figure out the equivalents for whatever distribution you happen to be using. It also assumes you have sudo writes to run anything as root; if that is not the case, su to root to run those commands (as root) that are prefixed with sudo. You will need mercurial installed to initially check out the code.
$ sudo yum install pam-devel
$ hg clone https://google-authenticator.googlecode.com/hg/ google-authenticator/
$ cd google-authenticator/libpam/
$ make
$ sudo make install
$ sudo vim /etc/pam.d/sshd
Once the PAM module and the command-line google-authenticator application are installed, you need to edit the /etc/pam.d/sshd file to add the module, so it may end up looking like:
auth required pam_sepermit.so
auth required pam_google_authenticator.so
auth include password-auth
This sets up two-factor authentication for SSH. It is also possible to do the same for gdm, requiring the use of two-factor authentication to log in locally.
When that is done, as the user that you want to require two-factor authentication for, run the google-authenticator application, which will create a new secret key in your home directory:
% google-authenticator
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/user@server%3Fsecret%3DSAEP64T5VZAVWAFB
Your new secret key is: SAEP64T5VZAVWAFB
Your verification code is 376046
Your emergency scratch codes are:
67868696
26247332
54815527
54336661
71083816
Do you want me to update your "~/.google_authenticator" file (y/n) y
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) n
If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y
In your browser, load the URL noted above; it will show a QRCode that you can scan into your phone using the Google Authenticator application for iPhone, Android, or Blackberry. If you already have a Google Authenticator token being generated on your phone, you can add a new one and it will display them both (and distinguish them by name).
One quick tip: time is _very_ important, so the server you are logging into should have an NTP client installed in order to keep the time accurate. Keep an eye on this; if you are having trouble you may have to open the window size as noted by google-authenticator.
You will also need to edit /etc/ssh/sshd_config to enable “ChallengeResponseAuthentication” and “UsePAM” (set them both to “yes”).
Restart sshd after making any changes to the file.
When this is done, try logging into the system via SSH:
% ssh server
Verification code:
Password:
Last login: Tue May 10 11:54:21 2011 from client.example.com
You must provide the verification code as presented by your phone in order to log in. Even if the password is known, without the verification code, the login will fail. Also note that you will be unable to use this if you use ssh private/public keys as the two are mutually exclusive (key-based logins get a passphrase prompt client-side and never provide a password to the server).
Setting up two-factor authentication for SSH is surprisingly simple, thanks to Google. It only takes a few minutes to set up, the infrastructure and tools are free, and the security gains are great.
http://www.mnxsolutions.com/security/two-factor-ssh-with-google-authenticator.html
When Google introduced two-factor authentication for the Google and Google Apps accounts, they also created a pluggable authentication module (PAM) for Linux. This is great news for people running Linux servers who want to protect their remotely-accessible SSH accounts with two-factor authentication. For free.
Two-factor authentication is where you authenticate to a service with two pieces of information: one you know, and one you don’t. The information you know is your password (which can be stolen) while the information you don’t know is a randomly-generated PIN number that changes every 60 seconds. So even if your password is stolen or discovered, unless an attacker has the means to get the right PIN (tied to a hardware device), they cannot log into the protected service.
Google has created the Google Authenticator application for iPhone, Android, and Blackberry — effectively turning your phone into your hardware token device. Before you can make use of two-factor authentication to secure your Linux logins, you will need to enable it in your Google account (I also wrote a tip on setting up Google two-factor authentication for users of Mac/iPhone).
Once two-factor authentication is enabled and working with your Google or Google Apps account, you can begin setting up the same for your Linux server. To do so, you will need to download and compile the PAM module for your system. The examples here will be based on Fedora 14, but it should be easy enough to figure out the equivalents for whatever distribution you happen to be using. It also assumes you have sudo writes to run anything as root; if that is not the case, su to root to run those commands (as root) that are prefixed with sudo. You will need mercurial installed to initially check out the code.
$ sudo yum install pam-devel
$ hg clone https://google-authenticator.googlecode.com/hg/ google-authenticator/
$ cd google-authenticator/libpam/
$ make
$ sudo make install
$ sudo vim /etc/pam.d/sshd
Once the PAM module and the command-line google-authenticator application are installed, you need to edit the /etc/pam.d/sshd file to add the module, so it may end up looking like:
auth required pam_sepermit.so
auth required pam_google_authenticator.so
auth include password-auth
This sets up two-factor authentication for SSH. It is also possible to do the same for gdm, requiring the use of two-factor authentication to log in locally.
When that is done, as the user that you want to require two-factor authentication for, run the google-authenticator application, which will create a new secret key in your home directory:
% google-authenticator
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/user@server%3Fsecret%3DSAEP64T5VZAVWAFB
Your new secret key is: SAEP64T5VZAVWAFB
Your verification code is 376046
Your emergency scratch codes are:
67868696
26247332
54815527
54336661
71083816
Do you want me to update your "~/.google_authenticator" file (y/n) y
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) n
If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y
In your browser, load the URL noted above; it will show a QRCode that you can scan into your phone using the Google Authenticator application for iPhone, Android, or Blackberry. If you already have a Google Authenticator token being generated on your phone, you can add a new one and it will display them both (and distinguish them by name).
One quick tip: time is _very_ important, so the server you are logging into should have an NTP client installed in order to keep the time accurate. Keep an eye on this; if you are having trouble you may have to open the window size as noted by google-authenticator.
You will also need to edit /etc/ssh/sshd_config to enable “ChallengeResponseAuthentication” and “UsePAM” (set them both to “yes”).
Restart sshd after making any changes to the file.
When this is done, try logging into the system via SSH:
% ssh server
Verification code:
Password:
Last login: Tue May 10 11:54:21 2011 from client.example.com
You must provide the verification code as presented by your phone in order to log in. Even if the password is known, without the verification code, the login will fail. Also note that you will be unable to use this if you use ssh private/public keys as the two are mutually exclusive (key-based logins get a passphrase prompt client-side and never provide a password to the server).
Setting up two-factor authentication for SSH is surprisingly simple, thanks to Google. It only takes a few minutes to set up, the infrastructure and tools are free, and the security gains are great.
http://www.mnxsolutions.com/security/two-factor-ssh-with-google-authenticator.html
Thursday, March 17, 2011
Networking question for core security guys
Hi Friends ,
Here i am publishing the networking questions which are asked by interviewer for Core security peoples .
1)How much you are rating your self in networking out of 10.?
2)Which models of Routers and Switches you handled ?
3)What is RIP , EIGRP , OSPF ?
4)What is Static and Dynamic routing ?
5)Why we create vlans?
6)How you troubleshoot the vlan problem ?
8)How you make it up down port status to up in switch ?
9)What is access list give the example of both standard and extended access list .
10)How you monitor ISP link in router ?
11)How to see the interface status in router and switches ?
12)How to take backup of router and switches configurations?
13)what is difference between SSH and Telnet ?
14)In which layer ICMP works??
15)What is private and public IP shema ?
16)What is span and spanning tree in Switches ?
17)Do you know about MPLS ?
18)What is the latest IOS of your router and swithces ?
19)How you can save the configuration of Routers and Switches ?
20)What is 802.1q ?
Here i am publishing the networking questions which are asked by interviewer for Core security peoples .
1)How much you are rating your self in networking out of 10.?
2)Which models of Routers and Switches you handled ?
3)What is RIP , EIGRP , OSPF ?
4)What is Static and Dynamic routing ?
5)Why we create vlans?
6)How you troubleshoot the vlan problem ?
8)How you make it up down port status to up in switch ?
9)What is access list give the example of both standard and extended access list .
10)How you monitor ISP link in router ?
11)How to see the interface status in router and switches ?
12)How to take backup of router and switches configurations?
13)what is difference between SSH and Telnet ?
14)In which layer ICMP works??
15)What is private and public IP shema ?
16)What is span and spanning tree in Switches ?
17)Do you know about MPLS ?
18)What is the latest IOS of your router and swithces ?
19)How you can save the configuration of Routers and Switches ?
20)What is 802.1q ?
Sunday, February 13, 2011
Tuesday, February 1, 2011
How Not to Respond to a Security Incident
Finding out that your organization's computer defenses has been breached is a stressful experience. Many are unprepared to deal with such situations, and some have a false sense of security as the result of impractical incident response plans.
Having read about the recent PlentyofFish.com security incident, as described by its founder and a more measured perspective from Brian Krebs, I was inspired to create this short list of what not to do when responding to a security incident:
- Don't drive the incident response (IR) team to work for several days without sleep. People's ability to conduct cognitive tasks is severely diminished when they are sleep-deprived. You may need to pull a one-nighter initially, but after that, stagger people's response tasks so they can get some rest.
- Don't make rush decisions when deciding upon the initial incident response steps. It is OK to take some time to assess the situation before taking action to avoid making mistakes. Of course, you need to balance this with waiting too long before making decisions regarding the next steps.
- Don't immediately attribute the source of the breach to people, companies or countries without conducting a thorough investigation. In particular, don't assume that the entity who notified you of the breach of a vulnerable condition is the entity responsible for the incident.
- Don't attempt to hire the entity who notified you of the breach to assist with incident response, unless there's truly no one else qualified for the job. They might not be responsible for the breach, but it's best to control the situation where you might accuse them of extortion. Also, there's no reason to encourage ambulance-chasing practices.
For more recommendations on what not to do when someone reports an incident, as well as for tips on what to avoid doing when reporting an incident, see our earlier diary Incident Reporting - Liston's "How-To" Guide.
In addition, here are a few Emergency Incident Response steps from Mandiant, which are a good starting point for responding to a security incident. I also put together a few incident response cheat sheets:
- Initial Security Incident Questionnaire for Responders
- Network DDoS Incident Response Cheat Sheet
- Security Incident Survey Cheat Sheet for Server Administrators
- Critical Log Review Checklist for Security Incidents
-- Lenny Zeltser http://blog.zeltser.com/
Friday, January 21, 2011
Phân tích DDOS Vietnamnet
Tối hôm qua tớ ngồi thử nghiệm thêm VNN ở một góc độ khác nhằm phản biện khía cạnh băng thông bị bão hoà thì thấy có vài điểm lý thú sau:
- Thử traceroute từ máy của tớ đến vietnamnet.vn thì thấy:
Code:
Chứng tỏ packets đi xuyên qua các hops không quá chậm.
Thử traceroute từ Đức về VN:
Code:
thì thấy packets đi xuyên các hops càng nhanh nữa.
Thử httpwatch để duyệt vietnamnet.vn thì lại thấy:
Điều này chứng tỏ:
- Cú GET đầu tiên đi đến www.vietnamnet.vn chỉ mất có 0.042 giây thì đầu bên khia nhận request và cho request này redirect đến vietnamnet.vn. Điều này chứng tỏ băng thông không hề bị nghẽn mà trái lại đường đi vô www.vietnamnet.vn rất nhanh.
- Giai đoạn redirection từ www.vietnamnet.vn đến vietnamnet.vn cho đến khi response về lại trình duyệt của tớ mất 6.449 giây. Chứng tỏ sự trễ nãi này xảy ra ở khoảng "response" (đi ra) chớ không phải nằm ở khoảng "request" (đi vô).
- Sau khi redirect đến vietnamnet.vn request này lại tiếp tục được redirect đến /vn/index.html (thuộc vietnamnet.vn) và mất thêm 2.143 giây nữa và tệ nhất là chỉ redirect đến một trang index.html http://vietnamnet.vn/vn/index.html) và response về trình duyệt mất đến 40.536 giây.
Qua những biểu hiện trên tớ tin chắc vnn không bị bão hoà băng thông bằng chứng là request đi vô vẫn cực nhanh. Chỉ có response đi ra cực chậm. Nến băng thông bị bão hoà thì ra hay vô cũng đều chậm. Dấu hiệu cho thấy ở đây là dịch vụ web bị nghẽn và không kịp phục vụ người truy cập.
Nếu thử "dig" thì thấy vietnamnet.vn có 2 "A" records:
và www.vietnamnet.vn lại chỉ có 1 "A" record mà thôi:
117.103.197.249 thì thuộc VTC (trong mạng vnnnic), còn 222.255.122.157 thì thuộc vinagame (trong mạng vnpt).
Xét đoạn httpwatch ở trên thì thấy:
- Nếu truy cập với www.vietnamnet.vn (117.103.197.249) thì sẽ được redirect về vietnamnet.vn (117.103.197.249 và 222.255.122.157) theo dạng DNS round robin.
- Nếu thực sự redirect từ 117.103.197.249 về 222.255.122.157 thì hữu lý (vì cho nó đi qua một mạng khác để share load) nhưng redirect từ 117.103.197.249 về lại chính 117.103.197.249 thì hơi phí vì dịch vụ web phải tốn thêm tài nguyên để xử lý thêm một cái redirection.
- Nếu truy cập trực tiếp tới vietnamnet.vn (222.255.122.157) thì không xảy ra redirection từ IP này sang IP khác nữa mà lại có thêm một lần redirection đến /vn/index.html ngay chính dịch vụ trên vietnamnet.vn, từ context "/" sang context "/vn". Xét về mặt tài nguyên thì dịch vụ web lại tiêu tốn tài nguyên để xử lý thêm một lần redirection. Có lẽ admin muốn redirect đến một trang static html để giảm thiểu hao tổn tài nguyên từ những truy cập trực tiếp đến các trang động (dynamic pages) tương tác trực tiếp đến CSDL nhưng thật sự redirection kiểu này ở tình trạng bị DDoS nặng nề thì không hữu hiệu rồi.
Tớ cũng thử "fire off" hơn 1 chục request liên tục trong 1 giây và thấy hệ thống vietnamnet responded y hệt như nhau. Các requests của tớ vẫn đến vietnamnet.vn và vẫn được redirect y hệt như trên. Điều này chứng tỏ hình như vietnamnet không có cơ chế "packet rating" (hoặc request rating) mà tớ đã đề cập ở bài trước. Nói một cách khác, dường như vietnamnet chìa lưng ra cho DDoS đập thì phải
.
- Thử traceroute từ máy của tớ đến vietnamnet.vn thì thấy:
Code:
conmale$ traceroute vietnamnet.vnconmale-hva
Chứng tỏ packets đi xuyên qua các hops không quá chậm.
Thử traceroute từ Đức về VN:
Code:
[geek@germany ~]$ traceroute vietnamnet.vn
thì thấy packets đi xuyên các hops càng nhanh nữa.
Thử httpwatch để duyệt vietnamnet.vn thì lại thấy:
13:06:39.771 0.042 380 0 GET null Redirect http://www.vietnamnet.vn/
13:06:40.278 6.449 427 182 GET 302 Redirect to: http://vietnamnet.vn http://www.vietnamnet.vn/
13:06:46.732 2.143 458 406 GET 302 Redirect to: /vn/index.html http://vietnamnet.vn/
13:06:48.882 40.536 436 19 GET 200 text/html http://vietnamnet.vn/vn/index.html
13:07:29.473 0.033 357 (1406) GET (Cache) image/x-icon http://vietnamnet.vn/favicon.ico
Điều này chứng tỏ:
- Cú GET đầu tiên đi đến www.vietnamnet.vn chỉ mất có 0.042 giây thì đầu bên khia nhận request và cho request này redirect đến vietnamnet.vn. Điều này chứng tỏ băng thông không hề bị nghẽn mà trái lại đường đi vô www.vietnamnet.vn rất nhanh.
- Giai đoạn redirection từ www.vietnamnet.vn đến vietnamnet.vn cho đến khi response về lại trình duyệt của tớ mất 6.449 giây. Chứng tỏ sự trễ nãi này xảy ra ở khoảng "response" (đi ra) chớ không phải nằm ở khoảng "request" (đi vô).
- Sau khi redirect đến vietnamnet.vn request này lại tiếp tục được redirect đến /vn/index.html (thuộc vietnamnet.vn) và mất thêm 2.143 giây nữa và tệ nhất là chỉ redirect đến một trang index.html http://vietnamnet.vn/vn/index.html) và response về trình duyệt mất đến 40.536 giây.
Qua những biểu hiện trên tớ tin chắc vnn không bị bão hoà băng thông bằng chứng là request đi vô vẫn cực nhanh. Chỉ có response đi ra cực chậm. Nến băng thông bị bão hoà thì ra hay vô cũng đều chậm. Dấu hiệu cho thấy ở đây là dịch vụ web bị nghẽn và không kịp phục vụ người truy cập.
Nếu thử "dig" thì thấy vietnamnet.vn có 2 "A" records:
conmale$ dig a vietnamnet.vn
; <<>> DiG 9.6.0-myBuild <<>> a vietnamnet.vn
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7119 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;vietnamnet.vn. IN A ;; ANSWER SECTION: vietnamnet.vn. 3600 IN A 222.255.122.157
vietnamnet.vn. 3600 IN A 117.103.197.249
;; Query time: 659 msec
;; SERVER: 139.130.4.4#53(139.130.4.4)
;; WHEN: Thu Jan 20 08:45:16 2011
;; MSG SIZE rcvd: 63
và www.vietnamnet.vn lại chỉ có 1 "A" record mà thôi:
conmale$ dig a www.vietnamnet.vn
; <<>> DiG 9.6.0-myBuild <<>> a www.vietnamnet.vn
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61465 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.vietnamnet.vn. IN A ;; ANSWER SECTION: www.vietnamnet.vn. 3600 IN A 117.103.197.249
;; Query time: 499 msec
;; SERVER: 139.130.4.4#53(139.130.4.4)
;; WHEN: Thu Jan 20 08:45:24 2011
;; MSG SIZE rcvd: 51
117.103.197.249 thì thuộc VTC (trong mạng vnnnic), còn 222.255.122.157 thì thuộc vinagame (trong mạng vnpt).
Xét đoạn httpwatch ở trên thì thấy:
- Nếu truy cập với www.vietnamnet.vn (117.103.197.249) thì sẽ được redirect về vietnamnet.vn (117.103.197.249 và 222.255.122.157) theo dạng DNS round robin.
- Nếu thực sự redirect từ 117.103.197.249 về 222.255.122.157 thì hữu lý (vì cho nó đi qua một mạng khác để share load) nhưng redirect từ 117.103.197.249 về lại chính 117.103.197.249 thì hơi phí vì dịch vụ web phải tốn thêm tài nguyên để xử lý thêm một cái redirection.
- Nếu truy cập trực tiếp tới vietnamnet.vn (222.255.122.157) thì không xảy ra redirection từ IP này sang IP khác nữa mà lại có thêm một lần redirection đến /vn/index.html ngay chính dịch vụ trên vietnamnet.vn, từ context "/" sang context "/vn". Xét về mặt tài nguyên thì dịch vụ web lại tiêu tốn tài nguyên để xử lý thêm một lần redirection. Có lẽ admin muốn redirect đến một trang static html để giảm thiểu hao tổn tài nguyên từ những truy cập trực tiếp đến các trang động (dynamic pages) tương tác trực tiếp đến CSDL nhưng thật sự redirection kiểu này ở tình trạng bị DDoS nặng nề thì không hữu hiệu rồi.
Tớ cũng thử "fire off" hơn 1 chục request liên tục trong 1 giây và thấy hệ thống vietnamnet responded y hệt như nhau. Các requests của tớ vẫn đến vietnamnet.vn và vẫn được redirect y hệt như trên. Điều này chứng tỏ hình như vietnamnet không có cơ chế "packet rating" (hoặc request rating) mà tớ đã đề cập ở bài trước. Nói một cách khác, dường như vietnamnet chìa lưng ra cho DDoS đập thì phải
.Monday, January 10, 2011
Load Balancing Algorithms
| High Performance Routing for Every Application |
Peplink's load balancing algorithms help you easily fine-tune how traffic is distributed across connections. Each deployment has a unique setup, and Peplink's enterprise grade load balancing features can fulfill all of your special requirements. Create your own rule with the following algorithms and you can sit back and enjoy the high performance routing that Peplink brings to you.
Weighted Balance
Assign more traffic to a faster link or less traffic to a connection with a bandwidth cap.
- Set a weight on the scale for each connection and outgoing traffic will be proportionally distributed according to the specified ratio.
Priority
Route traffic to your preferred link as long as it's available.
- Arrange the connection priority order, and traffic will be routed through the healthy link that has the highest priority in the list. Lower priority links will only be used if the current connection fails.
Overflow
Prevent traffic flow from slowing down when the connection runs out of available bandwidth.
- Drag and drop to arrange the connection overflow order and the highest priority link will route traffic as long as it has not been congested. Once it saturates, the lower priority links will start routing traffic.
Persistence
Eliminate session termination issue for HTTPS, E-banking, and other secure websites.
- Specify a traffic type and it will be routed through the same connection persistently based on its source and/or destination IP addresses. Traffic will keep routing on the same connection until the session ends.
Least Used
Help you choose the better connection with more free bandwidth.
- Traffic will be directed to the link with the most available bandwidth among the selected connections.
Lowest Latency
Give you the fastest response time when using applications like online gaming.
- Traffic will be assigned to the link with the lowest latency time among the selected connections.
Enforced
Restrict outbound traffic to a particular connection.
- Select a connection and the specified traffic type will be routed through it at all times, whether the link is up or down.
- For scenarios like accessing a server that only allows users from a specific IP.
Tuesday, December 28, 2010
Xác định IP trên Log Server
Giả sử log của Apache thế này:
127.0.0.1 - anonymous [25/Nov/2010:21:58:36 +0700] "GET / HTTP/1.0" 200 11 "-" "check_http/v1.4.15 (nagios-plugins 1.4.15)"
wc path/to/access.log | awk '{print $1}'
output có thể là
18681 ( đây là số dòng trong access.log tương ứng với số request apache đã nhận từ lúc cài đặt tới nay )
sau "một phút" chạy lại lệnh trên
19681 ( đây là số dòng trong access.log sau 1 phút )
trừ 2 thằng ta có được số request nhận được trong 1 phút vừa qua
19681 - 18681 = 1000 ( ví dụ thôi nhá :-) )
chạy lệnh sau
tail 'path/to/access.log' -n 1000 | awk '{print $1}' | sort | uniq -c | sort -n | tail -n 1
lệnh tail sẽ lấy từ access.log 1000 dòng "cuối cùng trong file" (là con số ta trừ ở trên ) , truyền qua cho awk để chỉ lọc ra phần IP trong cái đống đó, gom chúng lại bằng lệnh short rồi uniq -c sẽ đếm số lần xuất hiện của từng IP ( các dòng giống nhau sẽ cộng lại ) , chuyền qua cho sort -n để sắp từ nhỏ đến lớn ( lớn nhất cuối cùng ) và sau cùng là tail -n 1 là sẽ lấy 01 dòng cuối trong cái sort -n ở trên ( tức là cái IP truy cập nhiều nhất trong 1 phút qua )
output:
Code:
268 67.195.113.243
268 là số lần request chạm server được ghi nhận trong access.log , đằng sau là cái IP gửi request
Chia sẻ cùng mọi người cách của mình:
last_time=`tail -1 access_log | awk '{ print substr($4, 2, length($4)-1) }'`; standard_last_time=`echo $last_time | sed 's/\//-/g' | awk -F":" '{ print $1" "$2":"$3":"$4 }'`; pre_min=`date -d "$standard_last_time 1 minutes ago" +%d/%b/%Y:%k:%M:%S`; awk '$4 <= to && $4 >= from { print $1 }' from="[$pre_min" to="[$last_time" access_log | sort | uniq -c | sort -rn | awk '$1 >=200 { print $0 }'
Chôm của quanta 1 chút mình được lệnh sau:
pre_min=`date -d '1 minutes ago' +%d/%b/%Y:%H:%M`; grep -n -m 1 $pre_min access_log | cut -d":" -f1 | xargs -iline_num tail -n +line_num access_log | awk ' $4 <= to && $4 >= from { print $1 }' from="[$pre_min:00" to="[$pre_min:59" | sort | uniq -c | sort -rn
Lệnh này sẽ liệt kê số lần xuất hiện của 1 IP trong access_log chính xác trong khoảng thời gian 1 phút trước.
Có thể linh hoạt thêm 1 chút nếu khai báo thêm 1 biến cur_min. Ví dụ lệnh sau sẽ liệt kê số lấn xuất hiện của 1 IP trong access_log trong 10 phút trước
pre_min=`date -d '11 minutes ago' +%d/%b/%Y:%H:%M`; cur_min=`date -d '1 minutes ago' +%d/%b/%Y:%H:%M`; grep -n -m 1 $pre_min access_log | cut -d":" -f1 | xargs -iline_num tail -n +line_num access_log | awk ' $4 <= to && $4 >= from { print $1 }' from="[$pre_min:00" to="[$cur_min:59" | sort | uniq -c | sort -nr
Wednesday, November 17, 2010
Top Ten Sources of IT Security Best Practices
This 'Top Ten' list is intended to promote and publicize the existence of best practice standards, frameworks and guidelines for IT security. Most of the best practices are published by international organizations and governmental entities. Although there is some overlap, the perspectives on IT security, risk and controls vary considerably.
At Continental Audit Services (www.continentalaudit.com), our team of IT auditors is constantly assessing IT risks, reviewing controls and making recommendations. The selection of best practice standards and frameworks is integral to our audit process. We have seen how best practices are implemented in the real world sometimes in contrast to the theory and concepts found in published documentation.
This 'Top Ten' list is intended to be used as a reference for IT auditors, security practitioners, risk managers, compliance professionals, IT administrators, software developers and the broad range of IT professionals. We hope to add value to the overall IT professional community.
1. Best practice source: Control Objectives for Information and related Technology (COBIT)
Description: Generally accepted best practices, processes, measures and indicators for IT governance and control.
Website: http://www.isaca.org
2. Best practice source: ISO/IEC 27001 IT Security techniques -- Information security management systems
Description: Comprehensive management system for information security focused on IT risk and controls.
Website: http://www.iso.org
3. Best practice source: Center for Internet Security (CIS) Benchmarks
Description: Best practice standards and benchmarks to control IT risks. The focus is on technical security benchmarks, configurations and metrics.
Website: http://cisecurity.org
4. Best practice source: Open Web Application Security Project (OWASP)
Description: Web and application security best practices and tools.
Website: http://www.owasp.org
5. Best practice source: US Department of Defense, Security Technical Implementation Guides (STIGs)
Description: Technical configuration standards developed and used by the US Department of Defense. Covers a wide range of technologies.
Website: http://iase.disa.mil/stigs/index.html
6. Best practice source: US National Security Agency (NSA) Guides
Description: Technical security configuration guides developed and used by the US National Security Agency covering a wide range of technologies.
Website: http://www.nsa.gov/ia/guidance/security_configuration_guides/
7. Best practice source: US Federal Financial Institutions Examination Council's (FFIEC)
Description: Series of 'booklets' covering wide range of technologies and designed for federal auditors to assess compliance with best practices.
Website: http://www.ffiec.gov
8. Best practice source: US National Institute of Standards and Technology (NIST), Computer Security Division, Special Publications (SPs)
Description: Series of publications on security guidelines designed for a wide range of technologies.
Website: http://csrc.nist.gov/publications/PubsSPs.html
9. Best practice source: Committee of Sponsoring Organizations of the Treadway Commission (COSO) Framework
Description: Internal control and risk management framework used in compliance with Sarbanes-Oxley Act of 2002.
Website: http://www.coso.org
10. Best practice source: Information Technology Infrastructure Library (ITIL)
Description: Comprehensive set of best practices for IT services management (problem, change, configuration, incident management), development and operations. Published by UK Office of Government Commerce.
Website: http://www.itil-officialsite.com
At Continental Audit Services (www.continentalaudit.com), our team of IT auditors is constantly assessing IT risks, reviewing controls and making recommendations. The selection of best practice standards and frameworks is integral to our audit process. We have seen how best practices are implemented in the real world sometimes in contrast to the theory and concepts found in published documentation.
This 'Top Ten' list is intended to be used as a reference for IT auditors, security practitioners, risk managers, compliance professionals, IT administrators, software developers and the broad range of IT professionals. We hope to add value to the overall IT professional community.
1. Best practice source: Control Objectives for Information and related Technology (COBIT)
Description: Generally accepted best practices, processes, measures and indicators for IT governance and control.
Website: http://www.isaca.org
2. Best practice source: ISO/IEC 27001 IT Security techniques -- Information security management systems
Description: Comprehensive management system for information security focused on IT risk and controls.
Website: http://www.iso.org
3. Best practice source: Center for Internet Security (CIS) Benchmarks
Description: Best practice standards and benchmarks to control IT risks. The focus is on technical security benchmarks, configurations and metrics.
Website: http://cisecurity.org
4. Best practice source: Open Web Application Security Project (OWASP)
Description: Web and application security best practices and tools.
Website: http://www.owasp.org
5. Best practice source: US Department of Defense, Security Technical Implementation Guides (STIGs)
Description: Technical configuration standards developed and used by the US Department of Defense. Covers a wide range of technologies.
Website: http://iase.disa.mil/stigs/index.html
6. Best practice source: US National Security Agency (NSA) Guides
Description: Technical security configuration guides developed and used by the US National Security Agency covering a wide range of technologies.
Website: http://www.nsa.gov/ia/guidance/security_configuration_guides/
7. Best practice source: US Federal Financial Institutions Examination Council's (FFIEC)
Description: Series of 'booklets' covering wide range of technologies and designed for federal auditors to assess compliance with best practices.
Website: http://www.ffiec.gov
8. Best practice source: US National Institute of Standards and Technology (NIST), Computer Security Division, Special Publications (SPs)
Description: Series of publications on security guidelines designed for a wide range of technologies.
Website: http://csrc.nist.gov/publications/PubsSPs.html
9. Best practice source: Committee of Sponsoring Organizations of the Treadway Commission (COSO) Framework
Description: Internal control and risk management framework used in compliance with Sarbanes-Oxley Act of 2002.
Website: http://www.coso.org
10. Best practice source: Information Technology Infrastructure Library (ITIL)
Description: Comprehensive set of best practices for IT services management (problem, change, configuration, incident management), development and operations. Published by UK Office of Government Commerce.
Website: http://www.itil-officialsite.com
Friday, November 12, 2010
Ngăn ngừa social engineering, trojan, đánh cắp mật khẩu
- Cách an toàn nhất có lẽ là nên tạo một máy ảo (chạy vmware hoặc virtualbox) hoàn toàn chỉ dùng để thực hiện việc đăng nhập vào những trang mình cho là quan trọng. Tuyệt đối không dùng máy ảo này để duyệt web thông thường hoặc check mail. Thông tin cần thiết có thể được chuyển từ máy thật vào máy ảo một cách dễ dàng và có chọn lựa để tránh lây nhiễm viruses.
- Ngoài ra, tập thói quen sử dụng 2 trình duyệt khác nhau song song để tránh bị phishing và bị chôm sessions. Một trình duyệt (ví dụ như Firefox) dùng để duyệt những trang quen thuộc, một trình duyệt khác (ví dụ như Chrome) để cắt và dán những đường dẫn đến các trang web không quen thuộc. Bằng cách này, các phương pháp phishing sẽ được giảm thiểu tối đa (vì một trình duyệt như Chrome không hề đăng nhập ở đâu thì chẳng có gì để chôm hết).
- Tận dụng tối đa các plug-ins quan trọng trên Firefox (như noscript, noads....) để giảm thiểu khả năng bị thâm nhập xuyên qua web layer. Nếu được, nên cài hẳn một máy (hoặc máy ảo) chạy bằng hệ điều hành Linux để dùng. Máy chạy Windows chỉ để chơi game nội bộ.
- Cài chương trình antivirus và thường xuyên cập nhật "virus def", đừng lơ là chuyện này. Nếu được, nên tận dụng một firewall nào đó để gia tăng bảo vệ máy, đặc biệt firewall có đủ khả năng kiểm soát cả "inbound" và "outbound" traffic để cho phép những truy cập được ra vào ở những cổng (ví dụ như 80, 443, 110, 25) và ứng dụng nhất định nào đó mà thôi.
- Tuyệt đối không nên dùng cracked software (kể cả pdf) bởi vì đa số viruses và trojans đi theo đường này.
- Tuyệt đối không viếng những trang web lạ (và có dạng tên miền khó đọc hoặc nhại tên miền một trang nào đó phổ biến).
- Sử dụng một ứng dụng bảo mật như "filecrypt" để lưu các thông tin quan trong và nhạy cảm trong đó để tránh bị đánh cắp.
- Sử dụng một ứng dụng như "KeepPass" để lưu các mật khẩu và khi cần đăng nhập, dùng biện pháp "cut & paste" password hoặc viếng địa chỉ cần đăng nhập trực tiếp từ "keepass". Mật khẩu sẽ được nạp tự động xuyên qua bô nhớ của máy. Biện pháp này vô hiệu hóa khả năng bị keylog và bị chôm mật khẩu.
- Ngoài ra, tập thói quen sử dụng 2 trình duyệt khác nhau song song để tránh bị phishing và bị chôm sessions. Một trình duyệt (ví dụ như Firefox) dùng để duyệt những trang quen thuộc, một trình duyệt khác (ví dụ như Chrome) để cắt và dán những đường dẫn đến các trang web không quen thuộc. Bằng cách này, các phương pháp phishing sẽ được giảm thiểu tối đa (vì một trình duyệt như Chrome không hề đăng nhập ở đâu thì chẳng có gì để chôm hết).
- Tận dụng tối đa các plug-ins quan trọng trên Firefox (như noscript, noads....) để giảm thiểu khả năng bị thâm nhập xuyên qua web layer. Nếu được, nên cài hẳn một máy (hoặc máy ảo) chạy bằng hệ điều hành Linux để dùng. Máy chạy Windows chỉ để chơi game nội bộ.
- Cài chương trình antivirus và thường xuyên cập nhật "virus def", đừng lơ là chuyện này. Nếu được, nên tận dụng một firewall nào đó để gia tăng bảo vệ máy, đặc biệt firewall có đủ khả năng kiểm soát cả "inbound" và "outbound" traffic để cho phép những truy cập được ra vào ở những cổng (ví dụ như 80, 443, 110, 25) và ứng dụng nhất định nào đó mà thôi.
- Tuyệt đối không nên dùng cracked software (kể cả pdf) bởi vì đa số viruses và trojans đi theo đường này.
- Tuyệt đối không viếng những trang web lạ (và có dạng tên miền khó đọc hoặc nhại tên miền một trang nào đó phổ biến).
- Sử dụng một ứng dụng bảo mật như "filecrypt" để lưu các thông tin quan trong và nhạy cảm trong đó để tránh bị đánh cắp.
- Sử dụng một ứng dụng như "KeepPass" để lưu các mật khẩu và khi cần đăng nhập, dùng biện pháp "cut & paste" password hoặc viếng địa chỉ cần đăng nhập trực tiếp từ "keepass". Mật khẩu sẽ được nạp tự động xuyên qua bô nhớ của máy. Biện pháp này vô hiệu hóa khả năng bị keylog và bị chôm mật khẩu.
Sunday, October 17, 2010
Tác động lớn của một byte
TCP là một trong những giao thức phổ dụng nhất của mạng máy tính. Mỗi lần ta click vào một trang web mới là có (ít nhất) một kết nối TCP được thiết lập từ trình duyệt đến máy chủ. Vì thế, hiệu suất hoạt động của TCP ảnh hưởng trực tiếp đến toàn bộ mấy tỉ người dùng Internet. Thiết kế một giao thức phổ dụng như TCP quả thật rất khó, vì thế Cerf và Kahn được giải thưởng Turing rất xứng đáng.
Dù có viễn kiến vĩ đại, Cerf và Kahn hiển nhiên không phải là những người duy nhất đóng góp vào TCP. Họ chỉ đặt một cái nền. Còn trong vòng 40 năm nay có biết bao nhiêu người đã đóng góp vào cải thiện nhiều mặt của TCP. Thật ra chỉ cần đến khoảng cuối những năm 80 là “diện mạo” của TCP đã rất khác so với hồi Cerf và Kahn thiết kết nó.
Xem qua quá trình tiến hóa của TCP, một điều hiển hiện là việc giữ cho một giao thức hoạt động đúng như ý mình muốn thật là nan giải. Có hai lý do chính, đều liên quan đến sự đa dạng. Thứ nhất là sự đa dạng của các loại mục tiêu khác nhau mà ta muốn giao thức đạt được: hiệu suất cao, tính bảo mật tốt, dùng ít tài nguyên mạng và tài nguyên tính toán, xử lý cực nhanh với tốc độ ánh sáng, giữ cho phiên bản mới của giao thức tương hợp với phiên bản cũ, vân vân. Thứ hai là sự đa dạng (và đa nguyên) của những nhóm nghiên cứu và các công ty đóng góp vào cải tiến về lý thuyết và lập trình giao thức trên thực tế. Làm thế nào để đảm bảo rằng TCP do Microsoft lập trình chạy tốt với TCP của Linux, của BSD, của SunOS, MacOSX, cùng với cơ man nào là các phiên bản khác nhau của chúng. Khó nữa là chúng ta không có một bộ khung lý thuyết nào khả thi để có thể xác minh xem một thiết kế giao thức cho trước là thiết kế “tốt”: các bộ phận hoạt động đồng bộ với nhau, các phiên bản hoạt động không ngáng giò nhau, vân vân.
Khó thế đấy. Vậy mà, khi ta click vào http://www.procul.org/blog ta thấy ngay cái blog này. Bất kể ta chạy máy gì, hệ điều hành gì. Nó cho thấy sự tráng kiện (robustness) của giao thức TCP và của các giao thức mạng nói chung.
Thế nhưng, có khi các bộ phận của TCP thật sự không hoạt động đồng bộ với nhau, thậm chí chỉ vì một byte dữ liệu. Khi điều này xảy ra, nếu không hiểu rõ TCP và các ngóc ngách của nó thì không thể hiểu tại sao lại có những hiện tượng “ma quái” như vậy. Câu chuyện sau đây chỉ là một vị dụ.
Chuyện như sau. Một nhóm kỹ sư muốn thử nghiệm hiệu suất hoạt động của một hệ thống Wifi. Họ viết một chương trình nhỏ để gửi dữ liệu giữa hai máy dùng hệ thống Wifi nọ. Chương trình thiết lập một kết nối TCP giữa hai máy, xong rồi bên gửi gửi đi 100KB, bên nhận gửi lại một gói ký nhận nhỏ, rồi bên gửi lại gửi đi 100KB kế tiếp, vân vân. Mục tiêu là thực hiện gửi nhận như vậy liên tục một thời gian xem tốc độ truyền là bào nhiêu.
Kết quả: hệ thống Wifi này trên Windows XP đạt được tốc độ 3.5Mbps, còn trên MacOSX chỉ đạt được 2.7Mbps. Trong ngữ cảnh của họ thì 3.5Mbps là tốt. 2.7Mbps không tốt.
Vậy Windows XP có bộ TCP tốt hơn MacOSX? (Giả sử thẻ mạng và các thứ khác tương tự nhau.)
Không. Sau vài lần nghịch với các tham số. Họ giảm 100KB xuống còn 99,912 bytes (để gửi một đợt trước khi nhận gói xác minh). Về nguyên tắc, thay vì 100KB một vòng, ta thử 99KB một vòng thì tốc độ không nên có thay đổi gì dáng kể. Thế mà tốc độ của MacOSX tự nhiên tăng lên đến 5.2Mbps: hơn Windows và gần gấp đôi tốt độ cũ. Thú vị hơn nữa, nếu thay 99,912 bytes bằng 99,913 bytes một đợt thì tốc độ của MacOSX lại giảm xuống 2.7Mbps như xưa.
1 byte mà có thể tăng tốc TCP của Mac gấp đôi? Chuyện gì xảy ra?
Số là, trong mấy trăm cái mẹo cải thiện hiệu suất được đưa vào TCP trong 40 năm qua, có 4 cái mẹo tương tác với nhau rất độc đáo tạo ra hiện tượng trên.
Để mô tả 4 cái mẹo này, trước hết chúng ta lược qua xem TCP làm việc thế nào. Đại khái, TCP là một giao thức cung cấp dịnh vụ tin cậy cho “khách hàng” là các ứng dụng (như web browser, server, Media player, và rất nhiều các ứng dụng mạng khác). Để tạo ra dịch vụ tin cậy, TCP gửi dữ liệu giữa hai đầu gửi-nhận và bắt bên nhận gửi lại các mẩu xác minh là đã nhận (acknowledgements, viết tắt là ACK). Các mẩu dữ liệu của TCP tiếng Anh gọi là segments. Các mẩu dữ liệu được nhét vào các “gói dữ liệu”, như là các phong bì mà bên trong chứa dữ liệu còn bên ngoài chứa thông tin điều khiển và địa chỉ gửi nhận. Bao bì tốn khoảng 20 bytes, cộng thêm 20 bytes bao bì của mạng nữa là khoảng 40 bytes cho mỗi gói dữ liệu.
Mẹo 1: kích thước từng mẩu dữ liệu. Một phong bì do TCP gửi không thể chứa nhiều dữ liệu quá. Tại vì các gói dữ liệu đi qua nhiều loại mạng khác nhau. Mỗi loại mạng có kích thước gói tối đa khác nhau. Ví dụ mang Ethernet có kích thước tối đa là 1500 bytes, mạng X25 có kích thước gói tối đa là 576 bytes, vân vân. Một trong các lý do mà các mạng giới hạn kích thước gói dữ liệu là vì nếu kích thước gói lớn quá thì mỗi lần đường truyền bị lỗi gì ta phải gửi lại toàn bộ gói. Gói càng lớn thì xác suất nó bị lỗi càng cao, mà gửi lại gói to thì tốn tài nguyên hơn gửi lại gói nhỏ. Thế cho nên, nếu TCP gửi một cái phong bì khổng lồ thì đến mạng có giới hạn kích thước phong bì nó sẽ bị băm nhỏ ra thành nhiều gói nhỏ. Mỗi gói nhỏ tốn một phong bì riêng. Và như thế thì rất tốn. Túm lại, TCP có một biến số gọi là MSS để lưu trữ kích thước mẩu lớn nhất (của một kết nối). Có các thuật toán để xác định MSS nên là bao nhiêu cho mỗi kết nối. Nếu không chạy thuật toán thì trị mặc định là 576 – 40 = 536, trong đó 576 là do X25, còn 40 là kích thước bao bì của TCP/IP như đã nói ở trên. Nếu chỉ truyền trên Ethernet thì MSS nên là 1500-40 = 1460.
Mẹo 2: thuật toán Nagle. Thử tưởng tượng một khách hàng của TCP cứ thích đưa mỗi lần vài bytes cho TCP để gửi qua bên nhận. Các ứng dụng như telnet, ssh, rlogin lấy inputs từ chúng ta. Chúng ta gõ bàn phím rất chậm (tính theo tốc độ máy). Người gõ nhanh nhất thế giới cũng chỉ gõ được khoảng 150 từ một phút, vị chi là khoảng vài chục đến vài trăm mili-giây một ký tự. Do đó, hoàn toàn có khả năng là ứng dụng sẽ “đưa cho” TCP từng ký tự một, cứ khoảng 100-mili giây một ký tự. Mỗi lần tải một mẩu dữ liệu 1 ký tự, TCP phải tốn ít nhất 40 bytes bao bì cho nội dung thư. Tỉ lệ phí hoài là 40/41, gần bằng tỉ lệ phí hoàn cho Vinashin. Rất tốn băng thông! Do đó, hồi 1984 John Nagle đề nghị là TCP nên tích lũy một ít “hàng họ” (nghĩa là, ký tự) trước khi gửi. Ít nhất, nếu có một phong bì gửi trước đó mà chưa có hồi âm thì khoan hẵng gửi phong bì ít hàng hiện tại. Chờ hồi âm của phong bì trước, xong rồi hẵng gửi phong bì mới. Lý do là, trong thời gian chờ hồi âm, nhỡ đâu chú khách hàng lại tuồn thêm cho vài ký tự để đóng chung vào một gói thì đỡ tốn phí vận chuyển. Còn trong trường hợp phong bì đã đầy (MSS) thì gửi luôn không cần chờ.
(Mấy bác chuyên môn đánh áo phông bàn chải bên Đông Âu hồi xưa chắc chắn đã hiểu rõ bài toán đóng hàng này.)
Mẹo 3: hồi âm muộn (Delayed ACK). Ở phía bên nhận, để tiết kiệm phí vận chuyển thì TCP thường cố gắng đóng gói cả hồi âm lẫn dữ liệu chiều ngược (gọi là piggy-backing) gửi chung vào một gói. Ví dụ như sau khi nhận một thư từ browser, web-server đọc lên một file nào đó (index.html chẳng hạn) và gửi lại cho browser. Nếu TCP đừng hồi âm ngay, chờ một xíu cho chú server đọc đĩa, thì có luôn cả index.html mang cùng với hồi âm về. Do đó, chuẩn TCP có cái mẹo hồi âm muộn, bắt bên nhận chờ khoảng 200ms đến 500ms trước khi hồi âm một mẩu dữ liệu từ bên kia. Nhưng nếu trong thời gian chờ mà nhận thêm được một thư nữa thì hồi âm cả hai ngay. (Nếu không, bên kia tưởng thư mất gửi lại mất công lắm.) Đây là luật hồi âm kép.
Mẹo 4: nhãn thời gian (timestamp option). Để đảm bảo độ tin cậy, TCP cần biết xem thư gửi đi đã nhận được chưa. Nếu thư bị mất, hoặc hồi âm bị mất thì không nhận được hồi âm. Do đó, TCP cần có một cái đồng hồ báo mất. Khi đồng hồ reng leng keng thì gửi thư lại. Nếu thời khoảng gửi lại quá bé thì không tốt: tại vì có thể hồi âm đang trên đường về, chưa chi đã gửi lại. Nếu thời khoảng gửi lại quá dài thì cũng không tốt: thư đã mất mà không gửi lại luôn còn chờ gì nữa? Do đó, TCP cần một cơ chế để ước lượng thời gian khứ hồi là bao nhiêu, xong rồi đặt thời khoảng cho đồng hồ gửi lại cỡ chừng thời gian khứ hồi cộng với một khoảng đệm cho chắc. (Thuật toán ước lượng thời khoảng khứ hồi phức tạp hơn một chút, nhưng đại khái là thế.) Làm thế nào để đo thời gian khứ hồi? Cách thứ nhất là gửi thư, rồi khi nhận được hồi âm thì xem đó là thời gian khứ hồi. Nhưng mà nếu thư bị mất, phải gửi lại, rồi nhận được hồi âm, thì mình không biết là hồi âm cho thư cũ hay thư mới. Ngoài ra, nếu bên nhận lại dùng mẹo hồi âm muộn thì ước lượng thời gian khứ hồi của mình bị sai đi. Còn nữa, TCP thường gửi nhiều thư cùng một lúc, và nếu dùng một đồng hồ cho mỗi thư thì rất phức tạp và tốn tài nguyên. Cách thứ hai là mỗi lần gửi thư đi thì dán tem chứa thời điểm hiện tại vào đó. Bên nhận, trước khi hồi âm, lấy tem của thư bỏ vào hồi âm. Khi nhận được hồi âm thì bên gửi chỉ cần lấy thời điểm hiện tại trừ đi giá trị tem là biết thời khoảng khứ hồi. Cách đo thời khoảng khứ hồi dùng nhãn thời gian này tốt hơn, nhưng như thế thì ta lại tốn thêm 12 bytes để làm nhãn và vì thế trên Ethernet thì MSS chỉ còn tối đa là 1500 – 52 = 1448 bytes thay vì 1460 bytes như trước.
Tương tác giữa 4 cái mẹo. Quay lại với câu chuyện thử hiệu xuất giữa Windows và MacOSX trên Ethernet. Khác biệt thứ nhất là Windows XP không dùng nhãn thời gian, cho nên MSS = 1460, còn MacOSX dùng nhãn thời gian cho nên MSS = 1448 (trong môi trường thử nghiệm). Do đó, 100000 bytes được
- TCP của Windows XP băm ra thành 68 mẩu, mỗi mẩu 1460 bytes, cộng với một mẩu 720 bytes.
- TCP của Mac OSX băm ra thành 69 mẩu, mỗi mẩu 1448 bytes, cộng với một mẩu 88 bytes.
Khi Windows XP truyền thì:
- Bên gửi gửi đi 68 mẩu (đầy MSS nên gửi ngay), và giữ lại mẩu cuối (720 bytes) chờ hồi âm của mẩu 68.
- Bên nhận dùng luật hồi âm kép nên sẽ hồi âm cho các mẩu 2, 4, …, 68 ngay lập tức, và cuối cùng khi bên gửi nhận được hồi âm của mẩu 68 sẽ gửi ngay mẩu lẻ cuối cùng.
Khi Mac OSX truyền thì:
- Bên gửi gửi đi 69 mẩu (đầy MSS nên gửi ngay), và giữ lại mẩu cuối (88 bytes) chờ hồi âm mẩu 69.
- Bên nhận theo luật hồi âm kép, nên sẽ hồi âm cho các mẩu 2, 4, …, 68 ngay lập tức, nhưng giữ lại không hồi âm mẩu 69 ngay (trừ phi có thêm hàng họ của khách hàng gửi kèm hồi âm mang về)
- Nhưng hàng họ chỉ có sau 100KB, mà bây giờ bên nhân mới nhận được 100000-88 bytes thôi nên chưa có hàng.
- Bên gửi thì dùng thuật toán Nagle, giữ lại 88 bytes chờ khi mẩu 69 có hồi âm.
- Kết quả là hai bên phải chờ thêm từ 200ms đến 500ms nữa, tùy theo người lập trình TCP chọn giá trị hồi âm muộn là bao nhiêu.
- Kết quả cuối cùng là cứ 100KB thì MacOSX bị chậm lại 200ms!
200ms là một thời khoảng rất lớn. Trên Gigabit Ethernet, với tốc độ 1Gbps thì trong 200ms ta truyền được 200Mb vị chi là 25MB.
http://www.procul.org/blog/2010/10/13/1-byte/#more-2363
Friday, June 18, 2010
Distributed SSH Brute Force Attempts on the rise again
- Deploy the SSH server on a port other than 22/TCP
- Deploy one of the SSH brute force prevention tools
- Disallow remote root logins
- Set PasswordAuthentication to "no" and use keys
- If you must use passwords, ensure that they are all complex
- Use AllowGroups to limit access to a specific group of users
- Use as a chroot jail for SSH if possible
- Limit the IP ranges that can connect to SSH
Thursday, June 3, 2010
Tìm kẻ tấn công khi biêt IP
a- Kiểm tra xem cái đia chỉ WAN IP ấy có phải là IP của một Proxy server nào đó không? Nếu "yes" thì gần như là bótay.com.
b- Kiểm tra xem nó có phải là IP tĩnh (WAN static IP) không? Nếu "yes" thì còn may. Nó đang tấn công bạn từ một Webserver hay Fileserver... nào đó. Check thẳng vào server đó mà tìm tòi, dự đoán.
c- Nếu IP đó là một WAN dynamic IP do một ISP nào đó (thí dụ Viettel, VDC, FPT...) cung cấp, thì chú ý xác đinh tên của ISP, các thông tin liên quan có thể tìm thấy và chờ đợi.
d. Chờ cho đến khi nó hack lai máy (thí dụ webserver của mình), thì xác đinh ngay WAN IP của nó và lập tức check thẳng vào máy của nó, trong khi nó (hay ISP) chưa thay đổi WAN dynamic IP (của modem-router của nó).
Nếu nó (hay ISP) liên tục thay đổi WAN dynamic IP, thì cũng bótay.com.
Trong quá trình này kẻ thắng thường là người "thông minh hơn và quan trong là kiên nhẫn hơn".
e- Nhưng nếu nó đã thâm nhập đươc vào máy-server của bạn, chiếm đươc quyền admin. hay root và thay đổi Event log (cả các log khác nữa) trong hệ thống rồi, thì chắc chắn là bótay.com
b- Kiểm tra xem nó có phải là IP tĩnh (WAN static IP) không? Nếu "yes" thì còn may. Nó đang tấn công bạn từ một Webserver hay Fileserver... nào đó. Check thẳng vào server đó mà tìm tòi, dự đoán.
c- Nếu IP đó là một WAN dynamic IP do một ISP nào đó (thí dụ Viettel, VDC, FPT...) cung cấp, thì chú ý xác đinh tên của ISP, các thông tin liên quan có thể tìm thấy và chờ đợi.
d. Chờ cho đến khi nó hack lai máy (thí dụ webserver của mình), thì xác đinh ngay WAN IP của nó và lập tức check thẳng vào máy của nó, trong khi nó (hay ISP) chưa thay đổi WAN dynamic IP (của modem-router của nó).
Nếu nó (hay ISP) liên tục thay đổi WAN dynamic IP, thì cũng bótay.com.
Trong quá trình này kẻ thắng thường là người "thông minh hơn và quan trong là kiên nhẫn hơn".
e- Nhưng nếu nó đã thâm nhập đươc vào máy-server của bạn, chiếm đươc quyền admin. hay root và thay đổi Event log (cả các log khác nữa) trong hệ thống rồi, thì chắc chắn là bótay.com
Friday, May 21, 2010
Certificate Authority
1. CA = Certificate Authority là từ dùng để nói về một tổ chức/thực thể được tín nhiệm để cấp certificate cho những cá nhân và tổ chức khác.
2. Certificate = chứng chỉ của một cá nhân hay tổ chức được một CA cấp cho (có thể phải trải qua quá trình CA kiểm tra danh tính của đơn vị muốn được cấp certificate).
Ví dụ: Verisign là CA được tín nhiệm, thông qua hình thức là self-signed certificate của họ được các trình duyệt web tín nhiệm. Verisign cấp certificate cho công ty hdbank. Việc cấp này đơn giản là Verisign dùng self-signed certificate của họ để ký lên CSR của khách hàng.
CA hầu như không tham gia vào quá trình thực thi của bộ giao thức SSL/TLS. nói cách khác, trình duyệt và máy chủ hầu như chỉ nói chuyện trực tiếp với nhau, mà không phải kết nối đến một bên thứ 3 nào cả. CA chỉ đóng vai trò trong việc xác lập hạ tầng khóa công khai (PKI), hầu như không tham gia vào quá trình kiểm tra và xác thực cert.
vậy việc kiểm tra và xác thực cert diễn ra như thế nào? khi trình duyệt kết nối vào máy chủ web, máy chủ web gửi lại cert của họ, thì trình duyệt sẽ có trách nhiệm kiểm tra cert này. việc kiểm tra này gồm các bước (thứ tự tùy thuộc vào trình duyệt):
1. xem cert này được ai ký, và tổ chức ký cert này có được trình duyệt tín nhiệm hay không.
2. xem cert có còn hạn sử dụng hay không.
3. xem cert có bị vô hiệu hóa hay chưa.
4. xem common name của cert có trùng với tên của máy chủ mà trình duyệt đang kết nối hay không.
bước thứ 3 là lý do mà mình dùng từ "hầu như". trình duyệt (và máy chủ) có thể kết nối đến CA để kiểm tra xem certificate của bên còn lại có bị vô hiệu hóa hay chưa (revoked). RFC của TLS/SSL không bắt buộc các hiện thực TLS/SSL phải thực hiện bước này, và theo mình biết thì mặc định các trình duyệt không thực hiện việc kiểm tra này.
2. Certificate = chứng chỉ của một cá nhân hay tổ chức được một CA cấp cho (có thể phải trải qua quá trình CA kiểm tra danh tính của đơn vị muốn được cấp certificate).
Ví dụ: Verisign là CA được tín nhiệm, thông qua hình thức là self-signed certificate của họ được các trình duyệt web tín nhiệm. Verisign cấp certificate cho công ty hdbank. Việc cấp này đơn giản là Verisign dùng self-signed certificate của họ để ký lên CSR của khách hàng.
CA hầu như không tham gia vào quá trình thực thi của bộ giao thức SSL/TLS. nói cách khác, trình duyệt và máy chủ hầu như chỉ nói chuyện trực tiếp với nhau, mà không phải kết nối đến một bên thứ 3 nào cả. CA chỉ đóng vai trò trong việc xác lập hạ tầng khóa công khai (PKI), hầu như không tham gia vào quá trình kiểm tra và xác thực cert.
vậy việc kiểm tra và xác thực cert diễn ra như thế nào? khi trình duyệt kết nối vào máy chủ web, máy chủ web gửi lại cert của họ, thì trình duyệt sẽ có trách nhiệm kiểm tra cert này. việc kiểm tra này gồm các bước (thứ tự tùy thuộc vào trình duyệt):
1. xem cert này được ai ký, và tổ chức ký cert này có được trình duyệt tín nhiệm hay không.
2. xem cert có còn hạn sử dụng hay không.
3. xem cert có bị vô hiệu hóa hay chưa.
4. xem common name của cert có trùng với tên của máy chủ mà trình duyệt đang kết nối hay không.
bước thứ 3 là lý do mà mình dùng từ "hầu như". trình duyệt (và máy chủ) có thể kết nối đến CA để kiểm tra xem certificate của bên còn lại có bị vô hiệu hóa hay chưa (revoked). RFC của TLS/SSL không bắt buộc các hiện thực TLS/SSL phải thực hiện bước này, và theo mình biết thì mặc định các trình duyệt không thực hiện việc kiểm tra này.
Tuesday, January 12, 2010
SANS Security 560 Network penetration testing & Ethical hacking
SANS Security 560 is one of the most technically rigorous courses offered by the SANS Institute. Attendees are expected to have a working knowledge of TCP/IP, cryptographic routines such as DES, AES, and MD5, and the Windows and Linux command lines before they step into class. Although SANS Security 401 (Security Essentials) and then next SANS Security 504 (Hacker Techniques, Exploits, and Incident Handling) are not pre-requisites for 560, these courses cover the groundwork that all 560 attendees are expected to know. While 560 is technically in-depth, it is important to note that programming knowledge is NOT required for the course
http://rapidshare.com/files/242603438/SS560.NetworkPenetration_tdk.part01.rar
http://rapidshare.com/files/242602844/SS560.NetworkPenetration_tdk.part02.rar
http://rapidshare.com/files/242602835/SS560.NetworkPenetration_tdk.part03.rar
http://rapidshare.com/files/242602833/SS560.NetworkPenetration_tdk.part04.rar
http://rapidshare.com/files/242603634/SS560.NetworkPenetration_tdk.part05.rarhttp://rapidshare.com/files/242602815/SS560.NetworkPenetration_tdk.part06.rar
http://rapidshare.com/files/242603495/SS560.NetworkPenetration_tdk.part07.rar
http://rapidshare.com/files/242603502/SS560.NetworkPenetration_tdk.part08.rarhttp://rapidshare.com/files/242602700/SS560.NetworkPenetration_tdk.part09.rar
pass:KELCYRA4EVER
Wednesday, December 9, 2009
Monday, December 7, 2009
Analyzing Malicious Documents Cheat Sheet
This cheat sheet outlines tips and tools for reverse-engineering malicious documents, such as Microsoft Office (DOC, XLS, PPT) and Adobe Acrobat (PDF) files.
General Approach
- Locate potentially malicious embedded code, such as shellcode, VBA macros, or JavaScript.
- Extract suspicious code segments from the file.
- If relevant, disassemble and/or debug shellcode.
- If relevant, deobfuscate and examine JavaScript, ActionScript, or VB macro code.
- Understand next steps in the infection chain.
Microsoft Office Binary File Format Notes
Structured Storage (OLE SS) defines a file system inside the binary Microsoft Office file.
Data can be “storage” (folder) and “steam” (file).
Excel stores data inside the “workbook” stream.
PowerPoint stores data inside the “PowerPoint Document” stream.
Word stores data inside various streams.
Tools for Analyzing Microsoft Office Files
OfficeMalScanner locates shellcode and VBA macros from MS Office (DOC, XLS, and PPT) files.
DisView disassembles bytes at a given offset of an MS Office file. (Part of OfficeMalScanner)
MalHost-Setup extracts shellcode from a given offset in an MS Office file and embeds it an EXE file for further analysis. (Part of OfficeMalScanner)
Offvis shows raw contents and structure of an MS Office file, and identifies some common exploits.
BIFF-Workbench shows raw contents and structure of an XLS file and supports editing and searching.
Office Binary Translator converts DOC, PPT, and XLS files into Open XML files (includes BiffView tool).
OfficeCat scans MS Office files for embedded exploits that target several known vulnerabilities.
Useful MS Office Analysis Commands
| OfficeMalScanner file.doc scan brute | Locate shellcode, OLE data, PE files in file.doc |
| OfficeMalScanner file.doc info | Locate VB macro code in file.doc (no XML files) |
| OfficeMalScanner file.docx inflate | Decompress file.docx to locate VB code (XML files) |
| DisView file.doc 0x4500 | Disassemble shellcode at 0x4500 in file.doc |
| MalHost-Setup file.doc out.exe 0x4500 | Extract shellcode from file.doc’s offset 0x4500 and create it as out.exe |
Adobe PDF File Format Notes
A PDF File is comprised of header, objects, cross-reference table (to locate objects), and trailer.
“/OpenAction” and “/AA” (Additional Action) specifies the script or action to run automatically.
“/Names”, “/AcroForm”, “/Action” can also specify and launch scripts or actions.
“/JavaScript” specifies JavaScript to run.
“/GoTo*” changes the view to a specified destination within the PDF or in another PDF file.
“/Launch” launches a program or opens a document.
“/URI” accesses a resource by its URL.
“/SubmitForm” and “/GoToR” can send data to URL.
“/RichMedia” can be used to embed Flash in PDF.
“/ObjStm” can hide objects inside an Object Stream.
Be mindful of obfuscation with hex codes, such as “/JavaScript” vs. “/J#61vaScript”. (See examples)
Tools for Analyzing Adobe PDF Files
PDF StructAzer displays and modifies the structure and raw contents of the PDF file. (See user manual)
PDFiD identifies PDFs that contain strings associated with scripts and actions. (Part of Python PDF Tools)
PDF-parser identifies key elements of the PDF file without rendering it (Part of Python PDF Tools)
Origami is a Ruby framework for parsing, analyzing, modifying, and creating PDF files.
Sumatra PDF and MuPDF are lightweight and free viewers that may be used in place of Adobe Acrobat.
Pdftk tweaks PDFs and uncompresses page streams.
Malzilla can extract and decompress zlib streams from PDFs, and can help deobfuscate JavaScript.
Jsunpack-n can extract and decode JavaScript from pcap network captures, and can decode PDF files.
CWSandbox and Wepawet can automatically analyze some aspects of malicious PDF files.
Useful PDF Analysis Commands
| pdfid.py file.pdf | Locate script and action-related strings in file.pdf |
| pdf-parser.py file.pdf | Show file.pdf’s structure to identify suspect elements |
| pdfscan.rb file.pdf | Examine and display file.pdf’s structure (Usage) |
| pdftk file.pdf output out.pdf uncompress | Uncompress page streams in file.pdf and save the result in out.pdf |
Additional Malicious File Analysis Tools
McAfee FileInsight integrates a hex editor, calculator, disassembler, decoders, scripting support, etc.
ExeFilter can filter scripts from Office and PDF files.
VirusTotal can scan files with multiple anti-virus tools to identify some malicious documents.
References
Adobe Portable Document Format (PDF) Reference
Physical and Logical Structure of PDF Files
Methods for Understanding and Analyzing Targeted Attacks with Office Documents (video)
Analyzing MSOffice Malware with OfficeMalScanner (follow-up presentation)
PDF Security Analysis and Malware Threats
Malicious Origami in PDF (follow-up presentation)
Reverse-Engineering Malware cheat sheet
Post-Scriptum
Found this cheat sheet useful? Tweet it!
Special thanks for contributions and feedback to Pedro Bueno, Frank Boldewin, and Didier Stevens. If you have suggestions for improving this cheat sheet, please let me know.
This cheat sheet is distributed according to the Creative Commons v3 "Attribution" License. File version 1.5.
Take a look at my other security cheat sheets.
About the Author: Lenny Zeltser leads the security consulting practice at Savvis. His team provides security assessments, design, and operational assistance for business-critical IT infrastructure. Lenny also teaches malware analysis at SANS Institute, explores security topics at conferences and in articles, and volunteers as an incident handler at the Internet Storm Center.
Sunday, November 22, 2009
Netstat
Cột đầu tiên chỉ Protocol. Là TCP hay UDP
Cột thứ hai chỉ local port. Nghĩa là xem port nào đang mở.
o Nếu cột này có dạng: x.y.z.t PORT có nghĩa là máy đang có một service lắng nghe cổng là PORT, IP là x.y.z.t Nếu có một host khác muốn connect đến máy này, nhưng không kết nối với NIC có IP x.y.z.t thì sẽ không thể connect đến PORT được.
o Nếu cột này có dạng: 0.0.0.0 PORT có nghĩa là máy có service lắng nghe trên cổng là PORT. Tất cả các host nếu có route đến đều có thể connect.
Cột tiếp theo (số 3) là foreign port.
o Nếu status là ESTABLISHED thì cột này chỉ IP PORT của remote host
o Nếu status là listENING thì cột này chỉ các IP PORT mà service đó chập nhận. Thường cột này sẽ có dạng 0.0.0.0:* hoặc *:* chỉ đầu kia của socket có thể có IP bất kỳ và port bất kỳ. Vì đa phần các client khi connect sẽ dùng các empherical port (các port lớn hơn 1024, không phải dành cho các service thông dụng)
Cột thứ hai chỉ local port. Nghĩa là xem port nào đang mở.
o Nếu cột này có dạng: x.y.z.t PORT có nghĩa là máy đang có một service lắng nghe cổng là PORT, IP là x.y.z.t Nếu có một host khác muốn connect đến máy này, nhưng không kết nối với NIC có IP x.y.z.t thì sẽ không thể connect đến PORT được.
o Nếu cột này có dạng: 0.0.0.0 PORT có nghĩa là máy có service lắng nghe trên cổng là PORT. Tất cả các host nếu có route đến đều có thể connect.
Cột tiếp theo (số 3) là foreign port.
o Nếu status là ESTABLISHED thì cột này chỉ IP PORT của remote host
o Nếu status là listENING thì cột này chỉ các IP PORT mà service đó chập nhận. Thường cột này sẽ có dạng 0.0.0.0:* hoặc *:* chỉ đầu kia của socket có thể có IP bất kỳ và port bất kỳ. Vì đa phần các client khi connect sẽ dùng các empherical port (các port lớn hơn 1024, không phải dành cho các service thông dụng)
DNS - PXMMRF
Quá trình phân giải một tên miền thành một public IP giúp ta có thể kết nối với một server muc tiêu, thí du một webserver, theo các bứoc cơ bản sau:
1- Đánh tên miền, thí dụ www.hvaonline.net, trên thanh đia chỉ của trình duyệt hay đánh tên miền vào một vị trí qui định trong một tiện ích với DNS-enabled.
2- DNS client (hay còn gọi là DNS lookup client) trong HDH sẽ đựoc kích hoạt. DNS client trong Windows được kích hoạt với sự giúp đỡ của một file Dynamic loaded library (DLL). DNS client sẽ kích hoạt Library Function của DLL và sau đó DLL sẽ tiến hành quá trình kết nối với một DNS server. (Còn trong Linux quá trình có khác một chút: application liên quan (thí dụ trình duyệt web) sẽ chuyển Domain name đến DNS client và chờ nó trả lời).
Các DNS client của Microsoft đều có tính năng Local caching (lưu trữ một bảng phân giài tên miền có sẵn trong máy), tính năng này gọi là DNS client service (hay còn gọi là DNSCACHE).
Từ Windows prompt đánh lệnh ipconfig/displaydns, chúng ta sẽ thấy một bảng phân giải tên miền khá dài, kẻm theo các thông số liên quan như: Record type, TTL, Data Length, A record.. (Hãy thử xem các bạn! Xem xem có những tên miền độc hại, hay tên miền XXX đang bị lưu trữ, ngoài mong muốn của ta hay không ? Hề hề)
Bảng phân giải tên miền trong DNSCACHE này đựoc DNS client lưu lại sau các lần ta thừong xuyên truy cập đến các website quen thuộc. Nếu ta lại truy cập lần sau đến các website này, thì DNS client sẽ sử dụng các dữ liệu lưu trữ và chuyển đến application (trình duyệt), mà không cần kết nối với một DNS server bên ngoải, nếu như TTL chưa expired.
3-DNS client bắt đầu gửi các truy vấn (request) đến DNS server. Nhưng ta cần nhớ điều này: DNS client sẽ gửi request đến một DNS server "gần" nhất. Đó chính là DNS server đựoc lắp đặt trên local network của user (của ta), thửong là các DNS server của ISP. [Cũng chú ý là DNS client của Windows 2K SP4 và Windows mới hơn đã đựoc cấu hình để trứoc hết gửi request đến ISP Primary DNS server, nếu tại đây tên miền không đựoc phân giải thì nó mới gửi request tiếp đến Secondary DNS server ( hay Slave DNS server)]
Các ISP DNS server chính là recursive DNS server, chúng còn đựoc gọi là các "non-authoritative DNS server", hay là Resolver, mặc dù tôi không thích gọi chúng là Resolver, vì có thể nhầm với một trình Resolver trong HDH.
Nếu tính năng Recursion (Recursion- là hỏi DNS server khác hộ cho ta về việc phân giải tên miền) trên recursive DNS server không bị disabled (một vài Admin. quá cẩn thận làm việc kỳ như vậy đấy) thì nó sẽ tiêp nhận các request từ DNS client và bắt đầu phân giải tên miền. Nếu tên miền cần phân giải đã có trong CACHE của DNS server thì nó sẽ lấy dữ liệu trả lời ngay cho DNS client. DNS client tiếp nhân thông tin trả lởi và chuyển (convert) thông tin từ ngôn ngữ mà DNS server hiểu sang ngôn ngữ mà application (trình duyệt) có thể hiểu đựoc, cho application này. Nếu trong CACHE không có sẵn thì recursive DNS server bắt đầu quá trình hỏi các DNS khác, các DNS bên ngoài (trong RFC 1035-1987, mục 2: Common configuration, ngừoi ta gọi các DNS server bên ngoài này là "Foreign name server"). Vậy chúng thưc sư là các DNS server gì?
4- Recursive DNS server lúc này phải tìm trên mạng các DNSserver chịu trách nhiệm quản lý các hậu tố DNS của tên miền cần phân giải, là .com, .net..., trong thí dụ của ta tên miền cần phân giải là www.hvaonline.net thì recursive DNS server phải tìm ra các DNS server quản lý .net.
Nhưng làm thế nào mà tìm ra đựoc những DNS server quản lý .net trong hàng triệu DNS server trên mạng?
Cũng có cách đấy, recursive DNS server sẽ phải hỏi 13 Root DNS server xem những DNS server nào quản lý .net. Nhưng các Root DNS server ở đâu? Danh sách 13 Root DNS server này, kèm public IP đựoc lưu trữ trong chínhDNS server (phần mềm quàn lý DNS cài trong hệ thống- như Windows DNS, BIND...). Ai đã từng thiết lâp một DNS server sẽ tìm thấy chúng, nếu mở lần lựot các thẻ trên các giao diện của phần mềm. Ngoài ra cũng có thể thấy nó trong 1 file có tên là cache.dns tai thư mục \winnt\system32\dns hay windows\system32\dns.
Recursive DNS server, căn cứ danh sách 13 root DNS server và IP của chúng sẽ gửi các truy vấn đến các root DNS server này.
5- Tiếp nhận các request từ recursive DNS server, một hay một vài root DNS server sẽ trả lởi (respond) vả gửi dữ liệu đến recursive DNS server. Căn cứ thông tin cung cấp từ root DNS server, recursive DNS server sẽ gửi các request đến tất cả DNS server quản lý .net, vì nó không biết rõ trong các DNS server thì cái nào lưu trữ trong cache tên miền hvaonline.net. Môt hay một vài DNS server quản lý hvaonline.net sẽ trả lời recursive DNS server.
Tiếp nhân thông tin phân giải tên miền hvaonline.net từ DNS server nói trên, recursive DNS server sẽ chuyển thông tin phân giải tên miền về cho DNS client của máy ta và DNS client sẽ chuyển tiếp thông tin này cho application (trình duyệt). Chú ý là các DNS server quản lý tên miền hvaonline.net này mới chính là các Authoritative DNS server của tên miền hvaonline.net.
Hơi dài dòng nhỉ phải không các bạn. Nhưng phân tích kỹ quá trình phân giải tên miền chúng ta sẽ thấy rõ những yếu tố làm tiền đề cho các cuộc tấn công "DNS cache poisoning" như kiểu tấn công "Birthday Paradox" hay có thể kiểu tấn công mà Dan Kaminsky đề cập (nói có thể vì cho đến nay anh ta- Dan Kaminsky còn khá trẻ-chưa nói bất cứ chi tiết cụ thể nào về cơ chế tấn công). Anh ta hứa là sẽ chỉ nói vào ngày 6.8.08 tại diễn đàn Black Hat.
Các yếu tố làm tiền đề cho cuôc tấn công "DNS cache poisoning" là:
1- Muc tiêu của cuôc tấn công chủ yếu là các ISP recursive DNS server, không phải là các Foreign name server (hay Authoritative DNS server) vì thừong các user (hay hacker) không "liên hệ" trưc tiếp với chúng.
2- Tên miền gửi kèm theo request gửi từ hacker không có trong recursive DNS server cache.
3- Recursive DNS server phải enable option recursion (nhưng thừong như vậy)
4- Các gói tin trả lời giả mạo gửi từ máy hacker đến Victim recursive DNS server phải hiểu là giả mạo trả lời cùa, từ Authoritative DNS servers (hay gọi là Foreign name servers).
5- Khi hacker gửi các gói tin trả lời giả mạo đến recursive DNS server thì đồng thời các Authoritative DNS cũng gửi các gói tin trả lời thật (hợp lệ) đến recursive DNS server này. Có một sự "cạnh tranh" giữa 2 dòng thông tin. Các Authoritative DNS server thừong khá mạnh, hay rất mạnh. Do vậy muốn thành công hacker có thể phải tìm cách làm chúng "chạy chậm" lại, bằng cách DoS vào các Authoritative DNS server chẳng hạn.
6- Vì các recursive DNS server (hay chính xác hơn là các phần mềm quản lý DNS trong hệ thống) lại đồng thời gửi nhiều request đến tất cả các Authoritative DNS server nên tạo điều kiện thuân lơi khá lớn cho hacker gửi gói tin trả lởi giả mạo có transaction ID (hay còn gọi là requestID) trùng với transaction ID mà recursive DNS server tạo ra một cách xác xuất. Vì vậy gói tin trả lời giả mạo của hacker có thuân lợi hơn để đựoc recursive DNS server coi là hợp lệ và chấp nhận.
7- Nếu recursive DNS server đựoc cấu hình cho TTL đủ ngắn, dù hacker có poisoning đựoc cache của DNS server, thì tác dụng thưc tế của cuộc tấn công cũng rất hạn chế.
1- Đánh tên miền, thí dụ www.hvaonline.net, trên thanh đia chỉ của trình duyệt hay đánh tên miền vào một vị trí qui định trong một tiện ích với DNS-enabled.
2- DNS client (hay còn gọi là DNS lookup client) trong HDH sẽ đựoc kích hoạt. DNS client trong Windows được kích hoạt với sự giúp đỡ của một file Dynamic loaded library (DLL). DNS client sẽ kích hoạt Library Function của DLL và sau đó DLL sẽ tiến hành quá trình kết nối với một DNS server. (Còn trong Linux quá trình có khác một chút: application liên quan (thí dụ trình duyệt web) sẽ chuyển Domain name đến DNS client và chờ nó trả lời).
Các DNS client của Microsoft đều có tính năng Local caching (lưu trữ một bảng phân giài tên miền có sẵn trong máy), tính năng này gọi là DNS client service (hay còn gọi là DNSCACHE).
Từ Windows prompt đánh lệnh ipconfig/displaydns, chúng ta sẽ thấy một bảng phân giải tên miền khá dài, kẻm theo các thông số liên quan như: Record type, TTL, Data Length, A record.. (Hãy thử xem các bạn! Xem xem có những tên miền độc hại, hay tên miền XXX đang bị lưu trữ, ngoài mong muốn của ta hay không ? Hề hề)
Bảng phân giải tên miền trong DNSCACHE này đựoc DNS client lưu lại sau các lần ta thừong xuyên truy cập đến các website quen thuộc. Nếu ta lại truy cập lần sau đến các website này, thì DNS client sẽ sử dụng các dữ liệu lưu trữ và chuyển đến application (trình duyệt), mà không cần kết nối với một DNS server bên ngoải, nếu như TTL chưa expired.
3-DNS client bắt đầu gửi các truy vấn (request) đến DNS server. Nhưng ta cần nhớ điều này: DNS client sẽ gửi request đến một DNS server "gần" nhất. Đó chính là DNS server đựoc lắp đặt trên local network của user (của ta), thửong là các DNS server của ISP. [Cũng chú ý là DNS client của Windows 2K SP4 và Windows mới hơn đã đựoc cấu hình để trứoc hết gửi request đến ISP Primary DNS server, nếu tại đây tên miền không đựoc phân giải thì nó mới gửi request tiếp đến Secondary DNS server ( hay Slave DNS server)]
Các ISP DNS server chính là recursive DNS server, chúng còn đựoc gọi là các "non-authoritative DNS server", hay là Resolver, mặc dù tôi không thích gọi chúng là Resolver, vì có thể nhầm với một trình Resolver trong HDH.
Nếu tính năng Recursion (Recursion- là hỏi DNS server khác hộ cho ta về việc phân giải tên miền) trên recursive DNS server không bị disabled (một vài Admin. quá cẩn thận làm việc kỳ như vậy đấy) thì nó sẽ tiêp nhận các request từ DNS client và bắt đầu phân giải tên miền. Nếu tên miền cần phân giải đã có trong CACHE của DNS server thì nó sẽ lấy dữ liệu trả lời ngay cho DNS client. DNS client tiếp nhân thông tin trả lởi và chuyển (convert) thông tin từ ngôn ngữ mà DNS server hiểu sang ngôn ngữ mà application (trình duyệt) có thể hiểu đựoc, cho application này. Nếu trong CACHE không có sẵn thì recursive DNS server bắt đầu quá trình hỏi các DNS khác, các DNS bên ngoài (trong RFC 1035-1987, mục 2: Common configuration, ngừoi ta gọi các DNS server bên ngoài này là "Foreign name server"). Vậy chúng thưc sư là các DNS server gì?
4- Recursive DNS server lúc này phải tìm trên mạng các DNSserver chịu trách nhiệm quản lý các hậu tố DNS của tên miền cần phân giải, là .com, .net..., trong thí dụ của ta tên miền cần phân giải là www.hvaonline.net thì recursive DNS server phải tìm ra các DNS server quản lý .net.
Nhưng làm thế nào mà tìm ra đựoc những DNS server quản lý .net trong hàng triệu DNS server trên mạng?
Cũng có cách đấy, recursive DNS server sẽ phải hỏi 13 Root DNS server xem những DNS server nào quản lý .net. Nhưng các Root DNS server ở đâu? Danh sách 13 Root DNS server này, kèm public IP đựoc lưu trữ trong chínhDNS server (phần mềm quàn lý DNS cài trong hệ thống- như Windows DNS, BIND...). Ai đã từng thiết lâp một DNS server sẽ tìm thấy chúng, nếu mở lần lựot các thẻ trên các giao diện của phần mềm. Ngoài ra cũng có thể thấy nó trong 1 file có tên là cache.dns tai thư mục \winnt\system32\dns hay windows\system32\dns.
Recursive DNS server, căn cứ danh sách 13 root DNS server và IP của chúng sẽ gửi các truy vấn đến các root DNS server này.
5- Tiếp nhận các request từ recursive DNS server, một hay một vài root DNS server sẽ trả lởi (respond) vả gửi dữ liệu đến recursive DNS server. Căn cứ thông tin cung cấp từ root DNS server, recursive DNS server sẽ gửi các request đến tất cả DNS server quản lý .net, vì nó không biết rõ trong các DNS server thì cái nào lưu trữ trong cache tên miền hvaonline.net. Môt hay một vài DNS server quản lý hvaonline.net sẽ trả lời recursive DNS server.
Tiếp nhân thông tin phân giải tên miền hvaonline.net từ DNS server nói trên, recursive DNS server sẽ chuyển thông tin phân giải tên miền về cho DNS client của máy ta và DNS client sẽ chuyển tiếp thông tin này cho application (trình duyệt). Chú ý là các DNS server quản lý tên miền hvaonline.net này mới chính là các Authoritative DNS server của tên miền hvaonline.net.
Hơi dài dòng nhỉ phải không các bạn. Nhưng phân tích kỹ quá trình phân giải tên miền chúng ta sẽ thấy rõ những yếu tố làm tiền đề cho các cuộc tấn công "DNS cache poisoning" như kiểu tấn công "Birthday Paradox" hay có thể kiểu tấn công mà Dan Kaminsky đề cập (nói có thể vì cho đến nay anh ta- Dan Kaminsky còn khá trẻ-chưa nói bất cứ chi tiết cụ thể nào về cơ chế tấn công). Anh ta hứa là sẽ chỉ nói vào ngày 6.8.08 tại diễn đàn Black Hat.
Các yếu tố làm tiền đề cho cuôc tấn công "DNS cache poisoning" là:
1- Muc tiêu của cuôc tấn công chủ yếu là các ISP recursive DNS server, không phải là các Foreign name server (hay Authoritative DNS server) vì thừong các user (hay hacker) không "liên hệ" trưc tiếp với chúng.
2- Tên miền gửi kèm theo request gửi từ hacker không có trong recursive DNS server cache.
3- Recursive DNS server phải enable option recursion (nhưng thừong như vậy)
4- Các gói tin trả lời giả mạo gửi từ máy hacker đến Victim recursive DNS server phải hiểu là giả mạo trả lời cùa, từ Authoritative DNS servers (hay gọi là Foreign name servers).
5- Khi hacker gửi các gói tin trả lời giả mạo đến recursive DNS server thì đồng thời các Authoritative DNS cũng gửi các gói tin trả lời thật (hợp lệ) đến recursive DNS server này. Có một sự "cạnh tranh" giữa 2 dòng thông tin. Các Authoritative DNS server thừong khá mạnh, hay rất mạnh. Do vậy muốn thành công hacker có thể phải tìm cách làm chúng "chạy chậm" lại, bằng cách DoS vào các Authoritative DNS server chẳng hạn.
6- Vì các recursive DNS server (hay chính xác hơn là các phần mềm quản lý DNS trong hệ thống) lại đồng thời gửi nhiều request đến tất cả các Authoritative DNS server nên tạo điều kiện thuân lơi khá lớn cho hacker gửi gói tin trả lởi giả mạo có transaction ID (hay còn gọi là requestID) trùng với transaction ID mà recursive DNS server tạo ra một cách xác xuất. Vì vậy gói tin trả lời giả mạo của hacker có thuân lợi hơn để đựoc recursive DNS server coi là hợp lệ và chấp nhận.
7- Nếu recursive DNS server đựoc cấu hình cho TTL đủ ngắn, dù hacker có poisoning đựoc cache của DNS server, thì tác dụng thưc tế của cuộc tấn công cũng rất hạn chế.
Subscribe to:
Posts (Atom)