WHAT'S NEW?
Loading...
Showing posts with label Network Security. Show all posts
Showing posts with label Network Security. Show all posts

IT administrators are often so busy just trying to keep up with the obvious security threats that many more problems fly under the radar. Here are 10 security risks you may have in your organization that you are not aware of.

1: Your employees

Your own employees are your biggest source of security risks. Sometimes, it is deliberate; sometimes, it is not. Employees have the most access and the most time. We expend a lot of effort worrying about external threats, but in all honesty, all it takes is an employee bringing in a virus from a home PC on a USB drive to nullify all your forward-facing firewalls and measures. Disgruntled employees sometimes express their anger by hurting your computer systems. And of course, it is possible for a well-meaning employee to make a major mistake. Good governance, education, setting (and enforcing) policies, and knowing your employees are your best steps to closing the holes here.

2: Common coding mistakes

Certain mistakes in programming still get made despite years of warnings and education. Most common are SQL injection and cross-site scripting vulnerabilities. I still see these issues from time to time even in major software packages that you would think are trustworthy (WordPress is a good example). It’s hard to change software once you’ve installed it, so you need to keep these packages up to date even though it is quite a hassle.

3: Unauthorized machines

I’ve seen this one too many times. Someone decides to bring in an old PC and put it on the network to do something your existing infrastructure doesn’t allow them to do. They think that they are being helpful, working around the limitations of the IT department. After all, if IT won’t build a Web site for their group, it’s just “doing them a favor” to set up an old PC in the corner with a Web server on it, right? Wrong. The best way I’ve found to keep these rogue machines in line is with rigorous IP address audits and policies and scanning the network to create a list of machines. If machines can’t get IP addresses, they can’t do much harm.

4: Ancient “rock solid” servers

We all have them — that server buried deep in the data room that “just won’t quit.” Usually, it’s running some software package that is impossible to migrate to another machine. Sadly, these machines are often major security risks because they typically are no longer getting patches or we fail to patch them out of fear of breaking them. In addition, those older versions of operating systems often come with inherent security holes that no patching can fix. You need to replace these servers one way or the other. The best first step is to virtualize them. From there, it is a lot easier to try to update them.

5: Legacy applications

It’s not just the old servers that are big security risks; it is also the applications running on them, as well as other legacy applications you may have running. These applications would be a lot less problematic if they were current with their patches, but usually they aren’t. All too often, we miss a major version update because the upgrade is so difficult, and then we’re so far behind the ball that it’s impossible to catch up. Or perhaps the applications are completely discontinued. It’s painful to say it, but the best thing you can do is find a migration path to a recent version or another package entirely.

6: Local admins

We all know the dangers of allowing users to run with escalated privileges. Still, we occasionally end up with users being granted local admin rights inappropriately. In my experience, this often happens while troubleshooting a problem: We make the user a local admin to see if it fixes a problem and we forget to undo it. Regardless of how it occurs, it is a ticking time bomb for security. Use your central administration tools to make sure that the local admin list gets reset on a regular basis to the proper users and groups.

7: Incorrect share/file permissions

File permissions are tricky things, and most users are not even aware of how to set them. So what happens? Users create sensitive files in their usual networked location and those files get the default permissions, which are “collaboration friendly” to say the least. The next thing you know, everyone can read the documents, which are supposed to be confidential. Your best weapon is to pre- establish a share and file structure with the correct permissions. For example, give everyone a home directory for personal documents and create shares or directories around roles, projects, and teams with the appropriate permissions. The hard part is then educating them to use the correct locations — but that is much easier than trying to teach them permissions.

8: Hidden servers within applications

I have seen more and more applications lately that use a local Web server as an administration console. Sometimes, these applications are installed by users without permission. But occasionally, the IT department just does not realize what comes with an application. While these servers can be locked down so that they are not a risk (and with luck, they get installed like that), you need to verify that the applications are secured properly before allowing them to be installed on users’ machines.

9: VPN clients

Some users figure out how to set up VPN access on their personal machines. For a power user, it isn’t too hard to do. But you have no control over that machine, and once it is on the VPN, problems with the unauthorized machine can easily spill over onto the VPN. One thing you can do is audit the VPN systems to see who is connecting from what PCs and compare it to your list of authorized systems. Also, you can put additional firewalls around VPN clients to quarantine them. Finally, there are various systems to ensure that the clients connecting are on a preapproved list.

10: Disabled security software

Security software often puts up roadblocks to getting work done, so the “logical response” from many users is to find a way to work around it. For example, I’ve seen people set up anonymizers at home to sidestep IT policies. Power users (especially developers and system administrators) often know how to circumvent security tools. They may also be local administrators because of a technical need, which makes disabling software and changing settings even easier.
Combatting this is tough because these users often assume that they are “too smart” to be a security risk. What they fail to realize is that the modern crop of security threats do not require the user to make a mistake, like going to an obviously suspect Web site or downloading pirated software. Every Acrobat file, for example, is a potential plague rat at this point. Start looking for unusual trends, like large amounts of consistent traffic to an IP address and use centralized tools to ensure that settings are at the right levels and are reset periodically. Also, take any unnecessary local administration rights and firewall entire groups onto their own network segment to limit damage if those groups have a legitimate need for lower security.

Although network security has always been important, the stakes have never been higher than they are today. Network security should be a major priority for every organization. These 10 simple tips can help.

1: Reduce the attack surface whenever possible

One of the first steps you should take when hardening a machine is to reduce its attack surface. The more code that’s running on a machine, the greater the chance that the code will be exploitable. You should therefore uninstall any unnecessary operating system components and applications.

2: Use only reputable applications

Given the current economic climate, it might be tempting to use freeware, deeply discounted, or open source applications. While I will be the first to admit that I use a handful of such applications in my own organization, it is critically important to do a little bit of research before adopting such an application. Some free or low cost applications are designed to serve ads to users; others are designed to steal personal information from users or track their Internet browsing habits.

3: Use a normal user account when you can

As a best practice, administrators should use normal user accounts when they can. If a malware infection occurs, the malware generally has the same rights as the person who is logged in. So of course that malware could be far more damaging if the person who is logged in has administrative permissions.

4: Create multiple Administrator accounts

In the previous section, I discussed the importance of using a regular user account whenever possible and using an Administrative account only when you need to perform an action that requires administrative permissions. However, this does not mean that you should be using the domain Administrator account.
If you have multiple administrators in your organization, you should create a personalized administrator account for each of them. That way, when an administrative action is performed, it is possible to tell who did it. For example, if you have an Administrator named John Doe, you should create two accounts for that user. One will be the normal account for day-to-day use, and the other will be an administrative account to be used only when necessary. The accounts might be named JohnDoe and Admin-JohnDoe.

5: Don’t go overboard with audit logging

Although it may be tempting to create audit policies that track every possible event, there is such a thing as too much of a good thing. When you perform excessive auditing, the audit logs grow to massive sizes. It can be nearly impossible to find the log entries you’re looking for. Rather than audit every possible event, it is better to focus on auditing only the events that matter the most.

6: Make use of local security policies

Using Active Directory based group policy settings does not nullify the need for local security policy settings. Remember that group policy settings are enforced only if someone logs in using a domain account. They do nothing if someone logs into a machine using a local account. Local security policies can help to protect your machines against local account usage.

7: Review your firewall configuration

You should use a firewall at the network perimeter and on each machine on your network, but that alone isn’t enough. You should also review your firewall’s port exceptions list to ensure that only the essential ports are open.
A lot of emphasis is typically placed on the ports that are used by the Windows operating system, but you should also be on the lookout for any firewall rules that open ports 1433 and 1434. These ports are used for monitoring and remotely connecting to SQL server and have become a favorite target for hackers.

8: Practice isolation of services

Whenever possible, you should configure your servers so that they perform one specific task. That way, if a server is compromised, the hacker will gain access to only a specific set of services. I realize that financial constraints often force organizations to run multiple roles on their servers. In these types of situations, you may be able to improve security without increasing costs by using virtualization. In certain virtualized environments, Microsoft allows you to deploy multiple virtual machines running Windows Server 2008 R2 for the cost of a single server license.

9: Apply security patches in a timely manner

You should always test patches before applying them to your production servers. However, some organizations really go overboard with the testing process. While I certainly do not deny the importance of ensuring server stability, you have to balance the need for adequate testing with the need for adequate security.
When Microsoft releases a security patch, the patch is designed to address a well-documented vulnerability. This means that hackers already know about the vulnerability and will be specifically looking for deployments in which the patch that corrects that vulnerability has not yet been applied.

10: Make use of the Security Configuration Wizard

The Security Configuration Wizard allows you to create XML-based security policies, which can then be applied to your servers. These policies can be used to enable services, configure settings, and set firewall rules. Keep in mind that the policies created by the Security Configuration Wizard are different from security templates (which use .INF files) Furthermore, you can’t use group policies to deploy Security Configuration Wizard policies.



  • iPhone SSL Warning and Safari Phishing


  • RFC 1918 Blues


  • Slowloris HTTP DoS


  • CSRF And Ignoring Basic/Digest Auth



  • Hash Information Disclosure Via Collisions - The Hard Way


  • Socket Capable Browser Plugins Result In Transparent Proxy Abuse


  • XMLHTTPReqest “Ping” Sweeping in Firefox 3.5+


  • Session Fixation Via DNS Rebinding


  • Quicky Firefox DoS


  • DNS Rebinding for Credential Brute Force


  • SMBEnum


  • DNS Rebinding for Scraping and Spamming


  • SMB Decloaking


  • De-cloaking in IE7.0 Via Windows Variables


  • itms Decloaking


  • Flash Origin Policy Issues


  • Cross-subdomain Cookie Attacks


  • HTTP Parameter Pollution (HPP)


  • How to use Google Analytics to DoS a client from some website.


  • Our Favorite XSS Filters and how to Attack them


  • Location based XSS attacks


  • PHPIDS bypass


  • I know what your friends did last summer


  • Detecting IE in 12 bytes


  • Detecting browsers javascript hacks


  • Inline UTF-7 E4X javascript hijacking


  • HTML5 XSS


  • Opera XSS vectors


  • New PHPIDS vector


  • Bypassing CSP for fun, no profit


  • Twitter misidentifying context


  • Ping pong obfuscation


  • HTML5 new XSS vectors


  • About CSS Attacks


  • Web pages Detecting Virtualized Browsers and other tricks


  • Results, Unicode Left/Right Pointing Double Angel Quotation Mark


  • Detecting Private Browsing Mode


  • Cross-domain search timing


  • Bonus Safari XXE (only affecting Safari 4 Beta)


  • Apple's Safari 4 also fixes cross-domain XML theft


  • Apple's Safari 4 fixes local file theft attack


  • A more plausible E4X attack


  • A brief description of how to become a CA


  • Creating a rogue CA certificate


  • Browser scheme/slash quirks


  • Cross-protocol XSS with non-standard service ports


  • Forget sidejacking, clickjacking, and carjacking: enter “Formjacking”


  • MD5 extension attack


  • Attack - PDF Silent HTTP Form Repurposing Attacks


  • XSS Relocation Attacks through Word Hyperlinking


  • Hacking CSRF Tokens using CSS History Hack


  • Hijacking Opera’s Native Page using malicious RSS payloads


  • Millions of PDF invisibly embedded with your internal disk paths


  • Exploiting IE8 UTF-7 XSS Vulnerability using Local Redirection


  • Pwning Opera Unite with Inferno’s Eleven


  • Using Blended Browser Threats involving Chrome to steal files on your computer


  • Bypassing OWASP ESAPI XSS Protection inside Javascript


  • Hijacking Safari 4 Top Sites with Phish Bombs


  • Yahoo Babelfish - Possible Frame Injection Attack - Design Stringency


  • Gmail - Google Docs Cookie Hijacking through PDF Repurposing & PDF


  • IE8 Link Spoofing - Broken Status Bar Integrity


  • Blind SQL Injection: Inference thourgh Underflow exception


  • Exploiting Unexploitable XSS


  • Clickjacking & OAuth


  • Google Translate - Google User Content - File Uploading Cross - XSS and Design Stringency - A Talk


  • Active Man in the Middle Attacks


  • Cross-Site Identification (XSid)


  • Microsoft IIS with Metasploit evil.asp;.jpg


  • MSWord Scripting Object XSS Payload Execution Bug and Random CLSID Stringency


  • Generic cross-browser cross-domain theft


  • Popup & Focus URL Hijacking


  • Advanced SQL injection to operating system full control (whitepaper)


  • Expanding the control over the operating system from the database


  • HTML+TIME XSS attacks


  • Enumerating logins via Abuse of Functionality vulnerabilities


  • Hellfire for redirectors


  • DoS attacks via Abuse of Functionality vulnerabilities


  • URL Spoofing vulnerability in bots of search engines (#2)


  • URL Hiding - new method of URL Spoofing attacks


  • Exploiting Facebook Application XSS Holes to Make API Requests


  • Unauthorized TinyURL URL Enumeration Vulnerability

  • McAfee Mal Web map
    Red means danger. And orange offers plenty of risk, too.
    (Credit: McAfee)

    McAfee's third annual "Mapping the Mal Web" report, released Wednesday, looks at riskiest and safest domains across the globe. The small nation on the west coast of Africa reached the top spot this year with 36.7 percent of its sites posing a security risk. Because .cm is often a typo for .com, McAfee said, cybercrooks like to use that domain to set up typo-squatted sites to hit you with malware.You may want to think twice if you hit a site with a .cm extension. That belongs to Cameroon, pegged by McAfee as the world's riskiest domain.
    The generic and widely used .com domain itself isn't much safer, according to McAfee, jumping from ninth last year to second this year in riskiness, with 32.2 percent of its sites potentially hazardous to your PC's health.
    (Credit: McAfee)
    Romania (.ro) is tagged as the riskiest domain for malicious downloads, with 21 percent of its sites delivering payloads of viruses, spyware, and adware. The information (.info) domain is seen by McAfee as the most "spammy," with 17.2 percent of its sites generating junk mail.
    On the positive side, the government (.gov) is the safest generic domain with essentially 0 percent risk, while Japan (.jp) proved the safest country domain with a rating of only 0.1 percent. Last year's riskiest domain, Hong Kong (.hk) dropped to 34th place with a risk rating of only 1.1 percent, which McAfee attributed to the country's aggressive steps to stop scam-related domain registrations.
    (Credit: McAfee)
    "This report underscores how quickly cybercriminals change tactics to lure in the most victims and avoid being caught. Last year, Hong Kong was the riskiest domain and this year it is dramatically safer," Mike Gallagher, chief technology officer for McAfee Labs, said in a statement. "Cybercriminals target regions where registering sites is cheap and convenient, and pose the least risk of being caught."
    Overall, looking at 27 million Web sites and 104 top-level domains, McAfee found that 1.5 million sites, or 5.8 percent, were risky. That's up from 4.1 percent from the past two years, although the comparison is not direct since McAfee said it changed its rating methodology since then.
    McAfee noted that cybercriminals who create domains to scam people prefer registrars with cheap prices, volume discounts, and hefty refund policies. Crooks also like registrars with a "no questions asked" policy and that act slowly or not at all when informed of malicious domains.

    I have read research paper from University of California (Department of Information and Computer Science) written by Magda El Zarki, Sharad Mehrotra, Gene Tsudik and Nalini Venkatasubramanian which titled "Security Issues in a Future Vehicular Network".

    They have made an assumption that the security and privacy issues in vehicular network security are fairly common to most mobile and wireless network settings usch as authentication, data integrity, resistance to various denial-of-service attacks
    and so forth.

    In that paper, they highlighted a few important items for vehicular network security.

    · No confidentiality: the issue of data secrecy or confidentiality is not of concern in this network environment; none of the application scenarios we consider require any data to be kept secret. This is
    quite unusual in mobile networks. For example, in
    many modern cell phone networks (GSM, CDPD etc.) a secure channel is maintained between the cell phone and the nearest base station and/or local subscriber registry

    · No key distribution: most mobile network security architectures include provisions for key distribution. This is not only the case when an encrypted channel is set up; many settings require a key to be shared for authentication and data integrity reasons. In our case, key distribution is unnecessary for two reasons:

    1) there will be no bulk data transmitted (on a continuous basis) either among cars
    or between cars and roadside infrastructure, and,

    2) vehicles traveling at high speeds (as most do on highways) will likely spend little time within a cell of a given base station. Also, vehicles communicating in
    an ad hoc network broadcast their data, thus, pair-wise (or group-wise) key distribution is not needed.

    · No hand-over: typically, one of the notable security features of mobile networks is the secure hand-over protocol [3, 4], e.g., as a node moves from one cell to another, its state (including any on-going connection data) is handed over from one base station to the next. However, explicit hand-over is not needed if communication is largely one-way, i.e., vehicles reporting current speed and other parameters to the base stations.

    · No battery power concerns: this is actually the most important distinguishing factor of the network environment outlined in this proposal. In practically all mobile networks, power (CPU) consumption is a paramount concern. This includes not only power utilized for reception and transmission but also the power necessary to perform (usually expensive) cryptographic operations on weak and batterychallenged computing devices such as small PDAs, packet radios or cell phones. In our case, power consumption is not relevant since a running vehicle provides an ample source of battery power.

    · No CPU speed issues: a related concern in many mobile networks is the low CPU speed of the mobile node. Hence, there is usually a goal to minimize the use of cryptography because of the relatively long delays it imposes (e.g., an average Palm Pilot or Handspring PDA takes seconds to generate a digital signature). This often results in security protocols that are “contorted” to minimize the use of cryptography; sometimes, with disastrous consequences, e.g., the original GSM security architecture. Since “nodes” in our context are vehicles, more powerful (faster) CPUs can be assumed.

    · Extreme Time Sensitivity: as mentioned earlier, all data is very much time-sensitive. In applications such as VIVA, the needs for timeliness are only part of the problem. Time synchronization is also extremely important (although we can perhaps count on the GPS devices to provide accurate and uniform clock readings). Moreover, the system must be intolerant of replays (hostile and otherwise).

    Taking the above differences into account leads us to a fairly simple security architecture with the following notable features:

    · Digital Signatures: we require all broadcasts in VIVA as well as all “reports” in HITCH to be digitally signed by the originating vehicle. Since each vehicle (and the roadside infrastructure) will receive many more messages that it will send, the cost of signature verification is of more importance than that of signature generation. Therefore, at least at the beginning, we are likely to use RSA-based digital signatures (as opposed to, say, DSA). Of course, an appropriate message and signature format will be defined.

    · Time-stamping and sequencing: all communication in both applications will include both sequence numbers as well as timestamps. Clock synchronization is a non-issue, for the time being, as all vehicles and fixed infrastructure components are (per our assumption) equipped with GPS receivers and GPS is also a time service.

    · Certification Infrastructure (PKI): public key digital signatures are not particularly useful without a certification infrastructure. Designing a nimble, scalable and secure PKI has been a major challenge in the last decade. (See, for example, IETF PKI efforts.) We must take into account the unique aspects of our network environment in designing an appropriate PKI. Moreover, there are some recent and promising results in cryptography that obviate the need to public key certificates. For example, the Boneh/Franklin identity-based encryption system is an elegant method of obtaining public key cryptography without any certificates: in it, an entity’s public key is derived from a unique identity string, e.g., an email address or X.500 distinguished name. (This could be a vehicle identification number, in their case.)
    By: Bradley Mitchell

    Many folks setting up wireless home networks rush through the job to get their Internet connectivity working as quickly as possible. That's totally understandable. It's also quite risky as numerous security problems can result. Today's Wi-Fi networking products don't always help the situation as configuring their security features can be time-consuming and non-intuitive. The recommendations below summarize the steps you should take to improve the security of your home wireless network.

    1. Change Default Administrator Passwords (and Usernames)
    At the core of most Wi-Fi home networks is an access point or router. To set up these pieces of equipment, manufacturers provide Web pages that allow owners to enter their network address and account information. These Web tools are protected with a login screen (username and password) so that only the rightful owner can do this. However, for any given piece of equipment, the logins provided are simple and very well-known to hackers on the Internet. Change these settings immediately.

    2. Turn on (Compatible) WPA / WEP Encryption
    All Wi-Fi equipment supports some form of encryption. Encryption technology scrambles messages sent over wireless networks so that they cannot be easily read by humans. Several encryption technologies exist for Wi-Fi today. Naturally you will want to pick the strongest form of encryption that works with your wireless network. However, the way these technologies work, all Wi-Fi devices on your network must share the identical encryption settings. Therefore you may need to find a "lowest common demoninator" setting.

    3. Change the Default SSID
    Access points and routers all use a network name called the SSID. Manufacturers normally ship their products with the same SSID set. For example, the SSID for Linksys devices is normally "linksys." True, knowing the SSID does not by itself allow your neighbors to break into your network, but it is a start. More importantly, when someone finds a default SSID, they see it is a poorly configured network and are much more likely to attack it. Change the default SSID immediately when configuring wireless security on your network.

    4. Enable MAC Address Filtering
    Each piece of Wi-Fi gear possesses a unique identifier called the physical address or MAC address. Access points and routers keep track of the MAC addresses of all devices that connect to them. Many such products offer the owner an option to key in the MAC addresses of their home equipment, that restricts the network to only allow connections from those devices. Do this, but also know that the feature is not so powerful as it may seem. Hackers and their software programs can fake MAC addresses easily.

    5. Disable SSID Broadcast
    In Wi-Fi networking, the wireless access point or router typically broadcasts the network name (SSID) over the air at regular intervals. This feature was designed for businesses and mobile hotspots where Wi-Fi clients may roam in and out of range. In the home, this roaming feature is unnecessary, and it increases the likelihood someone will try to log in to your home network. Fortunately, most Wi-Fi access points allow the SSID broadcast feature to be disabled by the network administrator.

    6. Do Not Auto-Connect to Open Wi-Fi Networks
    Connecting to an open Wi-Fi network such as a free wireless hotspot or your neighbor's router exposes your computer to security risks. Although not normally enabled, most computers have a setting available allowing these connections to happen automatically without notifying you (the user). This setting should not be enabled except in temporary situations.

    7. Assign Static IP Addresses to Devices
    Most home networkers gravitate toward using dynamic IP addresses. DHCP technology is indeed easy to set up. Unfortunately, this convenience also works to the advantage of network attackers, who can easily obtain valid IP addresses from your network's DHCP pool. Turn off DHCP on the router or access point, set a fixed IP address range instead, then configure each connected device to match. Use a private IP address range (like 10.0.0.x) to prevent computers from being directly reached from the Internet.

    8. Enable Firewalls On Each Computer and the Router
    Modern network routers contain built-in firewall capability, but the option also exists to disable them. Ensure that your router's firewall is turned on. For extra protection, consider installing and running personal firewall software on each computer connected to the router.

    9. Position the Router or Access Point Safely
    Wi-Fi signals normally reach to the exterior of a home. A small amount of signal leakage outdoors is not a problem, but the further this signal reaches, the easier it is for others to detect and exploit. Wi-Fi signals often reach through neighboring homes and into streets, for example. When installing a wireless home network, the position of the access point or router determines its reach. Try to position these devices near the center of the home rather than near windows to minimize leakage.

    10. Turn Off the Network During Extended Periods of Non-Use
    The ultimate in wireless security measures, shutting down the network will most certainly prevent outside hackers from breaking in! While impractical to turn off and on the devices frequently, at least consider doing so during travel or extended periods offline. Computer disk drives have been known to suffer from power cycle wear-and-tear, but this is a secondary concern for broadband modems and routers.
    A basic Wi-Fi home network can be assembled fairly quickly. However, many homeowners aren't aware of all the options available for making their network better. Consider the below ideas for improving the capability, performance and security of your wireless home network.

    1. Upgrade and Add the Right Equipment
    Many homeowners have heard of basic Wi-Fi equipment like routers and wireless adapter cards. Many such products are available to choose from. The "best" choices are often unclear. Old equipment may need to be replaced with faster, more reliable or more compatible products. Folks also often fail to consider cool wireless gear like print servers, game adapters and video cameras. Before settling for a second-rate home network setup, do your research and acquire the right stuff at a good price.

    2. Install the Wireless Router / Access Point Strategically
    Some people quickly assemble their wireless home network only to find that it won't function in certain areas of the residence. Others enjoy a network functional at first but suffer quick disappointment later when it crashes as a microwave oven or cordless phone is turned on. Still others suffer from poor network performance but fear attempting to fix it. One easy way to address these common Wi-Fi networking problems is to move the wireless router (access point).

    3. Change the Wi-Fi Channel Number
    In the USA and most other countries, Wi-Fi equipment can transmit on any of several different "channels" similar to televisions. Most wireless routers ship with the same default channel number, and most homeowners never think about changing it. However, if a person experiences radio interference from a neighbor's router or some other piece of electronic equipment, changing the Wi-Fi channel just might be the best way to avoid it.

    4. Upgrade Wireless Router (Access Point) Firmware
    Wireless routers contain built-in programmable logic called firmware. A version of this firmware is installed on the router by the manufacturer, and this normally works well when first installing the device. However, many routers also offer a firmware upgrade capability that allows homeowners to install newer versions. Updated firmware can provide performance improvements, security enhancements or better reliability. As your router gets older, consider upgrading its firmware periodically.

    5. Improve Signal Strength and Range of the Wi-Fi Router (Access Point)
    No matter where in a residence a Wi-Fi router is installed, sometimes the wireless signal will simply not be strong enough. The likelihood of this problem increases with longer distances and with severe obstructions such as brick walls between the router and a Wi-Fi client. One way to solve this problem is to upgrade the Wi-Fi antenna installed on the router. Some routers do not support this option, but many do. The alternative involves installing an additional device called a wireless repeater.

    6. Improve Signal Strength and Range of Wi-Fi clients
    As with wireless routers, the signal strength of wireless clients can also be improved. Consider this option when faced with a Wi-Fi client that suffers from a very short range compared to the rest of the devices. This same technique can improve the ability of laptop computers to connect to Wi-Fi hotspots.

    7. Improve Wireless Network Security
    Many homeowners consider their wireless network a success when basic file and Internet connection sharing are functional. However, if proper security features are not in place, the work of network setup remains unfinished. Follow this checklist of essential steps for establishing and maintaining good Wi-Fi security on a home network.