Last month, a client called me and said:"I'll check it tomorrow, see if the system can export the format they want."I'm going to go up and down, and then I'm going to check the logs, but they are spread over three locations: Authentication Gateway, which is part of the inventory, a batch of CSV files on local servers, and some of them that have been cleared automatically by the system because the disk is full. And it took half a day to get a report together manually, and it was barely possible to get a report that could be off-limited, but data integrity and format specifications were certainly not perfect.
Legal basis and basic requirements for the retention of a log
The logs of the WiFi Real Name Certification System are not optional, but legal. Under article 21 of the Cybersecurity Act and the Regulations on Technical Measures for Internet Security Protection, public Internet access providers must record and retain user logs for a period of no less than six months. For hotels, this requirement includes: user identification information (name authentication information such as cell phone numbers, identity number), time off to access, assigned IP addresses and IP addresses on the Internet, and target addresses visited (at least at domain name levels). If the Internet service comes to get data, the hotel must provide them within a specified time or face administrative penalties.
Full overlay of log collection point
The most common problem with the hotel WiFi logs is incomplete coverage.→AP→Access switch→Core switch→NATHHELL_AUTH_GATEWAY→Export router→Internet. Many system logs record only the authentication information for that moment when NATSHEL_AUTH_GATEWAY is registered, but client behavioral logs are required to be collected continuously throughout the session. If NATSHEL_AUTH_GATEWAY deploys directly, all traffic goes through a gateway and the log is relatively complete. If it is deployed by side, without the traffic going through a gateway, additional traffic mirror or NetFlow collection options are needed.
The link between the NT log and the real name information is a core challenge.
A technical challenge for the WiFi real name certification system is to trace the NAT address. Hotels usually use one or more IP addresses on public networks to provide online access to all rooms, and the intranet converts through NAT. This raises the question: logs record Internet IP access, but there may be dozens of different users accessing the same IP under a public network. When it takes time to go back to which user visited a site, it is necessary to do a re-checking of the NAT log.——This process relies on three log-sheet links: the NAT map, the DHCP address allocation table, and the user-certified information sheet. If the time stamp of these tables is inaccurate or in inconsistent formats, the connection query will fail. Our practical experience is that all log-tables must be timetamped to millisecond accuracy and all network devices must do NTP time synchronization, otherwise time drifting can turn log connections into disaster.
Capacity planning and security protection for log storage
The WiFi system has a larger log than most people think. A hundred-room hotel produces an NAT log and an Internet log of behavior about 5-10 GB per day. Six months is around 1 TB. This is just the original log, which doubles storage requirements if indexes and archive backup are added. Many hotels start with single hard disks for logging, running two or three months, then automating old logs.——This is tantamount to the active destruction of evidence of compliance. The correct approach is to ensure at least eight months of log storage capacity (six months retained with a two-month buffer), make RAD disk redundancy to prevent loss of logs from single disk failure, regularly do off-site or cloud backup. At the same time, log files must be encrypted, strict read and access rights set up, and all access log operations record audit trails.
Rapid search capability in the audit landscape
The WiFi real name certification system is not compliant if it does not retrieve the logs within a short time and according to specified conditions. Typical queries are: all Internet records of a cell phone number over a certain period of time, access behaviour at an IP address over a given time, or lists of all online users over a given time frame. These search scenarios need to be designed with a good index strategy: time indexes, mobile phone indexes, IP addresses indexes that cover at least these three dimensions of the query. In terms of response time, inquiries should be returned in seconds for within one week and a full scan over one month would be acceptable to the minute stage but never appear."I can't."Or..."The data is gone."Situation.
Normative format for log export
Many hotels, WiFi, report on their real name certification systems at the last kilometre: data are available but exported in a wrong format. The log formats required by the web security department are usually clearly defined and field order, separator, coding is required. If the system is guided by an internal format, it needs to be converted manually into a standard format, which may introduce errors or even loss of data. It is recommended that the built-in standard format be exported when the system is designed, supported in formats such as at least CSV and Excel, where the field map relationship is fixed in the system configuration rather than by manual memory. A further summary document of the export record, including timing, emitter, data range, number of data lines, file Hashi value, must be generated at each export to prevent any post-disputing dispute over data integrity.
The WiFi system of physical accreditation is a basic function of the product, not an added value. A system that technically authenticates and experiences it is closed, but does not have a full log at the time of the audit, is not qualified in the hotel setting."Almost."Only"Okay."and"No way."。