Free Security Settings on SOHO Wireless and Wired Networks practice questions

On most home networks, the router's local management address is the same as the client's default gateway. Running ipconfig at a Command Prompt and reading the Default Gateway value for the active adapter gives you the correct IP to type into a browser, avoiding look-alike pages. Logging in to the ISP account portal is incorrect because that portal is a web account used for billing and service management; it may display some Wi-Fi settings but is not the router's full local admin interface, and it will typically prompt for an ISP email login rather than the device login. Pinging the DNS server address is incorrect because the DNS server may be an external ISP or public resolver address that has nothing to do with the router's local management page. Checking the DHCP lease of a wired printer is incorrect because that reveals only the printer's assigned IP, not the router's gateway address. The default gateway is the standard, fastest way to reach the router's admin page on a typical SOHO network.

The admin account controls Wi-Fi names, DNS, firewall rules, and firmware updates, so it should be protected with a long, unique passphrase because length resists guessing and password spraying better than short complexity. Storing it in a reputable password manager lets you generate and recall a strong random value safely. A short complex password reused from the Wi-Fi network is incorrect because the Wi-Fi password is shared more often and reuse means compromising one exposes the other. The default password with remote management enabled is incorrect because factory logins are widely published and enabling remote management makes the admin page reachable from the internet, combining two serious weaknesses. An eight-character password based on the company name is incorrect because it is both too short and personal/predictable, making it easy to guess. Best practice is a 16-24 character passphrase that is unique, non-personal, and kept separate from the Wi-Fi password.

Most IP filtering failures come from a single root cause: addresses move. DHCP assigns IPs dynamically, so a tablet that had one address last week may receive a different lease today. The rule still exists but now targets the wrong address or none at all, so the device slips past it. The fix is a DHCP reservation (static DHCP) that always hands the same IP to that device, keeping rules stable. The router firmware silently reverting the rule is incorrect because firmware does not remove individual filtering rules on its own; the rule was reported as still present. The tablet's MAC address being spoofed is incorrect because the rule is IP-based, not MAC-based, and spoofing a MAC is an intentional advanced action that is not the common everyday cause here. UPnP creating an exception is incorrect because UPnP creates inbound port-forwarding mappings, not outbound allowances that override an IP block. Pairing filters with DHCP reservations prevents this predictable outage.

An allow-list permits only the IPs you explicitly name and denies everything else, so the default answer becomes 'no.' This provides strong control that suits high-trust devices like an admin laptop, printer, or POS tablet, but it demands more upkeep because every new device or layout change requires a list update or you create surprise outages. Saying it permits everything by default with little upkeep is incorrect because that describes a block-list, which denies only named IPs and permits the rest. Saying it relies on MAC addresses that cannot be spoofed is incorrect on two counts: allow-lists here are IP-based, and MAC addresses can in fact be spoofed, which is why MAC filtering is treated as optional friction rather than primary defense. Saying it automatically adjusts when DHCP leases change is incorrect because no filter model self-adjusts to lease changes; stability requires DHCP reservations. Choose an allow-list only when you can clearly explain what should be allowed and why.

Firmware files are not interchangeable across a product line, so confirming the exact model name/number, the hardware revision (such as V1, V2, or Rev A), and any region or ISP variant is the critical first step. A file that 'almost matches' can turn a routine update into a recovery job. Performing a factory reset first is incorrect because a reset wipes Wi-Fi names, passwords, rules, and custom settings and may require ISP re-provisioning, which is a last resort, not a preparatory step. Disabling the firewall during the update is incorrect because it does not aid the update process and needlessly exposes the network. Downloading the file from a community forum mirror is incorrect because altered firmware images can add backdoors and corrupted files can fail mid-write; firmware should only come from the official vendor support site or app. After confirming the correct file, you back up the configuration, ensure stable power, use Ethernet, and avoid interrupting the process until the router reports the new version.

Universal Plug and Play (UPnP) lets devices request changes on the router automatically, most often by creating port-forwarding rules. The security concern is that UPnP can create inbound openings without clear user approval, so a compromised smart device could publish a service the owner never intended to expose. Disabling UPnP is often the safer default unless a specific feature requires inbound ports. DHCP reservations are incorrect because they simply ensure a device always receives the same IP address and do not open any ports to the internet. Content filtering is incorrect because it controls which domains or categories devices can reach, not inbound port exposure. Guest isolation is incorrect because it prevents guest devices from reaching the local LAN and admin interface, which improves security rather than creating exposure. The practical rule is: if you cannot name a feature that needs inbound ports, turn UPnP off and add narrow manual port forwards only when something breaks.

A screened subnet separates higher-risk devices from devices that hold sensitive data. On a consumer router this is commonly achieved with a guest or IoT network that blocks cross-network access, so if the weakly secured camera is compromised it cannot pivot toward the work laptops. Enabling guest isolation ('access intranet: off') prevents the segmented device from reaching shared folders and admin pages. Assigning the camera as the DMZ host is incorrect because consumer 'DMZ host' mode typically forwards most inbound ports to that one device, exposing it broadly rather than protecting the network. Enabling UPnP so the camera manages its own ports is incorrect because that increases exposure by letting the device open inbound ports automatically. Adding the camera to a MAC allow-list on the main LAN is incorrect because it keeps the risky device on the same trusted segment as the laptops and MAC filtering is easily spoofed; it does not provide meaningful separation. True protection comes from blocking cross-network access, and VLANs are stronger still where supported.

The goal is a location that is central for coverage but not visible or reachable from public areas, and that still allows adequate airflow. A ventilated staff-only room or locked network closet keeps the reset button, WPS button, and open Ethernet ports out of easy reach while preventing heat-related instability. Placing it on a reception desk facing the public entrance is incorrect because anyone could press the reset button, plug into a port, or read labels, turning a network issue into a physical control problem. Placing it on a windowsill for the widest coverage is incorrect because glass does not block radio waves well, so the signal spills outdoors and increases where an attacker can attempt to connect. Sealing it in a lobby cabinet for concealment is incorrect because a tight enclosure with no airflow causes overheating, reboots, and rushed 'quick fixes,' and a lobby is still a public area. Security should not create reliability problems; if the safest spot hurts coverage, add an access point or mesh node closer to users while keeping the router protected.

With UPnP disabled, you can still get the same result in a controlled, visible way by adding a single manual port forward to the one device that needs it, then retesting. This keeps exposure narrow and avoids the automatic, unmonitored openings that UPnP creates. Re-enabling UPnP permanently is incorrect because it reintroduces the exact risk the homeowner wanted to avoid, allowing any local device to request inbound port openings. Assigning the console to the DMZ host is incorrect because consumer DMZ host mode typically forwards most inbound ports to that device, exposing it far more broadly than a single needed port. Disabling the firewall is incorrect because it removes protection for the entire network and is never an appropriate fix for one application's port needs. The safe workflow is to keep UPnP off, add only the specific port forward required, remove rules you no longer use, and re-check periodically to avoid lingering 'mystery' openings.

The safest pattern is to keep router management local and reach the home network through a VPN when away, using a built-in VPN server or a dedicated device. The admin page is never exposed to the internet, yet the administrator still gains secure access to internal resources. Enabling remote management over HTTP on a nonstandard port is incorrect because HTTP sends login data without strong protection and a nonstandard port offers only weak obscurity that scanners easily defeat, still exposing the admin interface. Forwarding the admin port to the WAN interface is incorrect because it directly publishes the management page to the internet, inviting login attempts and exploitation of known bugs. Enabling WPS is incorrect because WPS trades security for convenience, can weaken the Wi-Fi join process, and has nothing to do with secure remote administration. Admin access should be rare, intentional, and local; a VPN provides better control than exposing services or the management page to the internet, and remote management should stay disabled unless a clear need exists.