[Touch-packages] [Bug 1881942] [NEW] default configuration forwards sshd failures to port 7070
Public bug reported:
ubuntu eoan (19.10)
---
While investigating why my fail2ban client was not blocking the usual
script-kiddie SSH attempts, I discovered that no sshd failures were
appearing in /var/log/auth.log. Upon opening
/etc/rsyslog.d/50-default.conf I discovered that sshd failures are being
transformed and forwarded to localhost:7070. Here's the section of
configuration:
if $programname == 'sshd' then {
if $msg startswith ' Failed' then {
# Transform and forward data!
action(type="omfwd" target="127.0.0.1" port="7070" protocol="tcp"
template="ip-json")
}
stop
}
For me, nothing is bound to port 7070.
I assume you have a good reason for such a default but it seems
suboptimal to stop processing after forwarding. I commented out the
stop line and restarted rsyslog and found that logs appeared in
/var/log/auth.log and that my fail2ban is now banning IPs, as expected.
I suggest changing the default configuration so that sshd failures reach
/var/log/auth.log.
** Affects: rsyslog (Ubuntu)
Importance: Undecided
Status: New
** Tags: eoan
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1881942
Title:
default configuration forwards sshd failures to port 7070
Status in rsyslog package in Ubuntu:
New
Bug description:
ubuntu eoan (19.10)
---
While investigating why my fail2ban client was not blocking the usual
script-kiddie SSH attempts, I discovered that no sshd failures were
appearing in /var/log/auth.log. Upon opening
/etc/rsyslog.d/50-default.conf I discovered that sshd failures are
being transformed and forwarded to localhost:7070. Here's the section
of configuration:
if $programname == 'sshd' then {
if $msg startswith ' Failed' then {
# Transform and forward data!
action(type="omfwd" target="127.0.0.1" port="7070" protocol="tcp"
template="ip-json")
}
stop
}
For me, nothing is bound to port 7070.
I assume you have a good reason for such a default but it seems
suboptimal to stop processing after forwarding. I commented out the
stop line and restarted rsyslog and found that logs appeared in
/var/log/auth.log and that my fail2ban is now banning IPs, as
expected.
I suggest changing the default configuration so that sshd failures
reach /var/log/auth.log.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1881942/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1013963] Re: NetworkManager doesn't support bridge interface defined in /etc/network/interfaces
see also: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1273201 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1013963 Title: NetworkManager doesn't support bridge interface defined in /etc/network/interfaces Status in network-manager package in Ubuntu: Confirmed Bug description: Hello, I need a network bridge for my virtualbox VMs on my desktop computer. If I create a br0 bridge in /etc/network/interfaces, it works but Network Manager applet doesn't see any active network connection, and as such I can't connect to VPN anymore. ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: network-manager-gnome 0.9.4.1-0ubuntu2 ProcVersionSignature: Ubuntu 3.2.0-25.40-generic 3.2.18 Uname: Linux 3.2.0-25-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.0.1-0ubuntu8 Architecture: amd64 CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found. Date: Sat Jun 16 14:27:24 2012 EcryptfsInUse: Yes InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Alpha amd64 (20120316) NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true ProcEnviron: TERM=xterm PATH=(custom, user) LANG=fr_FR.UTF-8 SHELL=/bin/bash RfKill: SourcePackage: network-manager-applet UpgradeStatus: No upgrade log present (probably fresh install) nmcli-dev: DEVICE TYPE STATE DBUS-PATH eth1 802-3-ethernetunavailable /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.4.0connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1013963/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1273201] Re: bridge_ignore_without_connections.patch breaks NM created bridge at boot
Is there any plan to get this into 14.04 LTS? I run Mint, which is going to stay on 14.04 LTS for the next few releases, so unless it gets into 14.04 LTS, Mint users won't be able to get this fix for - potentially - a long time. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1273201 Title: bridge_ignore_without_connections.patch breaks NM created bridge at boot Status in network-manager package in Ubuntu: Fix Released Bug description: I've created a bridge with network-manager-gnome, the bridge slave physical device is eth0. After a reboot the bridge is brought up, but eth0 isn't attached. First test-case: Created a bridge with network-manager-gnome with the bridge slave physical device is eth0 and remove all other connections. After a reboot the bridge is brought up, but eth0 isn't attached. When I open /etc/NetworkManager/NetworkManager.conf and save it without any modification, eth0 is instantly added to my bridge. Strange! Second test-case: Created a bridge with network-manager-gnome with the bridge slave physical device is eth0. Disable the autoconnect of the default wired network. After a reboot the bridge is brought up, but eth0 isn't attached. Instead eth0 is brought up and full configured. After compiling and testing different upstream versions, i could track the problem down to bridge_ignore_without_connections.patch. A network-manager package without this specific patch, brings my bridge up at boot and adds eth0 to the bridge in both test-cases. I've checked the behaviour on my ubuntu 13.10 box with network-manager (0.9.8.0-0ubuntu22) and the trusty version network-manager (0.9.8.8-0ubuntu1) . Till now i couldn't encounter any sideeffects of removing this patch with the bridge created by libvirt. Regards Mathias Kresin To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1273201/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
