starred/hardening
1
0
Fork 0
mirror of https://github.com/konstruktoid/hardening.git synced 2026-04-26 09:15:55 +03:00
Code Issues 6 Projects Releases 4 Packages Wiki Activity

[GH-ISSUE #144] [BUG] Buggy SERVERIP detection in ubuntu.sh #60

New issue
Closed
opened 2026-03-03 13:58:48 +03:00 by kerem · 8 comments
kerem commented 2026-03-03 13:58:48 +03:00
Owner
Copy link

Originally created by @bob-rove on GitHub (Jun 21, 2022).
Original GitHub issue: https://github.com/konstruktoid/hardening/issues/144

Originally assigned to: @konstruktoid on GitHub.

Describe the bug

Command on this line returns empty string or a route option instead of server IP, resulting in incorrect PSAD setting in /etc/psad/auto_dl file.

To Reproduce

  1. On fresh GCP VM and default route:
$ ip route | grep '^default'
default via 10.132.0.1 dev ens4

applying ./ubuntu.sh produces following line in /etc/psad/auto_dl file: 0; due to:

$ ip route | grep '^default' | awk '{print $9}'
  1. On private HW server with direct Internet link and default route with options:
$ ip route | grep '^default'
default via X.X.X.X dev enp41s0 proto static onlink initcwnd 10 initrwnd 10

applying ./ubuntu.sh produces following line in /etc/psad/auto_dl file:initcwnd 0; due to:

$ ip route | grep '^default' | awk '{print $9}'
initcwnd

Expected behavior

(a) Proper server IP appears in /etc/psad/auto_dl file or (b) no line at all added to this file.

System (lsb_release -a):

  1. GCP VM:
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 11 (bullseye)
Release:	11
Codename:	bullseye
  1. Private HW server:
# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04 LTS
Release:	22.04
Codename:	jammy

Additional context

Not sure how useful SERVERIP in /etc/psad/auto_dl file is, but previous revision of server IP detection (ie: $WBIN -ih | awk '{print $3}' | head -n1) might have worked better.

Originally created by @bob-rove on GitHub (Jun 21, 2022). Original GitHub issue: https://github.com/konstruktoid/hardening/issues/144 Originally assigned to: @konstruktoid on GitHub. **Describe the bug** Command on [this line](https://github.com/konstruktoid/hardening/blob/master/ubuntu.sh#L39) returns empty string or a route option instead of server IP, resulting in incorrect PSAD setting in `/etc/psad/auto_dl` file. **To Reproduce** 1. On fresh GCP VM and default route: ``` $ ip route | grep '^default' default via 10.132.0.1 dev ens4 ``` applying `./ubuntu.sh` produces following line in `/etc/psad/auto_dl` file:` 0;` due to: ``` $ ip route | grep '^default' | awk '{print $9}' ``` 2. On private HW server with direct Internet link and default route with options: ``` $ ip route | grep '^default' default via X.X.X.X dev enp41s0 proto static onlink initcwnd 10 initrwnd 10 ``` applying `./ubuntu.sh` produces following line in `/etc/psad/auto_dl` file:`initcwnd 0;` due to: ``` $ ip route | grep '^default' | awk '{print $9}' initcwnd ``` **Expected behavior** (a) Proper server IP appears in `/etc/psad/auto_dl` file or (b) no line at all added to this file. **System (lsb_release -a):** 1. GCP VM: ``` $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye ``` 2. Private HW server: ``` # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04 LTS Release: 22.04 Codename: jammy ``` **Additional context** Not sure how useful `SERVERIP` in `/etc/psad/auto_dl` file is, but previous revision of server IP detection (ie: `$WBIN -ih | awk '{print $3}' | head -n1`) might have worked better.
kerem closed this issue 2026-03-03 13:58:48 +03:00
kerem commented 2026-03-03 13:58:49 +03:00
Author
Owner
Copy link

@konstruktoid commented on GitHub (Jun 21, 2022):

Hi @bob-rove and thanks for opening this issue.
Yeah, I haven't taken initcwnd et al into consideration and testing is done on Ubuntu so Debian might fail in multiple ways.

I haven't yet found a solution that works flawlessly.
Could you try ip route get "$(resolvectl status | grep 'Current DNS Server' | awk '{print $NF; exit}')" | awk '{print $7; exit}'?

$WBIN -ih | awk '{print $3}' | head -n1 doesn't return anything in certain situations, depening on how the user has logged in.

<!-- gh-comment-id:1162202841 --> @konstruktoid commented on GitHub (Jun 21, 2022): Hi @bob-rove and thanks for opening this issue. Yeah, I haven't taken `initcwnd` et al into consideration and testing is done on Ubuntu so Debian might fail in multiple ways. I haven't yet found a solution that works flawlessly. Could you try `ip route get "$(resolvectl status | grep 'Current DNS Server' | awk '{print $NF; exit}')" | awk '{print $7; exit}'`? `$WBIN -ih | awk '{print $3}' | head -n1` doesn't return anything in certain situations, depening on how the user has logged in.
kerem commented 2026-03-03 13:58:49 +03:00
Author
Owner
Copy link

@bob-rove commented on GitHub (Jun 22, 2022):

Could you try ip route get "$(resolvectl status | grep 'Current DNS Server' | awk '{print $NF; exit}')" | awk '{print $7; exit}'?

This seems to be working fine 👍

ip route get 1.1.1.1 | awk '{print $7; exit}' gives current server IP on both system.

The only issue with resolvectl status - on System 1 (Debian, GCP VM) it returns error:

# resolvectl status
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.

This is probably because GCP and alike are used to provide internal DNS server on "meta" IP-address in /etc/resolv.conf and systemd-resolved service is disabled by default:

# cat /etc/resolv.conf | grep nameserver
nameserver 169.254.169.254

# systemctl status systemd-resolved
� systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

Nonetheless, ip route get 169.254.169.254 | awk '{print $7; exit}' also returns current server IP. So it may come down to finding a way to avoid resolvectl to support broader variety of setups.

<!-- gh-comment-id:1163132520 --> @bob-rove commented on GitHub (Jun 22, 2022): > Could you try `ip route get "$(resolvectl status | grep 'Current DNS Server' | awk '{print $NF; exit}')" | awk '{print $7; exit}'`? This seems to be working fine 👍 `ip route get 1.1.1.1 | awk '{print $7; exit}'` gives current server IP on both system. The only issue with `resolvectl status` - on System 1 (Debian, GCP VM) it returns error: ```bash # resolvectl status Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found. ``` This is probably because GCP and alike are used to provide internal DNS server on "meta" IP-address in `/etc/resolv.conf` and `systemd-resolved` service is disabled by default: ```bash # cat /etc/resolv.conf | grep nameserver nameserver 169.254.169.254 # systemctl status systemd-resolved � systemd-resolved.service - Network Name Resolution Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-resolved.service(8) man:org.freedesktop.resolve1(5) https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients ``` Nonetheless, `ip route get 169.254.169.254 | awk '{print $7; exit}'` also returns current server IP. So it may come down to finding a way to avoid `resolvectl` to support broader variety of setups.
kerem commented 2026-03-03 13:58:49 +03:00
Author
Owner
Copy link

@konstruktoid commented on GitHub (Jun 22, 2022):

Yeah, I can add a check that if resolvectl status fails then we'll grab a nameserver from /etc/resolv.conf

<!-- gh-comment-id:1163352714 --> @konstruktoid commented on GitHub (Jun 22, 2022): Yeah, I can add a check that if `resolvectl status` fails then we'll grab a nameserver from `/etc/resolv.conf`
kerem commented 2026-03-03 13:58:49 +03:00
Author
Owner
Copy link

@konstruktoid commented on GitHub (Jun 23, 2022):

could you please test https://github.com/konstruktoid/hardening/pull/147?

<!-- gh-comment-id:1164216452 --> @konstruktoid commented on GitHub (Jun 23, 2022): could you please test https://github.com/konstruktoid/hardening/pull/147?
kerem commented 2026-03-03 13:58:49 +03:00
Author
Owner
Copy link

@bob-rove commented on GitHub (Jun 23, 2022):

@konstruktoid tried.
I guess we should also account for nameservers with IPv6 addresses in the output not matching [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+ regex. For example:

# resolvectl status | grep -E 'DNS (Server:|Servers:)' | tail -n1
       DNS Servers: <IPv4-NS> <IPv6-NS>

# ip route get <IPv6-NS>
<IPv6-NS> from :: via fe80::1 dev enp41s0 proto static src <IPv6-SERVERIP> metric 1024 pref medium

Considering this, should the tool also write both IPv4 & IPv6 SERVERIP entries in /etc/psad/auto_dl ? 🤔

<!-- gh-comment-id:1164454082 --> @bob-rove commented on GitHub (Jun 23, 2022): @konstruktoid tried. I guess we should also account for nameservers with IPv6 addresses in the output not matching `[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+` regex. For example: ``` # resolvectl status | grep -E 'DNS (Server:|Servers:)' | tail -n1 DNS Servers: <IPv4-NS> <IPv6-NS> # ip route get <IPv6-NS> <IPv6-NS> from :: via fe80::1 dev enp41s0 proto static src <IPv6-SERVERIP> metric 1024 pref medium ``` Considering this, should the tool also write both IPv4 & IPv6 `SERVERIP` entries in `/etc/psad/auto_dl` ? 🤔
kerem commented 2026-03-03 13:58:49 +03:00
Author
Owner
Copy link

@konstruktoid commented on GitHub (Jun 23, 2022):

yeah, good point.
SERVERIP4, SERVERIP6 ain’t pretty but it’s a start.

<!-- gh-comment-id:1164543652 --> @konstruktoid commented on GitHub (Jun 23, 2022): yeah, good point. `SERVERIP4`, `SERVERIP6` ain’t pretty but it’s a start.
kerem commented 2026-03-03 13:58:49 +03:00
Author
Owner
Copy link

@konstruktoid commented on GitHub (Jun 27, 2022):

I'm having issues finding a environment with a working IPv6 set up, so this is still a WIP.

<!-- gh-comment-id:1167112242 --> @konstruktoid commented on GitHub (Jun 27, 2022): I'm having issues finding a environment with a working IPv6 set up, so this is still a WIP.
kerem commented 2026-03-03 13:58:50 +03:00
Author
Owner
Copy link

@konstruktoid commented on GitHub (Jun 28, 2022):

I'm going to merge #147 and then open a separate PR regarding IPv6 when I get it working.

<!-- gh-comment-id:1169239844 --> @konstruktoid commented on GitHub (Jun 28, 2022): I'm going to merge #147 and then open a separate PR regarding IPv6 when I get it working.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
renovate/github-codeql-action-4.x
v2.2.0
v2.1.0
v2.0.0
v1.0.0
v1.0
Labels
Clear labels   
Stale

   
bug

   
bug

   
bug

   
pull-request

Mirrored from GitHub Pull Request

No labels
Stale
bug
bug
bug
pull-request
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/hardening#60
No description provided.