# Network objects ## Network object types A firewall network object can be: - host (which always has a 32-bit netmask) - network, defined by network adress and netmask/CIDR bits - range, defined by a start-IP and an end-IP address or a group of the above. ***Network objects deal with IP-addresses and netmasks.*** ## Original network object types and naming ### host object notation `H_` `IPv4-address` ### network object notation `N_` `IPv4-network-address` `_` `netmask-bits` ### range object notation `R_` `START-IPv4-address` `-` `END-IPv4-address` :::warning You should avoid to create network objects, which don't exactly exist in the topology! ::: :::spoiler Example: You have a CITRIX-Client-***network of /24***. You have ***split*** this network ***in your mind***: You use the ***first /25*** of this network for administrators, while you use the ***upper /25*** for normal users. However, ***/25*** does not exist in the topology **as a network**! That's only in your mind! **Create a range instead!** ::: --- All of the above are short, intuitive and easy to read. Their names can be derived from their contents automatically. Also this can be validated automatically. :::info The "_" indicates that this string cannot be a valid DNS-name (or part of it). So this string must be some other object than a valid DNS-name. ::: --- ## Network object groups A network group can contain one or more - host object - network object - range object - other group objects (not itself) It does not define a certain network object type, but is a type that can group these. ### network group object notation `NG_` `"descriptive name"` :::spoiler Thoughts about differentiation of groups One ***could*** think about ***differentiating groups*** by their ***type of members***. In fact this can make sense, if all group objects follow a hyrarchical schema. Example: You create a group of hosts, this would be a *host-group*. Or you create a group of networks, that would a *network-group*. But how would you call a group that *combines both*? Very often you try to group objects by their type, but later have to break that schema for practical needs. IMHO there's no big gain to differentiate groups by their type of members. ::: ### Naming of network group object As this is not an original network type, its name cannot be derived automatically (if there's no additional schema which could solve this). Groups are more complicated to be handled automatically. :::info Therefor the descriptive name should focus on what the group's members have in common. Their names should not be driven by the specific use case for which they are needed right now. The focus is to re-use groups and to keep their count as low as possible. ::: --- **Example**: We need a group to define the SRC-adresses of the DB admin VDIs for a rule to allow management access to DB servers. The name **`G_DB-MANAGEMENT-clients`** is very **focused the specific case**. In contrast to that, the name **`G_VDI-admins-DB`** is more **focused on what their members have in common**. This makes **re-use** of this group **easier**. --- # Network services ***Network objects*** (for this definition) ***deal with IP-protocols and port-numbers.*** ## Network service object types Services can be defined by diverse characteristics in the OSI layer model. This service definition limits to **`IP protocol` and `port`**. This schema will **limit to this kind of** network service object **definition**. Other services are usually more complex and firewall hardware vendors have different approaches to define them. In a lot of cases they provide predefinitions for them. ## Original network service object types and naming ### TCP service notation `tcp_` `START-port-number` `[-` `END-port-number]` ### UDP service notation `udp_` `START-port-number` `[-` `END-port-number]` --- "natural numbers" for the port numbering. No need to fill with leading `0` for a 5-digit number. --- :::info Visual differentiation to network objects: **lower case and 3 letter prefix**. Can also be a range: No need to have a new kind of notation for ranges as they are more common in service definition (compared to network address-ranges). Still the pure length of the name string and the `-` between the two number is enough to cause attention that this object is a range. ::: ## Network service object groups A network service group can contain one or more - TCP service object - UDP service object - service object of other type (depending on vendor) ### network service group object notation `SG_` `"descriptive name"` ### Speciality: TCP-UDP-groups for same port [-ranges] `SG_` `START-port-number` `[-` `END-port-number]` Sometimes you need a group for the same ports, but in both protocols. The above follows the schema and still clear about the meaning. ### Naming of network service group object This is not an original network service type. But in the case of the speciality, group names can be derived automatically. The `descriptive name` should be that of the **service** it defines.