Simplicity
The simplicity methodology seeks to increase security by reducing vulnerability. In the rest of this tutorial you will learn to:
1. Reduce network access to your machine using a firewall (we'll teach you how to build your own)
2. Decrease the number of priveleged programs. You help yourself by decreasing priveleged programs because you reduce the ways ppl can gain access
3. Tighten configuration of those priveleged programs you want to keep
4. Reduce number of paths to root, that is restrict access of non-priveleged users
5. Deploy intrusion detection by using file integrity checking
You will do yourself a big favor if you restrict access to and remove all unnecessary priveleged programs. However, many linux users are unaware of what the hell all those programs do that come prepackaged with their distro of choice. The linux services list will give a brief description of each service configured to install automatically on linux and a recommendation as to whether the service should be left on or not.
Firewalls
BASIC Firewalling with IPChains
There are a number of great tutorials and HOWTOs on IPChains available on the net. If you get confused by this tutorial I would recommend you look to the internet for clarification. Remember, DIY.
Linux Kernal 2.2 supports stateless packet filtering -- like a router.
Linux Kernal 2.4 supports stateful packet filtering -- like on a commercial firewall package.
TCP/IP Introduction/Reminder
TCP/IP is the basic internet protocol developed by a group of academics. This is an open source standard and is what makes the internet as we know it possible. Microsoft has tried to coopt this standard and has released standards that were intended to make TCP/IP obsolete. Luckily these efforts were a failure.
Every communication between two computers on the internet is broken into data packets. Each data packet begins with a header which tells servers and computers where to send the packet to. TCP/IP stands for Transport Control Protocol / Internet Protocol. The IP part gets information from one host to another. The header's important fields are: Source IP address and Destination IP address. or SRC_IP and DST_IP. TCP gets information from one program to another. Header's important fields are: Source Port and Destination Port. Another TCP - like protocol is UDP or User Datagram Protocol. I will not elaborate on the difference here. I would advise you to look to the internet for more information if you are interested.
TCP rides with the IP packet through encapsulation, this will all be important in understading your IPChains. The header for TCP is placed at the beginning of the data portion of the IP packet.
TCP is good at correcting errors, packet ordering, confirming packets, and creating and destroying connections. This last part is of particular interest. By understanding how a connection is made using TCP and what that consists of, you can regulate who may connect to your computer. All hack attacks begin with a connection. So sit up and pay attention! You should be aware that the one downside of TCP that UDP is actually superior for is that TCP has a high overhead, data flows at slower speeds.
Packet Filtering Intro
There are two major types of firewalls: Packet Filtering and Proxy
I recommend packet filtering which can be implemented using IPChains and IPTables (later in this tutorial). Packet filtering deletes packets trying to connect over a network based on a set of rules written by you. Proxy-based firewalls allow you to make a connections through an intermediary host, then that host connects for you, making a clean connection and protecting the entity behind the host. The major drawback of using a Proxy is a slower connection. Although these are sometimes useful as a user wanting to surf anonymously. Remember though, you are not totally anonymous because the host knows who you are and everyone else knows who the host is (identification occurs through your IP address). Check out Cyberarmy.com for a list of proxies. Wingates can also be useful for this type of anonymity. I will post a tutorial on wingates later.
When you make a connection, you send your packet to a host port from a port on your machine. Common services such as FTP and Web Servers listen on a predictable port. In fact, web browsers are programmed to automatically check port 80 for the webpage by default. You can check another port with a web browser by indicating it in the address. i.e. www.hackerthreads.org:2105, however, if there is nothing there or if there is a service running that doesn't understand a browser request, nothing will come of your attempt. Daemon is the name for the listener on a port. So there would be an FTP daemon listening on port 21. Anyway, in building your firewall, you want to restrict access to ports as that is where the connection requests go. A bunch of open ports = vulnerability.
Common ports and their service:
FTP -- 20/21
SSH -- 22
SMTP -- 25
DNS -- 53
HTTP -- 80
POP -- 110
IMAP -- 143
HTTPS -- 443
IRC -- 6667
Telnet -- 23
If you dont know what these services are, look them up, they are very common. You should not have any trouble finding plenty of documentation on them.
Lets Block Connections
So here is how you would block all incoming connection requests but let all connection requests go through:
TCP does what is called handshaking when a new connection is made. The first packet sent says: Source -> Synchronize or (SYN) = on and Acknowledge (ACK) = off
The second packet says Dest->Source: SYN=on, ACK=on
The third packet says Source-> Destination: SYN=off, ACK=on
The fourth packet says .... -> SYN=off, ACK=on
To block all incoming requests then, you need to set you firewall to reject or drop all packets that have SYN=on and ACK=off. Lets get into some practical IPChain writing.
There are there possible chains INPUT, FORWARD, OUTPUT (packets that are going to be forwarded go through all three in ipchains)
When there is an incoming connection request on a specfic port, your machine will test the request against its rule set to determine whether the connection is responded too, is completed, rejected or dropped.
Lets look at an INPUT Chain then go through each line of the chain:
Default Policy: Accept
src_port = 23 judgement=block
dst_port = 21 judgement=block
This chain has a default policy of accept. That means when a new connection comes in, if it is not covered by your rule set then the connection will be allowed. The opposite is true for a default policy: deny
This chain then says that any packet that has a header indicating a source port of 23 block or do not allow the connection to be made, effectively denying access to telnet. The next rule says that any packet with a destination port 21 is also blocked, effectively denying access to FTP (both good policies).
IPChain Syntax:
ipchain -P
then set default policy of the chain
ipchains -F chain flushes or resets all chains.
ipchains -A chain
ipchains -L chain lists all rules for chain
ipchains -A chain
-s (Source_IP)
-d (Destination_IP)
--source-port (Source_Port)
--destination-port (Destination_Port)
-i (network_interface)
! (expression) also =NOT (boolean logic)
-y = SYN (flag set) to block packets with SYN status = on or = off
Chain
INPUT,OUTPUT,FORWARD
Judgement
ACCEPT,DROP,REJECT,LOG,MASQUERADE --accept permits a connetion to be made, drop means the connection is dropped and no msg is sent to user, reject means the connection is dropped and a reject message is sent to the user, log means that the connection attempt will be logged with the person's IP, time and other goodies.
Syntax Example for blocking ftp and telnet:
{Default Policy: Accept
src_port = 23 judgement=block
dst_port=21 judgement=block}
would look like:
ipchains -P input allow --setting default policy
ipchains -F input --flushing ruleset
ipchains -A input -p tcp --sport 23 -j DENY --denying any TCP connection with source port 23, which is telnet
ipchains -A input -p tcp --dport 21 -j DENY --denying any TCP connection with destination port 21, which is where your ftp server is
Daemons
As a Linux system administrator I recommend that you perform regular Service/Daemon Audits. This takes time and you do lose some of that simplicity, but you will more than make up for time lost up front doing audits by avoiding the time it takes with a hacked machine, especially if you are on a network.
Why are Audits important?
In the Linux operating system, programs have priveleges. Some have root priveleges. They need this privelege in order to run their processes. Some services are persistent, while others are considered non-persistent. The difference is that a persistent program is always running or is running on some schedule whereas a non-persistent program runs once when it is called to, i.e. on boot, and then doesn't run again. Running persistent programs that you don't need is not only a security issue but also drains resources by cycling through its process, requiring electricity and system resources. Don't be tempted to think that non-persistent programs are not a threat, they are.
Step 1 in System Audit:
Wrappers
Inetd - it's the original network superserver. There is also now Xinetd that has become very popular. I will cover Inetd but these principles are applicable to Xinetd as well. By superserver I mean Inetd is in control of serving several processes or services, it is several daemons (port listeners) at once.
Inetd listed on many ports and starts a single instance of an appropriate server for each incoming connetion. Here is a list of some of the most well known services controlled by Inetd: ftp, telnet, pop, imap, finger
You can get a list of services at /etc/services, you can also access the status of your services, so you know what is running. People use /etc/inetd.conf to configure there inetd superserver.
An example of what you may see in inetd.conf
(port) (type) (proto) (wait) (UID) (Program) (Arguments)
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
Here is an example of the RH6.2 inetd.conf file (I do not adovocate using RedHat or any other distribution):
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
shell stream tcp nowait root /usr/sbin/tcpd in.rshd
login stream tcp nowait root /usr/sbin/tcpd in.rlogind
talk dgram udp wait nobody.tty /usr/sbin/tcpd in.talkd
talk dgram udp wait nobody.tty /usr/sbin/tcpd in.ntalkd
finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd
linuxconf stream tcp wait root /bin/linuxconf linuxconf --http
note the services that have root as UID, those programs get root priveleges. Should an intruder gain control of that service you could be in trouble. That is why it is essential to audit services and determine whether a particular service is necessary.
Step 2 in System Audit: Onward to the SERVICES
It can sometimes be hard to find documentation on all those services. Why do so many come prepackaged? Because many linux distros are bending to market pressure for more features. Also, it decreases the cost to customer support since there are fewer newbies calling to ask how to turn service X on.
ftp
Generally bad news. Used for data transfer between to machines. Data is transfered in cleartext and that is really bad. FTP is difficult to firewall because ports 20 and 21 must be open and typically ftp servers open all kinds of extra ports for connection reasons as well. There are tons of security vulnerabilities in WU-FTPd, Pro-FTPd adn even on OpenBSD. I suggest replacing ftp with SSH. I will talk more about SSH later. The main advantage to ftp is that many ppl know how to use it and there are an abundance of clients. tftp can be helpful for other reasons, if you think you need it, you don't need me to explain it.
telnet
Generally bad news. Telnet is cleartext meaning the session and passwords can be gotten quite easily. These sessions can actually be hijacked using a program called Hunt. There are others like it as well such as Jaugarnaut. I would avoid this like the plague. SSH can replace this one too. This service is typically used as a way to get remote access to a machine.
rsh, rlogin, rcp, rexec
This service is also cleartext. It relies on IP addresses for authentication, which are spoofable. There is a lenghty vulnerability history.The R tools are pretty much out of use. They were built by Berkeley CS folks and were designed for a largely different network paradigm. The r-tools are not safe. They are all cleartext and they all have lengthy vulnerability histories. I would definetly turn these suckers off.
talk/ntalk
These can be useful, but you shouldn't discuss sensitive information using them. This is basically the original Instant Message client. Users on a network can send messages to each other instanteously. In the old days it was a great way to meet women in college, because we were all on the same network. You can just indicate a user and start talking. The dangerous part is that they are not encrypted and are hijackable. Thus I would not use them for sensitive information. The service themselves do not open your machine to vulnerabilities.
finger
Finger is a way to get information about users on a network. The command is simply finger
anacron
Anacron is similar to cron, but it is actually better for machines on the network that are not always-on machines. This program allows other programs to run on a schedule designated by weekly or hourly instead of by a time in cron. It is responsible for peforming some great tasks like changing logs. I would leave this guy on.
kudzu
This detects new hardware and stops running before anyone logs in. It's not a risk and is important. Leave it on. This is an example of a non-persistent service.
ipchains
ipchains loads your kernel filtering rules if there are rules that have been set. This can't hurt you but you may as well turn the thing off if you haven't created a rule set. I recommend turning it off and using IPTables and TCP Wrappers.
network
Starts up network interfaces and stops, this is a very important function. This is another non-persistent service. Leave it on.
portmap
Provides RPC portmapping to NFS and NIS. If you are not using these, and I recommend you not, trun Portmap off. Portmap has had many security vulnerabilities. It has been quite a risk in the past, you should really try not to use any of the above mentioned services anyway. As they too are risky business.
nfslock
Starts rpc.lockd and rpc.statd, two services that are needed for NFS clients and servers. If you are not using NFS, which you shouldn't be imo, then for god's sake turn this off.
apmd
Acronym stands for Advanced Power Management Daemon. This is good for linux on a laptop. If you are not on a laptop, you don't need this. I don't know of any security problems but this is a persistent process which eats up system resources, just runs useless cycles, no real benefit if you are not on a laptop. There could be vulnerabilities on this in the future, which system admins should keep in mind. The key is to beat crackers before they get to your system.
random
It is a non-persistent script that maintains a random seed needed by the OS. Dont worry about it. FYI the random seed is used for encryption. You should also know that no seed created by an algorithm is ever truly random, though many a CS student believes otherwise.
netfs
Mounts network filesystems. This is a non-persistent service so not a very risky proposition. NFS has had quite a few problems over the years and so I discourage its use. If you dont run NFS then this is not necessary. If you insist on running NFS or Samba keep security in mind. I recommend doing your damnest to secure your intranet so that intruders can't get in in the first place. Though that is not always possible.
syslogd
Starts the syslog daemon which is important. It logs activity to your log files. I strongly recommend keeping this running. It will help you identify attacks in their early stages. These logs are the first you check when you think there has been an intruder or when you think you are under attack. Without syslogd those files don't get created. That would be bad.
identd
Learn it and love it. Permits the systems that your computer communicates with to make TCP connections to determine who has originated a connection. I use it mainly to check on local users. Can tell you which computer got cracked, can help track the person down, depending on the attack. I would type man identd at the command line if were you and didn't know this service.
atd
Allows users to schedule programs for later execution. This has a lengthy security history and has been replaced by cron or anacron. Turn it off.
crond
Allows users to schedule programs for later use. I use this primarily for repetitive execution. Shell scripting knowledge required. Configure this to only allow priveleged users to access and modify it. If you are not familiar with this run a man page on it. I think you will find it extremely useful. I wish I could cron everything in life Smile Of course, automation is the holy grail for me so....
pcmcia
This just loads pcmcia modules into the kernel if you have a pcmcia card, which you will only have if you are running a laptop. Turn this off if you are not on a laptop, not necessary. Again try to avoid those useless cycles.
inetd
xinetd/inetd control many internet daemons as discussed above. If none of its services are running and you chose not to use TCP wrappers, turn this off.
rawdevices
Allows your system to map and block devices. This is non-persistent and is not a security threat. This is safe and useful.
gpm
A cut and paste server for command line session. This has had some root vulnerabilities in the past. If you run X you won't need this. If you are all command line sessions, you may want to keep it. I use command line though generally turn it off by habit. It's really your call.
httpd
This is your Apache web server. So, in general, I have this on, but then again I am serving pages and experimenting with differnt mods. If you do not want to serve pages or are currently not serving pages but intend to in the future, turn it off until you do. Web servers can present some interesting problems.
xfs
This is only needed if your box is a font server. I turn this off.
linuxconf
This is used to make policy changes. I believe it is a Red Hat product. There is much debate in the linux community whether this is a good tool or not. Personally, I used it when I first got into linux but don't anymore. It's non-persistent and not much of a risk. If you don't use it turn it off.
local
This is safe. local stores your machine scripts and is what you make of it. I leave this on, but audit it periodically.
Root Audit
Every file in Unix and Linux have a set of permissions. File permissions are octal and are generally three numbers. The first designates the User owner -- or who owns the file, the second number designates Group owner -- what Group the file is owned by and the third is Global or the permissions for everyone else.
Each number that represents the file permissions is a combination of three binary numbers:
100 (4) - Read
010 (2) - Write
001 (1) - Execute
So a 7 would equal give Read, Write adn Execute permissions to that particular Owner, Group or Global. A way for short handing that is 7 = rwx
To follow this example further, 5 = rx or gives permissions to Read and Execute. That would allow the user with this permission set to view and use a file but would not allow them to change the file.
4 = r or just Read permissions
6 = rw or Read and Write permissions
A file that is a program and needs to be ran to be used, for example ./edonk , cannot be used unless the permissions are set to allow execution. I have spent an hour researching a non-functioning program only to check the permissions and notice that I did not invoke the execute permissions for the user, group or globally. This is very important when you first install a program. Some come with wide open permissions, which can be dangerous if the program gives away important system information or access. Other programs give no permissions at all and cannot be run until you set the permissions appropriately.
Here is an example of a full set of permissions:
755 - user can can rwx, the group can rx, global can rx
SUID
755 is really 0755. That first digit has to do with Set -UID or SUID. SUID/SGID progs have a non-zero first digit, such as:
4755 - SetUID or 2755 - SetGID.
Progs normally run as the user who started the prog in the first place. SUID progs run as the owner. If a SUID prog develops a bug or vulnerabilty it can be exploited to allow regular system users to acquire the priveleges of the prog owner, usually root. This is why it is a damn good idea to restrict Set-UID.
Two ways to restrict Set-UID:
1. Strip off SUID bit -- remove SUID bit thus removing the security context transformation (or the transfer of root priveleges to regular users).
Here is the syntax: chmod u-s foo or chmod 0755 foo (if you are confused by this syntax look up chmod command)
2. Strip World Execute -- remove teh world execute bit to allow only those with a special group to use the program.
Here is the syntax: chmod o-x foo or chmod 4750 foo
Now that you know all about Set-UID and how to eliminate the vulnerabilty, check your programs under root ownership to see whether they have SUID permissions. If so, make sure you have a really good reason for granting those priveleges.
PS : dont give me any Credit, this is just an old file from my hdd
Tidak ada komentar:
Posting Komentar