Alternatively, you may use HFNetChk (see "Stay Current" under W1.5) to verify the presence of the corresponding patch:
You are probably vulnerable to sample application exploits if any of the following files resides in your %wwwroot%/scripts directory (e.g., C:\inetpub\wwwroot\scripts or D:\web\scripts) or any subdirectory thereof:
W1.5 How to Protect Against It
IIS 4 on NT 4:
IIS 4 on NT 4 Terminal Server Edition:
IIS 5 on Windows 2000:
IIS 5.1 on Windows XP:
W2.2 Operating Systems Affected
Most Microsoft Windows NT 4.0 systems running IIS 3.0 or 4.0, Remote Data Services 1.5, or Visual Studio 6.0.
W2.3 CVE Entries
W2.4 How to Determine if you are Vulnerable
If you are running Microsoft Windows NT 4.0 and IIS 3.0 or 4.0, then check for the existence of "msadcs.dll" (this is typically installed in "C:\Program Files\Common Files\System\Msadc\msadcs.dll", but that may vary depending on your system).
W2.5 How to Protect Against It
An excellent guide to the RDS and Jet weaknesses and how to correct them is available at http://www.wiretrip.net/rfp/p/doc.asp?id=29&iface=2.
Microsoft has also issued several security bulletins detailing this exploit and how to repair it via configuration changes:
W3.4 How to Determine if you are Vulnerable
If the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer is defined, then you have SQL Server or SQL Server Desktop Engine installed. If you are running an un-patched system or you have not updated your system with the latest patch, your system is very likely to be vulnerable.
Microsoft has developed the Microsoft Baseline Security Analyzer (MBSA). MBSA will scan for missing hotfixes and vulnerabilities in SQL Server 7.0 and 2000. It is available at http://www.microsoft.com/technet/security/tools/Tools/MBSAhome.as p.
Microsoft also has a HOWTO document to help you check your current version: HOW TO: Identify Your SQL Server Service Pack Version and Edition.
To ensure the fix is installed properly, verify the individual files by consulting the date/time stamp of the files listed in the file manifest in Microsoft Knowledge Base article. They can be found at:
Although this is a powerful and useful feature of Windows, improper configuration of network shares may expose critical system files, or may provide a mechanism for a nefarious user or program to take full control of the host. One of the ways in which both the Sircam virus (see CERT Advisory 2001-22) and Nimda worm (see CERT Advisory 2001-26) spread so rapidly in the summer of 2001 was by discovering unprotected network shares and placing a copy of itself in them. Many computer owners unknowingly open their systems to hackers when they try to improve convenience for co-workers and outside researchers by making their drives readable and writeable by network users. But when care is taken to ensure proper configuration of network shares, the risks of compromise can be adequately mitigated.
W4.2 Operating Systems Affected
Windows 95, Windows 98, Windows NT, Windows Me, Windows 2000, and Windows XP are all vulnerable.
W4.3 CVE Entries
CAN-1999-0519, CVE-2000-0979, CAN-2000-1079, CVE-2000-0044, CAN-1999-0621, CAN-1999-0520,
W4.4 How to Determine if you are Vulnerable
For Windows NT (SP4), Windows 2000 or Windows XP, the Microsoft Baseline Security Advisor, will report hosts are vulnerable to SMB exploits, and may be used to fix the problem. The tests can be run locally or on remote hosts.
network-based scanners will detect open shares. A quick, free, and secure
test for the presence of SMB file sharing and its related vulnerabilities,
effective for machines running any Windows operating system, is available at
the Gibson Research Corporation web site at http://grc.com/. Follow links to "ShieldsUP" to receive a
real-time appraisal of any system's SMB exposure. Detailed instructions are
available to help Microsoft Windows users deal with SMB vulnerabilities.
Note that if you are connected over a network where some intermediate device
blocks SMB, the ShieldsUP tool will report that you are not vulnerable when,
in fact, you are. This is the case, for example, for users on a cable modem
where the provider is blocking SMB into the cable modem network. ShieldsUP
will report that you are not vulnerable. However, the 4,000 or so other
people on your cable modem link can still exploit this vulnerability.
W4.5 How to Protect Against It
Several actions can be taken to mitigate the risk of exploitation of a vulnerability through a Windows Networking Shares:
net use \\a.b.c.d\ipc$ "" /user:""(where a.b.c.d is the IP address of the remote system).
If you receive a "connection
failed" response, then your system is not vulnerable. If no reply comes back
that means that the command was successful and your system is vulnerable.
"Hunt for NT" can also be used. It is a component of the NT Forensic Toolkit from http://www.foundstone.com/.
W5.5 How to Protect Against It
Domain controllers require Null sessions to communicate. Therefore, if you are working in a domain environment, you can minimize the information that attackers can obtain, but you cannot stop all leakage. To limit the information available to attackers, modify the following registry key:
Each of these articles discusses a variant on a cross-site scripting
vulnerability, some aspects of which may not yet be completely solved by
the patch. Please see http://sec.greymagic.com/adv/gm010-ie/ for more
information. If possible, it is generally good strategy to disable
scripting wherever it is not necessary.
To maintain your system's protection, keep abreast of any new IE updates with Windows Update, HFNetChk, or the Microsoft Baseline Security Analyzer (MBSA). You can also get general IE update information from Microsoft's Internet Explorer Home.
Return to the Beginning of This Document
In addition, a collection of command line shell scripts that will test
for registry access permissions and a range of other related security
concerns is available for download at http://www.afentis.com/top20.
W9.5 How to Protect Against It
To address this threat, access to the system registry must be restricted and the permissions set for critical registry keys reviewed. Users of Microsoft Windows NT 4.0 should also ensure that Service Pack 3 (SP3) has been installed before adjusting the registry. PLEASE NOTE: Editing the system Registry can have serious effects on the performance and operation of the computer and in extreme cases may cause irreparable damage and require reinstallation of the operating system.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg Description: REG_SZ Value: Registry ServerSecurity permissions set on this key define the Users or Groups that are permitted remote Registry access. Default Windows installations define this key and set the Access Control List to provide full privileges to the system Administrator and Administrators Group (and Backup Operators in Windows 2000).
Key Name: SecurePipeServers Class: REG_SZ
Key Name: winreg Class: REG_SZ
Value Name: Description Data Type: REG_SZ String: Registry Server
Value: Machine Value Type: REG_MULTI_SZ - Multi string Default Data: System\CurrentControlSet\Control\ProductOptionsSystem\ CurrentControlSet\Control\Print\PrintersSystem\CurrentControlSet\ Services\EventlogSoftware\Microsoft\WindowsNT\CurrentVersionSystem\ CurrentControlSet\Services\Replicator Valid Range: (A valid path to a location in the registry) Description: Allow machines access to listed locations in the registry provided that no explicit access restrictions exist for that location.
Value: Users Value Type: REG_MULTI_SZ - Multi string Default Data: (none) Valid Range: (A valid path to a location in the registry) Description: Allow users access to listed locations in the registry provided that no explicit access restrictions exist for that location.In the Microsoft Windows 2000 and Windows XP Registry:
Value: Machine Value Type: REG_MULTI_SZ - Multi string Default Data: System\CurrentControlSet\Control\ProductOptionsSystem\ CurrentControlSet\Control\Print\PrintersSystem\CurrentControlSet\ control\Server ApplicationSystm\CurrentControlSet\Services\Eventlog\ Software\Microsoft\Windows NT\CurrentVersion Value: Users (does not exist by default)
Remote procedure calls (RPCs) allow programs on one computer to execute procedures on a second computer by passing data and retrieving the results. RPC is therefore widely used for many distributed network services such as remote administration, NFS file sharing, and NIS. However there are multiple flaws in RPC which are being actively exploited. In many cases, RPC services execute with root privileges, and as a consequence, systems that offer vulnerable RPC services can provide an attacker with unauthorized remote root access. There is compelling evidence that the majority of the distributed denial of service attacks launched during 1999 and early 2000 were executed by systems that had been victimized through these RPC vulnerabilities. The broadly successful attack on U.S. Military systems during the Solar Sunrise incident also exploited an RPC flaw found on hundreds of Department of Defense computer systems.
U1.3 CVE Entries
CVE-1999-0166, CVE-1999-0167, CVE-1999-0168, CVE-1999-0170, CVE-1999-0211, CVE-1999-0977,
CVE-1999-0018, CVE-2000-0666, CVE-1999-0002, CVE-2001-0803, CVE-1999-0493, CAN-2002-0573,
CVE-2001-0717, CVE-1999-0003, CVE-1999-0019, CVE-1999-0208, CVE-1999-0696, CVE-1999-0693,
CVE-1999-0008, CVE-2001-0779, CAN-2002-0033, CAN-2002-0391, CAN-2002-0677, CAN-2002-0679,
U1.4 How to Determine if you are Vulnerable
Use a vulnerability scanner or the 'rpcinfo' command to determine if you are running one of the most commonly exploited RPC services:
RPC Program Number
U1.5 How to Protect Against It
Use the following steps to protect your system against RPC attacks:
For Solaris Software Patches:
For IBM AIX Software Patches:
For SGI Software Patches:
For Compaq (Digital Unix) Software Patches:
For Linux Software Patches:
A summary document pointing to specific guidance about three principal RPC vulnerabilities - Tooltalk, Calendar Manager, and Statd - may be found at: http://www.cert.org/incident_notes/IN-99-04.html
Summary documents pointing to specific guidance about the above RPC vulnerabilities may be found at:
Exploits of core Apache or its modules in the recent past have been few, but they have been well-documented and quickly utilized in attacks. Among the most recent:
Moreover, no web server can be considered secure until it is considered in the context of its interaction with web applications, especially CGI programs and databases. A hardened Apache configuration can still yield unauthorized access to data if CGI scripts are not themselves verified or database access controls not properly set. CGI scripts execute with the same permissions as the web server, so a malicious or just poorly written CGI script is just as dangerous as a software flaw in Apache. Unfortunately, these weaknesses on the back end of the web server remain problems today.
It is also imperative to harden the OS to truly prevent a web content from being modified or stolen. Although that is true for all running services, the fact that web services tend to have an external exposure lends itself to a false impression that they and the data they protect are somehow independent of the rest of the system. How failure to address this issue left one system vulnerable to attack is explained in http://www.wired.com/news/technology/0,1282,43234,00.html.
U2.2 Operating Systems Affected
Nearly all Linux systems and many other Unix systems come with Apache installed and often by fault enabled. All Unix systems are capable of running Apache. (Windows administrators should be aware that the version of Apache for Windows is likely subject to the same or similar vulnerabilities.)
U2.3 CVE Entries
CAN-2002-0392, CAN-2002-0061, CVE-1999-0021, CVE-1999-0172, CVE-1999-0266, CVE-1999-0067,
CVE-1999-0260, CVE-1999-0262, CVE-2000-0010, CVE-1999-0174, CVE-1999-0066, CVE-1999-0146,
CAN-2002-0513, CAN-2002-0682, CAN-2002-0257, CVE-2000-0208, CVE-2000-0287, CVE-2000-0941,
CAN-2000-0832, CVE-1999-0070, CVE-2002-0082, CAN-2002-0656, CAN-2002-0655, CVE-2001-1141,
CAN-2002-0657, CAN-1999-0509, CVE-1999-0237, CVE-1999-0264
U2.4 How to Determine if you are Vulnerable
Check to see what the latest version and patch level is at the Apache web site: http://httpd.apache.org/. If your version is not the most recent, then your server is likely vulnerable. This site also maintains a list of most recent vulnerabilities and documentation on how to determine if you are vulnerable to them.
U2.5 How to Protect Against It
The following steps should be taken to help protect an Apache web server:
For more Apache security information, see http://www.sans.org/Gold/apache.php and http://www.infosecuritymag.com/articles/april01/features1_web_server_sec.shtml.
The SSH1 protocol itself has been demonstrated to be potentially vulnerable to having a session decrypted in transit given certain configurations. For this reason, administrators are encouraged to use the stronger SSH2 protocol whenever possible.
In addition, users of OpenSSH should note that the OpenSSL libraries against which OpenSSH is typically built have software vulnerabilities of their own. Please see CERT Advisory 2002-23 for more details. They should also be aware that a trojan-horse version of the OpenSSH was being distributed for a short-time in summer 2002. Please see http://www.openssh.org/txt/trojan.adv for details about ensuring that your version is not affected
U3.2 Operating Systems Affected
Any Unix or Linux system running OpenSSH 3.3 or earlier, or SSH Communication Security's SSH 3.0.0 or earlier.
U3.3 CVE Entries
For ssh from SSH Communication Security:
CVE-2000-0575, CVE-2000-0992, CVE-2001-0144, CVE-2001-0361, CAN-2001-0471, CVE-2001-0553, CVE-2001-0259
CVE-2000-1169, CVE-2001-0144, CVE-2001-0361, CVE-2001-0872, CVE-2000-0525,
CAN-2001-0060, CAN-2002-0002, CAN-2002-0575, CAN-2002-0639, CAN-2002-0083, CAN-2002-0640,
CAN-2002-0656, CAN-2002-0655, CVE-2001-1141, CAN-2002-0657
U3.4 How to Determine if you are Vulnerable
Use a vulnerability scanner to see whether you are running a vulnerable version, or check the software version reported by running the command 'ssh -V'.
U3.5 How to Protect Against It
snmpwalk. Additional information can be found at http://www.zend.com/manual/function.snmpwalk.php. A good tutorial on this tool can be found at http://www.sans.org/newlook/resources/IDFAQ/SNMP.htm.
/etc/ftpusersfile and add the usernames "anonymous" and "ftp" in it (on separate lines). This file sets which users should not be allowed to login to FTP server. To add an additional layer of security, also remove the "ftp" user from the password file.
/etc/hosts.allowfile, you will allow access only from a specific IP address or domain. You should then put "in.ftpd: ALL" in
/etc/hosts.denyto block access from all others, and confirm that FTP daemon is started via "tcpd" in
/etc/inetd.conf. Some Linux distributions (such as RedHat) use an enhanced version of inetd called xinetd, which contains the TCP wrapper code and will check the above files by default. Refer to the manual for the tips on xinetd configuration.
/etc/ftpusersfile so that those accounts cannot be accessed by FTP.
~/.rhostsfile on machine B. All users can rsh, rcp, rlogin or rexec from machine A to machine B without having to re-authenticate if the name or address of machine A is in machine B's
R-services suffer from the two most fundamental flaws in network connections: lack of encryption and poor host authentication. The transmission of information between R-command clients and R-services in plain-text permits data or keystrokes to be intercepted. The fact that R-services simply accept the name or address presented by a connecting client permits that information to be forged. Without established trust relationships, users are forced to send passwords over the network in the clear. With trust relationships, an attacker can assume the identity of a valid user on a valid host, and use it to gain access to all other machines that trust the hacked machine.
Nearly all versions of Unix and Linux come with R-services installed and often enabled.
CVE-1999-0113, CVE-1999-0627, CVE-1999-0180, CAN-1999-0651, CAN-1999-0515
U6.4 How to Determine if you are
The R-services run out of a meta-server called "inetd," or on some systems, "xinetd." Inetd will permit rsh or rcp connections if there is an entry for "in.rshd" (the specific name may vary slightly for your distribution) in
/etc/inet/inetd.conf. Likewise, rexec requires an entry for
"in.rexecd," and rlogin an entry for "in.rlogind." Xinetd works similarly,
expecting a file named after each service it starts to appear in the
Trust relationships have been
established on a machine if there are entries in the
/etc/hosts.equiv file, or in the
of any valid user.
U6.5 How to Protect Against It
Disable the R-services on any system where they are not absolutely necessary. Secure shell (ssh, available from either OpenSSH or SSH Communications Security) and its compliments of scp and sftp can far more securely replace the functionality of all R-services. If R-services are absolutely necessary, disable trust relationships and use TCP Wrappers to log all connection attempts, restrict access to specific hosts, and provide host verification. TCP Wrappers functionality is already built into xinetd.
To disable trust
relationships, remove the
/etc/hosts.equiv file and the
~/.rhosts file of any user. If you must use trust
relationships, never use the "+" (wildcard) character, as it can be used
to allow any user or any machine (or worse, any user from any machine) to
login with proper credentials, and be sure to use TCP Wrappers. Never use
~/.rhosts to permit
password-less root authentication.
U7.4 How to Determine if you are
Since every Unix or Linux operating system comes with some sort of print server installed, and since even those which use a replacement for LPD (like LPRng) call their service "lpd" or "in.lpd," you should check with your operating system vendor to verify that you are running the latest version or patch provided, and if not consider your system vulnerable.
U7.5 How to Protect Against It
Please see CERT Advisory 2001-30 for specific remedy information for your operating system. Solaris users should also see CERT Advisory 2001-15 and Sun Security Bulletin #00206.
If your machine does not need to act as a print server for
remote requests, you may be able to minimize the risk of future
vulnerabilities in LPD by disabling the "in.lpd" service in inetd or
xinetd. For inetd, comment out the "in.lpd" entry in
restart inetd. For xinetd, add a "disable = yes" line to the "in.lpd" file
and restart xinetd. If you do need to service remote print requests,
restrict what hosts can connect to in.lpd with TCP Wrappers.
You can provide some protection against buffer overflows by enabling a non-executable stack on those operating systems that support this feature. While a non-executable stack will not protect against all buffer overflows, it can hinder the exploitation of some standard buffer overflow exploits publicly available on the Internet.
Most of these exploits are successful only against older versions of the software. In fact, Sendmail has not had a 'high' severity vulnerability in more two years. Despite the fact that these older problems are well documented and have been repaired in newer releases, there remain so many outdated or mis-configured versions still in use today that Sendmail remains one of the most frequently attacked services.
The risks presented by running Sendmail can be grouped into two major categories: privilege escalation caused by buffer overflows, and improper configuration that allows your machine to be a relay for electronic mail from any other machine. The former is a problem on any system still running older versions of the code. The latter results from using either improper or default configuration files, and is a chief obstacle to fighting the proliferation of spam.
Operating Systems Affected
Nearly all Unix and Linux systems come with a version of Sendmail installed and often by default enabled.
U8.3 CVE Entries
CVE-1999-0206, CVE-1999-0203, CVE-1999-0204, CVE-1999-0047, CAN-1999-0512, CVE-1999-0130,
CVE-1999-0131, CVE-1999-0393, CVE-1999-1309, CVE-2001-0653, CVE-2000-0319, CVE-1999-1109,
U8.4 How to Determine if you are
Sendmail has had a large number of vulnerabilities in the past. Don't always trust the version string returned by the daemon as that is just read from a text file on the system that may not have been updated properly.
Check to see what the latest version (if you built from source) or patch level (if it came packaged with your operating system) is for Sendmail; if you are not running it, you are probably vulnerable.
U8.5 How to Protect Against It
The following steps should be taken to protect Sendmail:
A number of factors contribute to this condition. Chief among them are administrators who are not aware of security upgrades, systems which are running BIND daemon (called "named") unnecessarily, and bad configuration files. Any of these can effect a denial of service, a buffer overflow or DNS cache poisoning. Among the most recently discovered BIND weaknesses was a denial of service, discussed in CERT Advisory CA-2002-15. In this case, an attacker can send specific DNS packets to force an internal consistency check which itself is vulnerable and will cause the BIND daemon to shut down. Another was a buffer overflow attack, discussed in CERT Advisory CA-2002-19, in which an attacker utilizes vulnerable implementations of the DNS resolver libraries. By sending malicious DNS responses, the attacker can explore this vulnerability and execute arbitrary code or even cause a denial of service.
In addition to the risk a vulnerable BIND poses to the server which hosts it, a single compromised machine may provide a platform for malicious activity targeting other machines on the Internet, or be used as a repository of illicit material without the administrator's knowledge.
Operating Systems Affected
Nearly all Unix and Linux systems come with a version of BIND installed and often by default enabled. Binary versions of BIND do exist for Windows.
U9.3 CVE Entries
CVE-1999-0009, CVE-1999-0833, CVE-2001-0010, CVE-2001-0011, CVE-2001-0013, CVE-1999-0024,
CVE-2001-0012, CVE-1999-0837, CVE-1999-0848, CVE-1999-0849, CAN-2002-0400
U9.4 How to Determine if you are Vulnerable
If you are running a version of BIND that came with your operating system, verify that you are current with the patches released by your vendor. If you are running BIND as built from source from the Internet Software Consortium (ISC), ensure that you are using the latest version of BIND. Any unpatched or outdated version of the software is likely to be vulnerable.
For most systems, the command "named -v" will show the installed BIND version, enumerated as X.Y.Z where X is the major version, Y is the minor version, and Z is a patch level. There are currently three major versions for BIND: 4, 8 and 9. If you are running BIND built from source, you should eschew version 4 for the latest version of 8 or preferably 9. You can retrieve the latest source from the ISC.
A more complete approach would be to use an updated vulnerability scanner to periodically check your DNS system against new flaws.
U9.5 How to Protect Against It
The most common password vulnerabilities are that (a) user accounts have weak or nonexistent passwords, (b) regardless of the strength of their password, users fail to protect it, (c) the operating system or additional software creates administrative accounts with weak or nonexistent passwords, and (d) password hashing algorithms are known and often hashes are stored such that they are visible by anyone. The best and most appropriate defense against these is a strong password policy which includes thorough instructions for good password habits and proactive checking of password integrity.
U10.2 Operating Systems Affected
Any operating system or application where users authenticate via a user ID and password.
U10.3 CVE Entries
U10.4 How to Determine if you are Vulnerable
On local systems, password hashes are stored in either
/etc/passwd needs to be readable by
all users on the network to permit authentication to complete. If that
file also includes the password hashes, then any user with access to the
system can read the hashes and attempt to break them with a password
/etc/shadow can be used alternatively to store the
hashes, and should only be readable by root. If your local accounts are
not protected by
/etc/shadow, then the risk to your passwords
is extremely high.
If you use NIS, then password hashes are readable by all users and passwords are similarly high risks. This may also be the case with some implementations of LDAP as a network authentication service.
But even if password hashes are protected, passwords can be guessed by other means. Although there are observable symptoms of general password weakness, such as the existence of active accounts for users who have departed the organization or services which are not running, the only way to know for certain that each individual password is strong is to test all of them against the same password cracking tools used by attackers. PLEASE NOTE: Never run a password scanner, even on systems for which you have root-like access, without explicit and preferably written permission from your employer. Administrators with the most benevolent of intentions have been fired for running password cracking tools without authority to do so.
The best cracking tools available are:
A good password, therefore cannot have a word or proper name as its root. A strong password policy should direct users to generate passwords from something more random, like a phrase, or the title of a book or song. By concatenating a longer string (taking the first letter of each word, or substituting a special character for a word, removing all the vowels, etc.), users can generate sufficiently long strings which combine alphanumeric and special characters in a way which dictionary attacks will have great difficulty cracking. And if the string is easy to remember, then the password should be as well.
Once users are given the proper instructions for generating good passwords, procedures should be put in place to assure that these instructions are followed. The best way to do this is by validating the password whenever the user changes it. Most flavors of Unix can use Npasswd as a front-end to check entered passwords against your password policy. PAM-enabled systems can also be extended to include cracklib (the libraries which accompany Crack).
If passwords cannot be verified against dictionary libraries when they are entered, then cracking utilities should be run in a stand-alone mode as part of routine scanning. AGAIN PLEASE NOTE: Never run a password scanner, even on systems for which you have root-like access, without explicit and preferably written permission from your employer. Administrators with the most benevolent of intentions have been fired for running password cracking tools without authority to do so. Once you have acquired authority to run cracking utilities on your system, do so regularly on a protected machine. Users whose passwords are cracked should be notified confidentially and given instructions on how to choose a good password. Administrators and management should develop these procedures together, so that management can provide assistance when users do not respond to these notifications.
Another way to protect against nonexistent or weak passwords is to use an alternative form of authentication such as password-generating tokens or biometrics. If you are having trouble with weak passwords, use an alternative means of authenticating users.
/etc/passwd, update your system to use use
/etc/shadow. If your system runs NIS or LDAP in such a way that hashes cannot be protected, anyone (even non-authenticated users) can read your password hashes and attempt cracking. You should therefore secure proper permission and run proactive cracking as a regular practice.
Even if passwords themselves are strong, accounts can be compromised if users do not protect their passwords. Good policy should include instructions that a user should never tell his or her password to anyone else, should never write a password down where it could be read by others, and should properly secure any files in which a password is stored to automate authentication (passwords are easier to protect when this practice is only used when absolutely necessary). Password aging should be enforced so that any passwords which slip through these rules are only vulnerable for a short window of time, and old passwords should not be reused. Make sure that the users are given warning and chances to change their password before it expires. When faced with the message: "your password has expired and must be changed," users will tend to pick a bad password.
In addition to these ports, you should also block: