## Chapter 12 — UPnP lets a device ask for a mapping ### Lesson map Lesson 12. Map, example, EX058. ```mermaid flowchart TD U["upnp = True"] --> C["check is not upnp"] C --> F["FIX UPnP off"] F --> P["A person did not have to write the allow"] ``` The flag is the evidence. A requested mapping is not printed. ### Logical drawing ```text policy shape deny what is not allowed this flag upnp True printed result FIX not printed a port, a protocol payload, a requesting device ``` ### Learning outcomes After this chapter, you should be able to: 1. Explain UPnP as a way for a device to request an inbound mapping. 2. Keep the UPnP line as FIX. 3. Refuse a port or a payload the file does not contain. ### 12.1 Default deny is a written policy. UPnP is an unwritten request. NIST SP 800-41 Rev. 1 describes a firewall policy that decides what is allowed and denies the rest. The value of that shape is that a new inbound path requires a person to change the policy and, in a careful shop, to record the change. Universal Plug and Play, in the sense chapter 4 uses it, lets a device on the inside ask the router to open a port. The allow list can grow without Ellen writing a line. That is the reason the checklist wants UPnP off unless a named need exists. The dictionary says `upnp` is true. The predicate is `not upnp`, so the print says `FIX`. No device is named as the requester. No port is numbered. Adding either would be fiction, and describing the request format would be an instruction this course does not give. Wool's study of firewall configurations is a warning from outside the bakery: rules that people believe are strict are often not. This chapter does not import his counts. A seven-line checklist is not a full ruleset, and a single true flag is not a census of every mapping the router might hold. The honest finding is the flag. Chapter 4's narrative turns UPnP off after closing and then checks that payments still work. The check is a business test, not a dump of a mapping table. The embedded boolean stays true. There is a dependency worth keeping visible. The card reader belongs to the payment company. If that device needed an inbound mapping, Ellen would ask the company, which is the third-party rule from chapter 2. The file never says the card reader asked for one. The decision to turn UPnP off is Leo's recommendation for the router Ellen can configure. It is not a claim about the payment company's network. ### 12.2 Worked example | Proposal | Why it fails or stands | Decision | |---|---|---| | "UPnP prints FIX because the flag is true." | The predicate | May stay | | "No port is on the page." | The file | May stay | | "A named device requested a named port." | Neither name exists | Refuse | | "Wool's percentages are the bakery's score." | A different study | Refuse | > **Synthetic case.** The payment company is not given a new finding. ### Errors and limits A short checklist can justify turning a feature off. It cannot pose as a complete map of inbound mappings. ### Apply - **EX058 — What do you add to the UPnP line?** The flag is true and the print says FIX. The story later turns the feature off. Which port do you record, and whose study supplies the bakery's percentage? *Rubric:* 3 = no port and no payload; the flag stays true in the script; the FIX line stays; the later change stays prose; no outside study's percentage is copied in;; 2 = the FIX line stays and no port is invented;; 1 = the story only;; 0 = none. ### Continue studying — lesson 12 (chapter 12 of 20) [← Chapter 11](#ch-11) · [Course chapter index](../SUBJECTS.md) · [Chapter 13 →](#ch-13) Continue to the next authored lesson. ## Worked answers **EX058.** No port and no payload are added. The flag stays true and the line stays FIX. The later change stays prose. No outside study's percentage is copied in.