Sysadmins ought to know what they are doing.
Most Linux distributions have a significant focus on security. This does not mean they are necessarily ready for production out of the box. Tools like SELinux, excellent firewall options, and robust access controls can make Linux exceptionally secure. Despite this, actually deploying a Linux system into production still requires …
Sysadmins ought to know what they are doing.
They should also have a sporting chance of setting up a system with which they're unfamiliar based upon sysadmin level knowledge of other systems (ie: Knowing what you want/need to achieve) and a web search engine.
Not sure I agree about using Webmin! In fact a new Linux user should not deviate from the prepackaged stuff in the default repos IMO. It also does not help you learn what is really going on if all you do is use a nice pretty GUI - if you want to do that you may as well use Windows if you can afford it, its hard to move away from a GUIbut is well worth it.
I think its a shame that SELinux is not enabled by default on Debian though and that the default firewall is set to to allow everything! Dont forget to close down you ipv6 too! Time to switch?!
> Not sure I agree about using Webmin!
Webmin is a Good Thing(tm). It dramatically increases the discoverability of a server's features for the uninitiated.
But as I say every time the subject comes up, it has two significant problems: you need to be *very* careful if you try to have multiple users (as it doesn't really have them - they're all subsets of root), and you shouldn't do much sendmail administration with it (it writes the sendmail.cf file directly, meaning the sendmail.mc file gets out of sync, so future .mc modifications will roll back your webmin changes...)
Webmin is usually one of the first things I install on Linux just so I can get a visual overview of the system. I generally don't leave it running though...
It's also handy for finding the name/location of the config files you are looking for but can't remember (locate is great when you can remember some or all of the name of a config file).
"It also does not help you learn what is really going on if all you do is use a nice pretty GUI - if you want to do that you may as well use Windows"
There is nothing wrong with GUI, if that's what you want, provided you understand its limits. Likewise there is nothing wrong with CLI, if that's what you want, provided you understand its limits.
Rename a thousand files - Use the CLI
Tell me which of those files is a picture of a dog - Use the GUI
I also frequently use Webmin on linux servers along with Virtualmin for web hosting set ups. It can speed up many mundane tasks and is a great way to make learning Linux sys admin more accessible.
Unlike other control panel type apps (I'm looking at you C'panel) it uses the default config files an packages so you can use it for some tasks while going back to the terminal and config files for other things. Best of both worlds really.
Really makes life easier having it installed on any linux box.
Always been a bit gun-shy about webmin myself (though must admit I've not tried it in some years). Not for any failings inherent to itself, but more the worry of incompatibility with a particular distro. Admittedly for something like CentOS I'd expect this to be well-maintained, but I always feared (and did experience at least once) that a module might not match up correctly with that distro's version of the underlying app, and using it would hose something.
I never really looked into how (or to what extent) webmin's devs had made it respond correctly to different app versions and distro packaging inconsistencies. The former I'd hope they would have a stab at, the latter rests mainly with the distro maintainers. Anyone got some insight on this?
Paris loves a bit of GUI administration.
Not at all snobish. The windows management GUIs are simply much better than webmin.
The problem I have with GUIs in general is just you dont learn as much about how things work. You need this knowledge for when something breaks and you need to manually edit a zone file or change some permissions somewhere and look at log files,once you have this knowledge then using a script to make the task quicker is a good option or indeed - a gui. Obviously when viewing data or typing a letter you are not going to use the CLI but for most server administration functions there is rarely a need. If nothing else Webmin opens up another area of potential attack and is largely unnecessary IMO.
The CLI is best described as powerful, cryptic and dangerous. Many GUIs are basically wrappers around a CLI-like command parser, in part to make things easier for the user to carry common tasks and in part to prevent something Godawfully stupid from happening because of a miskey. Anecdotally, I was using a CLI the day I accidentally reformatted the office dev server's hard drive. It would have taken a lot more effort to achieve this via a GUI.
I was about to say something like this...it's relatively easy to get truly catastrophic fuck-ups from the command line. A GUI works better for me, certainly. We're a visual species.
> Tell me which of those files is a picture of a dog - Use the GUI
Out of a thousand files? Are you kidding? That's going to be a ton of work.
It would be far better to do that with an automated tool. The real problem is that no such beast seems to exist. You use the GUI because you don't have a better option, not because it is actually a better option.
@Jedidiah - I don't know which OS you use, but mine has a preview option that can show filenames alongside a largeish icon of the image. Scroll down the list, it should take you a few seconds, if you're wanting to pick one image out.
I don't think you fully comprehend the scope of the problem described.
And just how long have you been holding onto that gem?
Sendmail module on webmin has "M4 configuration." Use that, then have it build your .mc. I have been using it for >5 years, works like a hot damn.
> Sendmail module on webmin has "M4 configuration."
Yes. But if you edit that, it'll throw away stuff you've done with the other config tools, which edit the .cf file directly.
This is why I raise the issue. Every time, you tell me you get it - then post stuff like this.
Webmin is a fine tool, but it runs the risk of rolling back changes if you edit the .m4 file after you've used it to effect other changes. I wonder that you keep trying to ignore this very simple fact.
If you use the M4 config editor, it will indeed blow away all other changes in the .mc. I don't know that I'd ever "ignore that fact," Vic. It's pretty much the way M4 is support to work. If you use tools that edit the .mc directly - or you enjoy going in and editing the .mc by hand - then do not use the sendmail module in webmin. Period.
That said, I was taught emphatically to never edit the .mc file in sendmail directly. In fact, I have been berated and mocked by sendmail devs for doing so. If I go onto a sendmail forum for help, or I try the mailing list, etc...I am repeatedly and forcefully told that I am never to do anything outside of M4. M4 is where configuration changes are "supposed" to be made, and so I make them there.
Things like virtuser and aliases as generally include files nowadays, so I can use the Sendmail webmin module to edit those without clobbering my config every time I touch M4. This means that the Sendmail module will allow me to do things “properly,” which means that when I need support from the community, I have at least a snowball’s chance in a neutron star of getting it.
That said, I would never berate someone for editing the .mc directly. There are so many different ways to do something in Linux that I don’t feel it’s my place to tell someone that their method is “wrong,” so long as it works consistently for them. I don’t have the jihadi attitude about such things that is so prevalent amongst Linux nerds.
So if you are following the “rules” as laid out by the Sendmail devs, you are using M4 to generate ever config change, with aliases, virtuser, generics etc pulled out as includes so they don’t get clobbered by M4 regeneration. In that case, I highly recommend the Sendmail module, because it works…even when something else edits the M4 or the includes.
If however you edit the .mc directly, the sendmail module in Webmin will screw up your Sendmail something fierce and you should stay away from it!
I suggest postfix, which is much easier to set up. I use my old master.cf and main.cf, aliases etc files heavily wounded with my own comments to set new ones. BTW this would be useless with the webmin approach.
Postfix isn't required for a great many cases. Such as when the local mail elements are being used to mail reports on behalf of a web application, or when you are using the Linux system's mail subsystem only as a pre-filter front-ending another system. (ClamAV + Mailscanner + Spamassassin, etc.)
They make for good, cheap, easy pre-filters for Exchange, for example.
I have spamassassin attached :
smtp inet n - - - - smtpd -o content_filter=spamassassin
etc piped at by postfix daemon. It works. ClamAV would not be very different, I guess. Postfix has a sendmail compatibility interface. gnu or bsd mail-utils and/or mutt are very handy too.
I heard that there are instances where sendmail does very complex job that postfix cannot handle. Haven't seen any of those myself.
@eulampios where exactly did I say that postfix couldn't or wouldn't use spamassassin, mailscanner, clamav or other?
I said you didn't need postfix to use them. The implication was not that postfix cannot use these technologies, but that postfix is more complicated to configure than sendmail. The further implication of that statement is that postfix is generally A Better Option, but that using the more complex tool isn't necessarily always required.
I wouldn’t want to run a full-bore business off of Sendmail – though I do admit that my PERSONAL email server is Sendmail – Postfix or QMail are better options than Sendmail for an actual email server.
That said, if I am not using the system to store emails – merely to send them on behalf of a web server, or to filter-and-forward (with or without LDAP lookups) – then I prefer to use the simpler tool. It is kinder to future admins who in most cases won't have 30+ years *nix experience.
Neither batch-renaming image files nor identifying an image of a dog are normal tasks for a sysadmin. The _limitations- of a GUI are why CLI is more useful.
Never did I contradict with what you said. I just felt (and heard) that postfix is an easier to set up and maintain option. On FreeBSD sendmail (or its default counterpart) did not seem to be hard to work with either...
@eulampios please try someday to front-end an LDAP-based email service with Postfix. Exchange is common, but I have LDAP QMail systems in the wild as well. Sendmail is significantly easier to set-up in as a simple mailfiter for LDAP-backed systems. (You want to be able to have the MTA do LDAP lookups so that you can do simple things like reject mail for addresses that don't exist, and banhammer systems that repeatedly try multiple non-extant addresses.)
Similarly on many Linux distros - CentOS is a great example - you don't need to "set up" sendmail at all. You simply "yum install apache php sendmail" and suddently your PHP scripts can send e-mail out. (In my case, i trap all outbound mail with an edge device and apply whatever filtering I need to there, but the principle of "it Just Works" remains.) If you need to make minor changes in Sendmail, use the M4 config (text-based) or the Webmin module.
Postfix is only easier if you are actually using it to host e-mail, rather than simply to process email. (In which case; Postfix all the way; never use Sendmail to host email!)
In more modern distros "apt-get install postfix" is enough to get a running mail system hosting whatever domain you want with a local mail store and an external mail server for sending if you so desire.
I don't see how you consider it hard to use postfix with LDAP since postfix supports it natively and it's mostly just a matter of putting "LDAP:" instead of whatever other store you could have used.
It also has some nice config items I use to restrict message size, ban certain attachments etc before the message reaches my mostly perl based filters.
Postfix seems to work out-of-the-box if the LDAP server is located on the same system as postfix itself, and that system is configured to talk to it, etc.
In my experience, getting sendmail to talk to an LDAP server is two lines in the M4 configuration. I don't have to configure PAM, the LDAP config file or anything else. Sendmail can be set up to talk to a remote LDAP server without having to involve or configure another thing on the Linux box.
Postfix only ever seems to work with a remote LDAP system if the Linux box is itself configured to authenticate against that LDAP domain. I prefer to not have to join my servers to the domain in order to do simple lookups.
That said, if you happen to have a link to any chunk of the postfix manual (or a decent walkthrough) that can show me how to set up postfix to a Windows Active Directory server without having to get the rest of the Linux system authenticating against AD, I'd be greatly indebted!
It sounds like postfix was using system accounts for delivery. That is the default and good for small setups but far from ideal when it comes to larger setups. I am not an expert on LDAP but I dug this up for you and I hope it helps.
Thank you for the link; I will give it a more in depth look tomorrow. At first glance, it looks like a walk-through focused on creating a postfix filterserver using a local LDAP setup. I'll poke at it some and see if I can figure out how to tie it back to Active Directory instead of a local LDAP setup. If I can figure it out, I'll do up a howto.
It would be nice to have a simple way of front-ending an exchange (or other) mail system using Active Directory as the user interface. Easy in Sendmail, but so far I've never made it work without Postfix using PAM to do LDAP lookups.
If I can make it as simple as sendmail...that's a huge step forward!
> If you use tools that edit the .mc directly - or you enjoy going in and editing the .mc by hand
> - then do not use the sendmail module in webmin
That's pretty much what I keep telling you. And you keep telling me you know better.
> I was taught emphatically to never edit the .mc file in sendmail directly
I very much doubt you were told that.
You were almost certainly told not to edit the .cf file directly.
> I am repeatedly and forcefully told that I am never to do anything outside of M4.
So you *weren't* told not to edit the .mc file. Like I said, then...
> M4 is where configuration changes are "supposed" to be made, and so I make them there.
And if you use the sendmail module in Webmin, that statement is no longer true, as it alters the .cf file directly for a number of options. Hence the warning I keep maknig, and you keep telling me isn't important.
> I suggest postfix, which is much easier to set up
That's somewhat subjective; personally, I find sendmail much easier to set up than postfix, but that's almost certainly down to the fact I have far more familiarity with it than I do with postfix...
> BTW this would be useless with the webmin approach.
There is a webmin module available for postfix. I've no idea how well it works...
> Postfix seems to work out-of-the-box if the LDAP server is located on the same system
Yes, that's the default. If you want it to talk to a different server, you use the server_host parameter. If you don't specify that parm, you get "localhost"...
I think we have a misunderstanding here; I don't use the Webmin module to edit any part of sendmail that would typically be part of the .cf. I use the M4 generator in the webmin module to exit those. I use the aliases and virtuser and so fort to edit those parts of the config that are in includes.
But you are correct; there are widgets in that sendmail config module that are flat out bad. They edit the .cf directly. And I would not ever recommend using those chunks of that module. It's useless! As soon as you touch the M4 config - which is how all config changes are "supposed" to be generated - then it wipes out our .cf; including any changes to the cf that you made with the sendmail module.
So just don't use those bits. I don't. But I do find it a convenient way to edit M4, edit "include-filed" items like aliases and virtuser, as well as manage the queue.
We are both right here, I think. There is value to the Sendmail module; but not ALL of it. It does edit the cf directly, which it should not do…but there are still other parts of the thing that work properly. I see no reason to throw the whole module away based on that; you just need to know it – and Sendmail – well enough to know what bits you cannot use.
I’d be far happier if they’d just pull the section that directly edit’s the cf out altogether…but I’ve simply ignored that for so long I just don’t notice it any more.
Maybe I need to do an article on that? "Webmin's sendmail module; which areas are safe, which break the rules."
Webmin module for postfix is quite good...unless you want to use LDAP...
Actually...now that I look at a fully up-to-date Sendmail module, it might be that only two sections of twelve are "dangerout/useless." From what I can see "Sendmail Options" and "Network Ports" directly edit the .cf. The rest seem to edit include files that don't get clobbered every time I regenerate the M4.
That's actually doing better than I remember...
that security is overridden by rank. Most places I've worked are happier to pay for a few days outage due to a virus or firewall breach if it means the boss or other important lackeys can do as they choose.
I've even sat with some and shown them how security invariably matches almost perfectly with other company ownership issues and their little faces light up with recognition and then a few days later the desire to not have to remember what their job should entail overrides all else.
Someone has lied about computing being easy for 20 odd years and reality isn’t going to change that in a hurry.
Just changing the port SSH runs on doesn't make it anymore secure.
If you must expose SSH services at least lock them down to known source locations.
Well, I've moved the port WELL upwards and disabled root AND only use PKI login (no interactive password login). Good enough?
Probably not, I'm no expert, but it's my best try. And in the end that's all you've got for the most part - educated guesses.
>Just changing the port SSH runs on doesn't make it anymore secure.
Maybe not, but it does mean you waste a [Insert Undesirable Afterlife Destination Here] of a lot fewer cycles dealing with botnet dictionary attacks.
"Just changing the port SSH runs on doesn't make it anymore secure."
Maybe not, but moving it well up stopped a lot of noise from the script kiddies who were active several years ago. I don't just mean noise in the logs, but the disk on my home system used to rattle pretty non stop when it was on port 22; life got more peaceful once I'd moved it.
If you install fail2ban as suggested in the article, then that will automatically kill off the brute-force botnet attacks.
Alternatively, these extra firewall rules right before you accept the ssh-connection will limit the number of attempts to 2 per minute. Can also be used for other services, if you like.
iptables -A INPUT -m state --protocol tcp --destination-port ssh --state NEW -m recent --set
iptables -A INPUT -m state --protocol tcp --destination-port ssh --state NEW -m recent --update --seconds 60 --hitcount 2 -j DROP
Right, it is usually recommended to disable password login and use key login instead.
"Just changing the port SSH runs on doesn't make it anymore secure."
True. BUT: You can now configure your firewall to say "You tried to frob port 22: ON TO THE BLACKLIST YOU GO!" You can do that IMMEDIATELY: no waiting for a log in failure to be created. Under Linux, you can have a firewall rule immediately add that IP to a "recent" IPTables rule, and have that rule be checked at the very beginning of checking an incoming packet.
You can place the REAL ssh server on another port (with mandatory keypair needed, no keyboard-interactive, no root log in, FAIL2BAN in effect) and greatly reduce the amount of time J. Random ScriptBot can have at your system.
Ditto for any other well-known port you AREN'T making generally available: Put a (metaphorical) land mine there - touch that port, immediately be blacklisted.
@David D. Hagwood
Would you look at that? Amidst the dross; a sysadmin emerges! Yes sir, someone who understood exactly where I was going with "don't run the thing on a standard port" without having to have it explained. You don't run RDP on 3389 and you sure as all get-out don't run SSH on 22.
Them is the honeypot ports. Security through obscurity isn't security at all...but a minor dollop of obscurity is useful in catching the obvious idiots who like to eat your CPU cycles with their useless TCP packets!
Blows my mind that this apparently needs to be explained to "senior Linux administrators," but what're ya going to do, eh?
I have an office full of web devs that use SCP with key to transfer files to the server. That's 6 people running SSH connections through our single outgoing IP so take a guess what blindly allowing only 2 connections attempts per minute would do to their ability to get work done.
Fail2ban is a better option since it only punishes the bad users rather than everyone equally.
Using standard ports as a honey pot only works if you have total control over who connects to your system and over what links. The idea fails badly if you ever have offices in more than one country or have people who work from home.
Do you want to be the guy to explain to a paying client why their whole office can't connect just because someone ran some software on it's default settings?
In situtaions like this - where I happen to know what IPs that most people are coming from - I whitelist the IPs. In fact, I generally have the DNS names whitelisted alongside some dynamic DNS deployments for remote/home users.
Works wonders for more than just SSH. SIP phones for example…
>Just changing the port SSH runs on doesn't make it anymore secure.
Yes it does.
It doesn't make it *secure*. It's certainly 'security through obscurity', but it is a mite more secure than leaving it on the default 22.
>If you must expose SSH services at least lock them down to known source locations.
Great! Now can you tell me the IP source address of the wifi access point in Terminal 7 of Amsterdam airport, because my boss has just called to say that mail is down, and I need to ssh in quickly to reboot the server.
Biting the hand that feeds IT © 1998–2018