Hi list users, who synchronizes with whom? the trojan client with the trojan server or the server with the client? I'd say since it must be analogue to all tcp connections the client syncs with the server, but I'm not sure whether it really works like this in the special (?) trojan case. I do not have enough background information to be sure. I already checked O'Reilly's Building internet firewalls but I cannot find there anthing covering this topic. thanx in advance Philipp
who synchronizes with whom? the trojan client with the trojan server or the server with the client? This depends completely on the trojan implementation. Sometimes only one direction (incoming or outgoing), sometimes also both directions (notify the "bad guys", to tell them the ip-address and wait for them to connect). Blocking all unwanted (unused) ports for listening sockets (ipchains -y) can prevent trojans which open listening sockets, but at this point it is often much too late - the trojan is already in
bye Markus -- _____________________________ /"\ Markus Gaugusch ICQ 11374583 \ / ASCII Ribbon Campaign markus@gaugusch.dhs.org X Against HTML Mail / \
who synchronizes with whom? the trojan client with the trojan server or the server with the client? This depends completely on the trojan implementation. Sometimes only one direction (incoming or outgoing), sometimes also both directions (notify the "bad guys", to tell them the ip-address and wait for them to connect). Blocking all unwanted (unused) ports for listening sockets (ipchains -y) can prevent trojans which open listening sockets, but at this point it is often much too late - the trojan is already in
Hmm...no good news. Since I at least want to have little security in this I'll put the -y in my most used hi-ports and the others I'll totally block.
bye Markus
-- _____________________________ /"\ Markus Gaugusch ICQ 11374583 \ / ASCII Ribbon Campaign markus@gaugusch.dhs.org X Against HTML Mail / \
* Philipp Snizek wrote on Wed, Apr 11, 2001 at 16:55 +0200:
Blocking all unwanted (unused) ports for listening sockets (ipchains -y)
Hmm...no good news. Since I at least want to have little security in this I'll put the -y in my most used hi-ports and the others I'll totally block.
AFAIK many trojans use UDP, please correct me if I'm wrong. "-y" affects TCP packets only. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
* Philipp Snizek wrote on Wed, Apr 11, 2001 at 16:55 +0200:
Blocking all unwanted (unused) ports for listening sockets (ipchains -y)
Hmm...no good news. Since I at least want to have little security in this I'll put the -y in my most used hi-ports and the others I'll totally block.
AFAIK many trojans use UDP, please correct me if I'm wrong. "-y" affects TCP packets only.
Accoroding to simovits.com most trojans use tcp and some litte udp. needless to say that udp in most cases can be blocked totally. But how would you try to stop trojans-communication if they used your most used hi-ports, lets say 25000-30000 for example? If you block these ports e.g. with ipchains, your clients are not able to communicate anymore to the outside world. If you block tcp-syn from internet to internal net according to Markus Gaugusch your chances depend on how the specific tcp trojan syncs: from client to server, server to client respectively. What would you do? Philipp
oki,
Steffen
-- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
http://www.securityportal.com/closet/closet20001101.html December 01, 2000 - I'm feeling clever today. I rebuilt my gateway server, and decided to go gung-ho when it came to firewalling - a default deny policy for input, output and forward chains. Needless to say, this breaks a lot of things. Well, it breaks basically everything, until you start putting in rules to allow packets through. Using a default deny policy in Linux is tricky because the firewall in kernel 2.2 is not stateful. (It is stateful in 2.4, but that is still in a test series and several months off from release.) With a stateful firewall you can make simple rules: "If you see an outgoing connection, let the incoming packets associated with it through." If your firewall is not stateful, you will have to create many rules to allow services to work for clients. This can be annoying if you really want to lock your firewall down. Here's what it comes down to: Creating a really tight firewall in Linux is a pain. But all is not lost. Several tips and tricks can aid you in creating a tight firewall. The first trick looks at the local port numbers that the system uses for outgoing connections. All TCP connections have a source port and address, and a destination port and address. If you want to control which ports connections are allowed to go out on - and thus the incoming packets you will need to allow in - you must know the port range. Otherwise, to let connections out and the reply data back in, you'll need to allow all the ports in, 65,535 of them. Luckily, this is configurable in Linux. You can set it in the kernel: /usr/src/linux/net/ipv4/tcp_ipv4.c /* * This array holds the first and last local port number. * For high-usage systems, use sysctl to change this to * 32768-61000 */ int sysctl_local_port_range[2] = { 1024, 4999 }; Or via the proc interface at any time (i.e. in the network startup script): /proc/sys/net/ipv4/ip_local_port_range Basically, any outgoing connection will originate from that port range, allowing you tight control over outgoing and incoming rules. But there arises another problem. IP-MASQ'ed connections do not originate from these defined local source ports, meaning services will not work properly unless you use some type of proxy or have permissive rules to allow client connections. The good news is that most of the IP-MASQ connections appear to originate from ports in the 61000-65095 range - at least they do on my server - and this doesn't change between reboots. (Look in ip_masq.c.) So if your IP-MASQ'ed connections are originating from ports 61000-65095, and connections from the server itself from 1024-4999, then you need two sets of rules for each thing you want to allow. Alternatively, you could use it to allow connections from the IP-MASQ'ed client but not from the server itself. Using it in this capacity would be pointless, however, since that can be accomplished in incoming firewall rules for the IP-MASQ clients, and output rules for the server itself. So, what good is any of this? Well, if you set the local port range on your IP-MASQ server to 61000-65095 (assuming you don't need more than 4000 simultaneous connections - if you do, use a larger range), it's easy to set via proc: echo 61000 65095 > /proc/sys/net/ipv4/ip_local_port_range Or if you want it to be permanent, you can set it in the kernel, though I recommend avoiding kernel hacks if possible. So with almost all (more on this later) of your connections originating from ports 61000-65095 on your server, it is very easy to use a default deny policy and allow selected services. For example, Web browsing: ipchains -A output -s 0.0.0.0/0.0.0.0 61000:65095 -d 0.0.0.0/0.0.0.0 80:80 -i eth0 -p 6 -j ACCEPT ipchains -A input -s 0.0.0.0/0.0.0.0 80:80 -d 0.0.0.0/0.0.0.0 61000:65095 ! -y -i eth0 -p 6 -j ACCEPT The "! -y" means no packets with the SYN bit set (used to initiate connections), since there should only be packets from established connections coming in. This works well for most common services; however, there are two that get quite messy. FTP requires the remote FTP server to establish inbound connections with the server, and depending on whether the server uses passive or active FTP, the ports these connections occur from can vary significantly. DNS also requires some messy fiddling, since it relies heavily on UDP packets. Depending on whether the request is simply forwarded by the server, generated by the server, or actually handled by name server software running on the server, can affect behavior significantly. Generally speaking, the best way to deal with these is to have some catch-all rules at the end to log all denied packets, for example: ipchains -A input -l -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -j DENY ipchains -A output -l -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -j DENY ipchains -A forward -l -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -j DENY You can then "tail -f /var/log/messages" and watch as packets are denied. You will then be able to determine what needs to be allowed through. The following is an entry from /var/log/messages while using an FTP client on the server: Oct 17 00:32:46 server kernel: Packet log: input DENY eth0 PROTO=6 1.2.3.4:20 5.6.7.8:61394L=44 S=0x00 I=61949 F=0x4000 T=250 SYN (#28) Now, this is extremely verbose. First off is the time, followed by the chain (input) and the action taken (DENY). The protocol is 6 (which according to /etc/protocols is TCP); the source is 1.2.3.4, port 20 (according to /etc/services this is ftp-data); and the destination was 5.6.7.8, port 61394, which was blocked by rule #28 in the input chain. Armed with this information, and the result of "remote directory listing not available" in your FTP client, it is a safe bet that you need to allow connections from port 20 to 61000-65095 if you want FTP to work properly. I spent about three days doing this off-and-on fine-tuning of my firewall. It's also a good way to refresh your memory on exactly how various strange protocols like FTP work. (OK, I admit that this kind of thing amuses me, which is probably why I am currently single.) Another problem can be setuid or programs run as root that use "strange" ports as the source port. For example, when root runs the SSH client to connect outwards, it might use port 1000 or similar, even with the local ports specified. You can largely avoid this by not running things as root - a good idea in any case. This type of behavior also raises some other questions: Can you do semi-reliable OS detection based on the source port? Stay tuned, same bat channel, same bat time, in one week for the answer to that question, and more. Kurt Seifried, seifried@securityportal.com Securityportal - your focal point for security on the 'net
But all is not lost. Several tips and tricks can aid you in creating a tight firewall. The first trick looks at the local port numbers that the system uses for outgoing connections. All TCP connections have a source port and address, and a destination port and address. If you want to control which ports connections are allowed to go out on - and thus the incoming packets you will need to allow in - you must know the port range. Otherwise, to let connections out and the reply data back in, you'll need to allow all the ports in, 65,535 of them.
Luckily, this is configurable in Linux. You can set it in the kernel:
/usr/src/linux/net/ipv4/tcp_ipv4.c /* * This array holds the first and last local port number. * For high-usage systems, use sysctl to change this to * 32768-61000 */ int sysctl_local_port_range[2] = { 1024, 4999 }; Or via the proc interface at any time (i.e. in the network startup script):
/proc/sys/net/ipv4/ip_local_port_range Basically, any outgoing connection will originate from that port range, allowing you tight control over outgoing and incoming rules.
Could you please explain closer? How does this refer to my question? How could I block trojan-client (me) -> trojan server (the attacker) using ip_local_port_range? Is this /proc filesystem feature protocol aware? BB-Zone Definition: ip_local_port_range Range of ports used by TCP and UDP to choose the local port. Contains two numbers, the first number is the lowest port, the second number the highest local port. Default is 1024-4999. Should be changed to 32768-61000 for high-usage systems. It seems to me by using this feature I only define what ports have to be used locally for connecting to servers. But there are always a number of trojans in every port range. How could I prevent these by using a none-stateful firewall? Is there a way? Philipp
Simple: If your firewall is like mine then only packets going out to port 25, port 80, etc are allowed, thus a trojan is less likely to be able to connect out (since they use ports like 31337 and so on). Plus since my firewall runs application level proxies for www/ftp, email, etc about the only protocol I allow my internal machines to do outbound is 22 (ssh), which makes keeping tabs on what is going on very easy.
Could you please explain closer? How does this refer to my question? How could I block trojan-client (me) -> trojan server (the attacker) using ip_local_port_range? Is this /proc filesystem feature protocol aware?
BB-Zone Definition: ip_local_port_range Range of ports used by TCP and UDP to choose the local port. Contains two numbers, the first number is the lowest port, the second number the highest local port. Default is 1024-4999. Should be changed to 32768-61000 for high-usage systems.
It seems to me by using this feature I only define what ports have to be used locally for connecting to servers. But there are always a number of trojans in every port range. How could I prevent these by using a none-stateful firewall? Is there a way?
Philipp
I'm starting to explore proxies. I'm curious which application level proxies you are using. On Thu, Apr 12, 2001 at 04:32:25PM -0600, Kurt Seifried wrote:
Simple:
If your firewall is like mine then only packets going out to port 25, port 80, etc are allowed, thus a trojan is less likely to be able to connect out (since they use ports like 31337 and so on). Plus since my firewall runs application level proxies for www/ftp, email, etc about the only protocol I allow my internal machines to do outbound is 22 (ssh), which makes keeping tabs on what is going on very easy.
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
-- -ashley One of these days I'm going to completely organize my life.
On Thu, 12 Apr 2001 12:48:24 +0200, you wrote:
Accoroding to simovits.com most trojans use tcp and some litte udp. needless to say that udp in most cases can be blocked totally. But how would you try to stop trojans-communication if they used your most used hi-ports, lets say 25000-30000 for example? If you block these ports e.g. with ipchains, your clients are not able to communicate anymore to the outside world. If you block tcp-syn from internet to internal net according to Markus Gaugusch your chances depend on how the specific tcp trojan syncs: from client to server, server to client respectively. What would you do?
I think it's impossible to protect against all type of trojans. Client to server trojans are difficult (if not impossible) to block if you want still use your computer for web browsing and/or other client applications. If I were a trojan maker I'd make my trojan to use the client (victim) to server (attacker) method using port 80 as destination port (the chances this port is allowed are high). This would work in 99.9% cases including firewalled environments. I cannot figure a way to block this type of attack *without* breaking normal client functionality. The only way to block (quite) all of these attacks would be to filter *all* client activity and letting only outgoing packets go by if and only if they match a previosly established connection. Here is where stateful inspection becomes useful. But it's still imposible to achieve general trojaning protection without breaking client functionality, as I said. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ** RoMaN SoFt / LLFB ** roman@madrid.com http://pagina.de/romansoft ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* RoMaN SoFt / LLFB !! wrote on Thu, Apr 12, 2001 at 14:35 +0200:
If I were a trojan maker I'd make my trojan to use the client (victim) to server (attacker) method using port 80 as destination port (the chances this port is allowed are high).
Yep, simply use HTTP for communication. Sniffing on network may show proxies. GET "http://geocities.com/url/comm.cgi?params". So I would so that: sniff for proxy if direct connects don't work. But there are more chances: ICMP payload or setting some bits in the IP headers. Nice communication, 448 bits per bit overhead (1 "payload" bit per packet) :) But should work and should be difficult to detect; I assume most people would think this is a kind of DoS [which is it, too :)]. Another nice idea was told i.e. on bugtraq: just take a raw socket, process all input via DES. Some bytes (i.e. last 20bytes or so of each packets) are interpreted as hash. If the hash matches, execute the decrypted instruction. Maybe a BASE64 decode is tried first [we may sniff an email] or whatever. This traffic may be on any hijacked TCP connection, an UDP packet or even IP proto 50. Nice idea - maybe combined with some ARP flooding, since switches are not uncommon... Or sniff for allowed packets: analyse the traffic and emulate such packets (same destination port, same source IP), this should work for some cases, too (i.e. SSH maybe or whatever). But ipchains -l [Kurt: surely you know that -s defaults to 0.0.0.0/0.0.0.0] -j DENY and things like snort helps you to detect such attemts. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
participants (6)
-
Ashley -
Kurt Seifried -
Markus Gaugusch -
Philipp Snizek -
RoMaN SoFt / LLFB!! -
Steffen Dettmer