Friday, July 17, 2009
OSX can't follow symlinks in Samba
Found this out last night trying to get my roommate/coworker's site up on my server. I ended up just creating a separate Samba share to the symlinked directory.
But hey, OS X is so pretty, who needs it to actually work like any other OS should :-p
Monday, July 13, 2009
X is still dead...
media-libs/mesa-9999
x11-libs/libdrm-9999
x11-drivers/xf86-video-intel-9999
x11-base/xorg-server-1.6.2
I enabled tiling (it was manually disabled before, as specified in this
gentoo-wiki article)
X is definitely more stable than before, I am able to log in to gnome and use
as normal, although sooner or later the GPU locks up again and I am just left
with a pointer and no keyboard.
Fortunately, this box's main purpose is as a server (primarily development :-),
so running X is not critical. For now, I am going to sit tight and just make
sure to continually run updates. I am going to wait a bit longer before I
upgrade to 2.6.31, simply because I need the kernel to be stable (beyond r2)
and do not want to sacrifice that just to get X running a bit smoother.
To see a more documented recap of what all I did with X, check out this gentoo bugzilla page
I started a couple of small projects this weekend. The first was getting SAMBA/cifs working again in the new network environment. I couldn't figure out why I couldn't see/access my SAMBA share on my gentoo box: nothing had really changed within the local network, other than a slightly different routing prefix... Why would that matter?
Then I remembered setting up my stateful firewall and documenting it on this very blog. Of course SAMBA isn't working, as I explicitly allow traffic over one particular Class C subnet, and since that change, all traffic is blocked. So after a quick few edits to my firewall configuration script and to smb.conf, I was again all set up.
The other small project was deploying some of the past sites I have completed on my web server, to act as a mini portfolio. I haven't decided whether I want to get the sites up and running as they do/did in production, or if I should just take screenshots. Right now I'm leaning towards screenshots, as I don't want to have to reconstruct each site's respective database and data.
This week I hope to get the chance to play around with Windows 7 a bit more and try and figure out why Gnome is running so slowly on my FreeBSD VM. I also plan on finally updating my Dell C610 laptop from Ubuntu 7.04 Feisty Fawn to 9.04 Jaunty Jackalope. This will mark the 5th release of Ubuntu I have used, as I started with the first release, 4.10 Warty Warthog, back in '04. I should take this opportunity to note that without Ubuntu, I would be nowhere near where I am today in terms of experience with Linux. I've always been a fan of Ubuntu's cheesy credo of "Linux for human beings," as it aims to simplify many of the complexities that are typically associated with Linux. Although I had used a few other distros prior to Ubuntu, namely RedHat, SuSE, and Mandrake, it was not until Ubuntu that I felt comfortable with the Linux kernel and using bash. So thank you Canonical for Ubuntu, and thank you to the Debian team for apt-get!
Lastly, this week, I think I'm going to give OSX on a VM another shot.
Sunday, June 21, 2009
Repositories
The Ubuntu VM is able to access both the shares on the Gentoo machine and the Vista machine using nautilus, although accessing the Vista share is definitely cumbersome and seems to work inconsistently and I'm not entirely sure why. When using smbclient from the console on the Ubuntu box, I am able to scan the shares on the Gentoo box, however I first had to enable lanman auth and client lanman auth in the Ubuntu VM's smb.conf to connect to the server. I'm not really sure why the server is requesting lanman authentication, although maybe some sort of authentication/encryption is required by samba to connect to shares that don't use user-level security. Theoretically, no authentication should be necessary using smbclient since guests are allowed. I'm still digging to find the answer...
In the process, I definitely had one big *duh* moment. After changing my USE flags in /etc/make.conf to add samba, I wanted to ensure all packages now would support samba (particularly gnome). I ran emerge --update --deep --newuse world, only to get stopped immediately with a "masked package error," as well as an error stating that I needed to update portage. So I updated portage and ran emerge --update --deep --newuse world again, only to hit a brick wall trying to update /sys-lib/timezone-data. Portage could not find timezone-data-2008c. This seemed a bit odd to me, as obviously, its now 2009, so why is portage trying to find a package marked 2008? So after a minute of twiddling my thumbs, I recalled having to always run 'apt-get update' on my Ubuntu laptop to update the repository tree... and I hadn't been doing the same on my gentoo machine with portage. AHA! Well a simple emerge --sync should do the trick, and I should be home free!
Well about this time, Charter decided to throw the Internet switch from "working" to "broken," for my router and I couldn't pull down the new portage tree, at least not within a reasonable amount of time. After a failed rsync, I tried again (I was still getting about 40% of my packets through, and I really wasn't in the mood to call Charter), and got responses from the rsync server... all of which were 404. So instead of giving in, and just calling Charter, I tried switching my SYNC parameter within etc/make.conf to a different server, first to Georgia Tech's (biting my tongue... I'm a UGA grad) with no success. After having a near aneurysm due to frustration, I figured out that I needed to emerge mirrorselect and run mirrorselect -r -i to find a new server. I managed to find a new rsync server, but finally gave in and decided it was about time to call Charter, as I was now experience around 80% packet loss *grrr.
So I dialed up the dreaded 1-888 number, I repeatedly hit '0' and was patched right through to a representative who was very helpful, and in fact got a technician out to me in a matter of two hours (unprecedented for Charter!), who came out and checked my levels, reran a cable, and swapped out my dying Motorola Surfboard modem, and got me back on my feet- he didn't even bitch about me using a router!
So now I was able to successfully sync portage, and again, ran emerge --update --deep --newuse world only to get another error that I needed to add a USE flag to do that...
So I just did it the quick, temporary way USE="###" emerge --update --deep --newuse world and it worked... until I got smacked with another error <sys-apps/man-pages-3 ("<sys-apps/man-pages-3" is blocking sys-apps/man-pages-posix-2003a). this forum post which seemed to the trick...
So that's where I am now, running a deep update with new use flags, hopefully not fruitlessly, currently on package 49 of 391. I guess at the very least, my server will be all up to date! More to come later....
Wednesday, June 17, 2009
SAMBA
One thing I did not do was learn how to effectively use CIFS and smbclient, so I'll have to familiarize myself with both and figure out how to mount and search samba shares.
On another note, I spoke with our web designer at work, and he shared with me that I should check out Inkscape, a free/open source vector graphics editor, similar to Adobe Illustrator. I really do need to familiarize myself with software such as this, as when it comes to web design, I am lacking most in creating and manipulating images.
He also pointed me to click2try.com, a pretty cool site with a bunch of hosted VMs, allowing users to try open source software for free, without having to install anything on the user's machine.
Monday, June 8, 2009
iptables complete
I created three chains, LOG_DROP, LOG_ACCEPT, and LOG_REJECT, to log packets when needed. I did not use LOG_DROP, nor LOG_REJECT (maybe in the future?), and instead am just using REJECT with --reject-with tcp-reset for TCP packets and icmp-port-unreachable for UDP packets to help mask the fact that I'm using a firewall. If the packets are simply dropped, it'd be pretty easy for an intruder to realize that I'm running a firewall because his packets would not result in the standard --tcp-reset or icmp-port-unreachable to indicate a nonexistent service. In the future, I may consider logging some of the rejected packets.
Right now the only services I am logging when accepted are SSH & SFTP (both use port 22), as logging every http request is impractical.
Unlogged accepts include http (port 80) and SAMBA (netbios-ssn, microsoft-ds, UDP 137 & 138). One key problem I had was allowing SAMBA to continue to work with the firewall enabled. With iptables running, I could only access my SAMBA shares by using the machine's IP, and not its hostname. While this problem was frustrating, it forced me to better manage my system by ensuring that samba was configured correctly (/etc/samba/smb.conf), my hostnames were set properly (it was not- only localhost was set in /etc/hosts), as well as resolv.conf (/etc/resolv.conf). This forum post eventually led me to realize that I needed to accept traffic on ports 137 & 138 on top of netbios-ssn (UDP 139), and microsoft-ds (TCP 445).
Further securing SAMBA, I specified the allowed source IPs on my network, both within smb.conf and iptables. If there's anything I've learned, its that redundancy in terms of security is never a bad idea.
Below is a (modified) iptables firewall script:
#!/bin/bash
# Stateful firewall for hostname
########################
# Ethernet Information #
########################
# Device: lo
# IP: 127.0.0.1
# Hostname: localhost
# Device: eth0
# IP: 192.168.2.3
# Hostname: hostname
# Flush all tables
iptables -F
# Remove all non-default cahins
iptables -X
#+-------------------------------+
#| Setup Firewall Process chains |
#+-------------------------------+
# Create a LOG_DROP chain for dropped incoming requests to be logged
iptables -N LOG_DROP
iptables -A LOG_DROP -j LOG --log-level info --log-prefix "Firewall-LOG_DROP: "
iptables -A LOG_DROP -j DROP
# Create a LOG_REJECT chain for rejected incoming requests to be logged
iptables -N LOG_REJECT
iptables -A LOG_REJECT -j LOG --log-level info --log-prefix "Firewall-LOG_REJECT: "
iptables -A LOG_REJECT -j REJECT
# Create a LOG_ACCEPT chain for accepted incoming requests to be logged
iptables -N LOG_ACCEPT
iptables -A LOG_ACCEPT -j LOG --log-level info --log-prefix "Firewall-LOG_ACCEPT: "
iptables -A LOG_ACCEPT -j ACCEPT
# Accept all connections from localhost
iptables -A INPUT -i lo -j ACCEPT
# Accept reply packets
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Accept PING requests
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
#+-----------------------------------+
#| Accepted services that ARE Logged |
#+-----------------------------------+
#SSH & SFTP (TCP)
iptables -A INPUT -p tcp --dport ssh -j LOG_ACCEPT
#+---------------------------------------+
#| Accepted services that are NOT Logged |
#+---------------------------------------+
# HTTP (TCP)
iptables -A INPUT -p tcp --dport http -j ACCEPT
# HTTPS (TCP)
#iptables -A INPUT -p tcp --dport https -j ACCEPT
# TOMCAT (TCP)
#iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
# If we're only using TOMCAT (no apache), we can forward traffic to 8080
#iptables -t nat -A OUTPUT -d localhost -p tcp --dport 80 -j REDIRECT --to-ports 8080
#iptables -t nat -A OUTPUT -d hostname -p tcp --dport 80 -j REDIRECT --to-ports 8080
#iptables -t nat -A PREROUTING -d hostname -p tcp --dport 80 -j REDIRECT --to-ports 8080
# RAILS (TCP)
#iptables -A INPUT -p tcp --dport 3000
# netbios-ssn (UDP)
#iptables -A INPUT -p udp --dport netbios-ssn -j ACCEPT
iptables -A INPUT -p udp --source 192.168.2.0/24 --dport netbios-ssn -j ACCEPT
# netbios-ssn (TCP)
#iptables -A INPUT -p tcp --dport netbios-ssn -j ACCEPT
iptables -A INPUT -p tcp --source 192.168.2.0/24 --dport netbios-ssn -j ACCEPT
# microsoft-ds (TCP)
#iptables -A INPUT -p tcp --dport microsoft-ds -j ACCEPT
iptables -A INPUT -p tcp --source 192.168.2.0/24 --dport microsoft-ds -j ACCEPT
# microsoft-ds (UDP)
#iptables -A INPUT -p udp --dport microsoft-ds -j ACCEPT
iptables -A INPUT -p udp --source 192.168.2.0/24 --dport microsoft-ds -j ACCEPT
# nmbd (UDP) required for SAMBA to send requests via broadcasting
iptables -A INPUT -p udp --source 192.168.2.0/24 --dport 137:138 -j ACCEPT
#iptables -A OUTPUT -p udp --dport 137:138 -j ACCEPT
# LOG & Drop malicious IPs
#iptables -A INPUT --source xxx.xxx.xxx.xxx -j LOG_DROP
# Reject remaining packets, do so with tcp-reset and icmp-port-unreachable
# so hackers don't know we're running a firewall
iptables -A INPUT -p tcp -i eth0 -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -i eth0 -j REJECT --reject-with icmp-port-unreachable
NAT translation and masquerading may be a project for a different day, but at least now I'm familiar with what they are and how they work.
Furthermore, I think this project will serve as a good segway into my next one, which is better learning SAMBA and how to configure it.