LinuxQuestions.org - Symlink Attack

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - Symlink Attack (https://www.linuxquestions.org/questions/linux-security-4/symlink-attack-701251/)

OK, that's cool and actually good to know, but that's not actually the direct result (nor the real intent) of such an attack.

Actually, the more I think about it, the more I'm leaning toward that being actually what happened with the OP. That makes more sense than the OP's explanation (or evidence).

Quote:

Originally Posted by unixfool (Post 3432464)

This type of attack has NOTHING to do with server load. I really don't think your load is going to change all that much between before and during a syn flood.

If you want a true assessment of a syn flood, try it with something like a vmware host. In fact, try it with two hosts...one being the attacker and one being the target. Find a syn flood tool and attack the target host and monitor the load of the server.

Syn floods consume network stack resources, not service or host-level resources or even hardware-based resources such as CPU and memory.

I really don't think what you saw in your logs was anywhere near what you are assuming. If you think otherwise, you need to provide more data than you have provived thus far. If that's all you have, that still doesn't mean that you were syn flooded or symlink attacked. If I were you I'd check things such as the syslog logs to ensure the server wasn't misconfigured. This sounds more and more like a misconfig and not an actual attack.

I agree that it would be a good idea for the OP to conduct his own SYN flood so he can see the effects with his own eyes. It's always better to verify things instead of relying on one's interpretation of some Wikipedia article.

Quote:

Originally Posted by chort (Post 3432468)

Depending on the level of logging, a SYN flood or other request flood could cause staggering disk I/O trying to keep up with logging the requests, which would result in very high load average and sluggish responses. I was once troubleshooting a Linux system that was responding very slowly despite not handling unusual amounts of network traffic. The cause turned out to be someone had enabled iptables logging for every packet and it was logging to local disk. Disabling iptables logging took the load from 27 to 3.

Good point. This could definitely be the case, although I would have expected the OP to mention something about the iptables configuration having been changed prior to the anomalous behavior. I mean, otherwise (with logging for all packets enabled) this might have been happening 24/7 (or at least whenever the server was busy). Of course, a SYN flood would have made the logging much worse if no logging limits were enforced. Another theory could be that rate limited logging and dropping was being done for excess SYNs (instead of all packets), but with the information we've been provided so far it's impossible to tell what's going on. I agree that this may have indeed been caused by excessive logging (as you have pointed out), I just wish we had some information we could use to have a fair degree of certainty.

Quote:

Originally Posted by unixfool (Post 3432556)

True that. This should be fairly simple for the OP to determine, though. Or, if he posts the output of "iptables -nvL" we could look into it ourselves. In a little bit, I'm gonna launch a SYN flood against one of my boxes with full logging enabled to see what happens to the load on the target. For now, I'll attack via 802.11g Wi-Fi, but once I find my trusty crossover cable I shall attack via Ethernet. I'll post any interesting results I get.

Quote:

Originally Posted by win32sux (Post 3433151)

I'm gonna launch a SYN flood against one of my boxes with full logging enabled to see what happens to the load on the target. For now, I'll attack via 802.11g Wi-Fi, but once I find my trusty crossover cable I shall attack via Ethernet. I'll post any interesting results I get.

Are you sure you need a crossover cable? All the NICs I've used in the last few years have auto MDIX, so you can use a normal "straight through" cable between two machines with such NICs and they'll communicate just fine.

Quote:

True that. This should be fairly simple for the OP to determine, though. Or, if he posts the output of "iptables -nvL" we could look into it ourselves.

Im not sure what to look into, but here it is.

Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

11M 2387M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
5225 295K REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp flags:!0x17/0x02 reject-with tcp-reset
124 9850 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID
13011 741K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0

0 0 DROP udp -- * * 99.248.145.194 0.0.0.0/0

0 0 DROP tcp -- * * 99.248.145.194 0.0.0.0/0

334 17400 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:8443
3 148 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:8880
1240K 65M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:80
91 4684 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:443
9 516 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:21
56 3128 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:22
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:587
2413 119K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:465
2893 145K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:110
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:995
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:143
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:993
2 128 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:106
2 128 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:3306
2 128 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:5432
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:9008
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:9080
25318 1984K DROP udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpt:137
9145 2172K DROP udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpt:138
21 1040 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:139
99 4788 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:445
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpt:1194
233K 11M ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpt:53
5 224 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:53
82 4990 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
icmp type 8 code 0
117K 15M DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp flags:!0x17/0x02 reject-with tcp-reset
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID
0 0 ACCEPT all -- lo lo 0.0.0.0/0 0.0.0.0/0

0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

12M 11G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
3154 546K REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp flags:!0x17/0x02 reject-with tcp-reset
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID
13011 741K ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0

245K 16M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

sorry for the double post..but just got another reply from tech suppport

Quote:

I am not sure that I would say it was a SYN Flood or a Denial of Service. Basically it was 1 or 2 IP addresses that were making multiple rapid connections to the server causing apache and MySql to increase memory and CPU usage on your server thereby causing it to become very sluggish to almost totally unresponsive.

As for enabling the 'TCP SYN cookies' I would not recommend that they be turned on unless you are willing to thoroughly test the effects of having them turned on.

Okay, I managed to do the test via Wi-Fi. The test via Ethernet is pending (I don't have physical access yet and haven't found a cable). Keep in mind that I conducted this test with a link quality of only 62%, so I expect the victim (with full logging enabled) to receive a much bigger hammering on Ethernet.

Before the start of the attack (without any logging enabled):

Code:

win32sux@toystore:~$ sudo iptables -nvL INPUT

Chain INPUT (policy ACCEPT 45 packets, 3300 bytes)

 pkts bytes target    prot opt in    out    source              destination        

win32sux@toystore:~$ cat /proc/loadavg 

0.00 0.08 0.16 2/191 5720

win32sux@toystore:~$ netstat -an --inet | grep SYN_RECV | wc -l

0

win32sux@toystore:~$

About three minutes into the attack (ongoing):

Code:

win32sux@toystore:~$ sudo iptables -nvL INPUT

Chain INPUT (policy ACCEPT 438K packets, 18M bytes)

 pkts bytes target    prot opt in    out    source              destination        

win32sux@toystore:~$ cat /proc/loadavg 

0.00 0.03 0.12 1/191 5726

win32sux@toystore:~$ netstat -an --inet | grep SYN_RECV | wc -l

256

win32sux@toystore:~$

Before the start of the attack (full logging enabled):

Code:

win32sux@toystore:~$ sudo iptables -nvL INPUT

Chain INPUT (policy ACCEPT 214 packets, 16024 bytes)

 pkts bytes target    prot opt in    out    source              destination        

  39  2844 LOG        0    --  eth0  *      0.0.0.0/0            0.0.0.0/0          LOG flags 0 level 4 prefix `SHITSTORM: ' 

win32sux@toystore:~$ cat /proc/loadavg 

0.00 0.00 0.07 2/191 5741

win32sux@toystore:~$ netstat -an --inet | grep SYN_RECV | wc -l

0

win32sux@toystore:~$

About three minutes into the attack (ongoing):

Code:

win32sux@toystore:~$ sudo iptables -nvL INPUT

Chain INPUT (policy ACCEPT 480K packets, 19M bytes)

 pkts bytes target    prot opt in    out    source              destination        

 480K  19M LOG        0    --  eth0  *      0.0.0.0/0            0.0.0.0/0          LOG flags 0 level 4 prefix `SHITSTORM: ' 

win32sux@toystore:~$ cat /proc/loadavg 

2.17 1.36 0.61 3/190 5746

win32sux@toystore:~$ netstat -an --inet | grep SYN_RECV | wc -l

256

win32sux@toystore:~$

Even with my crappy wireless connection to the victim, I think these results speak for themselves. They show that SYN flooding has no real effect on system load, unless some seriously insane logging is going on.

NOTES: The victim had a screensaver running during these tests. My TCP SYN queue on the victim box is set to 256, so when it's at 256 it's at denial-of-service (TCP SYN cookies weren't enabled during these tests). The service I attacked was SSH (22/TCP).

Quote:

Originally Posted by chort (Post 3433227)

Thanks for the tip, I'll check it out once I am able to.

WOW! You went from less than a megabyte to 18-19mb within 3 minutes.

Excellent demonstration...I don't know if it can be explained any better than that.

quite a big difference in the attack with the logs enabled though. 2.17 compared to 0.00.

So theres definately an increase. Maybe it was one of my mod_rewrites that was causing a loop.

I forgot to mention..my site that was being attacked was a vBulletin forum (latest version) with vbSEO installed.

Quote:

Originally Posted by mike2010 (Post 3433269)

Im not sure what to look into, but here it is.

Obviously there's no logging enabled there.

I think the answer from tech support explains the attack perfectly. In fact, yesterday while I was watching an IT humor video on YouTube I found a bunch of videos of kids running DoS scripts against various forum software.

I'm sure a lot of that forum software is badly written and it's not too difficult to figure out which operations are expensive and will cause the server to do a lot of work for a relatively inexpensive request from a malicious client.

you seem pretty cool and know your stuff.

Is there a popular free site / program out there that can do a Load Test and Security Scan on my site ?

I just tried a free trial of Alertsite and canceled immediately before even getting the scan results. They automatically charge you after 30 day free trial...even if no credit card is on file. Stay away..

I usually use Nessus for quick & dirty security audits. If you run it against your own site, go ahead and use the "dangerous" tests (the ones that might crash the server) for maximum discovery. The results aren't perfect, because it only tests for well-known attacks, and they aren't always accurate because a lot of them simply compare version strings. Most OS vendors back-port security patches to earlier versions of software, so even if you have version 3.4.5 and the security fix didn't appear until 3.6.0, a lot of times your version will have the patch if you've been running updates. On the other hand, 3rd party forum software probably doesn't get updated with your OS, so that you would have to monitor manually and upgrade to new versions as they're released.

Using software written by amateurs is risky for this reason, and there's no fool-proof way to audit it. Large corporations spend tens to hundreds of thousands of dollars on outside auditors to pen-test their systems with targeted and many times home-grown attacks. There's no way you can get that level of assurance without spending that kind of money, so you're left with automated tools that are far less than perfect.

Quote:

Originally Posted by chort (Post 3434975)

Thanks for the recommendation..I installed the Vista version on my PC yesterday.

Nessus 3.2.1.1 is what came with the free download yesterday. How could there even be a 3.6.0? Do I have to purchase for that version or something?

The only 2 scan policies I see available on the Nessus Client are
"Default Scan Policy" and
"Microsoft Patches"

the "dangerous" tests sound interesting..how could I get?

Quote:

Originally Posted by mike2010 (Post 3435841)

Nessus 3.2.1.1 is what came with the free download yesterday. How could there even be a 3.6.0?

The version numbers he used were refering to a hypothetical situation. They were the hypothetical version numbers of an application which you were scanning with Nessus, not the version numbers of Nessus itself. You are good to go.

But how do I get the "Dangerous" tests ?

I'd like to point out in a friendly way that this forum is called Linux Security, ergo talk of purchasing certain software, mentioning mcrsft vst installs, questions about "mcrsft ptchs" and anything mcrsft basically is not suited for this forum. If this thread no longer has a link to Linux Security, may I suggest creating a new thread in /General?