 | |
| |
| |
|
http://monitor.saycoo.com/zhtw/index.php
2008年8月2日 星期六
An Analysis of the RADIUS Authentication Protocol
An Analysis of the RADIUS Authentication Protocol
by Joshua Hill, InfoGard LaboratoriesCopyright © 2001, Joshua Hill
You may distribute unaltered copies of this document without restriction
A current version of this article is maintained at:
http://www.untruth.org/~josh/security/radius/
Please send comments to josh-radius@untruth.org
Last Modified Sat Nov 24 23:58:41 PST 2001
See the Document Change History section for a history of modification
1 Introduction
RADIUS is a widely used protocol in network environments. It is commonly used for embedded network devices such as routers, modem servers, switches, etc. It is used for several reasons:
- The embedded systems generally cannot deal with a large number of users with distinct authentication information. This requires more storage than many embedded systems possess.
- RADIUS facilitates centralized user administration, which is important for several of these applications. Many ISPs have tens of thousands, hundreds of thousands, or even millions of users. Users are added and deleted continuously throughout the day, and user authentication information changes constantly. Centralized administration of users in this setting is an operational requirement.
- RADIUS consistently provides some level of protection against a sniffing, active attacker. Other remote authentication protocols provide either intermittent protection, inadequate protection or non-existent protection. RADIUS's primary competition for remote authentication is TACACS+ and LDAP. LDAP natively provides no protection against sniffing or active attackers. TACACS+ is subtly flawed, as discussed by Solar Designer in his advisory.
- RADIUS support is nearly omni-present. Other remote authentication protocols do not have consistent support from hardware vendors, whereas RADIUS is uniformly supported. Because the platforms on which RADIUS is implemented on are often embedded systems, there are limited opportunities to support additional protocols. Any changes to the RADIUS protocol would have to be at least minimally compatible with pre-existing (unmodified) RADIUS clients and servers.
RADIUS is currently the de-facto standard for remote authentication. It is very prevalent in both new and legacy systems.
1.1 Applicability
This analysis deals with some of the characteristics of the base RADIUS protocol and of the User-Password attribute. Depending on the mode of authentication used, the described User-Password weaknesses may or may not compromise the security of the underlying authentication scheme. A complete compromise of the User-Password attribute would result in the complete compromise of the normal Username/Password or PAP authentication schemes, because both of these systems include otherwise unprotected authentication information in the User-Password attribute. On the other hand when a Challenge/Response system is in use, a complete compromise of the User-Password attribute would only expose the underlying Challenge/Response information to additional attack, which may or may not lead to a complete compromise of the authentication system, depending on the strength of the underlying authentication system.
This analysis does not cover the RADIUS protocol's accounting functionality (which is, incidentally, also flawed, but normally doesn't transport information that must be kept confidential).
2 Protocol Summary
A summary of the RADIUS packet is below (from the RFC):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
The code establishes the type of RADIUS packet. The codes are:
| Value | Description |
| 1 | Access-Request |
| 2 | Access-Accept |
| 3 | Access-Reject |
| 4 | Accounting-Request |
| 5 | Accounting-Response |
| 11 | Access-Challenge |
| 12 | Status-Server (experimental) |
| 13 | Status-Client (experimental) |
| 255 | Reserved |
The identifier is a one octet value that allows the RADIUS client to match a RADIUS response with the correct outstanding request.
The attributes section is where an arbitrary number of attribute fields are stored. The only pertinent attributes for this discussion are the User-Name and User-Password attributes.
This description will concentrate on the most common type of RADIUS exchange: An Access-Request involving a username and user password, followed by either an Access-Accept, Access-Reject or a failure. I will refer to the two participants in this protocol as the client and the server. The client is the entity that has authentication information that it wishes to validate. The server is the entity that has access to a database of authentication information that it can use to validate the client's authentication request.
2.1 Initial Client Processing
The client creates an Access-Request RADIUS packet, including at least the User-Name and User-Password attributes.
The Access-Request packet's identifier field is generated by the client. The generation process for the identifier field is not specified by the RADIUS protocol specification, but it is usually implemented as a simple counter that is incremented for each request.
The Access-Request packet contains a 16 octet Request Authenticator in the authenticator field. This Request authenticator is a randomly chosen 16 octet string.
This packet is completely unprotected, except for the User-Password attribute, which is protected as follows:
The client and server share a secret. That shared secret followed by the Request Authenticator is put through an MD5 hash to create a 16 octet value which is XORed with the password entered by the user. If the user password is greater than 16 octets, additional MD5 calculations are performed, using the previous ciphertext instead of the Request Authenticator.
More formally:
Call the shared secret S and the pseudo-random 128-bit Request Authenticator RA. The password is broken into 16-octet blocks p1, p2, ... pn, with the last block padded at the end with '0's to a 16-octet boundary. The ciphertext blocks are c1, c2... cn.
c1 = p1 XOR MD5(S + RA)
c2 = p2 XOR MD5(S + c1)
.
.
.
cn = pn XOR MD5(S + cn-1)
The User-Password attribute contains c1+c2+...+cn, Where + denotes concatenation.
2.2 Server Processing
The server receives the RADIUS Access-Request packet and verifies that the server possesses a shared secret for the client. If the server does not possess a shared secret for the client, the request is silently dropped.
Because the server also possesses the shared secret, it can go through a slightly modified version of the client's protection process on the User-Password attribute and obtain the unprotected password. It then uses its authentication database to validate the username and password. If the password is valid, the server creates an Access-Accept packet to send back to the client. If the password is invalid, the server creates an Access-Reject packet to send back to the client.
Both the Access-Accept packet and the Access-Reject packet use the same identifier value from the client's Access-Request packet, and put a Response Authenticator in the Authenticator field. The Response Authenticator is the is the MD5 hash of the response packet with the associated request packet's Request Authenticator in the Authenticator field, concatenated with the shared secret.
That is, ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where + denotes concatenation.
2.3 Client Post Processing
When the client receives a response packet, it attempts to match it with an outstanding request using the identifier field. If the client does not have an outstanding request using the same identifier, the response is silently discarded. The client then verifies the Response Authenticator by performing the same Response Authenticator calculation the server performed, and then comparing the result with the Authenticator field. If the Response Authenticator does not match, the packet is silently discarded.
If the client received a verified Access-Accept packet, the username and password are considered to be correct, and the user is authenticated. If the client received a verified Access-Reject message, the username and password are considered to be incorrect, and the user is not authenticated.
3 RADIUS Issues
The RADIUS protocol has a set of vulnerabilities that are either caused by the protocol or caused by poor client implementation and exacerbated by the protocol. The vulnerabilities that follow arose during a somewhat shallow exploration of the protocol; this is not expected to be a complete list of vulnerabilities of the RADIUS protocol, these are merely the vulnerabilities that presented themselves to the reviewer.
3.1 Response Authenticator Based Shared Secret Attack
The Response Authenticator is essentially an ad hoc MD5 based keyed hash. This primitive facilitates an attack on the shared secret. If an attacker observes a valid Access-Request packet and the associated Access-Accept or Access-Reject packet, they can launch an off-line exhaustive attack on the shared secret. The attacker can pre-compute the MD5 state for (Code+ID+Length+RequestAuth+Attributes) and then resume the hash once for each shared secret guess. The ability to pre-compute the leading sections of this keyed hash primitive reduces the computational requirements for a successful attack.
3.2 User-Password Attribute Cipher Design Comments
The User-Password protection scheme is a stream-cipher, where an MD5 hash is used as an ad hoc pseudorandom number generator (PRNG). The first 16 octets of the stream cipher display the same properties as a synchronous stream cipher. After the first 16 octets, the stream cipher state integrates the previous ciphertext, and becomes more accurately described as a self-synchronizing stream cipher.
The security of the cipher rests on the strength of MD5 for this type of use and the selection of the shared secret. It is unclear what the requirements for this cipher are, so it is unclear if the MD5 function is appropriate for this use. MD5 is not designed to be a stream cipher primitive, it is designed to be a cryptographic hash. This sort of misuse of cryptographic primitives often leads to subtly flawed systems.
3.3 User-Password Attribute Based Shared Secret Attack
Because of the selection of a stream cipher for protection of the User-Password attribute, an attacker can gain information about the Shared Secret if they can observe network traffic and attempt an authentication. The attacker attempts to authenticate to the client with a known password. The attacker then captures the resulting Access-Request packet and XORs the protected portion of the User-Password attribute with the password they provided to the client. This results in the value of the MD5(Shared Secret + Request Authenticator) operation. The Request Authenticator is known (it is in the client's Access-Request packet), so the attacker can launch an off-line exhaustive attack on the shared secret. Note, though, that the attacker cannot pre-compute the MD5 state of the hash for the Request Authenticator, because the Request Authenticator is hashed second.
3.4 User-Password Based Password Attack
The use of a stream cipher to protect the User-Password attribute results in a vulnerability that allows an attacker to circumvent any authentication rate limits imposed by the client. The attacker first attempts to authenticate to the client using a valid username and a known (and likely incorrect) user password. The attacker then captures the resulting Access-Request packet and determines the result of the MD5(Shared Secret + Request Authenticator) operation (in the same way as in the previous attack). The attacker can then replay modified Access-Request packets, using the same Request Authenticator and MD5(Shared Secret + Request Authenticator) value, changing the password (and the associated User-Password attribute) for each replay. If the server does not impose user based rate limits, this will allow the attacker to efficiently perform an exhaustive search for the correct user password.
Note that the attacker can only use this method to attack passwords that are 16 characters or less, as the User-Password protection mechanism uses a chaining method that includes previous ciphertext in the state after the first 16 octets of output.
Any sort of strong data authentication in the Access-Request packet would make this attack impossible.
3.5 Request Authenticator Based Attacks
The security of RADIUS depends on the generation of the Request Authenticator field. The Request Authenticator must be both unique and non-predictable in order for the RADIUS implementation to be secure. The RADIUS protocol specification does not emphasize the importance of the Request Authenticator generation, so there are a large number of implementations that use poor PRNGs to generate the Request Authenticator. If the client uses a PRNG that repeats values (or has a short cycle), the protocol ceases to provide the intended level of protection.
The last two of these attacks require the attacker to cause the client to produce a particular identifier value. This is generally not particularly difficult, as identifiers were never meant as a security feature. The actual method of identifier generation is not specified by the protocol specification, but the most common method of generating the identifier is to increment a one octet counter for each request, and include the counter value as the identifier. Because the identifier generation is normally deterministic, it often doesn't increase the work factor very much at all. An attacker can insert a series of extra requests to the client, forcing the desired identifier to reoccur much more rapidly than it would normally. Even if the identifier were not generated in a readily attackable way, it would still only increase the work factor by 256 times.
3.5.1 Passive User-Password Compromise Through Repeated Request Authenticators
If the attacker can sniff the traffic between the RADIUS client and the RADIUS server, they can passively produce a dictionary of Request Authenticators, and the associated (protected) User-Password attributes. If the attacker observes a repeated Request Authenticator, they can remove any influence of the Shared Secret from the first 16 octets of the passwords by XORing the first 16 octets of the protected passwords together. This yields the first 16 octets of the two (now unprotected) user passwords XORed together.
The impact of this attack varies according to how good the user passwords are. If the users all chose random passwords of the same length, the attacker can gain nothing because no information about either password can be extracted. Unfortunately, this is a somewhat unlikely occurrence. In reality, users choose passwords of varying lengths (generally less than 16 characters) and of varying quality.
The easiest problem for the attacker to exploit is the case where the two passwords are of different lengths. Ideally for the attacker, the passwords are both less than 16 characters long and are significantly different lengths. In this situation, one of the passwords has more padding than the other, so the non-overlapping characters of the longer password are XORed with '0' (the characters do not change). This results in the non-overlapping characters of the longer password being exposed to the attacker with no analysis.
More complex attacks are available if the attacker makes the assumption that the users chose low-entropy passwords. In this situation, the attacker can perform an intelligent dictionary attack guided by statistical analysis of the overlapping region. This dictionary attack can be further refined by noting the length of the two passwords and the trailing portion of the longer password, and then only trying passwords with this length and ending.
Even passwords longer than 16 characters are at risk from this attack, because the attacker still gains information about the first 16 characters of the password. This provides a firm basis for later attack, if nothing else.
3.5.2 Active User-Password Compromise through Repeated Request Authenticators
The attacker can attempt to authenticate many times using known passwords and intercept the generated Access-Request packets, extracting the Request Authenticator and User-Password attributes. The Attacker can then XOR the known password with the User-Password attribute and be left with the MD5(Shared Secret + Request Authenticator) value. The attacker generates a dictionary of Request Authenticator values and associated MD5(Shared Secret + Request Authenticator) values.
When the attacker sees a valid Access-Request packet that has a Request Authenticator value that is in the attacker's dictionary, the attacker can recover the first 16 octets from the protected region of the User-Password field by looking up the associated MD5(Shared Secret + Request Authenticator) value from the dictionary and XORing it with the intercepted protected portion of the User-Password attribute.
3.5.3 Replay of Server Responses through Repeated Request Authenticators
The attacker can build a dictionary of Request Authenticators, identifiers and associated server responses. When the attacker then sees a request that uses a Request Authenticator (and associated identifier) that is in the dictionary, the attacker can masquerade as the server and replay the previously observed server response.
Further, if the attacker can attempt to authenticate, causing the client to produce an Access-Request packet with the same Request Authenticator and identifier as a previously observed successful authentication, the attacker can replay the valid looking Access-Accept server response and successfully authenticate to the client without knowing a valid password.
3.5.4 DOS Arising from the Prediction of the Request Authenticator
If the attacker can predict future values of the Request Authenticator, the attacker can pose as the client and create a dictionary of future Request Authenticator values (with either the expected identifier, or with every possible identifier) and associated (presumably Access-Reject) server responses. The attacker can then masquerade as the server and respond to the client's (possibly valid) requests with valid looking Access-Reject packets, creating a denial of service.
3.6 Shared Secret Hygiene
The RADIUS standard specifically permits use of the same Shared Secret by many clients. This is a very bad idea, as it provides attackers with more data to work from and allows any flawed client to compromise several machines. All RADIUS clients that possesses the same shared secret can be viewed as a single RADIUS client for the purpose of all these attacks, because no RADIUS protection is applied to the client or server address.
Most client and server implementations only allow shared secrets to be input as ASCII strings. There are only 94 different ASCII characters that can be entered from a standard US style keyboard (out of the 256 possible). Many implementations also restrict the total length of the shared secret to 16 characters or less. Both of these restrictions artificially reduce the size of the keyspace that an attacker must search in order to guess the shared secret.
4 Conclusions
4.1 Summary Findings
The RADIUS protocol has several interesting issues that arise from its design. The design and policy characteristics that seem to be principally responsible for the security problems are as follows:
- The User-Password protection technique is flawed in many ways. It should not use a stream cipher, and it should not use MD5 as a cipher primitive. (note 3.2; attacks 3.3, 3.4, 3.5.1, 3.5.2)
- The Response Authenticator is a good idea, but it is poorly implemented. (attack 3.1)
- The Access-Request packet is not authenticated at all. (attack 3.4)
- Many client implementations do not create Request Authenticators that are sufficiently random. (all attacks in 3.5)
- Many administrators choose RADIUS shared secrets with insufficient information entropy. Many client and host implementations artificially limit the shared secret key space. (note 3.6)
4.2 Suggested Protocol Additions
Selection of a well understood symmetric block cipher to protect the user password would be good practice. A new User-Password like attribute that uses an alternate encryption scheme should be created. I suggest TDES (as specified in ANSI X9.52) used in CBC mode. If this new attribute is used, the User-Password attribute should not be.
Ideally the block cipher would be keyed independently from the shared secret, but this may prove unworkable for compatibility reasons. Another option would be to key the cipher from some derived value of the shared secret and the request authenticator. For instance the cipher could be keyed from the output of an HMAC of the Request Authenticator (where the HMAC is keyed by the shared secret) or by seeding a cryptographic PRNG with the shared secret and the request authenticator.
Instead of using an ad hoc keyed hash primitive in the Response Authenticator, an accepted Message Authentication Code (MAC) should be used. An HMAC would be an ideal choice for this primitive. In addition, the Access-Request packet would benefit from authentication.
Though MD5 is a cryptographic hash that could be used in the HMAC primitive, it has several significant attacks against it. The RADIUS protocol would benefit from using SHA-1 instead of MD5 for HMACs.
In order to protect the Access-Request, Access-Accept and Access-Deny packets, a new attribute should be created that contains a SHA-1-HMAC of the entire RADIUS packet (with the SHA-1-HMAC attribute data set to 0). If this attribute is present, the receiving client or server should compute the HMAC for the entire RADIUS packet (with the HMAC set to zeros) and verify that the result is the same as the stored HMAC. If the result is not the same, the packet should be discarded.
When the server generates a RADIUS Access-Accept or Access-Reject packet with a SHA-1-HMAC, it should set the Response Authenticator to the associated Request Authenticator. If a client receives a RADIUS Access-Accept or Access-Reject packet that has the SHA-1-HMAC attribute, it should not test for the validity of the Response Authenticator.
When a client generates a RADIUS Access-Request packet, it should include the SHA-1-HMAC attribute. When the server receives a RADIUS Access-Request packet, it should verify the SHA-1-HMAC attribute.
There is just such an attribute defined as a RADIUS Extension in RFC 2869, called the Message-Authenticator. This attribute contains the output from an MD5 based HMAC, keyed with the shared secret, of the entire RADIUS packet. This attribute adequately protects RADIUS packets that include this attribute. Unfortunately, this attribute is not required to be consistently used (in fact, it is only required to be used when the new EAP-Message attribute is used). RFC 2869 does suggest that this attributes be used in cases where the User-Password attribute is not included in the RADIUS Access-Request packet; unfortunately, the vulnerability seen in section 3.4 requires that the User-Password attribute is in use. Further, RFC 2869 does not suggest that the server and client should have a mode where packets received without the Message-Authenticator are discarded. Without this mode, the attacker can simply strip off the Message-Authenticator attribute from a RADIUS client Access-Request packet, modify the packet and then replay the resulting packet. (It should be noted that the attacker cannot strip off this attribute from a server Access-Accept or Access Reject packet, as that message is separately authenticated by the Response Authenticator).
The Message-Authenticator attribute could provide an effective defense if it were required to be more consistently used. Clients and servers should be able to be placed in a mode where RADIUS packets without the Message-Authenticator attribute are silently discarded.
4.3 Suggested Client Behavior Modifications
Authenticator Behavior
The RADIUS specification should require a strong cryptographic PRNG for generation of the Request-Authenticator, such as the PRNG specified in ANSI X9.17 appendix C or FIPS 186-2, appendix 3.
Shared Secret Behavior
The RADIUS specification should require each RADIUS client use a different Shared Secret. It should also require the shared secret to be a random bit string at least 16 octets long that was generated by a strong cryptographic PRNG.
In order to facilitate entry of this bit string, clients and servers should allow for input of arbitrary binary data. Quite likely, the easiest solution is to allow for the entry of hexadecimal digits.
4.4 General Comments
Both servers and clients should support the base RADIUS protocol and this extended RADIUS protocol. Both the server and the client should allow the administrator to enable the use of these RADIUS extensions on a client-by-client basis. This should be an explicit configuration option, not just an automatic determination made by the server. An automatic determination made by the server could lead to an attack where the attacker attempts to force the client/server interactions into the old RADIUS mode.
If it is not possible to change the RADIUS protocol, the system can still be made much more secure by just following the suggestions in section 4.3, which can all be implemented while still remaining completely compliant with the existing RADIUS protocol.
4.5 Why Modify RADIUS?
So, why attempt to modify RADIUS at all? Why not just go to another (presumably more modern, more secure) protocol? Well, for the most part, the answer is "Because such a protocol doesn't currently exist." In the near future, however, Diameter is likely to be released by the IETF.
Diameter is the planned RADIUS replacement. The great majority of all the protocol work that has gone into Diameter has been directed to removing some of the functional limitations imposed by the RADIUS protocol. Effectively no work has been done as relates to the client/server security of the protocol. (CMS is defined, but this is a security layer for the proxy to proxy interaction, not the client to proxy/server interaction)
So, does this mean that they continue to use even RADIUS's ad hoc system? No, they removed all security functionality from the protocol. They did the protocol designer's equivalent of punting. Section 2.2 of the current Diameter protocol spec says:
"Diameter clients, such as Network Access Servers (NASes) and Foreign Agents MUST support IP Security, and MAY support TLS. Diameter servers MUST support TLS, but the administrator MAY opt to configure IPSec instead of using TLS. Operating the Diameter protocol without any security mechanism is not recommended."
So, all security aspects of the protocol are handled by IPSec and/or TLS. From a security aspect, this strikes me as a very good idea. Both IPSec and TLS are fully featured (sometimes too fully featured) protocols that many people have reviewed. (That's already much better than RADIUS ever did).
Examining this from a slightly different angle gives me some cause for concern, however. It strikes me that the overhead imposed by a full TLS/IPSec implementation is very significant for many current-day embedded devices. This would seem to indicate that (at least in the near future) manufactures are going to either continue to use RADIUS or ignore the Diameter standard and perform Diameter without TLS or IPSec.
Because of this, I suspect that it would be advantageous to push for at least minimal RADIUS protocol revision.
5 Document Change History
- (2001-11-13) Modified section 1.1 to remove references to CHAP, as CHAP is not sent using the User-Password attribute. (Thanks to Barney Wolff for pointing this out)
- (2001-11-13) Changed the bibliography reference from RFC 2138 to RFC 2865. The update in RFCs does not change any of the analysis in this document. Also added a reference to RFC 2869.
- (2001-11-13) Modified section 4.2 to include a small discussion about RFC 2869's Message-Authenticator attribute and associated guidance included in the RFC.
- (2001-11-13) Modified the document so that "DIAMETER" is more properly referred to as "Diameter". (Thanks to Barney Wolff for pointing this out)
- (2001-11-14) Reformatted some bibliography references and added some contact information at the beginning of the document.
- (2001-11-24) Modified the reference in section 4.4 that read "section 5.3" to correctly read "section 4.3".
6 Previous Work
There has been some independent previous work with the RADIUS protocol:
Attacks 3.5.3 and 3.5.4 are likely the attacks referred to in the RADIUS RFC.
The known password attack on the shared secret using the Access-Request packet (attack 3.3) appears to have been first observed in September, 1996 by Thomas H. Ptacek.
Paper #1
The known password attack on the shared secret using the Access-Request packet (attack 3.3), and the shared secret attack on the Access-Reject and Access-Accept packets (attack 3.1) were independently observed in July, 1997 by Reilly (rich.friedeman@ANIXTER.COM)
Shared Secret Recovery in RADIUS
7 Acknowledgements
Thanks go to:
- Mark Smith (mark@halibut.com), who provided very useful comments regarding passwords greater than 16 bytes long.
- The Halibutians, for uncovering various grammatical and phrasing issues.
- Barney Wolff, who pointed me toward the updated RADIUS RFCs, allowing me to discuss the implications of the Message-Authenticator. Thanks also for setting me straight on a few DIA... errr... Diameter issues. :-)
- Andrew Pimlott, for pointing out some section numbering inaccuracies.
8 Bibliography
RFC 2865, "Remote Authentication Dial In User Service (RADIUS)", by C. Rigney, S. Willens, A. Rubens, W. Simpson. June 2000.
RFC 2869, "RADIUS Extensions", by C. Rigney, W. Willats, P. Calhoun. June 2000.
The DIAMETER Base Protocol, by Pat R. Calhoun, Haseeb Akhtar, Jari Arkko, Erik Guttman, Allan C. Rubens, Glen Zorn. July 2001.
DIAMETER CMS Security Application, by Pat R. Calhoun, Stephen Farrell, William Bulley. July 2001.
The Handbook of Applied Cryptography, by Alfred J Menezes, Paul C. van Ooschot, Scott A. Vanstone.
Chapter 5, chapter 6 and chapter 9. Most notably:
The MD5 based stream cipher as a synchronous stream cipher (6.1.1, ii)
The use of cryptographic functions in pseudorandom number generation is discussed in section 9.2.6.
The use of a MDC in the creation of a MAC is discussed in 9.5.2.
An Analysis of the TACACS+ Protocol and its Implementations by Solar Designer. July 2000.
RADIUS( Remote Access Dial In User Service) Protocol主要用來提供Authentication機制，用來辨認使用者的身份與密碼，確認通過之後，經由Authorization授權使用者登入網域使用相關資源，並可提供Accounting機制，保存使用者的網路使用記錄。
本校早期使用radius來做電話撥接上網的身份認證, 因ADSL的普及(超過60%以上的家庭)及各大ISP均提供免費撥接, 故已不再使用RADIUS來做撥接上網的身份認證 。
RADIUS在本校主要有三個用途:
- 校內無線網路使用者身份認證
- 跨校園無線網路漫遊使用者身份認證
- 代理快取伺服器校外使用者身份認證
N牌和A牌顯示卡對應表
NV 6800 Ultra 256MB
NV 6800 256MB
NV 7300GT 256MB
NV 7600GT 256MB
ATI X1650 PRO 512MB
ATI X1600 512/256MB
ATI 3650 512MB
ATI 1950 PRO 512/256MB
以上這幾張該選哪一張好呢... ? 還是有更好的選擇?
現在ATI正夯 該選ATI嗎?
3650有比1950PRO來的好嗎?
感覺1950 PRO好像比較優的感覺!!
1950PRO的3d效能確實比較高，
畢竟也算是一代卡王，不過是dx9世代的，
追求3d遊戲效能的話這張應該是首選，
不過3650有dx10，還有hd解碼功能，算是扳回一點點
以規格支援度來說,的確是3650勝
不過也只因為X1950是3650上兩代的顯卡...
只是我從某硬體網站的文章中找出等級之分
X1950PRO比3650(DDR3)還高兩個等級,
在以X1950PRO可以支援的特效下跑的話,3650應該還是會輸...
但是以目前整體來說個人會建議買3650(DDR3),不僅是低耗電,溫度也低
只是單單以效能來說,X1950PRO還是贏的...
資料來自 http://www.thg.com.tw/article_000128009.html
以下是兩個幫助你判斷的指標。下表將總體效能相近的各顯示卡加以歸類區分，越上層的顯示卡表示效能越高。
你可以根據此表比較顯示卡的價格，判斷最划算的交易、以及升級的可能性。除非新款顯示卡在此表中的階級比你目前所用的高出三級以上，否則不建議你升級。如果你堅持要升級，可能會發現升級前後的效能差不多：
| Nvidia GeForce | Ati Radeon |
| 8800 GTX | |
| 8800 GTS | |
| 7950 GX2 | |
| | X1950 XT、X1900 XTX、X1950 XTX |
| 7800 GTX 512、7900 GTX | X1900 XT |
| 7800 GTX、7950 GT | X1800 XT、X1900 AIW、X1900 GT、X1950 PRO |
| 7800 GT、7900 GS | X1800 XL |
| 7600 GT | X800 XT PE、X850 XT PE、X1650 XT、X1800 GTO |
| 6800 Ultra、7800 GS | X800 XT、X850 XT |
| 6800 GT、6800 GS (PCI-E) | X800 XL、X800 GTO2/GTO16 |
| 6800 GS (AGP) | X800 GTO 256mb、X800 PRO、X850 PRO |
| 6800、7300 GT GDDR3、7600 GS | X800、X800 GTO 128mb、X1600 XT、X1650 PRO |
| 6600 GT、6800LE、6800 XT、7300 GT DDR2 | 9800 XT、X700 PRO、X800 GT、X800 SE、X1300 XT、X1600 PRO |
| FX 5900、FX 5900 Ultra、FX 5950 Ultra、6600 (128-bit)、7300 GS | 9700、9700 PRO、9800、9800 PRO、X700、X1300 PRO |
| FX 5800 Ultra、FX 5900 XT、7300 LE | 9500 PRO、9600 XT、9800 PRO (128-bit)、X600 XT |
| 4 Ti 4600、4 Ti 4800、FX 5700 Ultra、6200 | 9600 PRO、9800 SE、X600 PRO |
| 4 Ti4200、4 Ti4400、4 Ti4800 SE、FX 5600 Ultra、FX 5700、6600 (64-bit) | 9500、9550、9600、X300 |
| 3 Ti500、FX 5200 Ultra、FX 5600、FX 5700 LE、6200 TC、6600 LE | 8500、9100、9000 PRO、9600 SE、X300 SE |
| 3、3 Ti200、FX 5200 (128-bit) | 9000、9200 |
| FX 5200 (64 bit) | 9200 SE |
| 2 GTS、4 MX 440、2 Ultra、2 Ti200 | 7500 |
| 256、2 MX 200、4 MX 420、2 MX 400 | SDR、LE、DDR、7000、7200 |
| Nvidia TNT Nvidia TNT | ATI Rage 所有系列 |
用来替换文件的replace
用来替换文件的replace，连正在使用的文件也能替换。非常无敌。
原文網址
比如：在C：\下建一个目录，c：\aaa
然后复制一首mp3到c:\aaa并命名为c:\aaa\a.mp3
然后再复制另一首歌到C:\a.mp3
然后用mediaplayer播放c:\aaa\a.mp3
在命令提示符下输入：replace c:\a.mp3 c:\aaa
过一会，是不是播放的歌已变为另一首。
用这个命令来替换系统文件真是太爽了，并且XP的系统文件保护也对它无效。
再也不用到安全模式下去替换文件了
格式
REPLACE[drive1:][path1]filename[drive2:][path2][/A][/P][/R][/W]
REPLACE[drive1:][path1]filename[drive2:][path2][/P][/R][/S][/W]
[drive1:][path1]filename指定源文件。
[drive2:][path2]指定要替换文件的
目录。
/A把新文件加入目标目录。不能和
/S或/U命令行开关搭配使用。
/P替换文件或加入源文件之前会先提示您
进行确认。
/R替换只读文件以及未受保护的
文件。
/S替换目标目录中所有子目录的文件。
不能与/A命令选项
搭配使用。
/W等您插入磁盘以后再运行。
/U只会替换或更新比源文件日期早的文件。
不能与/A命令行开关搭配使用原文網址
必须掌握的八个DOS命令
一，ping
它是用来检查网络是否通畅或者网络连接速度的命令。作为一个生活在网络上的管理员或者黑客来说，ping命令是第一个必须掌握的DOS命 令，它所利用的原理是这样的：网络上的机器都有唯一确定的IP地址，我们给目标IP地址发送一个数据包，对方就要返回一个同样大小的数据包，根据返回的数 据包我们可以确定目标主机的存在，可以初步判断目标主机的操作系统等。下面就来看看它的一些常用的操作。先看看帮助吧，在DOS窗口中键入：ping
/? 回车，。所示的帮助画面。在此，我们只掌握一些基本的很有用的参数就可以了（下同）。
-t
表示将不间断向目标IP发送数据包，直到我们强迫其停止。试想，如果你使用100M的宽带接入，而目标IP是56K的小猫，那么要不了多久，目标IP就因为承受不了这么多的数据而掉线，呵呵，一次攻击就这么简单的实现了。
-l 定义发送数据包的大小，默认为32字节，我们利用它可以最大定义到65500字节。结合上面介绍的-t参数一起使用，会有更好的效果哦。
-n
定义向目标IP发送数据包的次数，默认为3次。如果网络速度比较慢，3次对我们来说也浪费了不少时间，因为现在我们的目的仅仅是判断目标IP是否存在，那么就定义为一次吧。
说明一下，如果-t 参数和 -n参数一起使用，ping命令就以放在后面的参数为标准，比如“ping IP -t -n
3”，虽然使用了-t参数，但并不是一直ping下去，而是只ping 3次。另外，ping命令不一定非得ping
IP，也可以直接ping主机域名，这样就可以得到主机的IP。
下面我们举个例子来说明一下具体用法。
这里time=2表示从发出数据包到接受到返回数据包所用的时间是2秒，从这里可以判断网络连接速度的大小
。从TTL的返回值可以初步判断被ping主机的操作系统，之所以说“初步判断”是因为这个值是可以修改的。这里TTL=32表示操作系统可能是win98。
（小知识：如果TTL=128，则表示目标主机可能是Win2000；如果TTL=250，则目标主机可能是Unix）
至于利用ping命令可以快速查找局域网故障，可以快速搜索最快的QQ服务器，可以对别人进行ping攻击……这些就靠大家自己发挥了。
二，nbtstat
该命令使用TCP/IP上的NetBIOS显示协议统计和当前TCP/IP连接，使用这个命令你可以得到远程主机的NETBIOS信息，比如用户名、所属的工作组、网卡的MAC地址等。在此我们就有必要了解几个基本的参数。
-a 使用这个参数，只要你知道了远程主机的机器名称，就可以得到它的NETBIOS信息（下同）。
-A 这个参数也可以得到远程主机的NETBIOS信息，但需要你知道它的IP。
-n 列出本地机器的NETBIOS信息。
当得到了对方的IP或者机器名的时候，就可以使用nbtstat命令来进一步得到对方的信息了，这又增加了我们入侵的保险系数。
三，netstat
这是一个用来查看网络状态的命令，操作简便功能强大。
-a 查看本地机器的所有开放端口，可以有效发现和预防木马，可以知道机器所开的服务等信息，如图4。
这里可以看出本地机器开放有FTP服务、Telnet服务、邮件服务、WEB服务等。用法：netstat -a IP。
-r 列出当前的路由信息，告诉我们本地机器的网关、子网掩码等信息。用法：netstat -r IP。
四，tracert
跟踪路由信息，使用此命令可以查出数据从本地机器传输到目标主机所经过的所有途径，这对我们了解网络布局和结构很有帮助。如图5。
这里说明数据从本地机器传输到192.168.0.1的机器上，中间没有经过任何中转，说明这两台机器是在同一段局域网内。用法：tracert IP。
五，net
这个命令是网络命令中最重要的一个，必须透彻掌握它的每一个子命令的用法，因为它的功能实在是太强大了，这简直就是微软为我们提供的最好的入侵工具。首先让我们来看一看它都有那些子命令，键入net
/?回车如图6。
在这里，我们重点掌握几个入侵常用的子命令。
net view
使用此命令查看远程主机的所以共享资源。命令格式为net view\\IP。
net use
把远程主机的某个共享资源影射为本地盘符，图形界面方便使用，呵呵。命令格式为net use x:
\\IP\sharename。上面一个表示把192.168.0.5IP的共享名为magic的目录影射为本地的Z盘。下面表示和192.168.0.7建立IPC$连接（net
use\\IP\IPC$"password" /user:"name"），
建立了IPC$连接后，呵呵，就可以上传文件了：copy nc.exe
\\192.168.0.7\admin$，表示把本地目录下的nc.exe传到远程主机，结合后面要介绍到的其他DOS命令就可以实现入侵了。
net start
使用它来启动远程主机上的服务。当你和远程主机建立连接后，如果发现它的什么服务没有启动，而你又想利用此服务怎么办？就使用这个命令来启动吧。用法：net
start servername，如图9，成功启动了telnet服务。
net stop
入侵后发现远程主机的某个服务碍手碍脚，怎么办？利用这个命令停掉就ok了，用法和net start同。
net user
查看和帐户有关的情况，包括新建帐户、删除帐户、查看特定帐户、激活帐户、帐户禁用等。这对我们入侵是很有利的，最重要的，它为我们克隆帐户提供了前提。键入不带参数的net
user，可以查看所有用户，包括已经禁用的。下面分别讲解。
1，net user abcd 1234 /add，新建一个用户名为abcd，密码为1234的帐户，默认为user组成员。
2，net user abcd /del，将用户名为abcd的用户删除。
3，net user abcd /active:no，将用户名为abcd的用户禁用。
4，net user abcd /active:yes，激活用户名为abcd的用户。
5，net user abcd，查看用户名为abcd的用户的情况
原文網址
2008年8月1日 星期五
常用的RBL服务器列表及介绍
目前RBL服务器一般采用DNS查询或DNS区域传输的方法.国内的RBL服务器比较少，而且数据库比较小.国外的RBL服务器维护的数据库比较大,但使用起来由于国际网络原因经常有超时现象发生.企业应该根据自己收到的垃圾邮件的种类来选择合适的RBL.下面说几个常用的:
国内的:
国内的实时黑名单服务（RBL）做的最大的就是anti-spam. 它的官方网站是: www.anti-spam.org.cn
它提动的实时黑名单服务（RBL）主要包括四个部分：CBL、CDL和CBL+、CBL-。
CBL包含近期中国国内的主要垃圾邮件发送源。
CDL包含中国国内动态分配地址。
CBL+为CBL和CDL的合集。
CBL-是CBL+中去除了中国邮件服务运营商白名单服务（CML）的内容后的黑名单，该黑名单方便于既想使用实时黑名单，而又要保证在任何情况下都能收到来着他们的邮件的用户。
我们可以根据自己的实际情况选择下面的四种模式中的任意一种。
CBL: cbl.anti-spam.org.cn
CDL: cdl.anti-spam.org.cn
CBL+: cblplus.anti-spam.org.cn
CBL-: cblless.anti-spam.org.cn
注:anti-spam是免费的,但用户只能采用DNS查询的方法,它是不对用户开放DNS区域传输的.
国外的:
ORDB-RBL-------------------------------relays.ordb.org
spamhaus-------------------------------sbl.spamhaus.org
spamcop--------------------------------bl.spamcop.net
Infinite-Monkeys-----------------------proxies.relays.monkeys.com
NJABL----------------------------------dnsbl.njabl.org
osirusoft.com--------------------------relays.osirusoft.com
MAPS-RBL-------------------------------blackholes.mail-abuse.org
MAPS-DUL-------------------------------dialups.mail-abuse.org
MAPS-RSS-------------------------------relays.mail-abuse.org
MAPS-RBL+------------------------------rbl-plus.mail-abuse.ja.net
Easynet-DNSBL--------------------------blackholes.easynet.nl
Easynet-Proxies------------------------proxies.blackholes.easynet.nl
Easynet-Dynablock----------------------dynablock.easynet.nl
OSIRUSOFT-SPEWS------------------------spews.relays.osirusoft.com
咱们说几个比较大的:
(一)首先是spamhaus.org
最厉害，影响最大的要数Spamhaus项目组，网址 http://www.spamhaus.org 。只要被它列入黑名单，你的邮件服务器就算瘫痪了，因为据说全球80%以上的服务器会拒收从你的邮件服务器发去邮件。
它有三种类型：XBL，SBL，ROKSO。
（1）XBL（Exploits Block List）其实是它联盟成员的，主要封堵裸IP（没有相应域名），主要是由病毒劫持发送（如NetSky病毒），IP被禁后，没有解禁的可能。
（2）SBL（The Spamhaus Block List）是Spamhaus的强项，它封堵那些蓄意发送spam的IP（IP拥有者或其客户），不管发送者是谁，背景多深，它一视同仁，因此个人觉得它比较公正。国内两大商务网站——阿里巴巴和慧聪都不能幸免。
其它小商务网站和企业网站就更多了，大家可以登陆该组织网站查询。这些被封堵的IP的ISP主要是中国电信和中国网通，总体而论，网通比电信严重。
一旦你的IP被SBL后，切莫置之不理，试图更换IP继续发信是愚蠢的，Spamhaus会扩大封堵范围，比如你原来被封的IP是202.168.1.21，现在你换到202.168.1.87，被它发现后，可能从202.168.1.21到202.168.1.87的IP全部被封，这就会殃及池鱼。你应该及时与它的工作人员沟通，承认错误，保证不再明知故犯。
（3）ROKSO（The Register of Known Spam perations）那些屡教不改，明知故犯的SBL"死硬分子"和危险分子（贩毒，犯枪）有可能被打入ROKSO，如果这样，那恭喜你成为全球知名人士（网络世界的通缉犯）。Spamhaus会要求全球的ISP终止对你的一切服务（包括域名解析，网站服务），否则，这些ISP会连坐，Spamhaus会毫不犹豫地封它几个C段（6万多IP），甚至B段（1600多万IP）。想从ROKSO除名比登天还难！
由于中国部分ISP的漠视，中国的大量客户都遭受池鱼之灾，特别是一些企业用户，比如跟国外客户突然失去联系等，但他们被蒙在鼓里， 因为ISP不愿告诉他们真相.
(二）第二名Spamcop，网站 http://www.spamcop.net 。国内做邮件服务的，几乎都会撞到它枪口上。它封堵那些不符合国际的标准的邮件服务IP地址，每次封堵数小时到数日。它会影响至少40%的邮件。你屡发，它就屡封，除非你不发。我测试过sina.com，126.com，163.com，sohu.com，它们三天两头在spamcop上挂号。126.com，163.com，sohu.com比较诚实，在退信中写明原因——被spamcop记录了，但sina.com比较龌 龊，竟然欺骗用户，说是对方服务器的原因。总之，在一天之内，上述邮件服务器能够正常发送的没有几个小时。
Spamcop要求全部邮件服务器都要双向解析，即正向解析和反向解析。但国内绝大部分邮件服务商仅仅做正向解析，而没有反向解析。比较离谱的又是sina.com，它把邮件服务器域名正向解析到某个IP，但该IP竟然反向解析到其它域名。Spamcop经常向Spamhaus提交一些IP，被Spamhaus列入SBL。
（三）动态IP记录。IP静态和动态两种，提供主机托管的单位拥有静态IP。虽然通过动态IP（主要是XDSL拨号）也能发送电子邮件，但真正能够使对方接收到的，仅仅10%不到，那些群发组织或个人经常声称发送几十万个只要一点点钱，其实它们通过动态IP发送（它们不敢用静态IP，怕列入Spamhaus黑名单），再说，他们的邮件地址有多少是有效的呢？
这主要是国际上大量的组织在封堵动态IP，比较有名的有 http://www.gjabl.org ， http://www.sorb.org ，http://dsbl.org
另外:
spamhaus.org 的RBL是
SBL: sbl.spamhaus.org
XBL: xbl.spamhaus.org
SBL+XBL: sbl-xbl.spamhaus.org
而且spamhaus.org提供DNS区域传输,可以让用户把RBL内容同步到本地的DNS Server上,但这个功能不是免费的.价格根据你单位的邮箱用户数量和单位性质而不同.官方网站提供一个30天的试用.有兴趣的话可以试用一把.
spamcop.net的RBL是
bl.spamcop.net
国内的:
国内的实时黑名单服务（RBL）做的最大的就是anti-spam. 它的官方网站是: www.anti-spam.org.cn
它提动的实时黑名单服务（RBL）主要包括四个部分：CBL、CDL和CBL+、CBL-。
CBL包含近期中国国内的主要垃圾邮件发送源。
CDL包含中国国内动态分配地址。
CBL+为CBL和CDL的合集。
CBL-是CBL+中去除了中国邮件服务运营商白名单服务（CML）的内容后的黑名单，该黑名单方便于既想使用实时黑名单，而又要保证在任何情况下都能收到来着他们的邮件的用户。
我们可以根据自己的实际情况选择下面的四种模式中的任意一种。
CBL: cbl.anti-spam.org.cn
CDL: cdl.anti-spam.org.cn
CBL+: cblplus.anti-spam.org.cn
CBL-: cblless.anti-spam.org.cn
注:anti-spam是免费的,但用户只能采用DNS查询的方法,它是不对用户开放DNS区域传输的.
国外的:
ORDB-RBL-------------------------------relays.ordb.org
spamhaus-------------------------------sbl.spamhaus.org
spamcop--------------------------------bl.spamcop.net
Infinite-Monkeys-----------------------proxies.relays.monkeys.com
NJABL----------------------------------dnsbl.njabl.org
osirusoft.com--------------------------relays.osirusoft.com
MAPS-RBL-------------------------------blackholes.mail-abuse.org
MAPS-DUL-------------------------------dialups.mail-abuse.org
MAPS-RSS-------------------------------relays.mail-abuse.org
MAPS-RBL+------------------------------rbl-plus.mail-abuse.ja.net
Easynet-DNSBL--------------------------blackholes.easynet.nl
Easynet-Proxies------------------------proxies.blackholes.easynet.nl
Easynet-Dynablock----------------------dynablock.easynet.nl
OSIRUSOFT-SPEWS------------------------spews.relays.osirusoft.com
咱们说几个比较大的:
(一)首先是spamhaus.org
最厉害，影响最大的要数Spamhaus项目组，网址 http://www.spamhaus.org 。只要被它列入黑名单，你的邮件服务器就算瘫痪了，因为据说全球80%以上的服务器会拒收从你的邮件服务器发去邮件。
它有三种类型：XBL，SBL，ROKSO。
（1）XBL（Exploits Block List）其实是它联盟成员的，主要封堵裸IP（没有相应域名），主要是由病毒劫持发送（如NetSky病毒），IP被禁后，没有解禁的可能。
（2）SBL（The Spamhaus Block List）是Spamhaus的强项，它封堵那些蓄意发送spam的IP（IP拥有者或其客户），不管发送者是谁，背景多深，它一视同仁，因此个人觉得它比较公正。国内两大商务网站——阿里巴巴和慧聪都不能幸免。
其它小商务网站和企业网站就更多了，大家可以登陆该组织网站查询。这些被封堵的IP的ISP主要是中国电信和中国网通，总体而论，网通比电信严重。
一旦你的IP被SBL后，切莫置之不理，试图更换IP继续发信是愚蠢的，Spamhaus会扩大封堵范围，比如你原来被封的IP是202.168.1.21，现在你换到202.168.1.87，被它发现后，可能从202.168.1.21到202.168.1.87的IP全部被封，这就会殃及池鱼。你应该及时与它的工作人员沟通，承认错误，保证不再明知故犯。
（3）ROKSO（The Register of Known Spam perations）那些屡教不改，明知故犯的SBL"死硬分子"和危险分子（贩毒，犯枪）有可能被打入ROKSO，如果这样，那恭喜你成为全球知名人士（网络世界的通缉犯）。Spamhaus会要求全球的ISP终止对你的一切服务（包括域名解析，网站服务），否则，这些ISP会连坐，Spamhaus会毫不犹豫地封它几个C段（6万多IP），甚至B段（1600多万IP）。想从ROKSO除名比登天还难！
由于中国部分ISP的漠视，中国的大量客户都遭受池鱼之灾，特别是一些企业用户，比如跟国外客户突然失去联系等，但他们被蒙在鼓里， 因为ISP不愿告诉他们真相.
(二）第二名Spamcop，网站 http://www.spamcop.net 。国内做邮件服务的，几乎都会撞到它枪口上。它封堵那些不符合国际的标准的邮件服务IP地址，每次封堵数小时到数日。它会影响至少40%的邮件。你屡发，它就屡封，除非你不发。我测试过sina.com，126.com，163.com，sohu.com，它们三天两头在spamcop上挂号。126.com，163.com，sohu.com比较诚实，在退信中写明原因——被spamcop记录了，但sina.com比较龌 龊，竟然欺骗用户，说是对方服务器的原因。总之，在一天之内，上述邮件服务器能够正常发送的没有几个小时。
Spamcop要求全部邮件服务器都要双向解析，即正向解析和反向解析。但国内绝大部分邮件服务商仅仅做正向解析，而没有反向解析。比较离谱的又是sina.com，它把邮件服务器域名正向解析到某个IP，但该IP竟然反向解析到其它域名。Spamcop经常向Spamhaus提交一些IP，被Spamhaus列入SBL。
（三）动态IP记录。IP静态和动态两种，提供主机托管的单位拥有静态IP。虽然通过动态IP（主要是XDSL拨号）也能发送电子邮件，但真正能够使对方接收到的，仅仅10%不到，那些群发组织或个人经常声称发送几十万个只要一点点钱，其实它们通过动态IP发送（它们不敢用静态IP，怕列入Spamhaus黑名单），再说，他们的邮件地址有多少是有效的呢？
这主要是国际上大量的组织在封堵动态IP，比较有名的有 http://www.gjabl.org ， http://www.sorb.org ，http://dsbl.org
另外:
spamhaus.org 的RBL是
SBL: sbl.spamhaus.org
XBL: xbl.spamhaus.org
SBL+XBL: sbl-xbl.spamhaus.org
而且spamhaus.org提供DNS区域传输,可以让用户把RBL内容同步到本地的DNS Server上,但这个功能不是免费的.价格根据你单位的邮箱用户数量和单位性质而不同.官方网站提供一个30天的试用.有兴趣的话可以试用一把.
spamcop.net的RBL是
bl.spamcop.net
出处：5DMail.Net收集整理 作者：请作者联系 时间：2007-1-20 12:05:00
简单三步解决企业垃圾邮件难题
简单三步解决企业垃圾邮件难题
webtools page.
Welcome.
Here's my webtools page. Too many tools that I love on my UNIX system(s) are inaccessable to the average friend/co-worker of mine. Yet everyone has access to webpages. So my choices to help people out involve either giving shell accounts out and teaching people how to run specific UNIX comands or I could just write these tools on the web. So here they are (in order of writing):
NSLookup Gateway - queries 15 major US nameservers and several foreign nameservers
MXLookup Gateway - same as above, but it looks up the MX (Mail Exchanger) for hosts.
RBL Lookup - checks to see if a host/IP # is on any Realtime Blackhole Lists.
Whois Lookup - checks domain to see if its registered. And if so, it provides info on it.
Traceroute Tool - traces the route to said host and sends 10 packs and reports the results
Open Relay Tester Tool - attempts to relay a single message through a remote mail server
RWhois Lookup - Referral Whois, similar to whois but with more info
More to come as I think of it...
Whats New - Changes to this page since it's inception.
FAQ - Frequently asked questions
Encrypted Ted's Webtools (come on, everyone's doing it!).
http://www.mob.net/~ted/tools/index.html
Here's my webtools page. Too many tools that I love on my UNIX system(s) are inaccessable to the average friend/co-worker of mine. Yet everyone has access to webpages. So my choices to help people out involve either giving shell accounts out and teaching people how to run specific UNIX comands or I could just write these tools on the web. So here they are (in order of writing):
NSLookup Gateway - queries 15 major US nameservers and several foreign nameservers
MXLookup Gateway - same as above, but it looks up the MX (Mail Exchanger) for hosts.
RBL Lookup - checks to see if a host/IP # is on any Realtime Blackhole Lists.
Whois Lookup - checks domain to see if its registered. And if so, it provides info on it.
Traceroute Tool - traces the route to said host and sends 10 packs and reports the results
Open Relay Tester Tool - attempts to relay a single message through a remote mail server
RWhois Lookup - Referral Whois, similar to whois but with more info
More to come as I think of it...
Whats New - Changes to this page since it's inception.
FAQ - Frequently asked questions
Encrypted Ted's Webtools (come on, everyone's doing it!).
http://www.mob.net/~ted/tools/index.html
Xshell
Xshell is a powerful SSH1, SSH2, SFTP, TELNET, RLOGIN and SERIAL terminal emulator for Windows platforms. It allows users to gain access to Unix/Linux hosts easily and securely on a Windows workstation. SSH (Secure Shell) protocol supports encryption and user authentication for secure connections over the Internet, and it replaces legacy protocols such as TELNET and RLOGIN.
Xshell is designed to satisfy both beginners and advanced users. Its user interface is intuitive and it provides advanced users with powerful features such as local commands, searching with regular expressions, dynamic port forwarding, international languages and so forth.
http://www.netsarang.com/
Xshell is designed to satisfy both beginners and advanced users. Its user interface is intuitive and it provides advanced users with powerful features such as local commands, searching with regular expressions, dynamic port forwarding, international languages and so forth.
http://www.netsarang.com/
Install multiple versions of IE on your PC
Ever wanted to test your website in various versions of Internet Explorer?
http://tredosoft.com/Multiple_IE
http://tredosoft.com/Multiple_IE
2008年7月31日 星期四
上網時出現flash.ocx發生問題，而造成IE視窗必須關閉，該如何解決？
| 有時上網時會發生IE瀏覽器遇到附加元件上的問題，而必須關閉IE。這時候可以從錯誤訊息的畫面去了解發生問題的元件名稱。如以下錯誤訊息可以得知是 flash.ocx 發生問題，若將此錯誤訊息回報相關資料給微軟時，微軟的回覆表示此與Macromedia的Flash Player有關，而非windows系統本身發生問題。 flash.ocx錯誤有時瀏覽網頁會出現flash.ocx錯誤，這是因為網頁使用了新的flash技術 所以您需要下載新的flash player，下載請至 http://www.macromedia.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash 錯誤訊息： 解決方法： |
訂閱：
文章 (Atom)