DoS SMTP

Andrey Nikolaev

19 Jan 2006 19 Jan '06

10:15 a.m.

Hi! тут возникла проблемка, атакуют машинку под freebsd 5.4 smtp service ... адреса атаки рассыпаются, тюнинг фри ограничился этим: net.inet.tcp.msl=7500 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=100 чтото посоветуете ? как можно все таки найти источник? -- andy@cris.net AN1035-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Show replies by date

Oleh Hrynchuk

19 Jan 19 Jan

11:17 a.m.

Доброго дня. Не для Фрюхи, але ідея повинна бути зрозуміла. Див. аттач.

...

-----Original Message----- From: owner-uanog-outgoing@uanog.kiev.ua [mailto:owner-uanog-outgoing@uanog.kiev.ua] On Behalf Of Andrey Nikolaev Sent: Thursday, January 19, 2006 12:16 PM To: uanog@uanog.kiev.ua Subject: [uanog] DoS SMTP

Hi!

тут возникла проблемка, атакуют машинку под freebsd 5.4 smtp service ... адреса атаки рассыпаются, тюнинг фри ограничился этим: net.inet.tcp.msl=7500 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=100

чтото посоветуете ? как можно все таки найти источник?

-- andy@cris.net AN1035-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

vladimir.sharun＠ukr.net

11:31 a.m.

FreeBSD'шный pf умеет делать много всего интересного. Например защита от spoof'а для tcp, защита от syn flood'а туда же. Другое дело что ботнетом могут верифицировать адреса, вот тут да, может быть неприятно. Я в таких случаях включаю спецфильтр, собираю адреса, которые мешают (их обычно до 20к), аггрегирую и в блокировку на балансировщике. А там смотрим по результатам: если счетчик почти не растёт, то фильтры отключаем. Такая система делает DoS наоборот: можно уложить центр управления ботами либо конкретных ботов. Andrey Nikolaev wrote: AN> тут возникла проблемка, атакуют машинку под freebsd 5.4 smtp service ... AN> адреса атаки рассыпаются, тюнинг фри ограничился этим: AN> net.inet.tcp.msl=7500 AN> net.inet.tcp.blackhole=2 AN> net.inet.udp.blackhole=1 AN> net.inet.icmp.icmplim=100 AN> чтото посоветуете ? AN> как можно все таки найти источник? -- UKR.NET Postmaster =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Paul Arakelyan

3:03 p.m.

On Thu, Jan 19, 2006 at 12:15:54PM +0200, Andrey Nikolaev wrote:

...

Hi!

РСР БНГМХЙКЮ ОПНАКЕЛЙЮ, ЮРЮЙСЧР ЛЮЬХМЙС ОНД freebsd 5.4 smtp service ... ЮДПЕЯЮ ЮРЮЙХ ПЮЯЯШОЮЧРЯЪ, РЧМХМЦ ТПХ НЦПЮМХВХКЯЪ ЩРХЛ:

В смысле - "атакуют"? Вагон запросов на "connect"? Или таки ещё что-то прислать пытаются ? Адреса вообще реальные?

...

net.inet.tcp.msl=7500 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=100

-- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Andrey Nikolaev

3:20 p.m.

On 19 Jan 2006 at 05:03:06, Paul Arakelyan wrote:

...

В смысле - "атакуют"? Вагон запросов на "connect"? ага масса SYN пакетов Или таки ещё что-то прислать пытаются ? ничего, сразу обрыв коннекта Адреса вообще реальные? да

...
net.inet.tcp.msl=7500 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=100

-- andy@cris.net AN1035-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

vladimir.sharun＠ukr.net

3:42 p.m.

Andrey Nikolaev wrote:

...

...
В смысле - "атакуют"? Вагон запросов на "connect"?

AN> ага масса SYN пакетов курить man pf.conf на тему synproxy state -- UKR.NET Postmaster =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Dmitry Cherkasov

20 Jan 20 Jan

9:37 a.m.

On Thu, Jan 19, 2006 at 01:17:20PM +0200, Oleh Hrynchuk wrote: OH> OH> Доброго дня. OH> OH> Не для Фрюхи, але ідея повинна бути зрозуміла. OH> Див. аттач. Нормальна ідея, звичайно, але: ... Second, router access must be available. This can be a hurdle both technically (no access to the routers) and politically (the routers are owned by another entity). However, this can be a coordinated effort, with multiple teams handing off the tracing as each autonomous system boundary is crossed. If the trace is done completely within a single AS, however, many of the political and technical issues may not exist. Third, the attack must be of a duration that allows for a trace. Short, bursty attacks may not allow for a full trace. While a partial trace may help to narrow the scope of the search, it will not find the culprit. ... Якщо зловмисник десь поряд, особливих проблем немає. Та чи часто буває таке. Людина добре подумає перед тим, як шкодити своєму ІСП чи його клієнтам.. OH> OH> OH> > -----Original Message----- OH> > From: owner-uanog-outgoing@uanog.kiev.ua OH> > [mailto:owner-uanog-outgoing@uanog.kiev.ua] On Behalf Of OH> > Andrey Nikolaev OH> > Sent: Thursday, January 19, 2006 12:16 PM OH> > To: uanog@uanog.kiev.ua OH> > Subject: [uanog] DoS SMTP OH> > OH> > OH> > Hi! OH> > OH> > тут возникла проблемка, атакуют машинку под freebsd 5.4 smtp OH> > service ... OH> > адреса атаки рассыпаются, тюнинг фри ограничился этим: OH> > net.inet.tcp.msl=7500 OH> > net.inet.tcp.blackhole=2 OH> > net.inet.udp.blackhole=1 OH> > net.inet.icmp.icmplim=100 OH> > OH> > чтото посоветуете ? OH> > как можно все таки найти источник? OH> > OH> > -- OH> > andy@cris.net AN1035-RIPE OH> > =================================================================== OH> > uanog mailing list. OH> > To Unsubscribe: send mail to majordomo@uanog.kiev.ua with OH> > "unsubscribe uanog" in the body of the message OH> Date: Thu, 24 Apr 2003 08:44:23 +0300 OH> From: яНУПЮМЕМНMicrosoftInternetExplorer5 OH> Subject: Tracking Spoofed IP Addresses Version 2.0 OH> OH> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> OH> <HTML><HEAD><TITLE>Tracking Spoofed IP Addresses Version 2.0</TITLE> OH> <META content="text/html; charset=iso-8859-1" http-equiv=Content-Type> OH> <META content="MSHTML 5.00.3504.2500" name=GENERATOR></HEAD> OH> <BODY> OH> <CENTER> OH> <H1>Tracking Spoofed IP Addresses Version 2.0</H1></CENTER> OH> <CENTER> OH> <H3>By Rob Thomas, <A href="mailto:robt@cymru.com">robt@cymru.com</A>, 08 FEB OH> 2001</H3></CENTER> OH> <CENTER>[ <A href="http://www.cymru.com/Documents/index.html">Documents</A> OH> ] [ <A OH> href="http://www.cymru.com/index.html">Home</A> ] OH> <IMG src="http://www.cymru.com/Images/divider.gif"></CENTER> OH> <H2>Introduction</H2>Tracking spoofed IP addresses back to the source can be OH> quite a difficult task. For myriad reasons, such as limited router access, OH> attacks of a short duration, and the manual nature of spoofed address tracking, OH> finding the actual generator of the spoofed packets can be very difficult. For OH> this reason, attackers often use the bogon address ranges, where a bogon address OH> range is any unassigned and likely unrouted (by BGP4 in the Internet) netblock. OH> This includes the RFC1918 addresses as well as a collection of other address OH> spaces, such as 1/8, 169.254/16, and the like. OH> However, with a certain combination of features enabled on a Cisco router, it OH> is possible to determine the source of the spoofed packets. Further, this can be OH> done without the laborious and CPU intensive task of adding ACLs to filter the OH> spoofed packets. The key features are CEF and NetFlow. OH> NOTE: Please be aware that router resources are never infinite. Both OH> CEF and NetFlow require resources from the router, and therefore are not OH> entirely immune to issues. NetFlow exports, in particular, may heavily load both OH> the router and the export interface. Please take the time to test your OH> configuration prior to deploying it in production. OH> While this document details a method for tracking the source of a DDoS attack OH> that utilizes spoofed IP addresses, there are several other documents that OH> detail methods of mitigating DDoS attacks. You can view my <A OH> href="http://www.cymru.com/Documents/secure-ios-template.html">Secure IOS OH> Template</A> and my <A OH> href="http://www.cymru.com/Documents/secure-bgp-template.html">Secure BGP OH> Template</A> to enhance your router and peering security. There are also several OH> efforts currently underway to block DDoS attacks. Here are a few informative OH> links (thanks to John Kristoff for passing these along): OH> Pushback <A OH> href="http://www.research.att.com/~smb/talks/pushback-dodcert.pdf">http://www.research.att.com/~smb/talks/pushback-dodcert.pdf</A> <A OH> href="http://www.aciri.org/floyd/talks/pushback-Nov00.pdf">http://www.aciri.org/floyd/talks/pushback-Nov00.pdf</A> OH> Traceback <A OH> href="http://www.cs.washington.edu/homes/savage/traceback.html">http://www.cs.washington.edu/homes/savage/traceback.html</A> <A OH> href="http://www.research.att.com/lists/ietf-itrace/">http://www.research.att.com/lists/ietf-itrace/</A> OH> CenterTrack <A OH> href="http://www.nanog.org/mtg-9910/ppt/robert/index.htm">http://www.nanog.org/mtg-9910/ppt/robert/index.htm</A> <A OH> href="http://www.us.uu.net/gfx/projects/security/centertrack.pdf">http://www.us.uu.net/gfx/projects/security/centertrack.pdf</A> OH> OH> <H2>Router Configuration</H2>Most high-end Cisco routers on the Internet run OH> either CEF or dCEF. This is because of the large performance gains to be OH> realized with CEF, which stands for Cisco Express Forwarding. CEF has many OH> benefits over fast switching, including a more reliable and sturdy method for OH> building the forwarding table. CEF also offers some security benefits, such as OH> RPF (Reverse Path Forwarding). RPF provides a means of blocking packets that OH> claim to originate from within your network, but present themselves on an OH> external interface. Keep in mind that CEF can be a bit tricky to configure in an OH> environment that has asymmetric data flows. You may wish to review the <A OH> href="http://www.cisco.com/warp/public/cc/pd/iosw/iore/tech/cef_wp.htm">Cisco OH> CEF White Paper</A>. CEF is, therefore, a wise choice for reasons of performance OH> and security. CEF is enabled on a global basis with the command ip cef. To OH> enable dCEF (Distributed CEF), the global command is ip cef distributed. OH> NetFlow provides a means of mapping traffic flows through a router. This can OH> be of great use for capacity planning, statistical analysis of traffic patterns, OH> and security reviews. Here is a sample of the output from NetFlow: OH> <TT>router1#sh ip cache flow</TT> <TT>IP packet size distribution (11319 OH> total packets):</TT> <TT> 1-32 64 OH> 96 128 160 192 224 256 288 320 OH> 352 384 416 448 480</TT> <TT> .000 .016 OH> .002 .002 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000</TT><TT></TT> OH> <TT> 512 544 576 1024 1536 2048 2560 3072 3584 OH> 4096 4608</TT> <TT> .000 .000 .000 .000 .976 .000 .000 .000 .000 OH> .000 .000</TT><TT></TT> OH> <TT>IP Flow Switching Cache, 278544 bytes</TT> <TT> 1 active, 4095 OH> inactive, 19 added</TT> <TT> 1909 ager polls, 0 flow alloc OH> failures</TT> <TT> last clearing of statistics never</TT> OH> <TT>Protocol OH> Total Flows Packets Bytes Packets OH> Active(Sec) Idle(Sec)</TT> OH> <TT>-------- OH> Flows /Sec /Flow OH> /Pkt /Sec OH> /Flow /Flow</TT> OH> <TT>TCP-Telnet OH> 1 0.0 OH> 204 47 OH> 0.0 71.5 OH> 1.3</TT> OH> <TT>UDP-other OH> 7 OH> 0.0 3 OH> 627 0.0 OH> 8.4 15.3</TT> OH> <TT>ICMP OH> 10 OH> 0.0 5 OH> 91 0.0 OH> 4.1 15.4</TT> OH> <TT>Total: OH> 18 0.0 OH> 15 103 OH> 0.0 9.5 OH> 14.6</TT><TT></TT> OH> <TT>SrcIf OH> SrcIPaddress OH> DstIf OH> DstIPaddress Pr SrcP DstP Pkts</TT> OH> <TT>Se1 OH> 192.168.88.5 OH> Et0 OH> 192.168.77.2 11 0013 0007 31</TT> OH> From NetFlow, we can determine our packet distribution, protocol OH> distribution, and current flows. Clearly this is valuable data. Enabling NetFlow OH> is done on a per interface basis with the command: ip route-cache flow. OH> Once both CEF (or dCEF) and NetFlow are enabled on the router, we are ready OH> to begin hunting the source of a spoofed IP address attack. It is recommended OH> that the routers run Cisco IOS 12.0 or better. OH> <H2>Test Topology</H2>In the example scenario, a malicious user on the host OH> sweatpants, IP address 192.168.97.2/24, wishes to flood the host spanky, IP OH> address 192.168.77.2/24, with copious amounts of bogus UDP traffic. To avoid OH> being caught, the miscreant on sweatpants has decided to spoof his address to be OH> 96.170.4.8. The miscreant knows that the entire 96/8 netblock is unassigned, and OH> therefore any packets destined for this network will not arrive at an actual OH> site. The spoofed packets are all destined for UDP port 7, the echo port. The OH> source port is UDP port 19, the chargen port. OH> The network topology is: OH> <TT> -----------------</TT> OH> <TT> | spanky SPARC5 |</TT> OH> <TT> | 192.168.77.2/24 |</TT> OH> <TT> -----------------</TT> OH> <TT> OH> | Ethernet</TT> OH> <TT> OH> | e0</TT> <TT> -----------------</TT> OH> <TT> | 192.168.77.1/24 |</TT> OH> <TT> | OH> router1 |</TT> OH> <TT> | 10.10.10.1/30 |</TT> OH> <TT> -----------------</TT> OH> <TT> OH> | s1</TT> OH> <TT> OH> | Serial 64Kb</TT> OH> <TT> OH> | s1</TT> <TT> -----------------</TT> OH> <TT> | 10.10.10.2/30 |</TT> OH> <TT> | OH> router2 |</TT> OH> <TT> | 172.17.50.2/30 |</TT> OH> <TT> -----------------</TT> OH> <TT> OH> | s0</TT> OH> <TT> OH> | Serial 64Kb</TT> OH> <TT> OH> | OH> s0 OH> Ethernet</TT> <TT> OH> --------------------------------- OH> -------------------------</TT> <TT> | OH> 172.17.50.1/30 OH> | OH> | OH> |</TT> <TT> | OH> router3 10.222.88.1/25 OH> |---| 10.222.88.73/25 router5 |</TT> <TT> | OH> 10.222.88.129/25 OH> | OH> | OH> |</TT> <TT> OH> --------------------------------- OH> -------------------------</TT> OH> <TT> OH> | OH> e1 OH> e0 e0</TT> OH> <TT> OH> | Ethernet</TT> OH> <TT> OH> | e0</TT> <TT> ------------------</TT> OH> <TT> | 10.222.88.144/25 |</TT> OH> <TT> | OH> router4 |</TT> OH> <TT> | 192.168.97.1/24 |</TT> OH> <TT> -----------------</TT> OH> <TT> OH> | e1</TT> OH> <TT> OH> | Ethernet</TT> <TT> OH> ------------------</TT> <TT> | OH> 192.168.97.2/24 |</TT> <TT> | sweatpants OH> Linux |</TT> <TT> OH> ------------------</TT> OH> The routing is configured thusly: OH> spanky Default route, gateway 192.168.77.1 (router1) OH> router1 Default route, gateway 10.10.10.2 (router2) OH> router2 Static route 192.168.77.0/24, gateway OH> 10.10.10.1 (router1) Static route 192.168.97.0/24, OH> gateway 172.17.50.1 (router3) router3 Default route, OH> gateway 172.17.50.2 (router2) Static route OH> 192.168.97.0/24, gateway 10.222.88.144 (router4) router4 OH> Default route, gateway 10.222.88.129 (router3) OH> router5 Default route, gateway 10.222.88.1 (router3) OH> sweatpants Default route, gateway 192.168.97.1 OH> (router4) OH> While static routing was used for this experiment, the experiment is not OH> fundamentally changed by the use of a dynamic routing protocol, such as OSPF or OH> EIGRP. While the responses, to the spoofed address, from spanky might be dropped OH> sooner in the path, the result is the same -- the spoofed packets never make it OH> back to sweatpants, the source of the malevolent data stream. It is not uncommon OH> to find the use of default routes for networks that are singly attached to the OH> Internet. OH> <H2>The Game Begins</H2>Using a packet generator, the attack is launched from OH> sweatpants against spanky. A steady stream of spoofed packets now present OH> themselves on the network interface of spanky. Due to the interrupt saturation OH> and higher than normal CPU load, the attack is detected by the system OH> administrator. The use of the snoop tool (Solaris specific packet sniffer) OH> determines the source IP of the attack, 96.170.4.8. The network and security OH> teams are alerted. Once the source IP address (96.170.4.8) and source port (UDP OH> 19) are noted from the output of snoop, the first step is to login to the border OH> router, router1, and take a look. OH> In this topology, it may seem quite obvious that the source of the spoofed OH> packets, from the perspective of router1, must be the serial interface leading OH> to router2. However, it is wise to validate this assumption to ensure that the OH> source of the spoofed attack is not a host within the same subnet as spanky. OH> First, the NetFlow cache is queried thusly: OH> <TT>router1#sh ip cache flow | include 96.170</TT> OH> <TT>Se1 OH> 96.170.4.8 OH> Et0 OH> 192.168.77.2 11 0013 0007 159</TT> OH> Here we see that the source interface of the flow, which is listed in column OH> one, is serial1. So it has been determined that the source is somewhere beyond OH> the border router. Next, CEF is queried. CEF inserts all active sources, on a OH> per interface basis, in its tables. OH> <TT>router1#sh ip cef se1</TT> OH> <TT>Prefix OH> Next Hop OH> Interface</TT> OH> <TT>0.0.0.0/0 OH> 10.10.10.2 OH> Serial1</TT> <TT>10.10.10.0/30 OH> attached OH> Serial1</TT> OH> Here it is seen that the only next hop, according to the CEF cache, is OH> 10.10.10.2. Consulting the topology above, it is noted that the next hop IP OH> address is router2. The search moves one hop further, to router2. OH> The process is repeated on router2. First, a check of the NetFlow cache: OH> <TT>router2#sh ip cache flow | include 96.170</TT> OH> <TT>Se0 OH> 96.170.4.8 OH> Se1 OH> 192.168.77.2 11 0013 0007 299</TT> OH> The source interface of the flow is serial0. Now for a check of the CEF OH> tables: OH> <TT>router2#sh ip cef se0</TT> OH> <TT>Prefix OH> Next Hop OH> Interface</TT> <TT>172.17.50.0/30 OH> attached OH> Serial0</TT> <TT>192.168.97.0/24 OH> 172.17.50.1 Serial0</TT> OH> Once again, the topology is consulted and it is determined that the next hop OH> listed in the CEF tables, 172.17.50.1, is router3. OH> On router3, the NetFlow tables are examined: OH> <TT>router3#sh ip cache flow | include 96.170</TT> OH> <TT>Et1 OH> 96.170.4.8 OH> Se0 OH> 192.168.77.2 11 0013 0007 3235</TT> OH> Ah, perhaps the end is near! The source interface for the flow is Ethernet1. OH> Is the source station directly attached to this router? A check of the CEF OH> tables reveals: OH> <TT>router3#sh ip cef et1</TT> OH> <TT>Prefix OH> Next Hop OH> Interface</TT> <TT>10.222.88.128/25 OH> attached OH> Ethernet1</TT> <TT>10.222.88.144/32 OH> 10.222.88.144 Ethernet1</TT> OH> <TT>192.168.97.0/24 OH> 10.222.88.144 Ethernet1</TT> OH> <TT>10.222.88.73/32 OH> 10.222.88.73 Ethernet1</TT> OH> This presents a bit of a conundrum; there are two possible sources. It may be OH> necessary to check both IP addresses. First, a check of router5, 10.222.88.73. OH> <TT>router5#sh ip cache flow | include 96.170</TT> <TT>router5#</TT> OH> This command returns nothing. After verifying that the attack is still OH> underway, it is obvious that the attacker's data flow does not pass through this OH> router. Moving on to router4 reveals: OH> <TT>router4#sh ip cache flow | include 96.170</TT> OH> <TT>Et1 OH> 96.170.4.8 OH> Et0 OH> 192.168.77.2 11 0013 0007 6673</TT> OH> Ah, this looks promising. A quick check of the CEF tables finds: OH> <TT>router4#sh ip cef et1</TT> OH> <TT>Prefix OH> Next Hop OH> Interface</TT> <TT>192.168.97.0/24 OH> attached OH> Ethernet1</TT> <TT>192.168.97.2/32 OH> 192.168.97.2 Ethernet1</TT> OH> So the only active IP address is 192.168.97.2. Since a quick check of either OH> the MAC address (with sh arp) or other means reveals that this is not a Cisco OH> router, this IP address begins to look more suspect. At this point, network OH> sniffing can be performed to verify that the source IP of the attack, OH> 96.170.4.8, is tied to the MAC address of 192.168.97.2. The source of the OH> spoofed IP addresses has been found. OH> <H2>Limitations</H2>While this method is fast and presents very little impact on OH> the routers, it is not without certain limitations. OH> First, NetFlow must be running on the interfaces. NetFlow can be configured, OH> in real-time, during an attack. The NetFlow data is the key to this method. OH> Second, router access must be available. This can be a hurdle both OH> technically (no access to the routers) and politically (the routers are owned by OH> another entity). However, this can be a coordinated effort, with multiple teams OH> handing off the tracing as each autonomous system boundary is crossed. If the OH> trace is done completely within a single AS, however, many of the political and OH> technical issues may not exist. OH> Third, the attack must be of a duration that allows for a trace. Short, OH> bursty attacks may not allow for a full trace. While a partial trace may help to OH> narrow the scope of the search, it will not find the culprit. OH> Fourth, this method is obviously limited to the Cisco IOS platform. Other OH> platforms, such as a Check Point FireWall-1 firewall, will provide similar OH> tracing capabilities through the rule base or tools such as tcpdump, snoop, and OH> iptrace. However, some platforms may provide no trace method at all. OH> <H2>Conclusion</H2>Uncovering the source of a spoofed IP attack can assure that OH> the attacking host is removed as a threat to all networks. With a few relatively OH> simple and quick steps, the source of such an attack can be revealed. OH> <CENTER> OH> <IMG src="http://www.cymru.com/Images/divider.gif"> OH> [ <A href="http://www.cymru.com/Documents/index.html">Documents</A> OH> ] [ <A OH> href="http://www.cymru.com/index.html">Home</A> ] OH> Rob Thomas, <A href="mailto:robt@cymru.com">robt@cymru.com</A>, <A OH> href="http://www.cymru.com/">http://www.cymru.com/</A></CENTER></BODY></HTML> -- ------------------------------------------------------- Dmitry Cherkasov ISP "Intercom" (380)44 251-12-88 http://www.intercom.net.ua DC1-UANIC CHD1-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Oleh Hrynchuk

23 Jan 23 Jan

6:59 a.m.

Кгхм... Та якраз в тій ідеї і була основна передумова - підерів треба мочити всім гуртом. Тільки прослідкувавши ланцюжок атаки. А як інакше?... І, думається, що SP вже давно доросли до такої думки і надають посильну допомогу колегам.

...

-----Original Message----- From: owner-uanog-outgoing@uanog.kiev.ua [mailto:owner-uanog-outgoing@uanog.kiev.ua] On Behalf Of Dmitry Cherkasov Sent: Friday, January 20, 2006 11:38 AM To: uanog@uanog.kiev.ua Subject: [uanog] Re: RE: DoS SMTP

On Thu, Jan 19, 2006 at 01:17:20PM +0200, Oleh Hrynchuk wrote: OH> OH> Доброго дня. OH> OH> Не для Фрюхи, але ідея повинна бути зрозуміла. OH> Див. аттач.

Нормальна ідея, звичайно, але:

... Second, router access must be available. This can be a hurdle both technically (no access to the routers) and politically (the routers are owned by another entity). However, this can be a coordinated effort, with multiple teams handing off the tracing as each autonomous system boundary is crossed. If the trace is done completely within a single AS, however, many of the political and technical issues may not exist.

Third, the attack must be of a duration that allows for a trace. Short, bursty attacks may not allow for a full trace. While a partial trace may help to narrow the scope of the search, it will not find the culprit. ...

Якщо зловмисник десь поряд, особливих проблем немає. Та чи часто буває таке. Людина добре подумає перед тим, як шкодити своєму ІСП чи його клієнтам..

OH> OH> OH> > -----Original Message----- OH> > From: owner-uanog-outgoing@uanog.kiev.ua OH> > [mailto:owner-uanog-outgoing@uanog.kiev.ua] On Behalf Of > OH> Andrey Nikolaev > Sent: Thursday, January 19, 2006 12:16 PM > To: OH> uanog@uanog.kiev.ua > Subject: [uanog] DoS SMTP > > > Hi! OH> > OH> > тут возникла проблемка, атакуют машинку под freebsd 5.4 smtp > OH> service ... OH> > адреса атаки рассыпаются, тюнинг фри ограничился этим: OH> > net.inet.tcp.msl=7500 OH> > net.inet.tcp.blackhole=2 OH> > net.inet.udp.blackhole=1 OH> > net.inet.icmp.icmplim=100 OH> > OH> > чтото посоветуете ? OH> > как можно все таки найти источник? OH> > OH> > -- OH> > andy@cris.net AN1035-RIPE OH> > OH> =================================================================== OH> > uanog mailing list. OH> > To Unsubscribe: send mail to majordomo@uanog.kiev.ua with > OH> "unsubscribe uanog" in the body of the message

OH> Date: Thu, 24 Apr 2003 08:44:23 +0300 OH> From: яНУПЮМЕМНMicrosoftInternetExplorer5 OH> Subject: Tracking Spoofed IP Addresses Version 2.0 OH> OH> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> OH> <HTML><HEAD><TITLE>Tracking Spoofed IP Addresses Version 2.0</TITLE> OH> <META content="text/html; charset=iso-8859-1" OH> http-equiv=Content-Type> <META content="MSHTML 5.00.3504.2500" OH> name=GENERATOR></HEAD> <BODY> <CENTER> <H1>Tracking Spoofed IP OH> Addresses Version 2.0</H1></CENTER> <CENTER> <H3>By Rob Thomas, <A OH> href="mailto:robt@cymru.com">robt@cymru.com</A>, 08 FEB OH> 2001</H3></CENTER> <CENTER>[ <A OH> href="http://www.cymru.com/Documents/index.html">Documents</A> OH> ] [ <A OH> href="http://www.cymru.com/index.html">Home</A> ] <IMG OH> src="http://www.cymru.com/Images/divider.gif"></CENTER> OH> <H2>Introduction</H2>Tracking spoofed IP addresses back to the OH> source can be quite a difficult task. For myriad reasons, such as OH> limited router access, attacks of a short duration, and the manual OH> nature of spoofed address tracking, finding the actual generator of OH> the spoofed packets can be very difficult. For this reason, OH> attackers often use the bogon address ranges, where a bogon address range is any unassigned and likely unrouted (by BGP4 in the Internet) netblock. OH> This includes the RFC1918 addresses as well as a collection of OH> other address spaces, such as 1/8, 169.254/16, and the like. OH> However, with a certain combination of features enabled on a OH> Cisco router, it is possible to determine the source of the spoofed OH> packets. Further, this can be done without the laborious and CPU OH> intensive task of adding ACLs to filter the spoofed packets. The key features are CEF and NetFlow. OH> NOTE: Please be aware that router resources are never OH> infinite. Both CEF and NetFlow require resources from the router, OH> and therefore are not entirely immune to issues. NetFlow exports, OH> in particular, may heavily load both the router and the export OH> interface. Please take the time to test your configuration prior to deploying it in production. OH> While this document details a method for tracking the source of OH> a DDoS attack that utilizes spoofed IP addresses, there are several OH> other documents that detail methods of mitigating DDoS attacks. You OH> can view my <A OH> href="http://www.cymru.com/Documents/secure-ios-template.html">Secur OH> e IOS Template</A> and my <A OH> href="http://www.cymru.com/Documents/secure-bgp-template.html">Secur OH> e BGP Template</A> to enhance your router and peering security. OH> There are also several efforts currently underway to block DDoS attacks. Here are a few informative links (thanks to John Kristoff for passing these along): OH> Pushback <A OH> OH> href="http://www.research.att.com/~smb/talks/pushback-dodcert.pdf">h OH> ttp://www.research.att.com/~smb/talks/pushback-dodcert.pdf</A> <A OH> OH> href="http://www.aciri.org/floyd/talks/pushback-Nov00.pdf">http://ww OH> w.aciri.org/floyd/talks/pushback-Nov00.pdf</A> OH> Traceback <A OH> OH> href="http://www.cs.washington.edu/homes/savage/traceback.html">http OH> ://www.cs.washington.edu/homes/savage/traceback.html</A> <A OH> OH> href="http://www.research.att.com/lists/ietf-itrace/">http://www.res OH> earch.att.com/lists/ietf-itrace/</A> OH> CenterTrack <A OH> OH> href="http://www.nanog.org/mtg-9910/ppt/robert/index.htm">http://www OH> .nanog.org/mtg-9910/ppt/robert/index.htm</A> <A OH> OH> href="http://www.us.uu.net/gfx/projects/security/centertrack.pdf">ht OH> tp://www.us.uu.net/gfx/projects/security/centertrack.pdf</A> OH> OH> <H2>Router Configuration</H2>Most high-end Cisco routers on the OH> Internet run either CEF or dCEF. This is because of the large OH> performance gains to be realized with CEF, which stands for Cisco OH> Express Forwarding. CEF has many benefits over fast switching, OH> including a more reliable and sturdy method for building the OH> forwarding table. CEF also offers some security benefits, such as OH> RPF (Reverse Path Forwarding). RPF provides a means of blocking OH> packets that claim to originate from within your network, but OH> present themselves on an external interface. Keep in mind that CEF OH> can be a bit tricky to configure in an environment that has OH> asymmetric data flows. You may wish to review the <A OH> href="http://www.cisco.com/warp/public/cc/pd/iosw/iore/tech/cef_wp.h OH> tm">Cisco CEF White Paper</A>. CEF is, therefore, a wise choice for OH> reasons of performance and security. CEF is enabled on a global OH> basis with the command ip cef. To enable dCEF (Distributed CEF), OH> the global command is ip cef distributed. OH> NetFlow provides a means of mapping traffic flows through a OH> router. This can be of great use for capacity planning, statistical OH> analysis of traffic patterns, and security reviews. Here is a sample of the output from NetFlow: OH> <TT>router1#sh ip cache flow</TT> <TT>IP packet size OH> distribution (11319 total packets):</TT> <TT> OH> 1-32 64 96 128 160 OH> 192 224 256 288 320 352 OH> 384 416 448 480</TT> <TT> .000 OH> .016 OH> .002 .002 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 OH> .000</TT><TT></TT> <TT> 512 544 OH> 576 1024 1536 2048 2560 3072 3584 OH> 4096 4608</TT> <TT> .000 .000 .000 .000 .976 .000 OH> .000 .000 .000 .000 .000</TT><TT></TT> <TT>IP Flow Switching OH> Cache, 278544 bytes</TT> <TT> 1 active, 4095 inactive, 19 OH> added</TT> <TT> 1909 ager polls, 0 flow alloc OH> failures</TT> <TT> last clearing of statistics never</TT> OH> <TT>Protocol OH> Total Flows Packets Bytes OH> Packets OH> Active(Sec) Idle(Sec)</TT> OH> <TT>-------- OH> Flows /Sec OH> /Flow /Pkt OH> /Sec /Flow OH> /Flow</TT> OH> <TT>TCP-Telnet &n OH> bsp; 1 OH> 0.0 OH> 204 47 OH> 0.0 OH> 71.5 OH> 1.3</TT> OH> OH> <TT>UDP-other &nb OH> sp; OH> 7 OH> 0.0 3 OH> 627 OH> 0.0 OH> 8.4 15.3</TT> OH> <TT>ICMP &n OH> bsp; OH> 10 OH> 0.0 OH> 5 91 OH> 0.0 OH> 4.1 15.4</TT> OH> <TT>Total: OH> 18 OH> 0.0 OH> 15 103 OH> 0.0 OH> 9.5 14.6</TT><TT></TT> OH> <TT>SrcIf OH> SrcIPaddress OH> DstIf OH> DstIPaddress Pr SrcP DstP Pkts</TT> OH> <TT>Se1 &nb OH> sp; OH> 192.168.88.5 OH> Et0 OH> 192.168.77.2 11 0013 0007 OH> 31</TT> From NetFlow, we can determine our packet distribution, OH> protocol distribution, and current flows. Clearly this is valuable OH> data. Enabling NetFlow is done on a per interface basis with the command: ip route-cache flow. OH> Once both CEF (or dCEF) and NetFlow are enabled on the router, OH> we are ready to begin hunting the source of a spoofed IP address OH> attack. It is recommended that the routers run Cisco IOS 12.0 or better. OH> <H2>Test Topology</H2>In the example scenario, a malicious user on OH> the host sweatpants, IP address 192.168.97.2/24, wishes to flood OH> the host spanky, IP address 192.168.77.2/24, with copious amounts OH> of bogus UDP traffic. To avoid being caught, the miscreant on OH> sweatpants has decided to spoof his address to be 96.170.4.8. The OH> miscreant knows that the entire 96/8 netblock is unassigned, and OH> therefore any packets destined for this network will not arrive at OH> an actual site. The spoofed packets are all destined for UDP port 7, the echo port. The source port is UDP port 19, the chargen port. OH> The network topology is: OH> <TT> -----------------</TT> OH> <TT> | spanky SPARC5 OH> |</TT> <TT> | 192.168.77.2/24 OH> |</TT> <TT> OH> -----------------</TT> OH> <TT> OH> OH> | Ethernet</TT> OH> OH> <TT> OH> | e0</TT> <TT> OH> -----------------</TT> <TT> | OH> 192.168.77.1/24 |</TT> <TT> | OH> router1 |</TT> OH> <TT> | 10.10.10.1/30 OH> |</TT> <TT> OH> -----------------</TT> OH> <TT> OH> OH> | s1</TT> OH> OH> <TT> OH> OH> | Serial 64Kb</TT> OH> OH> <TT> OH> | s1</TT> <TT> OH> -----------------</TT> <TT> | OH> 10.10.10.2/30 |</TT> OH> <TT> | OH> router2 |</TT> OH> <TT> | 172.17.50.2/30 |</TT> OH> <TT> -----------------</TT> OH> <TT> OH> OH> | s0</TT> OH> OH> <TT> OH> OH> | Serial 64Kb</TT> OH> OH> <TT> OH> OH> | OH> OH> s0 OH> OH> Ethernet</TT> <TT> OH> --------------------------------- OH> -------------------------</TT> OH> <TT> | OH> 172.17.50.1/30 OH> OH> | OH> OH> | & OH> nbsp; &nb OH> sp; |</TT> <TT> | OH> router3 OH> 10.222.88.1/25 |---| 10.222.88.73/25 router5 |</TT> OH> <TT> | OH> 10.222.88.129/25 &nbs OH> p; OH> | OH> OH> | & OH> nbsp; &nb OH> sp; |</TT> <TT> OH> --------------------------------- OH> -------------------------</TT> OH> OH> <TT> OH> OH> | OH> OH> e1 OH> OH> e0 e0</TT> OH> OH> <TT> OH> OH> | Ethernet</TT> OH> OH> <TT> OH> | e0</TT> <TT> OH> ------------------</TT> <TT> | OH> 10.222.88.144/25 |</TT> <TT> | OH> router4 |</TT> OH> <TT> | 192.168.97.1/24 OH> |</TT> <TT> OH> -----------------</TT> OH> <TT> OH> OH> | e1</TT> OH> OH> <TT> OH> | Ethernet</TT> OH> <TT> OH> ------------------</TT> <TT> | OH> 192.168.97.2/24 |</TT> <TT> OH> | sweatpants Linux |</TT> OH> <TT> OH> ------------------</TT> OH> The routing is configured thusly: OH> spanky Default route, gateway OH> 192.168.77.1 (router1) OH> router1 Default route, gateway OH> 10.10.10.2 (router2) OH> router2 Static route 192.168.77.0/24, OH> gateway OH> 10.10.10.1 (router1) Static route OH> 192.168.97.0/24, gateway 172.17.50.1 (router3) router3 OH> Default route, gateway 172.17.50.2 (router2) OH> Static route 192.168.97.0/24, gateway OH> 10.222.88.144 (router4) router4 Default OH> route, gateway 10.222.88.129 (router3) OH> router5 Default route, gateway OH> 10.222.88.1 (router3) sweatpants Default OH> route, gateway 192.168.97.1 OH> (router4) OH> While static routing was used for this experiment, the OH> experiment is not fundamentally changed by the use of a dynamic OH> routing protocol, such as OSPF or EIGRP. While the responses, to OH> the spoofed address, from spanky might be dropped sooner in the OH> path, the result is the same -- the spoofed packets never make it OH> back to sweatpants, the source of the malevolent data stream. It is OH> not uncommon to find the use of default routes for networks that are singly attached to the Internet. OH> <H2>The Game Begins</H2>Using a packet generator, the attack is OH> launched from sweatpants against spanky. A steady stream of spoofed OH> packets now present themselves on the network interface of spanky. OH> Due to the interrupt saturation and higher than normal CPU load, OH> the attack is detected by the system administrator. The use of the OH> snoop tool (Solaris specific packet sniffer) determines the source OH> IP of the attack, 96.170.4.8. The network and security teams are OH> alerted. Once the source IP address (96.170.4.8) and source port OH> (UDP OH> 19) are noted from the output of snoop, the first step is to login OH> to the border router, router1, and take a look. OH> In this topology, it may seem quite obvious that the source of OH> the spoofed packets, from the perspective of router1, must be the OH> serial interface leading to router2. However, it is wise to OH> validate this assumption to ensure that the source of the spoofed attack is not a host within the same subnet as spanky. OH> First, the NetFlow cache is queried thusly: OH> <TT>router1#sh ip cache flow | include 96.170</TT> OH> <TT>Se1 &nb OH> sp; 96.170.4.8 OH> Et0 OH> 192.168.77.2 11 0013 0007 159</TT> OH> Here we see that the source interface of the flow, which is OH> listed in column one, is serial1. So it has been determined that OH> the source is somewhere beyond the border router. Next, CEF is OH> queried. CEF inserts all active sources, on a per interface basis, in its tables. OH> <TT>router1#sh ip cef se1</TT> OH> OH> <TT>Prefix OH> Next OH> Hop OH> ; OH> Interface</TT> OH> OH> <TT>0.0.0.0/0 &nb OH> sp; OH> 10.10.10.2 &nbs OH> p; Serial1</TT> OH> <TT>10.10.10.0/30 OH> OH> attached OH> OH> Serial1</TT> OH> Here it is seen that the only next hop, according to the CEF OH> cache, is 10.10.10.2. Consulting the topology above, it is noted OH> that the next hop IP address is router2. The search moves one hop further, to router2. OH> The process is repeated on router2. First, a check of the NetFlow cache: OH> <TT>router2#sh ip cache flow | include 96.170</TT> OH> <TT>Se0 &nb OH> sp; 96.170.4.8 OH> Se1 OH> 192.168.77.2 11 0013 0007 299</TT> OH> The source interface of the flow is serial0. Now for a check of OH> the CEF OH> tables: OH> <TT>router2#sh ip cef se0</TT> OH> OH> <TT>Prefix OH> Next OH> Hop OH> ; Interface</TT> OH> <TT>172.17.50.0/30 OH> OH> attached OH> Serial0</TT> OH> <TT>192.168.97.0/24 OH> 172.17.50.1 OH> Serial0</TT> Once again, the topology is consulted and it is OH> determined that the next hop listed in the CEF tables, 172.17.50.1, is router3. OH> On router3, the NetFlow tables are examined: OH> <TT>router3#sh ip cache flow | include 96.170</TT> OH> <TT>Et1 &nb OH> sp; 96.170.4.8 OH> Se0 OH> 192.168.77.2 11 0013 0007 3235</TT> Ah, OH> perhaps the end is near! The source interface for the flow is Ethernet1. OH> Is the source station directly attached to this router? A check of OH> the CEF tables reveals: OH> <TT>router3#sh ip cef et1</TT> OH> OH> <TT>Prefix OH> Next OH> Hop OH> ; Interface</TT> <TT>10.222.88.128/25 OH> OH> attached OH> Ethernet1</TT> OH> <TT>10.222.88.144/32 OH> 10.222.88.144 OH> Ethernet1</TT> <TT>192.168.97.0/24 OH> 10.222.88.144 OH> Ethernet1</TT> <TT>10.222.88.73/32 OH> 10.222.88.73 OH> Ethernet1</TT> This presents a bit of a conundrum; there are two OH> possible sources. It may be necessary to check both IP addresses. First, a check of router5, 10.222.88.73. OH> <TT>router5#sh ip cache flow | include 96.170</TT> OH> <TT>router5#</TT> This command returns nothing. After OH> verifying that the attack is still underway, it is obvious that the OH> attacker's data flow does not pass through this router. Moving on to router4 reveals: OH> <TT>router4#sh ip cache flow | include 96.170</TT> OH> <TT>Et1 &nb OH> sp; 96.170.4.8 OH> Et0 OH> 192.168.77.2 11 0013 0007 6673</TT> Ah, OH> this looks promising. A quick check of the CEF tables finds: OH> <TT>router4#sh ip cef et1</TT> OH> OH> <TT>Prefix OH> Next OH> Hop OH> ; Interface</TT> OH> <TT>192.168.97.0/24 OH> OH> attached OH> Ethernet1</TT> OH> <TT>192.168.97.2/32 OH> 192.168.97.2 OH> Ethernet1</TT> So the only active IP address is 192.168.97.2. OH> Since a quick check of either the MAC address (with sh arp) or OH> other means reveals that this is not a Cisco router, this IP OH> address begins to look more suspect. At this point, network OH> sniffing can be performed to verify that the source IP of the OH> attack, 96.170.4.8, is tied to the MAC address of 192.168.97.2. The source of the spoofed IP addresses has been found. OH> <H2>Limitations</H2>While this method is fast and presents very OH> little impact on the routers, it is not without certain limitations. OH> First, NetFlow must be running on the interfaces. NetFlow can be OH> configured, in real-time, during an attack. The NetFlow data is the key to this method. OH> Second, router access must be available. This can be a hurdle OH> both technically (no access to the routers) and politically (the OH> routers are owned by another entity). However, this can be a OH> coordinated effort, with multiple teams handing off the tracing as OH> each autonomous system boundary is crossed. If the trace is done OH> completely within a single AS, however, many of the political and technical issues may not exist. OH> Third, the attack must be of a duration that allows for a trace. OH> Short, bursty attacks may not allow for a full trace. While a OH> partial trace may help to narrow the scope of the search, it will not find the culprit. OH> Fourth, this method is obviously limited to the Cisco IOS OH> platform. Other platforms, such as a Check Point FireWall-1 OH> firewall, will provide similar tracing capabilities through the OH> rule base or tools such as tcpdump, snoop, and iptrace. However, some platforms may provide no trace method at all. OH> <H2>Conclusion</H2>Uncovering the source of a spoofed IP attack can OH> assure that the attacking host is removed as a threat to all OH> networks. With a few relatively simple and quick steps, the source of such an attack can be revealed. OH> <CENTER> OH> <IMG src="http://www.cymru.com/Images/divider.gif"> OH> [ <A OH> href="http://www.cymru.com/Documents/index.html">Documents</A> OH> ] [ <A OH> href="http://www.cymru.com/index.html">Home</A> ] Rob Thomas, <A OH> href="mailto:robt@cymru.com">robt@cymru.com</A>, <A OH> href="http://www.cymru.com/">http://www.cymru.com/</A></CENTER>< OH> /BODY></HTML>

-- ------------------------------------------------------- Dmitry Cherkasov ISP "Intercom" (380)44 251-12-88 http://www.intercom.net.ua DC1-UANIC CHD1-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

boris mostovoy

8:33 a.m.

Hello Oleh, Monday, January 23, 2006, 8:59:29 AM, you wrote: OH> Кгхм... OH> Та якраз в тій ідеї і була основна передумова - підерів треба мочити всім OH> гуртом. OH> Тільки прослідкувавши ланцюжок атаки. это идеал. В реале - увы, только если звезды удобно станут для небольшого гурта респонсибильных нетадминов. OH> А як інакше?... OH> І, думається, що SP вже давно доросли до такої думки і надають OH> посильну допомогу колегам. нет. Варианты - от простого непонимания и пофигизма до пассивного злорадства. Кстати, иногда так называемые сисадмины(нетадмины) более всего похожи на трансляторы начальственного видения в команды кошкам или чему еще из железок в зоне своей AS. Основная поза - "кабычегоневышло". А т.к. дидосеры более стимулированы (злобой, деньгами, еще чем) такие AS'ы под управлением "кабычегоневышлов" превращаются автоматически в черную дыру, в которой дидосерам удается скрыться. ps даже для оперативного оповещение и выстраивания капканов приходится использовать альтернативные каналы. Хотя для этого списка было бы самое то дело. Я, например, не уверен что в этом списке сейчас кто-то из дидосеров не ухмыляется, читая эту тему. -- С уважением, Борис Мостовой ООО "Хостмастер" +380(44)594-1-794(ext305) +380(44)451-7456 http://nic.net.ua http://www.hostmaster.net.ua http://forum.hostmaster.net.ua -- Best regards, boris mailto:vms@tormoz.net =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Oleh Hrynchuk

9:05 a.m.

Мдя, Боря рубанув нах правду-матку прямо в очі :))) Отака от вона, "сермяжная правда" :-/ Ну тоді лишається вести реєстр таких "кабынахчегоневышло" і поступати з ними "по справедливості". Боря, а в тебе подібний досвід взаємодії лише з Uaшними/RUшними адмінами, чи така ситуація характерна і для забугорних ones? Бо особисто я колись був дуже задоволений співпрацею з "забугорними". Практично ніколи не було відлупів/мовчання, а люди щиро намагались допомогти.

...

-----Original Message----- From: owner-uanog-outgoing@uanog.kiev.ua [mailto:owner-uanog-outgoing@uanog.kiev.ua] On Behalf Of boris mostovoy Sent: Monday, January 23, 2006 10:33 AM To: uanog@uanog.kiev.ua Subject: [uanog] Re: RE: Re: RE: DoS SMTP

Hello Oleh,

Monday, January 23, 2006, 8:59:29 AM, you wrote:

OH> Кгхм... OH> Та якраз в тій ідеї і була основна передумова - підерів треба мочити OH> всім гуртом. OH> Тільки прослідкувавши ланцюжок атаки.

это идеал. В реале - увы, только если звезды удобно станут для небольшого гурта респонсибильных нетадминов.

OH> А як інакше?...

OH> І, думається, що SP вже давно доросли до такої думки і надають OH> посильну допомогу колегам.

нет. Варианты - от простого непонимания и пофигизма до пассивного злорадства.

Кстати, иногда так называемые сисадмины(нетадмины) более всего похожи на трансляторы начальственного видения в команды кошкам или чему еще из железок в зоне своей AS. Основная поза - "кабычегоневышло". А т.к. дидосеры более стимулированы (злобой, деньгами, еще чем) такие AS'ы под управлением "кабычегоневышлов" превращаются автоматически в черную дыру, в которой дидосерам удается скрыться.

ps даже для оперативного оповещение и выстраивания капканов приходится использовать альтернативные каналы. Хотя для этого списка было бы самое то дело. Я, например, не уверен что в этом списке сейчас кто-то из дидосеров не ухмыляется, читая эту тему.

-- С уважением, Борис Мостовой ООО "Хостмастер" +380(44)594-1-794(ext305) +380(44)451-7456 http://nic.net.ua http://www.hostmaster.net.ua http://forum.hostmaster.net.ua

-- Best regards, boris mailto:vms@tormoz.net

=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

boris mostovoy

10:12 a.m.

Hello Oleh, Monday, January 23, 2006, 11:05:03 AM, you wrote: OH> Мдя, Боря рубанув нах правду-матку прямо в очі :))) OH> Отака от вона, "сермяжная правда" :-/ Олежка, когда приходится очень практически отжиматься - выводы делаешь как хирург, а не терапевт из фитолечебницы :) OH> Ну тоді лишається вести реєстр таких "кабынахчегоневышло" і поступати OH> з ними "по справедливості". Ну память пока не глючит :) Для политкорректности - если выйти на реальных хозяев - и эта категория народонаселения начинает шевелиться. OH> Боря, а в тебе подібний досвід взаємодії лише з Uaшними/RUшними адмінами, OH> чи така ситуація характерна і для забугорних ones? Давай введем понятие - для меня "забугор" начинается на border. Чужой AS - забугор со всеми вытекающими (в т.ч. preffered language :) У меня сейчас достаточно странная позиция - я не имею ни одного прямого договора с аплинками, которые накрывают местную территорию. И говорить с ними напрямую - типа не могу, могу через того, у кого есть прямые договора. Впрочем - тамошних дидосеров вполне могут тамошние нетадмины локализовать и выловить, достаточно отмашку дать (официально или нет - зачастую пофигу, они или уже смотрят в мониторилки или уже посмотрели и анализируют "якым саме чыном" блох подковать :) Более интересны местные дидосеры и заказчики - они прямо дискредитируют местный сегмент и напрямую находятся в пределах местных AS. Если не будем гуртом щемить - рассыплется местная авоська нафиг - мощности оборудования практически любого(в т.ч. "типа магистральных") провайдера не позволяют в одиночку отбить более-менее организованную атаку. А изыскать и защемить дидосера - в одиночку нереально в принципе. OH> Бо особисто я колись був дуже задоволений співпрацею з "забугорними". OH> Практично ніколи не було відлупів/мовчання, а люди щиро намагались OH> допомогти. Да, есть такой положительный момент. Предположу, что с некоторого уровня нетадмина он может достаточно широко пользоваться правом оперативно управлять собственной AS и взаимодействовать с пирами для решения общих задач. Отчитается потом (если спросят/или для истории|науки). Местные - зачастую у барина позволения абизяны спросить, да еще и вибрируют при этом - отвлечь ли барина от обеда? будить ли барина ночью? А то еще и в слепоглухонемого могут сыграть - особенно, если ресурс позволяет небольшую атачку проигнорировать... -- С уважением, Борис Мостовой ООО "Хостмастер" +380(44)594-1-794(ext305) +380(44)451-7456 http://nic.net.ua http://www.hostmaster.net.ua http://forum.hostmaster.net.ua -- Best regards, boris mailto:vms@tormoz.net =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Dmitry Cherkasov

11:59 a.m.

23.01.06, boris mostovoy написал(а):

...

... А изыскать и защемить дидосера - в одиночку нереально в принципе.

Упоминание дидосера в единственном числе -- наверное опечатка ;-) Дидос -- он же distributed. Если атака идет с пачки зомбированных машин, разбросанных по миру, отслеживать будет накладно. JIMHO, те, кто может позволить себе, должны ставить всевозможные IDS, чем навороченнее, тем дороже (и, возможно, эффективнее). Этим отсекаются примитивные и наиболее массовые атаки. Ибо серьезный специалист с хорошей мотивацией все равно скорее всего все сделает правильно -- и задосит и не отследится. Но это уже будет не просто для развлечения. А те, кто не может позволить, наверное, должны терпеть. Облегчить им жизнь можно, например, с помощью сервиса типа BGP Blackhole (пример: http://www.secsup.org/CustomerBlackHole/). Если говорить конкретно про SMTP, то насколько упростило бы жизнь, если бы все провайдеры запретили своим broadband и dialup клиентам напрямую коннектиться в мир по SMTP. Если бы реально было договориться всем ИСП в мире об этом -- вот этот было бы сотрудничество.. (Песня вспомнилась: "Если бы парни всей земли ..." -- наверное это так же реально :-( ) -- Dmitry Cherkasov =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Michael Petuschak

12:22 p.m.

Hi Dmitry,

...

Если говорить конкретно про SMTP, то насколько упростило бы жизнь, если бы все провайдеры запретили своим broadband и dialup клиентам напрямую коннектиться в мир по SMTP. Если бы реально было договориться всем ИСП в мире об этом -- вот этот было бы сотрудничество..

А выделенка - это broadband или нет? -- Michael Позвольте мне со всей прямотой криво усмехнуться. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Andrei Biryukov

12:51 p.m.

Dmitry Cherkasov wrote:

...

Если говорить конкретно про SMTP, то насколько упростило бы жизнь, если бы все провайдеры запретили своим broadband и dialup клиентам напрямую коннектиться в мир по SMTP. Если бы реально было договориться всем ИСП в мире об этом -- вот этот было бы сотрудничество.

У нас так уже лет пять. И кстати жалоб нет... -- Biryukov Andrei ElVisti Information Center, Kiev, Ukraine. E-mail amb@visti.net =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Dmitry Cherkasov

12:51 p.m.

23.01.06, Michael Petuschak написал(а):

...

Hi Dmitry,

...
Если говорить конкретно про SMTP, то насколько упростило бы жизнь, если бы все провайдеры запретили своим broadband и dialup клиентам напрямую коннектиться в мир по SMTP. Если бы реально было договориться всем ИСП в мире об этом -- вот этот было бы сотрудничество..

А выделенка - это broadband или нет?

В том смысле, что я использовал -- зависит от того, кто по ней подключен. Я подразумеваю бродбенд -- это квартирное физлицо без особых гарантий по полосе, которое получает динамический IP, и как правило выставляет в сеть свой Windows без особых мыслей по защите. Немного вирусов и троянов ему нисколько не мешают. Если за выделенкой находится юрлицо со своей сеткой, корпоративной почтой и договором (в котором записано, что хулиганство может быть поводом для отключения) -- то там отношение другое и это уже не массовый бродбенд.

...

-- Michael Позвольте мне со всей прямотой криво усмехнуться. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

-- Dmitry Cherkasov =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Dmitry Cherkasov

12:55 p.m.

23.01.06, Andrei Biryukov написал(а):

...

Dmitry Cherkasov wrote:

...
Если говорить конкретно про SMTP, то насколько упростило бы жизнь, если бы все провайдеры запретили своим broadband и dialup клиентам напрямую коннектиться в мир по SMTP. Если бы реально было договориться всем ИСП в мире об этом -- вот этот было бы сотрудничество.

У нас так уже лет пять. И кстати жалоб нет...

И у нас. И, думаю, еще у многих. Жалобы, конечно, есть, но вполне терпимо. -- Dmitry Cherkasov =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

boris mostovoy

1:03 p.m.

Hello Dmitry, Monday, January 23, 2006, 1:59:34 PM, you wrote: DC> 23.01.06, boris mostovoy написал(а):

...

...
... А изыскать и защемить дидосера - в одиночку нереально в принципе.

DC> Упоминание дидосера в единственном числе -- наверное опечатка ;-) Нет. DC> Дидос -- он же distributed. Если атака идет с пачки зомбированных DC> машин, разбросанных по миру, отслеживать будет накладно. поэтому надо отслеживать управление этим зомбинетом - иначе ловля блох будет бесконечна. DC> JIMHO, те, кто может позволить себе, должны ставить всевозможные IDS, DC> чем навороченнее, тем дороже (и, возможно, эффективнее). Этим DC> отсекаются примитивные и наиболее массовые атаки. Не бывает простых. Под вывеской "простой" вполне может быть отладка более сложной - надо реагировать на любую до полного понимания с полной серьезностью. DC> Ибо серьезный специалист с хорошей мотивацией все равно скорее DC> всего все сделает правильно -- и задосит и не отследится. Но это DC> уже будет не просто для развлечения. Ути-пути. Подробности знает серьезный специалист Кевин Митник - ему серьезный специалист Шимомура на пальцах объяснил :) DC> (Песня вспомнилась: "Если бы парни всей земли ..." -- наверное это так DC> же реально :-( ) А нафига нужен такой колхоз? Тут пяток спецов эффективнее справятся с задачей. Этим и отличаются информационные войска от стройбата с лопатами :) -- С уважением, Борис Мостовой ООО "Хостмастер" +380(44)594-1-794(ext305) +380(44)451-7456 http://nic.net.ua http://www.hostmaster.net.ua http://forum.hostmaster.net.ua -- Best regards, boris mailto:vms@tormoz.net =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Victor Forsyuk

1:22 p.m.

On Mon, Jan 23, 2006 at 01:59:34PM +0200, Dmitry Cherkasov wrote:

...

23.01.06, boris mostovoy написал(а):

...
... А изыскать и защемить дидосера - в одиночку нереально в принципе.

Упоминание дидосера в единственном числе -- наверное опечатка ;-) Дидос -- он же distributed. Если атака идет с пачки зомбированных машин, разбросанных по миру, отслеживать будет накладно.

С чего бы это опечатка? Не юзеров же, у которых в спальне стоит зомбированный виндюк с броадбендом, щемить. :) Защемить дидосера (того, кто атакой управляет) как раз технологически реально, и для "хороших парней" в погонах или в штатском - давно рутинная работа. И исполняется traceback быстро, без шуму и пыли, нужна только команда "фас".

...

отсекаются примитивные и наиболее массовые атаки. Ибо серьезный специалист с хорошей мотивацией все равно скорее всего все сделает правильно -- и задосит и не отследится. Но это уже будет не просто для развлечения.

Не отследится - невозможно. В принципе.

...

Если говорить конкретно про SMTP, то насколько упростило бы жизнь, если бы все провайдеры запретили своим broadband и dialup клиентам напрямую коннектиться в мир по SMTP. Если бы реально было договориться

Ну, пока это не дошло до всех провайдеров, кто мешает фильтровать таких у себя? :) =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

serge pekarsky

1:34 p.m.

Victor Forsyuk пишет:

...

On Mon, Jan 23, 2006 at 01:59:34PM +0200, Dmitry Cherkasov wrote:

...
Если говорить конкретно про SMTP, то насколько упростило бы жизнь,

"упростило" меняем на "усложнило"

...

...
если бы все провайдеры запретили своим broadband и dialup клиентам напрямую коннектиться в мир по SMTP. Если бы реально было договориться

Ну, пока это не дошло до всех провайдеров, кто мешает фильтровать таких у себя? :)

мобильные пользователи, которые шлют почту через один и тот же релей с авторизацией, взвоют. и правильно сделают. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Victor Forsyuk

1:53 p.m.

On Mon, Jan 23, 2006 at 03:34:10PM +0200, serge pekarsky wrote:

...

...
...
если бы все провайдеры запретили своим broadband и dialup клиентам напрямую коннектиться в мир по SMTP. Если бы реально было договориться

Ну, пока это не дошло до всех провайдеров, кто мешает фильтровать таких у себя? :)

мобильные пользователи, которые шлют почту через один и тот же релей с авторизацией, взвоют.

С чего бы? =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Sergey Smitienko

1:56 p.m.

...

...
мобильные пользователи, которые шлют почту через один и тот же релей с авторизацией, взвоют.

С чего бы?

С того, что такому пользователю нужно конектится на домашний SMTP. Идея сейчас очень популярная у корпоративов. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

serge pekarsky

2:07 p.m.

Victor Forsyuk пишет:

...

On Mon, Jan 23, 2006 at 03:34:10PM +0200, serge pekarsky wrote:

...
...
...
если бы все провайдеры запретили своим broadband и dialup клиентам напрямую коннектиться в мир по SMTP. Если бы реально было договориться

Ну, пока это не дошло до всех провайдеров, кто мешает фильтровать таких у себя? :)

мобильные пользователи, которые шлют почту через один и тот же релей с авторизацией, взвоют.

С чего бы?

так ведь smtp наружу закрыть предлагаете. а у него в ноуте прописано слать через корпоративный сервер. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Dmitry Cherkasov

2:23 p.m.

23.01.06, Victor Forsyuk написал(а):

...

On Mon, Jan 23, 2006 at 01:59:34PM +0200, Dmitry Cherkasov wrote:

...
23.01.06, boris mostovoy написал(а):

...
... А изыскать и защемить дидосера - в одиночку нереально в принципе.

Упоминание дидосера в единственном числе -- наверное опечатка ;-) Дидос -- он же distributed. Если атака идет с пачки зомбированных машин, разбросанных по миру, отслеживать будет накладно.

С чего бы это опечатка? Не юзеров же, у которых в спальне стоит зомбированный виндюк с броадбендом, щемить. :)

Защемить дидосера (того, кто атакой управляет) как раз технологически реально, и для "хороших парней" в погонах или в штатском - давно рутинная работа. И исполняется traceback быстро, без шуму и пыли, нужна только команда "фас".

...
отсекаются примитивные и наиболее массовые атаки. Ибо серьезный специалист с хорошей мотивацией все равно скорее всего все сделает правильно -- и задосит и не отследится. Но это уже будет не просто для развлечения.

Не отследится - невозможно. В принципе.

Гм.. противоречит ранее сказанному, вроде ;-)

...

...
Если говорить конкретно про SMTP, то насколько упростило бы жизнь, если бы все провайдеры запретили своим broadband и dialup клиентам напрямую коннектиться в мир по SMTP. Если бы реально было договориться

Ну, пока это не дошло до всех провайдеров, кто мешает фильтровать таких у себя? :)

Так уже ;-) С тех времен, когда выпустился mdaemon с разрешенным по умолчанию релеингом всего всем ;-) -- Dmitry Cherkasov =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Victor Forsyuk

2:46 p.m.

On Mon, Jan 23, 2006 at 03:56:46PM +0200, Sergey Smitienko wrote:

...

...
...
мобильные пользователи, которые шлют почту через один и тот же релей с авторизацией, взвоют.

С чего бы?

С того, что такому пользователю нужно конектится на домашний SMTP. Идея сейчас очень популярная у корпоративов.

Именно на домашний? Ну допустим. На здоровье. Как это противоречит моему нежеланию видеть хосты вида 162.red-83-52-48.dynamicip.rima-tde.net или adsl-159-193-192-81.adsl.iam.net.ma общающимися с моим SMTP сервером? :) =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

serge pekarsky

2:58 p.m.

Victor Forsyuk пишет:

...

On Mon, Jan 23, 2006 at 03:56:46PM +0200, Sergey Smitienko wrote:

...
...
...
мобильные пользователи, которые шлют почту через один и тот же релей с авторизацией, взвоют.

С чего бы?

С того, что такому пользователю нужно конектится на домашний SMTP. Идея сейчас очень популярная у корпоративов.

Именно на домашний? Ну допустим. На здоровье. Как это противоречит моему нежеланию видеть хосты вида 162.red-83-52-48.dynamicip.rima-tde.net или adsl-159-193-192-81.adsl.iam.net.ma общающимися с моим SMTP сервером?

:)

Виктор, Вы не стой стороны ложки: "если бы все провайдеры запретили своим broadband и dialup клиентам напрямую коннектиться в мир по SMTP. " довольно слабо коррелирует с Вашей фразой о чужих хостах и Вашем SMTP сервере. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Victor Forsyuk

3:03 p.m.

On Mon, Jan 23, 2006 at 04:07:52PM +0200, serge pekarsky wrote:

...

...
...
...
...
если бы все провайдеры запретили своим broadband и dialup клиентам напрямую коннектиться в мир по SMTP. Если бы реально было договориться

Ну, пока это не дошло до всех провайдеров, кто мешает фильтровать таких у себя? :)

мобильные пользователи, которые шлют почту через один и тот же релей с авторизацией, взвоют.

С чего бы?

так ведь smtp наружу закрыть предлагаете.

Прямой выход диалапных/кабельных/томуподобных клиентов на отправку почты мимо SMTP сервера провайдера? Да.

...

а у него в ноуте прописано слать через корпоративный сервер.

Ну и правильно. :) И если там цельный корпоративный(!) сервер(!), то есть два варианта: 1) Они получают адрес не из клиентского блока и соответствующий человеческий резолвинг. Наверняка, за небесплатно, но это снимает все проблемы. 2) Они читают ФАК-Ю на свой корпоративный сервер и понимают смысл слов smarthost или manualroute. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

serge pekarsky

3:11 p.m.

Victor Forsyuk пишет:

...

On Mon, Jan 23, 2006 at 04:07:52PM +0200, serge pekarsky wrote:

И если там цельный корпоративный(!) сервер(!), то есть два варианта:

1) Они получают адрес не из клиентского блока и соответствующий человеческий резолвинг. Наверняка, за небесплатно, но это снимает все проблемы.

гммммм, я понять не могу: то ли Вы упорствуете в заблуждении, то ли погода подействовала. описываю ситуацию (вполне живую): клиент, со статическим адресом - организация А, которая часто принимает у себя партнеров/наемных сотрудников/etc с мобильными ПК. приезжают очередные сотрудники/партнеры, включаются в сеть организации А (или не в сеть, а в гостевой сегмент), получают "серые" адреса и с неудовольствием понимают, что почта у них работать перестала, потому что провайдер фильтрует 25 порт наружу (к домашнему серверу).

...

2) Они читают ФАК-Ю на свой корпоративный сервер и понимают смысл слов smarthost или manualroute.

после чего находят во всем интернете, провайдеров, которые закрывают своим клиентам наружу смтп (или прозрачно пробрасывают на свой релей) и просят вот именно с их корпоративным(!) сервером (!) такого не делать. утопия. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Victor Forsyuk

3:21 p.m.

On Mon, Jan 23, 2006 at 04:23:44PM +0200, Dmitry Cherkasov wrote:

...

...
Защемить дидосера (того, кто атакой управляет) как раз технологически реально, и для "хороших парней" в погонах или в штатском - давно рутинная работа. И исполняется traceback быстро, без шуму и пыли, нужна только команда "фас".

...
отсекаются примитивные и наиболее массовые атаки. Ибо серьезный специалист с хорошей мотивацией все равно скорее всего все сделает правильно -- и задосит и не отследится. Но это уже будет не просто для развлечения.

Не отследится - невозможно. В принципе.

Гм.. противоречит ранее сказанному, вроде ;-)

Да вроде я не видел ничего в предыдущей беседе, что этому противоречило бы. Технологических проблем нет никаких. Просто success story в этой области не особо афишируют. Но когда ставится цель зайти в гости и зачитать права - обычно заходят :) =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Sergey Smitienko

3:28 p.m.

...

1) Они получают адрес не из клиентского блока и соответствующий человеческий резолвинг. Наверняка, за небесплатно, но это снимает все проблемы.

2) Они читают ФАК-Ю на свой корпоративный сервер и понимают смысл слов smarthost или manualroute.

Клиент - домашний пользователь. подключен по "домашнему" пакету к броадбанд-провайдеру. Работает в корпорации Икс. У него ноутбук, на котором настроена почта на mail.x-corporation.com. На почтовом сервере mail.x-coprotation.com поднята авторизация / SSL. При Вашем подходе он не сможет отправить почту через свой корпоротивный сервер. Второе слабое звено Ваших рассуждений: у пользователя может быть вполне законное желание получить дополнительную гарантию, что его почту никто не читает по дороге, и он вполне вправе не доверять провайдеровскому серверу. Я понятное дело не имею в виду в данном случае Вас лично, или компанию, в которой Вы работаете. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Pavel Narozhnyy

3:44 p.m.

VPN в руки такому клиенту. Вернее, его IT-department. On 1/23/06, Sergey Smitienko wrote:

...

...
1) Они получают адрес не из клиентского блока и соответствующий человеческий резолвинг. Наверняка, за небесплатно, но это снимает все проблемы.

2) Они читают ФАК-Ю на свой корпоративный сервер и понимают смысл слов smarthost или manualroute.

Клиент - домашний пользователь. подключен по "домашнему" пакету к броадбанд-провайдеру. Работает в корпорации Икс. У него ноутбук, на котором настроена почта на mail.x-corporation.com. На почтовом сервере mail.x-coprotation.com поднята авторизация / SSL. При Вашем подходе он не сможет отправить почту через свой корпоротивный сервер.

Второе слабое звено Ваших рассуждений: у пользователя может быть вполне законное желание получить дополнительную гарантию, что его почту никто не читает по дороге, и он вполне вправе не доверять провайдеровскому серверу. Я понятное дело не имею в виду в данном случае Вас лично, или компанию, в которой Вы работаете. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Anton Tolchanov

3:49 p.m.

Pavel Narozhnyy wrote:

...

VPN в руки такому клиенту. Вернее, его IT-department.

Зачём VPN? Для подобных целей подойдёт и корпоративный почтовый сервер, принимающий почту по SMTP over SSL на выделенном порту. Если tcp/25 фильтруют все, кому не лень, то зафильтрованного tcp/465 я в жизни не видел пока ещё ни разу.

...

...
Клиент - домашний пользователь. подключен по "домашнему" пакету к броадбанд-провайдеру. Работает в корпорации Икс. У него ноутбук, на котором настроена почта на mail.x-corporation.com. На почтовом сервере mail.x-coprotation.com поднята авторизация / SSL. При Вашем подходе он не сможет отправить почту через свой корпоротивный сервер.

-- ryzh-uanic =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Alexey Balakin

3:54 p.m.

Pavel Narozhnyy сообщил(а):

...

VPN в руки такому клиенту. Вернее, его IT-department. Тут тоже проблем. При настроеном SMTP-auth, клиент что у себя в офисе, что еще где-нибудь просто жмет отправить в почтовом клиенте - и получает результат.

А Вы предлагаете обучать юзера запуску VPN для отправки почты? -- Alexey Balakin whois -h whois.com.ua SMLL-UANIC =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Pavel Narozhnyy

3:56 p.m.

Именно. Проверено - работает. Если юзер этому необучаем - выгонять с работы. On 1/23/06, Alexey Balakin wrote:

...

Pavel Narozhnyy сообщил(а):

...
VPN в руки такому клиенту. Вернее, его IT-department. Тут тоже проблем. При настроеном SMTP-auth, клиент что у себя в офисе, что еще где-нибудь просто жмет отправить в почтовом клиенте - и получает результат.

А Вы предлагаете обучать юзера запуску VPN для отправки почты?

-- Alexey Balakin whois -h whois.com.ua SMLL-UANIC =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Alexander Trotsai

4:23 p.m.

double click на иконку clink на connect оба-на + доп. шифрование опять же On Mon, Jan 23, 2006 at 05:56:46PM +0200, Pavel Narozhnyy wrote: PN> Именно. Проверено - работает. Если юзер этому необучаем - выгонять с работы. PN> On 1/23/06, Alexey Balakin wrote: PN> > Pavel Narozhnyy сообщил(а): PN> > > VPN в руки такому клиенту. Вернее, его IT-department. PN> > Тут тоже проблем. При настроеном SMTP-auth, клиент что у себя в офисе, что PN> > еще где-нибудь просто жмет отправить в почтовом клиенте - и получает PN> > результат. PN> > PN> > А Вы предлагаете обучать юзера запуску VPN для отправки почты? PN> > -- Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc] Хaлявному Интернету в коннект не смотрят =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

serge pekarsky

4:25 p.m.

Pavel Narozhnyy пишет:

...

Именно. Проверено - работает. Если юзер этому необучаем - выгонять с работы.

"узок их круг и страшно далеки они от народа". VPN не работает сквозь прокси. В-общем, "играйте, как хотите". если в вышеописанной ситуации провайдер закроет наружу 25-й порт и упрется - не захочет открыть, сменим провайдера. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Konstantin N. Bezruchenko

4:46 p.m.

serge pekarsky wrote:

...

Pavel Narozhnyy пишет:

...
Именно. Проверено - работает. Если юзер этому необучаем - выгонять с работы.

"узок их круг и страшно далеки они от народа". VPN не работает сквозь прокси.

OpenVPN. -- Konstantin N. Bezruchenko | BK5536-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Sergey Pershin

8:08 p.m.

On Mon, 23 Jan 2006, Alexander Trotsai wrote:

...

double click на иконку clink на connect

при чем клик на коннект - лишнее. есть галочка - аутоконнект :)

...

оба-на + доп. шифрование опять же

On Mon, Jan 23, 2006 at 05:56:46PM +0200, Pavel Narozhnyy wrote: PN> Именно. Проверено - работает. Если юзер этому необучаем - выгонять с работы.

PN> On 1/23/06, Alexey Balakin wrote: PN> > Pavel Narozhnyy сообщил(а): PN> > > VPN в руки такому клиенту. Вернее, его IT-department. PN> > Тут тоже проблем. При настроеном SMTP-auth, клиент что у себя в офисе, что PN> > еще где-нибудь просто жмет отправить в почтовом клиенте - и получает PN> > результат. PN> > PN> > А Вы предлагаете обучать юзера запуску VPN для отправки почты? PN> >

-- regards, Serge Pershin =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Sergey Pershin

8:10 p.m.

New subject: DoS SMTP( fixed :) )

On Mon, 23 Jan 2006, Alexander Trotsai wrote:

...

double click на иконку clink на connect

причем клик на коннект - лишнее. есть галочка - аутоконнект :)

...

оба-на + доп. шифрование опять же

On Mon, Jan 23, 2006 at 05:56:46PM +0200, Pavel Narozhnyy wrote: PN> Именно. Проверено - работает. Если юзер этому необучаем - выгонять с работы.

PN> On 1/23/06, Alexey Balakin wrote: PN> > Pavel Narozhnyy сообщил(а): PN> > > VPN в руки такому клиенту. Вернее, его IT-department. PN> > Тут тоже проблем. При настроеном SMTP-auth, клиент что у себя в офисе, что PN> > еще где-нибудь просто жмет отправить в почтовом клиенте - и получает PN> > результат. PN> > PN> > А Вы предлагаете обучать юзера запуску VPN для отправки почты? PN> >

6814

Age (days ago)

6818

Last active (days ago)

List overview

Download

37 comments

18 participants

participants (18)

Alexander Trotsai
Alexey Balakin
Andrei Biryukov
Andrey Nikolaev
Anton Tolchanov
boris mostovoy
Dmitry Cherkasov
Dmitry Cherkasov
Konstantin N. Bezruchenko
Michael Petuschak
Oleh Hrynchuk
Paul Arakelyan
Pavel Narozhnyy
serge pekarsky
Sergey Pershin
Sergey Smitienko
Victor Forsyuk
vladimir.sharun＠ukr.net

DoS SMTP

Oleh Hrynchuk

Paul Arakelyan

Dmitry Cherkasov

Oleh Hrynchuk

boris mostovoy

Oleh Hrynchuk

boris mostovoy

Michael Petuschak

Andrei Biryukov

boris mostovoy

Victor Forsyuk

serge pekarsky

Victor Forsyuk

serge pekarsky

Victor Forsyuk

serge pekarsky

Victor Forsyuk

serge pekarsky

Victor Forsyuk

Anton Tolchanov

Alexey Balakin

serge pekarsky

Konstantin N. Bezruchenko

Sergey Pershin

Sergey Pershin

tags

participants (18)