James, On 05/20/2011 05:15 PM, James Babiak wrote: > True. But no one ever said that this would be a perfect solution and you > can assume you would be invulnerable to attack.
I was just explaining that your solution is fine for one type of attack. But there are more and you are not protected. > It's the same way with > any protection mechanism. Even the best firewalls and IDSs, properly > configured, won't stop a very skilled and dedicated attacker. Absolutely. You need to be quite skilled to get a security concept done and executed properly. > But it > will eliminate a lot of the chaff and drivebys. A home security system > is a perfect analogy. Is ADT going to stop a professional burgler? No. > But will it deter some kid who wants to break in just to steal some > stuff to pawn for drugs? Probably. They'll try the house next door > without any protection. Yes, it's like with spammers: they send you tons of stuff and don't care if you have a great anti-spam solution in place. It's about masses and hit rates. VoIP exploit tools are there, script kiddies are there. Set up a SIP honeypot and you'll wonder what kind of attacks you'll see. > This is beneficial for two reasons. First, obviously, it eliminates a > lot of the blind (script kiddie type) attacks that could possible find > and exploit some vulnerablity. Well, but just for this type of attack where you are 'protected' now against. You overlook other types of attacks. Scripts are available, script kiddies too. Toll fraud can be of course the worst problem, especially in 'home user' scenarios. If you loose money in this way, it can be very bad. On the other hand if your phone system is out of service (due to a successful attack) it might be bad, but probably not as bad as a huge phone bill. For an organization it is both: if there is toll fraud and the phone bill is huge, the organization might be unable to pay the bill and go bankrupt. But if the phone system is down for some time(because of i.e. a DoS attack on application level), the organization might also be in big trouble (depending on the business they are in). > And secondly, it cuts down on the > security log data, so if you are actively monitoring what's going on and > you see something get through, it will be more likely to raise red flags > and be investigated manually. If you have to examine hundreds of pages > of logs every day, mostly filled with crap, it's highly likely that you > would inadvertantly miss something that should be acted upon. But if you > eliminate the clutter, the serious items will stand out. Absolutely, it's all about designing a good SIP Security Defense system. Regards, Ingmar > -James > > On Fri, May 20, 2011 at 3:13 AM, Ingmar Schraub <[email protected] > <mailto:[email protected]>> wrote: > > James, > > of course if the attacks don't change and you are seeing only always the > same pattern, you should be fine - for now. But I would not lean back > and relax because you have somehow mastered this challenge. The world > changes and SIP attacks are now more and more advancing. > > Regards, > > Ingmar > > On 05/19/2011 10:18 PM, James Babiak wrote: > > Ingmar, > > > > You raise some valid points. However the vast majority of SIP-based > > attacks is for toll-fraud. I was getting hit with at least one a day, > > and somedays 4-5. The scans were very straighforward and not trying to > > implement any advanced circumvention tactics (like using varying > spoofed > > source IPs). So by blacklisting the IPs where the traffic was coming > > from, I've been able to dramatically decrease the number and > duration of > > the attacks. The latter being a single attempt. > > > > Lonnie's implementation of my blacklisting dialplan snippit into the > > Adaptive-Ban plugin already takes your concerns into account. You can > > easily specify whitelisted IP addresses that won't be banned. Such as > > your SIP trunk provider(s) or other PBXs. This eliminates the concern > > that an attack with inside knowledge could use your protection > mechanism > > against you. > > > > Yes it's not a perfect solution to eliminate 100% of attacks, but it > > will eliminate 99% of them. And the other 1% is going to get through > > almost anything you put together on an open system. > > > > And it's simply an option. If you don't want to enable it, you don't > > have to. Personally, I find (and have found) it very useful. > > > > -James > > > > On Thu, May 19, 2011 at 4:05 PM, Ingmar Schraub <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > The problem with SIP over UDP is that you can flood > destinations with > > random source IPs. Send out tons of INVITEs to let phones ring > which are > > registered with a PBX is a common type of attack. Do you > really want to > > block all those source IP addresses? The answer is 'no'. It simply > > doesn't > > make sense. > > > > UDP is a bad protocol for SIP signaling in terms of security. > It's a > > known > > fact that it is hard & very difficult to fight against UDP > attacks. > > If the > > attacker is not aiming for i.e. toll fraud but just for DoS (on > > application > > level) there is little you can do. > > > > Blacklisting/banning can be also dangerous. Let's assume the > > attacker uses > > as source IP the address of your SIP trunk provider. Do you really > > want to > > blacklist this address? Certainly not! The only real > protection is to > > switch completely to TCP (which includes SIP over TLS) and > apply proper > > security controls here. > > > > Regards, > > > > Ingamr > > > > On Thu, 19 May 2011 14:13:03 -0500, Lonnie Abelbeck > > <[email protected] <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > > James, > > > > > > Excellent testing, much appreciated... > > > > > > In summary, it appears adding support for: > > > -- > > > ; For Asterisk 1.4 > > > exten => s,n,Set(BANIP=${SIPCHANINFO(recvip)}) > > > exten => s,n,Log(NOTICE,\'${BANIP}\' - Dialplan Noted > Suspicious IP > > > Address) > > > > > > ; For Asterisk 1.6/1.8 > > > exten => s,n,Set(BANIP=${CHANNEL(recvip)}) > > > exten => s,n,Log(NOTICE,'${BANIP}' - Dialplan Noted > Suspicious IP > > Address) > > > -- > > > in the Adaptive-Ban plugin seems useful. I will do that. > (a one line > > > addition :-) ) > > > > > > It appears the asterisk functions SIPCHANINFO()/CHANNEL() > are the best > > > tools we have to determine the SIP source IP address via the > dialplan, > > > while not always perfect, it is quite useful for this > application. > > The > > > Adaptive-ban ADAPTIVE_BAN_WHITELIST and > > ADAPTIVE_BAN_WHITELIST_INTERNAL=1 > > > should take care of problematic spoofed IP's. > > > > > > Thanks for planting the seed for this feature. > > > > > > Lonnie > > > > > > > > > > > > On May 19, 2011, at 12:13 PM, James Babiak wrote: > > > > > >> Lonnie, > > >> > > >> Yeah I have persistent logging enabled. I also changed the 10MB > > default > > >> down to 2MB to help with keeping the processing of the log > file down. > > The > > >> (complex) sed call is what was spiking the system load up > very high > > when > > >> the log files were close to 10MB. I would agree with making the > > syslogd > > >> options exposed to be tweaked by users through the GUI. > > >> > > >> I like the SIPCHANINFO/CHANNEL variable use better. It > seems to more > > >> accurately acquire the true IP address of the attacker. As I > > mentioned > > >> before, while it would cut down tremendously on scans, I would > > see the > > >> occasional false positive in my bans. Things such as my own > IP or > > >> 127.0.0.1 or a NAT'd address. Using your variable, in my > own testing, > > >> seems to alleviate *some* of that. > > >> > > >> When calling from a NAT'd phone, it used to pull the NAT > IP, but now > > >> will pull the public one, which is good. But when I was > using sipp to > > try > > >> and spoof my IP to see the effect, I noticed some strange > behavior... > > >> > > >> The first few attempts would show up as: > > >> -- Executing [service@from-pstn-unknown:6] > > Set("SIP/5060-000003a1", > > >> "BANIP=127.0.1.1") in new stack > > >> -- Executing [service@from-pstn-unknown:7] > > NoOp("SIP/5060-000003a1", > > >> "IP is 127.0.1.1") in new stack > > >> -- Executing [service@from-pstn-unknown:8] > > >> System("SIP/5060-000003a1", "echo 127.0.1.1 >> > > /mnt/kd/banlist") in > > >> new stack > > >> using the SIPCHANINFO(recvip) variable. I wasn't even > specifying any > > >> special IP, just running it against my box. > > >> > > >> The invite looked like this: > > >> --==-- > > >> <--- SIP read from 72.64.129.130:1316 > <http://72.64.129.130:1316> <http://72.64.129.130:1316> > > ---> > > >> INVITE sip:[email protected]:5060 > <http://sip:[email protected]:5060> > > <http://sip:[email protected]:5060> SIP/2.0 > > >> Via: SIP/2.0/UDP 127.0.1.1:5060;branch=z9hG4bK-9481-1-0 > > >> From: sipp <sip:[email protected]:5060 > <http://sip:[email protected]:5060> > > <http://sip:[email protected]:5060>>;tag=9481SIPpTag001 > > >> To: sut <sip:[email protected]:5060 > <http://sip:[email protected]:5060> > > <http://sip:[email protected]:5060>> > > >> Call-ID: [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > >> CSeq: 1 INVITE > > >> Contact: sip:[email protected]:5060 > <http://sip:[email protected]:5060> <http://sip:[email protected]:5060> > > >> Max-Forwards: 70 > > >> Subject: Performance Test > > >> Content-Type: application/sdp > > >> Content-Length: 129 > > >> > > >> v=0 > > >> o=user1 53655765 2353687637 IN IP4 127.0.1.1 > > >> s=- > > >> c=IN IP4 127.0.1.1 > > >> t=0 0 > > >> m=audio 6000 RTP/AVP 0 > > >> a=rtpmap:0 PCMU/8000 > > >> --==-- > > >> > > >> Which is identical to the way my NAT'd phone's invite > looked. The > > only > > >> difference is that the BANIP for my phone was it's public > address, > > >> whereas the BANIP for the sipp call above was 127.0.1.1. > Seems weird. > > >> > > >> Even weirder, when I used sipp to launch ten calls at once, > the first > > >> two showed up as 127.0.1.1, the rest showed up as my public > IP. This > > was > > >> using simply "./sipp [host". I wonder if this is some kind > of bug? > > >> > > >> When changing the from/contact/etc. sip headers manually, > it doesn't > > >> seem to have any affect, and sets the correct SRC IP for the > > variable. > > I > > >> assume changing the IP header would allow you to pass the > variable a > > >> spoofed result, which in turn could be used as a form of > DoS attack. > > >> > > >> -James > > >> > > >> On Wed, May 18, 2011 at 7:02 PM, Lonnie Abelbeck > > >> <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > >> James, > > >> > > >> By default "syslogd -s 1024 -m 60 -b 2" /var/log/messages > are rotated > > at > > >> 1MB. Note that if the syslog is rotated the pre-existing > ban'ed > > IP are > > >> not removed, unless the box is rebooted or the firewall is > restarted. > > I > > >> have only seen minor effects on a net5501 under these > conditions. A > > >> single (albeit complex) 'sed' call does the grunt-work in the > > >> adaptive-ban plugin. > > >> > > >> If PERSISTLOG = yes, then the logs are rotated at 10MB (and > on slow > > >> flash instead of RAM) this could become slow. I never set > > PERSISTLOG. > > >> Possibly we need more control of the syslogd options with > > PERSISTLOG = > > >> yes . > > >> > > >> Michael and I have been playing around with the idea > (spawned by you) > > of > > >> generating a Log() for the adaptive-ban plugin to catch. > To get > > the IP > > >> address we found a better method: > > >> -- > > >> ; For Asterisk 1.4 > > >> exten => s,n,Set(BANIP=${SIPCHANINFO(recvip)}) > > >> exten => s,n,Log(NOTICE,\'${BANIP}\' - Dialplan Noted > Suspicious IP > > >> Address) > > >> > > >> ; For Asterisk 1.6/1.8 > > >> exten => s,n,Set(BANIP=${CHANNEL(recvip)}) > > >> exten => s,n,Log(NOTICE,'${BANIP}' - Dialplan Noted > Suspicious IP > > >> Address) > > >> -- > > >> > > >> A question for anyone, is the BANIP value above spoof-able? > > >> > > >> Lonnie > > >> > > >> > > >> > > >> On May 18, 2011, at 5:23 PM, James Babiak wrote: > > >> > > >> > Lonnie, > > >> > > > >> > Good idea, never thought about doing it that way. > > >> > > > >> > I would still personally want to keep track of them in some > > persistent > > >> > file though to be reloaded on reboots. > > >> > > > >> > I also noticed that when my log files get large (>5MBs), the > > adaptive > > >> > ban script seems to require large amounts of processing > power. I > > >> > noticed the other day where my load level was spiking > close to 1. > > When > > >> > I disabled the plugin, or started rotating my logs at > 2MBs, it > > dropped > > >> > dramatically. Have you had similar issues? > > >> > > > >> > Many attackers will actually try to place the call > attempts using > > your > > >> > own IP address, so I need to add the ability for it to > filter out > > those > > >> > IPs, otherwise it will put invalid entries into the > banned list. It > > >> > doesn't actually cause any negative side effects (outside > of extra > > >> > useless entries), but it also doesn't block the traffic. > > >> > > > >> > -James > > >> > > > >> > On Tue, May 17, 2011 at 8:08 PM, Lonnie Abelbeck > > >> > <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > > wrote: > > >> > James, > > >> > > > >> > Very clever! > > >> > > > >> > It probably is a little too convoluted, but if the dialplan > > contained: > > >> > -- > > >> > exten => _.,n,Set(BLKIP1=${CUT(CHANNEL,\/,2)}) > > >> > exten => _.,n,Set(BLKIP2=${CUT(BLKIP1,\-,1)}) > > >> > exten => _.,n,Log(NOTICE,\'${BLKIP2}\' - Dialplan Ban IP > Address) > > >> > -- > > >> > it would generate the log > > >> > -- > > >> > May 17 18:55:14 pbx local0.notice asterisk[30186]: > NOTICE[30186]: > > Ext. > > >> > s:5 in @ default: '10.10.50.1' - Dialplan Ban IP Address > > >> > -- > > >> > Then the AIF adaptive-ban plugin could be tweaked to have > > support for > > >> > that forced syslog string. > > >> > > > >> > Lonnie > > >> > > > >> > > > >> > On May 17, 2011, at 2:14 PM, James Babiak wrote: > > >> > > > >> > > I too was getting scanned a lot. My system is locked > down, so I > > >> > > wasn't really worried about tollfraud, but it would fill up > > my logs > > >> > > and CDRs which got annoying. > > >> > > > > >> > > I wanted to still be able to accept certain unauthenticated > > inbound > > >> > > calls (conf@ and james@, etc.), so I couldn't disable them > > >> > > altogether. So I put together this little dialplan > entry as a > > last > > >> > > resort in my incoming context: > > >> > > > > >> > > ; Don't accept any calls not identified above > > >> > > exten => _.,1,Progress() > > >> > > exten => _.,n,Set(CDR(userfield)=${EXTEN}) > > >> > > exten => _.,n,Wait(1) > > >> > > exten => _.,n,Answer() > > >> > > exten => _.,n,Set(BLKIP1=${CUT(CHANNEL,\/,2)}) > > >> > > exten => _.,n,Set(BLKIP2=${CUT(BLKIP1,\-,1)}) > > >> > > exten => _.,n,Noop(BLOCKING ALL VOIP TRAFFIC FROM > ${BLKIP2}) > > >> > > exten => _.,n,System(echo ${BLKIP2} >> /mnt/kd/banlist) > > >> > > exten => _.,n,System(iptables -A ADAPTIVE_BAN_CHAIN -p > udp -s > > >> > > ${BLKIP2} -j ADAPTIVE_BAN_DROP_CHAIN) > > >> > > exten => _.,n,Zapateller() > > >> > > exten => _.,n,Playback(the-number-u-dialed) > > >> > > exten => _.,n,SayDigits(${EXTEN}) > > >> > > exten => > > _.,n,Playback(has-been-disconnected&or&no-longer-in-service) > > >> > > exten => _.,n,Playback(check-number-dial-again) > > >> > > exten => _.,n,Congestion(5) > > >> > > exten => _.,n,Hangup() > > >> > > > > >> > > It will echo the IP address into a persistent banlist > (which gets > > >> > > reimplemented on a reboot), and then adds an iptables > rule to > > block > > >> > > any more udp traffic from that host. So if someone > tries to scan > > me, > > >> > > the first attempt will be accepted and logged, but any > future > > >> > > attempts will be blocked. > > >> > > > > >> > > Has helped tremendously! > > >> > > > > >> > > And I use the adaptive ban plug-in for sshd and > asterisk user > > >> > > account scans. > > >> > > > > >> > > -James > > >> > > > > >> > > On Thu, Apr 28, 2011 at 9:19 AM, Lonnie Abelbeck > > >> > > <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > >> > > > > >> > > On Apr 28, 2011, at 7:27 AM, Ingmar Schraub wrote: > > >> > > > > >> > > > On 04/28/2011 01:06 PM, Joss Giffard wrote: > > >> > > >> Hi, > > >> > > >> > > >> > > >> I recently updated our asterisk system to astlinux 0.7.7 > > whilst > > >> > > >> moving > > >> > > >> to a new SIP trunk provider. Everything seems to be > up and > > running > > >> > > >> correctly apart from the fact that very occasionally > each > > of the > > >> > > >> VoIP > > >> > > >> phones will receive an incoming call from 'asterisk' > that once > > >> > > >> answered > > >> > > >> is simply silence... I was wondering if anyone else has > > >> > > >> experienced > > >> > > >> anything similar or has any idea what would be causing > > this (or > > >> > > >> indeed > > >> > > >> how to cure it). The phones themselves are all > Grandstream > > >> > > >> GXP2000s. > > >> > > > > > >> > > > Looks like SIP scanning/spamming/toll fraud attack. > You could > > >> > > > tweak your > > >> > > > Asterisk configuration to not allow any other > un-authenticated > > >> > > > inbound > > >> > > > calls than from your SIP trunk provider and/or add > some further > > >> > > > security > > >> > > > controls to prevent such things. > > >> > > > > > >> > > > Here is a report from someone who had a similar > experience: > > >> > > > > > >> > > > > > > > http://www.fonality.com/trixbox/forums/trixbox-forums/open-discussion/blank-call-caller-id-asterisk > > >> > > > > > >> > > > There are also some ideas on how to block such calls. > Some are > > >> > > > good, > > >> > > > some may not make sense to everyone. > > >> > > > > > >> > > > Regards, > > >> > > > > > >> > > > Ingmar > > >> > > > > >> > > I agree with Ingmar, additionally if you are using Asterisk > > 1.4 you > > >> > > might want to set: > > >> > > -- > > >> > > alwaysauthreject=yes > > >> > > -- > > >> > > (Asterisk 1.8 defaults to yes) to reduce the amount of > > information > > >> > > to the scanner. > > >> > > > > >> > > You may also want to enable the Adaptive Ban plugin: > > >> > > > > >> > > Network Tab -> Firewall Plugins: [ adaptive-ban ] > > >> > > > > >> > > set to ENABLED=1 via the { Configure Plugin } button, > adjust any > > >> > > options and "Restart Firewall" to apply. > > >> > > > > >> > > The Adaptive Ban firewall plugin operates on the same > > principle as > > >> > > Fail2Ban, automatically blocking IP addresses that generate > > errors > > in > > >> > > the logs over a pre-defined threshold. > > >> > > > > >> > > Lonnie > > >> > > > > >> > > > > >> > > > > >> > > > > > > ------------------------------------------------------------------------------ > > >> > > WhatsUp Gold - Download Free Network Management Software > > >> > > The most intuitive, comprehensive, and cost-effective > network > > >> > > management toolset available today. Delivers lowest > initial > > >> > > acquisition cost and overall TCO of any competing solution. > > >> > > http://p.sf.net/sfu/whatsupgold-sd > > >> > > _______________________________________________ > > >> > > Astlinux-users mailing list > > >> > > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > >> > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > >> > > > > >> > > Donations to support AstLinux are graciously accepted via > > PayPal to > > >> > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>. > > >> > > > > >> > > > > > > ------------------------------------------------------------------------------ > > >> > > Achieve unprecedented app performance and reliability > > >> > > What every C/C++ and Fortran developer should know. > > >> > > Learn how Intel has extended the reach of its > next-generation > > tools > > >> > > to help boost performance applications - inlcuding > clusters. > > >> > > > > > > http://p.sf.net/sfu/intel-dev2devmay_______________________________________________ > > >> > > Astlinux-users mailing list > > >> > > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > >> > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > >> > > > > >> > > Donations to support AstLinux are graciously accepted via > > PayPal to > > >> > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>. > > >> > > > >> > > > >> > > > > > ------------------------------------------------------------------------------ > > >> > What Every C/C++ and Fortran developer Should Know! > > >> > Read this article and learn how Intel has extended the > reach of its > > >> > next-generation tools to help Windows* and Linux* C/C++ > and Fortran > > >> > developers boost performance applications - including > clusters. > > >> > http://p.sf.net/sfu/intel-dev2devmay > > >> > _______________________________________________ > > >> > Astlinux-users mailing list > > >> > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > >> > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > >> > > > >> > Donations to support AstLinux are graciously accepted via > PayPal to > > >> > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>. > > >> > > > >> > > > > > ------------------------------------------------------------------------------ > > >> > What Every C/C++ and Fortran developer Should Know! > > >> > Read this article and learn how Intel has extended the > reach of its > > >> > next-generation tools to help Windows* and Linux* C/C++ > and Fortran > > >> > developers boost performance applications - including > clusters. > > >> > > > > > http://p.sf.net/sfu/intel-dev2devmay_______________________________________________ > > >> > Astlinux-users mailing list > > >> > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > >> > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > >> > > > >> > Donations to support AstLinux are graciously accepted via > PayPal to > > >> > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>. > > >> > > >> > > >> > > > > ------------------------------------------------------------------------------ > > >> What Every C/C++ and Fortran developer Should Know! > > >> Read this article and learn how Intel has extended the > reach of its > > >> next-generation tools to help Windows* and Linux* C/C++ and > Fortran > > >> developers boost performance applications - including clusters. > > >> http://p.sf.net/sfu/intel-dev2devmay > > >> _______________________________________________ > > >> Astlinux-users mailing list > > >> [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > >> https://lists.sourceforge.net/lists/listinfo/astlinux-users > > >> > > >> Donations to support AstLinux are graciously accepted via > PayPal to > > >> [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>. > > >> > > >> > > > > ------------------------------------------------------------------------------ > > >> What Every C/C++ and Fortran developer Should Know! > > >> Read this article and learn how Intel has extended the > reach of its > > >> next-generation tools to help Windows* and Linux* C/C++ and > Fortran > > >> developers boost performance applications - including clusters. > > >> > > > > http://p.sf.net/sfu/intel-dev2devmay_______________________________________________ > > >> Astlinux-users mailing list > > >> [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > >> https://lists.sourceforge.net/lists/listinfo/astlinux-users > > >> > > >> Donations to support AstLinux are graciously accepted via > PayPal to > > >> [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>. > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > What Every C/C++ and Fortran developer Should Know! > > > Read this article and learn how Intel has extended the reach > of its > > > next-generation tools to help Windows* and Linux* C/C++ and > Fortran > > > developers boost performance applications - including clusters. > > > http://p.sf.net/sfu/intel-dev2devmay > > > _______________________________________________ > > > Astlinux-users mailing list > > > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > > > Donations to support AstLinux are graciously accepted via > PayPal to > > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>. > > > > > > ------------------------------------------------------------------------------ > > What Every C/C++ and Fortran developer Should Know! > > Read this article and learn how Intel has extended the reach > of its > > next-generation tools to help Windows* and Linux* C/C++ and > Fortran > > developers boost performance applications - including clusters. > > http://p.sf.net/sfu/intel-dev2devmay > > _______________________________________________ > > Astlinux-users mailing list > > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via > PayPal to > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>. > > > > > > > > > > > > ------------------------------------------------------------------------------ > > What Every C/C++ and Fortran developer Should Know! > > Read this article and learn how Intel has extended the reach of its > > next-generation tools to help Windows* and Linux* C/C++ and Fortran > > developers boost performance applications - including clusters. > > http://p.sf.net/sfu/intel-dev2devmay > > > > > > > > _______________________________________________ > > Astlinux-users mailing list > > [email protected] > <mailto:[email protected]> > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via PayPal > to [email protected] <mailto:[email protected]>. > > > ------------------------------------------------------------------------------ > What Every C/C++ and Fortran developer Should Know! > Read this article and learn how Intel has extended the reach of its > next-generation tools to help Windows* and Linux* C/C++ and Fortran > developers boost performance applications - including clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Astlinux-users mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > [email protected] <mailto:[email protected]>. > > > > > ------------------------------------------------------------------------------ > What Every C/C++ and Fortran developer Should Know! > Read this article and learn how Intel has extended the reach of its > next-generation tools to help Windows* and Linux* C/C++ and Fortran > developers boost performance applications - including clusters. > http://p.sf.net/sfu/intel-dev2devmay > > > > _______________________________________________ > Astlinux-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > [email protected]. ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Astlinux-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to [email protected].
