Regex to match multiple different lines - regex

I have the following file below and I would like to have a some regex expressions that could parse the file and give me an output like
139.162.78.135:41448 TLS Error: TLS handshake failed
139.162.78.135:41448 Connection reset, restarting
TLS Error: incoming packet authentication failed from [AF_INET]139.162.78.135:41448
139.162.78.135:41448 Fatal TLS Error
139.162.78.135:41448 VERIFY ERROR
139.162.78.135:41448 Bad encapsulated packet length
Note: this is for a program called fail2ban so that I can easily ban these ips that are trying to intrude my server.
I tried to parse the connection reset line like this \d+\.\d+\.\d+\.\d+:\d+ Connection reset, restarting But I don't know how to form another expression that can match the rest in one go.
Jun 19 04:27:29 Server ovpn-openvpn_tcp[856]: 139.162.78.135:41448 Connection reset, restarting [0]
Jun 19 04:27:29 Server ovpn-openvpn_tcp[856]: 139.162.78.135:41448 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 04:27:29 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]139.162.78.135:41828
Jun 19 04:27:29 Server ovpn-openvpn_tcp[856]: 139.162.78.135:41828 WARNING: Bad encapsulated packet length from peer (18245), which must be > 0 and <= 1627 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Jun 19 04:27:29 Server ovpn-openvpn_tcp[856]: 139.162.78.135:41828 Connection reset, restarting [0]
Jun 19 04:27:29 Server ovpn-openvpn_tcp[856]: 139.162.78.135:41828 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 04:52:47 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]67.52.172.103:2577
Jun 19 04:52:47 Server ovpn-openvpn_tcp[856]: 67.52.172.103:2577 Connection reset, restarting [0]
Jun 19 04:52:47 Server ovpn-openvpn_tcp[856]: 67.52.172.103:2577 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 04:52:48 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]67.52.172.103:63975
Jun 19 04:52:48 Server ovpn-openvpn_tcp[856]: 67.52.172.103:63975 Connection reset, restarting [-1]
Jun 19 04:52:48 Server ovpn-openvpn_tcp[856]: 67.52.172.103:63975 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 04:56:52 Server ovpn-openvpn_udp[811]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]185.200.118.55:55292
Jun 19 09:17:44 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]154.16.133.10:13456
Jun 19 09:17:44 Server ovpn-openvpn_tcp[856]: 154.16.133.10:13456 Connection reset, restarting [-1]
Jun 19 09:17:44 Server ovpn-openvpn_tcp[856]: 154.16.133.10:13456 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 09:17:44 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]154.16.133.10:13769
Jun 19 09:17:59 Server ovpn-openvpn_tcp[856]: 154.16.133.10:13769 Connection reset, restarting [-1]
Jun 19 09:17:59 Server ovpn-openvpn_tcp[856]: 154.16.133.10:13769 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 09:19:25 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]184.105.139.70:50240
Jun 19 09:19:26 Server ovpn-openvpn_tcp[856]: 184.105.139.70:50240 WARNING: Bad encapsulated packet length from peer (5635), which must be > 0 and <= 1627 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Jun 19 09:19:26 Server ovpn-openvpn_tcp[856]: 184.105.139.70:50240 Connection reset, restarting [0]
Jun 19 09:19:26 Server ovpn-openvpn_tcp[856]: 184.105.139.70:50240 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 14:11:58 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]223.146.71.5:59970
Jun 19 14:11:58 Server ovpn-openvpn_tcp[856]: 223.146.71.5:59970 Connection reset, restarting [0]
Jun 19 14:11:58 Server ovpn-openvpn_tcp[856]: 223.146.71.5:59970 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 14:11:59 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]223.146.71.5:60145
Jun 19 14:11:59 Server ovpn-openvpn_tcp[856]: 223.146.71.5:60145 WARNING: Bad encapsulated packet length from peer (21331), which must be > 0 and <= 1627 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Jun 19 14:11:59 Server ovpn-openvpn_tcp[856]: 223.146.71.5:60145 Connection reset, restarting [0]
Jun 19 14:11:59 Server ovpn-openvpn_tcp[856]: 223.146.71.5:60145 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 14:25:16 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]112.113.195.89:3079
Jun 19 14:26:16 Server ovpn-openvpn_tcp[856]: 112.113.195.89:3079 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jun 19 14:26:16 Server ovpn-openvpn_tcp[856]: 112.113.195.89:3079 TLS Error: TLS handshake failed
Jun 19 14:26:16 Server ovpn-openvpn_tcp[856]: 112.113.195.89:3079 Fatal TLS error (check_tls_errors_co), restarting
Jun 19 14:26:17 Server ovpn-openvpn_tcp[856]: 112.113.195.89:3079 SIGUSR1[soft,tls-error] received, client-instance restarting
Jun 19 16:27:19 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]213.202.230.144:2616
Jun 19 16:28:19 Server ovpn-openvpn_tcp[856]: 213.202.230.144:2616 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jun 19 16:28:19 Server ovpn-openvpn_tcp[856]: 213.202.230.144:2616 TLS Error: TLS handshake failed
Jun 19 16:28:19 Server ovpn-openvpn_tcp[856]: 213.202.230.144:2616 Fatal TLS error (check_tls_errors_co), restarting
Jun 19 16:28:19 Server ovpn-openvpn_tcp[856]: 213.202.230.144:2616 SIGUSR1[soft,tls-error] received, client-instance restarting
Jun 19 16:59:10 Server ovpn-openvpn_udp[811]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]185.200.118.41:40431
Jun 19 19:00:17 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]178.73.215.171:23509
Jun 19 19:00:17 Server ovpn-openvpn_tcp[856]: 178.73.215.171:23509 WARNING: Bad encapsulated packet length from peer (5635), which must be > 0 and <= 1627 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Jun 19 19:00:17 Server ovpn-openvpn_tcp[856]: 178.73.215.171:23509 Connection reset, restarting [0]
Jun 19 19:00:17 Server ovpn-openvpn_tcp[856]: 178.73.215.171:23509 SIGUSR1[soft,connection-reset] received, client-instance restarting

Use | to separate different options that you would like to capture. Since most of the options start with IP address, you could share your IP-matching regex among all of them.
Here is a regex with some "formatting" for easier understanding of what is going on; remove unnecessary spaces and end-of-line markers in the real regex:
\d+\.\d+\.\d+\.\d+:\d+
(?:
Connection reset, restarting
| TLS Error: TLS handshake failed
| Fatal TLS Error
| VERIFY ERROR
| Bad encapsulated packet length
)
| TLS Error: incoming packet authentication failed from [AF_INET]\d+\.\d+\.\d+\.\d+:\d+
Demo.

I think this problem may be divided into 2 parts:
What regex is used to represent the patterns, and
How to capture the IP address the OP is interested in.
Represent the patterns with the "or" and "group" operators
I think the multiple possibilities that follow the IP address may be handled by using the | operator and the ( ) grouping operator:
\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}:\d{1,5} (Connection reset|TLS Error|Fatal TLS Error|VERIFY ERROR|Bad encapsulated packet length)
The more complicated case is the last possibility that the IP address appears the last, such as in the message
Jun 19 16:59:10 Server ovpn-openvpn_udp[811]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]185.200.118.41:40431
I think a quick and dirty solution might be to wrap this case with a pair of ()and the other cases with another pair of () and then | them together:
((TLS Error.+\[AF_INET\])(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}:\d{1,5}))|(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}:\d{1,5} (Connection reset|TLS Error|Fatal TLS Error|VERIFY ERROR|Bad encapsulated packet length))
With this regex, a user will be able to obtain the lines that contain the interesting patterns. This pattern includes both the IP address and the error info, and now with 1 further step, the user can extract the parts of interest (in this case, IP address and port number) ---
Return only the matched parts
To tell a regex that some part is not part of the match result (and are used only as delimiters, for example), you can declare them as "lookaheads" ( (?=blah blah) ). The following shows how a one-liner with grep extracts the intruders:
$ grep -P "((?=TLS Error.+\[AF_INET\])(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}:\d{1,5}))|((\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}:\d{1,5}) (?=Connection reset|TLS Error|Fatal TLS Error|VERIFY ERROR|Bad encapsulated packet length))" -o temp.txt
67.52.172.103:63975
154.16.133.10:13456
154.16.133.10:13769
184.105.139.70:50240
223.146.71.5:59970
223.146.71.5:60145
112.113.195.89:3079
112.113.195.89:3079
213.202.230.144:2616
213.202.230.144:2616
178.73.215.171:23509
The -o tells grep to return only the matched parts; -P tells grep to use PCRE regex rather than POSIX regex.
Hope this may be useful!

Related

Redis wont start: Could not create server TCP listening socket 127.0.0.1:6379: bind: Address already in use

I have installed redis in my AWS server. I have followed this: https://www.digitalocean.com/community/tutorials/how-to-install-secure-redis-centos-7
$ systemctl start redis.service
$ systemctl enable redis
-> Created symlink /etc/systemd/system/multi-user.target.wants/redis.service → /usr/lib/systemd/system/redis.service.
$ systemctl status redis.service
● redis.service - Redis persistent key-value database
Loaded: loaded (/usr/lib/systemd/system/redis.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/redis.service.d
└─limit.conf
Active: failed (Result: exit-code) since Wed 2020-08-26 02:28:25 UTC; 10s ago
Main PID: 5012 (code=exited, status=1/FAILURE)
Aug 26 02:28:25 ip-xxx-xx-xx-xx.ap-southeast-2.compute.internal systemd[1]: Starting Redis persistent key-value database...
Aug 26 02:28:25 ip-xxx-xx-xx-xx.ap-southeast-2.compute.internal systemd[1]: Started Redis persistent key-value database.
Aug 26 02:28:25 ip-xxx-xx-xx-xx.ap-southeast-2.compute.internal systemd[1]: redis.service: Main process exited, code=exited, status=1/FAILURE
Aug 26 02:28:25 ip-xxx-xx-xx-xx.ap-southeast-2.compute.internal systemd[1]: redis.service: Failed with result 'exit-code'.
And when I check the /var/log/redis/redis.log this is what I see:
5012:C 26 Aug 2020 02:28:25.574 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
5012:C 26 Aug 2020 02:28:25.574 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=5012, just started
5012:C 26 Aug 2020 02:28:25.574 # Configuration loaded
5012:C 26 Aug 2020 02:28:25.574 * supervised by systemd, will signal readiness
5012:M 26 Aug 2020 02:28:25.575 # Could not create server TCP listening socket 127.0.0.1:6379: bind: Address already in use
And upon checking the ports:
$ netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 2812/redis-server *
tcp6 0 0 :::6379 :::* LISTEN 2812/redis-server *
This is showing the port 6379 is actually being used by redis-server.
So why cannot it start then?
Do I need to add any inbound/outbound rules in AWS? Please help.
UPDATE
ExecStart=/usr/bin/redis-server /etc/redis.conf --supervised systemd command on terminal returns bash: /etc/redis.conf: Permission denied. Looks like need to give right permission to /etc/redis.conf file.
$ ls -l /etc/redis.conf
-rw-r-----. 1 redis redis 62189 Aug 26 03:04 /etc/redis.conf
So what permission do I need to give here? Who should own this file?

OpenVPN config error- cannot connect client to server?

Currently learning how to config an openVPN server on an AWS Linux server as a bit of a self-taught exercise. I've managed to set everything up to trying to connect to it via the OpenVPN client GUI, but it's not working. The error message in the log below:
Enter Management Password:
Mon May 18 14:59:57 2020 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Mon May 18 14:59:57 2020 Need hold release from management interface, waiting...
Mon May 18 14:59:57 2020 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Mon May 18 14:59:57 2020 MANAGEMENT: CMD 'state on'
Mon May 18 14:59:57 2020 MANAGEMENT: CMD 'log all on'
Mon May 18 14:59:57 2020 MANAGEMENT: CMD 'echo all on'
Mon May 18 14:59:57 2020 MANAGEMENT: CMD 'bytecount 5'
Mon May 18 14:59:57 2020 MANAGEMENT: CMD 'hold off'
Mon May 18 14:59:57 2020 MANAGEMENT: CMD 'hold release'
Mon May 18 14:59:57 2020 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
Mon May 18 14:59:57 2020 OpenSSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch
Mon May 18 14:59:57 2020 Cannot load private key file client.key
Mon May 18 14:59:57 2020 SIGUSR1[soft,private-key-password-failure] received, process restarting
Mon May 18 14:59:57 2020 MANAGEMENT: >STATE:1589810397,RECONNECTING,private-key-password-failure,,,,,
Mon May 18 14:59:57 2020 Restart pause, 5 second(s)
Here's the configs I have for server and client:
client
dev tun
proto udp
remote [MY AWS IP GOES HERE] 1194
ca ca.crt
cert client.crt
key client.key
tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
cipher AES-256-CBC
auth SHA512
resolv-retry infinite
auth-retry none
nobind
persist-key
persist-tun
ns-cert-type server
comp-lzo
verb 3
tls-client
tls-auth pfs.key
Server
port 1194
proto udp
dev tun
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/server.crt
key /etc/openvpn/easy-rsa/pki/private/server.key
dh /etc/openvpn/easy-rsa/pki/dh.pem
cipher AES-256-CBC
auth SHA512
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 3
tls-server
tls-auth /etc/openvpn/pfs.key

Apache TLS Handshakes Timeout after DHCP Lease Renewal

I'm trying to figure out why my HTTPS sites go down everytime my server's DHCP lease gets renewed.
It happens consistently, but HTTP sites continue to work just fine.
Restarting systemd-networkd brings the sites back, but until that happens the HTTPS sites are basically unreachable.
Any tips on where to look first?
The weird thing is these sites come back after the next DHCP lease renewal, then I lose connectivity on the next one, then it comes back, then I lose it, on and on.
This is what I see in syslog when it happens.
Apr 13 18:06:25 www-1 systemd-networkd[13973]: ens4: DHCP lease lost
Apr 13 18:06:25 www-1 systemd-networkd[13973]: ens4: DHCPv4 address 10.138.0.29/32 via 10.138.0.1
Apr 13 18:06:25 www-1 systemd-networkd[13973]: ens4: IPv6 successfully enabled
Apr 13 18:06:25 www-1 dbus-daemon[579]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.231' (uid=101 pid=13973 comm="/lib/systemd/systemd-networkd " label="unconfined")
Apr 13 18:06:25 www-1 systemd-networkd[13973]: ens4: Configured
Apr 13 18:06:25 www-1 systemd[1]: Starting Hostname Service...
Apr 13 18:06:25 www-1 dbus-daemon[579]: [system] Successfully activated service 'org.freedesktop.hostname1'
Apr 13 18:06:25 www-1 systemd[1]: Started Hostname Service.
Apr 13 18:06:25 www-1 systemd-hostnamed[17589]: Changed host name to 'www-1.us-west1-b.c.camp-fire-259800.internal'
This issue seems to be related to the following:
https://moss.sh/name-resolution-issue-systemd-resolved/
and
https://github.com/systemd/systemd/issues/9243
I've disabled systemd-resolved and am using a static /etc/resolv.conf copied from /run/systemd/resolve/resolv.conf
For internal DNS I'm using a private Google DNS Zone.
Thanks.

CentOS 7 - Payara 5 fails to run on Port 80

I installed Paraya 5(.193) on CentOS 7 server and the installation is a success. Since I aim to host a JEE website on it, I changed the default http port (of Payara) from 8080 to 80 (after disabling apache web server in order to keep the port 80 free). However, when I rerun Payara (with Port 80 as a default one), I get the following error -
-- Unit payara.service has failed.
--
-- The result is failed.
Nov 20 14:39:42 server1.gdfnow.org systemd[1]: Unit payara.service entered failed state.
Nov 20 14:39:42 server1.gdfnow.org systemd[1]: payara.service failed.
Nov 20 14:39:42 server1.gdfnow.org polkitd[541]: Unregistered Authentication Agent for unix-process:16831:1426530 (system bus name :1.137, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8) (disc
Nov 20 14:39:44 server1.gdfnow.org unix_chkpwd[16992]: password check failed for user (root)
Nov 20 14:39:44 server1.gdfnow.org sshd[16990]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.88.201.58 user=root
Nov 20 14:39:44 server1.gdfnow.org sshd[16990]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Nov 20 14:39:46 server1.gdfnow.org sshd[16990]: Failed password for root from 115.88.201.58 port 51698 ssh2
Nov 20 14:39:46 server1.gdfnow.org sshd[16990]: Received disconnect from 115.88.201.58 port 51698:11: Bye Bye [preauth]
Nov 20 14:39:46 server1.gdfnow.org sshd[16990]: Disconnected from 115.88.201.58 port 51698 [preauth]
lines 1101-1128/1128 (END)
Any insight into this would be greatly appreciated.
PS - In the error log, I have no clue what this IP Address of 115.88.201.58. It is certainly not a Public IP of my client computer.
Thanks

sshd execs on new connection rather than fork

I am facing strange issue with sshd on centos 7. I start /sbin/sshd -ddd -D on one terminal of my server. Lets say its PID is $sshdpid
* connect from another m/c
On successful connection, I see that $sshdpid instead of showing /sbin/sshd -ddd -D shows sshd: root#pts/0
And now what happens is that when the client interactive session completes (exits). The $sshdpid remains no more in the server. It implies sshd server is not running. I see following logs:
on stdout:
Received disconnect from 10.10.73.40 port 36348:11: disconnected by user
Disconnected from 10.10.73.40 port 36348
debug1: do_cleanup
debug1: PAM: cleanup
debug1: PAM: closing session
debug1: PAM: deleting credentials
debug3: PAM: sshpam_thread_cleanup entering
[1]+ Exit 255 /sbin/sshd -ddd -D
I see following logs in /var/logs/messages in server.
Jun 3 11:23:57 master sshd: Received disconnect from 10.10.73.40 port 60586:11: disconnected by user
Jun 3 11:23:57 master sshd: Disconnected from 10.10.73.40 port 60586
Jun 3 11:23:57 master sshd: debug1: do_cleanup
Jun 3 11:23:57 master sshd: debug1: PAM: cleanup
Jun 3 11:23:57 master sshd: debug1: PAM: closing session
Jun 3 11:23:57 master sshd: debug1: PAM: deleting credentials
Jun 3 11:23:57 master sshd: debug3: PAM: sshpam_thread_cleanup entering
Jun 3 11:23:57 master systemd: Unit sshd.service entered failed state.
Jun 3 11:23:57 master systemd: sshd.service failed.
Jun 3 11:23:57 master systemd-logind: Removed session 13.
Jun 3 11:24:39 master systemd: sshd.service holdoff time over, scheduling restart.
Jun 3 11:24:39 master systemd: Starting OpenSSH server daemon...
I am sshing from client as root login
Please help. I am unable to debug this issue. :(