microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.37k stars 817 forks source link

CSF-LFD doesn't work properly on a WSL installation. #1552

Closed ghost closed 4 years ago

ghost commented 7 years ago

Just installed another WSL on build 14393.576 and disabled openssh server via apt-get uninstall openssh-server.

Did:

cd /usr/src
rm -fv csf.tgz
wget https://download.configserver.com/csf.tgz
tar -xzf csf.tgz
cd csf && sh install.sh
sed -i 's/TESTING = "1"/TESTING = "0"/g' /etc/csf/csf.conf
csf -r
perl /usr/local/csf/bin/csftest.pl
# cd /etc/csf && sh uninstall.sh

Got:

csf will not function on this server due to FATAL errors from missing modules [6]

I found only one result when I strict-search this in Google, and there isn't any general-audience-solution there:

http://www.webhostingtalk.com/showthread.php?t=1104523

fpqc commented 7 years ago

It says it relies on missing (kernel?) modules. If that is the case, the team would have to port or reimplement (depending on the license) those modules as Windows kernel drivers. The best place to request this is on the WSL uservoice.

CSF modules are apparently plugins for the iptables kernel module, which isn't and probably should not be implemented, since the Netfilter project is in the process of making it obsolete. The new firewall subsytem for Linux is called NFTables, which replaces the old list-traversal method of creating firewall rules with a nifty Compiler/bytecode/vm approach.

In nftables, your rules are compiled into bytecode for the NFTables VM by the userspace tool nft and sent by netlink sockets into the new nftables kernel module. The kmod uses a small number of simple opcodes to describe the logic of the firewall rules as primitive netfilter operations. This means that new features can be and are mostly being added in the userspace compiler.

The interesting thing is that since so much of nftables is being implemented in userspace (nft and libnftnl), it might actually be somewhat straightforward to replace the nftables kernelmode driver/VM with a compatibility layer in the lxcore driver. But if you want it, you've got to uservoice it!

benhillis commented 7 years ago

I took a look at this and it looks like the csf -r command is getting caught up on a couple of things. Before the missing modules error message there are a bunch of error messages about iptables. Looking at what's failing I see these two things:

/sbin/iptables Missing AF_INET RAW protocol 255 Missing ProcFs file /proc/[pid]/net/ip_tables_names

thebz commented 7 years ago

Nor should it, currently.

I don't know what guides you're following, but you should understand that WSL is not a standard Linux distribution. It's totally ok to not know something, but your last few issues are based on information from elsewhere that applies to standard Linux distributions.

I also don't know why you posted those logs, but neglected to post all the error strings. I've done so below, but be aware that to get good help you need to provide all the information.

Testing ip_tables/iptable_filter...FAILED [FATAL Error: iptables v1.6.0: can't initialize iptables tablefilter': Table does not exist (do you need to insmod?)] - Required for csf to function Testing ipt_LOG...FAILED [FATAL Error: iptables v1.6.0: can't initialize iptables table filter': Table does not exist (do you need to insmod?)] - Required for csf to function Testing ipt_multiport/xt_multiport...FAILED [FATAL Error: Could not open socket to kernel: Protocol not supported] - Required for csf to function Testing ipt_REJECT...FAILED [FATAL Error: iptables v1.6.0: can't initialize iptables tablefilter': Table does not exist (do you need to insmod?)] - Required for csf to function Testing ipt_state/xt_state...FAILED [FATAL Error: Could not open socket to kernel: Protocol not supported] - Required for csf to function Testing ipt_limit/xt_limit...FAILED [FATAL Error: iptables v1.6.0: can't initialize iptables table filter': Table does not exist (do you need to insmod?)] - Required for csf to function Testing ipt_recent...FAILED [Error: Could not open socket to kernel: Protocol not supported] - Required for PORTFLOOD and PORTKNOCKING features Testing xt_connlimit...FAILED [Error: Could not open socket to kernel: Protocol not supported] - Required for CONNLIMIT feature Testing ipt_owner/xt_owner...FAILED [Error: Could not open socket to kernel: Protocol not supported] - Required for SMTP_BLOCK and UID/GID blocking features Testing iptable_nat/ipt_REDIRECT...FAILED [Error: iptables v1.6.0: can't initialize iptables tablenat': Table does not exist (do you need to insmod?)] - Required for MESSENGER feature Testing iptable_nat/ipt_DNAT...FAILED [Error: iptables v1.6.0: can't initialize iptables table nat': Table does not exist (do you need to insmod?)] - Required for csf.redirect feature

ghost commented 7 years ago

Error strings? Sorry, I copied the only stderr available on the CLI without viewing any log (as I recall).

I am not an operating system developer and basically new to Linux, I just need CSF-LFD to higher the chance of preventing Bruteforce when logging in to WSL from a remote server.

I have now tried to install CSF-LFD on another WSL, updated. After installation.

csf -r:

*Error* Unable to lock [/proc/self/status]: Operation not supported at /usr/local/csf/lib/ConfigServer/Config.pm line 153.
*WARNING* URLGET set to use LWP but perl module is not installed, reverting to HTTP::Tiny
iptables v1.4.21: can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
Error: FASTSTART: (DROP no logging IPv4) [] [iptables-restore v1.4.21: iptables-restore: unable to initialize table 'filter']. Try restarting csf with FASTSTART disabled, at line 5080

perl /usr/local/csf/bin/csftest.pl:

Testing ip_tables/iptable_filter...FAILED [FATAL Error: iptables v1.4.21: can't initialize iptables table filter': Table does not exist (do you need to insmod?)] - Required for csf to function Testing ipt_LOG...FAILED [FATAL Error: iptables v1.4.21: can't initialize iptables tablefilter': Table does not exist (do you need to insmod?)] - Required for csf to function Testing ipt_multiport/xt_multiport...FAILED [FATAL Error: Could not open socket to kernel: Protocol not supported] - Required for csf to function Testing ipt_REJECT...FAILED [FATAL Error: iptables v1.4.21: can't initialize iptables table filter': Table does not exist (do you need to insmod?)] - Required for csf to function Testing ipt_state/xt_state...FAILED [FATAL Error: Could not open socket to kernel: Protocol not supported] - Required for csf to function Testing ipt_limit/xt_limit...FAILED [FATAL Error: iptables v1.4.21: can't initialize iptables tablefilter': Table does not exist (do you need to insmod?)] - Required for csf to function Testing ipt_recent...FAILED [Error: Could not open socket to kernel: Protocol not supported] - Required for PORTFLOOD and PORTKNOCKING features Testing xt_connlimit...FAILED [Error: Could not open socket to kernel: Protocol not supported] - Required for CONNLIMIT feature Testing ipt_owner/xt_owner...FAILED [Error: Could not open socket to kernel: Protocol not supported] - Required for SMTP_BLOCK and UID/GID blocking features Testing iptable_nat/ipt_REDIRECT...FAILED [Error: iptables v1.4.21: can't initialize iptables table nat': Table does not exist (do you need to insmod?)] - Required for MESSENGER feature Testing iptable_nat/ipt_DNAT...FAILED [Error: iptables v1.4.21: can't initialize iptables tablenat': Table does not exist (do you need to insmod?)] - Required for csf.redirect feature

If it isn't possible to use this firewall (or any other) in WSL then I wonder how I could defend from bruteforcing my private key, when trying to login. I believe there is a solution and I hope it will be published here so other users could benefit from.

aseering commented 7 years ago

@Benosika -- if you're worried about someone brute-forcing your SSH key (as distinct from "password") on a WSL system, then you're doin' it wrong :-) SSH keys, especially larger-than-default keys (such as 4096-bit keys as documented here), are extraordinarily hard to brute-force. As far as I know, it has never been done before. However, WSL itself is beta software; it regularly has new bugs, etc. If I were trying to hack an SSH server hosted on WSL that I knew used SSH keys, I wouldn't even bother trying to brute-force the key; I would go find a 0-day exploit in WSL and use that to hack in without requiring authentication at all. (Or I would go get a $5 wrench :-) Not that I would personally actually do that, but these days a lot of hacks are because of people revealing information rather than because the technology itself wasn't properly secured.)

The security concern is not with SSH keys. It's with SSH passwords. SSH password auth definitely can be, and often is, brute-forced. So if you want to avoid being hacked, easy: Disable SSH password authentication; only allow logins using SSH keys.

aseering commented 7 years ago

Also, if you really do want to play around with this, I wonder if a program like "DenyHosts" might work better? One that uses /etc/hosts.deny rather than firewall rules. (I don't actually know; just guessing.)

aseering commented 7 years ago

Also also, if you want to do this, keep in mind that WSL does not officially support system services at all at this time. So what you're trying to do is out of scope for WSL right now; that's why it's not easy to get it working :-) I think the official way to do what you're trying to do would be to acquire and set up a Windows-based SSH server. Use native Windows security tools and firewalls. Then, when you ssh into Windows, just run bash.exe to get a Linux prompt.

It's not that WSL can't be made to run an ssh server. It's more a case of "use at your own risk" :-)

ghost commented 7 years ago

Much thanks! I do tend to use keys of about 4096 bytes. Maybe just using a native tool for Windows SSH is what I need (or else, a virtual box with a small Linux).

ghost commented 7 years ago

BTW @aseering , I must say I didn't know that all system services aren't supported, I didn't even know WSL is still beta... When I read in the Wiki article "Windows subsystem for Linux" I didn't find the term beta besides that WSL's Ubuntu is 14.04. It's good to know there are plans to make it a full scale Ubuntu compatibility layer.

If I understand correct, for now we have all of the Linux kernel, all the Linux utilities that come with Ubuntu, but all of the Ubuntu shell besides system services.

ghost commented 7 years ago

BTW, do you think that the current release of WSL is ready to be as a substitute for a Linux system, in case you want to raise an Apache server and make your PC be the dedicated server instead paying about 70$ a month?

aseering commented 7 years ago

@Benosika -- when you installed WSL, the checkbox that you had to check to enable the feature was labeled "(Beta)". It's also called out in a special info box at the top of the main "About" page on the official documentation. (That "About" page, by the way, is the first link in the Documentation section in this GitHub site's README. So they kinda put the "beta" label right front and center :-) It's not called out like that on every page because there are other things that need to be called out too.

(By the way, I'm not sure which Wiki page you're referring to, but recent versions of WSL now default to Ubuntu 16.04. So perhaps that page could use an update?)

If I may be so bold: Slow down a little :-) Based on your questions on this bugtracker, I would guess that you are jumping eagerly and quickly into WSL. Which is great. So eagerly, in fact, that you're jumping right over important information. WSL is not going to solve your particular problem as quickly and with as little effort as you seem to have assumed. So I think you would benefit from spending more time understanding each step as you perform it, so that when you hit something that doesn't work (which you surely will -- you already have), you know why and can either fix it or ask informed questions about it.

Regarding existing functionality: WSL does not (yet!) give you anywhere close to the entire Linux kernel. The kernel is huge; WSL currently only supports a small fraction of it. However, the small fraction of the kernel that it does provide, enables probably 90+% of userspace applications to work :-) (The Linux kernel has a small core that's heavily used, and lots of drivers and lesser-known IPC and security and compatibility and monitoring and other features some of which are more often required than others. That's why prioritization is a big thing in this bugtracker; they're going for the high-impact kernel functionality first.)

Any stock Linux functionality that doesn't work with WSL, stems from missing kernel features. For example, system services don't work because systemd requires a handful of kernel features (mostly I think to do with process/service namespacing and isolation?) that WSL doesn't support yet.

There's also the question of what's available by default. Even if systemd did work, Windows doesn't choose to run it on boot. You would have to run it yourself, or set up something on the Windows side to launch it automatically for you. Would you want systemd to run automatically? I would argue that perhaps you wouldn't, at least not yet: WSL would currently use the stock Linux list of services, and many of those services (network-device configuration, DNS resolution, filesystem mounting and management, system clock management, initialization of the graphics subsystem [even for text terminals via kernel mode setting], managing the system hardware clock and syncing to timeservers, etc, etc) are things that Windows also does. In the best case, you waste time and system resources starting redundant and partially-redundant services. In the worst case, those services end up conflicting with each other -- for example, what if Windows is configured to set the low-level system hardware clock to local time, and Linux sets it to UTC and dynamically computes local time based on what timezone you're in? (That behavior is something that can be configured on both sides.) Then the two will be setting the clock back and forth, and getting all kinds of confused... More generally: This isn't Linux. It's Linux on Windows :-) It's not trying to replace a VM; it's trying to be a new thing, with greater integration than you'd usually have with a pure-Linux environment. The interactions between the two systems have not yet been fully worked out; there are a lot of rough edges in the details there.

If you want to get a better understanding of what works and what doesn't, a good starting point would be to look at the features that users are asking for. That list is the WSL UserVoice. Note that the entry for system-service support ("cron jobs, daemons, and backgrounds tasks") is pretty highly requested, but not the most highly-requested thing; there are other big things that are missing and that people really want.

In terms of using WSL to replace your dedicated Linux server: WSL is initially targeting developers. So developer tools (language compilers and interpreters, other build tools, etc) are what will tend to work best. I think you absolutely could get WSL running as a personal server, but it will require a significant amount of experimentation depending on exactly what services you need.

One other thing for you to consider, if you are thinking about moving away from a hosted service: Say you have a nice fast PC that uses 250 watts (0.25 kilowatts) of power at idle. (That's more than a cheap off-the-shelf system, but if you've got a storage RAID or a high-end graphics card it's easy to use that much power and more. Note that, if you're using a system as a dedicated server, it typically can't use standby or other more-effective power-saving modes because then it can't respond to incoming network requests.) Where I live, electricity costs roughly $0.20/kilowatt-hour. So, let's do the math: 0.25 kW 0.2 $/kWh 720 hours/month is $36/month added to your electricity bill, to use your PC as a dedicated server. Better than $70, sure, but still a lot of money. So what I did is, I spent $200 on a micro power-efficient Linux PC that's slow but still about as fast as $70/month hosting will buy for you, and that uses 30 watts of power in steady-state. Doing that math: 0.03 kw 0.2 $/kWh 720 hours/month is ~$4/month. So the dedicated PC paid for itself in about 6 months.

Another option: If you don't need that much compute power, go spend $40 on a Raspberry Pi 3. (Or a similar device, but in my experience the Pi has a great user community.) They're not fast, but they're super low-power compared to a desktop PC, and they run Linux and they have an Ethernet port. Instant dedicated server :-) Either way, you can then use WSL on your desktop PC for what it is IMO best at: Providing a bridge that lets you build and test stuff for your Linux server using your Windows PC.

ghost commented 7 years ago

I carefully read your answer and learned much from it. Thank you! I now recall I'm informed WSL is beta on installation though I never read the original documentation and will check it, as well as the UserVoice. I don't know how much it costs to keep my PC working for weeks (it's an old PC from 2009) but I guess with years it will be cheaper to have a dedicated server at home (if I buy a new PC). in any case it would be better for me from hiring anything external with the current prices... Thanks again!

therealkenc commented 4 years ago

Error here boiled down to:

iptables v1.4.21: can't initialize iptables table `filter': Table does not exist

That's /dupe #767

ghost commented 4 years ago

Hi! We've identified this issue as a duplicate of another one that already exists in this repository. This specific instance is being closed in favor of tracking the concern over on the referenced thread.

Thanks for your report!