My Online Log

As we already know if you use sysmlink on your ftp directory the proftpd will not recognized it, soft link won’t work if your link target is not share out in proftpd. Besides, chroot in proftpd will mess up your soft link path if you use full path.

here is some example

# ftp localhost
Connected to localhost (127.0.0.1).
220 FTP Server ready.
Name (localhost:root): test
331 Password required for test
Password:
230 User test logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
227 Entering Passive Mode (127,0,0,1,195,10).
150 Opening ASCII mode data connection for file list
drwx——   3 test     test         4096 Jul 13 18:15 .
drwx——   3 test     test         4096 Jul 13 18:15 ..
-rw——-   1 test     test          246 Jul  5 03:11 .bash_history
-rw-r–r–   1 test     test           33 Jun 24 19:38 .bash_logout
-rw-r–r–   1 test     test          176 Jun 24 19:38 .bash_profile
-rw-r–r–   1 test     test          124 Jun 24 19:38 .bashrc
lrwxrwxrwx   1 0        0              13 Jul 13 18:15 adit -> /home/adityo/
drwx——   3 test     test         4096 Jun 24 19:50 mail
226 Transfer complete
ftp> cd adit
550 adit: No such file or directory
ftp> quit
221 Goodbye.

How Links Work

There are two types of links in Unix: hard and symbolic.

A hard link is a file that is, for all intents and purposes, the file to which it is linked. The difference between a hardlink and the linked file is one of placement in the filesystem. Editing the hardlink edits the linked file. One limitation of hard links is that linked files cannot reside on different filesystems. This means that if /var and /home are two different mount points in /etc/fstab (or /etc/vfstab), then a file in /var/tmp cannot be hardlinked with a file in /home:

> pwd
/var/tmp
  > ln /home/tj/tmp/tmpfile tmplink
ln: cannot create hard link `tmplink' to `/home/tj/tmp/tmpfile': Invalid cross-device link

A symbolic link (also referred to as a “symlink”) is a file whose contents contain the name of the file to which the symbolic link points. For example:

lrwxrwxrwx   1 root     root           11 Mar  2  2000 rmt -> /sbin/rmt

The file rmt contains the nine characters /sbin/rmt. The reason symbolic links fail when chroot(2) is used to change the position of the root (/)of the filesystem is that, once / is moved, the pointed-to file path changes. If, for example, if chroot(2) is used to change the filesystem root to /ftp, then the symlink above would be actually be pointing to /ftp/sbin/rmt. Chances that that link, if chroot(2) is used, now points to a path that does not exist. Symbolic links that point to nonexistent files are known as dangling symbolic links. Note that symbolic links to files underneath the new root, such as symlinks to a file in the same directory:

> pwd
/var/ftp
  > ls -l
-rw-r--r--   1 root     root            0 Jan 16 11:50 tmpfile
  lrwxrwxrwx   1 root     root            7 Jan 16 11:50 tmplink -> tmpfile

will be unaffected; only paths that point outside/above the new root will be affected.

Filesystem Tricks

A typical scenario is one where “DefaultRoot ~” is used to restrict users to their home directories, and where the administrator would like to have a shared upload directory, say /var/ftp/incoming, in each user’s home directory. Symbolic links would normally be used to provide an arrangement like this. As mentioned above, though, when chroot(2) is used (which is what the DefaultRoot directive does), symlinks that point outside the new root (the user’s home directory in this case) will not work. To get around this apparent limitation, it is possible on modern operating systems to mount directories at several locations in the filesystem.

To have an exact duplicate of the /var/ftp/incoming directory available in /home/bob/incoming and /home/adityo/incoming, use one of these commands:

    * Linux (as of the 2.4.0 kernel):

mount --bind /var/ftp/incoming /home/adityo/incoming
  mount -o bind /home2/test.com/ /home/domains/test.com/

    * BSD (as of 4.4BSD):

mount_null /var/ftp/incoming /home/adityo/incoming

    * Solaris:

mount -F lofs /var/ftp/incoming /home/adityo/incoming

set it on fstab
/var/ftp/incoming /home/bob/incoming ext3 --bind 0 0

referer :
- http://www.proftpd.org/localsite/Userguide/linked/chroot-symlinks.html
          

quote from http://www.linuxquestions.org/questions/linux-security-4/telneting-to-a-udp-port-353876/

UDP is a connectionless protocol which means it basically just sends packets out to the specified destination. TCP is connection-oriented which means it establishes a connection to the other end using the ‘3-way handshake’.

So it makes sense to apply the ‘telnet’ paradigm to TCP – you make connection to a specific host and port, you still remain connected (for a period of time) even if you aren’t sending any data and you can send and receive data continuously without having to reconnect in between.

UDP on the other hand doesn’t really fit the telnet model – its more of a fire-and-forget system where you fire-off a series of packets towards the destination. You then go on with something else (or just wait doing nothing) until (or if) the remote process sends some packets back.

That is why we can’t use telnet to test udp port, in this tutorial i will try to use nmap, you need to install nmap first. Here is the command

# nmap -p [port] -sU -P0 [host name | ip address]
# nmap -p 5060 -sU -P0 example.com
# nmap -p 5060 -sU -P0 21.12.32.123

From the command shown above, I am assuming that the host example.com(21.12.32.123) is currently serving asterisk sip service on UDP port 5060.

Sample opened UDP port output:

# nmap -p 5060 -sU -P0 21.12.32.123

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2010-07-07 22:26 MSD
Interesting ports on 21.12.32.123:
PORT     STATE         SERVICE
5060/udp open|filtered sip

Nmap finished: 1 IP address (1 host up) scanned in 2.021 seconds

If you have a closed UDP port, you should be seeing similar lines as shown

Interesting ports on localhost (127.0.0.1):
PORT STATE SERVICE
123/udp closed ntp