Just a quick tip that might help out the folks needing something better than gcj and still using an open version of Java.
On CentOS 5.2 :
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-2.noarch.rpm
yum install -y java-1.6.0-openjdk-plugin java-1.6.0-openjdk-devel java-1.6.0-openjdk
😉
Hope that makes someone’s life easier!
The other day I had an old client forward me an email from their credit card processing company, saying that the server upon which their website was hosted failed their PCI Compliance security check. I had never heard of this and was wary that it might be a service they were being tricked into adding on, but upon further investigation, I learned that many credit card processing companies are now instituting this new security policy, which is designed to tighten up security on web servers in order to decrease the chances of credit card theft.
This sounded all well and good, and I figured that with my background in securing servers to meet Department of Defense standards it ought to be a breeze. Little did I know that the server in question would put up quite a battle for the lone reason that it was running Plesk, the web host management tool. I had written off Plesk long ago, having ditched the server I had it running on after many issues with it, and I thought I would never have to work with it again, but alas…
I started Googling, of course, and found some great resources out there which cover the tightening up of Plesk in order to meet PCI compliance.
One of the best articles I found was at linux-advocay.org, which explains how to fix issues with Courier, Qmail, Apache, SSL, and iptables in case you don’t have Plesk’s Firewall add-on.
Also, a fellow by the name of DrJermy writes of his solutions about dealing with Plesk and PCI Compliance.
For some general information about what PCI compliance is all about, check out pcicomplianceguide.org.
My Take
As I worked through the PCI issues with the client who contacted me, I started realizing that the standards by which the server was being scanned were presumptuous in that they didn’t take into account back porting, as implemented by RedHat, and that they were making me fix issues which seemed rather trivial in regards to credit card processing security.
If they really wanted to do something that mattered, they should have a look at the NSA’s hardening guides.
If you’ve found yourself in a Network/System Admin position without the proper tools, and can’t seem to get them, there’s usually a way to do things for free with Linux or at least using the repos provided under an enterprise support package such as RHEL. 🙂 This is for monitoring who’s chewing up the pipe by IP address.
* Obviously there’s 100 ways to skin a cat in Open Source, but this is one way that can take you from “Who’s hogging the pipe” to “HEY! Stop doing that” in 15 minutes. Granted this isn’t meant for controlling the traffic, that’s another story. *
How To: ( Warning! – You may need to verify this action with your IT Dept – Warning!)
1. On the Core switch just before the “Gateway” hop takes place, and Pre-NAT rules, you’ll need to enable a port for monitoring the traffic (both TX and RX) to and from the “Gateway”. This box could also be used as a SNORT box. (once again another story)
2. You’ll need a Linux box with dual NIC’s (for remote usage) or a single NIC with Physical terminal access for direct access only.
3. Install and run/configure “iptraf” (using sudo or root access)
#sudo yum install -y iptraf
#sudo iptraf (once the Screen launches, hit any key)
Scroll down to “Configure” (enter)
Set “Force Promiscuous mode” to ON
(You may wish to keep “Reverse DNS Lookups” off as well)
(Adjust “Additional ports” or any other settings if needed)
“Exit Configuration”
Select “IP Traffic Monitor”
Select the interface that’s plugged into the “Monitored” port. (from Step 1.)
Once the monitoring begins you can sort by bytes or packet count etc.
Find the “Hogger”.
Note: I really like the “iftop” tool as well, but it’s not in the RHEL Repos. ;0)
You can’t control the traffic from this app, but at least you can verify if the traffic is legit or not. Once you have the ip you can do the standard ip/arp/mac table lookups etc. to locate the machine.
HTH.
dbcooper
My goal was to set up a network share on a RHEL5 server using Samba, so that our Windows users could access the shared folder from their desktops. It was difficult to find any information on doing this and nothing else, such as setting up Samba as a domain controller, which I was not interested in. Sometimes Google gives you more than you want.
If you are running RedHat Enterprise 5, and are interested in setting up Samba shares for Windows users to access, read on. This may work for other flavors of Linux, and older versions of RHEL, but I can’t vouch for that.
First, make sure the correct Samba packages are installed:
#> rpm -qa |grep samba
samba-client-3.0.28-1.el5_2.1
samba-3.0.28-1.el5_2.1
samba-common-3.0.28-1.el5_2.1
system-config-samba-1.2.39-1.el5
If these are not installed, use yum to grab them and install them.
You may need to open ports in the system firewall so that all of this will work. The ports that need to be open for Samba to work are:
139 and 445
It’s easiest to do this from your RedHat gui (System > Administration > Security Level and Firewall).
Next, set up the smb service to run at boot time:
#> chkconfig smb on
In RedHat, this will also cause the nmb service to run, which is fine.
Now, start Samba:
#> service smb start
Now, create the directory you want to share. For this example, I will make it simple:
#> mkdir /dv1
Set permissions accordingly. In my scenario, I wanted our developers to all be able to access this directory from Windows, and they were all part of the ‘developers’ group on my RedHat server, so I set the permissions like so:
#> chown developers.developers /dv1
#> chmod 755 /dv1
In order to get Samba to share this directory, I had to add the appropriate policies for SELinux, which are mentioned in the smb.conf file. Assuming you are running SELinux (it’s default with RedHat Enterprise 5), these can be added at the command line.
Since you created a new directory that will be shared with Samba (the ‘dv1’ directory you created earlier), a label must be set for that as well. Using ‘dv1’ as the directory name, run this:
To set a label use the following:
#> chcon -t samba_share_t /dv1
Now to configure the Samba configuration file. Always make a backup of the original before editing any config file!
#> cp /etc/samba/smb.conf /etc/samba/smb.conf.orig
To edit the config file, do this:
#> nano /etc/samba/smb.conf
Under [global] settings, uncomment the necessary lines and make changes so that it looks something like this:
workgroup = YourWindowsWorkgroupName server string = YourRedhatServerName netbios name = YourRedhatServerName hosts allow = 127.0.0.1 192.168.1.
Leave everything else in that section the way it is.
Note: the 192.168.1. address needs to be that of your local network.
Then under Standalone Server Options:
security = user
passdb backend = tdbsam
I commented out all Printer sharing crap since I didn’t use any of that.
Lastly, under Share Definitions:
[homes]
comment = Home Directories
browseable = no
writeable = yes
; valid users = %S
; valid users = MYDOMAIN%S
;[printers]
; comment = All Printers
; path = /var/spool/samba
; browseable = no
; guest ok = no
; writeable = no
; printable = yes
[dv1]
comment = My dog has fleas
path = /dv1/
valid users = user1,user2,user3
public = no
writeable = yes
create mask = 0765
Obviously, swap out user1,user2,user3 with the users who will be accessing this share. You put the username for the RedHat box you are on, not the Windows username (unless it’s the same).
Save the file and go back to the command line. Test it out by running this:
#> testparm
You shouln’t see any error reported. If all is good, run this:
#> service smb restart
You will see smb and nmb stop and restart. There should be no errors or “FAILED” notices.
Assuming your users already have accounts on your RedHat box, you need to add them to Samba like so:
#> smbpasswd -a username
New SMB password:
Retype new SMB password:
I set a temporary password here, then ask them to change it next time they log into the server at the command line by running this:
#> smbpasswd
It will prompt them for their old password (the temporary one you just gave them), and for the new one.
Once all that is done and you have set your own Samba password, you should be able to do this from Windows:
Go to Start and select Run. Type in the hostname of your RedHat server (which you specified in the smb.conf file) like so:
\YourRedhatServerName
You will be prompted for a username and password, and you should enter the RedHat server login name and the Smaba password that you just created.
If all goes well, a window will appear which shows the dv1 directory. You can now drag, drop, copy, and paste to and from this folder as if it were on your Windows machine!