Regular Expressions (Regex)

A regular expression (regex) is a compact language for describing the *shape* of text instead of one fixed word. Rather than searching for the literal string admin, you can describe a pattern like "three digits, a dot, three digits, a dot..." to find every IP address in a file. In cybersecurity, regex is the workhorse of log analysis and threat hunting. SIEM correlation rules, IDS/IPS signatures (Snort and Suricata), firewall log parsers, and fast grep hunts all run on it. Learning to read and write patterns lets you pull every source IP out of an auth log, flag suspicious URLs, or validate input to block injection in seconds instead of scrolling. This sheet uses extended regex (ERE), the flavor you get with grep -E. Most other tools (Python re, JavaScript, Suricata) share the same core syntax, so the tokens below transfer almost everywhere.

A character class matches exactly one character out of a set. List the allowed characters in square brackets, use a hyphen for a range ([a-z]), and put a ^ first to negate the set ([^a-z]). The \d \w \s shorthands come from Perl/PCRE. They are convenient, but **\d is not portable to grep -E** (see the grep section), so the POSIX classes like [[:digit:]] are the safe choice in shell scripts.

Anchors match a position, not a character, so they pin a pattern to where it appears. ^ ties the match to the start of the line and $ to the end. \b matches a word boundary (the edge between a word character and a non-word character), which stops \bcat\b from matching "category". Groups with ( ) let a quantifier or an alternation apply to several tokens at once, and alternation with | means "this OR that". Combine them to write one pattern that catches several cases, for example ^(ERROR|WARN|FATAL) to grab every high-severity log line.

These are practical, log-grepping patterns. They are deliberately loose so they are short and easy to remember. They find well-formed text but do not fully validate it, for example the IP pattern will happily match 999.999.999.999. For hunting through logs that is fine. For strict input validation you would tighten each octet to (25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9]).

Plain grep uses basic regex (BRE), where +, ?, {, |, and () are literal characters and need a backslash to act special. That is confusing, so for pattern work always reach for grep -E (extended regex), where those operators just work. For the Perl \d shorthand and lookaround, use grep -P instead.

1. Write one pattern that matches only the high-severity lines of app.log: those beginning with ERROR, WARN, or FATAL. Hint: combine the ^ anchor with alternation and a group. Run it with grep -E '<pattern>' app.log and count the matches with -c. Does the line that only mentions the word ERROR in the middle of an INFO line count? Does the line that starts with lowercase warn count? 2. Use grep -oE with the email pattern from this sheet against contacts.txt to extract every address, one per line. How many does it find — and why doesn't it pick up the line that spells the address out in words, or the line with root@localhost? 3. Near the end of app.log are two lines built to test the escaped-dot IP pattern: one address written with real dots, one with the dots swapped for x. Run the loose IP pattern from this sheet with grep -oE against the file and see which of the two gets extracted. Then explain in one sentence why an unescaped . in the pattern would have matched both.