Ale's questions

In our lab, we have a few dozens of dual-boot computers installed with Windows 10 and Ubuntu, using either legacy (CSM) or UEFI boot depending on the machine. In both cases, GRUB2 is used as a bootloader. All the machines have a custom partitioning scheme without a Windows recovery partition, as the latter is not needed for Windows to properly boot/work. If a machine has issues, we rather reimage it from the network (using a PXE booted Linux).

Now the problem comes with Windows feature updates, the latest being version 2004 (EDIT: at the time this question was written, but the problem continues with more recent updates like 21H1). When one of these updates installs, it somewhat shrinks the Windows system partition to add back the recovery partition. Given its reduced size it would be fine to leave it alone, but this operation breaks GRUB as the Linux partition changes number, and the first stage of GRUB doesn't understand partition labels to find its second stage (even on UEFI machines). If a machine is hanged on a GRUB rescue prompt, there's no way to remotely correct the issue... sometimes leaving offline for hours (if not more) machines that must remain remotely accessible.

As we don't have any use for the recovery partition, the question is how to prevent the updates from creating it in the first point? Of course we could have it there when imaging the machines, but given that we don't actually want it, it seems just a waste of disk space.

EDIT for clarity: (a) The partition I'm mentioning is not the FAT32 formatted UEFI system partition (ESP), without which Windows could not even boot on UEFI setups. It is NTFS formatted and has a size of 400-500 MB. We don't have any reasons of getting rid of ESP on UEFI systems, it is also required by UEFI-GRUB by the way... (b) I've observed a few cases where the recovery partition doesn't get created, while the update succeeds. It might be related to the available space on the system partition, or from the number of primary partitions on MBR systems (4 being the maximum—if there are already 4, Windows could not add another one so easily). (c) Mainly looking at how to prevent this on currently installed systems. For future installations, we can include a precreated recovery partition to prevent updates from changing the partition scheme.

EDIT: after observation of the issue on several machines for several months, it appears that (a) the update process properly works without the recovery partition, and (b) the partition is never created on MBR-formatted disks that already have 4 primary partition and no extended one. One solution could therefore be to have the PXE-loaded code running pre-boot to create placeholder partitions to fill the MBR table... but modifying the MBR can always be source of trouble. On UEFI machines though, I don't see a clear solution as the GPT always has enough entries for the recovery partition to be created.

Since at least a few months, issuing a netstat -t command on our web server, which has TCP ports 22, 80 and 443 exposed to the Internet, often reveals dozens of connections in SYN_RECV status:

$ netstat -nt
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 128.1XX.XX.X:22         142.93.230.186:50603    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         104.248.89.196:36332    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         167.71.79.217:40430     SYN_RECV
tcp        0      0 128.1XX.XX.X:22         142.93.235.90:36742     SYN_RECV
tcp        0      0 128.1XX.XX.X:80         178.128.243.146:35451   SYN_RECV
tcp        0      0 128.1XX.XX.X:443        178.62.253.100:43994    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         188.166.91.16:42461     SYN_RECV
tcp        0      0 128.1XX.XX.X:22         178.62.242.138:33381    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         142.93.235.90:57784     SYN_RECV
tcp        0      0 128.1XX.XX.X:443        165.22.198.207:36181    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         68.183.11.83:63899      SYN_RECV
tcp        0      0 128.1XX.XX.X:22         104.248.93.253:41816    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         104.248.85.129:48833    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         178.62.207.43:59050     SYN_RECV
tcp        0      0 128.1XX.XX.X:80         128.199.55.152:55891    SYN_RECV
tcp        0      0 128.1XX.XX.X:443        178.62.205.23:52978     SYN_RECV
tcp        0      0 128.1XX.XX.X:80         165.22.198.135:36668    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         165.22.203.65:65273     SYN_RECV
tcp        0      0 128.1XX.XX.X:80         68.183.15.91:46722      SYN_RECV
tcp        0      0 128.1XX.XX.X:443        167.71.4.136:55194      SYN_RECV
tcp        0      0 128.1XX.XX.X:80         142.93.228.103:60458    SYN_RECV
tcp        0      0 128.1XX.XX.X:443        178.62.253.100:52599    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         104.248.89.56:46283     SYN_RECV
tcp        0      0 128.1XX.XX.X:443        178.62.250.235:43637    SYN_RECV
tcp        0      0 128.1XX.XX.X:443        167.71.7.181:37556      SYN_RECV
tcp        0      0 128.1XX.XX.X:80         104.248.89.200:64128    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         142.93.139.213:38821    SYN_RECV
tcp        0      0 128.1XX.XX.X:443        104.248.92.161:63004    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         68.183.15.91:46210      SYN_RECV
tcp        0      0 128.1XX.XX.X:443        104.248.92.138:39651    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         178.62.241.74:43953     SYN_RECV
tcp        0      0 128.1XX.XX.X:22         142.93.224.74:42996     SYN_RECV
tcp        0      0 128.1XX.XX.X:443        165.22.196.167:38597    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         178.128.254.3:36751     SYN_RECV
tcp        0      0 128.1XX.XX.X:22         104.248.93.27:32904     SYN_RECV
tcp        0      0 128.1XX.XX.X:443        167.71.78.255:60529     SYN_RECV
tcp        0      0 128.1XX.XX.X:22         165.22.201.209:45397    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         178.62.207.205:39291    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         165.22.198.207:61967    SYN_RECV
tcp        0      0 128.1XX.XX.X:443        178.62.234.81:39309     SYN_RECV
[---cut---]

The first though I had was that it was a SYN flooding attack, however (a) the server doesn't seem to suffer at all from the "attack", (b) the SYN rate is pretty low, at just slightly over 2 packets/sec., and (c) I generally observe those SYN packets coming from the same netblock both on that server (University lab web server hosted in our University network) and on a home server which is on a completely different netblock (connected via a regular residential fiber connection with a public dynamic IP), and (d) the Linux kernel never complies about a possible SYN flood (TCP SYN cookies are enabled).

What I'm wondering, is what the actual purpose of those SYN packets can be. They don't seem to come from network problems (badly configured firewalls or similar issues). They almost always come from IP spaces of datacenters, which change from one day to another (it could be Amazon EC2, Serverius, DigitalOcean, etc.). Sometimes it's just one to a few IPs, sometimes there are dozens. Sometimes the IP answers if I ping it, sometimes not. Although I only tested sporadically, I've almost never found a reachable web server at those IPs on port 80 or 443 (never tried to scan more ports than this), but see below for the first one I found, today. They come by bursts for perhaps one hour, then disappear; I didn't try yet to automatically detect them to have a hourly plot to see if there is some "schedule".

I was also thinking that this might be some kind of amplification attack using forged IP source addresses (each received SYN packet will eventually produce 5 SYN ACK packets before the server times out), but it doesn't make much sense as (a) a normal server would quickly reply with a RST packet thus stopping further SYN ACKs, and (b) as mentioned, those servers don't appear to host public websites that might worth of a DDoS amplification attack.

The (possibly spoofed?) source addresses mostly have no PTR record, or a generic one, but in some cases they give actual hostnames (e.g. in the list mentioned above, 142.93.230.186 gives parimatchklub.com, apparently a Russian sports betting site). The site was very slow to reach, so perhaps it is indeed some form of reflection attack against the apparent source addresses?

Did anybody else already observe this? Any explanation about the actual purpose of those packets?

Is it at all possible, and how, to configure the Exim4 mail server to convert outgoing messages (or message parts) from 8bit encoding to Quoted-Printable (or Base64, although I'd prefer QP) before signing them with DKIM and transferring them?

We currently have a setup where messages containing 8bit parts get an invalid DKIM signature when arriving at the destination server because they are converted by an upstream server (which we have no control of) to Quoted-Printable. Unfortunately, we can't really complain about the behaviour of the upstream server because RFC4871 clearly states that it is the signing server that has to reencode the mail in the appropriate encoding before signing (see [RFC4871 section 5.3][1]):

In order to minimize the chances of such breakage, signers SHOULD convert the message to a suitable MIME content transfer encoding such as quoted-printable or base64 as described in MIME Part One [RFC2045] before signing.

I would therefore expect this conversion to be a basic function of any mail server supporting DKIM, but as far as I searched in the exim manuals, there is nothing like that. Is it any known solution to this issue? [1]: https://www.rfc-editor.org/rfc/rfc4871#section-5.3

We have a setup where students log in (using LDAP auth) to Ubuntu 16.04 machines, where two network cards are installed: one to connect to the LAN and Ethernet, and the second one to expose a connection for user devices (e.g. Raspberry Pi). Currently, the secondary network interface (and the related iptables rules and dnsmasq daemon) is permanently up, but we'd like to have it up only while a user is locally logged in.

As far as I understand, using systemd it should be possible to have a service (which might be a script taking up or down the network interface) running when a user logs in and out. However, we'd need to make sure that only local logins would work for this (i.e., tty1-6 or the GUI login on lightdm) (this is for compliance reasons, as we can't leave around "free-to-use" network cables that can work without a proper user authentication), and I can't figure out in the documentation how to do this properly.

For now I tried this unit file:

[Unit]
Description=LAN sharing for users

[Service]
Type=oneshot
RemainAfterExit=false
Restart=no
ExecStart=/sbin/ifup eth1
ExecStop=/sbin/ifdown eth1

[Install]
WantedBy=default.target

But I can't manage to have this run as root at user login, nor how to ensure that this is a local login. Is this at all possible with systemd (on Ubuntu 16.04 LTS, i.e. systemd version 229-4), and how to properly implement it? I would expect this to be trivial (I would see this as giving privileges for a peripheral like sound card only to locally logged in users).

For our installation image for Windows 10 (Education version), I'd like to prevent users from creating new folders on the C:\. The installation is used by students sharing PCs in a class room, and therefore we want to keep the main directory of the disk clean (they all have home directories to store their data). In the current installation of Windows 7 I could very simply edit the permissions using the standard Windows GUI. With Windows 10, it fails.

What I already tried:

• Changing the permissions from the GUI → Failed to enumerate objects in the container (Access is denied).
• Taking ownership of the C:\ directory from the GUI → Access is denied
• Adding a Deny entry from the GUI, without changing the existing permissions → Access is denied
• Changing the permissions using cacls from an elevated command prompt → Access is denied
• Taking ownership from an elevated command prompt using the takeown /f c:\ /a command → Access is denied
• Same cacls and takeown commands from a command prompt running under the SYSTEM user (obtained with psexec64) → Access is denied

Despite the fact that it should not be a security risk to allow users to create their own folder at C:\ (new files are not permitted), this is not what we want, because we would like to make sure people use their home (which has backups and snapshots, unlike the local PC hard drives).

The permissions on C:\ look the same that were on a Windows 7 Enterprise installation, including the mandatory label (icacls displays in both cases Mandatory Label\High Mandatory Level:(OI)(NP)(IO)(NW)), and the owner is the same (TrustedInstaller), so I wouldn't expect to see a difference between Windows 7 and Windows 10 on this.

Now, there is an option that actually works: using cacls from the Windows 10 recovery command prompt. However, although this solution is fine for the image deployment, we also have several machines that need to be corrected manually because we can't reimage them. Despite the fact that I can boot the Windows 10 recovery over PXE (using memdisk and an ISO image of the CD), it would be very helpful if this could be done from within the actual OS running on the machines. Even better if it can be one with a GPO.

The EPEL package for Nagios on RedHat Enterprise Linux 6 has been updated some weeks ago from version 3.4 to version 4.3. The update has been done by a simple yum update command, and nothing indicated a major version change.

Although after the update Nagios was seemingly working fine (all services are properly visible in the Web interface), not much is actually working: service checks are not performed and mails are not sent either. Dozens of error messages are visible in /var/log/messages:

Jan 26 15:58:55 srv1 nagios: Unable to send check for host 'srv3' to worker (ret=-2)
Jan 26 15:58:58 srv1 nagios: Unable to run check for service 'Total Processes' on host 'srv4'
Jan 26 15:59:05 srv1 nagios: Unable to run check for service 'Lab Home Partition' on host 'srv1'

Furthermore, trying to restart nagios ends up in an error that was not present before the update: No usable PID found in /var/run/nagios/nagios.pid. This part of the issue seems to have a solution here: Nagios Woudn't Start, now won't Stop!

After noticing that the update created a /etc/nagios/nagios.cfg.rpmnew file, I ran a diff with the original config file from the 3.5.1 RPM to see what the differences were, and changed the actual config file accordingly. The changes are mainly concerning the position of some files used at runtime (here are the values of the new version):

object_cache_file=/var/spool/nagios/objects.cache
precached_object_file=/var/spool/nagios/objects.precache
lock_file=/var/run/nagios/nagios.pid
temp_file=/var/spool/nagios/nagios.tmp
check_result_path=/var/spool/nagios/checkresults

This solves the stop/restart issue mentioned above, however, it breaks the web interface, which now displays Error: Could not read object configuration data!. And the service checks still don't run.

Error messages are also present in /var/log/audit/audit.log, indicating that the issue is probably related to SELinux (the system is running in enforced mode):

type=AVC msg=audit(1516991640.421:263116): avc:  denied  { getattr } for  pid=29_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1516991640.421:263116): arch=c000003e syscall=4 success=n fsgid=494 tty=(none) ses=4000 comm="check_procs" exe="/usr/lib64/nagios/plugins

Indeed, temporarily setting SELinux to permissive mode completely solves the issue; however, this is not a solution. How to properly update the SELinux settings while keeping SELinux in enforcing mode?

I have a Samba server (version 3.6.23-30) running on a RedHat Enterprise sever version 6.7. It is joined to Active Directory, and authentifies the users to AD. Winbind is not running ("Winbind is not used; users and groups are local" situation, according to the Samba howto). This worked perfectly since a long time, until the last update from samba 3.6.23-25 to 3.6.23-30 (actually several fixes for security issues, including Badlock, were introduced 10 days ago in 3.6.23-26, but that version was never deployed here).

I tried downgrading Samba to 3.6.23-25, and that solves the problem (but of course is not a solution, given the security fixes contained in 3.6.23-26):

yum downgrade samba-3.6.23-25.el6_7.x86_64 samba-common-3.6.23-25.el6_7 samba-winbind-clients-3.6.23-25.el6_7 samba-client-3.6.23-25.el6_7 samba-winbind-3.6.23-25.el6_7

After the installation of the update, users could not connect anymore to the shares on the server, directly getting an "Access denied" message:

C:\Users\admin>net use \\servername /user:INTRANET\username
The password or user name is invalid for \\servername.

Enter the password for 'INTRANET\username' to connect to 'servername':
System error 5 has occurred.

Access is denied.

This is not due to a wrong password or anything like that, because in that case, it displays error 1326 (username or password is incorrect). The connection has been tried from Windows 7, Windows Server 2012 R2, and even Windows XP SP3, with the same result.

net ads testjoin says that that server is correctly joined to Active Directory. I also tried leaving AD and rejoining it, but it didn't improve the situation.

The error message for the client in the smbd log (using a debug log level) is:

[2016/04/18 14:09:19.133618,  2] ../libcli/auth/credentials.c:289(netlogon_creds_client_check)   credentials check failed
[2016/04/18 14:09:19.133674,  0] rpc_client/cli_netlogon.c:623(rpccli_netlogon_sam_network_logon)   rpccli_netlogon_sam_network_logon: credentials chain check failed 
[2016/04/18 14:09:19.134036,  0] auth/auth_domain.c:331(domain_client_validate)   domain_client_validate: unable to validate password for user username in domain INTRANET to Domain controller AD6. Error was NT_STATUS_ACCESS_DENIED. 
[2016/04/18 14:09:19.135842,  5] auth/auth.c:281(check_ntlm_password)   check_ntlm_password: winbind authentication for user [username] FAILED with error NT_STATUS_ACCESS_DENIED 
[2016/04/18 14:09:19.135917,  2] auth/auth.c:330(check_ntlm_password)   check_ntlm_password:  Authentication for user [username] -> [username] FAILED with error NT_STATUS_ACCESS_DENIED

Now, if I start the winbind daemon, the authentication problem disappears and users could successfully connect to the Samba server. However, in that case a second annoying problem appears. Taking a directory where a user only has rights because of the group membership (i.e. user is member of a UNIX group on the Samba server):

username$ ls -l /export/projects/testproject
drwxrws---.  2 root testgrp     4096 Apr 18 11:24 testproject

Here, username is member of the testgrp group and can successfully access the directory:

username$ ls -l /export/projects/testproject/
-rw-r--r--. 1 root testgrp         0 Apr 18 11:24 test.txt

The same user connected to the Samba server could not access the directory (access denied). Before the update (with winbindd disabled), the access worked fine. I guess this has something to do with the fact that winbindd is running, as the testgrp group does not map to any AD object (it is displayed in the Security tab of the Windows Explorer as UNIX group\testgrp).

Is there any way to be able to use local groups as here with winbind enabled (and without the need of creating corresponding AD objects)? I tried adding this to smbd.conf:

idmap config * : backend = tdb
idmap config * : range = 1000000-1999999

but it does not improve anything, also because I guess this is rather mapping AD users/groups to Linux ones, rather than the opposite.

Or in alternative, what could be the "access denied" problem when running Samba without winbindd? Is that a bug introduced by the update (and therefore should be sent as a bug report to RedHat), or rather a feature due to some change in the security model?

A common way to test an existing website on a new server before switching it to production by updating the DNS record is to change the hosts file on a development machine (/etc/hosts on *NIX systems, and %windir%\system32\drivers\etc\hosts on Windows), to have the OS resolve the hostname of the server to the new server. The developer can thus test the new server in real conditions before the actual deployment.

Now, changing the hosts file also has some downsides, among which:

• the developer might forget to remove the change, with possibly undesired effects on the long term
• the change requires administrative access on the machine

Hence the question: is there a way to do this change only within the browser (for Firefox, Chrome, and/or MSIE)? Looking for Firefox, I've found two or three add-ons, but they all do the same: modifying the OS-wide hosts file.

I'm looking for a self-contained lightweight solution working on both MS Windows and Linux, that does not require administrator privileges (so I can for example have students do that on their lab PCs), and without any external hardware/services (e.g. a router doing DNS spoofing or a proxy server doing the same).

We currently have a setup (running on Ubuntu 14.04 LTS) with mixed LDAP/NIS authentication and automounted home directories from several servers (with the auto.home map distributed over NIS). Everything runs smoothly as long as the user logging in (either with NIS or LDAP) already has a home directory somewhere (i.e., ls /home/user successfully triggers its mounting).

I wanted to use pam_mkhomedir.so to have local home directories automatically created for people not having a home on the servers (which works fine on normal setups), but of course this could not work (same problem described in this question: LDAP/NFS/PAM/AutoFS : mkhomedir PAM plugin failling), as autofs and pam_mkhomedir could not work together. Any mkdir in /home actually fails when automounting is enabled there, therefore making a bind mount inside /home is also not a solution.

Does anybody know a good solution to have local home directories created for uses not having a NFS home, knowing that we have no control over the info coming from the LDAP (i.e., users must have their homes in /home/username, and autofs is working there), and without hacking into autofs sources? Creating a home on a NFS server at login would be a possibility, but how to do that in a safe way?