How they are saved depends on the distro. If you use something like Fedora before this, then whether using a gui or command line, you are effectively editing a file and then reload that file by restarting a sudo service. If you use something like gentoo, then it saves your firewall on shutdown or at your request.
You can adjust the Fedora / RHEL / CentOS firewall on the fly with the iptables command. Yes you could just edit the save file and then reload the firewall, but it's always been possible to make firewall changes on-the-fly without doing a reload. It was just tedious, especially for long intricate chains. If you then want to make the changes permanent, you issue the save command.
$ sudo service iptables save
That saves the rules out to the/etc/sysconfig/iptables file (which is what gets loaded when you do "service iptables load").
Frankly, this sounds more like UI changes for interacting with IPTables, and not a core change to how IPTables works.
(Note: I'm speaking from experience with CentOS 5.x and RHEL 5.x, not Fedora.)
Is the advantage of adding those devices going to bring in more revenue than the extra effort and lost/compromised data is going to cost?
Yes, I predict a lot of these policies will last for as long as it takes for someone to abuse the policy and for corporate legal to get involved.
At which point you will end up back with an approved device list and not being allowed to use personal devices for corporate usage.
There will always be someone who ruins it for everyone.
Can someone explain why the ability for for Drive By's can happen AT ALL an how come the code that allows this sort of shit to happen has not been ripped out with extreme prejudice after the very first occurrence of this behavior?
Because you're letting random websites run code (Javascript, Flash, PDF, Java) on your computer. And even though that code is sandboxed (by Flash or Java or JavaScript or Adobe PDF Reader) there are flaws in those sandboxes that allow for arbitrary execution of code. Which then lets the little nasty critter out of the sandbox and into your user profile where it can dig in and make itself comfortable.
I'm so confused. Why do the antivirus / anti-malware packages out there not detect and delete these stupid things?
Because anti-virus and anti-malware tools are reactive.
There will always be a lead time between when the malware hits the wild and when anti-virus and anti-malware vendors update their signature databases. That time period can range from hours to months.
(Yet another reason to browse in a way that only whitelisted sites are allowed to do fancy things. It may be a PITA, but it drives down the risk of infection by a few orders of magnitude.)
Why is this even allowed (widget impersonation) is beyond me. The reason being, clicking the big X in the upper right should do one thing only, close a window, not install Super Deluxe Antivirus 2011, Doomsday Edition.
And wasn't anti-popup technology supposed to fix this?
a) Web browsers serve text and images. They do not (yet) monitor what the content of those images look like. It's very easy to create a web page that looks a lot like an operating system warning, you just have to keep it within the borders of the page.
(Which is why some systems dim the entire screen before presenting security dialog prompts. That's something that a fake alert in a web browser can't do.)
b) Anti-popup technology does not yet handle DHTML(?) pop-ups or pop-ups done with CSS tricks. On the plus side, those tricks are constrained to the browser tab where they occur instead of actually popping open additional browser windows of random sizes in front of or behind the existing browser window.
Do you check that all your files are there before taking a backup? Probably not. Even if you have a very complex strategy of nested backup with grandfather and his whole family, odds are that once you notice that the said file is gone, it is also gone on your backup.
rdiff-backup
The backup directory has a pristine copy of the current data, with the outdated content stored as incrementals going back as far as you want. (We do 13 months.)
Any sort of delta/snapshot style backup strategy handles this just fine. As long as you have enough space on the backup media to store all of the deltas for the time duration that you want.
Thanks, I knew of Webscription, but not Fictionwise.
My Sony PRS-505 is a bit over 3 years old now. I love the dear thing, but it's not holding a charge as well as it used to (I can't leave it alone for a month straight and still expect to use it, now I have to tend to it every 2 weeks).
When it dies in another few years, I'll probably pickup a PRS-350 or whatever is the successor in that model. My interest for ebooks is solely leisure, cover-to-cover, reading.
Me, moderately annoyed by CentOS 6 not being out yet? Eh, not really.
The 5.6 boxes are running fine and will be for a few more years. RHEL5 doesn't exit the normal life cycle until March 31, 2014, and the extended life cycle runs until March 31, 2017. So we have until 2014 for regular patches and 2017 for critical security patches.
Which means that CentOS will still be shipping critical security patches until 2017 as well.
How can you steal something when Redhat make it available for free? You pay for Redhat if you want support and their management tools. They probably consider CentOS a loss leader, a lot of their business is likely "won" by converting sysadmins from the free distro.
That's why we use it.
We use CentOS on the boxes where support doesn't matter and RHEL on the boxes where it does matter. It didn't cost us anything to dip our toes in the water and get comfortable with how CentOS does things. And that knowledge transferred right over when we started using RHEL for the important stuff.
2: FTP for anonymous downloads is one thing (assuming a hardened FTP server.) Anonymous uploads can be done too, provided you clean the incoming directory. FTP for users with passwords sent plaintext is just bad form. Use sftp, or scp for this.
The best way to do anon uploads.
- Keep them in their own folder (usually/uploads).
- Don't allow files to be downloaded by other anon users.
- Bonus points if the files are invisible once uploaded.
- As you state, clean the files off the server after a short period.
Our anon upload server sees files like "test1.zip" being uploaded about once a year by automated probe tools. But since they can't download the file once its up there, they can't use the server as a warez / nasty-stuff distribution hub. So they move on.
And the long answer. All you can do is firewall, and use things like fail2ban.
Which does nothing against distributed attacks where each IP only tries a handful of username/password pairs before the next bot in the network takes over.
(You would need to be a member of a large organization, with a few thousand machines all sharing information on failed attack attempts.)
If the users need to authenticate - switch to SCP over SSH. Switching to SFTP sounds nice in theory, until some tech comes along and screws up the FTP server config and people are able to start logging in again over regular FTP.
If the content is designed to be public readable, setup a download only FTP site that requires no authentication, and do the uploads via SCP.
If you need to allow uploads, setup a folder that allows anonymous uploads, but don't let FTP users download from that folder. Retrieve the files from the server using SCP, or have an automated system scan them for malware (and delete anything that starts with the EXE signature) and then transfer them over SSH to an internal server.
(Never allow anonymously uploaded files to be downloaded by anonymous users. The warez folks will come camp on your server as a way to trade files. Which is why you set/uploads as upload-only and require the use of a different access method to retrieve the files.)
If your security is even modest as far as passwords there is no need to worry.
Unless they're solely doing FTP over SSL, then as soon as one of their customers goes to a coffee shop with an open WiFi, those passwords (no matter how complex) are useless once sniffed.
Just say no to authenticating over non-encrypted channels (Telnet, FTP, POP3, SMTP, IMAP).
WinSCP for Windows, and probably half a dozen others (FileZIlla?)
On Linux... scp at the command line. Or rsync over SSH.
Same answer for OS X.
Once SSH is in the picture, you can do all sorts of magical things over it. And rsync over SSH takes care of the "resuming large downloads" issue entirely.
denyhosts is your best bet, IMHO. After a few failed attempts, it blocks the IP and kills automated attacks.
Except that for the more serious attackers, who have botnets at their disposal, it doesn't do much. In a attack by a botnet, each IP address only hits your server a handful of times and they're synchronized so that each bot tries a different username/password combination. But since there are a few thousand or tens of thousands of machines in the botnet, it adds up to a few tens of thousands of attack attempts.
denyhosts and fail2ban are fine against the script kiddies operating from a single source IP, but not so good against the larger adversaries.
The point of "don't rely on security through obscurity" is that being obscure should not be your only layer of defense.
Moving your SSH service off of the default port has a few benefits:
- Most of the standard attack scripts no longer work against your server.
- Your security logs are 99% less cluttered (if not 99.9%), making it easier to see the more determined and worrisome attackers.
I never leave a public facing server's SSH port on the default, it's not hard to specify an alternate port in the SSH clients and it makes my life a lot simpler when I don't have to wade through a few thousand password attempts each day on the standard port. There are a few attackers out there who do port-scanning first to find the SSH port before trying dictionary attacks, but since we don't do password authentication they're still left out in the cold unless they get our private SSH keys.
The difference between using SSH key authentication and plain old passwords is pretty large.
- In order to attack password authentication, you can be anywhere in the world, use a botnet, and pretty much have no restrictions or advance work needed. You can probably even just sniff them off the wire if the users are using FTP / POP3 / IMAP / SMTP-AUTH without encryption.
- In order to attack SSH key authentication, you have to first obtain a copy of the SSH private key. Which is not what your everyday attacker is prepared to do. Your server is no longer the "low hanging fruit" that 99% of attackers go after. And getting the private key file would require either physical access or a trojan that steals SSH keys.
(There's not much that will fully protect you against a determined adversary who is specifically targeting you. Just like there's no such thing as a perfect safe or lock. But you can at least make it darned difficult for them.)
Public-facing FTP sites are only good for (2) things.
1) Distribution of public material. In which case you upload it with scp (over SSH) then just grant anonymous access to download the files.
2) Upload-only for clients / users to upload files that can't be uploaded (easily) via some other method or which are too large to fit in an email. Make sure that you don't allow uploaded files to be downloaded, otherwise the warez folks will come park their bits on your server.
Either way, you should be using scp instead of FTP for password-based authentication and for the secure transmission of files that need to be uploaded/downloaded. If you're doing password authentication over FTP (and not even using SSL), then you're just begging to get hacked.
Password safe programs, or encrypt the contents of the text file with GPG. Which has advantages like being able to send backup copies of site passwords to your webmail, or printing it out and putting it in safe. The main issue is that you have to keep your GPG private key safe, but I'm used to taking precautions with that.
You should rewrite the scripts to only push changes when there are actual changes to be made.
That will drastically reduce your few thousand or few tens of thousands of commits per year down quite a bit.
(We had an automated push system for log files that pushed them into a SVN repository once an hour. That logged about 8760 commits per year. But since log files don't actually change every hour a rewrite of the scripts on the new server will cut that down to a small fraction of the old volume.)
There is a balance point between too many commits and the one big commit. Some of it also depends on your version control system (distributed or centralized).
Was there a concrete reason for that 1-line code change? Does it address a specific bug? Then it's definitely a worthwhile commit. Drafting out a new module? I generally commit about once an hour, just on the off-chance that the computer decides to freeze up / hang / crash / etc. Usually whenever I finish a major block of code or in the case of custom non-programming work, whenever I finish a significant step in a process.
Doing commits every 5 minutes is probably too often, doing commits once a week is way too long (potentially losing multiple days worth of work). And I constantly argue against "end-of-day" commits because those tend to have the worst commit messages.
I suggest committing when:
- You are getting up to stretch. Because after your mini-break, you won't remember enough detail to document why you made the change.
- You've addressed a specific bug or collection of small bugs / changes.
- You've finished a task / reached a natural break point and want to save your progress.
Slashdot Mirror
How they are saved depends on the distro. If you use something like Fedora before this, then whether using a gui or command line, you are effectively editing a file and then reload that file by restarting a sudo service. If you use something like gentoo, then it saves your firewall on shutdown or at your request.
/etc/sysconfig/iptables file (which is what gets loaded when you do "service iptables load").
You can adjust the Fedora / RHEL / CentOS firewall on the fly with the iptables command. Yes you could just edit the save file and then reload the firewall, but it's always been possible to make firewall changes on-the-fly without doing a reload. It was just tedious, especially for long intricate chains. If you then want to make the changes permanent, you issue the save command.
$ sudo service iptables save
That saves the rules out to the
Frankly, this sounds more like UI changes for interacting with IPTables, and not a core change to how IPTables works.
(Note: I'm speaking from experience with CentOS 5.x and RHEL 5.x, not Fedora.)
Is the advantage of adding those devices going to bring in more revenue than the extra effort and lost/compromised data is going to cost?
Yes, I predict a lot of these policies will last for as long as it takes for someone to abuse the policy and for corporate legal to get involved. At which point you will end up back with an approved device list and not being allowed to use personal devices for corporate usage.
There will always be someone who ruins it for everyone.
Can someone explain why the ability for for Drive By's can happen AT ALL an how come the code that allows this sort of shit to happen has not been ripped out with extreme prejudice after the very first occurrence of this behavior?
Because you're letting random websites run code (Javascript, Flash, PDF, Java) on your computer. And even though that code is sandboxed (by Flash or Java or JavaScript or Adobe PDF Reader) there are flaws in those sandboxes that allow for arbitrary execution of code. Which then lets the little nasty critter out of the sandbox and into your user profile where it can dig in and make itself comfortable.
I'm so confused. Why do the antivirus / anti-malware packages out there not detect and delete these stupid things?
Because anti-virus and anti-malware tools are reactive.
There will always be a lead time between when the malware hits the wild and when anti-virus and anti-malware vendors update their signature databases. That time period can range from hours to months.
(Yet another reason to browse in a way that only whitelisted sites are allowed to do fancy things. It may be a PITA, but it drives down the risk of infection by a few orders of magnitude.)
Why is this even allowed (widget impersonation) is beyond me. The reason being, clicking the big X in the upper right should do one thing only, close a window, not install Super Deluxe Antivirus 2011, Doomsday Edition.
And wasn't anti-popup technology supposed to fix this?
a) Web browsers serve text and images. They do not (yet) monitor what the content of those images look like. It's very easy to create a web page that looks a lot like an operating system warning, you just have to keep it within the borders of the page.
(Which is why some systems dim the entire screen before presenting security dialog prompts. That's something that a fake alert in a web browser can't do.)
b) Anti-popup technology does not yet handle DHTML(?) pop-ups or pop-ups done with CSS tricks. On the plus side, those tricks are constrained to the browser tab where they occur instead of actually popping open additional browser windows of random sizes in front of or behind the existing browser window.
Do you check that all your files are there before taking a backup? Probably not. Even if you have a very complex strategy of nested backup with grandfather and his whole family, odds are that once you notice that the said file is gone, it is also gone on your backup.
rdiff-backup
The backup directory has a pristine copy of the current data, with the outdated content stored as incrementals going back as far as you want. (We do 13 months.)
Any sort of delta/snapshot style backup strategy handles this just fine. As long as you have enough space on the backup media to store all of the deltas for the time duration that you want.
Thanks, I knew of Webscription, but not Fictionwise.
My Sony PRS-505 is a bit over 3 years old now. I love the dear thing, but it's not holding a charge as well as it used to (I can't leave it alone for a month straight and still expect to use it, now I have to tend to it every 2 weeks).
When it dies in another few years, I'll probably pickup a PRS-350 or whatever is the successor in that model. My interest for ebooks is solely leisure, cover-to-cover, reading.
There are also message threads over at the MobileRead where people have posted older public-domain books, properly formatted for eReaders.
Not to mention Baen's WebScription which has very good prices and zero DRM.
Also:
Nautilus: sftp://remotehost/home/user
The Nautilus trick works by using Places -> Connect to server in GNOME on Ubuntu. And you can probably also do scp://remotehost/some/directory.
The same trick probably works on OS X.
gFTP does scp as well?
There's maybe something called Fugu for OS X.
Me, moderately annoyed by CentOS 6 not being out yet? Eh, not really.
The 5.6 boxes are running fine and will be for a few more years. RHEL5 doesn't exit the normal life cycle until March 31, 2014, and the extended life cycle runs until March 31, 2017. So we have until 2014 for regular patches and 2017 for critical security patches.
Which means that CentOS will still be shipping critical security patches until 2017 as well.
How can you steal something when Redhat make it available for free? You pay for Redhat if you want support and their management tools. They probably consider CentOS a loss leader, a lot of their business is likely "won" by converting sysadmins from the free distro.
That's why we use it.
We use CentOS on the boxes where support doesn't matter and RHEL on the boxes where it does matter. It didn't cost us anything to dip our toes in the water and get comfortable with how CentOS does things. And that knowledge transferred right over when we started using RHEL for the important stuff.
2: FTP for anonymous downloads is one thing (assuming a hardened FTP server.) Anonymous uploads can be done too, provided you clean the incoming directory. FTP for users with passwords sent plaintext is just bad form. Use sftp, or scp for this.
/uploads).
The best way to do anon uploads.
- Keep them in their own folder (usually
- Don't allow files to be downloaded by other anon users.
- Bonus points if the files are invisible once uploaded.
- As you state, clean the files off the server after a short period.
Our anon upload server sees files like "test1.zip" being uploaded about once a year by automated probe tools. But since they can't download the file once its up there, they can't use the server as a warez / nasty-stuff distribution hub. So they move on.
And the long answer. All you can do is firewall, and use things like fail2ban.
Which does nothing against distributed attacks where each IP only tries a handful of username/password pairs before the next bot in the network takes over.
(You would need to be a member of a large organization, with a few thousand machines all sharing information on failed attack attempts.)
If the users need to authenticate - switch to SCP over SSH. Switching to SFTP sounds nice in theory, until some tech comes along and screws up the FTP server config and people are able to start logging in again over regular FTP.
/uploads as upload-only and require the use of a different access method to retrieve the files.)
If the content is designed to be public readable, setup a download only FTP site that requires no authentication, and do the uploads via SCP.
If you need to allow uploads, setup a folder that allows anonymous uploads, but don't let FTP users download from that folder. Retrieve the files from the server using SCP, or have an automated system scan them for malware (and delete anything that starts with the EXE signature) and then transfer them over SSH to an internal server.
(Never allow anonymously uploaded files to be downloaded by anonymous users. The warez folks will come camp on your server as a way to trade files. Which is why you set
If your security is even modest as far as passwords there is no need to worry.
Unless they're solely doing FTP over SSL, then as soon as one of their customers goes to a coffee shop with an open WiFi, those passwords (no matter how complex) are useless once sniffed.
Just say no to authenticating over non-encrypted channels (Telnet, FTP, POP3, SMTP, IMAP).
WinSCP for Windows, and probably half a dozen others (FileZIlla?)
On Linux... scp at the command line. Or rsync over SSH.
Same answer for OS X.
Once SSH is in the picture, you can do all sorts of magical things over it. And rsync over SSH takes care of the "resuming large downloads" issue entirely.
This doesn't change the problem, brute force attempts come through on ssh too. All you solution does is transfer the question to a different port.
It fixes the issue of FTP sending passwords in the clear.
denyhosts is your best bet, IMHO. After a few failed attempts, it blocks the IP and kills automated attacks.
Except that for the more serious attackers, who have botnets at their disposal, it doesn't do much. In a attack by a botnet, each IP address only hits your server a handful of times and they're synchronized so that each bot tries a different username/password combination. But since there are a few thousand or tens of thousands of machines in the botnet, it adds up to a few tens of thousands of attack attempts.
denyhosts and fail2ban are fine against the script kiddies operating from a single source IP, but not so good against the larger adversaries.
Security through obscurity. That works well. NOT!
The point of "don't rely on security through obscurity" is that being obscure should not be your only layer of defense.
Moving your SSH service off of the default port has a few benefits:
- Most of the standard attack scripts no longer work against your server.
- Your security logs are 99% less cluttered (if not 99.9%), making it easier to see the more determined and worrisome attackers.
I never leave a public facing server's SSH port on the default, it's not hard to specify an alternate port in the SSH clients and it makes my life a lot simpler when I don't have to wade through a few thousand password attempts each day on the standard port. There are a few attackers out there who do port-scanning first to find the SSH port before trying dictionary attacks, but since we don't do password authentication they're still left out in the cold unless they get our private SSH keys.
The difference between using SSH key authentication and plain old passwords is pretty large.
- In order to attack password authentication, you can be anywhere in the world, use a botnet, and pretty much have no restrictions or advance work needed. You can probably even just sniff them off the wire if the users are using FTP / POP3 / IMAP / SMTP-AUTH without encryption.
- In order to attack SSH key authentication, you have to first obtain a copy of the SSH private key. Which is not what your everyday attacker is prepared to do. Your server is no longer the "low hanging fruit" that 99% of attackers go after. And getting the private key file would require either physical access or a trojan that steals SSH keys.
(There's not much that will fully protect you against a determined adversary who is specifically targeting you. Just like there's no such thing as a perfect safe or lock. But you can at least make it darned difficult for them.)
Public-facing FTP sites are only good for (2) things.
1) Distribution of public material. In which case you upload it with scp (over SSH) then just grant anonymous access to download the files.
2) Upload-only for clients / users to upload files that can't be uploaded (easily) via some other method or which are too large to fit in an email. Make sure that you don't allow uploaded files to be downloaded, otherwise the warez folks will come park their bits on your server.
Either way, you should be using scp instead of FTP for password-based authentication and for the secure transmission of files that need to be uploaded/downloaded. If you're doing password authentication over FTP (and not even using SSL), then you're just begging to get hacked.
Password safe programs, or encrypt the contents of the text file with GPG. Which has advantages like being able to send backup copies of site passwords to your webmail, or printing it out and putting it in safe. The main issue is that you have to keep your GPG private key safe, but I'm used to taking precautions with that.
-----BEGIN PGP MESSAGE-----
Version: GnuPG v2.0.12 (MingW32)
hQIMAz00SGeYEuCgARAApEqhL8yaKi4TGy/u+OhpCfeILMDuqJZHiUal3ERSqPpo
GynRpLc8H6bdThJs9Z3p5OLtq2NIKBCRCtAo/vVpgiCvyMqUs/DcH+SfzcL5vSME
aGHzxsjXa7e3zVbFR0ZOAhf7ADHg2MjmdS0U9g8FI9aevGcDv7Rn9XvXmGgXUdyA
qkk1bvEX2trBE2LpEcIXrZjCKQ8HcarNpE77kPluyfQPzKRtomgTJ9TlXgOZ2rRo
ptFbK3HrmpZkjX/gzGBwIC6ZDdJAwvuiGfA00mI8C6reb9Eb69B6tiP//RnFHFg8
9C912U/gCYG9zy3zZU5RN38k5FOh1VNjRUv8D2YDbhmZHGqzeK0TLlly+Mf/5+Gv
eTpuiDij3LwynF/5HtQ3qf0p7H1zYZwp81/OyjyflouLLpTkPug6M5UiJ3kRXYJ6
Dowd35cZb1rvn0ZZxwj4ayNntvSHgEZ2RlJzupE0TT0ZAa1Ec7eoZM2UcIc/hO+y
jBKmZ7vtDqijuo3qs0/OmeyZYr/aG3Tv4+XnW5rSgUf04WRy+T2oIlt9s8KtkRZw
wqak9MOf4gZhGFARkXxC8Itay5i7/wIEfRe/spLCXODQk0tVnlNryd1mRwoXUEoU
wWKvV22vlemn18v60v8hk/gW8tm4/ERDHALsXwRih8lNVqx4AI8OE5kSnyYNYwzS
XQHVk6tz4YXIevvErxNOlDHX1Gc23EgJCRVEt3vACjLYfcCRG+d/p4Jzkdf7qlK6
ZpUG43QcP9rL2BZopsVSDFzVFaX2ihbWAER8cDWRtcjPo0ybdTMYNVI0Cge3Tw==
=KX7+
-----END PGP MESSAGE-----
You should rewrite the scripts to only push changes when there are actual changes to be made.
That will drastically reduce your few thousand or few tens of thousands of commits per year down quite a bit.
(We had an automated push system for log files that pushed them into a SVN repository once an hour. That logged about 8760 commits per year. But since log files don't actually change every hour a rewrite of the scripts on the new server will cut that down to a small fraction of the old volume.)
There is a balance point between too many commits and the one big commit. Some of it also depends on your version control system (distributed or centralized).
Was there a concrete reason for that 1-line code change? Does it address a specific bug? Then it's definitely a worthwhile commit. Drafting out a new module? I generally commit about once an hour, just on the off-chance that the computer decides to freeze up / hang / crash / etc. Usually whenever I finish a major block of code or in the case of custom non-programming work, whenever I finish a significant step in a process.
Doing commits every 5 minutes is probably too often, doing commits once a week is way too long (potentially losing multiple days worth of work). And I constantly argue against "end-of-day" commits because those tend to have the worst commit messages.
I suggest committing when:
- You are getting up to stretch. Because after your mini-break, you won't remember enough detail to document why you made the change.
- You've addressed a specific bug or collection of small bugs / changes.
- You've finished a task / reached a natural break point and want to save your progress.
Sad but true. I doubt very many people under the age of 40 have read the Lensman series.
And don't forget the Q-gun.