Blogroll

Have faith and stem the flood of SYNers

In my previous post I showed what a SYN flood and SYN scan was. The ability to determine open ports rather silently and not trigger alarms may have raised the eyebrows of some. I mentioned that Stateful Packet Inspection and Firewalls can stop this. Certain logging applications can alarm on SYN and SYN/ACK without an ACK.

Queue holy music and the clouds parting. Today I will deploy some protection with the SRX110. So without a screen this is what happens when I launch a SYN scan against my SRX. Time to fight back.

As you can see you can see the service that is running on it. Good old SSH. Well I don’t want people to just scan my untrusted interface and decipher what is running. I am going to ensure that I can control the amount of information I give up freely. I am not going down without a fight.

The following screen can be put in place. I have applied it to my untrust security zone.

telaranrhiod:~ pandom$ sudo nmap -sS 192.168.1.200
Password:
Starting Nmap 6.25 ( http://nmap.org ) at 2012-12-21 09:45 EST
Nmap scan report for 192.168.1.200
Host is up (0.0041s latency).
Not shown: 792 filtered ports
PORT STATE SERVICE
4/tcp open unknown
7/tcp open echo
9/tcp open discard
22/tcp open ssh
32/tcp open unknown
37/tcp open time
43/tcp open whois
70/tcp open gopher
89/tcp open su-mit-tg
161/tcp open snmp
254/tcp open unknown
264/tcp open bgmp
301/tcp open unknown
407/tcp open timbuktu
417/tcp open onmux
512/tcp open exec
544/tcp open kshell
545/tcp open ekshell
631/tcp open ipp
666/tcp open doom
668/tcp open mecomm
687/tcp open asipregistry
691/tcp open resvc
705/tcp open agentx
714/tcp open iris-xpcs
720/tcp open unknown
722/tcp open unknown
783/tcp open spamassassin
900/tcp open omginitialrefs
1021/tcp open exp1
1022/tcp open exp2
1028/tcp open unknown
1031/tcp open iad2
1033/tcp open netinfo
1034/tcp open zincite-a
1036/tcp open nsstp
1040/tcp open netsaint
1042/tcp open afrog
1045/tcp open fpitp
1049/tcp open td-postman
1052/tcp open ddt
1056/tcp open vfo
1062/tcp open veracity
1065/tcp open syscomlan
1067/tcp open instl_boots
1068/tcp open instl_bootc
1071/tcp open bsquare-voip
1082/tcp open amt-esd-prot
1084/tcp open ansoft-lm-2
1090/tcp open ff-fms
1121/tcp open rmpp
1124/tcp open hpvmmcontrol
1151/tcp open unizensus
1187/tcp open alias
1199/tcp open dmidi
1213/tcp open mpc-lifenet
1236/tcp open bvcontrol
1272/tcp open cspmlockmgr
1461/tcp open ibm_wrless_lan
1521/tcp open oracle
1580/tcp open tn-tl-r1
1583/tcp open simbaexpress
1700/tcp open mps-raft
1717/tcp open fj-hdnet
1719/tcp open h323gatestat
1721/tcp open caicci
1801/tcp open msmq
1812/tcp open radius
1862/tcp open mysql-cm-agent
1863/tcp open msnp
1900/tcp open upnp
1914/tcp open elm-momentum
1974/tcp open drp
1999/tcp open tcp-id-port
2000/tcp open cisco-sccp
2010/tcp open search
2020/tcp open xinupageserver
2035/tcp open imsldoc
2045/tcp open cdfunc
2046/tcp open sdfunc
2048/tcp open dls-monitor
2068/tcp open advocentkvm
2100/tcp open amiganetfs
2103/tcp open zephyr-clt
2107/tcp open msmq-mgmt
2179/tcp open vmrdp
2190/tcp open tivoconnect
2288/tcp open netml
2366/tcp open qip-login
2710/tcp open sso-service
2875/tcp open dxmessagebase2
2910/tcp open tdaccess
2968/tcp open enpp
3005/tcp open deslogin
3017/tcp open event_listener
3077/tcp open orbix-loc-ssl
3128/tcp open squid-http
3211/tcp open avsecuremgmt
3300/tcp open unknown
3323/tcp open active-net
3372/tcp open msdtc
3390/tcp open dsc
3690/tcp open svn
3784/tcp open bfd-control
3827/tcp open netmpi
3871/tcp open avocent-adsap
3878/tcp open fotogcad
3889/tcp open dandv-tester
3945/tcp open emcads
4002/tcp open mlchat-proxy
4126/tcp open ddrepl
4279/tcp open vrml-multi-use
4444/tcp open krb524
4445/tcp open upnotifyp
4446/tcp open n1-fwp
4567/tcp open tram
4899/tcp open radmin
5000/tcp open upnp
5001/tcp open commplex-link
5003/tcp open filemaker
5009/tcp open airport-admin
5054/tcp open rlm-admin
5087/tcp open unknown
5200/tcp open targus-getdata
5214/tcp open unknown
5226/tcp open hp-status
5405/tcp open pcduo
5431/tcp open park-agent
5500/tcp open hotline
5550/tcp open sdadmind
5560/tcp open isqlplus
5631/tcp open pcanywheredata
5633/tcp open beorl
5678/tcp open rrac
5801/tcp open vnc-http-1
5859/tcp open wherehoo
5862/tcp open unknown
6004/tcp open X11:4
6006/tcp open X11:6
6100/tcp open synchronet-db
6123/tcp open backup-express
6510/tcp open mcer-port
6580/tcp open parsec-master
6646/tcp open unknown
6667/tcp open irc
6692/tcp open unknown
6788/tcp open smc-http
7004/tcp open afs3-kaserver
7103/tcp open unknown
7106/tcp open unknown
7201/tcp open dlip
7443/tcp open oracleas-https
7741/tcp open scriptview
7800/tcp open asr
7938/tcp open lgtomapper
8011/tcp open unknown
8021/tcp open ftp-proxy
8022/tcp open oa-system
8081/tcp open blackice-icecap
8085/tcp open unknown
8090/tcp open unknown
8222/tcp open unknown
8333/tcp open unknown
8443/tcp open https-alt
8701/tcp open unknown
8899/tcp open ospf-lite
8994/tcp open unknown
9050/tcp open tor-socks
9080/tcp open glrpc
9207/tcp open wap-vcal-s
9290/tcp open unknown
9418/tcp open git
9502/tcp open unknown
9535/tcp open man
9593/tcp open cba8
9618/tcp open condor
9929/tcp open nping-echo
10012/tcp open unknown
10566/tcp open unknown
11111/tcp open vce
13782/tcp open netbackup
15004/tcp open unknown
15742/tcp open unknown
16080/tcp open osxwebadmin
16992/tcp open amt-soap-http
19283/tcp open keysrvr
19350/tcp open unknown
19842/tcp open unknown
20222/tcp open ipulse-ics
24800/tcp open unknown
25735/tcp open unknown
27353/tcp open unknown
27715/tcp open unknown
30000/tcp open unknown
30951/tcp open unknown
31038/tcp open unknown
32769/tcp open filenet-rpc
32777/tcp open sometimes-rpc17
34573/tcp open unknown
35500/tcp open unknown
48080/tcp open unknown
49154/tcp open unknown
49400/tcp open compaqdiag
51103/tcp open unknown
52848/tcp open unknown
54045/tcp open unknown
56737/tcp open unknown
65129/tcp open unknown
MAC Address: B0:A8:6E:66:E2:00 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 34.67 seconds
telaranrhiod:~ pandom$

Phwoar. Look at all the breadcrumbs and honeypots. If that was the response I got from a scan I’d be shaking my head. Where to start? What vulnerability to address? For an attacker, the return on investment is money vs time. How much money will they get for the time they spend attacking? The results above will slow an attacker down. Remember though, this is NOT the only way to discover ports. This may be the quietest way but certainly not the only way.

Above output shows 13377 hits of SYN SYN/ACK without an ACK have occurred on the untrust screen. Verification is important but also Controlling options is paramount. You must remember that understanding what traverses your network is critical to understanding security risks and mitigating them.

A security engineer must consider that illegitimate TCP SYN requests en masse constitutes a denial of service attack. To accurately control traffic without dropping legitimate TCP sessions an understanding of expected TCP session is important.

The SRX has many options to control SYN floods under the screens particular option. They range from source and destination to attack thresholds. It is important to understand the difference. Source and Destination thresholds can be very bad. They will drop any TCP session, legitimate or illegitimate, once the threshold is reached. The difference between Source and Destination and attack thresholds is the following. An attack threshold, once reached, will proxy SYN-ACK replies to SYN requests to an attempt to determine legitimate TCP connections.

Now let us look at the system defaults before we go change stuff. Juniper has applied these defaults for the SRX110. These change per platform.

The commands above put limits on packets per second. If they need to be tweaked that can be done like below. If you are worried about half-open sessions filling up your firewalls connection table then reduce the timeout period from the default of 20 to 10.

I cannot stress enough the importance of understanding the traffic flows and baseline information when adjusting the SYN thresholds on source and destination. Simple deployment for effective results. If you are not careful, it could be too effective. After all, a SYN flood won’t occur if you have a crippled network segment due to aggressive thresholds.

Related

Post navigation

4 thoughts on “Have faith and stem the flood of SYNers”

I noted on twitter to use a CP filter as the initial part of your post mentioned “Well I don’t want people to just scan my untrusted interface and decipher what is running”

You would construct a CP filter in which only trusted source IP ranges were allowed in on certain protocols on the untrusted interface. i.e. you would only allow inbound SSH from a trusted source IP range. Hence if someone scanned on your untrusted interface from a range not in your trusted source, they would never even know that port was open.

In fact your CP filter should be constructed so that only known legitimate traffic would ever come inbound. Anyone scanning your interface would only see legitimate services responding to them. Of course nothing really should be open to them.

Of course transit traffic is handled differently. The above is only for services running and responding on the firewall itself.

The great thing about junos as well is that it allows you to use something called apply-paths which pulls IP addresses directly from other parts of the configuration. As an example on my edge Junipers I have an apply-path statement that only allows BGP inbound form an apply-path statement that matched any configured BGP peer. This means the filter automatically allowed a newly configured neighour in, and blocks any peer that I de-configure (is that a word?)

You can of course also police syn packets inbound to the CP. Same as ICMP or any other packet.

But yes, this is all for traffic going to the device itself, but you did mention the statement I noted above so assumed this is what you were blocking 🙂