Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
What's the story with these ads on Slashdot? Check out our new blog post to find out. ×

Comment Re:Because we are distracted by "global warming" (Score 1) 148

I don't believe in that either. There is no global warming, and no poisoning or pollution of anything.

I am willing to stipulate that global warming happens and concerns may have some bearing, if you will just agree that toxic chemical releases and water contamination are a bigger more immediately pressing issue that GW should not distract us from.

Also, we have done most of what is within our power regarding GW, and if we weren't so distracted, we could have much more beneficial improvements if our officials would concentrate on fixing things that are the most seriously broken that they can have the greatest positive impact on.

Especially when we have credible scientists warning that the EPA is so negligent in the latest accident that it seemed like it could have been a planned accident to get their way politically.

I'm giving the EPA the benefit of the doubt that they were just grossly negligent ---- if BP, or a private cleanup company had committed a clearly incorrect decision with these kinds of disastrous results, there would be billion dollar fines and likely executives going to jail.

Comment Re:How often are the addresses re-validated? (Score 1) 104

If you have clients whose accounts are compromised, then [...]

It's not the same users over and over again. It's a different user almost every time.
The couple users that DID get re-compromised, after we unlocked their account, were cancelled as a customer after the 3rd incident, and their computer was legitimately infected ---- It is just totally not our job as ISP to help them clean up their infection for free.
There are about 3,000 hosted and ISP mailboxes and 500 domains.

We do incoming and outgoing mail relay for by last count several thousand private mail servers as well.

We deactivate the account immediately when we find them, and delete all their queued messages.

The problem is finding them, because spammers are not always calling attention to themselves.

Generally, found issues come from accounts that the spammer gained access to through brute force. We have many defense mechanisms against brute force, including password policy for new passwords, not all digits, not all lower, not all upper, banning any IP after 10 successive failed logins, and lockout if more than X IP addresses detected active on an account over Y minutes.

And nevertheless, there are still users that fall for phishing or get their password guessed. It seems like these come in waves, like the spammers are saving them up and acting upon them at an "opportune" time.

Some spam events areinfected systems if they are relaying off of us, since we provide a free SMTP relay host for our ISP customers. We're damned if we don't do that, because we publish end users' dynamic IP address ranges in the Spamhaus PBL, and we always get blamed by customer if a customer's private mail server on their own premises gets blacklisted or has other issues, because "It's our IP address".

It is not straightforward at all to look at an outgoing mailflow and determine if account(s) are compromised. Often something will appear to be outgoing spam, But then turn out just to be an ISP user's free e-mail account that they set to forward all their e-mail to example@gmail.com, OR Out-of-Office responses sent from Microsoft Exchange.

In the past we even got auto-generated spam complaints about forwarded mail, based on the recipient's own forwarding rules!

Comment Re:How often are the addresses re-validated? (Score 2) 104

Many, many spamming IP addresses are hijacked hosts that are cleaned up eventually.

My mail servers IPs have been hijacked for spamming many times, probably about 3 or 4 times a month, but as far as I know, they are generally cleaned up within a few hours, and usually the volume is restricted by message rate controls.

The biggest problem is We have no idea when it is happening, or if there are complaints, which messages are actually true spam, and which messages are just "legitimate marketing" that look spammy.

Also, the RBLS have destroyed mutual cooperation between operators against spam.... we all just have our blacklists, and then we start having equally huge whitelists that represent the hundreds of thousands of legitimate mail transactions that blacklists have incorrectly interfered with.

Nobody really sends detailed abuse complaints anymore or provide any data that could be meaningfully used for reliable spam content identification without false positives. They just put IP addresses straight to blacklist

. Heck, the abuse@ contact address and IP address space WHOIS abuse contacts get no messages at all from humans for the most part, except (ironically) marketing attempts, DMCA letters, and DoS amplification reports.

So the "eventually" part, is because noone's even bothering to lend a hand against the spammers. Perhaps everyone is just overwhelmed and desensitized.

You'll just wake up after some sneaky spammer has been abusing your mail server starting at 4am, and after you find your IP with a bad reputation on a bunch of blocklists with not a single actionable abuse complaint. You will have most RBLs that tell you "their spam traps are secret," and you need to wait 3 days before requesting removal, so they won't even reveal what the spam message looked like, or enough information to identify the abuser on a multi-tenant mail server.

Then there are 'fascist' blacklists who decide, they want to blackmail you and force you to pay a fee for removal. In a number of cases, we have referred those guys to our lawyers, to see if we can do anything about them. Hopefully, law enforcement will eventually lay down the criminal charges against paid-removal blacklists for racketeering.

Then there are reputation services such as Cisco's which has no remediation or contact to resolve the listings at all, And they are highly secretive about how they even work.

Then there are RBLs that insist on blacklisting you for 48 hours, or 5 days, because some spammer managed to go to town for a few hours one night.....

Most often: it is some customer mailboxes whose password has been guessed by spammers who then proceed to abuse the account.

Or a mailbox on a customer mail server relaying off of ours.

It is not so easy to tell when it has happened, because there are plenty of customers running legitimate "newsletters" off their mailbox. We limit each customer to an average rate of 1200 messages per day for some domains, and 250 messages per day for others, but "legitimate" bulk mailers using their normal account to e-mail blast frequently hit the limits and complain about it, Meanwhile, there are spammers who are relentless and send a trickle of messages just below the limits sometimes.

Then there are spammers who use IP addresses of non-mail servers such as workstations..... by co-opting random systems and running random malware that pretends to be a SMTP server, Or they install a local SMTP server and relay off of it.

The latter are frequently short-lived attacks. By the time anything is in a RBL: the spammer has already probably moved on to the next batch of IP addresses to disrupt.

Comment Re:The article does not say... (Score 1) 148

Reducing one's use of paper products will not reduce global deforestation

I suggest banning the sale of lumber products taken from natural forests, Or of farm or other products created on formerly forested land without paying a heft fee per hectare of land.

Let the economic ramifications work their way back through the system and remove any significant incentive for people to deforest land.

Comment Confirmation bias (Score 1) 292

Or Texas Sharpshooter fallacy. It was always fun shooting bullets at the barn, and then afterwards painting the targets with the bullseye around each bullet.

Recorded history isn't that long. If you start with a conclusion, then you are always going to find evidence for it.

There is some probability of such events happening with OR without climate change.

Comment Re:chroot is not for security. like change directo (Score 1) 744

Sounds to me like you are banking on kernel exploits being more rare than they actually are.

Well, from a chroot environment running as a non-root user: it is going to be a technical challenge to make calls to the kernel directly, and for all you know a syscall filtering mechanism is in place, And chroot is just one of the early lines of defense.

Comment Re:read the man page (Score 1) 744

Gonna be kind of tthough to have a ahell without a tty, aka /dev/*tty*So yeah, you need /dev.

False. In fact you're false on so many counts, that I'll just show with a session excerpt to a jailed shell.

[~]# uname -ir
2.6.32-573.1.1.el6.x86_64 x86_64 [~]# grep support1 /etc/passwd
support1:x:1411:1411::/var/jail/./home/support1:/usr/sbin/jk_chrootsh
[~]# grep support1 /var/jail/etc/passwd
support1:x:1411:1411::/home/support1:/bin/bash
[~]# cat /proc/uptime
246835.99 239072.52
[~]# su - support1
[~]$ cat /proc/uptime
cat: /proc/uptime: No such file or directory
[~]$ ls -la /dev
total 8
drwxr-xr-x. 2 root root 4096 Aug 19 10:01 .
drwxr-xr-x. 10 root root 4096 Aug 19 10:07 ..
[~]$ ls /proc
ls: cannot access /proc: No such file or directory
[~]$ find / | grep tty
find: `/home.a/lost+found': Permission denied
/usr/share/terminfo/p/putty-256color
/usr/share/terminfo/p/putty
/usr/share/terminfo/p/putty-vt100
[~]$ whoami
support1
[~]$ ld
bash: ld: command not found
[~]$ /lib64/ld-linux-x86-64.so.2 /bin/date
Mon Aug 31 01:35:54 CDT 2015
[~]$ cat /bin/date > date
[~]$ ./date
bash: ./date: Permission denied
[~]$ /lib64/ld-linux-x86-64.so.2 ./date
./date: error while loading shared libraries: ./date: failed to map segment from shared object: Operation not permitted
[~]$ /lib64/ld-2.12.so /bin/date
Mon Aug 31 01:37:17 CDT 2015
[~]$ /lib64/ld-2.12.so ./date
./date: error while loading shared libraries: ./date: failed to map segment from shared object: Operation not permitted
[/home.a/support1]$ find / | grep '/ld'
/etc/ld.so.cache
/etc/ld.so.conf
/usr/bin/ldd
/lib64/ld-2.12.so
/lib64/ld-linux-x86-64.so.2
[~]$

Comment Re:Bullshit (Score 1) 744

yet it has never been clear to me which variables get passed over to the root session ans which do not

All exported environment variables, just as if you started a spawned a shell binary with the same user.

Except on systems that implemented PAM su, on these systems, PAM modules might be used to change the values of ulimits or some other environment variables, or clear some.

They might do this because it is the desire of whoever configured the system to assign additional characteristics to certain interactive root or other-user shells.

Comment Re:The way this should end (Score 1) 744

In the long run, he's not going to be satisfied until he's created his own OS, kernel and all because he calls anything he didn't write a "broken concept," whatever that is

How about we get someone to fork the Systemd that distros have adopted and start working on fixing it, paring it down, and removing unneeded functionality into separate optional related projects?

Comment Re:chroot is not for security. like change directo (Score 2, Informative) 744

You can ALWAYS "break out" of chroot.

If you get a shell in one of my chroot's used for security, then.....

  • Your uid and gid are not going to be 0. Good luck telling the kernel to try and get you out.
  • There aren't going to be any /dev, /proc, or other special filesystems inside your chroot.
  • There aren't going to be any compilers or setuid binaries inside your chroot
  • If this is a FTP area, there won't be any binaries at all
  • Only the minimum files actually necessary for the program that uses that chroot are going to be found inside that chroot.
  • You won't have a chmod() command anywhere available inside that chroot.
  • All unnecessary POSIX capabilities will have been masked out from the process.
  • There won't be any writable locations in your chroot, the whole chroot will be mounted on a read-only file system, except if there is a place where writes are required by the legitimate software, And those mount points will have been marked as noexec.
  • The kernel will be running PaX or GRSecurity, such that most user data areas are non-executable, and memory pages expected to be executable of programs will get marked as read-only as they are launched, so only available binaries can be used to communicate with the kernel through syscalls.

In short: I think chroot is plenty good for security. There's no way in hell you are breaking out, without a straight up kernel arbitrary execution exploit.

Comment Bullshit (Score 5, Insightful) 744

Lennart Poettering's long story short: "`su` is really a broken concept

Declaring established concepts as broken so you can "fix" them.

Su is not a broken concept; it's a long well-established fundamental of BSD Unix/Linux. You need a shell with some commands to be run with additional privileges in the original user's context.

If you need a full login you invoke 'su -' or 'sudo bash -'

Deciding what a full login comprises is the shell's responsibility, not your init system's job.

Comment Re:That's gonna be a nope (Score 1) 134

I don't want a tracker device to give every advertiser every single piece of data the phone gets. I don't want a media device slinging ads, loaded with bloatware.

You can either have a smartphone, or you can avoid having those things, not all 3 things.

Nokia 3310 for no ads, bloatware, trackers for advertisers.

It's not a smartphone, but it is a smart phone.

Every successful person has had failures but repeated failure is no guarantee of eventual success.

Working...