This is an online log of my Slackware experiences. Be aware that I'm also using this blog to cover basic and intermediate security issues that may not pertain to Slackware. This is my way of consolidating blogs (I've several of them).
Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts
Friday, November 17, 2017
Some Goodness Not Related To Linux
In my spare time, I game on my gaming PC. Once upon a time, I had a gaming laptop. It's not been used for close to 2 years, as the graphics card went bad.
This particular system is an Alienware M17x R3. I was torn between getting the same graphics card (the GTX 580M, a dedicated mobile graphics card) or upgrading to something like the 680M or 780M.
It's taken me this long to decide. I decided to stick with the 580M, knowing that this card will probably also go bad within 1-2 years (they are not long-in-the-tooth). Why the 580M? Because I didn't feel like hacking the laptop to get the 680M or above to work. They aren't plug-n-play and require some effort to get to work. I wanted no fuss. Plus, the 580M is now a lot cheaper...I got this one for $125, whereas 2 years ago, they were running twice that.
The card I bought was still in it's original packaging, (ie, it was new).
It arrived last night and I spent most of my evening installing it and then struggling with the laptop. There was another issue that I had issues fixing. The damned battery was drained. In this system, it appears that the system throttles down when the battery isn't working. The system was very slow and at first I thought I had grounded something within the internals of the system when I had it open.
I studied up in my spare time at work tonight, got home, removed the battery from the system, rebooted the system and it acted like it was a NEW system! Before then, it would refuse to install the many system patches waiting for it, as well as auto-updating programs such as Steam, Origin, and other programs.
I'm glad I decided to try that first, as I was almost ready to try to re-install the OS.
A new battery is on the way.
I will attempt to game on this system this weekend. I've it tethered to my 27" iMac (using it as a extra monitor, a neat trick that Macs can do).
The card appears to be working well. If it dies within a year, I'll consider upgrading, as some of the newer cards last longer. If it lasts two years, I'll consider buying another 580M.
At some point, I should consider running Linux and using the Steam Linux client.
Labels:
Alienware,
graphics card,
GTX 580M,
linux,
M17x,
Nvidia,
R3,
Steam,
video card
Thursday, November 12, 2015
IPs hammering Postfix
So, I've been lax in checking my logs lately, but decided to check them last night on my Linode server, which is running Ubuntu.
I'm running PSAD but for some reason, it stopped reporting scanning IPs to me. I've fixed that but it won't account for the last few months of PSAD not working.
What I'm seeing in the syslogs are connection attempts to my Postfix mail server. The server appears to have automatically dropped the traffic. I see no indication that Iptables tried to block the traffic, but this is probably due to needing to have Postfix open to the internet.
I can either rely on Postfix to continue to kill these connection attempts or I can add them to the firewall. First, I've to compile a listing of unique IPs (there were many duplicates as well as other connection information that needed to be removed).
The first thing I did was filter any logs not relevant to Postfix and redirect that output to a file. In fact what I did was grep the syslogs using the following filter: 'disconnect from unknown', which showed me every instance of Postfix disconnecting an IP from communication:
The small snippet above shows that there are repeat offenders. That'll need to be sorted out but we'll do that later. Right now, all I need are the IPs. I've to remove everything else.
I then use the following to remove a good bit of the logs:
The result is:
Note that everytime I'm making a change to the output, I'm also redirecting the output to a new file.
I then remove all instances of 'unknown' from the file (I had to add spaces between the the pointed brackets and the word "unknown", otherwise neither will render...remove the spaced for the code to work properly):
All that's left are removing the brackets:
I then sort the file while also only wanting to see unique IPs:
I started out with 394 lines and ended up with 94 unique IPs, across two syslog files. I still have to do the archived syslog files. I also saw that the 94 IPs show many IPs that are in sequence, which means that the culprits are trying to distribute the attacks over a range of IPs (I've posted similar attacks when analyzing SSH logs).
The resulting log file is here.
So, now, I can either be happy with how Postfix is handling the traffic or add the IPs to my firewall ruleset. This was more of an exercise in seeing how well I could quickly assess the nature of the traffic in question and I'm happy (it was simple enough, although I'm out of practice in doing such things).
UPDATE:
1. I scrubbed the archived syslog files and the total, including those IPs I already scrubbed, is 959, and when sorted uniquely, there are 301 IPs.
2. I added the first batch of IPs to /etc/hosts.deny for tcpwrappers to block. I also found that I couldn't use tcpwrappers since I didn't compile postfix with tcpwrapper support, so I installed xinetd (which can wrap services inside itself with some configuration). I'll monitor to see if the IPs will be blocked and if it doesn't work, I'll add the IPs to the firewall's ruleset.
I'm running PSAD but for some reason, it stopped reporting scanning IPs to me. I've fixed that but it won't account for the last few months of PSAD not working.
What I'm seeing in the syslogs are connection attempts to my Postfix mail server. The server appears to have automatically dropped the traffic. I see no indication that Iptables tried to block the traffic, but this is probably due to needing to have Postfix open to the internet.
I can either rely on Postfix to continue to kill these connection attempts or I can add them to the firewall. First, I've to compile a listing of unique IPs (there were many duplicates as well as other connection information that needed to be removed).
The first thing I did was filter any logs not relevant to Postfix and redirect that output to a file. In fact what I did was grep the syslogs using the following filter: 'disconnect from unknown', which showed me every instance of Postfix disconnecting an IP from communication:
root@linode:/var/log# grep 'disconnect from unknown' syslog > /root/postfix_drops
Nov 12 05:44:12 linode postfix/smtpd[15130]: disconnect from unknown[198.206.134.152]
Nov 12 05:46:10 linode postfix/smtpd[15176]: disconnect from unknown[203.157.41.130]
Nov 12 05:57:11 linode postfix/smtpd[15366]: disconnect from unknown[91.205.167.98]
Nov 12 06:03:48 linode postfix/smtpd[15424]: disconnect from unknown[198.206.134.152]
Nov 12 06:05:49 linode postfix/smtpd[15467]: disconnect from unknown[155.208.242.236]
Nov 12 06:17:03 linode postfix/smtpd[15677]: disconnect from unknown[203.122.41.195]
Nov 12 06:17:20 linode postfix/smtpd[15677]: disconnect from unknown[112.175.103.29]
Nov 12 06:21:59 linode postfix/smtpd[15861]: disconnect from unknown[122.154.46.172]
Nov 12 06:22:20 linode postfix/smtpd[15861]: disconnect from unknown[155.208.242.236]
Nov 12 06:23:41 linode postfix/smtpd[15861]: disconnect from unknown[198.206.134.152]
Nov 12 06:35:21 linode postfix/smtpd[16335]: disconnect from unknown[122.154.46.172]
Nov 12 06:48:00 linode postfix/smtpd[16516]: disconnect from unknown[203.157.41.130]
The small snippet above shows that there are repeat offenders. That'll need to be sorted out but we'll do that later. Right now, all I need are the IPs. I've to remove everything else.
I then use the following to remove a good bit of the logs:
root@linode:/var/log# nawk '{print $8}' /root/postfix_drops > /root/postfix_drops_2
The result is:
unknown[91.205.167.98]
unknown[198.206.134.152]
unknown[155.208.242.236]
unknown[203.122.41.195]
unknown[112.175.103.29]
unknown[122.154.46.172]
unknown[155.208.242.236]
unknown[198.206.134.152]
unknown[122.154.46.172]
unknown[203.157.41.130]
Note that everytime I'm making a change to the output, I'm also redirecting the output to a new file.
I then remove all instances of 'unknown' from the file (I had to add spaces between the the pointed brackets and the word "unknown", otherwise neither will render...remove the spaced for the code to work properly):
root@linode:/var/log# sed 's/\< unknown \>//g' /root/postfix_drops_2 > /root/postfix_drops_3
[155.208.242.236]
[203.122.41.195]
[112.175.103.29]
[122.154.46.172]
[155.208.242.236]
[198.206.134.152]
[122.154.46.172]
[203.157.41.130]
All that's left are removing the brackets:
root@linode:/var/log# sed 's/\[//g;s/\]//g' /root/postfix_drops_3 > /root/postfix_drops_4
203.122.41.195
112.175.103.29
122.154.46.172
155.208.242.236
198.206.134.152
122.154.46.172
203.157.41.130
I then sort the file while also only wanting to see unique IPs:
root@linode:/var/log# sort -u /root/postfix_drops_4
94.156.37.145
94.156.37.146
94.156.37.147
94.156.37.148
94.156.37.149
94.156.37.150
I started out with 394 lines and ended up with 94 unique IPs, across two syslog files. I still have to do the archived syslog files. I also saw that the 94 IPs show many IPs that are in sequence, which means that the culprits are trying to distribute the attacks over a range of IPs (I've posted similar attacks when analyzing SSH logs).
The resulting log file is here.
So, now, I can either be happy with how Postfix is handling the traffic or add the IPs to my firewall ruleset. This was more of an exercise in seeing how well I could quickly assess the nature of the traffic in question and I'm happy (it was simple enough, although I'm out of practice in doing such things).
UPDATE:
1. I scrubbed the archived syslog files and the total, including those IPs I already scrubbed, is 959, and when sorted uniquely, there are 301 IPs.
2. I added the first batch of IPs to /etc/hosts.deny for tcpwrappers to block. I also found that I couldn't use tcpwrappers since I didn't compile postfix with tcpwrapper support, so I installed xinetd (which can wrap services inside itself with some configuration). I'll monitor to see if the IPs will be blocked and if it doesn't work, I'll add the IPs to the firewall's ruleset.
Saturday, May 16, 2015
Linux - User Account Management, Part II
In my post titled, "Linux - User Account Management, Part I," I talked about how to check a user's account for expiration. I set a user account to expire on 5/15/2015. It is now 5/16/2015. The user account has expired. When I attempt to log into this account, it shows as expired:
Next, we'll learn how to set the number of days until a password change is required. We'll set the password to expire for 30 days:
ron@slackbox:~$ su norTo re-enable the account, I will use either of the following commands:
Password:
Your login has expired. Contact the system administrator.
usermod -e yyyy-mm-dd usernameWhen running the chage command, there's no message or prompt after execution. I'm able to log back in without issue.
chage -E yyyy-mm-dd username
Next, we'll learn how to set the number of days until a password change is required. We'll set the password to expire for 30 days:
ron@slackbox:~$ron@slackbox:~$ sudo chage -M 30 nor
ron@slackbox:~$
ron@slackbox:~$ sudo chage -l nor
Last password change : May 10, 2015
Password expires : Jun 09, 2015
Password inactive : never
Account expires : Dec 31, 2015
Minimum number of days between password change : 0
Maximum number of days between password change : 30
Number of days of warning before password expires : 7
ron@slackbox:~$
We'll check this account again after 30 days and use the 'password -u nor' command to re-enable the expired password at that time.
Tuesday, May 12, 2015
How to configure a user to run privileged commands & and how to switch user accounts...all via CLI.
How to switch users in Linux? How to run privileged commands without having to run the command as root (or switch to the root account, which can be dangerous)?
'su' can be used to switch from a regular user to the root user. You can check to see which user you are by using the 'whoami' command. Or, you can tell what type of user account you're using by looking at the prompt. The # prompt is the root account and the $ prompt is a regular user account.
You can also use sudo to run privileged commands if the system admin allows your account to run privileged commands.
One quick way to configure sudo to allow a regular user to run privileged commands is to:
Type visudo, which will open up the /etc/sudoers file using vi. Visudo allows you to edit the file in a safe fashion. (visudo locks the sudoers file against multiple simultaneous edits, provides basic sanity checks, and checks for parse errors.) You should find "# %wheel ALL=(ALL) ALL". If you see # in front of a row, it usually means that it's been commented out. That means that any commands will be treated as regular file comments/notes and will not be executed as commands. It means the command is disabled, so to enable that particular command, remove the "#". Save and quit the edit session by typing ":wq" which means write to file and quit the session.
Next, type 'vigr', which opens up the /etc/group file in a safe fashion for you to edit. Find the wheel group within the file and add the account name to the group. For example, my current wheel group within /etc/group shows the following:
wheel:x:10:root,ron,nor
I added the 'nor' user. Type ':wq' again, which saves the edit and quits the session.
Now, when you need to run root-level commands, you don't have use 'su -c' and enter the root password. What happens is that you'll still be prompted for a password, but you'll type in the password associated with the regular account. This keeps the admin from having to share out the system's root password.
Again, these are pretty basic and simple steps unless you're totally not familiar with *nix (these steps can apply to the BSDs or other Unix clones, as well).
'su' can be used to switch from a regular user to the root user. You can check to see which user you are by using the 'whoami' command. Or, you can tell what type of user account you're using by looking at the prompt. The # prompt is the root account and the $ prompt is a regular user account.
You can also use sudo to run privileged commands if the system admin allows your account to run privileged commands.
One quick way to configure sudo to allow a regular user to run privileged commands is to:
Type visudo, which will open up the /etc/sudoers file using vi. Visudo allows you to edit the file in a safe fashion. (visudo locks the sudoers file against multiple simultaneous edits, provides basic sanity checks, and checks for parse errors.) You should find "# %wheel ALL=(ALL) ALL". If you see # in front of a row, it usually means that it's been commented out. That means that any commands will be treated as regular file comments/notes and will not be executed as commands. It means the command is disabled, so to enable that particular command, remove the "#". Save and quit the edit session by typing ":wq" which means write to file and quit the session.
Next, type 'vigr', which opens up the /etc/group file in a safe fashion for you to edit. Find the wheel group within the file and add the account name to the group. For example, my current wheel group within /etc/group shows the following:
wheel:x:10:root,ron,nor
I added the 'nor' user. Type ':wq' again, which saves the edit and quits the session.
Now, when you need to run root-level commands, you don't have use 'su -c' and enter the root password. What happens is that you'll still be prompted for a password, but you'll type in the password associated with the regular account. This keeps the admin from having to share out the system's root password.
Again, these are pretty basic and simple steps unless you're totally not familiar with *nix (these steps can apply to the BSDs or other Unix clones, as well).
Labels:
administration,
linux,
privileged,
root,
su,
sudo,
vi,
vigr,
visudo
Monday, May 11, 2015
Linux - User Account Management, Part I
I've never administered user accounts in Linux. I know Linux but I'd be lying if I said I knew every facet of it. I've created accounts and actually gave a fellow Linux user access to my machine once (checking the logs from time to time just to ensure he wasn't doing things he wasn't supposed to do), but I'd never made an account that had an expiration date (nor a password that had an expiration date). So, yesterday, I created a test account that had an account expiration of May 15, 2015. I want to be able to unexpire the account once it has expired.
I referenced some commands that would allow me to monitor a user account's status. 'chage' is one of those commands:
To check if the password has expired, use the following:
I know these are simple commands and the process itself is simple, but again, I've never done this before and wanted to share what I've learned...someone out there will learn from my experience.
I referenced some commands that would allow me to monitor a user account's status. 'chage' is one of those commands:
I'd use the 'usermod' or 'chage' commands to change the expiration date (using sudo):ron@slackbox:~$ sudo chage -l norPassword:Last password change : May 10, 2015Password expires : neverPassword inactive : neverAccount expires : May 15, 2015Minimum number of days between password change : 0Maximum number of days between password change : 99999Number of days of warning before password expires : 7
usermod -e yyyy-mm-dd usernameI'll use the above commands in a few days just to test.
chage -E yyyy-mm-dd username
To check if the password has expired, use the following:
grep ‘username’ /etc/shadowThe following command would re-enable an expired password:
password -u usernameI encourage you to read the chage and passwd manual pages for further insight on how to use these two commands.
I know these are simple commands and the process itself is simple, but again, I've never done this before and wanted to share what I've learned...someone out there will learn from my experience.
Saturday, May 09, 2015
Installing Slackware 14.1
Awhile back, I bought a bunch of 500GB SATA drives so that I could experiment with Linux and RAID. The plan was to use the drives as one gigantic drive. The setup was somewhat easy to do, but I could never finish the configuration because I kept getting errors when trying to use lilo and grub, so I stopped.
Today, I picked up again, giving up on RAID and just using a conventional setup. I'm trying to install Slackware 14.1, but for some reason, the machine won't boot up after installation. I created a USB boot drive and for some weird reason, it's not readable, although I didn't get any errors when creating it. I also opted to boot from the MBR, and initially had issues getting the system booted up, until I looked in the BIOS settings and saw that the system was trying to boot from one of the other unused disks. Once I fixed that, it booted up without issue. I still may try to recreate the USB boot disk, but I'll do that later.
So far I've done the standard things: created a regular user (immediately), added the regular user to the wheel group and edited the sudoers file to accept root commands from the wheel group. The system also has two NICs and when installing Slackware, the install used the motherboard's NIC and not the extra NIC I installed (this wasn't a huge issue, but had me wondering why I couldn't get an internet connection).
I'm currently using XFCE as a desktop environment. I wanted to use KDE but for some reason, it's not working. It's something to look into later.
I've been without Slackware for quite awhile (the last 4-5 years). I'm also not so Slackware-savvy, but I'm so familiar with installing Slack that I had no issues getting it up and running. I know that Slack has many new and enhanced features. The challenge is to get familiar again. I'll do this without relying on IRC (the days of IRCing are over for me).
I did apply some of the tips listed here, though.
Today, I picked up again, giving up on RAID and just using a conventional setup. I'm trying to install Slackware 14.1, but for some reason, the machine won't boot up after installation. I created a USB boot drive and for some weird reason, it's not readable, although I didn't get any errors when creating it. I also opted to boot from the MBR, and initially had issues getting the system booted up, until I looked in the BIOS settings and saw that the system was trying to boot from one of the other unused disks. Once I fixed that, it booted up without issue. I still may try to recreate the USB boot disk, but I'll do that later.
So far I've done the standard things: created a regular user (immediately), added the regular user to the wheel group and edited the sudoers file to accept root commands from the wheel group. The system also has two NICs and when installing Slackware, the install used the motherboard's NIC and not the extra NIC I installed (this wasn't a huge issue, but had me wondering why I couldn't get an internet connection).
I'm currently using XFCE as a desktop environment. I wanted to use KDE but for some reason, it's not working. It's something to look into later.
I've been without Slackware for quite awhile (the last 4-5 years). I'm also not so Slackware-savvy, but I'm so familiar with installing Slack that I had no issues getting it up and running. I know that Slack has many new and enhanced features. The challenge is to get familiar again. I'll do this without relying on IRC (the days of IRCing are over for me).
I did apply some of the tips listed here, though.
Wednesday, January 28, 2015
CVE-2015-0235: Linux and glibc "Ghost" Vulnerability
Wondering about the Linux Ghost vulnerability?
Here's what I received from the US CERT:
Here's what I received from the US CERT:
The Linux GNU C Library (glibc) versions prior to 2.18 are vulnerable to remote code execution via a vulnerability in the gethostbyname function. Exploitation of this vulnerability may allow a remote attacker to take control of an affected system. Linux distributions employing glibc-2.18 and later are not affected.How to determine if your distribution is affect: run "ldd --version". If versions prior to v2.18 show in the results, you're vulnerable.
US-CERT recommends users and administrators refer to their respective Linux or Unix-based OS vendor(s) for an appropriate patch if affected. Patches are available from Ubuntu and Red Hat. The GNU C Library versions 2.18 and laterare also available for experienced users and administrators to implement.
I used this link to check my Ubuntu servers. Although, that resource doesn't cater to Slackware, the checks can still be applied. I'm not using Slackware as a flavor at the moment, but I'm sure Pat V. is working on a patched version of glibc. In fact, it would be wise to check your distribution's website for further news about this vulnerability and how to patch your particular flavor of Linux.
Sunday, October 19, 2014
Refreshing My Slackware Box
I have been trying to refresh my lab a bit. My Slackware machine hasn't been used in a few years and has 4 older hard drives. I decided to replace the older drives (4 drives - 60-, 80-, 160-, and 60-GB, 3 IDE drives and one SATA drive) and invest in 4 newer drives (4 x 500-GB SATA III).
I want to set up 2 x 500-GB in RAID 0, if possible (software RAID, if possible, hardware RAID if not). I've never set up a RAID array before, and if I can set up 2 x 500-GB in RAID 0, I'll essentially have a 1-TB drive.
I ran into a problem, though. My system seems to not want to always detect the CD drive anymore. Initially, it did, but stopped when I tried to install Slackware 14.1 last night. I got as far as selection of the source drive, even though it detected the CD drive when booting the install CD. I changed the jumper on the back of the drive but it did nothing, and now it won't see the install CD at all. So I decided to try using a USB flash drive as an install source. I also just now noticed that the .iso I'm trying to use is 64-bit, which is the wrong arch. :( I'll download the proper image right now.
I tried using my Alienware system to set up a Slackware install USB flash drive...it was a mess! I ended up just going to my Ubuntu machine and giving it a shot...it is far less confusing. Part of the confusion is that I don't see flushed-out documentation on how to do this in Windows. Most people are either using Unetbootin but the Windows tool for that wasn't detecting the USB flash drive, for some reason. Then, when I tried to use manual instructions, most of the HOWTOs I found weren't clear enough and were a bit vague (trust me...I know how to follow instructions and I've written HOWTOs before).
Hopefully, I can get this working so I can push myself into using Slackware again.
UPDATE --
Just as I finished this post, 'dd' finished. Here's what I did:
This took maybe 10 minutes to do. Again, I have the wrong image, so I'll have to do this all over again...shouldn't be an issue, though.
UPDATE 2 --
Annnnddd...after 2 days of trying getting CDs to be read by the CD reader, I swapped it out with a known working reader. It worked and I threw out the non-working reader. The swapped reader worked for a bit then stopped working too. I then swapped out the IDE cable (yep...no SATA reader in this particular system). It started working again. So, it was the cable and not the readers. Oh, and I went to the trash can and reclaimed the trashed CD reader. :) Slackware 14.1 is now installing, although I still need to read the RAID HOWTO to see what's needed to set that up.
UPDATE 3 --
About that CD reader...it ain't the reader(s). The one I swapped in is intermittent as well, even when paired with known working cabling. It has to be the motherboard that's acting flakey. As well, LILO won't install on my RAID 5 setup...it keeps erroring out and telling me to use another bootup method or to fix the issue (issue has to do with using "--metadata=0.90" on my boot partition setup...I've tried it without setting this particular metadata configuration and it flat-out won't boot). I'd use an alternative boot-up method but the damned motherboard is so old that it doesn't support removable drives such as flash drives as boot-up options. And since the BIOS update utility for this motherboard requires a Windows OS to be installed (and I'm not going to install Windows on this system just to update the BIOS, which might not even fix what I'm complaining about). I'm thinking of just upgrading the motherboard, but if I do that, I'm going to upgrade the CPU as well...gonna go Intel Core i5 and Gigabyte GA-Z87-HD3, more than likely...and if I do that, I'm just going to use it as my main desktop gaming rig, which means I won't be using it as a Linux machine. That might be ideal, since I've a gaming rig that is acting up (its a 6-core AMD CPU system that keeps powering down)...I can relegate that machine to Linux duty after also upgrading it's motherboard and CPU (going Intel i5 as well). I have some decisions to make, I guess.
I want to set up 2 x 500-GB in RAID 0, if possible (software RAID, if possible, hardware RAID if not). I've never set up a RAID array before, and if I can set up 2 x 500-GB in RAID 0, I'll essentially have a 1-TB drive.
I ran into a problem, though. My system seems to not want to always detect the CD drive anymore. Initially, it did, but stopped when I tried to install Slackware 14.1 last night. I got as far as selection of the source drive, even though it detected the CD drive when booting the install CD. I changed the jumper on the back of the drive but it did nothing, and now it won't see the install CD at all. So I decided to try using a USB flash drive as an install source. I also just now noticed that the .iso I'm trying to use is 64-bit, which is the wrong arch. :( I'll download the proper image right now.
I tried using my Alienware system to set up a Slackware install USB flash drive...it was a mess! I ended up just going to my Ubuntu machine and giving it a shot...it is far less confusing. Part of the confusion is that I don't see flushed-out documentation on how to do this in Windows. Most people are either using Unetbootin but the Windows tool for that wasn't detecting the USB flash drive, for some reason. Then, when I tried to use manual instructions, most of the HOWTOs I found weren't clear enough and were a bit vague (trust me...I know how to follow instructions and I've written HOWTOs before).
Hopefully, I can get this working so I can push myself into using Slackware again.
UPDATE --
Just as I finished this post, 'dd' finished. Here's what I did:
ron@Ubuntu1:~$ isohybrid slackware64-14.1-install-dvd.iso
isohybrid: Warning: more than 1024 cylinders: 2326
isohybrid: Not all BIOSes will be able to boot this device
ron@Ubuntu1:~$
ron@Ubuntu1:~$
ron@Ubuntu1:~$ sudo dd if=slackware64-14.1-install-dvd.iso of=/dev/sdb
4763648+0 records in
4763648+0 records out
2438987776 bytes (2.4 GB) copied, 1150.13 s, 2.1 MB/s
This took maybe 10 minutes to do. Again, I have the wrong image, so I'll have to do this all over again...shouldn't be an issue, though.
UPDATE 2 --
Annnnddd...after 2 days of trying getting CDs to be read by the CD reader, I swapped it out with a known working reader. It worked and I threw out the non-working reader. The swapped reader worked for a bit then stopped working too. I then swapped out the IDE cable (yep...no SATA reader in this particular system). It started working again. So, it was the cable and not the readers. Oh, and I went to the trash can and reclaimed the trashed CD reader. :) Slackware 14.1 is now installing, although I still need to read the RAID HOWTO to see what's needed to set that up.
UPDATE 3 --
About that CD reader...it ain't the reader(s). The one I swapped in is intermittent as well, even when paired with known working cabling. It has to be the motherboard that's acting flakey. As well, LILO won't install on my RAID 5 setup...it keeps erroring out and telling me to use another bootup method or to fix the issue (issue has to do with using "--metadata=0.90" on my boot partition setup...I've tried it without setting this particular metadata configuration and it flat-out won't boot). I'd use an alternative boot-up method but the damned motherboard is so old that it doesn't support removable drives such as flash drives as boot-up options. And since the BIOS update utility for this motherboard requires a Windows OS to be installed (and I'm not going to install Windows on this system just to update the BIOS, which might not even fix what I'm complaining about). I'm thinking of just upgrading the motherboard, but if I do that, I'm going to upgrade the CPU as well...gonna go Intel Core i5 and Gigabyte GA-Z87-HD3, more than likely...and if I do that, I'm just going to use it as my main desktop gaming rig, which means I won't be using it as a Linux machine. That might be ideal, since I've a gaming rig that is acting up (its a 6-core AMD CPU system that keeps powering down)...I can relegate that machine to Linux duty after also upgrading it's motherboard and CPU (going Intel i5 as well). I have some decisions to make, I guess.
Labels:
dd,
distribution,
install,
linux,
Slackware,
Ubuntu,
USB,
usb flash dirve
Monday, February 03, 2014
Why You Should Learn to Run a Server Before You Learn to Code
http://lifehacker.com/why-you-should-learn-to-run-a-server-before-you-learn-t-1497178889
This was a good read!
The reader comments were also very much full of rich details and advice. Everyone nowadays wants to learn to program and only thinks of the glorious moments (creating the perfect, most popular app that will make you tons of money). A perfect programmer would be well-rounded and understand server management as well as coding.
This was a good read!
The reader comments were also very much full of rich details and advice. Everyone nowadays wants to learn to program and only thinks of the glorious moments (creating the perfect, most popular app that will make you tons of money). A perfect programmer would be well-rounded and understand server management as well as coding.
Labels:
*nix,
administration,
application,
coding,
linux,
programming,
security,
server
Saturday, January 25, 2014
Scripting book?
I found something nice. See below. As well, I neglected to even consider that Dave Taylor had a Google Plus account (I will follow him).
Labels:
book,
Dave Taylor,
linux,
scripting,
Shell,
shell scripting,
unix
Friday, December 27, 2013
nmon - Linux
Found this little tidbit (nmon) on Google+ (Ubuntu group):
https://plus.google.com/101635552034658832984/posts/BoQk2BibQkJ
It may come in handy during my next troubleshooting crisis.
Monday, December 23, 2013
For those people who are trying to chose the best Linux distro...
For those people who are trying to chose the best Linux distro...
The whole research is here.
Google+ link
The whole research is here.
Google+ link
Tuesday, November 26, 2013
Time-saving Tips - Linux Journal
Wow. I was reading the below link, to refresh myself with screen (I've been slacking with admin'ing my Linux machines, and I rarely get the chance to log in via CLI.
I tried the bit in the article here:
http://www.linuxjournal.com/content/time-saving-tricks-command-line?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+linuxjournalcom+%28Linux+Journal+-+The+Original+Magazine+of+the+Linux+Community%29&utm_content=FaceBook
I tried the bit in the article here:
...[L]et's say I want to run a git push
command again, but I don't remember exactly which one. So I press Ctrl-r and start typing "push". This will match the most recent command, but I actually want the one before that, and I don't remember a better fragment to type. The solution is to press Ctrl-r again, in the middle of my current search, as that jumps to the next matching command.
My mind was blown away. I've never used that method. I always referenced 'history', found the ID# for the command I needed, then typed "!ID" (example, !2015), which would run the command. I'm still in the middle of the article (just two pages), but I'm going to skim over LJ articles during the next few days since I'm off until next Monday...I need to force myself to become more immersed in *nix.http://www.linuxjournal.com/content/time-saving-tricks-command-line?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+linuxjournalcom+%28Linux+Journal+-+The+Original+Magazine+of+the+Linux+Community%29&utm_content=FaceBook
Web Administration Scripts - Linux Journal
I haven't read all of this yet, but since it's related to Linux, Apache, and DDoS, I thought I'd bookmark it and share it here. It's an article by Dave Taylor.
http://www.linuxjournal.com/content/web-administration-scripts?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+linuxjournalcom+%28Linux+Journal+-+The+Original+Magazine+of+the+Linux+Community%29
After I finish reading the article, I'll add any comments I may have to this blog entry.
http://www.linuxjournal.com/content/web-administration-scripts?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+linuxjournalcom+%28Linux+Journal+-+The+Original+Magazine+of+the+Linux+Community%29
After I finish reading the article, I'll add any comments I may have to this blog entry.
Labels:
administration,
apache,
Dave Taylor,
linux,
Linux Journal,
scripts,
web
Thursday, June 20, 2013
Possible Malware Infection on Home System
So, I've a potential malware infection on a host within my home LAN. It is a Windows 7 system. Before anyone ridicules the choice of Windows, let it be known that it is rather easy to secure a Windows system from a lot of malware. Really. And in my line of work, I've seen many non-Windows systems compromised, so my view is entirely different than the typical *nix zealots out there. If you aren't already aware, I tend to be highly objective when it comes to OS ideology. I'm not going to be open to discuss things if the first shared thought is, "why are you using Windows?" I'm not for the "down with the man" mentality.
Now, about this issue. Here are the current symptoms:
McAfee AV is installed. It was found to not be running when I first began to investigate. I reactivated it last night, did a quick scan (no issues detected) and then did a full scan (no issues detected).
I also ran MalwareBytes. It didn't find anything other than some cookies that it suggested to be removed (I removed them).
I also ran both AdAware and Spybot: Search and Destroy. Both found some spyware-related things that I removed. They didn't find anything with high severity.
I also ran the MS malicious software removal tool (it didn't detect any issues).
I did all this yesterday evening and finished around 8PM.
I also have Snort sniffing traffic on the LAN. It is detecting some rather weird traffic. It is seeing the Win7 system trying to communicate with a Linux host on port 137 (the Linux host is refusing the attempts). Also, if I do a tcpdump to see any traffic coming from the Win7 machine, I see the Win7 machine connecting to each Linux server on the LAN on port 80. What's odd about that is that it seems to have focused purely on the Linux machines, and each and every machine it connects to actually has Apache running. I've seen no service scans (or any other scans).
This morning, I decided to check the Snort logs and saw that the activity stopped occurring after my "fix" last night, but that it started up again at 2:44AM this morning. When I checked the Win7 host, McAfee wasn't running. I couldn't restart it (it was unresponsive). I did another MWB scan, which didn't detect anything. I checked the system logs and didn't see anything other than a lot of DNS errors (that may be indicative of anti-antivirus activity). I then went to the McAfee AV home page to get a status of my system and saw that the status was, "This device needs to be online to get the latest protection updates." Weird, especially since I've no indication that the system isn't online.
I decided to search the McAfee pages to see what solutions they offer (free solutions). Right off the bat, I saw that the only thing they offer is a $90 removal service...WTH. Their product let the machine get compromised, then they want to charge an additional $90 for removal (and no other free offerings). That seems hokey. I never had this problem with Norton/Symantec.
At this point, I'm probably going to reinstall the system with it's factory image. This is the first time in a very long time (I'm talking 10+ years) that I've had to reimage due to malware on a Window system. I've other systems in the house running Windows, and some have NO 3rd-party AV (my Alienware system is running Win8 and it's using Windows Defender without issue).
I'll keep this post updated with any other information I discover over the next few days.
UPDATE - I've found some free tools -- http://www.mcafee.com/us/downloads/free-tools/
UPDATE 2 - I've conducted some scans using the free tools and I'm still not able to find anything. I'm wondering if the activity I've observed is actually part of their host discovery toolset...that sorta makes sense. If only I could get some type of verification on this from a McAfee rep, or maybe find some document that describes how the host discovery system works and how it would look from a network security perspective. But all that still wouldn't explain why the AV keeps disabling in the middle of the night...
FINAL UPDATE - Issue resolved. After investigating further, I found that there was no infection. Two things were occurring: 1) I've found that the AV services appear to be polling for services (network discovery - Symantec/Norton has this feature as well), 2) the self-update process had hung, which was causing the AV shutdowns. Once I removed the existing version and got the latest, I found that there was a drastic difference between the two versions. As well, the account portal had changed. The fact that there was a major client upgrade may've broken communication with the account portal (that began working once I upgraded manually). When this subscription is up, I'll either use Windows Defender or use one of my existing Symantec licenses to install that AV onto the system...not liking the McAfee AV experience. :/
Now, about this issue. Here are the current symptoms:
McAfee AV is installed. It was found to not be running when I first began to investigate. I reactivated it last night, did a quick scan (no issues detected) and then did a full scan (no issues detected).
I also ran MalwareBytes. It didn't find anything other than some cookies that it suggested to be removed (I removed them).
I also ran both AdAware and Spybot: Search and Destroy. Both found some spyware-related things that I removed. They didn't find anything with high severity.
I also ran the MS malicious software removal tool (it didn't detect any issues).
I did all this yesterday evening and finished around 8PM.
I also have Snort sniffing traffic on the LAN. It is detecting some rather weird traffic. It is seeing the Win7 system trying to communicate with a Linux host on port 137 (the Linux host is refusing the attempts). Also, if I do a tcpdump to see any traffic coming from the Win7 machine, I see the Win7 machine connecting to each Linux server on the LAN on port 80. What's odd about that is that it seems to have focused purely on the Linux machines, and each and every machine it connects to actually has Apache running. I've seen no service scans (or any other scans).
This morning, I decided to check the Snort logs and saw that the activity stopped occurring after my "fix" last night, but that it started up again at 2:44AM this morning. When I checked the Win7 host, McAfee wasn't running. I couldn't restart it (it was unresponsive). I did another MWB scan, which didn't detect anything. I checked the system logs and didn't see anything other than a lot of DNS errors (that may be indicative of anti-antivirus activity). I then went to the McAfee AV home page to get a status of my system and saw that the status was, "This device needs to be online to get the latest protection updates." Weird, especially since I've no indication that the system isn't online.
I decided to search the McAfee pages to see what solutions they offer (free solutions). Right off the bat, I saw that the only thing they offer is a $90 removal service...WTH. Their product let the machine get compromised, then they want to charge an additional $90 for removal (and no other free offerings). That seems hokey. I never had this problem with Norton/Symantec.
At this point, I'm probably going to reinstall the system with it's factory image. This is the first time in a very long time (I'm talking 10+ years) that I've had to reimage due to malware on a Window system. I've other systems in the house running Windows, and some have NO 3rd-party AV (my Alienware system is running Win8 and it's using Windows Defender without issue).
I'll keep this post updated with any other information I discover over the next few days.
UPDATE - I've found some free tools -- http://www.mcafee.com/us/downloads/free-tools/
UPDATE 2 - I've conducted some scans using the free tools and I'm still not able to find anything. I'm wondering if the activity I've observed is actually part of their host discovery toolset...that sorta makes sense. If only I could get some type of verification on this from a McAfee rep, or maybe find some document that describes how the host discovery system works and how it would look from a network security perspective. But all that still wouldn't explain why the AV keeps disabling in the middle of the night...
FINAL UPDATE - Issue resolved. After investigating further, I found that there was no infection. Two things were occurring: 1) I've found that the AV services appear to be polling for services (network discovery - Symantec/Norton has this feature as well), 2) the self-update process had hung, which was causing the AV shutdowns. Once I removed the existing version and got the latest, I found that there was a drastic difference between the two versions. As well, the account portal had changed. The fact that there was a major client upgrade may've broken communication with the account portal (that began working once I upgraded manually). When this subscription is up, I'll either use Windows Defender or use one of my existing Symantec licenses to install that AV onto the system...not liking the McAfee AV experience. :/
Labels:
antivirus,
AV,
compromise,
linux,
malwarebytes,
McAfee,
MWB,
system logs,
Window 7,
Windows Defender
Thursday, August 04, 2011
Snort and Thresholding Noisy Alerts
I'm trying to stay sharp as a security techie, so I've been trying to contribute to Linux and security forums. There's a guy who was asking how to use bpf.conf with Snort. I suggested he use threshold.conf instead. I actually referenced this (I love TaoSecurity) to help him. He was being flooded with "SHELLCODE x86 inc ecx NOOP" alerts. The assistance thread is here, at LinuxQuestions.org.
Labels:
linux,
linuxquestions.org,
Snort,
TaoSecurity,
thresholding
Saturday, June 06, 2009
Researching and found an old flamefest spark
Reference:
http://mythtv.beirdo.ca/ircLog/channel/1/2008-07-14
Summary: At LQ.org, there was a discussion on the security forums on how vulnerable Linux was to attacks/malware. Someone didn't like what was being discussed because of typical Linux zealotry. What happened on LQ's forums spilled over into ##slackware on IRC. Dagmar, the instigator of a LOT of bad things that used to happen in ##slackware got perm banned by me. Later, documented in the link above, he is his typical self, not even attempting to objectively explain what the whole thing was about, pretty much slandering me about how flawed my thoughts are on the whole thing and is worrying that I'll propagate bad information.
Let me explain some things about myself. I'm an IT security engineer. I don't just mess with routers and I'm not some glorified network engineer. I'm a senior consultant. I not only consult, I'm able to find "needle-in-the-haystack"-type info using packet-level analysis. Most of what I do requires that I be a jack-of-all-trades in network engineering, but my specialty is security. I'm proficient in utilizing many industry-leading security tools, both freeware and commercial software. I work at a very large ISP/telecom within a large managed security services team. I am THE lead of a government security operations center. We manage well over 100 customers' security posture via firewalls, NIDS, HIDS, and IPS appliances, using ArcSight, an aggregation and correlation tool that is fast becoming the standard in security event monitoring.
Every day, we see machines being compromised...this is nothing new. The compromises span every mainstream OS. This includes Linux. Whether it is kernel level or application level is not the argument. The argument is that Linux is not as rock-solid as everyone makes it out to be. Sure, it has more safeguards than Windows-based systems, but it is still susceptible to application-level exploits. Whether this is a coder issue or PEBKAC/user/admin issue is besides the point.
People need to stop thinking that just because they are running Linux, they are safe. That is NOT the case. This is not paranoia speaking. It is from seeing such things happen on a daily basis during security event monitoring. Due to applications such as PHP-Nuke, it is becoming more difficult to secure back end applications. It is much harder to stop SQL injection than it is to stop SSH brute-forcing, for instance. This isn't the only issue, though. The issue is the perception that because Linux code is open and free, the code base is free of vulnerabilities. That is NOT the case. Also, many people think that a majority of the cracker focus is on Win32 because MS has a majority of the market share. That also is NOT the case. That is a big assumption. milw0rm and other such sites document many *nix-based vulnerabilities, along with Bugtraq at Securityfocus track all vulnerabilities. Sometimes, people justify Linux because its security model is better focused than Win32 systems. It is, but that does not mean that Linux is rock-solid. It has its own faults, whether it is the user, the admin, or the software developer (or even kernel developer).
Dagmar has a habit of blocking out people's opinions and sometimes beating people down with his own. Dagmar thinks he knows security more than anyone else when he's just a developer. I see attacks every day on all types of machines. Some of the attacks are successful. I doubt that Dagmar sees those. Dagmar need not worry about me "propagating" untruth, because what I say IS the truth. All you have to do to see the truth is to research and not be blind to other opinions.
Dagmar also stalked. After the IRC discussion, he began to frequent the LQ security forums and respond to every thread I posted to. He was hardly ever in those forums before then. I noticed this immediately (and also checked). I didn't mind this, but when it spilled back over into IRC, I tired of it and wanted it ended...it really had no place in ##slackware and I was fed up with his attitude about the whole thing. I don't suffer drama very well.
Now, Dagmar has been banned several times before for the lack of tact in the way he 'helped' people in ##slackware. He was walking a thin line to begin with. Those with operator status in ##slackware acknowledge that he is knowledgeable, but that is not grounds for him to be dismissed as an abusive ##slackware visitor. Sure enough, he did the same thing with a channel operator (me) and I banned him. I also discussed it with the other operators. The consensus was that he stay banned since his history of being banned was substantial.
That was why he got banned...not because his views went against my own, but because he started regressing back to his former self and became abusive. He did the same in the LQ.org forums, but I was able to filter his posts from my normal views. As an operator at Freenode.net, I can't and shouldn't filter any visitor from my views in ##slackware, so my only option was to ban him, and like I said before, he'd his own infamous nature that was going against him.
As a security consultant, I'm certainly not going to keep my thoughts quiet about what I think is a disservice to my favorite operating system. I certainly know more than someone who is not a security consultant about IT security...its what I get paid to do and its what I've been doing for years. It's the same as a person who has built his own car, vs. someone who works as a senior Mercedes mechanic.
As much as I can, I tell people that there is NO secure OS. It is only as secure as the admin makes it, and even if the admin puts 100% resources into hardening the box, it will never be 100% secure. The LQ security forums is itself proof that Linux systems get compromised more than most people think. 2-3 times a week, someone reports they've been compromised. There's even 4 threads on Linux-based vulnerabilities:
Kernel Vulns
Mozilla Firefox Vulns
The Problem with PHP Application Security
Failed SSH Login Attempts
I can post a ton of other links but why do this when there is Google?
http://mythtv.beirdo.ca/ircLog/channel/1/2008-07-14
Summary: At LQ.org, there was a discussion on the security forums on how vulnerable Linux was to attacks/malware. Someone didn't like what was being discussed because of typical Linux zealotry. What happened on LQ's forums spilled over into ##slackware on IRC. Dagmar, the instigator of a LOT of bad things that used to happen in ##slackware got perm banned by me. Later, documented in the link above, he is his typical self, not even attempting to objectively explain what the whole thing was about, pretty much slandering me about how flawed my thoughts are on the whole thing and is worrying that I'll propagate bad information.
Let me explain some things about myself. I'm an IT security engineer. I don't just mess with routers and I'm not some glorified network engineer. I'm a senior consultant. I not only consult, I'm able to find "needle-in-the-haystack"-type info using packet-level analysis. Most of what I do requires that I be a jack-of-all-trades in network engineering, but my specialty is security. I'm proficient in utilizing many industry-leading security tools, both freeware and commercial software. I work at a very large ISP/telecom within a large managed security services team. I am THE lead of a government security operations center. We manage well over 100 customers' security posture via firewalls, NIDS, HIDS, and IPS appliances, using ArcSight, an aggregation and correlation tool that is fast becoming the standard in security event monitoring.
Every day, we see machines being compromised...this is nothing new. The compromises span every mainstream OS. This includes Linux. Whether it is kernel level or application level is not the argument. The argument is that Linux is not as rock-solid as everyone makes it out to be. Sure, it has more safeguards than Windows-based systems, but it is still susceptible to application-level exploits. Whether this is a coder issue or PEBKAC/user/admin issue is besides the point.
People need to stop thinking that just because they are running Linux, they are safe. That is NOT the case. This is not paranoia speaking. It is from seeing such things happen on a daily basis during security event monitoring. Due to applications such as PHP-Nuke, it is becoming more difficult to secure back end applications. It is much harder to stop SQL injection than it is to stop SSH brute-forcing, for instance. This isn't the only issue, though. The issue is the perception that because Linux code is open and free, the code base is free of vulnerabilities. That is NOT the case. Also, many people think that a majority of the cracker focus is on Win32 because MS has a majority of the market share. That also is NOT the case. That is a big assumption. milw0rm and other such sites document many *nix-based vulnerabilities, along with Bugtraq at Securityfocus track all vulnerabilities. Sometimes, people justify Linux because its security model is better focused than Win32 systems. It is, but that does not mean that Linux is rock-solid. It has its own faults, whether it is the user, the admin, or the software developer (or even kernel developer).
Dagmar has a habit of blocking out people's opinions and sometimes beating people down with his own. Dagmar thinks he knows security more than anyone else when he's just a developer. I see attacks every day on all types of machines. Some of the attacks are successful. I doubt that Dagmar sees those. Dagmar need not worry about me "propagating" untruth, because what I say IS the truth. All you have to do to see the truth is to research and not be blind to other opinions.
Dagmar also stalked. After the IRC discussion, he began to frequent the LQ security forums and respond to every thread I posted to. He was hardly ever in those forums before then. I noticed this immediately (and also checked). I didn't mind this, but when it spilled back over into IRC, I tired of it and wanted it ended...it really had no place in ##slackware and I was fed up with his attitude about the whole thing. I don't suffer drama very well.
Now, Dagmar has been banned several times before for the lack of tact in the way he 'helped' people in ##slackware. He was walking a thin line to begin with. Those with operator status in ##slackware acknowledge that he is knowledgeable, but that is not grounds for him to be dismissed as an abusive ##slackware visitor. Sure enough, he did the same thing with a channel operator (me) and I banned him. I also discussed it with the other operators. The consensus was that he stay banned since his history of being banned was substantial.
That was why he got banned...not because his views went against my own, but because he started regressing back to his former self and became abusive. He did the same in the LQ.org forums, but I was able to filter his posts from my normal views. As an operator at Freenode.net, I can't and shouldn't filter any visitor from my views in ##slackware, so my only option was to ban him, and like I said before, he'd his own infamous nature that was going against him.
As a security consultant, I'm certainly not going to keep my thoughts quiet about what I think is a disservice to my favorite operating system. I certainly know more than someone who is not a security consultant about IT security...its what I get paid to do and its what I've been doing for years. It's the same as a person who has built his own car, vs. someone who works as a senior Mercedes mechanic.
As much as I can, I tell people that there is NO secure OS. It is only as secure as the admin makes it, and even if the admin puts 100% resources into hardening the box, it will never be 100% secure. The LQ security forums is itself proof that Linux systems get compromised more than most people think. 2-3 times a week, someone reports they've been compromised. There's even 4 threads on Linux-based vulnerabilities:
Kernel Vulns
Mozilla Firefox Vulns
The Problem with PHP Application Security
Failed SSH Login Attempts
I can post a ton of other links but why do this when there is Google?
Labels:
##slackware,
Application Security,
IRC,
linux,
LQ.org,
milw0rm,
security
Sunday, February 17, 2008
Kernel vulnerabilities affecting Linux machines
Whenever there's some kernel-level vulnerability, it seems that the whole community goes ape-crap over something that should be a no-brainer.
The recent vulnerability is documented here:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0010
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0163
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0600
So, what's the big deal? It is a locally exploitable vulnerability. Everyone is acting like its the end of the world. Why? Are people actually giving people access to their systems that they don't trust? Why am I not worried? Because I want to learn things about security. Think about this for a second: in an enterprise environment, you're not going to be able to always apply kernel patches to production machines. You're not always going to be able to test by standing up a development environment. There is not always going to be one distribution used and not every platform will share the same hardware. What's readily apparent is that security should always be applied in layers. This means that no one should be accessing machines on your local network that you can't trust. If someone is not trustworthy, you should always be worrying about what they're doing on the network, instead of only when kernel-level vulnerabilities are discovered.
Does that lessen the responsibility of the system admins? No, but if everyone thought less of patching applications and more as a security administrator, the workload of the system administrator would probably be less. What I'm seeing in chatrooms and forums is this: "Oh shit...this exploit gives local root access...I have to apply this patch NOW!!" Someone said something similar in an IRC channel that I frequent:
The conversation dies shortly thereafter. I do think SiegeX was thinking in a sane manner. What he's worried about is someone either breaking into the machine or someone from inside tunneling and somehow letting an unauthorized user into the network. Layered security addresses both of those concerns. You lock down your firewall to only allow certain traffic in/out of the network. You set up either an IDS or an IPS to either log suspicious traffic or actively log and block unusual traffic. Yes, IDS/IPS can detect layer-7 traffic anomalies (but only if there are rules patterned after the unwanted traffic). Those people that tunnel out of the corporate network can be either reprimanded or handed their walking papers...that problem can be solved rather quickly.
I take it that SiegeX didn't want to deal with traffic analysis. That's the only way ANYONE is going to see stuff. Think about it. When you look at firewall logs, you're looking at logged traffic. If you're looking at your system logs (for instance, /var/log/secure, /var/log/faillog, or /var/log/messages (which may contain snort log and/or firewall log entries)), you're pretty much conducting traffic analysis. This should be within the realm of every system admin.
The easier way would be to address the kernel vulnerability, but I've also seen places that will NOT update a kernel unless absolutely necessary. The train-of-thought is that they wanted absolute stability and that stability overruled patch updating. What type of organization would think in this manner? Think of organizations that deal in national flight systems.
So, when am I going to apply a patched kernel? I don't know...my LAN is so layered with security that its not a hot priority for me to apply this patch.
Lastly, here's a Secunia link of the vulnerabilities in question: http://secunia.com/advisories/28835/
The recent vulnerability is documented here:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0010
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0163
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0600
So, what's the big deal? It is a locally exploitable vulnerability. Everyone is acting like its the end of the world. Why? Are people actually giving people access to their systems that they don't trust? Why am I not worried? Because I want to learn things about security. Think about this for a second: in an enterprise environment, you're not going to be able to always apply kernel patches to production machines. You're not always going to be able to test by standing up a development environment. There is not always going to be one distribution used and not every platform will share the same hardware. What's readily apparent is that security should always be applied in layers. This means that no one should be accessing machines on your local network that you can't trust. If someone is not trustworthy, you should always be worrying about what they're doing on the network, instead of only when kernel-level vulnerabilities are discovered.
Does that lessen the responsibility of the system admins? No, but if everyone thought less of patching applications and more as a security administrator, the workload of the system administrator would probably be less. What I'm seeing in chatrooms and forums is this: "Oh shit...this exploit gives local root access...I have to apply this patch NOW!!" Someone said something similar in an IRC channel that I frequent:
SiegeX - I dunno, having a local root exploit (which ive tested with existing code) on a box that runs any sort of service would worry the hell out of me
W|GGL|T - SiegeX: in all actuality, you could have root exploits locally all over the place and you'd not know about it
SiegeX - and I probably do, but its no excuse for not patching the ones I do
W|GGL|T - security is more than just patching....in a corporate scenario, you have to balance out if you can even apply the patch....you bet your ass we're not going to take down a production system that has a localized vulnerability if it is indeed only local
SiegeX - heh, step 1) su root 2) cat /etc/shadow 3) ??? 4) profit
W|GGL|T - its called mitigation
W|GGL|T - if security is applied in layers, certain risks are lessened
SiegeX - W|GGL|T: why wouldnt you apply the patch on a production clone for testing purposes and do regression testing on that to make sure everything is a-ok before moving it over ?
W|GGL|T - SiegeX: if the corporate network has 10 different security layers, the need for immediate patching is small. sure, we'd patch but we'd do it in a sane manner
SiegeX - W|GGL|T: since you're into the corp security let me ask you if there was a solid way for a corp to not allow outbound tunnels while still allowing https?
SiegeX - s/was/is
W|GGL|T - SiegeX: nope, but then again, those who don't follow corporate policy need to be fired
SiegeX - afaik, if you tunnel over https, not even a L7 filter will look at it funny since the connection setup looks legit. Only thing i can think of is traffic analysis
W|GGL|T - there are always checks and balances
W|GGL|T - SiegeX: hrmm....there is IDS
W|GGL|T - and there is also a concept called behavioral analysis
The conversation dies shortly thereafter. I do think SiegeX was thinking in a sane manner. What he's worried about is someone either breaking into the machine or someone from inside tunneling and somehow letting an unauthorized user into the network. Layered security addresses both of those concerns. You lock down your firewall to only allow certain traffic in/out of the network. You set up either an IDS or an IPS to either log suspicious traffic or actively log and block unusual traffic. Yes, IDS/IPS can detect layer-7 traffic anomalies (but only if there are rules patterned after the unwanted traffic). Those people that tunnel out of the corporate network can be either reprimanded or handed their walking papers...that problem can be solved rather quickly.
I take it that SiegeX didn't want to deal with traffic analysis. That's the only way ANYONE is going to see stuff. Think about it. When you look at firewall logs, you're looking at logged traffic. If you're looking at your system logs (for instance, /var/log/secure, /var/log/faillog, or /var/log/messages (which may contain snort log and/or firewall log entries)), you're pretty much conducting traffic analysis. This should be within the realm of every system admin.
The easier way would be to address the kernel vulnerability, but I've also seen places that will NOT update a kernel unless absolutely necessary. The train-of-thought is that they wanted absolute stability and that stability overruled patch updating. What type of organization would think in this manner? Think of organizations that deal in national flight systems.
So, when am I going to apply a patched kernel? I don't know...my LAN is so layered with security that its not a hot priority for me to apply this patch.
Lastly, here's a Secunia link of the vulnerabilities in question: http://secunia.com/advisories/28835/
Labels:
cve.mitre.org,
kernel,
linux,
local exploit,
Secunia.com,
Slackware
Friday, January 25, 2008
Mystery infestation strikes Linux/Apache Web sites
http://www.linux.com/feature/125548
"According to a press release issued earlier this month by Finjan, a security research firm, compromised Web servers are infecting thousands of visitors daily with malware that turns their Windows machines into unwitting bots to do the bidding of an as yet unidentified criminal organization. Security firms ScanSafe and SecureWorks have since added their own takes on the situation, though with varying estimates on the number of sites affected. All reports thus far say the compromised servers are running Linux and Apache."
Sunday, November 18, 2007
58 Cool Hacks...and more
Here are fifty-eight (58) cool hacks that are posted on the Linux Format Wiki. Some of these are actually cool and insightful. I plan on attemtping to regularly use a few of them. I'll let you know a bit later which ones they are and how well my implementation and usage goes.
Here is another good link. It describes in detail how to build your own distribution (build, not create, as you will build from a pre-existing Linux ISO file). If I'd enough time to do this, I would...maybe during my next holiday, I'll begin this, with the idea of making a seriously light yet secure distro.
This one is a good one, but I've only skimmed it so far. It is LinuxFormat's Slackware documentation. Since I know they are a bit biased in their views of Slackware (they seem to think that apt-get-like package management is a requirement and that the distribution is a bit 'behind the times'), I know I need to read this part of their wiki with some attention to detail.
Here is another good link. It describes in detail how to build your own distribution (build, not create, as you will build from a pre-existing Linux ISO file). If I'd enough time to do this, I would...maybe during my next holiday, I'll begin this, with the idea of making a seriously light yet secure distro.
This one is a good one, but I've only skimmed it so far. It is LinuxFormat's Slackware documentation. Since I know they are a bit biased in their views of Slackware (they seem to think that apt-get-like package management is a requirement and that the distribution is a bit 'behind the times'), I know I need to read this part of their wiki with some attention to detail.
Subscribe to:
Posts (Atom)